Thanks to everyone for the comments and review. I have written things
up on the wiki:
https://wiki.debian.org/BuildProfile/upstream-cargo
and added the entry here:
https://wiki.debian.org/BuildProfileSpec
Please comment here, if you think any of this doesn't make sense.
Thanks,
Ian.
--
Ian
On Fri, 16 Dec 2022 at 11:01:58 +, Ian Jackson wrote:
> With nopython, we want to *avoid doing the Python things at all*. But
> "the Python things" here isn't "all Python things" - it's "certain
> Python things that appear in the outputs". So that can't be done as a
> blanket exclusion on B-d
Quoting Russ Allbery (2022-12-16 17:07:00)
> Jonas Smedegaard writes:
> > Quoting Russ Allbery (2022-12-15 17:41:15)
>
> >> This is why I don't agree with Jonas: yes, there *are* other ways to
> >> achieve the same goal, but they're more complicated and harder to
> >> explain. The user experienc
Jonas Smedegaard writes:
> Quoting Russ Allbery (2022-12-15 17:41:15)
>> This is why I don't agree with Jonas: yes, there *are* other ways to
>> achieve the same goal, but they're more complicated and harder to
>> explain. The user experience of this build profile looks a lot simpler
>> and clea
Quoting Russ Allbery (2022-12-15 17:41:15)
> Ian Jackson writes:
>
> > I would like to add the following entry to the table of build
> > profiles in BuildProfileSpec:
>
> > Profile anme: `cargo-upstream`
> > Can cause changes to built binaries, including functional chnges. (Y)
> > Should not
Helmut Grohne writes ("Re: Proposed `cargo-upstream` dpkg-buildpackage etc.
build profile"):
> On Thu, Dec 15, 2022 at 11:44:34PM +, Ian Jackson wrote:
> > I'm not sure precisely how this feature could (or should) be made
> > available to *all* application pack
Hi Ian,
On Thu, Dec 15, 2022 at 11:44:34PM +, Ian Jackson wrote:
> I'm not sure precisely how this feature could (or should) be made
> available to *all* application packages in a central way. Having
> tools like debcargo automatically add the profile to the build deps
> produces a lot of blo
Helmut Grohne writes ("Re: Proposed `cargo-upstream` dpkg-buildpackage etc.
build profile"):
> Thank you very much for immediately taking this to the list.
You're welcome.
Thanks for the review and the penetrating questions.
> I think that you imply here that all of the ru
Hi Ian,
Thank you very much for immediately taking this to the list. The
discussion I've seen thus far seems very constructive and useful to me.
Thanks to the other participants as well.
On Thu, Dec 15, 2022 at 10:41:13AM +, Ian Jackson wrote:
> I would like to add the following entry to the
Ian Jackson writes:
> I would like to add the following entry to the table of build
> profiles in BuildProfileSpec:
> Profile anme: `cargo-upstream`
> Can cause changes to built binaries, including functional chnges. (Y)
> Should not cause changes to set of build debs. (N)
> Description:
>
Quoting Ian Jackson (2022-12-15 14:05:32)
> Jonas Smedegaard writes ("Re: Proposed `cargo-upstream` dpkg-buildpackage
> etc. build profile"):
> > What is the benefit of introducing a standardized flag for this
> > relatively narrow scope, compared to doing non-standar
Wouter Verhelst writes ("Re: Proposed `cargo-upstream` dpkg-buildpackage etc.
build profile"):
> I have just one question: why make this rust-specific? I think a similar
> thing might be useful for golang packages (who also don't support shared
> libraries), or, heck, even
Jonas Smedegaard writes ("Re: Proposed `cargo-upstream` dpkg-buildpackage etc.
build profile"):
> Similar pain for other upstream ecosystems as well - I know about npm
> for NodeJS modules, but imagine it is similar for Java and others as
> well.
Yes.
> What is the be
Hi Ian,
On Thu, Dec 15, 2022 at 10:41:13AM +, Ian Jackson wrote:
> I would like to add the following entry to the table of build
> profiles in BuildProfileSpec:
>
> Profile anme: `cargo-upstream`
> Can cause changes to built binaries, including functional chnges. (Y)
> Should not cause cha
[ reply to d-devel only, as more suitable for Debian-wide issue ]
Quoting Ian Jackson (2022-12-15 11:41:13)
> I would like to add the following entry to the table of build
> profiles in BuildProfileSpec:
>
> Profile anme: `cargo-upstream`
> Can cause changes to built binaries, including functio
I would like to add the following entry to the table of build
profiles in BuildProfileSpec:
Profile anme: `cargo-upstream`
Can cause changes to built binaries, including functional chnges. (Y)
Should not cause changes to set of build debs. (N)
Description:
Obtain Rust dependencies from crat
self is being compiled using sbuild. During "Install
> package
> build dependencies" stage, 'swig:native' is correctly resolved to
> 'swig:amd64'. All deps are correctly installed, then. But later, when it
> comes
> to dpkg-buildpackage stage, it f
Hello.
While experimenting with cross-compilation I faced an error that looks like a
bug in dpkg-buildpackage for me.
The conditions are the following:
Build Architecture: amd64
Host Architecture: arm64
The package I'm trying to cross-build is 'u-boot' with some patches. It
(Disclaimer: This is a xkcd:386-like response to this subthread)
> Here's the current list of these packages on my system:
>
> $ aptitude -F '%p' search '~prequired !~E'
The list omits 'apt' as a libapt internally flags it as essential to
grant it the utmost protection by all clients along wit
On Fri, Jan 17, 2020 at 03:02:06AM +, Paul Wise wrote:
> Personally, I think there is value in Daniel's work on bootstrapping
> Debian from other operating systems and Helmut's work on bootstrapping
> Debian from existing Debian architectures. Both are important projects
> and we need Debian an
On Fri, 2020-01-17 at 10:58 +0100, Johannes Schauer wrote:
> Quoting Simon McVittie (2020-01-16 19:47:02)
> > I think I dimly remember someone setting up "the buildd from hell" which
> > deliberately did this as a QA mechanism, but it doesn't seem to have
> > continued in any systematic way.
>
> i
On Fri, Jan 17, 2020 at 2:05 AM Johannes Schauer wrote:
> yes, probably a communication problem. I think you are talking about [1] from
> August 11 last year? I replied the same day, telling you to please file a bug
> with your patches to continue discussion there. But then there was no response
>
Hi,
Quoting Daniel Schepler (2020-01-17 17:58:09)
> > I'm also very excited about having yet another chroot backend being
> > integrated into sbuild! Though my first comment would be the same as I gave
> > those asking for a docker backend in #867176: maybe try adding that backend
> > to autopkgte
> true bugs, or whether I'm at fault for trying to run dpkg-buildpackage
> manually instead of using it through pbuilder or sbuild.
Given that I'm also bootstrapping Debian (in a different setting), I'm
running into much the same problems. However, when I file bugs about
b
d -lssp when
> building with -fstack-protector-strong or -fstack-protector as almost
> all Debian packages do. To anybody on the list: is there something I
> did wrong with the cross build there, which was to run
> "dpkg-buildpackage -a i386 -B -Pcross"?)
This sounds a
On Fri, 2020-01-17 at 11:12:50 +0100, Ansgar wrote:
> Johannes Schauer writes:
> > My advice would also be to switch from debootstrap to mmdebstrap because the
> > latter is able to create a chroot with only Essential:yes packages in it
> > while
> > debootstrap includes Priority:required packages
way.
> These are where I found that having extra packages installed during
> the dpkg-buildpackage run either failed or resulted in broken
> packages. (Some examples of the type of thing I mean: #948522,
> #887902.)
I would expect a sensible package build to not depend on package
rela
Johannes Schauer writes:
> My advice would also be to switch from debootstrap to mmdebstrap because the
> latter is able to create a chroot with only Essential:yes packages in it while
> debootstrap includes Priority:required packages as well. Alternatively,
> debootstrap could gain a variant only
Hi Daniel, Sam and all,
Quoting Sam Hartman (2020-01-17 01:27:52)
> > "Daniel" == Daniel Schepler writes:
>
> Daniel> (Incidentally, another offshoot was creating local patches to
> sbuild
> Daniel> which add an operation mode using systemd-nspawn --ephemeral to
> start
> Danie
Hi,
Quoting Simon McVittie (2020-01-16 19:47:02)
> I think I dimly remember someone setting up "the buildd from hell" which
> deliberately did this as a QA mechanism, but it doesn't seem to have
> continued in any systematic way.
is there more information about it somewhere? My inbox has only two
On Thu, Jan 16, 2020 at 7:18 PM Ondřej Surý wrote:
> while your effort is valiant, I see a little value in it as there’s no real
> world use case. While your arguments are valid, you are imposing additional
> work on generally already overloaded maintainers with unclear goal and
> purpose.
Per
> "Daniel" == Daniel Schepler writes:
Daniel> (Incidentally, another offshoot was creating local patches to sbuild
Daniel> which add an operation mode using systemd-nspawn --ephemeral to
start
Daniel> a container (along with the base being a BTRFS subvolume to speed up
Daniel
or as almost
all Debian packages do. To anybody on the list: is there something I
did wrong with the cross build there, which was to run
"dpkg-buildpackage -a i386 -B -Pcross"?)
--
Daniel Schepler
nning a manual test bootstrap of Debian (starting with
> cross-compiled packages amd64 -> i386 up to the point I was able to
> install debhelper), and posting a few bugs I've found along the way.
> These are where I found that having extra packages installed during
> the dpkg
; These are where I found that having extra packages installed during
> the dpkg-buildpackage run either failed or resulted in broken
> packages. (Some examples of the type of thing I mean: #948522,
> #887902.)
>
> However, I've been getting push back on some of these, wi
ns on whether these are
Daniel> true bugs, or whether I'm at fault for trying to run
dpkg-buildpackage
Daniel> manually instead of using it through pbuilder or sbuild.
I think it is often a bug, but rarely if ever a serious bug.
I'd say that a good test is whether you can pr
On Thu, 2020-01-16 at 08:50 -0800, Daniel Schepler wrote:
> These are where I found that having extra packages installed during
> the dpkg-buildpackage run either failed or resulted in broken
> packages. (Some examples of the type of thing I mean: #948522,
> #887902.)
If you bui
I've been running a manual test bootstrap of Debian (starting with
cross-compiled packages amd64 -> i386 up to the point I was able to
install debhelper), and posting a few bugs I've found along the way.
These are where I found that having extra packages installed during
the dpkg-bui
On Mon, Sep 04, 2017 at 01:45:25PM +0800, 殷啟聰 | Kai-Chung Yan wrote:
> +1 to setting UTF-8 as default.
>
> Some Java packages that I worked with contain source files with symbols not
> recognized by compilers unless the encoding is set to UTF-8. Mostly these
> symbols are a copyright sign "©" ap
and I had a discussion in #debian-devel. It
> looks like setting the default locale to C.UTF-8 in dpkg-buildpackage is
> an easy way to improve this situation a lot. Any package that needs an
> encoding besides UTF-8 could always set it by adding something like this
> to debian/rules
]] Ivan Shmakov
> > Tollef Fog Heen writes:
> > Ivan Shmakov
> > Hans-Christoph Steiner writes:
>
> >>> Package: dpkg-dev
>
> >>> More and more packages are adding unicode files
>
> >> I assume you mean “UTF-8 filenames” here (per below), right?
>
> >>> as unicode support ha
> Tollef Fog Heen writes:
> Ivan Shmakov
> Hans-Christoph Steiner writes:
>>> Package: dpkg-dev
>>> More and more packages are adding unicode files
>> I assume you mean “UTF-8 filenames” here (per below), right?
>>> as unicode support has become more reliable and available.
]] Ivan Shmakov
> > Hans-Christoph Steiner writes:
>
> > Package: dpkg-dev
>
> > More and more packages are adding unicode files
>
> I assume you mean “UTF-8 filenames” here (per below), right?
>
> > as unicode support has become more reliable and available.
>
> What are
> Hans-Christoph Steiner writes:
> Package: dpkg-dev
> More and more packages are adding unicode files
I assume you mean “UTF-8 filenames” here (per below), right?
> as unicode support has become more reliable and available.
What are the use cases for such filenames?
Hans-Christoph Steiner writes ("make dpkg-buildpackage default locale UTF-8"):
> More and more packages are adding unicode files as unicode support has
> become more reliable and available. The package building process is not
> guaranteed to happen in a unicode locale since
in #debian-devel. It
> looks like setting the default locale to C.UTF-8 in dpkg-buildpackage is
> an easy way to improve this situation a lot. Any package that needs an
> encoding besides UTF-8 could always set it by adding something like this
> to debian/rules:
>
> export LC_
filenames when the
system is using ASCII causes errors (Python makes them very visible, for
example).
mbiebl, youpi, wRAR, bunk, and I had a discussion in #debian-devel. It
looks like setting the default locale to C.UTF-8 in dpkg-buildpackage is
an easy way to improve this situation a lot. Any package
Hi.
I will put all the bugs that I report about this issue here:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=binary-indep;users=sanv...@debian.org
So far there are one that I reported 19 days ago as a "test report"
and 162 that I reported today. I'm intentionally excluding packages
having
On Tue, Nov 24, 2015 at 00:41:35 +0100, Santiago Vila wrote:
> On Mon, Nov 23, 2015 at 08:42:14PM +0100, Julien Cristau wrote:
> > On Tue, Nov 24, 2015 at 06:14:43 +1100, Ben Finney wrote:
> >
> > > If it's a “severe violation of Debian policy”, the bug is at least
> > > “serious” severity.
> > >
On Mon, Nov 23, 2015 at 08:42:14PM +0100, Julien Cristau wrote:
> On Tue, Nov 24, 2015 at 06:14:43 +1100, Ben Finney wrote:
>
> > If it's a “severe violation of Debian policy”, the bug is at least
> > “serious” severity.
> >
> The release team's RC policy decides which policy violations we consid
On Tue, 2015-11-24 at 08:48 +1100, Ben Finney wrote:
> Julien Cristau writes:
>
> > On Tue, Nov 24, 2015 at 06:14:43 +1100, Ben Finney wrote:
> >
> > > If it's a “severe violation of Debian policy”, the bug is at least
> > > “serious” severity.
>
> This is one way that a bug can be determined “S
Julien Cristau writes:
> On Tue, Nov 24, 2015 at 06:14:43 +1100, Ben Finney wrote:
>
> > If it's a “severe violation of Debian policy”, the bug is at least
> > “serious” severity.
This is one way that a bug can be determined “Severity: serious”, by
definition.
In other words: “severe violation
Santiago Vila wrote:
> I've noticed that some packages fail to build from source when built
> using "dpkg-buildpackage -A".
>
> This is not only a violation of policy, but also prevents the package
> from being uploaded in source-only form, as the architecture-indepe
On Tue, Nov 24, 2015 at 06:14:43 +1100, Ben Finney wrote:
> If it's a “severe violation of Debian policy”, the bug is at least
> “serious” severity.
>
The release team's RC policy decides which policy violations we consider
"severe" in the sense of "gets a serious severity bug".
Cheers,
Julien
Santiago Vila writes:
> On Mon, Nov 23, 2015 at 11:29:19AM +0100, Jakub Wilk wrote:
> > I'd use "severity: serious", just like for a normal FTBFS.
>
> The problem with making them "severity: serious" is that I would be
> deciding on my own that those bugs are RC. Normally, the release team
> deci
On Mon, Nov 23, 2015 at 05:51:44PM +0100, Thomas Goirand wrote:
> > As the number of bugs is going to be greater than ten
>
> Do you have the exact figures? How many packages are affected?
I don't have exact figures yet, but I estimate about 300, more or less.
I considered the source packages ge
On 11/23/2015 10:52 AM, Santiago Vila wrote:
> Greetings.
>
> I've noticed that some packages fail to build from source when built
> using "dpkg-buildpackage -A".
>
> This is not only a violation of policy, but also prevents the package
> from being
On Mon, Nov 23, 2015 at 11:29:19AM +0100, Jakub Wilk wrote:
> * Santiago Vila , 2015-11-23, 10:52:
> >I've noticed that some packages fail to build from source when built using
> >"dpkg-buildpackage -A".
> [...]
> >I think those are clearly bugs, and they sho
* Santiago Vila , 2015-11-23, 10:52:
I've noticed that some packages fail to build from source when built
using "dpkg-buildpackage -A".
[...]
I think those are clearly bugs, and they should be reported. The only
thing that may be unclear is the severity. I would like this to be
Greetings.
I've noticed that some packages fail to build from source when built
using "dpkg-buildpackage -A".
This is not only a violation of policy, but also prevents the package
from being uploaded in source-only form, as the architecture-independent
packages are generated by a
t; >
> > > $ DEB_BUILD_OPTIONS=parallel=N debian/rules build
> >
> > I prefer the latter behaviour but the former brevity. Would you consider
> > something like -J in dpkg-buildpackage adjusting parallel= in
> > DEB_BUILD_OPTIONS, and perhaps in the future phasing
+++ Jonas Smedegaard [2015-05-13 15:44 +0200]:
> Quoting Julian Taylor (2015-05-13 14:48:02)
> > Are those still parallel or does the flag override all submakes? The
> > option is not documented in make's manpage.
>
> From make man page:
>
> > SEE ALSO
> >
> > The full documentation for make is
Quoting Julian Taylor (2015-05-13 14:48:02)
> Are those still parallel or does the flag override all submakes? The
> option is not documented in make's manpage.
From make man page:
> SEE ALSO
>
> The full documentation for make is maintained as a Texinfo manual. If
> the info and make programs
On Wed, May 13, 2015 at 2:21 PM, Guillem Jover wrote:
> IMO dpkg-buildpackage should assume yes, in the same way it assumes
> packages are cross-buildable, and we don't go around marking them as
> such. But I guess for Debian that depends on how much of our packaging
> and upstr
allel=N debian/rules build
>
> I prefer the latter behaviour but the former brevity. Would you consider
> something like -J in dpkg-buildpackage adjusting parallel= in
> DEB_BUILD_OPTIONS, and perhaps in the future phasing out -j?
Sure, adding either an option to disable the forced p
On Mon, May 11, 2015 at 08:40:16PM +0200, Guillem Jover wrote:
> $ make -jN -f debian/rules build
>
> and
>
> $ DEB_BUILD_OPTIONS=parallel=N debian/rules build
I prefer the latter behaviour but the former brevity. Would you consider
something like -J in dpkg-buildpackage adjusti
lds,
> > that -j and DEB_BUILD_OPTIONS=parallel= are not exactly the same. Is
> > that expected?
Yes, this is expected, there was a bug report recently asking to
clarify this in the man page, fixed in master and will be included
in the upcoming dpkg 1.18.0 release.
> dpkg-buildpackage -j is
expected? If not then it should perhaps be considered/investigated in
> case other builds are sensitive to the difference?
>
> here is a message from Ed Grimley-Evans, checking the FTBFS:
> ---
> freecdb illustrates the problem repeatably:
>
> works:
>DEB_BUIL
+++ Guillem Jover [2015-05-10 04:53 +0200]:
> Hi!
>
> “Recently” when adding support for «-jauto» to dpkg-buildpackage, I
> noticed that the semantics for the -j option were quite unorthodox.
> The value from the DEB_BUILD_OPTIONS paralle= option takes precedence
> and over
Hi!
“Recently” when adding support for «-jauto» to dpkg-buildpackage, I
noticed that the semantics for the -j option were quite unorthodox.
The value from the DEB_BUILD_OPTIONS paralle= option takes precedence
and overrides any explicit value passed on the commend-line via -j,
(when -j should be
Am Sonntag, den 05.01.2014, 15:09 +0100 schrieb Guillem Jover:
> On Thu, 2014-01-02 at 17:22:33 +, Jonathan Dowland wrote:
> > You raise some very valid points and §I appreciate your concerns and
> > perhaps should rephrase my request so that I'm suggesting subsuming the
> > most common used fe
On Thu, 2014-01-02 at 17:22:33 +, Jonathan Dowland wrote:
> You raise some very valid points and §I appreciate your concerns and
> perhaps should rephrase my request so that I'm suggesting subsuming the
> most common used features of debsign and perhaps as part of a staged
> migration (compat s
On Sunday 05 January 2014 11:58:07 Didier 'OdyX' Raboud wrote:
> Le samedi, 4 janvier 2014, 19.54:05 Stefano Rivera a écrit :
> > Hi Jonathan (2014.01.02_19:22:33_+0200)
> >
> > > > * having to support remote signing
> > >
> > > It would be fair enough to stderr "not supported, please use the
>
Le samedi, 4 janvier 2014, 19.54:05 Stefano Rivera a écrit :
> Hi Jonathan (2014.01.02_19:22:33_+0200)
>
> > > * having to support remote signing
> >
> > It would be fair enough to stderr "not supported, please use the
> > older tool in devscripts" and error 1 if such an argument was
> > provide
Hi Jonathan (2014.01.02_19:22:33_+0200)
> > * having to support remote signing
>
> It would be fair enough to stderr "not supported, please use the older
> tool in devscripts" and error 1 if such an argument was provided. That
> would be pragmatic if (as I suspect) -r is rarely used.
Aww. I'm a
Roger Leigh writes ("Re: Bug#733029: dpkg-buildpackage: disable signing by
default (-us -uc should be the default)"):
> On the sbuild/buildd side, we have run dpkg-buildpackage with
> "-us -uc" by default for years. If you do enable signing, as is
> the case for b
gh
> with the current no-signing-UNRELEASED behaviour, the need for -us -uc
> should have dropped in many cases.
On the sbuild/buildd side, we have run dpkg-buildpackage with
"-us -uc" by default for years. If you do enable signing, as is
the case for buildd uploads, we run de
You raise some very valid points and §I appreciate your concerns and
perhaps should rephrase my request so that I'm suggesting subsuming the
most common used features of debsign and perhaps as part of a staged
migration (compat symlink to debsign binary name in the phase 1, real
name dpkg-sign or w
Hi!
On Thu, 2014-01-02 at 09:24:55 +, Jonathan Dowland wrote:
> On Mon, Dec 30, 2013 at 12:27:29PM +0100, Guillem Jover wrote:
> > * signing would get rafactored into a new program so that users do
> >not need to manually mangle the .changes file, rebuild or require
> >devscripts for
On Mon, Dec 30, 2013 at 12:27:29PM +0100, Guillem Jover wrote:
> * signing would get rafactored into a new program so that users do
>not need to manually mangle the .changes file, rebuild or require
>devscripts for something that was possible out-of-the-box.
I chose to read that as "debsi
d that this change should dealt together with a general revamp of
dpkg-buildpackage.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subjec
here's few things that I'd
want to tackle first:
[...]
* (possibly) new options would get added to specify signing, although
there's --force-sign since 1.17.0, which could be used already on the
buildds.
I took a look at a random build log[0], and it looks like buildds don
Hi!
[ CCing debian-devel to get input from possibly afftected users. ]
On Tue, 2013-12-24 at 15:14:22 +0800, Paul Wise wrote:
> Package: dpkg-dev
> Severity: wishlist
> File: /usr/bin/dpkg-buildpackage
> X-Debbugs-CC: Arno Töll
>
> Please disable signing by default. General
severity 699206 serious
thanks
Hi Dominik,
first of all, please stop including all the email and bottom-posting,
this is a pain and against usual netiquette.
Then ...
On Mo, 30 Sep 2013, Dominik George wrote:
> If you accuse everyone else in the community
[...]
I did not accuse anyone, I ask
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Norbert Preining schrieb:
>Hi Dominik,
>
>> Simply put: Because you made no effort to fix it :).
>
>Thanks for the very useful comment.
>
>Yes, I care for RC bugs in my own packages ... and that are quite
>a lot. So no time to fix RC bugs of other
Hi Dominik,
> Simply put: Because you made no effort to fix it :).
Thanks for the very useful comment.
Yes, I care for RC bugs in my own packages ... and that are quite
a lot. So no time to fix RC bugs of other maintainers.
Norbert
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Norbert Preining schrieb:
>On So, 29 Sep 2013, Stephen Kitt wrote:
>> > Uninstall the libc6-amd64:i386 package.
>> > See http://lists.debian.org/debian-mentors/2013/03/msg00139.html.
>>
>> But watch out for http://bugs.debian.org/699206 - make sur
On So, 29 Sep 2013, Stephen Kitt wrote:
> > Uninstall the libc6-amd64:i386 package.
> > See http://lists.debian.org/debian-mentors/2013/03/msg00139.html.
>
> But watch out for http://bugs.debian.org/699206 - make sure you have a root
> sash running somewhere so you can relink /lib64/ld-linux-x86-6
On Sun, 29 Sep 2013 08:58:36 +0200, Sven Joachim wrote:
> On 2013-09-28 22:18 +0200, Norbert Preining wrote:
> > since a short time when I build a binary package on my running system,
> > I cannot install the created .deb anymore because it depends on
> > libc-amd64 (>= some.version) which somehow
On 29-09-13 08:40, Norbert Preining wrote:
> What is going wrong here?
For whatever reason, the amd64 build is picking up i386 paths. I don't
know how that happens, except that I expect it is some multi-arch
twitch. I recommend you build your packages in a chroot to avoid this
(an other) issues. I
On 2013-09-28 22:18 +0200, Norbert Preining wrote:
> since a short time when I build a binary package on my running system,
> I cannot install the created .deb anymore because it depends on
> libc-amd64 (>= some.version) which somehow is not what I have although
> I am running amd64 sid.
Uninstal
Hi everyone,
second try, with more data ..
default package texinfo, I am importing a new upstream into my git,
no changes to debian/rules or debian/control, rebuild.
>From the debian/control:
..
Package: info
...
Architecture: any
Multi-Arch: foreign
...
After building the package looks like:
i
On Sun, Sep 29, 2013 at 12:18:03AM +0400, Norbert Preining wrote:
> since a short time when I build a binary package on my running system, I
> cannot install the created .deb anymore because it depends on
>libc-amd64 (>= some.version)
> which somehow is not what I have although I am running am
Hi everyone,
since a short time when I build a binary package on my running system, I cannot
install the created .deb anymore because it depends on
libc-amd64 (>= some.version)
which somehow is not what I have although I am running amd64 sid.
Any suggestions?
Thanks
Norbert
---
debian-de...@liska.ath.cx (Olе Streicher) writes:
> Goswin von Brederlow writes:
>> debian-de...@liska.ath.cx (Ole Streicher) writes:
>>> I think the best way would be that debuild/dpkg-buildpackage would not
>>> automatically unapply the patches (so it would leav
Goswin von Brederlow writes:
> debian-de...@liska.ath.cx (Ole Streicher) writes:
>> I think the best way would be that debuild/dpkg-buildpackage would not
>> automatically unapply the patches (so it would leave the source in the
> It doesn't automatically unapply the pa
gt;>> source, so only the patched version knows for sure how to clean it up.
>
>> Note that it only calls clean with unpatched sources if you
>> specifically unpatched your source before calling it.
>
> If you insist so much on this standard: why does debuild (or
>
is just the better design: the package was built with a patched
>> source, so only the patched version knows for sure how to clean it up.
> Note that it only calls clean with unpatched sources if you
> specifically unpatched your source before calling it.
If you insist so much on this s
ng the sources *before* the build process was cleaned up makes
>>>>> no sense to me at all. Could you provide a use case for that?
>>>> As was described in #649531:
>>>>
>>>> vcs clone
>>>> cd repo
>>>> ... twe
no sense to me at all. Could you provide a use case for that?
>>> As was described in #649531:
>>>
>>> vcs clone
>>> cd repo
>>> ... tweak a little ...
>>> dpkg-buildpackage; # applies patches, builds, and unapplies patches
>>>
1 - 100 of 432 matches
Mail list logo