Re: Need a buildd build after trip through NEW -- best practice?
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
Looking for new maintainer(s) for GStreamer packages
Hi! Currently I'm the only maintainer for the GStreamer packages, basically all on this list here: https://qa.debian.org/developer.php?login=gstreamer...@packages.debian.org I'm not planning to maintain them (or any of my other packages) further in the near future but will keep things running somehow for now because of the large number of reverse dependencies. The packages should continue to be team-maintained for the same reason. I can either add one or more people to the existing GStreamer team, or I'm also fine with it being moved to a separate team, e.g. the GNOME or multimedia teams. Thanks! PS: To preempt any questions as for why, the background for my decision to stop maintaining any packages is this thread, but it's really just the straw that broke the camel's back https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022938.html signature.asc Description: This is a digitally signed message part
Re: Need a buildd build after trip through NEW -- best practice?
Hi all On 25-08-2022 02:43, Paul Wise wrote: I don't think Build-Architecture header is done yet? Neither do I. Although since we build all arch:all packages on amd64 machines now I don't think this is needed for throwing away NEW binaries? 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 recall some ports have a not-for-us list, is that exposed for amd64? 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. I think there's still time to fix stuff if we enable it soon. Paul [1] https://qa.debian.org/dose/debcheck/src_testing_main/index.html (difference between amd64 and each) OpenPGP_signature Description: OpenPGP digital signature
Re: Need a buildd build after trip through NEW -- best practice?
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 signature.asc Description: This is a digitally signed message part
Re: Need a buildd build after trip through NEW -- best practice?
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. signature.asc Description: PGP signature
Re: Need a buildd build after trip through NEW -- best practice?
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. signature.asc Description: PGP signature
Re: Need a buildd build after trip through NEW -- best practice?
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 signature.asc Description: PGP signature
Bug#1018100: ITP: liblanguage-detector-java -- Language Detection Library for Java
Package: wnpp Severity: wishlist Owner: Markus Koschany X-Debbugs-Cc: debian-devel@lists.debian.org, a...@debian.org,debian-j...@lists.debian.org * Package name: liblanguage-detector-java Version : 0.6 Upstream Author : Nakatani Shuyo, Francois ROLAND, Fabian Kessler, Nicole Torres, Robert Theis * URL : https://github.com/optimaize/language-detector * License : Apache-2.0 Programming Lang: Java Description : Language Detection Library for Java This software uses language profiles which were created based on common text for each language. N-grams, a contiguous sequence of n items from a given sample of text, were then extracted from that text and stored in the profiles. When trying to figure out in what language a certain text is written, the program goes through the same process: It creates the same kind of n-grams of the input text. Then it compares the relative frequency of them, and finds the language that matches best. Currently 71 languages are supported.
Work-needing packages report for Aug 26, 2022
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1261 (new: 10) Total number of packages offered up for adoption: 177 (new: 2) Total number of packages requested help for: 63 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: emacs-async (#1017879), orphaned 4 days ago Description: simple library for asynchronous processing in Emacs Reverse Depends: elpa-helm elpa-helm-core elpa-magit-todos elpa-pyim Installations reported by Popcon: 2050 Bug Report URL: https://bugs.debian.org/1017879 emacs-noflet (#1017883), orphaned 4 days ago Description: Emacs Lisp noflet macro for dynamic, local advice Installations reported by Popcon: 12 Bug Report URL: https://bugs.debian.org/1017883 emacs-pg-el (#1017880), orphaned 4 days ago Description: Emacs Lisp interface for PostgreSQL Reverse Depends: elpa-emacsql-psql Installations reported by Popcon: 25 Bug Report URL: https://bugs.debian.org/1017880 game-music-emu (#1018069), orphaned today Description: Playback library for video game music files - development files Reverse Depends: gstreamer1.0-plugins-bad libavformat-extra58 libavformat-extra59 libavformat58 libavformat59 libgme-dev mpd qmmp xmms2-plugin-gme Installations reported by Popcon: 104138 Bug Report URL: https://bugs.debian.org/1018069 granite (#1018149), orphaned today Description: extension of GTK3 libraries Reverse Depends: akira bookworm budgie-applications-menu-applet easyssh go-for-it granite-demo libgranite-dev libgranite6 minder sequeler Installations reported by Popcon: 743 Bug Report URL: https://bugs.debian.org/1018149 granite-7 (#1018147), orphaned today Description: extension of GTK4 libraries Reverse Depends: granite-7-demo libgranite-7-7 libgranite-7-dev Installations reported by Popcon: 7 Bug Report URL: https://bugs.debian.org/1018147 pitivi (#1018070), orphaned today Description: non-linear audio/video editor using GStreamer Installations reported by Popcon: 1273 Bug Report URL: https://bugs.debian.org/1018070 pkg-info-el (#1017882), orphaned 4 days ago Description: Emacs Lisp library providing information about Emacs packages Reverse Depends: elpa-cider elpa-flycheck elpa-puppet-mode Installations reported by Popcon: 418 Bug Report URL: https://bugs.debian.org/1017882 stylish-haskell (#1017878), orphaned 4 days ago Description: Haskell code prettifier Installations reported by Popcon: 93 Bug Report URL: https://bugs.debian.org/1017878 unclutter-xfixes (#1017881), orphaned 4 days ago Description: hide the X mouse cursor after a period of inactivity, using XFixes Installations reported by Popcon: 60 Bug Report URL: https://bugs.debian.org/1017881 1251 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: ocrmypdf (#1017872), offered 4 days ago Description: add an OCR text layer to PDF files Installations reported by Popcon: 1050 Bug Report URL: https://bugs.debian.org/1017872 pikepdf (#1017873), offered 4 days ago Reverse Depends: ocrmypdf pdfarranger python3-img2pdf Installations reported by Popcon: 3601 Bug Report URL: https://bugs.debian.org/1017873 175 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#910917), requested 1412 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc bfh-container-server courier-webadmin cvsweb debbugs-web doc-central (131 more omitted) Installations reported by Popcon: 93770 Bug Report URL: https://bugs.debian.org/910917 apparmor (#1006872), requested 171 days ago Description: user-space parser utility for AppArmor Reverse Depends: apparmor-notify apparmor-profiles apparmor-profiles-extra apparmor-utils content-hub-testability dbus-broker dbus-daemon dbus-tests debian-cloud-images-packages dovecot-core (18 more omitted) Installations reported by Popcon: 182250 Bug Report URL: https://bugs.debian.org/1006872 aufs (#963191), requested 796 days ago Description: driver for a union mount for Linux filesystems
Current NEW review process saps developer motivation [Was: Looking for new maintainer(s) for GStreamer packages]
On August 25, 2022 10:52:56 AM GMT+02:00, "Sebastian Dröge" wrote: >PS: To preempt any questions as for why, the background for my decision >to stop maintaining any packages is this thread, but it's really just >the straw that broke the camel's back > > https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022938.html > A bit off-topic, but I think we really ought to discuss (address?) this elephant in the room once more. I don't have the answers, but Sebastian's email yet again clearly illustrates how the status quo is hurting the project. This clear example comes in addition to worries raised before about what the status quo does to recruitment of new developers. PS: I do not imply that the elephant in the room is the ftpmasters. I'm thinking of the *process*. The people involved put in admirable work in carrying out said process. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
