Re: Need a buildd build after trip through NEW -- best practice?
Am Wed, Aug 24, 2022 at 12:09:20AM + 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
Bug#1018027: ITP: node-degenerator -- Compiles sync functions into async functions
Package: wnpp Severity: wishlist Owner: Michael Ikwuegbu X-Debbugs-CC: debian-devel@lists.debian.org * Package name : node-degenerator Version : 3.0.2 Upstream Author : Nathan Rajlich (http://n8.io/) * URL : https://github.com/TooTallNate/node-degenerator#readme * License : Expat Programming Lang: JavaScript Description : Compiles sync functions into async functions This module takes a String to one or more synchronous JavaScript functions, and returns a new String with those JS functions transpiled into async functions. . Node.js is an event-based server-side JavaScript engine.
Re: Need a buildd build after trip through NEW -- best practice?
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. 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. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Need a buildd build after trip through NEW -- best practice?
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
Re: Need a buildd build after trip through NEW -- best practice?
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
signature.asc
Description: This is a digitally signed message part
