Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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. --

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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 packages

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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 rust

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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: >

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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 P

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

[ 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

Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

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

Re: Unmet :native dependency error when cross-compiling with dpkg-buildpackage

ll > 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 fails with the following error: > > Command: dpkg-buildpackage --sanit

Unmet :native dependency error when cross-compiling with dpkg-buildpackage

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 has build-time

Re: Is running dpkg-buildpackage manually from the command line forbidden?

(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

Re: Is running dpkg-buildpackage manually from the command line forbidden?

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

Re: Is running dpkg-buildpackage manually from the command line forbidden?

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. > >

Re: Is running dpkg-buildpackage manually from the command line forbidden?

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

Re: Is running dpkg-buildpackage manually from the command line forbidden?

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

Re: Is running dpkg-buildpackage manually from the command line forbidden?

, 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 build failures in non-standard

Re: Is running dpkg-buildpackage manually from the command line forbidden?

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

Re: Is running dpkg-buildpackage manually from the command line forbidden?

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

Re: Is running dpkg-buildpackage manually from the command line forbidden?

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 relationsh

Re: Is running dpkg-buildpackage manually from the command line forbidden?

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

Re: Is running dpkg-buildpackage manually from the command line forbidden?

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 >

Re: Is running dpkg-buildpackage manually from the command line forbidden?

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

Re: Is running dpkg-buildpackage manually from the command line forbidden?

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.

Re: Is running dpkg-buildpackage manually from the command line forbidden?

> "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

Re: Is running dpkg-buildpackage manually from the command line forbidden?

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

Re: Is running dpkg-buildpackage manually from the command line forbidden?

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-buildp

Re: Is running dpkg-buildpackage manually from the command line forbidden?

e 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, with > maintai

Re: Is running dpkg-buildpackage manually from the command line forbidden?

er 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 produce a clean, simple p

Re: Is running dpkg-buildpackage manually from the command line forbidden?

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 b

Is running dpkg-buildpackage manually from the command line forbidden?

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-buildpackage

Re: make dpkg-buildpackage default locale UTF-8

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 "©"

Re: make dpkg-buildpackage default locale UTF-8

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 debia

Re: make dpkg-buildpackage default locale UTF-8

]] 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? >

Re: make dpkg-buildpackage default locale UTF-8

> 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

Re: make dpkg-buildpackage default locale UTF-8

]] 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. > >

Re: make dpkg-buildpackage default locale UTF-8

> 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

Re: make dpkg-buildpackage default locale UTF-8

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

Re: Bug#873919: make dpkg-buildpackage default locale UTF-8

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_

make dpkg-buildpackage default locale UTF-8

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

Re: Mass bug filing: dpkg-buildpackage -A

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

Re: Mass bug filing: dpkg-buildpackage -A

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. > >

Re: Mass bug filing: dpkg-buildpackage -A

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

Re: Mass bug filing: dpkg-buildpackage -A

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

Mass bug filing: dpkg-buildpackage -A

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 dedic

Re: Mass bug filing: dpkg-buildpackage -A

* Santiago Vila <sanv...@unex.es>, 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 severi

Re: Mass bug filing: dpkg-buildpackage -A

On Mon, Nov 23, 2015 at 11:29:19AM +0100, Jakub Wilk wrote: > * Santiago Vila <sanv...@unex.es>, 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 c

Re: Mass bug filing: dpkg-buildpackage -A

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

Re: Mass bug filing: dpkg-buildpackage -A

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

Re: Mass bug filing: dpkg-buildpackage -A

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

Re: Mass bug filing: dpkg-buildpackage -A

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 bei

Re: Mass bug filing: dpkg-buildpackage -A

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-independent

Re: Mass bug filing: dpkg-buildpackage -A

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

Re: Heads up: Upcoming dpkg-buildpackage -j precedence change

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 parallel runs in combination with -j

Re: Heads up: Upcoming dpkg-buildpackage -j precedence change

+++ 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 maintained as

Re: Heads up: Upcoming dpkg-buildpackage -j precedence change

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 parallel runs in combination with -j, or a new option

Re: Heads up: Upcoming dpkg-buildpackage -j precedence change

On Wed, May 13, 2015 at 2:21 PM, Guillem Jover guil...@debian.org 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 upstream

Re: Heads up: Upcoming dpkg-buildpackage -j precedence change

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 are

Re: Heads up: Upcoming dpkg-buildpackage -j precedence change

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 adjusting parallel

Re: Heads up: Upcoming dpkg-buildpackage -j precedence change

=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 buggy. No. This is the equivalent distinction

Re: Heads up: Upcoming dpkg-buildpackage -j precedence change

+++ 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 overrides any explicit value

Re: Heads up: Upcoming dpkg-buildpackage -j precedence change

? 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_BUILD_OPTIONS=parallel=4 dpkg-buildpackage -b fails

Heads up: Upcoming dpkg-buildpackage -j precedence change

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

Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)

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 features

Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)

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 provided. That would

Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)

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 older tool in

Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)

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

Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)

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

Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)

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 debsign

Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)

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

Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)

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

Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)

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 debsign explicitly after dpkg-buildpackage completed

Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)

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 buildd uploads, we run debsign

Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)

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 a...@debian.org Please disable signing by default. Generally

Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)

. But there'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't use dpkg

Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)

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 subject of unsubscribe. Trouble

Re: dpkg-buildpackage creating uninstallable packages?

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

Re: dpkg-buildpackage creating uninstallable packages?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Norbert Preining prein...@logic.at 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 -

Re: dpkg-buildpackage creating uninstallable packages?

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

Re: dpkg-buildpackage creating uninstallable packages?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Norbert Preining prein...@logic.at 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

Re: dpkg-buildpackage creating uninstallable packages?

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

Re: dpkg-buildpackage creating uninstallable packages?

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:

Re: dpkg-buildpackage creating uninstallable packages?

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. Uninstall

Re: dpkg-buildpackage creating uninstallable packages?

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

Re: dpkg-buildpackage creating uninstallable packages?

On Sun, 29 Sep 2013 08:58:36 +0200, Sven Joachim svenj...@gmx.de 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

dpkg-buildpackage creating uninstallable packages?

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

Re: dpkg-buildpackage creating uninstallable packages?

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 amd64

Re: debuild/dpkg-buildpackage behaves not as expected

debian-de...@liska.ath.cx (Olе Streicher) writes: Goswin von Brederlow goswin-...@web.de 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

Re: debuild/dpkg-buildpackage behaves not as expected

: why does debuild (or dpkg-buildpackage) undo the patches if they were not applied before? In this case, it would be up to the (rare) people to unpatch if they need this. One could even provide a debuild/dpkg-buildpackage option for that (like --unpatch-after-build or so), or do it in a hook

Re: debuild/dpkg-buildpackage behaves not as expected

Goswin von Brederlow goswin-...@web.de 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 patches. It only

Re: debuild/dpkg-buildpackage behaves not as expected

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 dpkg-buildpackage) undo the patches if they were not applied before? In this case, it would

Re: debuild/dpkg-buildpackage behaves not as expected

* 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 repository with unpatched source cd repo ... tweak a little ... dpkg-buildpackage; # applies patches, builds, and unapplies patches vcs diff

Re: debuild/dpkg-buildpackage behaves not as expected

for that? As was described in #649531: vcs clone repository with unpatched source cd repo ... tweak a little ... dpkg-buildpackage; # applies patches, builds, and unapplies patches vcs diff; # looks good? vcs commit This works only for the special case that build does not change any source

  1   2   3   4   5   >