Commonly, I update a package that provides a shared library. Due to the package naming convention, a new SOVERSION necessitates a trip through NEW, which in turn means a binary upload.

The binary upload cannot transition to testing -- a buildd binary build is required. So far as I know -- assuming [1] is still up-to-date, this means a nuisance upload just bumping the debian revision from -1 to -2. Is this still the recommended practice?

I've also been wondering about the "Give Back" action button on the buildd log page. It doesn't work in this case because "Package in state Installed, cannot give back. ✗". Wondering if the logic can be modified to also check whether the build was done on a buildd -- e.g. check whether the logs column contains "no log". If it wasn't a buildd build, can the giveback be allowed?

Thanks,
-Steve

[1] https://wiki.debian.org/SourceOnlyUpload

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEy89k8fa3rclNjyokyeVeL63I9LkFAmMFTa4ACgkQyeVeL63I 9LndLg/+Kzg8zr7SuUnx9IePKM9X6Q8NMHXFbtNscpXEmhLhc4T9oNd2mTqcQmfj +bMxxQr8/0cjV6vKj3eSRjdWBfok0VsTSl//z79owbBksZ9swdB+2NUlWUugI1ty oU63Vv0yO6dJwSVYu8Owii6bl+SzcexlibRFNZ0briZmnuJxR4rYb16aYQbQEZUS ZPTzgMTjLnM0NhJ+F2wlOQhfi8U8K3jmvgCF3MG3tO9X3Lav0noDqnlnll+xnFgl G6k8vN3jyBF9NsOrTV0HD1OcIL4d2ccChCdme4GJZXyPMj4b+aFyx9a23lIBmesG IO90b3Gh/LCGMXhIvCUIjmO6LMYuNYn8FOrbFWSGX9q54zW5mKQdZww4TK5Wg9+8 fqDbBkh1ZPFONsPrIxZkXpynHFKzKFSsTyC0Ejvv3BjL/kD1bJ2NOj1DIdwwMu5m 9sRIgLBTuttsSJiZBzem62v/VJBqsXQDszZfe0x18Zcb5XG/C09Ftfp5bK3ghqlm tu9n5/0s7kFrNhjsKsKu0I74FaM30jeDCvVUXlMWVHVxuGJFdZmIqsPN7h3BkfeT GKlLDo7FmfghmjS9JzbAM/l/pbd3x3EyD5kLGGh9SMvsJcBWtkhnYVcTU0ptt2Wm Z8LghTFWqNZXHSnkcaqR1Dmb4yZhVE0Yl1C3UvwxD9vhku5bjDc=
=ZVcR
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Aug 23, 2022 at 04:59:10PM -0500, Steven Robbins wrote:

Commonly, I update a package that provides a shared library. Due to the package naming convention, a new SOVERSION necessitates a trip through NEW, which in turn means a binary upload.

The binary upload cannot transition to testing -- a buildd binary build is required. So far as I know -- assuming [1] is still up-to-date, this means a
nuisance upload just bumping the debian revision from -1 to -2. Is this still
the recommended practice?

yes.

it's rather easy to do too, though maybe there should be something in src:devscripts
implementing something along these lines:

dch -i -m "Source only upload for testing migration."
dch -r
debuild -S
cd .. ; dput $changes_file
# git commit & git tag


4 out of these 5 steps I've automated for myself with small scripts written catering how "my" packages are maintained (which is the part where putting
this in src:devscripts is not that easy...).

"debuild -S" I do manually, because sometimes that's all I do and sometimes
I feed the resulting source package into yet another small script called
'spb', because it's running _s_udo _p_builder _b_uilt on the latest source package in $PWD.


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

When this virus is over, I still want some of you all to stay away from me.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmMFbCoACgkQCRq4Vgaa qhxp4w//Tw/WEhhZ6eMsfAylGBHs5E5egwuydUAlvTDEFhTvuuNycGCO359hZ60Z AtU8983kARpDWl9+g6oeMa368KV30Nz3XTwhiP61H+WADsRE7neNZxit0Dtd43t+ yqU41wjKO2MxUecCBOodQ4lNuFv11lU3La0VrRGk6kViLb/F8Hbod+8wojkkKUZ5 tn8GFijsnjq0EzBBq92/54BF3g1RzhAf55aeEaf1X9iLGZS97+AINHlQ0EI8c8rY hzaNA8IlhrfAPT+N0g0CQ+uqCpyFwCwGT/BBRdXF6sF8uM2Y+MS5evxeRLtMWnrg 8oVgA3CXnOhxhXvaKcWwRhrsUUtbOAT66dvwhPkuZi0+2NZbwEvSfQVaSCl7Uhnf 6QJXKIR4erIz3jeM0jqOa7cs1+eyJ1Zkk+Kw2sMkoIXhsVHnrOXNyGxRoMh3aq9b xLXtlgzUxwEtEXlWEeMiOUpTx36YeiPXZOb9U1qd2uXlQysPCO0/E5B9tnuiJ6IR wRuzCtpXDy78Q0ikyPnPu+uU1Jp5EGqc/WhKSpvmWASka1VNUxXK57MNvrS8+MAJ mKs2htVjihhbUmMa5PeFGs8gNV57LTENy1i5I

On Tue, 2022-08-23 at 16:59 -0500, Steven Robbins wrote:

The binary upload cannot transition to testing -- a buildd binary build is required.  So far as I know -- assuming [1] is still up-to-date, this means a
nuisance upload just bumping the debian revision from -1 to -2.  Is this still
the recommended practice?

The release team automatically do binNMUs for packages that need a
rebuild to transition to testing and are able to be binNMUed, so for
many packages you don't need to worry about this. If for some reason
they don't do this or for arch:all packages, you need to reupload.
Usually I use this as an opportunity for some extra package polish.

The patch for dropping NEW binaries has been in dak for two years but
its configuration options were never enabled by ftp-master so far.

Dinstall::ThrowAwayNewBinarySuites
Dinstall::ThrowAwayNewBinaryComponents

I've also been wondering about the "Give Back" action button on the buildd log

The give-back action is only for failed builds, not successful ones.

