Coordinate response to xz-utils (DSA 5649-1)
Hi, how should we react to the compromised xz-utils upload? Ubuntu is reverting their amd64 binaries to pre-Feb 25 and rebuilding stuff. On Debian side AFAIU currently amd64 buildds are paused and pending reinstall (plus rotation of key material, both OpenPGP and SSH). People are starting to investigate packages that have been built since the compromised xz-utils was uploaded, including packages built for stable suites using reproducible builds. Is there someone keeping track of this? Should we also reset the archive to some prior state and rebuilt packages like Ubuntu? Do we need to revert to an earlier date as vulnerable versions have been uploaded to experimental on 2024-02-01 (but the earlier version might only have corrupted test files, not the payload enabler)? If so, which suites and which architectures? (This will likely take a while to prepare.) Do we need any other immediate actions? Should we use something other than mail to keep track of what we want to do? (Mail threads can become hard to keep track of after all.) (Let us please keep future improvements such as more isolated builds out of this particular discussion.) Ansgar
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Sat, 6 Jan 2024 19:38:42 -0800 Steve Langasek wrote: > - dpkg will be uploaded to experimental with 64-bit time_t in the default > flags As far as I understand this approach will break any consumer on a library whose ABI changes to to the ABI changes introduced here unless the consumer is built with the flags from `dpkg-buildflags` (which would now define the ABI). In particular users could no longer just invoke `gcc` alone, but would have to also rely on `dpkg-buildflags` for any software they built on their own using runtime libraries shipped by Debian. It would work in some cases (multi-ABI libraries like libc6 or libraries not affected by the ABI change), but it is not reliable. Do we want this? It must at least be documented, probably in Debian Policy and GCC. This was asked on debian-devel@ multiple times, but there was no answer so far. Ansgar
Re: 11.7 planning + bookworm planning
Hi, On Sun, 2023-04-23 at 18:02 +0200, Paul Gevers wrote: > Any FTP master for 10 or 17 June? So far it looks fine for me. > kibi - 10, 17, 24 d-i > Luna - 10, 17, 24 CD testing > elbrus - 10, 17, 24 release team > adsb - 10, 17, 24 release team > Sledge - 10, 17, 24 images team > donald - 10, 17 press Ansgar
Re: testing security uploads to bookworm-security
Hi, Salvatore Bonaccorso writes: > python-cryptography/38.0.4-3~deb12u1 was uploaded to security-master > as source only upload, the upload got rejected with: > > | Source-only uploads to NEW are not allowed. There were two issues: - The override sync from ftp-master to security-master was not handling the fancy new `-security` addition to suite names. - `bookworm-security` was still configured to not accept any uploads (as was done when the suite was created to prevent accidental uploads). Both issues are now solved and the python-cryptography source upload was processed successfully. Ansgar signature.asc Description: PGP signature
Re: Please dak copy-installer 20230217
Hi, Cyril Brulebois writes: > FTP team, please sync the installer from sid to testing, as it seems to > be Installed for all release architectures (9 total, even if mipsel just > went in): > > dak copy-installer 20230217 Done: +--- | $ dak copy-installer 20230217 | | Will copy installer version 20230217 from suite unstable to | testing. | Architectures to copy: i386, amd64, mipsel, ppc64el, s390x, armel, armhf, arm64, mips64el | Architectures to skip: | Installer has been copied successfully. +--- Thanks for your work on d-i! Ansgar
Re: 11.6 planning
On Thu, 2022-11-17 at 21:33 +, Adam D. Barratt wrote: > Please could you indicate your availability and preferences between: > > - December 3rd No time here. > - December 10th > - December 17th These are still free. Ansgar
Re: grub-pc: regression: update to 2.06-3~deb11u2 fails with gpt
Control: retitle -1 grub-pc: use persistent disk identifier stored in configuration file Control: affects -1 - release.debian.org [ Cc'ed -release@ to notify them it's not a regression after all ] On Wed, 05 Oct 2022 10:27:29 +0200 Ansgar wrote: > On Wed, 2022-10-05 at 09:48 +0200, Ansgar wrote: > > the upgrade to grub-pc 2.06-3~deb11u2 fails: > > > > +--- > > > Setting up grub-pc (2.06-3~deb11u2) ... > > > Installing for i386-pc platform. > > > grub-install: warning: this GPT partition label contains no BIOS > > > Boot Partition; embedding won't be possible. > > > grub-install: error: embedding is not possible, but this is > > > required for cross-disk install. > > > You must correct your GRUB install devices before proceeding: > > > > > > DEBIAN_FRONTEND=dialog dpkg --configure grub-pc > > > dpkg --configure -a > > > dpkg: error processing package grub-pc (--configure): > > > installed grub-pc package post-installation script subprocess > > > returned error exit status 1 > > > Errors were encountered while processing: > > > grub-pc > > > Log ended: 2022-09-23 06:09:42 > > +--- > [...] > > /dev/sda uses GPT and has one partition /dev/sda1; it was created > > this way by d-i (though it has the setting to use gpt enabled). > > Ah, but this was a distraction: /dev/sda isn't the boot device. The > boot device is currently /dev/sdb. That still has a DOS disk label; the > systems using GPT for the boot device as well have a small 1M partition > for BIOS boot. > > So grub-install shouldn't try to install to /dev/sda, but I find > nothing in /etc referencing /dev/sda at all (except for a comment in > /etc/fstab). So I'm not sure why the system tries to install grub > there. > > I now also checked /var/log/installer/syslog and when installing the > system /dev/sda and /dev/sdb were the other way around. And it looks > like that was the case before the previous reboot as well. > > So possibly one of the race conditions I read about? (FWIW, this is a > VM running under VMware.) >From some more investigation and chat on IRC: - Currently the only place where the configuration where grub should be installed is debconf, in particular grub-pc/install_devices. This should be moved to a configuration file in /etc. - grub should use a persistent device identifier instead of /dev/sda and similar. Steve McIntyre said on #-devel: | so we go to all the effort finding out the device details in a | sustainable way, then don't store it :facepalm: | we should be using a persistent device identifier here | and each time we run grub-install that should be re-resolved to a | /dev/*** reference | for added cleverness, we should also warn users that disks have moved | if we no longer find the disk(s) we expect to install ointo | and prompt for an update | so we pick up on disk replacement, etc. I think one has to check that grub doesn't get confused as well: in my case the device can be /dev/sda or /dev/sdb for Linux, but it should always be (hd0) for grub. Implementing this probably also requires changes to the grub-installer package. Ansgar
Bug#1021301: grub-pc: regression: update to 2.06-3~deb11u2 fails with gpt
Package: grub-pc Version: 2.06-3~deb11u2 Severity: important X-Debbugs-Cc: debian-release@lists.debian.org Hi, the upgrade to grub-pc 2.06-3~deb11u2 fails: +--- | Setting up grub-pc (2.06-3~deb11u2) ... | Installing for i386-pc platform. | grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible. | grub-install: error: embedding is not possible, but this is required for cross-disk install. | You must correct your GRUB install devices before proceeding: | | DEBIAN_FRONTEND=dialog dpkg --configure grub-pc | dpkg --configure -a | dpkg: error processing package grub-pc (--configure): | installed grub-pc package post-installation script subprocess returned error exit status 1 | Errors were encountered while processing: | grub-pc | Log ended: 2022-09-23 06:09:42 +--- The previous version installed successfully and the system was booting without problems so far: +--- | Setting up grub-pc (2.06-3~deb11u1) ... | Installing for i386-pc platform. | Installation finished. No error reported. | Generating grub configuration file ... | Found linux image: /boot/vmlinuz-5.10.0-17-amd64 | Found initrd image: /boot/initrd.img-5.10.0-17-amd64 | Found linux image: /boot/vmlinuz-5.10.0-16-amd64 | Found initrd image: /boot/initrd.img-5.10.0-16-amd64 | Warning: os-prober will be executed to detect other bootable partitions. | Its output will be used to detect bootable binaries on them and create new boot entries. | done | Log ended: 2022-09-12 06:51:32 +--- /dev/sda uses GPT and has one partition /dev/sda1; it was created this way by d-i (though it has the setting to use gpt enabled). Ansgar
Re: debian-installer 20220917 via tpu
Cyril Brulebois writes: > FTP Masters, please sync the installer from *tpu* to testing, once it's > available there. > > dak copy-installer 20220917 -s bookworm-proposed-updates Done: +--- | $ dak copy-installer 20220917 -s bookworm-proposed-updates | | Will copy installer version 20220917 from suite bookworm-proposed-updates to | testing. | Architectures to copy: i386, amd64, mipsel, ppc64el, s390x, armel, armhf, arm64, mips64el | Architectures to skip: | Installer has been copied successfully. +--- Ansgar
Re: Please dak copy-installer 20220914
Cyril Brulebois writes: > FTP Masters, please sync the installer from sid to testing, as it seems > to be Installed for all release architectures (9 total): > > dak copy-installer 20220914 Done: +--- | $ dak copy-installer 20220914 | | Will copy installer version 20220914 from suite unstable to | testing. | Architectures to copy: i386, amd64, mipsel, ppc64el, s390x, armel, armhf, arm64, mips64el | Architectures to skip: | Installer has been copied successfully. +--- Ansgar
Fwd: transition: gjs and gnome-shell likely to be removed from armel
Control: reassign -1 release.debian.org On Thu, 25 Aug 2022 11:19:30 +0100 Simon McVittie wrote: > Package: rele...@debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: debian-...@lists.debian.org, debian-gtk-gn...@lists.debian.org > > The plan is for Debian 12 to release with GNOME 43, which is currently in > beta upstream. Beta versions of individual GNOME 43 packages are gradually > making their way into either unstable if they are not disruptive, or > experimental if they are. One of the new packages we need is an update > to gjs, GNOME's JavaScript environment, which depends on mozjs102 > (Spidermonkey), the latest stable-branch of Mozilla's JavaScript engine. > > mozjs102 makes more use of atomic operations, which are available on > all architectures except for armel (because armel is ARMv5, and useful > atomics are ARMv6 or ARMv7 instructions). This has led to a few different > failure modes when building mozjs102 on armel (#1017979, #1017961). > Even if we can solve them eventually, I think delaying GNOME 43 for the > benefit of machines that are not powerful enough to run GNOME would be > doing a disservice to our users. > > So I think we need to be looking at the possibility of doing > architecture-specific removals of gjs and dependent packages from armel. > Based on prior experience of similar architecture-specific removals from > s390x when mozjs was compiling-but-broken on that architecture, I think > this would involve: > > - removing gjs > - removing gnome-shell (and its extensions) > - removing gdm3 > - either hacking gnome-panel to be able to compile without gdm3, or > removing it > - either hacking meta-gnome3 to install a non-GNOME display manager and > the GNOME Flashback desktop environment (basically a GNOME 2 fork) > instead of real GNOME, or leaving it unmodified but accepting that > gnome-core and therefore task-gnome-desktop are uninstallable on armel > - disabling a subset of unit tests in src:ostree (which want gjs) > - removing leaf apps written in JavaScript, such as polari > > Obviously that's quite a bit of churn, mostly in packages that, in > practice, have never been useful to run on the 2009-2010 plug computers > that seem to be the main use-case for armel. > > Is armel a realistic candidate for being a Debian 12 release > architecture? It's already lacking other important packages like Firefox, > and if it ceased to be treated as a release architecture very soon, > then we wouldn't have to do all this work to coax GNOME into testing > despite armel. > > Or, failing that, is it still the release team's position that all task > packages are required to be installable on all architectures, and that it > is preferable to have a task install the wrong things rather than have > it be uninstallable? If we could have task-gnome-desktop and gnome-core > just be uninstallable on armel, and have the testing machinery accept > and ignore that, then that would seem more honest than having to modify > them like we did for s390x[1]. > > As with my previous work on mozjs + s390x, it is worth noting that I > am not an ARM porter or an ARM desktop user, my only armel machine is > no longer supported as of Debian 11 and was never able to run GNOME
Re: buster EOL (10.13) and 11.5 planning
Hi, On Thu, 2022-07-28 at 17:09 +0100, Adam D. Barratt wrote: > - August 20 > - [August 27 doesn't work for at least me and the Images Team, so nope] > - September 3rd > - September 10th All dates should still work for me. > any opinions on whether we should do them at the same time or > separately. Either is fine with me. Ansgar
Re: 11.4 planning
Hi, On Fri, 2022-06-17 at 20:31 +0100, Adam D. Barratt wrote: > - July 2nd (means freezing next weekend, but so be it) > - July 9th Both would work for me. Ansgar
Re: Bug#1012533: ftp.debian.org: Please consider a firmware component for bookworm
Hi, On Wed, 2022-06-08 at 21:48 +0200, Jonathan Carter wrote: > Recently, Steve McIntyre initiated a discussion[1] on debian-devel on > the future of firmware in Debian, and how we want to address it > as a project. [ Request to add non-free-firmware ] Okay, I'm fine with adding non-free-firmware. I assume the other members of the ftp team are also still fine with this. Should we add it to testing/unstable/experimental in one go? Or does the release team prefer to wait with adding it to testing? We can always revert the addition temporarily if we find bugs that take a while to fix. Ansgar
Re: Bug#1010660: britney: Crash with RecursionError: maximum recursion depth exceeded
Control: reassign -1 release.debian.org Control: retitle -1 britney: Crash with RecursionError: maximum recursion depth exceeded On Fri, 2022-05-06 at 12:41 +0200, Christian Marillat wrote: > I'm using britney (last commit normally) > 2ccce826090ebc3f2cbdb26df3c5b0817f7a7cc2 britney is not part of dak and is not maintained by the FTP team; reassigned to the correct pseudo-package. > You can download data used for this crash here : > > https://www.deb-multimedia.org/tests/britney-2022-05-06.tar.xz > > Since may 2, 2022 I see : > > Traceback (most recent call last): > File "/usr/bin/britney.py", line 1583, in > Britney().main() > File "/usr/bin/britney.py", line 1570, in main > self.upgrade_testing() > File "/usr/bin/britney.py", line 1241, in upgrade_testing > self.run_auto_hinter() > File "/usr/bin/britney.py", line 1515, in run_auto_hinter > for lst in self.get_auto_hinter_hints(self.upgrade_me): > File "/usr/bin/britney.py", line 1479, in get_auto_hinter_hints > hint = find_related(e, set(), True) > File "/usr/bin/britney.py", line 1468, in find_related > if not find_related(p, hint): > File "/usr/bin/britney.py", line 1468, in find_related > if not find_related(p, hint): > File "/usr/bin/britney.py", line 1468, in find_related > if not find_related(p, hint): > [Previous line repeated 989 more times] > File "/usr/bin/britney.py", line 1462, in find_related > hint.add(excuse.item) > File "/usr/lib/python3/dist-packages/britney2/migrationitem.py", > line 79, in __hash__ > if not self.version: > RecursionError: maximum recursion depth exceeded
Bug#995636: OpenSSL 3.0 - Apache 2.0 vs GPL 2 (Re: Bug#995636: transition: openssl)
Paul Wise writes: > On Wed, Oct 6, 2021 at 11:30 AM Luca Boccassi wrote: >> On Tue, 2021-10-05 at 21:04 +0200, Sebastian Andrzej Siewior wrote: >> > Additionally OpenSSL is considered system library, see >> > https://bugs.debian.org/951780 >> > https://bugs.debian.org/972181 >> >> Even if that interpretation holds, and it's not a universal >> interpretation (eg: lawyers from Canonical strongly disagree as far as >> I know), again that applies to first-party binaries only as far as I >> understand. It's not as clear-cut with libraries used by third parties. I believe Canonical also ships GPL-2-only programs linked (possibly indirectly) to OpenSSL as part of their Linux distribution these days. > As I understand it, it is meant only for binaries distributed by > parties other than the one distributing the system containing the > "system library". So third-party app distributors are fine to ignore > the incompatibility between a GPL app and a proprietary libc, but the > OS vendor can't include GPL apps linked to that proprietary libc > within their system. Debian uses many GPL-2-incompatible system libraries: for example GPL-3-or-later libraries such as libstdc++ or libgcc or gnutls[1]. Debian also ships many GPL-2-only programs using these. So if this was considered a problem, then the problem would be quite large. [1]: gnutls could be made LGPL-2.1-or-later by rewriting the GPL-3-or-later build scripts; note that GPL-2 states that "complete source code" includes "scripts used to control compilation and installation of the executable" > I believe OpenSSL 3's choice of the Apache 2 license only improves > compatibility, it doesn't reduce it. GPLv3 is supposedly compatible > with Apache 2, so GPLv3 and GPLv2+ programs are newly compatible with > OpenSSL 3. Most existing GPLv2-only programs that use OpenSSL will > have the exception anyway. This depends on what you mean by "use OpenSSL": if program use OpenSSL directly, maybe; if programs link to OpenSSL indirectly, for example via dependency chains such as my-program -> some-library -> some-library-implementing-some-network-protocol -> OpenSSL this becomes increasingly unlikely the longer the chain is. Also people seem to keep adding TLS support to more and more libraries, so such a dependency can just silently appear later. Python programs using OpenSSL also usually don't have such an exception. , Ansgar
Re: Finding a tentative bullseye release date
Hi, On Tue, 2021-07-20 at 22:35 +0200, Paul Gevers wrote: > We currently don't have any day yet with all involved > teams comfortably present, the one coming closest is 4 September. > Somebody from ftp available on 14 august? That should be doable. Ansgar
Re: Please dak copy-installer 20210606
Hi, Cyril Brulebois writes: > dak copy-installer 20210606 Done: +--- | Will copy installer version 20210606 from suite unstable to testing. | Architectures to copy: i386, amd64, mipsel, ppc64el, s390x, armel, armhf, arm64, mips64el | Architectures to skip: | Installer has been copied successfully. +--- Ansgar
Re: Finding a tentative bullseye release date
On Sun, 2021-05-30 at 09:09 +0200, Paul Gevers wrote: > 26 June > 3 July > 10 July > 17 July [Steve (CD), press] > 24 July [Steve (CD), press] > 31 July > 7 August > 14 August Currently all of these are fine for me. Ansgar
Re: Tentative summary of the AMD/ATI/NVidia issue
Lucas Nussbaum writes: > It looks like the three open paths for resolution are: > > A) understand and restore the behaviour from Debian 10, that is, get X > to work in a degraded mode after installation. How it worked with Debian > 10 (and why it doesn't with Debian 11) is unknown. > > B) In the installer, detect that firmware-amd-graphics or > firmware-misc-nonfree should be installed, and either install it (?), > or redirect the user to the unofficial installer that includes them. > > C) Do nothing and document this in the release notes There is at least also D) Install (non-free) firmware and include it in official install media. I don't think degraded operation (just vesa, no sound, no wifi, known issues in microcode, ...) will continue to be an attractive option. So maybe we should revisit whether we should just include firmware; I wanted to suggest so at least for Bookworm. Ansgar
Re: Finding a tentative bullseye release date
にゃあ！ On Wed, 2021-04-21 at 21:19 +0200, Paul Gevers wrote: > Can you please let us know if/when you're available? > May 1 CD, Press > May 8 CD, Press > May 15 CD > May 22 CD, Press > May 29 (CD) All should be fine for me. It's not like one can do much other interesting things currently. Ansgar
Bug#983912: grub2: consider renaming signed source packages to grub2-signed-*
Source: grub2 Version: 2.04-16 Severity: normal X-Debbugs-Cc: ftpmas...@debian.org, debian-release@lists.debian.org grub2 currently uses grub-efi-signed-* as source package names for the Secure Boot signed packages. While releasing the last security update we found a small issue with these names: dak processes source packages in lexiographic order, so it would process grub-efi-signed-* before grub2 when accepting all packages at once from the "embargoed" policy queue. But the grub-efi-signed-* binary packages have Built-Using: grub2; as grub2 is not accepted from embargoed at this point in time, the /binary/ uploads will be rejected in this case. (This problem exists in principle with all Built-Using relations.) We could avoid this particular problem if the source package names of the signed packages sort after grub2, i.e., if they were named grub2-signed-* or grub2-efi-signed-*. With linux this is already the case (src:linux and src:linux-signed-*). (As a minor thing, I think the changelog entry in the signed packages should also use the grub maintainer's name, not ftpmaster@ similar to what src:linux-signed-* has, but that is just cosmetics.) I've Cc'ed debian-release@ as it is already past soft freeze, but I think just renaming the source packages would be unlikely to break anything. Ansgar
Bug#980040: nmu: dune-grid-glue_2.7.0-3
Control: tags -1 - moreinfo On Sun, 2021-01-17 at 11:43 +0100, Sebastian Ramacher wrote: > > nmu dune-grid-glue_2.7.0-3 . ANY . unstable . -m "Rebuild against > > DUNE 2.7.1" > > dw dune-grid-glue_2.7.0-3 . ANY . -m "libdune-grid-dev (>= 2.7.1)" > > dune-grid-glue is currently missing builds on arm64, armhf and > ppc64el. dune-grid-glue built on these architectures with the updated dependencies after a give-back, but that means a binNMU is only needed on the other architectures (or all if the version should be in sync, but I doubt people will use multi-arch for such packages). Ansgar
Bug#980040: nmu: dune-grid-glue_2.7.0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, please schedule a binNMU for dune-grid-glue to build it against the DUNE 2.7.1 release. Ansgar nmu dune-grid-glue_2.7.0-3 . ANY . unstable . -m "Rebuild against DUNE 2.7.1" dw dune-grid-glue_2.7.0-3 . ANY . -m "libdune-grid-dev (>= 2.7.1)"
Re: Please dak copy-installer 20201202
Cyril Brulebois writes: > FTP Masters, please sync the installer from sid to testing, as it seems > to be Installed for all release architectures (9 total): > > dak copy-installer 20201202 Done. Ansgar
Bug#966373: general: Higher version for uploads to stable and oldstable distributions
Hi Javier, On Sun, 2020-09-06 at 09:20 +0200, Javier Serrano Polo wrote: > On Sun, 30 Aug 2020 11:53:59 +0200 Chris Hofstaedtler < > z...@debian.org> > wrote: > > Filing this against the `general` package does nothing > > useful for this discussion, > > On Mon, 27 Jul 2020 16:28:25 +0200 Ansgar wrote: > > I would recommend to > > discuss on debian-devel@. I didn't say that, but I said "If the submitter [Javier Serrano Polo] wasn't banned from Debian lists, ...". This implies that I would not recommend discussing it on debian-devel@ to Javier Serrano Polo as Javier Serrano Polo is banned on Debian mailing lists, so bugs are unlikely to get any answer anyway. I also didn't recommend filing bug reports against the "general" pseudo-package (which you then did, possibly because you are aware that you are banned on Debian lists). If you want a more specific recommendation: I would recommend not sending mails to Debian mailing lists if you are banned on them. This includes filing bugs that end up forwarded to said mailing lists. Please don't send me further mails. Regards, Ansgar
Re: Go issues wrt. Debian infrastructure: moving forward
Hi, Clément Hermann writes: > The original message on debian-go and debian-release is here: > > https://lists.debian.org/msgid-search/176455fa-4611-f2c1-9ca1-f855d7d99...@debian.org For the ftp-master side, I wanted to just import all sources from a stable release into security-master (in a private archive). dak can then use these when binNMUs arrive, for Built-Using, or when people upload without the .orig.tar.gz included. The second part should already work. There are currently two issues with this: - security-master.d.o should get more disk space. Maybe we should get a (new) physical host for security-master that provides this? It should probably be a physical host and not a VM to allow using a YubiKey (or similar) for the signing key. - Time. I currently don't have much to spend on Debian. Are there more issues that ftp-master would have to deal with? Ansgar
Re: Please dak copy-installer 20200314
Cyril Brulebois writes: > dak copy-installer 20200314 Done. Ansgar
Re: Please dak copy-installer 20191129
Cyril Brulebois writes: > FTPmasters, please sync the installer from sid to testing, as it seems > to be Installed for all release architectures (9 total): > > dak copy-installer 20191129 Done. > FWIW, unless somebody objects, it should be fine to get rid of all > previous versions in both testing and unstable. I'll try to remember to do so in the next days. Thanks for your tireless work on d-i. Ansgar
Bug#944351: Providing minor version somewhere in /etc/os-release in buster
Stephen Dowdy writes:
> On 11/16/19 1:35 AM, Julien Cristau wrote:
> If i could interject here... I haven't followed the entire thread from
> start-to-finish, but
> my main concern here is the fact that somewhere 'lsb_release -rs' got broken.
> This has ALWAYS returned "{major}.{minor}" release strings. now it does not.
Did it return `{major}.{minor}` even when Debian releases used `X.Y.Z`?
If yes, then it should just return `10` these days as Debian no longer
uses `X.Y.Z`, but only `X.Y` (and `Y` is basically the patch level); or
just `X` to identify releases.
> I use this ALL THE TIME to check status of my systems.
What status? That you have installed all recent updates? But just
checking version numbers doesn't indicate that (it misses both X-updates
and X-security).
> https://www.freedesktop.org/software/systemd/man/os-release.html
> (seems as good a place as any)
>
> specifies: "...This field is optional. Example: "VERSION_ID=17" or
> "VERSION_ID=11.04"..."
>
> clearly it is intended to be able to support {major}.{minor}, and is
> *optional*.
Though version numbers like `11.04` aren't following the {major}.{minor}
scheme. In fact the examples don't include the patch level (I assume
the `11.04` refers to Ubuntu's version scheme), so they suggest we
should just use VERSION_ID=10.
> So, my vote is to put the full "{major}.{minor}" there. anyone parsing it
> can always
> strip past the '.' if they don't care about the minor part, and i'll argue if
> they are
> NOT doing so, then that'd be a bug, as the field certainly can contain '.' by
> the
> above reference.
No, with Ubuntu's version scheme `18.04` and `18.10` are different
releases. But Debian's `10.0` and `10.1` are the same release.
So you cannot just stop the part after the `.` and expect automated
systems to work correctly, but would have to decide on a
per-distribution basis how to treat the `VERSION_ID` if Debian were to
put `10.1` there.
(While for Debian Woody or Sarge VERSION_ID=3.0 or VERSION_ID=3.1 would
have been correct.)
Ansgar
Re: Debian Linux kernel uploads
Hi, Hector Oron writes: > I would like to support Debian Linux kernel team by doing kernel > package uploads. Related to Linux uploads: I've added an exception to allow source-only uploads to NEW for src:linux. Feel free to try. Ansgar
Bug#942104: release.debian.org: Will fail if "Suite" field is missing
> britney assumes that if you have a Release file, it will contain a "Suite" > field. That's not true, the "Codename" entry is required but the "Suite" > one is optional. https://wiki.debian.org/DebianRepository/Format#A.22Release.22_files says one of Suite and Codename is required. Codename itself is not required. I wouldn't be surprised if many tools just use one and assume it always exists and would recommend to always provide both. Ansgar
Re: Please dak copy-installer 20190702
Cyril Brulebois writes: > FTPmasters, please sync the installer from sid to testing, as it seems > to be Installed for all release architectures (10 total): > > dak copy-installer 20190702 Done. Ansgar
Bug#929011: unblock: singularity-container/3.1.1+ds-1
Control: tag -1 - moreinfo Paul Gevers writes: > On Wed, 15 May 2019 03:47:28 -0400 Afif Elghraoui wrote: >> Please unblock package singularity-container/3.1.1+ds-1 >> >> This package is prone to security vulnerabilities. Upstream provides >> long-term support for selected versions to their paid users, but also >> releases all code changes (including backported security patches) to the >> community. >> >> Both 3.0.x and 3.1.x were released earlier this year and it was not >> known at the time which of these would be the LTS version. 3.0.3 is what >> I bet on and what is in Testing now, but it now turns out that I was >> wrong and it's actually 3.1. Using it would greatly facilitate our >> ability to provide support over the lifetime of Buster. >> >> The benefits of doing this have also just been clearly demonstrated: >> Upstream just released 3.2.0, adding new features as well as fixing >> security issues affecting versions 3.1.0 and up, but because 3.1 is >> under LTS support for their paid users, they also provided the security >> patches backported to 3.1 (see the 3.2.0 release notes - >> https://github.com/sylabs/singularity/releases/tag/v3.2.0 ). >> >> So I apologize for the large diff, but I think we'd be in much better >> shape having this upstream version in Buster. Especially because of the >> large diff, backporting patches to 3.0 without the help from upstream >> that we'd get by using 3.1 would be unnecessarily more burdensome. >> >> many thanks for your time and consideration > > Your proposed changes very much do not align with the freeze policy, so > you're asking for an exception for a new upstream release. This package > is currently listed to be auto-removed due to docker.io, so I am not > going to review it now. docker.io is a major concern for the > security-team so that needs to be resolved first. If that gets resolved > in a timely manner, i.e. before it is auto-removed, please ping this bug > (e.g. by removing the moreinfo bug). I've removed the moreinfo tag as docker.io was unblocked. Ansgar
Re: Please dak copy-installer 20190623
Cyril Brulebois writes: > FTPmasters, please sync the installer from sid to testing: > > dak copy-installer 20190623 Done. Thanks for your work, Ansgar
Re: Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Jonathan Dowland writes: > So far as I am aware there is still radio silence from active GNOME > packaging team members regarding this issue. No comment yet on the > patch I adapted, positive or negative; this bug (#927667) remains > at an RC severity. > > I've not yet read all the thread that Samuel linked to[1] but it looks > like it leans in favour of preserving the current default (xorg). > > I'm copying -release team to see if they have any (new) opinions on > the matter. Otherwise I guess it's up to someone to prepare an NMU > upload, which I will *try* to look at in the next few days, but can't > make any guarantees. I'm just a GNOME user, but from gdm3's changelog the default was switched to Wayland in July 2017 (or August 2017 for unstable). I myself only noticed the switch after reading it happened somewhere on the internet shortly after it happened. Switching the default back two weeks before the release seems too late for me. The largest issue seems to be accessibility, but as far as I understand we already recommend a different desktop environment for that. I don't think that warrants changes that would only see very little testing by now :-/ Ansgar
Bug#929108: unblock: gmsh/4.1.5+really4.1.3+ds1-1
Control: tags -1 - moreinfo Control: retitle -1 unblock: gmsh/4.1.5+really4.1.3+ds1-1 Ivo De Decker writes: > On Fri, May 17, 2019 at 11:12:59AM +0200, Ansgar Burchardt wrote: >> Do you prefer an upload via t-p-u or should I prepare a gmsh >> 4.1.5+really4.1.3+ds1-1 upload for unstable? > > An upload to unstable would be preferred. So please go ahead with that and > remove the moreinfo tag from this bug once it is in unstable. gmsh_4.1.5+really4.1.3+ds1-1 was uploaded to unstable yesterday. Ansgar
Bug#928227: technical solutions enabling binNMUs in the security archive (support of golang packages)
Paul Gevers writes: > On 20-05-2019 09:06, Ansgar wrote: >> I though about importing the full source to security-master already for >> a different reason: `Built-Using` leads to a similar problem as binNMUs >> in that uploads require source that is not already present in the >> archive. >> >> It is not necessary to push all sources to the public mirrors. > > Does this mean you think it is feasible to do/fix this in the near future? Importing sources once is probably doable; writing something to continue updating them (at point release time and similar) takes more time which I currently can't commit to. There is also the question of storage: the full buster source is something like 60 GB+, but security-master only has 63 GB free storage right now (need to check with DSA by how much that could increase). Though we might need more storage over the lifetime of Buster anyway as eventually oldstable will have debug symbols too... If storage is a problem, we would need to look at importing only subsets, but I don't really like treating packages differently. Ansgar
Bug#928227: technical solutions enabling binNMUs in the security archive (support of golang packages)
Paul Gevers writes: > On 08-05-2019 18:33, Shengjing Zhu wrote: >>>> 2. binNMU without full source upload for security-master. >>>> >>>>It's still not possible, and I don't know there's any effort to >>>>change the dak. > > I am all to new into this business, so ignore my ignorance and please > educate me on any mistake. Can somebody please try to explain what the > exact problem is or point me to documentation or earlier discussion that > do that? I'll try to write down potential descriptions as I see them > (from quite a bit of guessing). > > IIUC from this thread so far, ftp-master and security-master are two > separate archives [1]. The security-master archive only contains sources > and binaries that were uploaded to security. A potential solution to the > problem at hand seems to be to sync all sources from ftp-master into > security-master, but I guess that is undesirable because of the massive > size increase of the security archive in that case. If this is going to > be the solution, is this still dak domain? I though about importing the full source to security-master already for a different reason: `Built-Using` leads to a similar problem as binNMUs in that uploads require source that is not already present in the archive. It is not necessary to push all sources to the public mirrors. > Another solution already raised by Shengjing is to merge the archives. I > *guess* that is undesirable due to the fact that the security archive > often has embargoed sources and binaries. Am I right there? That doesn't work as dak doesn't try to keep secrets. There are various ways information would be leaked about embargoed issues (mails, database, web interface (rmadison), ...). I personally also don't find it too bad to have a fallback: if one of the hosts is broken at the same time we have to release a critical update, we can still do so by publishing via the "wrong" archive. Ansgar
Bug#929108: unblock / tpu approval: gmsh/4.1.3+ds1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
gmsh has an old path to OpenCASCADE include files (#927808); this is
easy to fix (see attached diff).
Rebuilding the package also changes a dependency on amd64 (libgmsh4.1
depends on `libhdf5-openmpi-103 (>= 1.8.13)` instead of `libhdf5-103`
after the rebuild); however this matches the dependency on i386.
However gmsh was updated to a new upstream release in unstable on
2019-03-02 with a small fix on 2019-03-04; this missed the freeze date
slightly.
Do you prefer an upload via t-p-u or should I prepare a gmsh
4.1.5+really4.1.3+ds1-1 upload for unstable?
Ansgar
diff -Nru gmsh-4.1.3+ds1/debian/changelog gmsh-4.1.3+ds1/debian/changelog
--- gmsh-4.1.3+ds1/debian/changelog 2019-01-27 12:22:01.0 +0100
+++ gmsh-4.1.3+ds1/debian/changelog 2019-05-17 10:41:56.0 +0200
@@ -1,3 +1,10 @@
+gmsh (4.1.3+ds1-2) buster; urgency=medium
+
+ * Team upload.
+ * debian/rules: Do not pass `-DOCC_INC=...` to cmake (Closes: #927808)
+
+ -- Ansgar Burchardt Fri, 17 May 2019 10:41:56 +0200
+
gmsh (4.1.3+ds1-1) unstable; urgency=medium
* [dbbbe82] New upstream version 4.1.3+ds1
diff -Nru gmsh-4.1.3+ds1/debian/rules gmsh-4.1.3+ds1/debian/rules
--- gmsh-4.1.3+ds1/debian/rules 2019-01-27 12:22:01.0 +0100
+++ gmsh-4.1.3+ds1/debian/rules 2019-05-17 10:39:57.0 +0200
@@ -32,7 +32,6 @@
-DENABLE_ONELAB:BOOL=ON \
-DCMAKE_SKIP_RPATH:BOOL=ON \
-DCMAKE_INCLUDE_PATH:STRING="/usr/include/mpi" \
--DOCC_INC:STRING="/usr/include/occt" \
-DOCC_LIB:STRING="/usr/lib/${DEB_HOST_MULTIARCH}"
│
Bug#925435: unblock: fwupd/1.2.5-2
Steve McIntyre writes: > Please unblock package fwupd Please also unblock fwupd-amd64-signed/1.2.5+2 fwupd-arm64-signed/1.2.5+2 fwupd-armhf-signed/1.2.5+2 fwupd-i386-signed/1.2.5+2 at the same time. Ansgar
Bug#925436: unblock: fwupdate/12-4
Steve McIntyre writes: > Please unblock package fwupdate Please also unblock fwupdate-amd64-signed/12+4 fwupdate-arm64-signed/12+4 fwupdate-armhf-signed/12+4 fwupdate-i386-signed/12+4 at the same time. Ansgar
Re: Please dak copy-installer 20181206
Cyril Brulebois writes: > FTPmasters, please sync the installer from sid to testing: > > dak copy-installer 20181206 Done. Thanks for your work on d-i :-) Ansgar
Re: Scheduling 9.6
Hi, "Adam D. Barratt" writes: > - November 10th This would work if needed, though I don't mind someone else doing the archive side (still have some things to sort out *sigh*). Ansgar
Re: Broken dak?
Cyril Brulebois writes: > I assume you've been notified already but anyway… > > britney explodes likes this: > | Traceback (most recent call last): > | File "/usr/local/bin/dak", line 249, in > | main() > | File "/usr/local/bin/dak", line 229, in main > | module.main() > | File "/srv/ftp-master.debian.org/dak/dak/control_suite.py", line 470, in > main > | process_file(sys.stdin, suite, action, transaction, britney, force) > | File "/srv/ftp-master.debian.org/dak/dak/control_suite.py", line 288, in > process_file > | set_suite(file, suite, transaction, britney, force) > | File "/srv/ftp-master.debian.org/dak/dak/control_suite.py", line 250, in > set_suite > | for key in sorted(desired, > cmp=functools.cmp_to_key(cmp_package_version)): > | TypeError: comparison function must return int, not K > > Possibly a consequence of this? > | commit a3a66d4d86181735a72f766fa24fbb5d7d8de625 > | Author: Bastian Blank > | Date: Wed Jun 27 15:26:19 2018 +0200 > | > | Convert remaing compare functions Yes, should be fixed by now. Ansgar
Re: Scheduling 9.5
Hi, On Sat, 2018-06-23 at 17:30 +0100, Adam D. Barratt wrote: > On Tue, 2018-06-12 at 12:44 +0100, Adam D. Barratt wrote: > [...] > > Given all of the above, I think the sanest option is to concentrate > > on getting 8.11 done and jessie off our radar and then get 9.5 > > sorted. > > > > For suggested dates for 9.5, we know that June 30th is a no-go, > > Debcamp starts on July 21st and then Debconf on the 28th. So that > > leaves us with: > > > > - July 7th > > - July 14th > > > > Are people available for either or both of those dates? > > The 7th is looking like the favourite so far (although would mean > freezing next weekend), but we still need an ftp-master (N)ACK on > either / both date. I still have time on either weekend. Ansgar
Re: jessie-security packages missing from ftp-master
Hi, "Adam D. Barratt" writes: > On Sun, 2018-06-17 at 14:05 +0200, Ansgar Burchardt wrote: >> "Adam D. Barratt" writes: >> > Packages not synced to ftp-master >> > = >> > > [...] >> > * openoffice.org-dictionaries 1:3.3.0~rc10-4+deb8u1 (source + all) >> > - I think this is due to some of the binaries (e.g. hunspell-fr) >> > being produced by other source packages with higher versions > [...] >> All of these should now be in oldstable-new. > > Thanks a lot for all the work on that! In future I'll try and follow up > more quickly after issues, so it's easier to check and resurrect > things. :( > > I assume something (relevant) has changed in the past year or so, as > openoffice.org-dictionaries managed to get accepted this time. It looks > like the original issue was what I thought, however: > > hunspell-fr | 1:3.3.0-4+deb8u1 | oldstable-proposed-updates | all > hunspell-fr | 1:5.2-1 | oldstable | source, all I temporarily disabled the version check (o-p-u > oldstable) to get this in o-p-u. > Is that likely to cause an issue on point release day, or should we > simply end up with jessie containing both binaries temporarily, with > the "older" one getting dominated away? I guess dominate should just get rid of the lower versioned package. Ansgar
Re: jessie-security packages missing from ftp-master
"Adam D. Barratt" writes: > Packages not synced to ftp-master > = > > I've added notes where I'm aware of reasons for the missing sync. I > think this set will all need ftp-master investigation / resolution. > > * enigmail 2:1.9.9-1~deb8u1 (source + all) > * freerdp 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1 (source + > binaries) > * mat 0.5.2-3+deb8u1 (source + all) > - This was originally uploaded to ftp-master, rejected, and re- > uploaded to security "as-is", so failed the replay check on ftp-master > * openjdk-7 7u171-2.6.13-1~deb8u1 (source + binaries) > - I think this may have been a case where the binary uploads were > processed before the source. I suspect that on re-processing some > architectures may have issues with version constraints, but getting as > many incorporated as possible would be appreciated. > * openoffice.org-dictionaries 1:3.3.0~rc10-4+deb8u1 (source + all) > - I think this is due to some of the binaries (e.g. hunspell-fr) > being produced by other source packages with higher versions > * procps > - appears to have had some sort of upload error > > 20180610173424|process-upload|dak|procps_3.3.9-9+deb8u1_armhf.changes|Error > while loading changes: No valid signature found. (GPG exited with status code > 512) All of these should now be in oldstable-new. Ansgar
Re: Please dak copy-installer 20180610
Cyril Brulebois writes: > FTPmasters, please sync the installer from sid to testing: > > dak copy-installer 20180610 Done. Thanks for maintaining d-i, Ansgar
Re: Scheduling 9.5
On Fri, 2018-06-08 at 18:51 +0100, Adam D. Barratt wrote: > We can either accept the packages and put up with the situation for a > short while, or do 9.5 before 8.11. In practical terms, that would > likely mean both 9.5 and 8.11 on June 23rd, freezing both next > weekend. Should be fine with me; Joerg wanted to do the 8.11 one, but if he has time restrictions on June 23rd and doing 8.11 after 9.5 would be too late for him, I could probably also do both. (If Joerg wants to do both, that's also fine with me.) Ansgar
Re: Bug#894123: RM: nvidia-graphics-modules/oldstable -- RoQA; license problem; incompatible with current kernel ABI
Control: reassign -1 release.debian.org Control: user release.debian@packages.debian.org Control: usertag -1 + rm Control: tag -1 + jessie Removals from (old)*stable are handled by the release team; reassigning this bug to them. On Mon, 2018-03-26 at 16:51 +0100, Ben Hutchings wrote: > See #815060 for the license issue. > > The Linux kernel ABI in jessie was changed in January as a result of > the mitigation of the Meltdown security issue. This package would > need to be updated to build new compatible modules, but that should > not be done due to the license issue. > > For the same reasons, this package should also be removed from wheezy > - though I don't think that's practical no since there won't be any > further point releases.
Re: Scheduling 9.4
On Sat, 2018-02-10 at 12:27 +0100, Julien Cristau wrote: > we shipped 9.3 a couple of months ago, so we're overdue for 9.4. > > Can you please let us know your availability on the following: > - March 3 > - March 10 These don't work for me. > - March 17 > - March 24 > - March 31 These might work. Given Steve doesn't have time on the later dates, it might be better to have another ftpmaster handle the point release on March 3 or 10. Ansgar
Re: wanna-build access to schedule binNMUs for Go packages
Philipp Kern writes: > On 01.02.2018 06:45, Salvatore Bonaccorso wrote: >> On Wed, Jan 31, 2018 at 09:04:09PM +0100, Michael Stapelberg wrote: >>> binNMUs for unstable. >> >> Why, if that is for unstable, permissions for embargoed >> queues/security would be needed? Is that due to implementtation on >> accessing wanna-build? >> >> Access to information about embargoed information would not be ok. > > This is nothing new. It has always been that way. As soon as you have > write access to wanna-build, you can inspect all suites. Yes, that's > somewhat sad, but at the same time it shouldn't give you access to the > actual source packages. So with w-b access one only sees that a package is built for a security archive, but has no access to build logs / binaries / sources? That information can already be seen by accessing debianqueue's log on the security archive upload host. Ansgar
Re: Please help with corebird vs. stretch point release
Cyril Brulebois writes: > Forwarding from IRC where Adam mentioned this a couple of times, we > would love help with corebird for the upcoming stretch point release: > >> please could someone fix up >> queue/reject/corebird_1.4.1-1+deb9u1_amd64.changes >> and reinject it? >> >> I imagine it will need a forget-signature, renaming to _amd64+buildd.changes >> and copying it and its contents back to unchecked. >> >> possible extra fun being both uploads contain an _amd64.buildinfo as >> well... Done now. I didn't see a *.buildinfo in the target directory. So we probably no longer keep it in the archive at that time and it shouldn't need renaming. Ansgar
Re: Scheduling 9.3
On Thu, 2017-11-16 at 08:02 +, Adam D. Barratt wrote: > I believe we still need ftp-master and press confirmation, but I've > been failing at poking. Either of 2017-12-02 or 2017-12-09 should be fine for me. Ansgar
Bug#876313: jessie-pu: package dput/0.9.6.4+deb8u1
"Adam D. Barratt" writes: > On Wed, 2017-09-20 at 22:10 +0200, Ansgar Burchardt wrote: >> I prepared an update for dput to point security uploads to >> ftp.security.upload.d.o instead of security-master.d.o, see >> attached diff. > > Please go ahead. Thanks, uploaded. Ansgar
Re: Missing security builds for ffmpeg, block asterisk
Salvatore Bonaccorso writes: > On Sat, Sep 23, 2017 at 08:13:41PM +0100, Adam D. Barratt wrote: >> On Sat, 2017-09-23 at 20:09 +0100, Jonathan Wiltshire wrote: >> > On Sat, Sep 23, 2017 at 08:05:42PM +0100, Jonathan Wiltshire wrote: >> > > We seem to be missing the following builds of ffmpeg 7:3.2.7- >> > > 1~deb9u1: >> > > >> > > arm64 armel armhf mips64el mipsel ppc64el s390x >> > >> > I lied; that should read: >> > >> > all amd64 i386 mips >> > >> > Sorry for the confusion. >> > >> If it makes things easier, I don't mind re-signing and re-uploading the >> packages if someone could make the .changes files available. > > I resigned and uploaded those, and hopefully right, because I had to > collect the dbgsym packages as well. > > Ideally such operation though is done by ftp-master, which have better > possibilties :) I actually gathered the files a bit earlier today (the signatures were still valid). So your upload should get rejected. It looks like it was the usual problem with files getting sync in the wrong order, same as happened for other uploads recently. Ansgar
Bug#876313: jessie-pu: package dput/0.9.6.4+deb8u1
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu [ X-Debbugs-Cc'ed dput maintainer ] I prepared an update for dput to point security uploads to ftp.security.upload.d.o instead of security-master.d.o, see attached diff. I'll skip on dput-ng as it fails to build from source in Jessie (tests fail with "UnsupportedDistribution: Unsupported release precise"; probably easy to fix, but not motivated). Ansgar diff -Nru dput-0.9.6.4/debian/changelog dput-0.9.6.4+deb8u1/debian/changelog --- dput-0.9.6.4/debian/changelog 2013-07-19 13:08:40.0 +0200 +++ dput-0.9.6.4+deb8u1/debian/changelog2017-09-20 21:32:45.0 +0200 @@ -1,3 +1,10 @@ +dput (0.9.6.4+deb8u1) jessie; urgency=medium + + * dput.cf: replace security-master.d.o with ftp.upload.security.d.o +(Closes: #863348) + + -- Ansgar Burchardt <ans...@debian.org> Wed, 20 Sep 2017 21:32:45 +0200 + dput (0.9.6.4) unstable; urgency=low [ Salvatore Bonaccorso ] diff -Nru dput-0.9.6.4/dput.cf dput-0.9.6.4+deb8u1/dput.cf --- dput-0.9.6.4/dput.cf2013-07-19 11:54:33.0 +0200 +++ dput-0.9.6.4+deb8u1/dput.cf 2017-09-20 21:32:33.0 +0200 @@ -56,7 +56,7 @@ # pre_upload_command = /path/to/some/script [security-master] -fqdn = security-master.debian.org +fqdn = ftp.security.upload.debian.org method = ftp incoming = /pub/SecurityUploadQueue login = anonymous @@ -66,7 +66,7 @@ pre_upload_command = /usr/share/dput/helper/security-warning [security-master-unembargoed] -fqdn = security-master.debian.org +fqdn = ftp.security.upload.debian.org method = ftp incoming = /pub/OpenSecurityUploadQueue login = anonymous
Re: Scheduling 9.2
Jonathan Wiltshire writes: > Ok, does 7th October work any better? I'm keen not to get too far adrift > from the interval though. Should be okay if no other ftpmaster volunteers. Ansgar
Re: Please dak copy-installer 20170828, please force it into testing
Cyril Brulebois <k...@debian.org> writes: > FTPmasters, please sync the installer from sid to testing: > > dak copy-installer 20170828 Done. Ansgar
Re: Please dak copy-installer 20170615
Cyril Brulebois writes: > FTPmasters, please sync the installer from sid to testing: > > dak copy-installer 20170615 Done. > Also, there was no recent clean-up in the sid directory; I think we > could remove everything from 2015. Maybe also everything from 2016, > but I'm tempted to give debian-boot@ people a chance to react in case > images from 2016 should stay a bit longer. Of course this can wait > post-release, no urgency from my point of view. Not done yet, but we should probably also do the clean-up for stretch. Ansgar
Re: Please dak copy-installer 20170608
Cyril Brulebois writes: > FTPmasters, please sync the installer from sid to testing: > > dak copy-installer 20170608 Done. Also removed dists/testing/main/installer-* for non-release architectures. Ansgar
Bug#863816: RM: ksh/93u+20120801-3.1
On Wed, 31 May 2017 14:28:25 +0100 "Adam D. Barratt" wrote: > On 2017-05-31 14:17, Christoph Martin wrote: > > Please remove the recent non-maintainer upload from me of ksh with the > > version 93u+20120801-3.1 . It has the wrong version number since the > > last released version was 93u+20120801-2. [...] > > As soon as this version is removed I'll do a NMU with version -2.1 > > You can't make version numbers of published packages go backwards, > so that would either need an epoch or a "really"-style version > number. Though there really is no need to reupload the package just to correct the version. Just ignore that one version number was skipped. Ansgar
Re: Last chance for d-i changes in stretch
Cyril Brulebois writes: > Didier 'OdyX' Raboud (2017-05-27): >> It also currently uses httpredir.debian.org as only mirror, so we should >> decide if it makes sense to consolidate onto deb.debian.org for win32- >> loader too. > > Unless we're aware of limitations win32-loader might hit on deb.d.o, I'd > go for a transition to this hostname. > > Ditto for d-i-n-i, which I'll check right away. httpredir.d.o seems to be just an alias for deb.d.o these days: I see a "Welcome to deb.debian.org!" page when I open httpredir.d.o in a browser. So changing the mirror from httpredir.d.o to deb.d.o should be very low-risk :-) Ansgar
Re: Please get ready for copy-installer 20170525
Cyril Brulebois writes: > FTPmasters, I've just uploaded d-i 20170525 to the archive, and need to > leave for the day, so it would be nice if you could please sync the > installer from sid to testing when all builds are ready: > > dak copy-installer 20170525 Done. Ansgar
Bug#858163: unblock: gitlab/8.13.11+dfsg-6
Hi,
> You probably want something like:
>
> """
> if su ${gitlab_user} -c 'psql gitlab_production -c ""'; then
> su postgres -c "dropdb gitlab_production"
> fi
> """
I believe maintainer scripts (and various other parts) should use
`runuser` instead of `su`. It does not open PAM sessions which seems
to sometimes cause problems.
`/sbin/runuser` is already available in Jessie, so there should be no
issues with using it.
(Maybe one should add something to Policy about `runuser`?)
Ansgar
Bug#859084: unblock: win32-loader/0.8.2
Didier 'OdyX' Raboud <o...@debian.org> writes: > ftpmaster: please copy debian/tools/win32-loader/unstable into …/testing Done. Ansgar
Re: 8.8 planning
On Tue, 2017-03-14 at 12:00 +0100, Julien Cristau wrote: > It's time to start thinking about our next stable point > release. Here > are some dates, please let us know which ones would work. > > * April 8-9 Not ideal, but should work. > * April 15-16 Only on 16th. > * April 22-23 > * April 29-30 > * May 6-7 These should all be okay. Ansgar
Re: Please dak copy-installer 20170127
Cyril Brulebois writes: > FTPmasters, please sync the installer from sid to testing: > > dak copy-installer 20170127 Done. Ansgar
Re: Release impact of introducing a new archive section?
Josh Triplett writes: > Given that, can you please go ahead and add the two new sections for > rust (https://bugs.debian.org/845576) and javascript > (https://bugs.debian.org/753480), and update the override file for > existing packages? These packages should move to the "rust" section: > rustc, cargo, libstd-rust*, and rust-*. And all packages named > node-*, libjs-*, and javascript-* should move to the "javascript" > section. I've done this now. Ansgar
Bug#845254: unblock: win32-loader/0.8.0
Didier 'OdyX' Raboud writes: > Le lundi, 21 novembre 2016, 23.30:52 h CET Cyril Brulebois a écrit : >> so feel free to let this package get into testing when it's copied over >> by ftpmasters. > > Le lundi, 21 novembre 2016, 21.09:46 h CET Didier 'OdyX' Raboud a écrit : >> 0.8.0 is long overdue in stretch, please let it migrate. ftpmaster: please >> copy debian/tools/win32-loader/unstable into …/testing > > ftpmasters: ping ? tools/win32-loader/testing/ now has win32-loader from Apr 21 2016. Sorry for forgetting about this :/ Ansgar
Bug#848607: nmu: dune-grid-glue_2.5.0~20161206g666200e-2, dune-pdelab_2.5.0~20161204gdb53a76-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please schedule binNMUs for dune-grid-glue and dune-pdelab to have them rebuilt against dune-grid 2.5.0-1. nmu dune-grid-glue_2.5.0~20161206g666200e-2 . ANY . unstable . -m "Rebuild against dune-grid 2.5.0." nmu dune-pdelab_2.5.0~20161204gdb53a76-3 . ANY . unstable . -m "Rebuild against dune-grid 2.5.0." As issues with openmpi on mips64el (#848574) currently prevent building of dune-common and dune-grid 2.5.0, a dep-wait would be nice so the packages might get rebuilt later. dw dune-grid-glue_2.5.0~20161206g666200e-2 . ANY . unstable . -m "libdune-grid-dev (>= 2.5.0)" dw dune-pdelab_2.5.0~20161204gdb53a76-3 . ANY . unstable . -m "libdune-grid-dev (>= 2.5.0)" Ansgar
Re: dbgsym packages and stretch-as-stable
Hi, "Adam D. Barratt" writes: > Apologies if I missed something in earlier discussions, but how are > automagic debug packages and uploads to stable expected to interact? > > Will there need to be stable-new-dbgsym and pu-dbgsym suites, or will > the packages sit in stable-new and pu alongside the rest of the binary > packages and then move to stable-debug at the point release? The current implementation for policy queues has the -dbgsym packages in the same policy queue (i.e. stable-new). Once they are accepted they should go to a new proposed-updates-debug suite (in the debian-debug archive) and from there into stable-debug (at point release time). Ansgar
Re: Please dak copy-installer 20161027
Cyril Brulebois writes: > FTPmasters, please sync the installer from sid to testing: > > dak copy-installer 20161027 Done. Can we remove older version from testing and unstable? Ansgar
Re: 8.6 planning
On Sun, 2016-08-07 at 23:04 +0100, Adam D. Barratt wrote: > It's time for another Jessie point release; as wheezy's EOL, we don't > have to worry about trying to fit two in at the same time. Some > possible > dates: > > August 20th/21st - doesn't work for me > > August 27th/28th - public holiday weekend in the UK; doesn't work for > me These don't work for me either. (Also they are probably too close by now.) > September 3rd/4th Might work with some extra planning, but not that well. > September 10th/11th > > September 17th/18th These should be okay for me. Ansgar
Re: Please dak copy-installer 20160630
Cyril Brulebois <k...@debian.org> writes: > FTPmasters, please sync the installer from sid to testing (it's been > Installed on all archs already, ISTR it's sufficient): > > dak copy-installer 20160630 Done. Ansgar
Re: Please dak copy-installer 20160516
Cyril Brulebois writes: > Thanks, please rerun with the binNMU now so that we get the > brltty/espeakup fixes for Stretch Alpha 6: > > dak copy-installer 20160516+b1 Done. Ansgar
Re: Please dak copy-installer 20160516
Cyril Brulebois <k...@debian.org> writes: > FTPmasters, please sync the installer from sid to testing: > > dak copy-installer 20160516 Done. Thanks for your work on d-i, Ansgar
Re: arch all package's missing dependency on i386 prevents testing migration
Neil Williams <codeh...@debian.org> writes: > On Tue, 29 Mar 2016 21:25:26 -0700 > Afif Elghraoui <a...@ghraoui.name> wrote: >> The package in question, circlator, depends on two >> architecture-dependent packages that can only build on amd64 and >> kfreebsd-amd64 currently. The package cannot migrate to testing >> because those dependencies are not available for i386 [1]. >> >> I am hoping there is a better solution to this problem than to work >> around this by changing this package's build architecture from "all" >> to "any-amd64" > > That's not a workaround, it is the correct fix for the error in the > original upload. The package cannot work on all architectures - the > fact that this is because of dependencies rather than the code within > the package is irrelevant. Unless the code in the package can > *transparently* omit the need for the dependency on architectures where > that dependency does not exist, then the package is not arch:all. > Installation alone is insufficient, the package needs to be usable on > all the architectures in the Architecture list. No. It is arch:all if it contains no arch-specific binaries and doesn't require arch-specific dependencies (i.e. dependencies which should only appear on specific architectures like "foo [amd64]"). It should be fine if an arch:all package depends on binary packages that are not installable on all architectures. Otherwise a lot of arch:all packages that depend on, say, linux-specific binary packages would become arch:any which is not very useful. As far as I remember, the testing migration script checks installability of arch:all packages on amd64 and i386, and there are manual workarounds for arch:all packages that are not installable on these architectures. Cc'ed the release team to take a look too. Ansgar
Bug#816292: nmu: dune-grid-glue_2.4.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please schedule a binNMU for dune-grid-glue to rebuild the package against the DUNE 2.4.1 libraries. nmu dune-grid-glue_2.4.0-1 . ANY . unstable . -m "Rebuild against DUNE 2.4.1." dw dune-grid-glue_2.4.0-1 . ANY . unstable . -m "libdune-grid-dev (>= 2.4.1)" Ansgar
Re: 8.4 and 7.10 planning
"Adam D. Barratt" writes: > We're due both Jessie and Wheezy point releases, and are proposing doing > both on the same weekend again, as we did for 8.2 and 7.9, as the CD > team seem happy to try it again. > > Some suggested dates: > > March 12th / 13th > March 19th / 20th > April 2nd / 3rd These all look fine for me. > March 26th / 27th - Easter, holiday weekend in at least the UK Not good. Ansgar
Bug#812977: nmu: ceph_0.80.11-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, somebody reported to ftpmaster@ that two mipsel binaries are corrupt: ceph-test-dbg_0.80.11-1_mipsel.deb and qgis-dbg_2.8.4+dfsg-1_mips64el.deb > $ dpkg-deb --extract ./ceph-test-dbg_0.80.11-1_mipsel.deb . > dpkg-deb (subprocess): decompressing archive member: lzma error: compressed > data is corrupt > tar: Unexpected EOF in archive > tar: Unexpected EOF in archive > tar: Error is not recoverable: exiting now > dpkg-deb: error: subprocess tar returned error exit status 2 This can also be seen in the build log[1] (at the end where package contents are listed). I have no idea what caused this, but assume it might have been some temporary error for now. Please try rebuilding the package. nmu ceph_0.80.11-1 . mipsel . unstable . -m "Rebuild ceph-test-dbg which was corrupted in the previous build." qgis has already been superseded by a newer version in unstable and the newer build log no longer shows the error. Ansgar [1] <https://buildd.debian.org/status/fetch.php?pkg=ceph=mipsel=0.80.11-1=1453099724>
Bug#812500: jessie-pu/nmu: package user-mode-linux/3.16-1um-0.1+b2
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu As user-mode-linux was suggested for removal in #-devel, I was reminded that the package in stable probably should be rebuilt against the current version of the linux sources. u-m-l 3.16-1um-0.1+b1 has Built-Using: linux (= 3.16.7-ckt7-1) but the current version of the Linux kernel in stable is 3.16.7-ckt20-1+deb8u2. I guess this means u-m-l misses several security updates. Ansgar
Re: 8.3 planning
On Sun, 2015-12-13 at 17:22 +, Adam D. Barratt wrote: > On Sun, 2015-12-06 at 16:10 -0500, Donald Norwood wrote: > > On 12/04/2015 01:12 PM, Steve McIntyre wrote: > > > On Fri, Dec 04, 2015 at 05:43:54PM +, Adam Barratt wrote: > > > > On that basis, looking at January we have: > > > > > > > > 2nd/3rd - depends how much people are still suffering. :-) > > > No chance for me that weekend - I've got plans already. > > > > > > > 9th/10th > > > > 16th/17th > > > > 23rd/24th - likely to be bad for me > > > All of these look OK so far. > > > > > Press can do 16/17 or 23/24. > > Just missing ftp-master then - ping :-) Both 16/17 or 23/24 should be fine for me. Not quite sure about 9/10th. Ansgar
Re: Please dak copy-installer 20151023
Cyril Brulebois <k...@debian.org> writes: > FTPmasters, please sync the installer from sid to testing: > > dak copy-installer 20151023 Done. Ansgar
Bug#800582: nmu: dune-grid-glue_2.4~20150723gd6e4c74-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, dune-grid-glue needs to be rebuild against the DUNE 2.4.0 release. Please schedule a binNMU. nmu dune-grid-glue_2.4~20150723gd6e4c74-2 . ALL . -m "Rebuild against DUNE 2.4.0." Ansgar
Re: Please dak copy-installer 20150911
Cyril Brulebois <k...@debian.org> writes: > FTPmasters, please sync the installer from sid to testing: > > dak copy-installer 20150911 Done. Ansgar
Re: Please dak copy-installer 20150828 hint it into testing
Cyril Brulebois k...@debian.org writes: FTPmasters, please sync the installer from sid to testing: dak copy-installer 20150828 Done. Ansgar
Re: 8.2 and 7.9 planning
Adam D. Barratt a...@adam-barratt.org.uk writes: We're somewhat overdue for both 8.2 and 7.9 now (in that order). Some potential September dates: 5/6th - okay for me Should be okay, provided I get internet on Aug 31st as planned. 12/13th - the 12th doesn't work for me until at least mid-afternoon 19th/20th - looks okay 26th/27th - looks okay Work might interfere with these a bit (might have a meeting on the day before, though currently it looks like it might be in October). I would only be available on Saturday afternoon and Sunday. Ansgar
Re: Please dak copy-installer 20150813 hint it into testing
Cyril Brulebois k...@debian.org writes: FTPmasters, please sync the installer from sid to testing: dak copy-installer 20150813 Done. Thanks for your work on d-i, Ansgar
Re: Please dak copy-installer 20150718 hint it into testing
Cyril Brulebois k...@debian.org writes: FTPmasters, please sync the installer from sid to testing: dak copy-installer 20150718 Done. Ansgar -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r3o53ox4@deep-thought.43-1.org
Re: Please copy tools/win32-loader/unstable to .../testing
Hi, Adam D. Barratt a...@adam-barratt.org.uk writes: As discussed with OdyX, please copy the current version of tools/win32-loader from unstable/ to testing/. We'll then unblock the source package, so that we can get it migrated before the 8.1 point release (which includes a version of win32-loader that's newer than the current version in testing). Just did so. Ansgar -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87a8wjg9gm@deep-thought.43-1.org
Bug#786500: nmu: alberta_3.0.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, libalberta uses a relocation type that should not be used for shared libraries on powerpc[1] which makes the library unusable. As the build log looked okay to me and the older version (3.0.0-3) worked, I tried rebuilding the package on partch.d.o and the bad relocations disappeared... At least readelf -a no longer showed any occurence of R_PPC_REL24. I'm wondering if this was some issue with an older version of the toolchain; note that alberta uses clang instead of gcc as gcc has a bug (see link in [1]). Could you please schedule a binNMU for alberta on powerpc to get it rebuilt with the current toolchain? Please also consider giving back dune-grid/2.4~20150506gd3c1350-1 on powerpc in experimental with an additional build-dep on the binNMU'ed libalberta-dev (= 2.3.1-1+b1) Ansgar nmu alberta_3.0.1-1 . powerpc . -m Rebuild with current toolchain. gb dune-grid_2.4~20150506gd3c1350-1 . powerpc . experimental dw dune-grid_2.4~20150506gd3c1350-1 . powerpc . experimental -m libalberta-dev (= 2.3.1-1+b1) (Not sure if gb/dw are correct like this.) [1] https://lists.debian.org/debian-powerpc/2015/05/msg00061.html -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150522100215.16327.85829.report...@snout.igpm.rwth-aachen.de
Bug#779878: nmu: binutils-z80_4 binutils-mingw-w64_5.1 binutils-arm-none-eabi_5 possibly others
On 05/19/2015 07:04 PM, Emilio Pozuelo Monfort wrote:
On 05/03/15 22:45, Ansgar Burchardt wrote:
as I saw binutils_2.25-5 got unblocked, I was wondering weather the
binutils-* packages built from binutils-source should be rebuilt
aginst the new version targeting Jessie?
There are binutils-{z80,mingw-w64,arm-none-eabi} currently in the
archive and built against older versions of binutils (cf. [1]).
The gcc-{arm-non-eabi,mingw-w64} packages are in the same situation,
so are gdb-{arm-none-eabi,avr,mingw-w64} (though for some of the
latter only the Debian revision of gdb changed).
Finally there's also gnat-4.9.
nmu binutils-z80_4 . ALL . -m Rebuilt against binutils 2.25-5.
nmu binutils-mingw-w64_5.1 . ALL . -m Rebuilt against binutils 2.25-5.
nmu binutils-arm-none-eabi_5 . ALL . -m Rebuilt against binutils 2.25-5.
These three happened in time for jessie.
gnat-4.9 didn't. It was built against gcc-4.9_4.9.2-2, but we only ship
gcc4-.9_4.9.2-10 in stable AFAICS. That seems odd.
I haven't checked gcc-*. Is this such an issue that we should do the binNMUs
for
stable?
I don't think so. It might have been worth doing so before the release
to make sure an eventual rebuild doesn't bring surprises, but it's too
late for that.
Ansgar
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/555f3c8a.3010...@debian.org
Re: Please dak copy-installer 20150422 hint it into testing
Cyril Brulebois k...@debian.org writes: FTPmasters, please sync the installer from sid to testing: dak copy-installer 20150422 Done. Thanks for your work on d-i! Ansgar -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87k2x3z4ci@deep-thought.43-1.org
Re: Please dak copy-installer 20150418 hint it into testing
Hi, Cyril Brulebois k...@debian.org writes: FTPmasters, please sync the installer from sid to testing: dak copy-installer 20150418 Just did that. I suppose we need to wait for a dinstall to actually install stuff from buildds, and another one after copy-installer is run? Or is it possible to have copy-installer now and 1352 to propagate changes right after that? I don't think there is need to wait for dinstall: everything is installed by the unchecked runs; dinstall just updates indices and does housekeeping. Well, and mirror pushes of course. Ansgar -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wq19blx0@deep-thought.43-1.org
Re: Proposal to do regular jenkins updates via jessie-updates
Hi,
Adam D. Barratt a...@adam-barratt.org.uk writes:
On Wed, 2015-04-08 at 23:33 +0200, Niels Thykier wrote:
On 2015-04-08 22:45, Miguel Landaeta wrote:
Do you think is feasible or acceptable to maintain Jenkins in
jessie-updates suite instead?
I am not entirely convinced that Jenkins applies to stable-updates
criteria[1]. However, I am leaving the final call on that to the SRMs.
As someone who was involved in the initial setup of stable-updates, I'm
afraid that I'm not convinced either.
[...]
https://wiki.jenkins-ci.org/display/JENKINS/LTS+Release+Line suggests
that long-term means supported for three months. I'm struggling to
combine those two ideas, particularly in the context of a Debian stable
release. (Similarly battle-tested — meaning those commits that have
already been a part of a main line release for more than a week.)
I do wonder whether backports might be suitable, but I can't and won't
speak on behalf of the backports team.
From my understanding, packages in ${x}-backports must be included in
the ${x+1} release. For a package like Jenkins this currently doesn't
seem possible, so it cannot go to backports either.
So it looks to me like we currently miss a place to offer a package like
Jenkins to stable users, but it would be nice to have one as I believe
there will be more packages in this situation in the future (even though
we might not like this).
I do wonder a bit how much this is different from Iceweasel or Chromium
however: there we also ship new upstream releases to stay at a supported
version (though the life-time for Jenkins seems even shorter). Of course
this only works as long as no new dependencies are pulled in, or at
least stay at something managable.
Ansgar
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87oamx203n@deep-thought.43-1.org
Re: Please dak copy-installer 20150324 hint it into testing
Cyril Brulebois k...@debian.org writes: FTPmasters, please sync the installer from sid to testing: dak copy-installer 20150324 Done. Ansgar -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnjg9q62@deep-thought.43-1.org
Bug#779878: nmu: binutils-z80_4 binutils-mingw-w64_5.1 binutils-arm-none-eabi_5 possibly others
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Hi,
as I saw binutils_2.25-5 got unblocked, I was wondering weather the
binutils-* packages built from binutils-source should be rebuilt
aginst the new version targeting Jessie?
There are binutils-{z80,mingw-w64,arm-none-eabi} currently in the
archive and built against older versions of binutils (cf. [1]).
The gcc-{arm-non-eabi,mingw-w64} packages are in the same situation,
so are gdb-{arm-none-eabi,avr,mingw-w64} (though for some of the
latter only the Debian revision of gdb changed).
Finally there's also gnat-4.9.
nmu binutils-z80_4 . ALL . -m Rebuilt against binutils 2.25-5.
nmu binutils-mingw-w64_5.1 . ALL . -m Rebuilt against binutils 2.25-5.
nmu binutils-arm-none-eabi_5 . ALL . -m Rebuilt against binutils 2.25-5.
Ansgar
[1] https://ftp-master.debian.org/users/ansgar/outdated-built-using.txt
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20150305214534.30773.56314.report...@deep-thought.43-1.org
Bug#776360: nmu: user-mode-linux_3.16-1um-0.1
Control: tag -1 - moreinfo On 01/27/2015 07:48 PM, Niels Thykier wrote: On 2015-01-27 09:53, Ansgar Burchardt wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, user-mode-linux is built against an old kernel version (3.16.5-1). I think it should be rebuilt against the current version before release. nmu user-mode-linux_3.16-1um-0.1 . ALL . -m Rebuilt against linux 3.16.7-ckt4-1. The current version of the kernel FTBFS on arm64, so we might see a newer version of Linux. linux 3.16.7-ckt4-2 fixed the FTBFS on arm64 (already built there). The new version is also already installed on i386 and amd64, the only two architectures user-mode-linux is available for. Ansgar -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54c8bddb.5040...@debian.org
