Bug#1016750: [Sbcl-bugs] Heap exhaustion problem with SBCL 2.2.6 on armel, armhf
Hello, On Sat 27 Aug 2022 at 03:15PM -04, Douglas Katzman wrote: > > I suspect that the heap exhaustion is corrected for this release. You have in mind an upcoming 2.2.8 release, right? 2.2.7 is still showing the test failure. > Also I think this particular GC invariant failure is not of the utmost > importance. It seems > directly related to the heap exhaustion which leaves things in an > inconsistent state such > that 'gc_gen_report_to_file' does not work. It's unfortunate that such is the > case, but it is > what it is. I would have far been more worried about a GC failure on > its own. Thank you for this analysis. It would seem that disabling the test is an acceptable workaround. -- Sean Whitton signature.asc Description: PGP signature
Bug#1018140: override: clutter-1.0:oldlibs/optional
Hello, On Fri 26 Aug 2022 at 01:33AM +01, Simon McVittie wrote: > > On Thu, 25 Aug 2022 at 16:26:21 -0700, Sean Whitton wrote: >> On Thu 25 Aug 2022 at 08:50PM +01, Simon McVittie wrote: >> > clutter-1.0 is unmaintained upstream (#996690), but has too many >> > reverse-dependencies to remove immediately. Please move all of its binary >> > packages into oldlibs to make this more obvious. >> >> Done. Just for next time, please list the binary packages in the >> request, as we have to feed the names of each of them to dak. > > Sorry, reportbug asked me for "either source of [sic] binary package" > so I assumed either one was equally useful to the ftp team. Is there a > syntax in which the ftp team would prefer to receive override requests > for easiest review/copy/paste, so I can ask for reportbug to populate > the bug report with that syntax, analogous to how it knows how to compose > ben and wanna-build syntax for release team bugs? That would be great. This is used for most requests: dak override --done=NNN PACKAGE SECTION PRIORITY And there is also dak control-overrides, where you feed it lines: echo "PACKAGE PRIORITY SECTION\nPACKAGE2 PRIORITY2 SECTION2\n" \ | dak control-overrides -C and then manually close the bug. The latter is what I used for your case because I had to build up a list of package names anyway. But the former is probably best for reportbug generation, as more copy-pastable? > (Perhaps the ideal thing would be if I could tell reportbug that I > want to override "src:clutter-1.0 src:cogl", and it would do the > appropriate apt queries to expand that into a list of binary packages > ready for the ftp team's use?) I think sometimes you might want to just change the source package overrides though? -- Sean Whitton signature.asc Description: PGP signature
Bug#1017725: dgit-maint-native(7) examples should use push-source (rather than push)
Hello,
On Wed 24 Aug 2022 at 10:57PM +01, Ian Jackson wrote:
>
> Sean Whitton writes ("Bug#1017725: dgit-maint-native(7) examples should use
> push-source (rather than push)"):
>> On Fri 19 Aug 2022 at 05:12PM +02, Philip Hands wrote:
>> > It strikes me that examples that currently show the `push` sub-command:
>> >
>> > dgit -wgf --overwrite push
>> > and
>> > dgit -wgf push
>> >
>> > should show the use of the `push-source` sub-command instead,
>> > since doing binary uploads to Debian now prevents migration to
>> > testing, so chances are that's not what most people want to do.
>>
>> Yes, that should be updated.
>>
>> > One could perhaps also add a `--with-binary` option for `push` and
>> > gently transition to defaulting to doing source-only uploads unless
>> > one specified that option via config or options.
>>
>> This is an intriguing suggestion, thank you.
>
> Given the differences between the behaviour of (what is now) push and
> of push-source, I'm not really convinced that a mere option is
> sufficient.
>
> But, how about this:
>
> * Provide `push-built` which does what `push` does now.
> * Change `push` to look at a (not distro-dependent) config option.
> - for bookworm, defaults to "do push-built, warn"
> - for bookworm+1, defaults to "do push-source"
>
> People who have scripts that do "dgit push" and need to work on older
> releases can safely pass the config option right away since unknown
> config options are ignored.
Yes, having a 'push-built' like this alongside 'push-source' sounds
better than the current push and push-source combination. LGTM.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#1017892: Ships copies of libraries that are in Debian and autogenerated files that can't be renegerated with the code in Debian main
control: severity 1017906 wishlist Hello, On Mon 22 Aug 2022 at 10:05AM +01, Simon McVittie wrote: > > Control: clone -1 -2 > Control: retitle -1 librsvg: Has vendored copies of Rust libraries that are > in Debian > Control: retitle -2 librsvg: Contains generated files whose source is not > necessarily the same version that's in main > Control: tags -1 + help > Control: tags -2 + help > > On Mon, 22 Aug 2022 at 10:19:01 +0300, Sebastian Dröge wrote: >> The vendor subdirectory in the librsvg source package contains copies of >> various Rust libraries in specific versions. Some of them are packaged in >> Debian (i.e. the version from Debian should be used), others contain >> autogenerated files for which the original source is not in Debian. > > This seems like two separate issues, so I'm cloning it. > > Is there ftp team consensus that either or both of these issues are RC? #1017892 is wishlist or not a bug. Certainly not a DFSG issue. #1017906 *might* be a problem. If there is generated Rust code without the source code used to generate it, or the tool used to transform the sources into the generated Rust code, then there is source code missing. I have not looked into the package to see whether this is actually the case. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017890: Ships autogenerated files that can't be renegerated with the code in Debian main
Hello, On Mon 22 Aug 2022 at 10:00AM +01, Simon McVittie wrote: > Before we go adding a complete copy of GLib to GObject-Introspection, > is there ftp team consensus that the issue described in #1017890 is a > serious bug? The basic idea in these cases is that it must be possible to regenerate anything not in its preferred form for modification using the contents of the archive, such that main is self-contained. But whether something is in its preferred form for modification is case-by-case and a matter of judgement, so there's no whole team consensus to be had, really. > The reason that the inputs used to generate the GIR descriptions > for GLib are shipped by GObject-Introspection rather than GLib is to > resolve a circular dependency. Normally each library generates its own > GObject-Introspection metadata, but GObject-Introspection is a GLib-based > library, so it needs GLib for compilation. > > Rather than directly shipping pregenerated GIR XML, GObject-Introspection > ships files containing the doc-comments from GLib. These are a subset > of GLib's source code, created by removing the actual C code (which is > redundant with the information that can be introspected from the actual > libraries and headers) and leaving only the comments. Sounds like a subset of the preferred form for modification is still the preferred form for modification, so, without having thought about this as carefully as I would were I reviewing the package in NEW, it sounds like this package is okay. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017873: RFA: pikepdf
Hello, On Sun 21 Aug 2022 at 02:55PM -07, Sean Whitton wrote: > > Package: wnpp > Severity: normal > X-Debbugs-Cc: debian-pyt...@lists.debian.org, barlow@gmail.com > Control: affects -1 src:pikepdf > > I request an adoptor for the pikepdf package. It would be better if > someone with more knowledge of either or both Python and PDFs were to > maintain it. I have also filed an RFA for ocrmypdf, the most important > reverse dependency. Looks like it has more rdeps these days than I realised! ocrmypdf is not the most important of them, apologies! -- Sean Whitton signature.asc Description: PGP signature
Bug#1017883: O: emacs-noflet -- Emacs Lisp noflet macro for dynamic, local advice
Package: wnpp Severity: normal X-Debbugs-Cc: debian-emac...@lists.debian.org Control: affects -1 src:emacs-noflet I hereby orphan the emacs-noflet package. I don't use it anymore, and it would be better if someone who did maintains it. This is a team-maintained package, so the adoptor should either replace me in Uploaders:, or alternatively take the package out of the team's hands. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017882: O: pkg-info-el -- Emacs Lisp library providing information about Emacs packages
Package: wnpp Severity: normal X-Debbugs-Cc: debian-emac...@lists.debian.org Control: affects -1 src:pkg-info-el I hereby orphan the pkg-info-el package. This is a team-maintained package, so the adoptor should either replace me in Uploaders:, or alternatively take the package out of the team's hands. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017881: O: unclutter-xfixes -- hide the X mouse cursor after a period of inactivity, using XFixes
Package: wnpp Severity: normal Control: affects -1 src:unclutter-xfixes I hereby orphan the unclutter-xfixes package. I have been using exclusively Wayland for more than a year, so don't use this anymore. The package description is: unclutter-xfixes is a rewrite of the popular tool unclutter, but using the x11-xfixes extension. It has fewer bugs when used with modern applications and window managers. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017880: O: emacs-pg-el -- Emacs Lisp interface for PostgreSQL
Package: wnpp Severity: normal X-Debbugs-Cc: debian-emac...@lists.debian.org Control: affects -1 src:emacs-pg-el I hereby orphan the emacs-pg-el package. This package is no longer in my init.el and it would be better if someone who actually uses the package maintains it. This is a team-maintained package, so the adoptor should either replace me in Uploaders:, or alternatively take the package out of the team's hands. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017879: O: emacs-async -- simple library for asynchronous processing in Emacs
Package: wnpp Severity: normal X-Debbugs-Cc: debian-emac...@lists.debian.org Control: affects -1 src:emacs-async I hereby orphan the emacs-async package. This package has not been in my init.el for around years and it would be better if someone who actually uses the package maintains it. This is a team-maintained package, so the adoptor should either replace me in Uploaders:, or alternatively take the package out of the team's hands. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017878: O: stylish-haskell -- Haskell code prettifier
Package: wnpp Severity: normal X-Debbugs-Cc: debian-hask...@lists.debian.org Control: affects -1 src:stylish-haskell I hereby orphan the stylish-haskell package. The package description is: stylish-haskell prettifies Haskell code. A design goal is not getting in the user's way, so it restricts itself to formatting only some parts of the Haskell code piped to it, such as import statements. -- Sean Whitton signature.asc Description: PGP signature
Bug#1016750: [Sbcl-bugs] Heap exhaustion problem with SBCL 2.2.6 on armel, armhf
Hello, On Tue 09 Aug 2022 at 02:53PM -04, Douglas Katzman wrote: > > https://ci.debian.net/data/autopkgtest/testing/armhf/c/cl-ironclad/24441370/log.gz > shows a GC invariant failure, not a heap exhaustion. > How do I identify the exact git revision of SBCL you're using? I can only > guess at what > line# failed an assertion in my current tree. I've just updated SBCL in Debian to 2.2.7 and dropped two patches included in that release, which simplifies things a bit. ci.debian.net will re-run the cl-ironclad test suite soon. Let me know if it would be useful for me to file a Launchpad bug gathering the various links together. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017873: RFA: pikepdf
Package: wnpp Severity: normal X-Debbugs-Cc: debian-pyt...@lists.debian.org, barlow@gmail.com Control: affects -1 src:pikepdf I request an adoptor for the pikepdf package. It would be better if someone with more knowledge of either or both Python and PDFs were to maintain it. I have also filed an RFA for ocrmypdf, the most important reverse dependency. The package description is: pikepdf is a Python library to read and write PDFs with QPDF. Features include: . * Editing, manipulation and transformation of existing PDFs * Based on the mature, proven QPDF C++ library * Works with encrypted PDFs * Supports all PDF compression filters * Can create "fast web view" (linearized) PDFs * Creates standards compliant PDFs that pass validation in other tools * Automatically repairs damaged PDFs, just like QPDF * Implements more of the PDF specification than existing Python PDF tools * IPython notebook and Jupyter integration -- Sean Whitton signature.asc Description: PGP signature
Bug#1017872: RFA: ocrmypdf -- add an OCR text layer to PDF files
Package: wnpp Severity: normal X-Debbugs-Cc: debian-pyt...@lists.debian.org, barlow@gmail.com Control: affects -1 src:ocrmypdf I request an adopter for the ocrmypdf package. I don't use it as often as I did (hardly ever the past couple of years), and anyway it would be better for a Python programmer to maintain it. The package description is: OCRmyPDF generates a searchable PDF/A file from a regular PDF containing only images, allowing it to be searched. . It uses the Tesseract OCR engine and so supports all the languages that Tesseract does. . Some other main features: . * Places OCR text accurately below the image to ease copy / paste * Keeps the exact resolution of the original embedded images * When possible, inserts OCR information as a lossless operation without rendering vector information * Keeps file size about the same * If requested deskews and/or cleans the image before performing OCR * Validates input and output files * Provides debug mode to enable easy verification of the OCR results * Processes pages in parallel when more than one CPU core is available * Battle-tested on thousands of PDFs, a test suite and continuous integration. -- Sean Whitton signature.asc Description: PGP signature
Bug#1004221: reportbug: automatically add usertags for ftp.debian.org bugs
Hello, On Sat 22 Jan 2022 at 09:21PM -05, Sandro Tosi wrote: > > Hey Paul, > > On Sat, Jan 22, 2022 at 8:45 PM Paul Wise wrote: >> >> Package: reportbug >> Version: 11.2.0 >> Severity: wishlist >> X-Debbugs-CC: ftp.debian@packages.debian.org >> Control: affects -1 ftp.debian@packages.debian.org >> >> When filing bugs against ftp.debian.org there is a menu >> asking what kind of request the bug report is about: >> >> 1 ANAIS Package removal - Architecture Not Allowed In Source. >> 2 ICE Package removal - Internal Compiler Error. >> 3 NBS Package removal - Not Built [by] Source. >> 4 NPOASRPackage removal - Never Part Of A Stable Release. >> 5 NVIU Package removal - Newer Version In Unstable. >> 6 ROM Package removal - Request Of Maintainer. >> 7 ROP Package removal - Request of Porter. >> 8 RoQA Package removal - Requested by the QA team. >> 9 other Not a package removal request, report other problems. >>10 override Change override request. >> >> Currently reportbug doesn't add removal usertags, which means people >> try to do it and then often they get it wrong, many use rm or removal >> instead of remove for example or make typos like remvoe or similar. >> >> Please add these usertags for Package removal requests: >> >>User: ftp.debian@packages.debian.org >>Usertags: remove > > no disrespect, according to https://ftp-master.debian.org/ you are not > part of the FTP master team; we would really like the input from that > team (CC'ed) on how to structure this: after all, these packages are > coded for their consumption, and we should do what makes their work > easier. I don't believe any of our scripts for removals care about usertags, just bug subjects, so it seems fine to trust the existing tags the BTS knows about, as demonstrated by Paul's rsync commands. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017725: dgit-maint-native(7) examples should use push-source (rather than push)
Hello, On Fri 19 Aug 2022 at 05:12PM +02, Philip Hands wrote: > > Package: dgit > Version: 9.16 > Severity: minor > > It strikes me that examples that currently show the `push` sub-command: > > dgit -wgf --overwrite push > and > dgit -wgf push > > should show the use of the `push-source` sub-command instead, since doing > binary > uploads to Debian now prevents migration to testing, so chances are that's not > what most people want to do. Yes, that should be updated. > One could perhaps also add a `--with-binary` option for `push` and > gently transition to defaulting to doing source-only uploads unless > one specified that option via config or options. This is an intriguing suggestion, thank you. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017487: RFP: python-sphinx-design -- Sphinx extension for designing view size-responsive web components
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-pyt...@lists.debian.org * Package name: python-sphinx-design Version : 0.2.0 Upstream Author : Chris Sewell * URL : https://github.com/executablebooks/sphinx-design * License : Expat Programming Lang: Python Description : Sphinx extension for designing view size-responsive web components The latest upstream version of pikepdf, primarily maintained by me, requires this library for its docs build. I'd therefore be very grateful if someone on the Python team would package it. -- Sean Whitton signature.asc Description: PGP signature
Bug#1016928: override: telnet:optional/oldlibs, inetutils-telnet:standard/net, telnetd:optional/oldlibs
Hello, On Wed 10 Aug 2022 at 01:00PM +02, Guillem Jover wrote: > Hi! > > On Tue, 2022-08-09 at 20:42:15 -0700, Sean Whitton wrote: >> On Wed 10 Aug 2022 at 01:53AM +02, Guillem Jover wrote: >> >> > Package: ftp.debian.org >> > Severity: wishlist >> > User: ftp.debian@packages.debian.org >> > Usertags: override >> > User: guil...@debian.org >> > Usertags: inetutils-default-telnet-switch inetutils-default-telnetd-switch > >> > Please update the overrides for these telnet related packages, as part >> > of the netkit to inetutils telnet "default" implementation switch. >> > >> > <https://lists.debian.org/debian-devel/2022/07/msg00139.html> >> >> Done these, though I'm not so sure about the oldlibs for the >> transitional packages if you're planning to remove them the very next >> release cycle -- normally we don't bother changing overrides for that. > > Thanks! And oh, had not heard this before. > > Well the oldlibs is machine-readable way to convey that these are > obsolete packages (given that we lack a proper obsolete section), that > help both humans (f.ex. via grouping in the aptitude section subtree), > or QA programs. So, I've never thought their life expectancy would be > relevant. :) I think it's because override changes are manual and there are a lot of transitional packages each release, so it would be a lot of work for not so much gain. -- Sean Whitton
Bug#1016928: override: telnet:optional/oldlibs, inetutils-telnet:standard/net, telnetd:optional/oldlibs
Hello, On Wed 10 Aug 2022 at 01:53AM +02, Guillem Jover wrote: > Package: ftp.debian.org > Severity: wishlist > User: ftp.debian@packages.debian.org > Usertags: override > User: guil...@debian.org > Usertags: inetutils-default-telnet-switch inetutils-default-telnetd-switch > > Hi! > > Please update the overrides for these telnet related packages, as part > of the netkit to inetutils telnet "default" implementation switch. > > <https://lists.debian.org/debian-devel/2022/07/msg00139.html> Done these, though I'm not so sure about the oldlibs for the transitional packages if you're planning to remove them the very next release cycle -- normally we don't bother changing overrides for that. -- Sean Whitton
Bug#1016750: [Sbcl-bugs] Heap exhaustion problem with SBCL 2.2.6 on armel, armhf
Hello, On Tue 09 Aug 2022 at 02:53PM -04, Douglas Katzman wrote: > https://ci.debian.net/data/autopkgtest/testing/armhf/c/cl-ironclad/24441370/log.gz > shows a GC invariant failure, not a heap exhaustion. Hmm okay, sounds like it's a bug in sbcl rather than cl-ironclad, then. > How do I identify the exact git revision of SBCL you're using? I can only > guess > at what line# failed an assertion in my current tree. We currently use the release tarballs from URIs matching: <https://sf.net/sbcl/sbcl-*-source.tar.bz2> plus these patches: <https://salsa.debian.org/common-lisp-team/sbcl/-/tree/master/debian/patches> a couple of which are backported from git. (If I continue to be the only person working on sbcl packaging in Debian, I'll probably switch to packaging git revisions not tarballs, and patches in git not in a directory like this, which'll mean that you can work with our git repo directly.) Thanks. -- Sean Whitton
Bug#992485: override: mime-support:oldlibs/optional
Hello, On Thu 19 Aug 2021 at 04:52PM +09, Charles Plessy wrote: > Le Thu, Aug 19, 2021 at 01:48:01AM -0500, Daniel Lewart a écrit : >> >> Please change mime-support from: >> net/standard >> to: >> oldlibs/optional > > Thanks Daniel, > > Indeed I intended to ask for it during this release cycle. Actually, > the source package already reflects this. > > > https://salsa.debian.org/debian/mime-support/-/blob/master/debian/control#L4-5 > > I have started to open bugs on some of the packages that still depend on > mime-support directly. Your help is welcome. I don't think we normally bother changing the overrides for transitional packages since they are eligible for removal the very next release cycle. Is there something different for this case? Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#945962: libgl1: still uses Priority: extra
Hello, On Sun 01 Dec 2019 at 08:37PM +01, Thorsten Glaser wrote: > Package: libgl1 > Version: 1.1.0-1+b1 > Severity: normal > > Please change Priority extra to optional, in accordance with latest > Policy, as to not make packages depending on libgl1 but of a conforming > priority violate Policy’s requirement of not depending on packages with > a lower priority. I thought we systematically altered everything extra->optional in dak. Anyway, have run 'dak override' for this now. -- Sean Whitton signature.asc Description: PGP signature
Bug#981323: usbutils not installed by default anymore
control: tag -1 + moreinfo Hello, On Fri 29 Jan 2021 at 11:51AM +01, Laurent Bigonville wrote: > Package: usbutils > Version: 1:013-3 > Severity: normal > > Hello, > > I think we already discussed that on IRC, but usbutils is apparently not > installed by default anymore. > > As a user I would expect to have that package installed (like pciutils), > all physical machines have USB today (and desktop VM's also) > > util-linux is already pulling libudev1. The only extra dependency that > usbutils is adding is libusb-1.0-0. Do you know the history of this -- what happened to mean that it stopped being installed by default when it used to be? -- Sean Whitton signature.asc Description: PGP signature
Bug#944632: override: color-theme-modern:editors/optional
Hello, On Tue 12 Nov 2019 at 08:10PM -05, Nicholas D Steeves wrote: > I was not aware that the Emacsen Team had standardised on Section: > editors, moving away from Section: lisp. This particularly makes > sense for things that affect UI like themes and new modes. Queued, though I note that it was in 'misc' not 'lisp' before. > A section change would be very much appreciated :-) Also, please let > me know if the use of reportbug's "override" submenu for > ftp.debian.org bugs was appropriate when filing this bug. Yup. -- Sean Whitton signature.asc Description: PGP signature
Bug#992476: override: gcc-9-base:libs/optional
Hello, On Tue 09 Aug 2022 at 05:55PM +02, Cyril Brulebois wrote: > Hey, > > Simon McVittie (2022-08-09): >> On Thu, 19 Aug 2021 at 00:06:00 -0500, Daniel Lewart wrote: >> > Please change gcc-9-base from: >> > libs/required >> > to: >> > libs/optional >> >> Reminder that this request for a priority reduction is still outstanding. >> >> gcc 9 has not been the default gcc since 2020, and Debian 11 was released >> with gcc 10 as default; but as of mid 2022, a minimal debootstrap of >> unstable still contains gcc-9-base as a result of its inflated Priority, >> even though nothing in the minimal set depends on it any more. > > Fun you should be reprising that today, I stumbled upon it a few hours > ago while comparing upgraded 10→11 systems vs. fresh 11 systems… > > No objections from the d-i side, sorry if that blocked the issue. :/ That wasn't it, we would have asked. These bugs have a higher status in my MUA than they used to so hopefully this won't happen again. -- Sean Whitton signature.asc Description: PGP signature
Bug#1016750: Heap exhaustion problem with SBCL 2.2.6 on armel, armhf
Hello, When I updated SBCL in Debian from 2.2.3 to 2.2.6, our ci infrastructure detected that the test suite for the cl-ironclad package consistently runs out of memory on armhf and armel. This didn't happen before. https://ci.debian.net/packages/c/cl-ironclad/testing/armhf/ https://ci.debian.net/packages/c/cl-ironclad/testing/armel/ Based on your understanding of the changes between SBCL 2.2.3 and 2.2.6, does it seem likely that this is an SBCL bug, or rather that changes in SBCL have uncovered a bug or limitation in the ironclad test suite, e.g. that it tries to use more memory than a 32-bit address space can accommodate? Also asked about here: <https://github.com/sharplispers/ironclad/issues/53>. Would be grateful for any input. Thanks. -- Sean Whitton
Bug#1016750: sbcl breaks cl-ironclad autopkgtest on armhf: Heap exhausted, game over.
Hello, On Tue 09 Aug 2022 at 07:46AM +02, Paul Gevers wrote: > Hi Sean, > > On 09-08-2022 05:08, Sean Whitton wrote: >> It looks like Lisp just ran out of memory. > > Yes, but it does so systematically. > >> Indeed, I can't see this >> failure on debci.debian.org at present, > > Huh? Did you check https://ci.debian.net/packages/c/cl-ironclad/testing/armhf/ > or https://ci.debian.net/packages/c/cl-ironclad/testing/armel/ You'll see > there that cl-ironclad was retried with sbcl about 11 + 10 times and every > time it failed (and never succeeded). > >> which makes sense if it's a >> random OOM problem on weaker architectures like armhf -- so, not the >> fault of the new sbcl upload. > > This isn't random. And, our armhf box has 255 GB of RAM (and armel VM has 26 > GB), so running out of memory isn't likely. What can happen is that threads > use too much resources for the address space, but that's something under > control of the packages in question if I'm correct (but please correct me if I > misunderstand). I'm not saying it's (easily) fixable, just that it > systematically runs out of reachable memory during the particular test. Right, it's not random. I was looking at the page for unstable. I first looked at <https://ci.debian.net/packages/c/cl-ironclad/> and the failure doesn't show up there -- do you know what that would be? Then I clicked on unstable but not testing, it would seem. I'll write to upstream about this. -- Sean Whitton signature.asc Description: PGP signature
Bug#1016750: sbcl breaks cl-ironclad autopkgtest on armhf: Heap exhausted, game over.
Hello Paul, On Sat 06 Aug 2022 at 04:19PM +02, Paul Gevers wrote: > With a recent upload of sbcl the autopkgtest of cl-ironclad fails in testing > when that autopkgtest is run with the binary packages of sbcl from > unstable. It passes when run with only packages from testing. > > ; wrote > > /tmp/autopkgtest-lxc.d2c27h4h/downtmp/autopkgtest_tmp/usr/share/common-lisp/source/ironclad/src/ciphers/tea-tmp93OFNPHA.fasl > ; compilation finished in 0:00:00.160 > ; compiling file > "/usr/share/common-lisp/source/ironclad/src/ciphers/threefish.lisp" (written > 18 FEB 2022 01:39:10 PM): > Heap exhausted during garbage collection: 16 bytes available, 48 requested. > Immobile Object Counts > Gen GF type fdefn symbol code Boxed ConsRaw Code SmMix Mixed > LgRaw LgCode LgMix Waste% AllocTrig Dirty GCs Mem-age > 1 00 0 0 0 7121939 9668 5273 827 > 0 0 17 19.96186748032499253 18850 1 1.1503 > 2 00 0 0 0 19865 2766 12586 848361681 > 10 34127 11.7 137430448 5368709 23089 0 0.9496 > 3 00 0 0 0 45116 7190 7447604 35521673 > 2394673311.0 270091288 2007806 0 0.4559 > 4 00 0 0 0 0 0 0 0 0 0 > 0 0 00.0 0 200 0 0 0. > 5 00 0 0 0 0 0 0 0 0 0 > 0 0 00.0 0 200 0 0 0. > 6 00 0 0 0 1370471 1242 3507314 40 > 2551342811.930584464 200 251 0 0. > Tot 00 0 0 0 73472 11366 30943 4200 4975 4221 > 5046357566.9 499973680 [93.1% of 536870912 max] > GC control variables: >*GC-INHIBIT* = true >*GC-PENDING* = true > fatal error encountered in SBCL pid 1357: > Heap exhausted, game over. It looks like Lisp just ran out of memory. Indeed, I can't see this failure on debci.debian.org at present, which makes sense if it's a random OOM problem on weaker architectures like armhf -- so, not the fault of the new sbcl upload. Is it possible to label the tests as flaky on only a single architecture? -- Sean Whitton
Bug#1016455: cryptsetup-initramfs: fix for #902943 breaks image building use case
Hello, On Sat 06 Aug 2022 at 12:12AM +02, Guilhem Moulin wrote: > Could you please double check that > > > https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/3854ce68641ba84b04df35828ccb9abcb569e5c6 > and > > https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/e03fcc0d3e3285b4e72208f40a4ac59db3022b48 > > suit your use case? (No need to build the package, you can just patch > the initramfs hook and boot script in /usr/share/initramfs-tools.) Tested building an image, and now it generates a crypttab in the initramfs that I am pretty sure will work -- thank you. -- Sean Whitton signature.asc Description: PGP signature
Bug#1016608: howm: please rename binary package to "elpa-howm"
Package: howm Version: 1.4.7-1 Severity: normal Dear maintainer, Please consider renaming the binary package to "elpa-howm", or at least adding "Provides: elpa-howm". This package is not maintained by the Debian Emacsen team, but we do maintain dh_elpa, and so it would be helpful if you were to follow our naming conventions.[1] The source package name of "howm" is correct, but the binary package should be "elpa-howm". Thanks. [1] https://wiki.debian.org/Teams/DebianEmacsenTeam#Addons_packaging_policy -- Sean Whitton signature.asc Description: PGP signature
Bug#1016609: howm: please package new upstream version 1.4.8
Package: howm Version: 1.4.7-1 Severity: wishlist Dear maintainer, There is a new upstream release, 1.4.8, which includes a compatibility fix for Emacs 28. That's the version of Emacs expected in the upcoming bookworm release, so this bug may become RC once it's uploaded to Debian. It would be great if howm could be updated before then. Thanks! -- Sean Whitton signature.asc Description: PGP signature
Bug#1016455: cryptsetup-initramfs: fix for #902943 breaks image building use case
Package: cryptsetup-initramfs Version: 2:2.3.7-1+deb11u1 Dear maintainer, I'm building disk images with an ext4 rootfs on LVM on LUKS. I put a PARTUUID in the /etc/crypttab of the image's rootfs, like this: erebus_crypt PARTUUID=13b9dfdf-04a2-4c97-a241-fe6cdfe76f68 none luks,discard,initramfs I then run 'update-initramfs -u' while chrooted into the image's rootfs, and the cryptsetup-initramfs scripts put this line in cryptroot/crypttab in the initramfs: erebus_crypt /dev/mapper/loop0p2 none luks,discard,initramfs So, the PARTUUID= source is being mapped to a /dev/mapper source, which I think is the work of the fix for #902943. It's the same for UUID=. The problem is that /dev/mapper/loop0p2 is valid only on the image-building host, and not on the host that will actually try to boot the image. Indeed, that's the whole reason I am using a PARTUUID, so that it will stay valid. So it looks like the fix for #902943 has broken this sort of use case. It would be great to have some way to cause the PARTUUID to be passed through unchanged. Thanks. -- Sean Whitton
Bug#1015779: dgit: dgit --dpm push-source failure
Package: dgit Version: 9.13 X-debbugs-cc: r...@defaultvalue.org $ scp coccia.debian.org:~rlb/emacs_28.1+1-unofficial.orig.tar.xz . $ mv emacs_28.1+1-unofficial.orig.tar.xz emacs_28.1+1.orig.tar.xz $ git clone salsa.debian.org:rlb/deb-emacs -b tmp-deb-28.1 $ cd deb-emacs $ # HEAD at commit 22246c8c7ae8eb6ec49ac4bd6129dada8a2de08e $ dgit --dry-run --dpm --deliberately-not-fast-forward push-source DRY RUN ONLY Format `3.0 (quilt)', need to check/update patch stack canonical suite name for unstable is sid dgit: split brain (separate dgit view) may be needed (--quilt=dpm). examining quilt state (multiple patches, dpm mode) dgit: base trees orig=8485c6b1c516c1d73d70 o+d/p=bd9223dc722a33bb66f8 dgit: quilt differences: src: ## orig ## gitignores: == orig == dgit: quilt differences: HEAD == o+d/p HEAD == o+d/p dgit view: created (commit id 22246c8c7ae8eb6ec49ac4bd6129dada8a2de08e) # git pull --ff-only -q /home/spwhitton/tmp/deb-emacs/.git/dgit/unpack/work master # dpkg-source '-i(?:^|/)'\\'.git(?:/|$)' -I.git -b -- work changelog will contain changes since 1:27.1+1-3.1 # sh -ec 'exec >../$1; shift; exec "$@"' x 'emacs_28.1+1-1_source.changes' dpkg-genchanges -S '-v1:27.1+1-3.1' dgit: error: open emacs_28.1+1-1.dsc (source package): No such file or directory ! Push failed, before we got started. ! You can retry the push, after fixing the problem, if you like. Adding -DD, the end of output: CD work + env PATH=/etc/perl:/usr/local/lib/x86_64-linux-gnu/perl/5.32.1:/usr/local/share/perl/5.32.1:/usr/lib/x86_64-linux-gnu/perl5/5.32:/usr/share/perl5:/usr/lib/x86_64-linux-gnu/perl-base:/usr/lib/x86_64-linux-gnu/perl/5.32:/usr/share/perl/5.32:/usr/local/lib/site_perl:/usr/share/dgit:/home/spwhitton/local/bin:/home/spwhitton/src/dotfiles/bin:/usr/sbin:/sbin:/opt/emacs-snapshot/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games git playtree-setup . + git reset -q --hard 22246c8c7ae8eb6ec49ac4bd6129dada8a2de08e CD .. # dpkg-source '-i(?:^|/)'\\'.git(?:/|$)' -I.git -b -- work CD work query: fetching https://api.ftp-master.debian.org/dsc_in_suite/unstable/emacs... changelog will contain changes since 1:27.1+1-3.1 # sh -ec 'exec >../$1; shift; exec "$@"' x 'emacs_28.1+1-1_source.changes' dpkg-genchanges -S '-v1:27.1+1-3.1' CD .. moving emacs_28.1+1-1.dsc, emacs_28.1+1-1_source.changes, etc. to /home/spwhitton/tmp/deb-emacs/.. dgit: error: open emacs_28.1+1-1.dsc (source package): No such file or directory ! Push failed, before we got started. ! You can retry the push, after fixing the problem, if you like. The dpkg-source command creates emacs_28.1+1-1.dsc when I run it myself from .git/dgit/unpack, so it's not obvious why it's not there when dgit tries to move it. But I have not yet dug very deep. -- Sean Whitton
Bug#1015729: ITP: org-make-toc -- automatic tables of contents for Org files
Package: wnpp Severity: wishlist Owner: Sean Whitton X-Debbugs-Cc: debian-de...@lists.debian.org, debian-emac...@lists.debian.org * Package name: org-make-toc Version : 0.5 Upstream Author : Adam Porter * URL : https://github.com/alphapapa/org-make-toc * License : GPL-3 Programming Lang: Emacs Lisp Description : automatic tables of contents for Org files I am packaging this as a dependency of ement-el, another ITP of mine. -- Sean Whitton
Bug#1015727: ITP: taxy-magit-section-el -- View Taxy structs in a Magit Section buffer
Package: wnpp Severity: wishlist Owner: Sean Whitton X-Debbugs-Cc: debian-de...@lists.debian.org, debian-emac...@lists.debian.org * Package name: taxy-magit-section-el Version : 0.9.1 Upstream Author : Adam Porter * URL : https://github.com/alphapapa/taxy.el branch package/taxy-magit-section * License : GPL-3+ Programming Lang: Emacs Lisp Description : View Taxy structs in a Magit Section buffer I am packaging this as a dependency of ement-el, another ITP of mine. -- Sean Whitton
Bug#1015726: ITP: emacs-svg-lib -- SVG tags, progress bars & icons for Emacs
Package: wnpp Severity: wishlist Owner: Sean Whitton X-Debbugs-Cc: debian-de...@lists.debian.org, debian-emac...@lists.debian.org * Package name: emacs-svg-lib Version : 0.2.5 Upstream Author : Nicolas P. Rougier * URL : https://github.com/rougier/svg-lib * License : GPL-3+ Programming Lang: Emacs Lisp Description : SVG tags, progress bars & icons for Emacs I am packaging this as a dependency of ement-el, another ITP of mine. -- Sean Whitton
Bug#1015725: ITP: taxy-el -- Programmable taxonomical grouping for arbitrary objects for Emacs
Package: wnpp Severity: wishlist Owner: Sean Whitton X-Debbugs-Cc: debian-de...@lists.debian.org, debian-emac...@lists.debian.org * Package name: taxy-el Version : 0.9 Upstream Author : Adam Porter * URL : https://github.com/alphapapa/taxy.el * License : GPL-3+ Programming Lang: Emacs Lisp Description : Programmable taxonomical grouping for arbitrary objects for Emacs I am packaging this as a dependency of ement-el, another ITP of mine. -- Sean Whitton
Bug#1015724: ITP: plz-el -- HTTP library for Emacs
Package: wnpp Severity: wishlist Owner: Sean Whitton X-Debbugs-Cc: debian-de...@lists.debian.org, debian-emac...@lists.debian.org * Package name: plz-el Version : 0.2 Upstream Author : Adam Porter * URL : https://github.com/alphapapa/plz.el * License : GPL-3+ Programming Lang: Emacs Lisp Description : HTTP library for Emacs I am packaging this as a dependency of ement-el, another ITP of mine. -- Sean Whitton
Bug#1015723: ITP: ement-el -- Matrix client for Emacs
Package: wnpp Severity: wishlist Owner: Sean Whitton X-Debbugs-Cc: debian-de...@lists.debian.org, debian-emac...@lists.debian.org * Package name: ement-el Version : 0~git... Upstream Author : Adam Porter * URL : https://github.com/alphapapa/ement.el * License : GPL-3+ Programming Lang: Emacs Lisp Description : Matrix client for Emacs I'll upload this to experimental for now, until upstream makes a stable release. But we can help them do some testing. -- Sean Whitton
Bug#1015232: RM: elisp-slime-nav -- ROM; obsolete
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-emac...@lists.debian.org So far as I can tell, elisp-slime-nav has been entirely obsoleted by recent versions of xref.el, which is built into Emacs, and which we also package the latest upstream version of separately in Debian. Seems better not to have elisp-slime-nav in bookworm. Thanks. -- Sean Whitton
Bug#1012354: Please add support for systemd-binfmt
Hello, On Sat 18 Jun 2022 at 10:37AM +02, Michael Biebl wrote: > Am 14.06.22 um 21:59 schrieb Michael Biebl: >> Am 14.06.22 um 21:50 schrieb Sean Whitton: >>> Hello, >>> >>> On Tue 14 Jun 2022 at 09:39PM +02, Michael Biebl wrote: >>> >>>> Hi Sean >>>> >>>> Am 13.06.22 um 03:14 schrieb Sean Whitton: >>>>> Thanks for the patch. I take it you got the sbcl.conf from the >>>>> binfmt-conf package? So systemd-binfmt means that these config files >>>>> get stored in packages rather than all stored in binfmt-conf? >>>> >>>> I'm confused. What's the "binfmt-conf" package? >>> >>> Sorry, I meant binfmt-support. >> >> Ok, then that's a no. >> >> I looked at that kind of binfmt configuration the sbcl package ships >> (i.e. debian/binfmt) and created sbcl.conf from that information. > > Maybe that was a bit misleading. > What I meant to say is that the information in sbcl.conf is not coming > from the binfmt-support package but from the binfmt config file shipped > in sbcl as debian/binfmt. > And in the same way, sbcl.conf should be shipped in the sbcl package. Cool, thank you. -- Sean Whitton signature.asc Description: PGP signature
Bug#737634: Bug#1007717: Native source package format with non-native version
With three first preference votes for A and five first preference votes for C, the outcome is no longer in doubt. Therefore, using its powers under constitution 6.1.5, the Technical Committee issues the following advice: 1. It is not a bug of any severity for a package with a non-native version number to use a native source package format. 2. Thus, we think that dpkg shouldn't issue warnings, or otherwise complain, when a non-native version number is used w/ 3.0 (native). 3. We suggest that the wontfix tag on #737634 be reconsidered. 4. We believe that there are indeed circumstances in which 1.0-with-diff is the best choice for a particular source package, including, but not limited to, git-first packaging workflows. However, we recommend discontinuing use of 1.0-with-diff in other circumstances, to simplify the contents of the archive. This is because there is currently no other source format which is such that avoid both (i) uploading the whole source, including upstream, for every upload; and (ii) having to maintain debian/patches/ inside the package tree. 5. We decline to comment on the recent source package format MBF. -- Sean Whitton
Bug#1007717: Ballot and call for votes
Hello, On Mon 20 Jun 2022 at 05:31PM -07, Sean Whitton wrote: > BEGIN BALLOT > > Using its powers under constitution 6.1.5, the Technical Committee > issues the following advice: > > 1. It is not a bug of any severity for a package with a non-native > version number to use a native source package format. > > 2. Thus, we think that dpkg shouldn't issue warnings, or otherwise > complain, when a non-native version number is used w/ 3.0 (native). > > 3. We suggest that the wontfix tag on #737634 be reconsidered. > > 4a. We believe that there are indeed circumstances in which > 1.0-with-diff is the best choice for a particular source package, > including, but not limited to, git-first packaging workflows. > > This is because there is currently no other source format which is > such that avoid both (i) uploading the whole source, including > upstream, for every upload; and (ii) having to maintain > debian/patches/ inside the package tree. > > 4c. We believe that there are indeed circumstances in which > 1.0-with-diff is the best choice for a particular source package, > including, but not limited to, git-first packaging workflows. > However, we recommend discontinuing use of 1.0-with-diff in other > circumstances, to simplify the contents of the archive. > > This is because ... [second paragraph as in 4a]. > > 5. We decline to comment on the recent source package format MBF. > > Option A -- issue items 1-3, 4a and 5 > > Option C -- issue items 1-3, 4c and 5 > > Option X -- issue only items 1, 2, 3 and 5 > > Option N -- none of the above. > > END BALLOT I vote A > C > X > N -- Sean Whitton signature.asc Description: PGP signature
Bug#1007717: Ballot and call for votes
Hello, I hereby call for votes on the following resolution: BEGIN BALLOT Using its powers under constitution 6.1.5, the Technical Committee issues the following advice: 1. It is not a bug of any severity for a package with a non-native version number to use a native source package format. 2. Thus, we think that dpkg shouldn't issue warnings, or otherwise complain, when a non-native version number is used w/ 3.0 (native). 3. We suggest that the wontfix tag on #737634 be reconsidered. 4a. We believe that there are indeed circumstances in which 1.0-with-diff is the best choice for a particular source package, including, but not limited to, git-first packaging workflows. This is because there is currently no other source format which is such that avoid both (i) uploading the whole source, including upstream, for every upload; and (ii) having to maintain debian/patches/ inside the package tree. 4c. We believe that there are indeed circumstances in which 1.0-with-diff is the best choice for a particular source package, including, but not limited to, git-first packaging workflows. However, we recommend discontinuing use of 1.0-with-diff in other circumstances, to simplify the contents of the archive. This is because ... [second paragraph as in 4a]. 5. We decline to comment on the recent source package format MBF. Option A -- issue items 1-3, 4a and 5 Option C -- issue items 1-3, 4c and 5 Option X -- issue only items 1, 2, 3 and 5 Option N -- none of the above. END BALLOT -- Sean Whitton signature.asc Description: PGP signature
Bug#1007717: Updated draft resolution
Hello, On Fri 17 Jun 2022 at 02:45am +02, gregor herrmann wrote: > Well, yes, sure. > That would all be nice. > But issuing some advice about 1.0-with-or-without-dpatch or whatever > doesn't really change anything for them. Indeed, we have somewhat drifted off-topic :) > Oh, right, I totally agree that for all practical reasons the > practical source of most of the packages I upload are in a salsa > git repo. > > But that's completely irrelevant. > What's relevant for Debian are some *.orig.tar.gz *.debian.tar.xz > *.dsc an some web mirrors. I don't understand -- why would it be irrelevant? -- Sean Whitton
Bug#1007717: Updated draft resolution
Hello, On Fri 17 Jun 2022 at 01:03AM +02, gregor herrmann wrote: > And that's what we are talking about: Debian experts building > packages for Debian. At least that's what my priorities are. I think Ian might really mean "Debian source package experts". It ought to be our goal to make it so that you can be a Debian expert without being a Debian source package expert. It also seems worth mentioning that users wanting to apply patches to packages installed on their systems are also one of priorities. > And dgit also is just a nice workaround for the problem that the > canonical source of Debian packages is not Git repo; it pretends that > there is, and it stumbles across all kinds of corner cases caused by > how source packages look like nowadays. I would challenge this idea: at this point, the canonical source of very many Debian packages is indeed their git repos on salsa. Not all of them, but very many. -- Sean Whitton signature.asc Description: PGP signature
Bug#1007717: Updated draft resolution
Hello, On Thu 16 Jun 2022 at 08:47am +02, Helmut Grohne wrote: > > Indeed, and I do agree that 4c is such a clear statement. I would like > to see a stronger statement here, but Sam et al. tried to gain consensus > on that and there wasn't. So the CTTE advice probably shouldn't override > that non-consensus. That makes 4c a lot more of an attractive option to > me. Finally, the main conflicting parties in this issue (oversimplified) > were Lucas and Ian, so if 4c is strong enough for Lucas, that's good as > well. > > I hereby withdraw my intention to extend the ballot as sent by Sean on > June 7th. > > Thanks for bearing with me and bringing those arguments forward. Cool, thanks for reviewing and confirming that. -- Sean Whitton
Bug#1007717: Updated draft resolution
Hello, On Wed 15 Jun 2022 at 04:06PM +02, Lucas Nussbaum wrote: > > According to https://udd.debian.org/~lucas/format10.cgi (which is based > on what lintian knows about the archive), there are 114 packages using > 1.0 with quilt. However, 67 of those are maintained by the Debian X > team. If you plan to discontinue 1.0+patch-system in the context of > this bug, it would probably be a good idea to have a discussion with > them to better understand their use case. Thanks for this info. > I personally think that it would be enough for this bug to issue a clear > statement that we want to move away from 1.0 unless there's a good > reason, on a per-package basis, not to. That would create a mandate to > work on surveying the remaining packages and identifying the remaining > use cases. That would also allow motivated volunteers to work on > migrating the remaining packages when there's no reason to stay with > 1.0, using the NMU procedure if needed. I agree that this would be a good outcome, as expressed by your option 4c. -- Sean Whitton signature.asc Description: PGP signature
Bug#1012354: Please add support for systemd-binfmt
Hello, On Tue 14 Jun 2022 at 09:39PM +02, Michael Biebl wrote: > Hi Sean > > Am 13.06.22 um 03:14 schrieb Sean Whitton: >> Thanks for the patch. I take it you got the sbcl.conf from the >> binfmt-conf package? So systemd-binfmt means that these config files >> get stored in packages rather than all stored in binfmt-conf? > > I'm confused. What's the "binfmt-conf" package? Sorry, I meant binfmt-support. -- Sean Whitton signature.asc Description: PGP signature
Bug#1012354: Please add support for systemd-binfmt
Hello Michael, On Sun 05 Jun 2022 at 04:09PM +02, Michael Biebl wrote: > Package: sbcl > Version: 2:2.2.3-1 > Severity: wishlist > Tags: patch > User: pkg-systemd-maintain...@lists.alioth.debian.org > Usertags: systemd-binfmt > > Hi, > > your package sbcl declares a dependency (Recommends) on binfmt-support > and ships binfmt-support configuration files in /usr/share/binfmt/. > > systemd provides a builtin, cross-distro facility named systemd-binfmt to > register binary formats. > > You can read more about it at > https://www.freedesktop.org/software/systemd/man/systemd-binfmt.html > https://www.freedesktop.org/software/systemd/man/binfmt.d.html > https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html > > The systemd package provides a dpkg file trigger so it is sufficient to > simply install configuration files in /usr/lib/binfmt.d/, no > modifications in the maintainer scripts are necessary. > > The attached patch adds support for systemd-binfmt and adjusts the > dependency on binfmt-support accordingly, so binfmt-support is no longer > installed automatically if systemd is already installed. Thanks for the patch. I take it you got the sbcl.conf from the binfmt-conf package? So systemd-binfmt means that these config files get stored in packages rather than all stored in binfmt-conf? -- Sean Whitton signature.asc Description: PGP signature
Bug#1007717: Draft resolution for "Native source package format with non-native version"
he development of such a source format. To be honest I don't think it's really necessary as everyone agrees it would be better to have it, but if you think it should be said explicitly then let's do that. -- Sean Whitton
Bug#1007717: Draft resolution for "Native source package format with non-native version"
Hello, On Wed 08 Jun 2022 at 12:06pm +02, Julian Andres Klode wrote: > On Tue, Jun 07, 2022 at 08:19:29PM +0200, Helmut Grohne wrote: >> Please keep in mind that this is about trade-offs. It is a question of >> how we value "package ownership". If we favour the strong ownership >> approach that Debian used for a long time, then yes accommodating the >> needs of maintainers is paramount. If we want to lessen the concept of >> ownership, embrace drive-by contributions and decentralize maintenance, >> then we need a stronger focus on uniformity. I suppose that my own >> opinion on this matter is fairly obvious at this point. > > This is also a significant issue for downstreams. With my Ubuntu hat > on, if I have to touch packages downstream, I loathe it everytime I > get a non-descript blob of all the changes. This is not inherent to all of the workflows we are discussing here, just one of them. Indeed, this is one of the primary motivations for one of the others. -- Sean Whitton
Bug#1007717: Updated draft resolution
Hello, On Tue 10 May 2022 at 05:29pm -07, Sean Whitton wrote: > At today's ctte meeting we considered whether we can start a vote on > this, but two committee members were missing, and someone else at the > meeting reported that they hadn't yet been able to spend enough time > thinking through the issue to be ready to vote. > > We came up with the following plan. Below I've drafted a ballot. Once > each of those three individuals has let me know that they've had a > chance to catch up, I'll start a vote. The hope is that this can happen > well in advance of our next meeting. So, ctte members, if I don't > already know that you're caught up, please write to me once you are. Unfortunately, people haven't yet indicated they're caught up. Here's an updated ballot in light of our upcoming meeting. I've left space to add a 4b, if, when our current discussion is concluded, someone would like that in addition to 4c. ~ DRAFT Using its powers under constitution 6.1.5, the Technical Committee issues the following advice: 1. It is not a bug of any severity for a package with a non-native version number to use a native source package format. 2. Thus, we think that dpkg shouldn't issue warnings, or otherwise complain, when a non-native version number is used w/ 3.0 (native). 3. We suggest that the wontfix tag on #737634 be reconsidered. 4a. We believe that there are indeed circumstances in which 1.0-with-diff is the best choice for a particular source package, including, but not limited to, git-first packaging workflows. This is because there is currently no other source format which is such that avoid both (i) uploading the whole source, including upstream, for every upload; and (ii) having to maintain debian/patches/ inside the package tree. 4c. We believe that there are indeed circumstances in which 1.0-with-diff is the best choice for a particular source package, including, but not limited to, git-first packaging workflows. However, we recommend discontinuing use of 1.0-with-diff in other circumstances, to simplify the contents of the archive. This is because ... [second paragraph as in 4a]. 5. We decline to comment on the recent source package format MBF. Option A -- issue items 1-3, 4a and 5 Option C -- issue items 1-3, 4c and 5 Option X -- issue only items 1, 2, 3 and 5 Option N -- none of the above. END DRAFT -- Sean Whitton
Bug#1007717: Draft resolution for "Native source package format with non-native version"
Hello, On Tue 07 Jun 2022 at 09:31am +02, Lucas Nussbaum wrote: > A middle ground between (4) and (4b) could be to discourage the use of > 1.0-with-diff in circumstances where it is not justified. Something > like: > > 4c. We believe that there are indeed circumstances in which > 1.0-with-diff is the best choice for a particular source package, > including, but not limited to, git-first packaging workflows. > However, we recommend discontinuing use of 1.0-with-diff in other > circumstances to gain more uniformity. > > That opens the path to an archive where the only remaining 1.0 packages > are the ones where there's a reason to use 1.0. (as opposed to > currently, where we have a mix of packages using 1.0 for a good reason, > and packages using 1.0 because nobody cared to update them to modern > practices). This would be a good ballot option to include, thank you. -- Sean Whitton
Bug#1007717: Draft resolution for "Native source package format with non-native version"
Hello, On Tue 07 Jun 2022 at 11:26am +01, Ian Jackson wrote: > In this case I would like to suggest that progress would be better > served by trying to unblock a better source format that (i) has some > kind of delta representation (ii) does not put a > needing-to-be-maintained copy of the delta metadata inside the working > tree. > > There are several proposals for how to do that which are obviously > possible to implement. If the TC wants to unblock that, you could > look at them and pick one. > > (And, I quextion whether .dsc format is the right place for Debian to > pursue uniformity. .dsc is a legacy format we are maintaining because > our git transition is stalled.) I think that this would be out-of-scope for this bug as presented to us: we'd need someone to present those options for us to choose between. Let's stick with the current resolution text for a bug that's probably been open too long already. -- Sean Whitton
Bug#1007717: Draft resolution for "Native source package format with non-native version"
Hello, On Tue 07 Jun 2022 at 08:19pm +02, Helmut Grohne wrote: > Please keep in mind that this is about trade-offs. It is a question of > how we value "package ownership". If we favour the strong ownership > approach that Debian used for a long time, then yes accommodating the > needs of maintainers is paramount. If we want to lessen the concept of > ownership, embrace drive-by contributions and decentralize maintenance, > then we need a stronger focus on uniformity. I suppose that my own > opinion on this matter is fairly obvious at this point. I disagree with you that this is primarily about package ownership, and I think that we agree on more than you realise we do :) The git-first people are not making a trade-off between the maintainer's convenience and the convenience of others who want to work with the package. The most important reason for wanting both (i) git-first workflows and (ii) uploads done with dgit, is to make it easier for people other than the maintainer to work with the package. So, your priorities are quite in agreement with those of Ian, Sam, Russ and I. In other words, I would like to make weaker package ownership more possible, in a project with Debian's history, by improving our tools for dealing with packages for which you're not primary maintainer. What we disagree about is the extent to which the current tooling amounts to a failed experiment, such that we should give up on it and fall back to 'apt-get source'. Many people strongly prefer 'dgit clone' to 'apt-get source' already, and the number of people switching to upload with 'dgit [--gbp] push-source' is steadily rising. Against this backdrop, some of us are interested in git-first workflows for reducing the distance between the output of 'debcheckout' and 'dgit clone'. It's completely reasonable that you're more sceptical about the prospects of solving the outstanding issues in this programme than others are, but surely we can agree that this is an ongoing piece of work rather than something we're sure we can reject? And if keeping an old source package format around is needed for that work to continue, then that's a compelling reason to keep it around. > How would you go about reducing them to a sane number? The goal is to attack this problem on two fronts: 1. reduce the need for uniformity by making it possible for people to get their cross-archive work done using 'dgit clone' 2. develop git-first workflows that solve all the existing usecases. > You can rephrase it as reducing complexity if that helps. It's not the > one additional source package format that is too much. It's that we > continue using all the failed experiments while adding new ones and when > some Lucas comes around and tries to clean up the mess he gets referred > to us. As I said, I don't think it's fair to characterise the git-first work as a failed experiment. It's ongoing work. And the source package format is just a way to keep it going, at the present moment. > I have anecdotal evidence that people find Debian's processes too > complex. Unless you closely work withing a particular packaging team > (with unified processes), onboarding people into Debian takes very long > compared to other projects. Right, hence why we want 'dgit clone' to be as useful as possible. -- Sean Whitton
Bug#1007717: Draft resolution for "Native source package format with non-native version"
Hello, On Tue 07 Jun 2022 at 07:43am +02, Helmut Grohne wrote: > While I can agree with this item on a technical level, I think there is > more to it than that and I am wondering whether it sends the "right" > message. > > Sometimes, things we do are technically possible and fill a niche well. > Yet, we decide that it is no longer reasonable to continue supporting > them and remove their support despite the feature being useful to some. > Quite clearly, there is a trade-off involved here. Continuing to support > 1.0-with-diff comes with a cost that reduces uniformity inside the > archive. Evidently, this is what motivated Lucas to file the MBF > initially. My experience is that lack of uniformity is a significant > barrier to prospective contributors to Debian. I think this argument needs to be made more precise -- we should be clearer about why this particular un-uniformity is bad. I don't think the issue for new contributors is persuasive enough, as new contributors can mostly ignore source packages. It's not like, e.g., debhelper vs. cdbs. I haven't yet seen an argument that the lack of uniformity is doing anyone's work any harm comparable to the harm done to things like what Ian and Sam want to do. > Exploring different technical approaches does have value as well, but I > think we've had sufficient time to consider the various advantages and > disadvantages of various source packages formats. On a whole, it seems > to me that that the number of packages benefiting from 1.0-with-diff is > relatively small. I agree, it's not about the benefits of the source format, we do indeed understand all the trade-offs by now. It's that certain ideas and workflows *which are not really about source packages* are made inconvenient or impossible if we remove this option. In other words, it needs to be replaced before it can be deprecated. > What would you think about adding an alternative option 4? > > 4b. We believe that there are indeed circumstances in which > 1.0-with-diff is the best choice for a particular source package. > Given that the number of packages for which this is relevant is > fairly small, we recommend discontinuing use of 1.0-with-diff to > gain more uniformity. Thanks for coming up with the text. I'd say that as uniformity is not good in itself, it would be good to have more concrete reasons for wanting uniformity in this case documented in this bug (not necessarily in the resolution text) before we add it to the ballot. -- Sean Whitton
Bug#1009617: mailscripts: new script to reinject a message via sendmail: sendmail-reinject
Hello Jameson, On Mon 16 May 2022 at 12:33PM -07, Jameson Graef Rollins wrote: > Here's a new version of the patch addressing Sean's comments. I need it signed off; please see CONTRIBUTING.rst. -- Sean Whitton signature.asc Description: PGP signature
Bug#1009617: mailscripts: new script to reinject a message via sendmail: sendmail-reinject
Hello, On Mon 16 May 2022 at 09:13am -07, Jameson Graef Rollins wrote: > On Wed, May 11 2022, Sean Whitton wrote: >> Hello Jameson, >> >> On Tue 12 Apr 2022 at 03:17PM -07, Jameson Graef Rollins wrote: >> >>> Package: mailscripts >>> Version: 0.24-1 >>> Severity: wishlist >>> Tags: patch >>> >>> Attached is a patch (via git format-patch) for a script to re-inject >>> an existing message via sendmail. The script extracts the sender and >>> all recipients from the message and constructs the appropriate >>> sendmail command to re-send the message. This is very useful for >>> messages that were fcc'd but for some reason failed to make it out on >>> an initial pass (e.g. MTA misconfiguration). A man page is also >>> included. >> >> Cool, I'd like to add this. Just two questions >> >> - what license are you releasing it under? please add the usual >> copyright and license headers and update d/copyright >> >> - how about renaming --id to --notmuch-id or --notmuch-message-id ? > > Thanks Sean. --notmuch-id seems ok to me. Do you want to go ahead and > make the change, or should I resend the patch? Well, you also need to add the license header, so please resend. -- Sean Whitton
Bug#1009617: mailscripts: new script to reinject a message via sendmail: sendmail-reinject
Hello Jameson, On Tue 12 Apr 2022 at 03:17PM -07, Jameson Graef Rollins wrote: > Package: mailscripts > Version: 0.24-1 > Severity: wishlist > Tags: patch > > Attached is a patch (via git format-patch) for a script to re-inject > an existing message via sendmail. The script extracts the sender and > all recipients from the message and constructs the appropriate > sendmail command to re-send the message. This is very useful for > messages that were fcc'd but for some reason failed to make it out on > an initial pass (e.g. MTA misconfiguration). A man page is also > included. Cool, I'd like to add this. Just two questions - what license are you releasing it under? please add the usual copyright and license headers and update d/copyright - how about renaming --id to --notmuch-id or --notmuch-message-id ? -- Sean Whitton signature.asc Description: PGP signature
Bug#1007717: attempt to summarize current state of this bug
Hello, On Wed 11 May 2022 at 10:56AM +02, Lucas Nussbaum wrote: > I think that: > [...] > - git-using workflows are a best practice (based on their usage by the > vast majority of packages) > > But I challenge that there is a consensus that git-first workflows are a > best practice. I think that they are a practice that is worth exploring > and experimenting on, but not yet widely adopted nor understood. But I > would be happy to be proven wrong (especially of based on facts). I would say that we don't have a consensus on either. -- Sean Whitton signature.asc Description: PGP signature
Bug#1007717: Draft resolution for "Native source package format with non-native version"
Hello, At today's ctte meeting we considered whether we can start a vote on this, but two committee members were missing, and someone else at the meeting reported that they hadn't yet been able to spend enough time thinking through the issue to be ready to vote. We came up with the following plan. Below I've drafted a ballot. Once each of those three individuals has let me know that they've had a chance to catch up, I'll start a vote. The hope is that this can happen well in advance of our next meeting. So, ctte members, if I don't already know that you're caught up, please write to me once you are. ~ DRAFT Using its powers under constitution 6.1.5, the Technical Committee issues the following advice: 1. It is not a bug of any severity for a package with a non-native version number to use a native source package format. 2. Thus, we think that dpkg shouldn't issue warnings, or otherwise complain, when a non-native version number is used w/ 3.0 (native). 3. We suggest that the wontfix tag on #737634 be reconsidered. 4. We believe that there are indeed circumstances in which 1.0-with-diff is the best choice for a particular source package, including, but not limited to, git-first packaging workflows. 5. We decline to comment on the recent source package format MBF. Option A -- issue items 1--5 Option B -- issue items 1, 2, 3 and 5, but not 4 Option N -- none of the above. END DRAFT -- Sean Whitton signature.asc Description: PGP signature
Bug#1010397: Fwd: Bug#1010397: git-annex sync fails in rsync remotes with rsync 3.2.4-1
Hello, On Tue 03 May 2022 at 12:13PM -04, Joey Hess wrote: > Fixed with attached patch. Cool, thanks. Seems like there might be a release soon so I'll hold off patching Debian's version? -- Sean Whitton signature.asc Description: PGP signature
Bug#1010397: Fwd: Bug#1010397: git-annex sync fails in rsync remotes with rsync 3.2.4-1
Hello, On Mon 02 May 2022 at 12:51PM -04, Joey Hess wrote: > Joey Hess wrote: >> The rsync command that git-annex runs has a trailing close quote, as >> seen in the first excerpt above. But rsync then complains about the path >> with that close quote removed. >> >> I'm having a hard time not seeing this as a bug in rsync. > > # NEWS for rsync 3.2.4 (15 Apr 2022) > > ## Changes in this version: > > ### BEHAVIOR CHANGES: > > - A new form of arg protection was added that works similarly to the older >[`--protect-args`](rsync.1#opt) (`-s`) option but in a way that avoids >breaking things like rrsync (the restricted rsync script): rsync now uses >backslash escaping for sending "shell-active" characters to the remote >shell. This includes spaces, so fetching a remote file via a simple quoted >filename value now works by default without any extra quoting > > This change must be the cause of the problem. > > git-annex can be configured to not do its own shell escaping when accessing > a rsync special remote. If your remote is named "foo", you can configure it > that way as follows: > > git-annex enableremote foo shellescape=no Thanks for looking into it. Do you see this as a workaround or what people using newer rsync should use going forward? -- Sean Whitton
Bug#1009433: tried but got stuck with dgit and git-debrebase
Hello, On Sat 23 Apr 2022 at 09:10PM +03, Thomas Koch wrote: > I think I believe how to fix the FTBFS: > > --- a/debian/patches/0005-configure-mkdocs-for-Debian.patch > +++ b/debian/patches/0005-configure-mkdocs-for-Debian.patch > @@ -23,7 +23,8 @@ index 1302441..05ada85 100644 > +site_dir: html > copyright: "Copyright (C) 2011-2020 Bozhidar Batsov and Projectile > contributors" > docs_dir: doc > - pages: > +-pages: > ++nav: > - Home: index.md > -- Installation: installation.md > - Usage: usage.md > > But I'm stuck since I need to finally learn dgit and apparently > git-debrebase. I'll start with the manpages. dgit-maint-debrebase(7) should be in a "How do I ..." format; let me know if there are parts that are unclear. -- Sean Whitton signature.asc Description: PGP signature
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hello, On Wed 20 Apr 2022 at 03:31PM +01, Matthew Vernon wrote: > ===Rationale > > There are two "rename" programs - the perl rename, and the util-linux > rename. Debian and its derivatives have shipped the perl rename as > /usr/bin/rename, whilst other distributions (e.g. Fedora) have shipped > the util-linux rename thus. The two implementations are incompatible. > Users might reasonably desire both implementations to be available on > the same system; they are designed to meet different needs. > > Backwards-compatibility (and the lack of a compelling argument that > rename from util-linux should replace perl rename) means that > /usr/bin/rename in Debian should remain the perl rename. > > Prior to bullseye, util-linux's rename was shipped as > /usr/bin/rename.ul; Debian's users who wish to use util-linux's rename > will expect it to be in this location. > > ===End Rationale > > ===Begin Resolution A > The Technical Committee overrides the util-linux maintainer, and > requires that util-linux's rename should be shipped as > /usr/bin/rename.ul in a binary package built from src:util-linux. The > package containing rename.ul must not conflict with the rename package > nor divert /usr/bin/rename. > ===End Resolution A > > ===Begin Resolution B > The Technical Committee overrides the util-linux maintainer, and > requires that util-linux's rename should be shipped in a binary package > built from src:util-linux. If this package Conflicts with the rename > package, then it must not contain any other binaries. > ===End Resolution B > > ===Begin Resolution N > None of the above > ===End Resolution N I vote A > B > N -- Sean Whitton signature.asc Description: PGP signature
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hello, On Fri 15 Apr 2022 at 01:14PM -07, Russ Allbery wrote: > Sean Whitton writes: > >> In this case I believe you need to formally withdraw options A and >> then propose another ballot. > > Minor procedural point: the person proposing the options can also freely > modify them, so you didn't technically have to withdraw them and could > instead just alter the options to whatever new text you want. 6.3.2: > > Any member of the Technical Committee may propose additional ballot > options or modify or withdraw a ballot option they proposed. > > (The underlying assumption is that the TC are sophisticated voters who can > closely track the status of the ballot, so we can err on the side of > convenience to let proposers rewrite the options to whatever they want. > If that makes previously acceptable options unacceptable, other TC members > can always propose new options or reinstate versions of the previous > options.) I failed to read "or modify", thank you. -- Sean Whitton signature.asc Description: PGP signature
Bug#1009680: ghostscript breaks ocrmypdf autopkgtest: seemingly multiple issues
control: reassign -1 ghostscript control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=705187 control: retitle -1 Ghostscript 9.56 removes hidden (e.g. OCR) text layers when refrying with NEWPDF=true Hello, On Thu 14 Apr 2022 at 11:13AM +02, Paul Gevers wrote: > With a recent upload of ghostscript the autopkgtest of ocrmypdf fails in > testing when that autopkgtest is run with the binary packages of > ghostscript from unstable. It passes when run with only packages from > testing. In tabular form: > > passfail > ghostscriptfrom testing9.56.0~dfsg-1 > ocrmypdf from testing13.4.0+dfsg-1 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration of ghostscript to > testing [1]. Due to the nature of this issue, I filed this bug report > against both packages. Can you please investigate the situation and > reassign the bug to the right package? > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation It's a regression in Ghostscript. OCRmyPDF has made a release including a workaround but the test suite for that fails, so I can't upload it yet. But in any case this bug is not one in OCRmyPDF. -- Sean Whitton signature.asc Description: PGP signature
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hello Matthew, On Thu 14 Apr 2022 at 04:47PM +01, Matthew Vernon wrote: > ===Begin Resolution > > The Technical Committee resolves that util-linux's rename should be > shipped in a binary package build from src:util-linux. If this package > Conflicts with the rename package, then it should not contain any other > binaries. > > The Technical Committee overrides the util-linux maintainer, and > requires that this binary should be shipped as /usr/bin/rename.ul > > ===End Resolution > > A: Approve resolution, including override of util-linux maintainer > B: Approve only first paragraph of resolution > N: None of the above I think that both of these involve overriding the maintainer, as the restriction to not include any other binaries if the package Conflicts: with bin:rename is also to override the maintainer? > Matthew > ps; my first TC resolution, please be gentle if I have the procedure wrong! Thank you for coming up with this text. Actually, the new procedure is new to all of us; this is our first use of it. In this case I believe you need to formally withdraw options A and then propose another ballot. -- Sean Whitton signature.asc Description: PGP signature
Bug#1008489: dpkg: postinst should not warn about Debian's default (and soon only supported) filesystem layout
Hello, On Sat 09 Apr 2022 at 03:47pm +02, Ansgar wrote: > On Sun, 2022-03-27 at 14:34 +0200, Ansgar wrote: >> I think the warning emitted by dpkg's postinst script about Debian's >> default filesystem layout is not appropriate and at least partially >> misleading. Several other people agreed with this sentiment. > > To clarify due to misunderstanding that seem to have happened: > > - Merged-/usr is planned to become the only supported layout for Debian > in the future, cf. [1]. > > - Most Debian derivates will probably follow, some have already done so > before Debian itself. So showing this warning in Debian derivates by > default seems not a good solution; if a derivative wants this warning, > they can patch it back in. Okay I see. To answer your question, then, the ctte has not even discussed the relevance of warnings to derivatives. I can't speak for everyone, but I suspect that we would not consider this NMU to be in line with our existing decisions. -- Sean Whitton
Bug#1008489: proposed diff for dpkg 1.21.7+nmu1
Hello, On Sat 09 Apr 2022 at 11:50am +02, Ansgar wrote: > Hi, > > I've prepared a patch for the current issue. See the attached proposed > NMU diff. I've limited it to minimal changes. I don't understand. The warning is already no longer emitted on Debian? -- Sean Whitton
Bug#994388: dpkg currently warning about merged-usr systems
Hello, On Sat 09 Apr 2022 at 02:52pm +02, Wouter Verhelst wrote: > On a side note, the dpkg maintainer replied to my message, dropping the > -ctte Cc, wherein he claims that the warning has been removed: Yes, it has been removed for some days now -- sorry, thought that was more widely known. > https://lists.debian.org/debian-dpkg/2022/04/msg7.html Thanks for the link. -- Sean Whitton
Bug#994388: dpkg currently warning about merged-usr systems
Hello Wouter, On Fri 08 Apr 2022 at 09:36AM +02, Wouter Verhelst wrote: > Given that, in case the dpkg maintainer chooses to remain silent > again, I believe the only way forward is for the TC to recommend a GR > under §4.2.1 of the consitution. Perhaps there is some appropriate GR that at some point it will be appropriate for the ctte to propose, but not one with the same text as one of our merged-/usr decisions already issued -- that doesn't make much constitutional sense, I think. -- Sean Whitton
Bug#1007717: Native source package format with non-native version
Hello, On Tue 29 Mar 2022 at 09:06PM +02, Lucas Nussbaum wrote: > On 28/03/22 at 16:21 -0700, Sean Whitton wrote: >> >> I don't think it's the preferred method. I believe most of the project >> sees git histories are the preferred tool for achieving the goal you >> state. >> >> If we had only source packages for this purpose, then yes, 3.0 (quilt) >> plus DEP-3 would be preferred. But we have git, too, and indeed dgit. >> Repositories for packages contain both upstream history and Debian >> packaging history, and we have powerful git subcommands for extracting >> information. In many cases there is a good argument to be made that the >> git history is part of the preferred form of modification. > > I think there are three different use cases to consider: I agree that we should consider them separately. > A. preferred form for regular contributions to the package (typically > by the package maintainer) > > B. preferred form for occasional contributions to the package (typically > by an NMUer, or by the security team) > > C. preferred form for reviewing the packaging and Debian-specific > changes. > > > I fully agree that the git repository is the preferred form for A. > However, for B and C, I think that our lingua franca is the source > package, and thus a source package that doesn't make it hard to > understand things such as Debian-specific patches. Of course that > could change if we were able to standardize on a git workflow (or > a small set of git workflows), but I don't see this happenning anytime > soon. What you get from 'dgit clone' is designed to serve (B) and (C) well, and somewhat sidesteps precisely the problems created by our having multiple git workflows. Please consider trying out dgit-user(7) and/or dgit-nmu-simple(7) next time you need to engage in (B) or (C). It's really very nice :) -- Sean Whitton signature.asc Description: PGP signature
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hello Chris, On Mon 28 Mar 2022 at 10:35PM +02, Christoph Berg wrote: > The problem here is that if ul-extra contains things besides rename, > and it conflicts with the perl rename, people will rightfully complain > that they can't install /usr/bin/fincore-from-ul-extra and > /usr/bin/rename-from-perl at the same time. Indeed, and doesn't it violate Policy 10.1, which says "Two different packages must not install programs with different functionality but with the same filenames" ? Perhaps it's an edge case. -- Sean Whitton signature.asc Description: PGP signature
Bug#1008480: debian-policy: The mime-support package was split into media-types and mailcap
control: tag -1 + pending Hello, On Sun 27 Mar 2022 at 12:47PM +09, Charles Plessy wrote: > Package: debian-policy > Version: 4.6.0.1 > Severity: normal > X-Debbugs-Cc: ple...@debian.org > > Hi Russ and Sean, > > it is a long time I have not posted here! > > In the previous release cycle, I have split the mime-support into the > media-types and the mailcap packages. > > The patch below updates the Policy to reflect that. This is technically a normative change but since the change has already been made in the archive, I've just gone ahead and applied it to 'next'. Thanks! -- Sean Whitton signature.asc Description: PGP signature
Bug#1007717: Native source package format with non-native version
Hello Lucas, Many thanks for providing this summary of your position. Let me just note a point of disagreement: On Tue 15 Mar 2022 at 10:06PM +01, Lucas Nussbaum wrote: > A point that I find important is the following: as a project, I think > that we care about facilitating the review of changes we make to > upstream source. Certainly we do. > I think that the preferred method (and widely accepted method) for > that is currently to use the 3.0 (quilt) format with DEP-3-documented > patches, on top of a tarball that contains the pristine upstream > source. > > The git packaging workflows that generate source packages using either > 1.0 native packages, or 1.0 non-native packages without patches, make it > harder to identify and review those changes, as they require browsing > the git repository, which sometimes is not properly documented using > Vcs-*. I don't think it's the preferred method. I believe most of the project sees git histories are the preferred tool for achieving the goal you state. If we had only source packages for this purpose, then yes, 3.0 (quilt) plus DEP-3 would be preferred. But we have git, too, and indeed dgit. Repositories for packages contain both upstream history and Debian packaging history, and we have powerful git subcommands for extracting information. In many cases there is a good argument to be made that the git history is part of the preferred form of modification. -- Sean Whitton signature.asc Description: PGP signature
Bug#994388: dpkg currently warning about merged-usr systems
Hello, On Thu 24 Mar 2022 at 04:50PM -07, Russ Allbery wrote: > Josh Triplett writes: > >> I think it's appropriate for people to wait on such work until there's >> guidance from the TC ensuring that such a patch will be accepted. >> Otherwise, anyone spending time writing it is spending substantial >> effort that may well be wasted. > > I think this is a totally fair thing to be concerned about. Should such a > patch exist -- with the obvious condition that I think it's quite > reasonable to do several rounds of iteration on making that patch solid, > ensuring there are tests, and so forth -- I think it's obvious that we > should merge it given the previous TC decision. Of course, I'm not a TC > member. > > It's difficult, procedurally, for the TC to do anything about a > theoretical patch that someone could write but hasn't written. > Particularly for dpkg, the details are important. I can think of some > ways of supporting merged-/usr that I wouldn't support even while > supporting the TC decision. We have various goals (such as being able to > bootstrap entirely through package installation) that can be met while > supporting merged-/usr but which do require design and care. > > If a concrete patch exists, the TC can (and has in the past) authorize an > NMU to apply it. Obviously, we should try to avoid reaching that level of > social and process confrontation if we can avoid it, but this is clearly > within the TC's constitutional power via a maintainer override, which puts > the discussion on somewhat firmer ground. But design of that patch is > *not* within the TC's constitutional mandate. > > It may be useful to look at how multiarch support in dpkg was handled. > That was quite painful and I really hope we don't end up following that > path exactly, but it provides a concrete example of how Debian's processes > can reach a resolution. > > I personally am still hopeful that we could do much better than the > multiarch outcome and find a patch that meets the architectural criteria > of the dpkg maintainer, but I'm fairly certain that we're not going to > make any progress towards that goal without having working code, or at > least a very detailed architecture, to start discussing and analyzing. This is how I see it as well. Putting aside the postinst warning, the I can't see anything the TC could do beyond what we've already done, until there's a patch on the table. Thanks for the summary. -- Sean Whitton signature.asc Description: PGP signature
Bug#994388: dpkg currently warning about merged-usr systems
Hello Helmut, On Thu 24 Mar 2022 at 02:49pm +01, Helmut Grohne wrote: > Hi, > > On Thu, Mar 24, 2022 at 09:12:14AM +0100, Ansgar wrote: >> Maybe it should be changed into a warning that non-merged-/usr systems >> will not be supported in the future. The `dpkg-fsys-usrunmess` program >> should probably also include a warning that it will convert the system >> into a state no longer supported by Debian in the future. > > What is supported is a bit subjective I fear. At this point, neither > merged-/usr nor unmerged-/usr is supported well. Both are broken in one > way or another and nobody steps up to fix the mess. We should distinguish two senses of "supported". There is the sense of what Debian-the-project supports. That is specified in the TC decision. That is not subjective. There is the sense of what Debian-the-archive-contents supports. That is indeed subjective just as you explain. There exists disagreement about whether the Ubuntu approach to implementing merged-/usr is adequate. The difficulty is that Guillem's warning kind of refers to both. -- Sean Whitton
Bug#1006830: elpa-mailscripts: notmuch-slurp-debbugs misses messages
Hello,
On Wed 16 Mar 2022 at 04:36PM -07, Sean Whitton wrote:
> Hmm... I don't see how it could have worked before. Does this fix it:
>
>> diff --git a/notmuch-slurp-debbug b/notmuch-slurp-debbug
>> index ad0db47..1568d9c 100755
>> --- a/notmuch-slurp-debbug
>> +++ b/notmuch-slurp-debbug
>> @@ -50,7 +50,7 @@ if (-f $conf_f) {
>> $maildir = catfile $database_path, "inbox";
>> }
>> $maildir = $mgr->open(
>> -folder=> $maildir,
>> +folder=> glob $maildir,
>> access=> "a",
>> keep_dups => 1,
>> type => "maildir"
This patch won't work. I just pushed a commit which does.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#1007840: [notmuch-slurp-debbug] notmuch-slurp-debbug should use "notmuch insert"
Hello, On Thu 17 Mar 2022 at 06:18PM -04, Daniel Kahn Gillmor wrote: > Hi Sean, thanks for the prompt response. > > On Thu 2022-03-17 11:34:32 -0700, Sean Whitton wrote: >> On Thu 17 Mar 2022 at 01:51PM -04, Daniel Kahn Gillmor wrote: >>> For backward compatibility, if a "maildir" configuration variable is >>> present, it could fall back to the old form of insertion, but emit a >>> warning that it is doing so. >> >> How about using 'notmuch insert --folder=' if the old config >> key is present, and not issuing a warning? > > The trouble with that is that --insert is defined "relative to the > top-level directory given by the value of database.mail_root.", whereas > the maildir is a full filesystem path. > > Seems better to me to do a deprecation cycle. It's noisier short term, > but cleaner longterm. > > The other open question here is that "notmuch insert" on its own > defaults to delivering at the top level, whereas notmuch-slurp-debbug > wants to use the "inbox" folder just below the top level. > > I'm personally fine with the default delivery location changing, but if > you think we ought to default to something like --folder=inbox > --create-folder i'd be willing to do that too. I was thinking that some users might want to ensure the new mail goes into a particular subdirectory, as they can do at present (I know Vagrant does this, for example). You can do that with your new insert_args, but why not support both ways? We just File::Spec::abs2rel the old configuration key and use it. Most people won't want to pass any tags, this way the user doesn't have to go read notmuch-insert(1), and we also get backwards compatibility for free. > If we go the --folder=inbox --create-folder route, then we'd need to > decide whether the passthrough arguments would *append* to > --folder=inbox --create-folder, or whether they would *replace* > --folder=inbox --create-folder. I'd lean toward replacement in that > case. > > Also, what would you like this configuration key to be named? I was > thinking "insert_args". Fine with me. > d) if messages are placed by default via "--folder=inbox > --create-folder", how should the config key interact with the default >args? > (if we get to this question, i prefer replacement) Replacement is okay with me. -- Sean Whitton signature.asc Description: PGP signature
Bug#966068: RFA: emacs-helm-ag -- Silver Searcher integration with Emacs Helm
control: retitle -1 O: emacs-helm-ag Hello, On Wed 22 Jul 2020 at 07:34AM -07, Sean Whitton wrote: > I request an adoptor for the emacs-helm-ag package. I haven't been > using it myself for a while. > > This is a team-maintained package, so the adoptor should either replace > me in Uploaders:, or alternatively take the package out of the team's > hands. I hereby orphan emacs-helm-ag. -- Sean Whitton signature.asc Description: PGP signature
Bug#952808: RFA: clojure-mode
control: retitle -1 O: clojure-mode Hello, On Sat 29 Feb 2020 at 08:30AM -07, Sean Whitton wrote: > Package: wnpp > Severity: normal > > I request an adoptor for the clojure-mode package. > > This is a team-maintained package, so the adoptor should either replace > me in Uploaders:, or alternatively take the package out of the team's > hands. I hereby orphan clojure-mode. -- Sean Whitton signature.asc Description: PGP signature
Bug#1007877: RM: hothasktags -- ROM; unbuildable for more than a year
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-hask...@lists.debian.org Please drop hothasktags from sid. It has been unbuildable for more than a year and no-one seems sufficiently interested in the package. -- Sean Whitton signature.asc Description: PGP signature
Bug#1003031: RFA: projectile
control: retitle -1 O: projectile Hello, On Sun 02 Jan 2022 at 04:12PM -07, Sean Whitton wrote: > I request an adoptor for the projectile package. I haven't used it for > some time, as I'm now using the built-in package.el for everything for > which I used to use projectile. > > This is a team-maintained package, so the adoptor should either replace > me in Uploaders:, or alternatively take the package out of the team's > hands. > > The package is maintained using git-debrebase, using the workflow > described in dgit-maint-debrebase(7). That's been working well, so I'd > encourage any adopter to continue using the tool. I hereby orphan projectile. There's nothing wrong with it; there is no need for an RM or anything. -- Sean Whitton signature.asc Description: PGP signature
Bug#1007874: O: helm-org
Package: wnpp Severity: normal X-Debbugs-Cc: debian-emac...@lists.debian.org Control: affects -1 src:helm-org I intend to orphan the helm-org package. This package is no longer loaded by my init.el and it would be better if someone who actually uses the package maintains it. There is nothing wrong with it; no need for an RM or anything. This is a team-maintained package, so the adoptor should either replace me in Uploaders:, or alternatively take the package out of the team's hands. -- Sean Whitton signature.asc Description: PGP signature
Bug#1007873: O: popup-el -- visual popup user interface library for Emacs
Package: wnpp Severity: normal X-Debbugs-Cc: debian-emac...@lists.debian.org Control: affects -1 src:popup-el I intend to orphan the popup-el package. This package is no longer loaded by my init.el and it would be better if someone who actually uses the package maintains it. There is nothing wrong with it; no need for an RM or anything. This is a team-maintained package, so the adoptor should either replace me in Uploaders:, or alternatively take the package out of the team's hands. The package description is: popup.el is a visual popup user interface library for Emacs. It provides common UI widgets such as popup tooltips and popup menus. -- Sean Whitton signature.asc Description: PGP signature
Bug#904242: RFA: debpaste-el
control: retitle -1 O: debpaste-el Hello, On Sun 22 Jul 2018 at 01:46PM +08, Sean Whitton wrote: > I request an adoptor for the debpaste-el package. > > This package is no longer in my ~/.emacs.d/init.el and it would be > better if someone who actually uses the package maintains it. > > This is a team-maintained package, so the adoptor should either replace > me in Uploaders:, or alternatively take the package out of the team's > hands. I hereby orphan debpaste-el. -- Sean Whitton signature.asc Description: PGP signature
Bug#904238: RFA: cycle-quotes
control: retitle -1 O: cycle-quotes Hello, On Sun 22 Jul 2018 at 01:42PM +08, Sean Whitton wrote: > I request an adoptor for the cycle-quotes package. > > This package is no longer in my ~/.emacs.d/init.el and it would be > better if someone who actually uses the package maintains it. > > This is a team-maintained package, so the adoptor should either replace > me in Uploaders:, or alternatively take the package out of the team's > hands. I hereby orphan cycle-quotes. -- Sean Whitton signature.asc Description: PGP signature
Bug#904239: RFA: deft
control: retitle -1 O: deft Hello, On Sun 22 Jul 2018 at 01:43PM +08, Sean Whitton wrote: > Package: wnpp > Severity: normal > > I request an adoptor for the deft package. > > This package is no longer in my ~/.emacs.d/init.el and it would be > better if someone who actually uses the package maintains it. > > This is a team-maintained package, so the adoptor should either replace > me in Uploaders:, or alternatively take the package out of the team's > hands. I hereby orphan deft. There's nothing wrong with it; no need for an RM or anything. -- Sean Whitton signature.asc Description: PGP signature
Bug#904241: RFA: xml-rpc-el
control: retitle -1 O: xml-rpc-el Hello, On Sun 22 Jul 2018 at 01:45PM +08, Sean Whitton wrote: > Package: wnpp > Severity: normal > > I request an adoptor for the xml-rpc-el package. > > This is a reverse-dependency for another package for which I am > requesting an adopter, debpaste-el. > > This is a team-maintained package, so the adoptor should either replace > me in Uploaders:, or alternatively take the package out of the team's > hands. I hereby orphan xml-rpc-el. There is nothing wrong with it; no need for an RM or anything. -- Sean Whitton signature.asc Description: PGP signature
Bug#904232: RFA: pointback
control: retitle -1 O: pointback Hello, On Sun 22 Jul 2018 at 01:30PM +08, Sean Whitton wrote: > Package: wnpp > Severity: normal > > I request an adoptor for the pointback package. > > This package is no longer in my ~/.emacs.d/init.el and it would be > better if someone who actually uses the package maintains it. > > This is a team-maintained package, so the adoptor should either replace > me in Uploaders:, or alternatively take the package out of the team's > hands. I hereby orphan pointback. -- Sean Whitton signature.asc Description: PGP signature
Bug#1007870: O: sesman
Package: wnpp Severity: normal X-Debbugs-Cc: debian-emac...@lists.debian.org Control: affects -1 src:sesman I intend to orphan the sesman package. This package is no longer loaded by my init.el and it would be better if someone who actually uses the package maintains it. There is nothing wrong with it; no need for an RM or anything. This is a team-maintained package, so the adoptor should either replace me in Uploaders:, or alternatively take the package out of the team's hands. -- Sean Whitton signature.asc Description: PGP signature
Bug#1007869: O: rainbow-delimiters -- Emacs mode to colour-code delimiters according to their depth
Package: wnpp Severity: normal X-Debbugs-Cc: debian-emac...@lists.debian.org Control: affects -1 src:rainbow-delimiters I intend to orphan the rainbow-delimiters package. This package is no longer loaded by my init.el and it would be better if someone who actually uses the package maintains it. There is nothing wrong with it; no need for an RM or anything. This is a team-maintained package, so the adoptor should either replace me in Uploaders:, or alternatively take the package out of the team's hands. The package description is: rainbow-delimiters is a "rainbow parentheses"-like mode which highlights delimiters such as parentheses, brackets or braces according to their depth. Each successive level is highlighted in a different color. This makes it easy to spot matching delimiters, orient yourself in the code, and tell which statements are at a given depth. . Great care has been taken to make this mode fast. You shouldn't see any change in scrolling or editing speed when it's on even when working in delimiter-rich languages like Clojure or Emacs Lisp. It can be used with any language. . You can customize the colors rainbow-delimiters uses. The default colors are intentionally subtle; they are unobtrusive enough to make the mode worth looking at even if you usually don't like rainbow parentheses modes. A number of major color themes such as Zenburn and Solarized have added their own faces for the mode. -- Sean Whitton signature.asc Description: PGP signature
Bug#1007868: O: queue-el
Package: wnpp Severity: normal X-Debbugs-Cc: debian-emac...@lists.debian.org Control: affects -1 src:queue-el I intend to orphan the queue-el package. This package is no longer loaded by my init.el and it would be better if someone who actually uses the package maintains it. There is nothing wrong with it; no need for an RM or anything. This is a team-maintained package, so the adoptor should either replace me in Uploaders:, or alternatively take the package out of the team's hands. -- Sean Whitton signature.asc Description: PGP signature
Bug#1007867: O: parsebib
Package: wnpp Severity: normal X-Debbugs-Cc: debian-emac...@lists.debian.org Control: affects -1 src:parsebib I intend to orphan the parsebib package. This package is no longer loaded by my init.el and it would be better if someone who actually uses the package maintains it. There is nothing wrong with it; no need for an RM or anything. This is a team-maintained package, so the adoptor should either replace me in Uploaders:, or alternatively take the package out of the team's hands. -- Sean Whitton signature.asc Description: PGP signature
Bug#904236: RFA: emacs-world-time-mode
control: retitle -1 O: emacs-world-time-mode On Sun 22 Jul 2018 at 01:41PM +08, Sean Whitton wrote: > I request an adoptor for the emacs-world-time-mode package. > > This package is no longer in my ~/.emacs.d/init.el and it would be > better if someone who actually uses the package maintains it. > > This is a team-maintained package, so the adoptor should either replace > me in Uploaders:, or alternatively take the package out of the team's > hands. I hereby orphan emacs-world-time-mode. There is nothing wrong with it; no need for an RM or anything. -- Sean Whitton signature.asc Description: PGP signature
Bug#904243: RFA: paredit-everywhere -- cut-down version of paredit for non-lisp buffers
Hello, On Sun 22 Jul 2018 at 01:47PM +08, Sean Whitton wrote: > Package: wnpp > Severity: normal > > I request an adopter for the paredit-everywhere package. > > This package is no longer in my ~/.emacs.d/init.el and it would be > better if someone who actually uses the package maintains it. FAOD, at > the time of writing, I am not requesting an adopter for paredit-el and I > continue to use paredit-el. > > This is a team-maintained package, so the adoptor should either replace > me in Uploaders:, or alternatively take the package out of the team's > hands. I hereby orphan paredit-everywhere (not paredit-el). -- Sean Whitton signature.asc Description: PGP signature
Bug#901374: RFA: perspective-el
control: retitle -1 O: perspective-el Hello, On Tue 12 Jun 2018 at 10:13AM +01, Sean Whitton wrote: > I request an adoptor for the perspective-el package. > > This package is no longer in my ~/.emacs.d/init.el and it would be > better if someone who actually uses the package maintains it. > > This is a team-maintained package, so the adoptor should either replace > me in Uploaders:, or alternatively take the package out of the team's > hands. I hereby orphan perspective-el. -- Sean Whitton signature.asc Description: PGP signature