For successful builds you need a binNMU or new source version.

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmMFazcACgkQMRa6Xp/6 aaN9Eg/9EY+HXJCiSIOMMKFF98BTYyoL0jNdTchusH4TWXTS9rg39z7aBGPzOpQg Wk6MPWhk5CZZMEl81NuadPA8ANMzfYo7due8IJXPc8l9GNb277LGVP6NU4QrEh7K pAtFPvNJZJZ4RlZFnVrSLBEsvWEs6K6xH4fchCzjcz1ufWsSCwsceBmoV0tWTPwL UvbLPGTm8Q4K5bRJWbYYBn7FFrzc0c5vrswAIFSpMNQrbP4eqWMqhXX4prAERKeh z0jqzZZK+s9dLPjSUaRnvukti7WXXmtkepCpmb2o/eBGLP+NY4HrZ5iuawyqJzTV hAYfEr11TN1JtslQUgelPkEnFqMXRtgZjB+BgXCAjMEo+OYC/agXbFKMNseHM+eV hTv2DguJjuZ0k/v/sMdt8FIu8GgtEqsLLwSUIUSL2z5jNolePtlt4LKrLWtjBZPa Wrjgiji7DYAG6HER8Rj2xVcz/NP2ynNKZTN5k4NVoULE4ZfO+746p2c9Q1/1UZXA 2JjG9Ft8HXiPRca9NQxJm1HQ+O78Xps+fHLfd6EGwIYfvch7C5bO5AJqqKn8uov2 dER/hpk8voy7bBmzMPqk3NIY8rRFHRgD8uRem4FCeFfSluMnMI50I8S7tK3dbxSp 9OfjIGaUA6fRdxNWWyKALpMUlxYECAKxHPrCjEhLyWOOV+7J2II=
=YYhS
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

------DOHX0WTKWTKNDLLOWLMY9TOGCP49GR
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 24 August 2022 3:29:10 am IST, Steven Robbins <steve@sumost.ca> wrote:

The binary upload cannot transition to testing -- a buildd binary build is >required. So far as I know -- assuming [1] is still up-to-date, this means a >nuisance upload just bumping the debian revision from -1 to -2. Is this still
the recommended practice?

Yes.

I've also been wondering about the "Give Back" action button on the buildd log
page. It doesn't work in this case because "Package in state Installed, >cannot give back. ✗".

This was probably done to ensure only source-only uploads make it through.

Wondering if the logic can be modified to also check
whether the build was done on a buildd -- e.g. check whether the logs column >contains "no log". If it wasn't a buildd build, can the giveback be allowed?

It was probably intentional. In any case, you might want to CC the wanna-build team ML as well[2]

[1] https://wiki.debian.org/SourceOnlyUpload

[2]: https://lists.debian.org/debian-wb-team/

--
Regards,
Nilesh
------DOHX0WTKWTKNDLLOWLMY9TOGCP49GR
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><body><div style='white-space: pre-wrap'><div class='k9mail-signature'>-- <br>Regards,<br>Nilesh</div></div></body></html>
------DOHX0WTKWTKNDLLOWLMY9TOGCP49GR--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[My earlier mail went blank, not sure what's up with K-9]


On 24 August 2022 3:29:10 am IST, Steven Robbins <steve@sumost.ca> wrote:

The binary upload cannot transition to testing -- a buildd binary build is >required. So far as I know -- assuming [1] is still up-to-date, this means a >nuisance upload just bumping the debian revision from -1 to -2. Is this still
the recommended practice?

Yes.

I've also been wondering about the "Give Back" action button on the buildd log
page. It doesn't work in this case because "Package in state Installed, >cannot give back. ✗".

Yes, because it already succeeded. You can only `give back' for builds that failed.

Wondering if the logic can be modified to also check
whether the build was done on a buildd -- e.g. check whether the logs column >contains "no log". If it wasn't a buildd build, can the giveback be allowed?

It seems intentional, so that source-only uploads are really done. But you might want to ask wanna-build team (I am not a member/admin) here[2]

[1] https://wiki.debian.org/SourceOnlyUpload

[2]:
https://lists.debian.org/debian-wb-team/
--
Best,
Nilesh

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, Aug 24, 2022 at 12:09:20AM +0000 schrieb Holger Levsen:

it's rather easy to do too, though maybe there should be something in src:devscripts
implementing something along these lines:

Sure its easy and may be everybody (including me) has written some local scripts. The fact that it is easy is no good reason to force a lot of developers to work on the symptoms, that binary name changes have to
pass NEW. IMHO Debian would be an easier place if this would not be the
case.

To give some example: bamtools has an RC bug #1015861 which is now
pending for five months due to passing NEW. And yes, I have pinged on
IRC about this - no idea what the proper pinging frequency might be. In
nearly all cases it worked nicely for me by fast processing by ftpmaster
(and I again use this chance to thank the ftpmaster team for this.) On
the other hand I'd love to pull some work from their shoulders and I
keep on thinking that binary name changes force passing NEW is a burden
for them that can be removed. In a previous thread about this Scott
Kitterman gave some explanation[1] which I summarize here (please read
full posting of Scott[1] to get the whole arguments - may be the summary
is to short):

1. Second pair of eyeballs verifying that SONAME bump has not
broken anything.
2. New binary package "steals" binary from another source.
3. Overall sense of the rename.

It's not just let's do extra copyright/license checks.
(which was the only argument I have heard before - AT)

In his mail Scott explicitly said:

Speaking only for myself, not the FTP Team.

I admit I like the technical arguments given by Scott. However, to my perception the issues named above might be uncovered by automated tools
we are just using and would raise according bug reports. In my
(possibly naive) eyes the issue is caused by a "feature" in the
ftpmaster scripts and could be solved by enhancing those scripts -
provided that we as a community decide that the migration via NEW
is not really needed in case of binary name changes. So should we
vote about this (and if yes is there any volunteer to implement this
change.)

Kind regards

Andreas.

[1] https://lists.debian.org/debian-devel/2022/01/msg00231.html

--
http://fam-tille.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------emwtmp0HVEnUDcT0TIcGj4ZU
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGksDQoNCk9uIDI0LTA4LTIwMjIgMDI6MDUsIFBhdWwgV2lzZSB3cm90ZToNCj4gVGhlIHJl bGVhc2UgdGVhbSBhdXRvbWF0aWNhbGx5IGRvIGJpbk5NVXMgZm9yIHBhY2thZ2VzIHRoYXQg bmVlZCBhDQo+IHJlYnVpbGQgdG8gdHJhbnNpdGlvbiB0byB0ZXN0aW5nIGFuZCBhcmUgYWJs ZSB0byBiZSBiaW5OTVVlZA0KDQpNYXliZSBteSBmZWxsb3cgUmVsZWFzZSBUZWFtIG1lbWJl cnMgaGF2ZSBhdXRvbWF0ZWQgdGhpcyBsb2NhbGx5LCBidXQgDQpJJ20gbm90IGF3YXJlIG9m IHNoYXJlZCB0b29scyAob3IgZXZlbiBjcm9uIGpvYnMpIHRoYXQgZG8gdGhpcy4gSWYgd2Ug DQpzcG90IHRoZW0sIHdlICptYXkqIChhbmQgb2Z0ZW4gZG8gKSBiaW5OTVUuDQoNCj4gVGhl IHBhdGNoIGZvciBkcm9wcGluZyBORVcgYmluYXJpZXMgaGFzIGJlZW4gaW4gZGFrIGZvciB0 d28geWVhcnMgYnV0DQo+IGl0cyBjb25maWd1cmF0aW9uIG9wdGlvbnMgd2VyZSBuZXZlciBl bmFibGVkIGJ5IGZ0cC1tYXN0ZXIgc28gZmFyLg0KPiANCj4gRGluc3RhbGw6OlRocm93QXdh eU5ld0JpbmFyeVN1aXRlcw0KPiBEaW5zdGFsbDo6VGhyb3dBd2F5TmV3QmluYXJ5Q29tcG9u ZW50cw0KDQpJIHdvdWxkIGJlIGEgZ3JlYXQgZmFuIG9mIHRoaXMgaGFwcGVuaW5nLg0KDQpQ YXVsDQo=

--------------emwtmp0HVEnUDcT0TIcGj4ZU--

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmMGhN8FAwAAAAAACgkQnFyZ6wW9dQpq SwgAmvFIeRGR1oiKQr4G8QaVSyvqAaU6be3jNOkKhL6060Lhehbf8oX4dkwFfBESgeYZvQjShanS aGNU13I03oLjwkaMJbbgfW2sydr3BKd+rLhHXo5R/0whg1aR4Ft+GJkaO6/SleAzs8sz/5kQ8xGl 17VhVY4PVYz0BKR5FjQeViUw0axJnLFjioxIZuDO2mHWLsqrxwdUSoDm3RZTLygqoudveiqymQWw BQz4MsICt/mg/ONsxsniHGMhS7c+DGyi0sLdQPz9a683Ll3M4FV+4mSbAFKZWcvEmhHXAbBnw2+P 59XakEFVizvf6rlRDDqFzM3Eqv8kjnyWDyvz9BSyTw==
=C6WK
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-08-24 22:06:55 +0200, Paul Gevers wrote:

Hi,

On 24-08-2022 02:05, Paul Wise wrote:

The release team automatically do binNMUs for packages that need a
rebuild to transition to testing and are able to be binNMUed

Maybe my fellow Release Team members have automated this locally, but I'm
not aware of shared tools (or even cron jobs) that do this. If we spot them, we *may* (and often do ) binNMU.

I run

$ drt-tools process-excuses

once a day (except during VAC or when I am not in front of a box with my
Debian keys). That schedules binNMUs for all packages that only require
a rebuild and have no other issues preventing migration.

The code is at https://github.com/sebastinas/drt-tools.

The patch for dropping NEW binaries has been in dak for two years but
its configuration options were never enabled by ftp-master so far.

Dinstall::ThrowAwayNewBinarySuites
Dinstall::ThrowAwayNewBinaryComponents

I would be a great fan of this happening.

Indeed.

Cheers
--
Sebastian Ramacher

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 2022-08-24 at 23:19 +0200, Sebastian Ramacher wrote:

I run

$ drt-tools process-excuses

once a day (except during VAC or when I am not in front of a box with my Debian keys). That schedules binNMUs for all packages that only require
a rebuild and have no other issues preventing migration.

Perhaps those binNMUs should be done from release.d.o, so
that the responsibility for them is the full release team?

The binNMUs will still be needed when all NEW binaries are discarded,
because maintainers will still occasionally accidentally or on purpose
(for eg rebootstraps) do uploads with both source and binaries and the
dak patches only discard NEW binaries, not all maintainer binaries.

Dinstall::ThrowAwayNewBinarySuites
Dinstall::ThrowAwayNewBinaryComponents

I would be a great fan of this happening.

Indeed.

The dak docs/TODO file still has this in it.

* Throw away all DD uploaded .debs. (Depend on "Lintian based automated
rejects")
- Need a way to define a build-architecture for arch_all debs. Some of
them can only be built on certain architectures.
A control file header build-architecture: YXY should do it.
- It's a suite option, not active for all at once.
- Should have all buildd machines under dsa control

Lintian based rejects is done long ago.

I don't think Build-Architecture header is done yet? Although since we
build all arch:all packages on amd64 machines now I don't think this is
needed for throwing away NEW binaries?

AFAICS from `git grep -iW throw.*away`, the code works by to saving all binaries from NEW uploads to the morgue instead of the archive, for combinations of suite and component listed in the config options.

https://salsa.debian.org/ftp-team/dak/

The options aren't set, except in the test suite:

Dinstall {
ThrowAwayNewBinarySuites {
"unstable";
};
ThrowAwayNewBinaryComponents {
"main";
};
};

All buildds for official architectures are run by DSA these days.

The tests for this feature assume "that uploads by buildds use a suffix
(like pkgnew_0.1-1_amd64-buildd.changes), to avoid filename conflicts
with the orignal upload", looks like that is true for Debian now, based
on a quick look through the morgue and the proposed-updates dir:

https://deb.debian.org/debian/dists/bullseye-proposed-updates/

I don't know if the cruft report code will detect these sourceful
uploads without the discarded binaries as cruft and remove them,
but I guess that scenario was tested before the feature was merged.

The only other issue I can think of is in a bootstrap situation,
you want to keep maintainer-built binaries rather than discarding them,
but I guess a maintainer binary-only upload can work around that issue, followed of course by binNMUs and the corresponding buildd uploads.

So probably the feature is ready to be enabled, although maybe after
the bookworm release is the best time to enable it in case there is any unforeseen autocruft/(re)bootstrap/other fallout.

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmMGxckACgkQMRa6Xp/6 aaP38g//agYqJmw2p/MaH1MfwfmCz6t3aT6dRLo2EnOXJjqkMSx8vmum2NCmtbdz Ofm8PHvvFAks6r2Y3mmUvfY6YXk08e3nNZqMibjGFY9KgzMSTzRiS5RwbEaAxmpY EzYOSrA0YhjTJeb03UYLTc0oxNudsdWK4MBkf24W3TWSoPUWTOEYGyhoBSXrmyd8 pxJo4rIIPu+TZLyD9UC/32oBMlftRJLcqDEM9vXG3ImnsX8ilb2TY5RPhCcNKbFO RZwpWKX7Eop2ssCKqpF6k7DhlH4ylBJqnGjolSlISg7TXxrwhJddGPPvZuqlRmrh XAQTGzWnnK5oCyzXVEb3rMAorK9xVjOnuAF6H2bqIHt1kzvSr/LTXl0xTpltDuZT CpbbrxAL238gbV9Hf8ukR4PyCgoPheAMIm+KAGo7/6sEsbVNrIenFO/eExvGfuVa vNh+lxX4ghAHHrrFGCPgflyk3oBXLhBTb0rZkV20AHrIdleQacFllAnIdq+IUqSL GC1hKItL6bUOQwDwIbM0STiEpx7GQSutVBDu/c2TSzVTPyM19LLyK1/uFPDpGeQR 2lZCw41mHbe599i/C1Fh7BlapkQtSoN/Cp2JsmOboV8D1MuNl6RZuKK4ouZ21FKv wVdB43bodPgyZQEl3ri2ZIJ5qLXiV0AqOe6rrWCdh46nQSDa/64=
=F56s
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-08-25 08:43:58 +0800, Paul Wise wrote:

On Wed, 2022-08-24 at 23:19 +0200, Sebastian Ramacher wrote:

I run

$ drt-tools process-excuses

once a day (except during VAC or when I am not in front of a box with my Debian keys). That schedules binNMUs for all packages that only require
a rebuild and have no other issues preventing migration.

Perhaps those binNMUs should be done from release.d.o, so
that the responsibility for them is the full release team?

In theory I agree … but the code requires a rustc version that is not in stable and a bunch of rust crates that are not packaged. Since I don't
have the time to backport rustc and I don't want to burden DSA with
maintining a rustup/cargo setup, that's currently not possible.

Cheers
--
Sebastian Ramacher

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------ksdmwwWMEjENmMD0tkNNcGyZ
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGkgYWxsDQoNCk9uIDI1LTA4LTIwMjIgMDI6NDMsIFBhdWwgV2lzZSB3cm90ZToNCj4gSSBk b24ndCB0aGluayBCdWlsZC1BcmNoaXRlY3R1cmUgaGVhZGVyIGlzIGRvbmUgeWV0Pw0KDQpO ZWl0aGVyIGRvIEkuDQoNCj4gQWx0aG91Z2ggc2luY2Ugd2UNCj4gYnVpbGQgYWxsIGFyY2g6 YWxsIHBhY2thZ2VzIG9uIGFtZDY0IG1hY2hpbmVzIG5vdyBJIGRvbid0IHRoaW5rIHRoaXMg aXMNCj4gbmVlZGVkIGZvciB0aHJvd2luZyBhd2F5IE5FVyBiaW5hcmllcz8NCg0KSW4gdGVz dGluZyBhbmQgb24gcmVsZWFzZSBhcmNoaXRlY3R1cmVzLCBJJ20gb25seSBhd2FyZSBbMV0g b2Ygb25lIHRoYXQgDQpjYW4ndCBidWlsZCBhcmNoOmFsbCthcmNoOmFueSBiaW5hcmllcyBv biBhbWQ2NCAoY211Y2wpLCBidXQgZXZlbiB0aGF0IA0Kb25lIGJ1aWxkcyBpdHMgYXJjaDph bGwgYmluYXJpZXMgb24gYW1kNjQuIEknbSB3b25kZXJpbmcgaWYgdGhlcmUgYXJlIA0KcGFj a2FnZXMgd2hlcmUgdGhpcyBpcyBhIGtub3duIGlzc3VlIChhbmQgd2l0aCB0aGUgbWlzc2lu ZyBoZWFkZXIsIGlzIA0KdGhlcmUgYSB3YXkgdGhlIG91dHNpZGUgd29ybGQgY2FuIHRyYWNr IHRoaXMpPyBJIHJlY2FsbCBzb21lIHBvcnRzIGhhdmUgDQphIG5vdC1mb3ItdXMgbGlzdCwg aXMgdGhhdCBleHBvc2VkIGZvciBhbWQ2ND8NCg0KPiBTbyBwcm9iYWJseSB0aGUgZmVhdHVy ZSBpcyByZWFkeSB0byBiZSBlbmFibGVkLCBhbHRob3VnaCBtYXliZSBhZnRlcg0KPiB0aGUg Ym9va3dvcm0gcmVsZWFzZSBpcyB0aGUgYmVzdCB0aW1lIHRvIGVuYWJsZSBpdCBpbiBjYXNl IHRoZXJlIGlzIGFueQ0KPiB1bmZvcmVzZWVuIGF1dG9jcnVmdC8ocmUpYm9vdHN0cmFwL290 aGVyIGZhbGxvdXQuDQoNCkkgdGhpbmsgdGhlcmUncyBzdGlsbCB0aW1lIHRvIGZpeCBzdHVm ZiBpZiB3ZSBlbmFibGUgaXQgc29vbi4NCg0KUGF1bA0KDQpbMV0gaHR0cHM6Ly9xYS5kZWJp YW4ub3JnL2Rvc2UvZGViY2hlY2svc3JjX3Rlc3RpbmdfbWFpbi9pbmRleC5odG1sIA0KKGRp ZmZlcmVuY2UgYmV0d2VlbiBhbWQ2NCBhbmQgZWFjaCkNCg==

--------------ksdmwwWMEjENmMD0tkNNcGyZ--

-----BEGIN PGP SIGNATURE-----

wsB4BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmMHOzEFAwAAAAAACgkQnFyZ6wW9dQqb 2wf42s9Vspu60MQVg+mwFMGWZp3t/KHtXYnz11RuQMs3g90WwfQlETjbnlDQMQbKu5PgdI9kfSV7 NdZM9favDAqW3bOCFiTWWtvty5nSIcS6D9/B3Fji3rlcd1rDZ5sZXlbKtZTALJpdNeHnwr1K05YN euTDjSlZ1BD+ljvPOLO0k68qD8LeLipUBHg5SgyLDsP4t1DQtbNH0+9O5AuQvEmTCwZtTTVeein6 kGM2IpJkBnzz7U3vBgDHzNBnqq/8oXS6tJjTmAzHrX3ttFoSN7iP/b1jxVkifiEeMmmRAt3Hqa8x 6xRsjmZKanyteAnBWEMxgze4USzIeQl4JAUcISsO
=n98/
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Aug 25, 2022 at 07:13:52PM +0800, Paul Wise wrote:

On Thu, 2022-08-25 at 11:04 +0200, Paul Gevers wrote:

In testing and on release architectures, I'm only aware [1] of one that can't build arch:all+arch:any binaries on amd64 (cmucl), but even that
one builds its arch:all binaries on amd64. I'm wondering if there are packages where this is a known issue (and with the missing header, is
there a way the outside world can track this)?

I guess finding out the list of such packages would require someone to
do a rebuild run of the arch:all packages on arm64 or similar.

https://tests.reproducible-builds.org/debian/ does rebuild of all source packages for arm64, armhf, i386 and amd64.

https://tests.reproducible-builds.org/debian/unstable/arm64/index_blacklisted.html
shows 3 packages we have blacklisted on unstable/arm64.

https://tests.reproducible-builds.org/debian/bookworm/arm64/index_blacklisted.html
shows 1 package blacklisted on bookworm/arm64.

https://tests.reproducible-builds.org/debian/bookworm/arm64/index_FTBFS.html shows 1105 packages failing to build on bookworm/arm64, while
only 829 packages fail to build on bookworm/amd64 as shown on https://tests.reproducible-builds.org/debian/bookworm/amd64/index_FTBFS.html


This data is also available via json as described in https://jenkins.debian.net/userContent/about.html#_reproducible_builds_jobs

There are two JSON files which can be downloaded from https://tests.reproducible-builds.org/reproducible.json and https://tests.reproducible-builds.org/reproducible-tracker.json
The 1st one has all the data (except history) and the 2nd has all
the data we consider relevant to bother maintainers with, that is,
some ftbfs isses are excluded.


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Another end of the world is possible.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmMHZnEACgkQCRq4Vgaa qhyLHw/9Fqw2UPbN1dLgZ4/rO0yphl557JmiwzQ6imjALDQMUHwwp2i/jKfJo2qQ oKRYwgLHqUBN671+yYbVDwrSghuESIHsMz3hTs2JUkuSbhUacEXnrzMNwBaFS8tz P5LyH9bBHiqzMxj5rg9ktnmjAssHyLgLAr25TT+K8mNp4WYMkotYCELUTN03blxA zoyPCmCzrg7HYhkTWOKmTs6fAHSFZSCj19APp91BfO00tgumFu9cqa2O8H/YtNf/ yGx8ErUuqm/DXCCfuDYofSO6Linwp7hy0ptF2shviOO1pwo/+QDkG49r4HhY4vhT rUo2ruDUlU2mQUr1Xc0rvRXnm4SUzn2L9x50VJML74E8YNXVmoUTWz5ZzxVBoEsE H93Ztvh82uZN030bjIHVTtQ5srHE361WnlpF3QZlVuyXrQHPIxGOHAQclwF1oYb8 okvcYQDsHnTv5m6abpJHxLdroRg19rJnHWI0z56NuUd4H53u1RgTVCK/RB6SMwrm gqvc3OW2VmY7LM8ysaXnurrYq+FosL6JFV76QuyR1XjHWP0OU+igpUgsBnCm5A6c MybnEJPoxEz4Nk4Vx810NpI7J3JFr2qGy1II/6Sp8+UmjiqYYrHljk/PQjmJ3m52
PF+dRB53c

On Thu, 2022-08-25 at 11:04 +0200, Paul Gevers wrote:

In testing and on release architectures, I'm only aware [1] of one that can't build arch:all+arch:any binaries on amd64 (cmucl), but even that
one builds its arch:all binaries on amd64. I'm wondering if there are packages where this is a known issue (and with the missing header, is
there a way the outside world can track this)?

I guess finding out the list of such packages would require someone to
do a rebuild run of the arch:all packages on arm64 or similar.

I recall some ports have a not-for-us list, is that exposed for amd64?

The Auto-Not-For-Us state for amd64 is filled with packages that do not
have amd64 in their host architecture list. I think it contains things
for other ports and things that aren't 64-bit yet.

https://buildd.debian.org/status/architecture.php?a=amd64&suite=sid

There is also the Not-For-Us state, I think that is set manually by
porters or buildd admins, but this seems rarely done, one example:

https://buildd.debian.org/status/architecture.php?a=mipsel&suite=sid

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmMHWWwACgkQMRa6Xp/6 aaMuFA/8D3FKoD8hHdO2swrADH9i5nrTVl4F6pvONpBif7KX+gaaw8Y/wEj2c0lq qfg4m8VKmeyDKFKWO4Vu4bQcHAr8ybv5mmUrHH8kZFmhWaR/sSdB6KJ8qb7fe5zm Qh6JfPjXm7EVQG9+l+sYmmebIWp47kX09ZDFvZkG5SIuhu1dRe4jPdvRKQ4tjQFg GmWc0Sq5oQ7MpludW9nDr10D3EmiKqh7eLeLp26NqZHzJXvxGgvysnZ2DyZW3y7k I8XAaDeAPjU6AsUbNxf2hR5U5SCok4oWVXxJp/DYewWnDww8OF6J6hFKGngyA3Gk 2QUkeBVkNhSF8a/H+ocAeF+O5lQLPbxOHt9R7QzKOcbhgwRaXfOuWu6uKCG/8yYm gYNFK9k2419QT1MjCK3WSGBW/nwaBSAallPCYABqkwrT/Yd4j1azGQS0/1C9r4rb GMgpVxelT/3RttwJdc6OzACT8t9fGBfR4b1xjFA0Ach2pkJDwy/Ek82v3q/8Wbva HCNS6cwmZHr0Sp4L0SrldCYDY2WvSOufX+TPBbdj3d4ENBbRwJuaRuz8CzI+ebBq jXQx7zYgrOR8QNLpJDcj5iDKensenFmVrTA0CwhibZ3QlR7mxlOS/w+Usy9aNJII s5y1OrcAjTLUcBk3ZAUKZf5xu9lR6mGZZS5oftetz5beEuTEWTw=
=qmy+
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Aug 24, 2022 at 10:06:55PM +0200, Paul Gevers wrote:

The patch for dropping NEW binaries has been in dak for two years but
its configuration options were never enabled by ftp-master so far. Dinstall::ThrowAwayNewBinarySuites
Dinstall::ThrowAwayNewBinaryComponents

I would be a great fan of this happening.

YES, please.



--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

If you liked Corona, you will also enjoy the upcoming global climate disaster.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmMHZvAACgkQCRq4Vgaa qhxCjA/+JnYyL9Q4xAID6NLTb7D/rsytdxtmecJ7mFh0VBEKprKTKu7EqVzJKTWl cmhkA4S4Btn3rq104n9feHikU2Qm/3mMUrBXJEv7gWIitXzbm7elEnUdvUcH+gcW oYcFYSzN3KeA+5XYlS9CeqTyjke2+XRVNmRxaONXhP9pDM9Bqisl2J5w/K7rU6dI LKfhYRqFG68ZQOmT0n+fZcvkNXcudLFeuHP9iaOKrQAkYRJ2nN/R17eKFb4JM66x WYEuthqLCrnVIr5Gy3MUd2ZjAJ9/7gx7DwFFnsCbAKKWbvbMzwD1a/mgv4+kwV1w 2WTF6vg2WOMvUxF7Xgz3D+ue21B4sC6eAjPKjmw0eNOEIwVamDvgQoqhYNSzHDVg J0tPhKcrRxxMPlaYtVszTM2w4dfVH4z0u5Ed9PJq5bPrvS7VMiwHBd48D20tQUZq sxtmsk1j11Hwt6NLaq0O0ecWnao3zO6eniu7hLPHLeF+7lTozPBTu5qx989yDJwC lvvr3m6cGU+3UdDfyiMc17l5q21u8+W2BTzpN4PiJgX3dAjPYDp0sqO2xZ3KZssM HwgW3L4jWulhCJz8CPJ1bJTmsEJgfU5rf1

Hello,

On Wed 24 Aug 2022 at 12:09AM GMT, Holger Levsen wrote:

On Tue, Aug 23, 2022 at 04:59:10PM -0500, Steven Robbins wrote:

Commonly, I update a package that provides a shared library. Due to the
package naming convention, a new SOVERSION necessitates a trip through NEW, >> which in turn means a binary upload.

The binary upload cannot transition to testing -- a buildd binary build is >> required. So far as I know -- assuming [1] is still up-to-date, this means a
nuisance upload just bumping the debian revision from -1 to -2. Is this still
the recommended practice?

yes.

it's rather easy to do too, though maybe there should be something in src:devscripts
implementing something along these lines:

dch -i -m "Source only upload for testing migration."
dch -r
debuild -S
cd .. ; dput $changes_file
# git commit & git tag

When the Emacs team needed to rebuild all our arch:all packages David
did it with something like

for foo in ...; do
dgit clone foo
dch "Rebuild for ..."
dch -r
git commit debian/changelog -m"..."
dgit push-source
done

The advantage being that it's git workflow-agnostic, so perhaps more
more useful to have that in devscripts.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmMHhD0ZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQAvhD/95cnLok2rbkp4iKspUdWlM za7GuhPequCxCj4LOVPa4V/apZ1+jw6XWNuuS+9idoJh3SlftECrUJbhk8mxsPGy KjDlZrKcgE3cNRu4pk0i99Q6QFB+hkPJda9dtstVJVUX2Ev/4QRt7+FgRna5W2ku 4l5fJx3X8yIBhgct4sG/MQFHrnA5rRT3jnAlcfLz201B6iFzVdPb7dEOnBkR5gvM eeSyoV7Ky0BejII8ZAanOuut2SwduButZabpUZpxI6+msArOTGSYu7kEtHjpTJpW t4bYS40Vv0+EqVsmKYj80WAgtxnbi50AUwplCdliMiseF1An9BEdYtL2XBvXDDkm 9RVD7y0ndx7BeqrJ+KdRB64qz2rVamNh5AqRaSToWFeSYSB6QHjSFWOSCfX9ldyH U6Ilc4XyVWb4i8XiM64Z1bBN0jWVCr96IVJZefYad/GYoJIkNyW6cE3q2GvbuS4Z 1QO2TvzC6/SJHh4vAEI04BOYgCCFnFNCUzwJtsAe0lDEQDWMz/sDPYnCgg/wcebS h0t5AJFuZ1qtb/A6JmEio3Z+PAKys1OvIvXe42tV96wcI1BIaMJzVeF2xzs7mkwc kKztZ3m43HJTlcGV/dFEHUd+2dQgKfvXpvK/OzjB+xjsiLYh4oy4SJ75WtcY1K6p nb3TglCVdGxPKQKZKjasbQ==wD0r
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

Copy: debian-devel@lists.debian.org

On Tuesday, August 23, 2022 6:56:32 P.M. CDT Nilesh Patra wrote:

On 24 August 2022 3:29:10 am IST, Steven Robbins <steve@sumost.ca> wrote: >The binary upload cannot transition to testing -- a buildd binary build is >required. So far as I know -- assuming [1] is still up-to-date, this means >a nuisance upload just bumping the debian revision from -1 to -2. Is this >still the recommended practice?

I've also been wondering about the "Give Back" action button on the buildd >log page. It doesn't work in this case because "Package in state >Installed, cannot give back. ✗".

Wondering if the logic can be modified to also check
whether the build was done on a buildd -- e.g. check whether the logs >column contains "no log". If it wasn't a buildd build, can the giveback
be allowed?

It was probably intentional. In any case, you might want to CC the wanna-build team ML as well

I understand that the current state is that one can only "give back" a failed build. I'm asking whether this must necessarily be the case.

Specficially: in the case of a NEW binary upload, could a manual request be implemented (pick a different name if "give back" is not suitable) such that it
is thrown away and replaced by a buildd build?

Thanks,
-Steve

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEy89k8fa3rclNjyokyeVeL63I9LkFAmML8iwACgkQyeVeL63I 9LkOCg/9Fj2+pBNN0MxotQbzXEHZ5JCZ7OUtoTmT4pVrCQCgUS49mlmLGjf06xP3 h16JKhpZEVFCzZl7rvnQlziamjMEjAtL1TBF4uod3fBi4vdiw/VLAe3Okma/Q/dq 6BrgIkbDaW8JleaNICW44PG0ZPle8bA43D/Bl+oZBoJ/B7o4QfUIpn7TCd8tzX7a ny71K91sCjapEymTxHFzpAITv+5bVSpzD50MCHQIaWoho49TxlL6ZyVXAJx+a7DE rSaJ6zEjww9voPv7y3fbd8nAAT9jo2uwRAc4tvmBAC0796UG5VTyKTnev9kr25uh qLsINnAwR4sXDvlsLMxF2uZAKBdL2dc8Yw7Twx613R4yLwL7GaCAlYACkJ2KCy0j +o7TVG5oJ0nrqNh+u9y+8kYefDJEInAVj/OSZyofrlNZUoZxYS/HOndQVHnIA5EU MPIyRlXcGO3so0ZxXIU99WACK0rbQvYfiB7jkNBqBBOZPCSmKTbjLfKYt7K7Aud3 MBlx4VWsrNbr02kLESKyovhtlSHhrWB/J3Vms20EV5sUPKj99zFDPle+dWXmePvY BIXiSJbm5TbCd0oGE421gEtV0QTXxbf26FuyWwaGZDFe8dgQEv76WIHa4VH3xNCz gd0/VAXoIIy8ZpINOfRCGqr47hJjcrt52OUdZ/IBxymPDyptNs8=
=H4kd
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2022-08-28 at 17:54 -0500, Steven Robbins wrote:

Specficially: in the case of a NEW binary upload, could a manual request be implemented (pick a different name if "give back" is not suitable) such that it
is thrown away and replaced by a buildd build?

The dak software already has an option to enable throwing away all the
binary packages from NEW before they reach the archive, but this option
is not yet enabled on the Debian ftp-master server unfortunately.

If you are suggesting the ability for dak to replace binaries already
in the archive with different content without a new source version,
then I don't think that should be implemented for Debian at least,
since our archive is meant to only contain immutable package files.

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmMMI/UACgkQMRa6Xp/6 aaMJRg//UWH9U6PQyuECZgziPr0NdN1or8nKmLpEm+UkrkZrQyrURIaapRJLcKKV 06ROzKfSpYmHeaqnKgylx+/a0vfqaERX7NQV7m2R0bjEJqD+jRXDdFaTTLLmEdoK xfAEz8UEWhKjNI2HZccdS2jG1FcjEtJxLnDvK83p83fK6w4TATgzVMT9MsH/aSG5 iE7Z+t4XzMYEM2acii3/TA7vzUHUMwp2oWsNRBs4IYujZLV6PT9o23wS5oXcALIE fTHd+fpy7Zhbze+yq3nkOITW1jZdY+a4C08cuSy2a3NuJp6CYFqcnoGCbpdMwEw8 NllUOVhaHj9xrCdURKs3/Kdp1ksH7yQAFlHwhqWqp7FWKzZKrF8Sysis/T33raHX Bg4iPNUhUHYI9mqU0jRA1fG2CjlVuZGOVdHX7jd7NlUKbxE9fzBJuT1+UFiiOPfW xb8vSG+gR5r8CfH11iddl1JBQ0Vsc3skwRxX9hdQcGeUXPVir05pCpHrJ4FJHSZF 68trSnBXbqqEOxq+jWVbc5MzCq2kJpJT7bJ/3ctGw10zjbuAlKQXcUV9ud3E87ce kJSVR9KIZv6NOffO865GZoEmBqBkQISrGmJDHaWjljOzGLd0pwNTh5vcMhCML526 pmEGY0VnZvTna+eEQY2nvGlXUCNNtuzKFOHcXabpvMJEZZ8klVo=
=Nk5V
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Aug 28, 2022 at 05:54:36PM -0500, Steven Robbins wrote:

I understand that the current state is that one can only "give back" a failed
build. I'm asking whether this must necessarily be the case.

Yes, by definition.

Specficially: in the case of a NEW binary upload, could a manual request be implemented (pick a different name if "give back" is not suitable) such that it
is thrown away and replaced by a buildd build?

That's called a binNMU and it was already explained in this thread that it already happens and that it cannot work for packages building arch:all.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmMMXSctFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh fk0P/3snGLZFfpgjtc8Wv47EnZfLuz1yCWwAO+AWskfAj9wt2DXZTdMpnS29FdOU covQMaTqHb/eXu61b1SB4eqTvy4OWj8cAyHJ5fPmkabb4JrEcItREd//mXb3HeTz JP0XTn/zoUk8wo3f1b16rrjkpx3ujVlXKsdGuKKDkf8/lbay3r6RnPOY823QVdZO s8VyaMr1k/0XhkFjSJMq0ngGzsd06xpKqSGswqS8Ha3H5gwtvLZP1UQIMG8sbq+l JpMTd7GkinHhhbLkvnW2D9p9k9gNpLK7MNqFF89lvnIuGtbJbEjoa6W0bAfUT4dS n/+sQthDGH3s4h7EB9zU8/xsbcSlS9AQfmnspRbWTH5JuTj04ZCKWlQiu3GKjDPx cLxyvgmvH85eEn4qnTKrLoeK8GdeDylzPvQcDs/HYvMmrZoQFfP4xEJiP5y178Sj 8HZyCscrR9ooTyL43dEfarFel6AOCGAHmvMc4dTT8Gb+Ku5u4y80DdrIhxrYiF8T v41XsBMtPOQGwZsIMDqCxXrerWOnBF8yR0a+SjiwDyc3+yF3FYhheVBCofvAV8y3 Af93I0sj9twUAnlKvBd/64vyuIuQSipYNo8vEwdhun15PdDy1INHedg1c0bC2By6 tYAd+j/V0tyra75ZjbhhwPw6ya5RyozI4l0GUrX+JOGRfwTE
=sfQu
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Sep 01, 2022 at 08:45:06AM -0500, Steven Robbins wrote:

Specficially: in the case of a NEW binary upload, could a manual request be
implemented (pick a different name if "give back" is not suitable) such that it is thrown away and replaced by a buildd build?

If you are suggesting the ability for dak to replace binaries already
in the archive with different content without a new source version,
then I don't think that should be implemented for Debian at least,
since our archive is meant to only contain immutable package files.

OK, so let's call it "bin nmu", then. And add the "+bN" version suffix.

Have you seen <f914c58ce37a6474c8d8473ef59590e6fe9fdf8b.camel@debian.org>
and <YwaV6RhnDqCfSmrx@ramacher.at>?
(and <YwxdMWGBI9CQ9Lch@belkar.wrar.name>)

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmMQu/QtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh OKoP/3+X32nZHbFDoja1OB/z8UsELtUb2vDP04HkzV2Xb9gKvhLe++H3Dog3PMjb 5s+O0EJJ89VgnkvZOu0XYONe5bYFp+RassmwF1RyzUbVLAE2+r5CerWU8OHRlX7p txtBYSjGtQVWvWAD/NMooG59+6EZdjDcclYWTC9Pju61sJ4VMiRWpOtxqRVaKOeo JXv2Mkxnqx58+/6VCWw2euDUhT/ZXIx6xaFPHUQlHO5cry+QyeX+LRl6eyA9ODWs rMqb2OsuyFJXefaXPI6VKHxpxAFG6QPqdaOW8aucv1mnTtqzFcBUSRuImJzhZeHH VlIyy0F/cBYFKeScfNNUM/lBE7LZzoixbpmsbWNjOdSRBgQezwe5lGG+O4H1JjU1 HevWdvwKYKKs6f01xQCBb+t7iiJqcng/W+i9sweRijysxdVD5a/l7kva8DB+8O3U tkZQ4P3TTQlPNrD+uN1ceziZejMdss2tJ51yQPtAZnYEoPSc3uRhKinprrwb14Qk k+pbNuICW24duJzBPcj837I1j3VeCpKugzlX64qCm+Kv7bQvVPs1yWCZRJQwdY6+ i9edKytssCcYTGpSCNcgrOcp9tVQKwKAs2iBLpUABRPFJWGeO0BJ4+THP09sMobK 3XvtW555OY+VQdEbvYj5qvCAUr94C4miBKeiajTS6xiHA4Nc
=ku4T
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: debian-devel@lists.debian.org

Paul Said:

On Sun, 2022-08-28 at 17:54 -0500, Steven Robbins wrote:

Specficially: in the case of a NEW binary upload, could a manual request
be
implemented (pick a different name if "give back" is not suitable) such that it is thrown away and replaced by a buildd build?

If you are suggesting the ability for dak to replace binaries already
in the archive with different content without a new source version,
then I don't think that should be implemented for Debian at least,
since our archive is meant to only contain immutable package files.

OK, so let's call it "bin nmu", then. And add the "+bN" version suffix.

The dak software already has an option to enable throwing away all the
binary packages from NEW before they reach the archive, but this option
is not yet enabled on the Debian ftp-master server unfortunately.

This would clearly be optimal. I'm just asking about an additional / alternative mechanism.

-Steve
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEy89k8fa3rclNjyokyeVeL63I9LkFAmMQt2IACgkQyeVeL63I 9LlP1hAAoBTkTLIwSD5xxGrDImJno40aRu+If45sla3USTFaqVCAn9J1kdqfoQXc RxlDLSbTToZOIvPRHqGHiQYtMxtSZPEEGWYK/Gwq5UHgzpr92AZrib7anm9guAdz jah3eE7jrNfLA9hTKRvTGQLRxZ9CWDPclTW/L5fJZMbYf1Az1vSl685sx+Qlcti1 Jk9c1qbgtxXp+D4PMTGhFa/j1HAV9nUlc5ZDj0cnruS9iGUp/h3HgXJOfdAgGfTN 6/71RIsyNkMTkLIUM1WURywHXDZ2ZuYeuOtBIqAGZutcjG1jvjj3hChAh9oxtAey OL2P4HR+NwhqP/jy4OjkAH/+t4oNbBzVpW4y8X6dg57zQd+wC8TEY5NSA7vTvrLn lrgs5sVVrr1TJkeum6fyM8kpd4QDY2dSvVBkJKCZJeeM+oCD/yEe9ErU9cBDy28G IZEzxpxjElj/pLA3SmASy3r7KNB+omx0LSC7pIqAFt1cA3XfKUHRiRGqNS7xYjqm RmLyqzkG6Wah7v9rS4aAW0DzeR8EiEVOeQS0GkjPMNeQtIdsZ+zLq0ZOfbIZEjfA oX2EvZECPBoHPx7ywQgCLjks9CdMJMbZWTe8UKxx/bvUANzFdzgzkcau6C/IiJw4 CtJZj713OVFR4KypgKw9wRyAaQPzV2Oy8WOIfS3qseY/YR7owgA=
=cmB1
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 2022-09-01 at 08:45 -0500, Steven Robbins wrote:

OK, so let's call it "bin nmu", then.  And add the "+bN" version
suffix.

As others said, binNMUs exist, but not for arch:all packages. Debian
doesn't yet have sourceful no-change rebuilds, so you have to manually
do a sourceful no-change upload (or a regular upload). Ubuntu does tho.

dch supports the --rebuild option for this, but only on Ubuntu systems.

This would clearly be optimal.  I'm just asking about an additional / alternative mechanism.

Yeah, we need sourceful no-change rebuilds in addition to NEW
discarding. The first step would be updating dch to support this,
after that the infrastructure can be updated, although I guess the
infra could reimplement what `dch --rebuild` does instead. This still
needs a volunteer to implement it, so far we have none to do that.

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmMRJ5kACgkQMRa6Xp/6 aaOTzA//aVzAxWRxRrDMDHK07uM+X63GHau/LKqQ7jd25zX6t8TC2ApOjYuY3Qw4 6NinLOyORFD93hPS6CoAU29gsuS33EdipNDRl5INXCYflu8Z3qqETCYtKehC0iq1 SJ8QEuIPWZ1R6tcssN4v/kJaMCUaOrzgI4koN7vOqgp4YZdhKnq4v0r6Gk0/vLEF f2kwAtqeqNp8jfjVzF7LFp4Ha7v9gAtSJPT3bcm54qhIOzW+zJHlVp9aM/j+rO7X 39QPkWltCmlQ3asxnsOP14vovLDcazKahYYDKzsHLLdGN4v4lEj6MX2esAqGdCIm 1T91qWnmstsBzg+I4W54bQHjCD8Mce61f+l4AT69+Opwt9ePYYNmbLmsKWoN1C9M PVJzkN15pEqe+vQhFAmryCb7IY7ERNT8UEOdBSVcwl43PoS/aUTIMj8hs11hXF3r X2p7mjfWxeke61A3O1m646w4gc+oV9ZwMYa+Sxz8QLonef9697WdHVeEHysbPg8K n0W+Ist/YlPKF2Ln0BwHzW3Cd6lWmZTLpiXq2eQglVjec8BJbLhZ2nStYlY3QJzD 4fAVr/AH5grJBlTyEdDip/Tk/uaZ0ziTzG74wSm413kXmLwJkJIKM2w6JNxLEhuA oIXZlT/C7wEecypC9uYaUOeg/kZLjK4zYXTiFN7+51JZpHGUJWA=
=Ngg3
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)