Bug#1070472: Uses the obsolete /sbin/route without a dependency

Package: miniupnpd Version: 2.3.1-1 Severity: serious Tags: patch Pseudo-patch for miniupnpd.config: - MiniUPnPd_EXTERNAL_INTERFACE=$(LC_ALL=C /sbin/route | grep -m 1 default | awk -- '{ print $8 }') + MiniUPnPd_EXTERNAL_INTERFACE=$(LC_ALL=C ip -o route show | sed -nre '/^default

Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod

On Apr 26, Michael Tokarev wrote: > So, should I disable module utils in busybox-udeb now? I think so. > Is kmod udeb ready and used in d-i already, or does it need some > prep first? AFAIK it works. -- ciao, Marco signature.asc Description: PGP signature

Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod

On Jan 06, Michael Tokarev wrote: > Yes, some utils in busybox aren't as good as regular implementations. For Yes. Nowadays kmod has many more features related to compressed modules and verification of signatures. Can we agree that kmod should provide these programs for d-i? Or can the d-i

Bug#1056156: varnish: CVE-2023-44487: VSV00013 Varnish HTTP/2 Rapid Reset Attack

Control: found -1 5.0.0-1 Control: fixed -1 7.4.2 On Nov 17, Salvatore Bonaccorso wrote: > CVE-2023-44487[0]: > | The HTTP/2 protocol allows a denial of service (server resource > | consumption) because request cancellation can reset many streams > | quickly, as exploited in the wild in August

Bug#1063804: FTBFS: depmod: FATAL: could not search modules: No such file or directory

On Feb 12, Salvatore Bonaccorso wrote: > --with-module-directory=/usr/lib/modules > > Looping in Marco for comments. I can revert it if it causes too much trouble, but maybe this is just the right time to switch the kernel packages to /usr/lib/modules/ as well? Please let me know if I am

Bug#1063476: the sanesecurity configuration is not suitable for a release

Source: fangfrisch Version: 1.7.0-1 Severity: grave Tags: upstream Control: forwarded -1 https://github.com/rseichter/fangfrisch/issues/30 The sanesecurity section of default configuration, if enabled, relies on an unofficial HTTP mirror which is seriously overloaded and probably seriously

Bug#1043456: tecla: shows nothing and segfaults on keypress

On Sep 07, Jeremy Bícha wrote: > This popup window is Tecla. Does it work correctly? This way it does not crash anymore. Still, it should be fixed to either not crash or not start if it can only be called by gnome-control-center. (BTW, it does not react to left-alt, while it correctly reports

Bug#1043456: tecla: shows nothing and segfaults on keypress

Control: reopen -1 Still broken. ||/ Name Version Architecture Description +++-==---==> ii tecla 45~rc-1 amd64keyboard layout viewer for the GNO> [Thread debugging using libthread_db

Bug#1050586: kmod: Updating to kmod to 30+20230601-1 results in a non booting system modules cannot be decompressed

Control: retitle -1 kmod does not work with XZ in-kernel module decompression On Aug 27, Jon Westgate wrote: > Note that I already had "Support in-kernel module decompression" selected > when the compression method was XZ. > > Would you like me to try without it? No need to: we know that

Bug#1050586: kmod: Updating to kmod to 30+20230601-1 results in a non booting system modules cannot be decompressed

On Aug 26, Jon Westgate <0...@fsck.tv> wrote: > The error message it gave was "decompresson failed with status 6" Status 6 is XZ_OPTIONS_ERROR, which means "Input was encoded with settings that are not supported by this XZ decoder". So it looks like you have compressed the modules (how?) with XZ

Bug#1050586: kmod: Updating to kmod to 30+20230601-1 results in a non booting system modules cannot be decompressed

On Aug 26, Jon Westgate wrote: > Yes I am using compressed modules And are these modules compressed with xz or something else? This new code was introduced in the latest snapshot, and apparently it fails when used with kernels with compressed modules support enabled (which so far is not the

Bug#1050586: kmod: Updating to kmod to 30+20230601-1 results in a non booting system modules cannot be decompressed

On Aug 26, Jon Westgate <0...@fsck.tv> wrote: > Kernel: Linux 6.4.11 (SMP w/12 CPU threads; PREEMPT) I see that you are using a custom kernel. What is the status of the CONFIG_MODULE_COMPRESS_* kernel configuration options? -- ciao, Marco signature.asc Description: PGP signature

Bug#1050582: kmod update corrupts systemd uefi boot

On Aug 26, antonio wrote: > Kernel: Linux 6.4.12-1-liquorix-amd64 (SMP w/24 CPU threads; PREEMPT) I see that you are using a custom kernel. What is the status of the CONFIG_MODULE_COMPRESS_* kernel configuration options? -- ciao, Marco signature.asc Description: PGP signature

Bug#1050586: kmod: Updating to kmod to 30+20230601-1 results in a non booting system modules cannot be decompressed

On Aug 26, Jon Westgate <0...@fsck.tv> wrote: > The system partially booted but systemd then prevented boot due to missing > modules, > The error message it gave was "decompresson failed with status 6" Are you using compressed modules? -- ciao, Marco signature.asc Description: PGP signature

Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/

On May 29, Luca Boccassi wrote: > Does it matter that much if the empty directory is removed? Next time > a package shipping a modules-load config is installed it will be just > re-added, no? Or are there functional issues? I do not think that it is a big deal if /usr/lib/modules-load.d/

Bug#1034958: Consequence of #951598

On Apr 29, Helge Kreutzmann wrote: > Reverse, I believe manpages-dev should declare: > Breaks: inn2-dev (<< 2.7.0-1) > Replaces: inn2-dev (<< 2.7.0-1) > > Is this fine for you? Yes. -- ciao, Marco signature.asc Description: PGP signature

Bug#1035098: Bug#1034958: Consequence of #951598

Would this work for you? Please let me know ASAP since the hard freeze is very close. Package: inn2-dev Breaks: manpages-dev (<< 6.03-2) -- ciao, Marco signature.asc Description: PGP signature

Bug#1034081: openbgpd: FTBFS twice in a row: src/bgpd/parse.c cannot be regenerated

On Apr 08, Andreas Beckmann wrote: > Justification: fails to build from source twice in a row This can be fixed by adding a build-dependency on yacc. > openbgpd/experimental fails to build twice in a row. (I haven't checked > whether the version in sid has the same problem.) It does: should I

Bug#1034346: usrmerge: fails to install on Xen VPS due to /lib/modules mount

Control: severity -1 normal On Apr 13, Hans-Christoph Steiner wrote: > I have some VPSes which are based on Xen, so the kernel comes from the host, > and the VPS has no kernel installed. /lib/modules is mounted but not via > /etc/fstab. When trying to upgrade from bullseye to bookworm, I get:

Bug#1033167: usrmerge: messes with /etc/shells

On Mar 18, Helmut Grohne wrote: > I think that it is quite obvious that /etc/shells is debianutils' > territory. When I found that on some systems /etc/shells was out of sync > with /var/lib/shells.state, I was quite puzzled until I noticed that > usrmerge messes with this file. This really is

Bug#1030669: Only include in Bookworm with commitment to stable updates

On Feb 02, Moritz Muehlenhoff wrote: > Varnish should only be included in Bookworm with a reliable commitment > by the maintainers to backport/test security fixes across the typical > three year life cycle (two years of stable-security and one year of > oldstable-security). I do not think that

Bug#1029447: unmuting audio breaks video playing in browsers

Package: wireplumber Version: 0.4.13-1 Severity: grave If I replace pipewire-media-session with wireplumber then playing video in browsers (e.g. Youtube and other similar sites, or even just embedded tags) stutters and stops. Just pressing the mute button in the video player makes video work

Bug#1027760: gortr appears to be unmaintained

Control: severity -1 important Control: affects -1 cfrpki On Jan 03, Marco d'Itri wrote: > gortr has not been updated upstream in over two years and probably most > users at this point have switched to stayrtr for good. But cfrpki build-depends on golang-github-cloudflare-gortr-dev, so

Bug#1027760: gortr appears to be unmaintained

Source: gortr Version: 0.14.7-1 Severity: serious Tags: upstream gortr has not been updated upstream in over two years and probably most users at this point have switched to stayrtr for good. Lacking new facts I do not want it in bookworm and I will probably request its removal during the

Bug#1025739: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

On Dec 09, Andreas Tille wrote: > I would consider asking upstream about this for sure but the code is in > maintenance mode and there is no Git repository to step back in history. > The only way to go would be to take configure.ac from a later version > and find out how it can be tweaked to

Bug#1023258: uses com.sun.org.apache.xml.internal.serialize

Package: pcalendar Version: 3.4.1-4 Severity: grave Tags: upstream I understand that com.sun.org.apache.xml.internal.serialize was an internal JDK class which is not available anymore. When saving, it crashes with this error and DESTROYS the original file: Exception in thread

Bug#1013554: golang-github-valyala-tcplisten: FTBFS: dh_auto_test: error: cd _build && go test -vet=off -v -p 8 github.com/valyala/tcplisten returned exit code 1

On Jul 30, Mathias Gibbens wrote: > Feel free to apply it directly yourself. :) If this does fix the > issue, it would probably be good to contact Lucas and see if we can > figure out what in the rebuild setup needs to be tweaked to ensure that > "ip6-localhost" is properly resolvable. This

Bug#926699: Transition to usrmerge has started

On Sep 19, Andreas Beckmann wrote: > Shouldn't that fail in such a broken environment? Definitely yes, I will have a look later today. The main issue can only be fixed in the libc packages (which would be wonderful, because then we could stop creating the biarch links and directories on all

Bug#1014114: installation of crypt.h in the multiarch location breaks the GCC and LLVM multilib builds

On Jun 30, Helmut Grohne wrote: > Assuming that, we basically have the two options above: > * Move crypt.h back for all multilib architectures only. > * Add multilib packages. > > Marco, do you have any preference here? I do not want to add any more complexity than what is strictly required

Bug#1014114: installation of crypt.h in the multiarch location breaks the GCC and LLVM multilib builds

On Jun 30, Matthias Klose wrote: > installation of crypt.h in the multiarch location breaks the GCC and LLVM > multilib builds. > > For libsanitizer, crypt.h is needed to determine the size of a struct, the > library itself is not needed. Moving it to the MA location makes it > unavailable for

Bug#1010244: does not work with PHP 8.1

Package: phpsysinfo Version: 3.2.5-3 Severity: grave Tags: upstream phpsysinfo fails with: Fatal error: __autoload() is no longer supported, use spl_autoload_register() instead in /usr/share/phpsysinfo/includes/autoloader.inc.php on line 25 This has been fixed in a more recent upstream

Bug#1009043: dpkg-fsys-usrunmess abuses "Protected: yes" status

Package: dpkg Version: 1.21.0 Severity: serious The dpkg-fsys-usrunmess program installs a dpkg-fsys-usrunmess package which maliciously abuses the Protected and Conflicts/Replaces/Provides fields to prevent installing again the usrmerge package:

Bug#1006330: broken by python3-distro 1.7.0-1

Package: ansible-mitogen Version: 0.3.1-2 Severity: grave Tags: upstream Works with 1.6.0-2, is totally broken with 1.7.0-1. [mux 685121] 14:38:50.354759 D mitogen: PkgutilMethod(): loading 'ansible.module_utils.distro' using <_frozen_importlib_external.SourceFileLoader object at

Bug#1004253: broken for BIND in stable

Package: prometheus-bind-exporter Version: 0.4.0+ds-1+b5 Severity: grave It just does not work due to https://github.com/prometheus-community/bind_exporter/issues/96: Jan 23 16:31:43 dns2 prometheus-bind-exporter[14800]: level=error ts=2022-01-23T15:31:43.292Z caller=bind_exporter.go:427

Bug#998108: firefox freezes shortly after start

On Nov 11, ‍小太 wrote: > If you open /usr/lib/firefox/libxul.so in a hex editor and go to file offset > 0x46a4703, you can perform a find and replace with the below hex strings: > find:498B5C2408904889DFFF157FBD9703EBF5 > replace: 4D8B6C2408904C89EFFF157FBD9703EBDA Great work! Quick one

Bug#998108: firefox freezes shortly after start

On Nov 06, dirdi wrote: > As a first step it would be good to have a method - e.g. a crafted > HTML page - to crash firefox instantly and reproducible. This would > enable us to bisect the changes between 93.0-1 and 93.0-1+b1. I do not think that this would be possible because after restarting

Bug#995308: libcrypt1: symlink points to libpthread

Maybe then the glibc people know what could make ldconfig create a link to the wrong library. On Sep 30, shichimohedron wrote: > >Does it still happen after something like this? > > > mv /usr/sbin/ldconfig /usr/sbin/ldconfig.old > > cp -a /bin/true /usr/sbin/ldconfig > > dpkg -i

Bug#995308: libcrypt1: symlink points to libpthread

On Sep 29, Flying Sea Buckthorn wrote: > Curiuosly enough, I found out that the symlink that should have been > pointing to crypto library (/lib/x86_64-linux-gnu/libcrypto.so.1 -> > libcrypto.so.1.1.0) pointed to libpthread.so.1 instead since upgrade. Is this about libcrypto.so.1 or

Bug#987130: libcrypt-dev makes sysvinit FTBFS: ./src/sulogin.c:978: undefined reference to `crypt'

On Apr 18, Helmut Grohne wrote: > One aspect to this certainly is that the .pc files are now located in > /lib, which is wrong as pkg-config does not search that directory. I've I am not even sure that there is any point in having a .pc file for libcrypt (and I highly doubt that anything uses

Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

On Apr 14, Paul Gevers wrote: > The patch looks sensible after reading the discussion in these bugs. Can > we have an upload soon to have exposure? Unless there are any objections I will do a libxcrypt upload in a couple of days. I think that I can leave the udeb library in /usr/lib/. --

Bug#985311: libxcrypt migration blocker: inappropriate Build-Dependency: libltdl-dev during freeze

On Mar 15, Helmut Grohne wrote: > As a workaround, I propose vendoring ltdl.m4. It is not uncommon to Will do. > As a long term solution, I propose demoting the libc6-dev -> > libxcrypt-dev dependency to Recommends. Doing so shrinks the expectation > of what build-essential provides. It should

Bug#979231: the new mailcap entry breaks mutt

On Jan 04, Vagrant Cascadian wrote: > Removal sounds like a reasonable fix as well, although there are a > handful of reverse dependencies of various forms: > > $ apt rdepends a2ps > a2ps > Reverse Depends: > Depends: apsfilter QA > Recommends: magicfilter QA > Suggests: jed-extra barely

Bug#979231: the new mailcap entry breaks mutt

Package: a2ps Version: 1:4.14-6 Severity: critical Tags: newcomer X-Debbugs-Cc: vagr...@debian.org The recent NMU of a2ps converted the package to dh, and this enabled dh_installmime which was present in debian/rules but commented. The installed file adds to mailcap an entry for "text/plain",

Bug#978489: missing dependency on qml-module-qtquick-controls

Package: linphone-desktop Version: 4.2.5-2 Severity: grave Or else linphone will crash with: [00:50:46:566][0x5618e548aed0][Info]app/App.cpp:784: "Open Linphone app." [00:50:46:566][0x5618e548aed0][Info]app/App.cpp:225: "Creating subwindow: `qrc:/ui/views/App/Calls/CallsWindow.qml`."

Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

On Nov 19, Sven Joachim wrote: > I am not one of them, but AFAICS that would introduce a fatal circular > dependency between libc6 and libcrypt1: libc6 needs libcrypt1 to be > configured before it can be unpacked, but libcrypt1 depends on libc6 so > it cannot be configured before libc6 is at

Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

On Nov 16, Niko Tyni wrote: > As to the fix, I suspect we need a pre-dependency from libc6 to libcrypt1 > for one release cycle, so that libc6 cannot be unpacked before libcrypt1 > is fully installed. I think that Niko is right, so I would like to know the opinion of the glibc maintainers. --

Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

On Nov 14, Dominic Hargreaves wrote: > This seems to be same as #953562 which was reported in March. Why do you think that this is the same? -- ciao, Marco signature.asc Description: PGP signature

Bug#953952: kmod: libkmod2-udeb contains binary instead of libraries

libkmod.so.2 -> libkmod.so.2.3.5 Package: kmod-udeb Source: kmod Version: 27-3 Architecture: amd64 Maintainer: Marco d'Itri Installed-Size: 133 Depends: libc6-udeb (>= 2.30) Section: debian-installer Priority: important Description: libkmod shared library This is a mini

Bug#953562: Possibly causes unbootable state

On Mar 15, Timo Kluck wrote: > Thanks for the suggestion. I ended up doing something similar in > parallel (apologies for ubuntu-specific instructions): Then this is not interesting. -- ciao, Marco signature.asc Description: PGP signature

Bug#953562: Possibly causes unbootable state

On Mar 15, Timo Kluck wrote: > I'll attempt to recover with a live cd and can post updates here if that's > useful. chroot and run ldconfig, for a start. -- ciao, Marco signature.asc Description: PGP signature

Bug#953952: kmod: libkmod2-udeb contains binary instead of libraries

On Mar 14, Aurelien Jarno wrote: > The binaries should probably be moved to a different package like > kmod-udeb, as they conflict with busybox-udeb. Right now the kmod ones > are used, but it depends on the unpack order. Good to know after 8 years! Should I bother at all building a kmod-udeb

Bug#953958: Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless

On Mar 15, John Paul Adrian Glaubitz wrote: > Do you have a patch handy, then I'll fix the package manually for the time > being for ia64 only? Just edit debian/patch_libtool. Let me know if it works and I will apply the change. -- ciao, Marco signature.asc Description: PGP signature

Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless

On Mar 14, John Paul Adrian Glaubitz wrote: > This actually causes issues on ia64 now: Why do you believe that this is the cause? > /usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot > open shared object file: No such file or directory Is this cured by manually running

Bug#953562: libcrypt1 should ship file in /usr, breaks is useless

On Mar 10, Julian Andres Klode wrote: > It likely works out fine in practice in most cases, but > let's be safe, k? Do you care enough to test a patch? -- ciao, Marco signature.asc Description: PGP signature

Bug#952399: OpenSSL linking without license exception

On Feb 26, Michael Biebl wrote: > Doesn't really help to add such a license exception as you also need to > consider users of libkmod and check the rdep tree recursively. > > Imho the only sane way to deal with this is to treat OpenSSL as a system > library and apparently other distros with

Bug#952399: OpenSSL linking without license exception

Control: found 26+20191223-1 On Feb 23, Bastian Germann wrote: > All of the GPL-2+ licensed executables contained in the kmod binary > package link to libcrypto even though they do not have any OpenSSL > license exception. ftp-master considers this a serious issue. So please > remove this

Bug#948318: openssh-server: Unable to restart sshd restart after upgrade to version 8.1p1-2

On Jan 20, Russ Allbery wrote: > This also implies that there is arguably an SONAME issue with this library > given that two versions of the library with the same SONAME don't provide > the same symbols, but I suspect there were really, really good reasons to > not change the SONAME. The

Bug#948318: openssh-server: Unable to restart sshd restart after upgrade to version 8.1p1-2

On Jan 07, Guillaume Brocker wrote: > janv. 06 11:10:46 sigismund sshd[27148]: /usr/sbin/sshd: > /lib/i386-linux-gnu/libcrypt.so.1: version `XCRYPT_2.0' not found (required > by /usr/sbin/sshd) Does purging libxcrypt1 make it work? If you can confirm this then I will make the next libcrypt1

Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_N1a1Mk/lib/modules/5.4.0-1-amd64/modules.builtin.bin'

Control: severity -1 normal Control: tags -1 patch Control: reassign -1 initramfs-tools On Jan 06, crvi wrote: >* What outcome did you expect instead? > > Successful ramfs generation Do you have any reason to believe that the initrfamfs was not generated successfully? This is only

Bug#947780: libcrypt1: keep from migrating to testing until libcrypt{,1}-dev situation is fixed in glibc

On Dec 30, Thorsten Glaser wrote: > ① it won’t migrate as-is currently anyway, because it needs > a new source-only upload and piuparts fails testing, though > the latter might be due to the glibc issue maybe? No, this is an unrelated piuparts bug which was fixed yesterday. -- ciao, Marco

Bug#946599: libcrypt1: failure to switch from libc6 to libcrypt1 hoses the whole system

Since nobody else managed to reproduce this so far I am inclined to demote the bug to "important" to allow the migration to testing. -- ciao, Marco signature.asc Description: PGP signature

Bug#946856: Breaks d-i at runtime due to dependency loop with libc6-udeb

The fixed package is currently in NEW. -- ciao, Marco signature.asc Description: PGP signature

Bug#946856: Breaks d-i at runtime due to dependency loop with libc6-udeb

On Dec 16, Steve McIntyre wrote: > Some testing of this in a d-i environment would have been nice. :-( Is there a practical way to do this (i.e. without rebuilding half of d-i)? The new package was discussed on debian-boot@. -- ciao, Marco signature.asc Description: PGP signature

Bug#946563: there is no need for a versioned libxcrypt1-dev package

On Dec 11, Marco d'Itri wrote: > On Dec 11, Matthias Klose wrote: > > > there is really no need for a versioned libxcrypt1-dev package. Please > > rename > > that properly to libxcrypt-dev. > Can you be more specific in why this would not be allowed? > Currentl

Bug#946599: libcrypt1: failure to switch from libc6 to libcrypt1 hoses the whole system

On Dec 12, Thorsten Glaser wrote: > I did a dist-upgrade, and apt uses a different resolver than apt-get, > but… perhaps the apt maintainers can help trying to figure this out? I have tried "apt-get --purge dist-upgrade" too and it still does not fail on my system. Can you report this from

Bug#946599: libcrypt1: failure to switch from libc6 to libcrypt1 hoses the whole system

On Dec 11, Aurelien Jarno wrote: > On 2019-12-11 17:54, Marco d'Itri wrote: > > On Dec 11, Thorsten Glaser wrote: > > > > > Thankfully, I had a root session in a chroot open and used > > > the program, statically linked, from http://koltsoff.com/pub/getroot

Bug#946599: libcrypt1: failure to switch from libc6 to libcrypt1 hoses the whole system

On Dec 11, Thorsten Glaser wrote: > Thankfully, I had a root session in a chroot open and used > the program, statically linked, from http://koltsoff.com/pub/getroot/ > to recover access outside the chroot, by using dpkg -i --force-all > first on libc6_*.deb, then libcrypt1_*.deb. Afterwards,

Bug#946563: there is no need for a versioned libxcrypt1-dev package

On Dec 11, Matthias Klose wrote: > there is really no need for a versioned libxcrypt1-dev package. Please rename > that properly to libxcrypt-dev. Can you be more specific in why this would not be allowed? Currently I am not building libxcrypt2 and libxcrypt2-dev, but the package is ready to do

Bug#940596: upgrading libjbig2dec0 broke mupdf

Package: mupdf Version: 1.15.0+ds1-1+b1 Severity: grave After upgrading libjbig2dec0 from 0.16-1 to 0.16+20190905-2 it does not start anymore: md@bongo:~$ mupdf /usr/lib/mupdf/mupdf-x11: symbol lookup error: /usr/lib/mupdf/mupdf-x11: undefined symbol: jbig2_ctx_new [Exit 127] md@bongo:~$ nm -D

Bug#926699: libc6-{i386,x32}: installing, removing, reinstalling in a --merged-usr system results in unmerged /lib{32,x32}

Control: severity -1 normal On Aug 22, Marco d'Itri wrote: > Another option is agreeing that this cannot be fixed in a sane and > practical way until non-merged systems have to be supported, and > document somewhere that if anybody does this install-remove-reinstall > dan

Bug#926699: libc6-{i386,x32}: installing, removing, reinstalling in a --merged-usr system results in unmerged /lib{32,x32}

On Aug 19, Aurelien Jarno wrote: Thank you for expressing your position in more detail. > usrmerge works by moving all data from /lib into /usr/lib and then > creating a symlink /lib -> /usr/lib. The same is done for the biarch > or triarch directories, namely /lib32, /lib64, /libx32 and

Bug#926699: libc6-{i386,x32}: installing, removing, reinstalling in a --merged-usr system results in unmerged /lib{32,x32}

On Aug 17, Aurelien Jarno wrote: > One package should be responsible for providing those links so that > glibc is not the last package using them. The same way that base-files > ensure that some directories are present. usrmerge is only needed to be installed during the conversion of a

Bug#926699: libc6-{i386,x32}: installing, removing, reinstalling in a --merged-usr system results in unmerged /lib{32,x32}

On Aug 17, Aurelien Jarno wrote: > > > The preinst scripts could check whether the package is being installed > > > in a --merged-usr environment and create (dangling) symlinks if > > > /usr/lib{32,x32} is missing. And postrm remove could recreate them if > > > they went missing. Yes: this is

Bug#928172: fixing debian-security-support upgrades from stretch (for good)

On May 13, Holger Levsen wrote: > So I think this can only be fixed properly (=without asking people to > upgrade to the latest stretch pointrelease but instead allowing upgrades > to buster from *any* stretch pointrelease) by adding a "pre-depends: > debian-security-support (>= 2019.04.25)" to

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

On Feb 18, Didier 'OdyX' Raboud wrote: > * another use-case is to be able to share an identical `/usr` over a network > link; hence booting an initramfs, mounting a local `/`, then mounting `/usr` > over the network. It seems that an initramfs with everything needed to mount > a filesystem

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

On Dec 23, Simon McVittie wrote: > An alternative to the usrmerge package might be to do this transition > in an initramfs hook or something similar, which would guarantee that > nothing else is concurrently altering /usr or the directories that are > meant to be merged into it. FWIW I tried

Bug#915883: usrmerge: missing dependency on perl

Control: severity 915883 normal On Dec 07, Niko Tyni wrote: > The build system should invoke dh_perl to fill in the ${perl:Depends} > substvar (already referenced in the source control file.) You are right that I forgot to invoke dh_perl, but in practice this does not matter because there is

Bug#914897: debating the wrong thing

On Dec 03, Adam Borowski wrote: > unusrmerge would still be still far less work than continuing with 2. Yet I No "unmerge" program is possible since some symlinks are created by maintainer scripts and hence cannot be recreated except by running again the maintainer scripts in the right

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

On Dec 02, Wouter Verhelst wrote: > One thing that has not been answered yet in this discussion (and if the > TC is to make a decision about it, I think it should be) is "why are we > doing this". That is, what is the problem that usrmerge is meant to > solve, and how does it attempt to solve

Bug#914897: affects private debs too

On Nov 29, Adam Borowski wrote: > Thus: sorry but there is no way we can possibly support usrmerged and > non-usrmerged systems at the same time. Usrmerge is not viable without a > flag day. We have being doing exactly this opt-in (the usrmerge package) for over three years and opt-out (the

Bug#903439: /bin/kmod: dummy module redundant parameter in modprobe

Control: severity -1 normal On Jul 10, Stanislav Lorenc wrote: > Justification: renders package unusable Obviously not, even if it were true. > root@honor:/# cat /etc/modprobe.d/dummy.conf > options dummy numdummies=10 numdummies=0 is set in /lib/modprobe.d/systemd.conf, for good reasons. If

Bug#896500: libnet-whois-ripe-perl: Can't use 'defined(@array)'

Control: retitle -1 RM: libnet-whois-ripe-perl -- ROM; broken and obsolete Control: reassign -1 ftp.debian.org On Apr 21, Niko Tyni wrote: > This has been fatal since Perl 5.22, so stretch is affected too. Thank you. So this shows that nobody uses this package anymore and it

Bug#894580: postinst does not create the knot-resolver user

Package: knot-resolver Version: 2.1.1-1 Severity: grave Tags: patch Due to a typo in postinst, the knot-resolver user is not actually created at install time, so nothing works. -if [ "$1" = "$configure" ]; then +if [ "$1" = "configure" ]; then -- ciao, Marco signature.asc Description: PGP

Bug#882247:

On Jan 05, Mike Hommey wrote: > There is something wrong with the default locale. Try installing a > locale package (even firefox-l10n-en-gb) or downgrade to 57. Confirmed, this fixes it. -- ciao, Marco signature.asc Description: PGP signature

Bug#877212: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

On Oct 03, Gunnar Wolf wrote: > So, contrib is _explicitly_ meant for software that does not meet the > DFSG, not for random stuff that cannot be packaged for convenience or > different issues. I am almost sure that when I joined the project contrib was also the place for

Bug#863269: usrmerge is not yet ready for a stable release

On Jun 02, Adrian Bunk wrote: > No system running stable Debian only is supposed to have merged /usr, Bullshit. -- ciao, Marco signature.asc Description: PGP signature

Bug#761658: urgency of a fix before stretch

On Jun 03, Norbert Preining wrote: > >As one of the systemd maintainers I am explicitly and publicly > >requesting that you do not introduce this unwanted change. > Then how are you planning to deal with this serious bug after years of > inactivity? I think that I have

Bug#761658: urgency of a fix before stretch

On Jun 02, Norbert Preining wrote: > I am planning to upload an NMU fixing this issue to DELAY3 and hope that > release managers allow this fix into stretch. You cannot do a NMU just because the maintainers of a package disagree with you. As one of the systemd

Bug#781155: openbsd-inetd: openbsd-inetd.service should be the main service file

On Apr 13, Raphael Hertzog wrote: > Consistency between package name and init script and service file > has no reason to be classified as "historical accident", it seems > to be nice bonus point to me... I think that consistenct between daemon name and systemd unit name is a

Bug#781155: openbsd-inetd: openbsd-inetd.service should be the main service file

On Apr 11, Raphael Hertzog wrote: > Why aren't you providing openbsd-inetd.service as the real file and > inetd.service as a symlink ? Because naming the init script "openbsd-inetd" was an historical accident caused by problems when replacing the old netkit-inetd. Since we

Bug#781155: openbsd-inetd: openbsd-inetd.service should be the main service file

On Apr 11, Niels Thykier wrote: > Are there any updates on this bug? If not, then we will be inclined to I do not think that there is anything I can or should do in openbsd-inetd: the bug should either be closed or downgraded. > remove openbsd-inetd from testing. Bad idea,

Bug#817236: schroot: no access to pseudo-terminals in new chroots

On Mar 09, Cyril Brulebois wrote: > If nobody (esp. Ben & Marco) objects to them, I guess you could push > them to master once alioth is back? I think Simon did a great job analyzing this, so I fully support merging his patch. -- ciao, Marco signature.asc Description: PGP

Bug#781155: openbsd-inetd: openbsd-inetd.service should be the main service file

On Apr 10, Michael Biebl wrote: > Ideally, the .service file name and sysv init script do match. > If that is not the case, because upstream chose a different name, my > recommendation is to create a symlink and ship that statically in the > package, i.e. not create it via

Bug#848622: usrmerge: Breaks dpkg-query --search

Control: block -1 by 134758 Control: severity -1 normal Control: found -1 1 On Dec 19, Guillem Jover wrote: > While I was checking the implications of the dpkg-shlibdeps breakage I > realized that «dpkg-query --search» is also broken when deploying a > merged-/usr with the

Bug#848504: usrmerge breaks various systemd symlinks

Control: severity -1 normal Control: tag -1 -moreinfo Control: close -1 On Dec 17, Christian Hofstaedtler wrote: > usrmerge reports that various symlinks installed by systemd are "broken" > and cannot be properly converted: Because they are, so the program cannot magically

Bug#844220: exim4: fails to install: user mail was not found

Control: severity -1 normal Control: tag -1 unreproducible On Nov 16, Holger Levsen wrote: > sadly I dont have much time atm to try to reproduce manually, so if > noone else can I would suggest downgrading this bug to normal and > unreproducible and maybe I'll find the

Bug#828351: inn2: FTBFS with openssl 1.1.0

On Nov 29, Sebastian Andrzej Siewior wrote: > Please find attached a patch against the package which includes the > three three patches mentioned here and was sbuild tested. > Should I NMU it? NO! I have a new package ready, but it needs some mild testing. -- ciao,

Bug#843073: Debian Installer Stretch Alpha 8 release

On Nov 21, Guillem Jover wrote: > Oh, and forgot to mention, this issue has been known for over 8 > months, and now there's this need to be pushy and rush things, etc. > I certainly do not appreciate that. No, not really: it was not clear (e.g. I could never reproduce it)

Bug#844220: maybe not /usr-merged but 0700 for / could be the culprit here

On Nov 18, Holger Levsen wrote: > someone mailed me privately and pointed me to this forum post > https://bbs.archlinux.org/viewtopic.php?id=186056=2 which made me > realize that debootstrap had another change: TARGET is now created with > 0700 permissions and not 0755

Bug#843073: dpkg: dpkg-shlibdeps failing due to /usr/lib/ld-linux-armhf.so.3 symlink

On Nov 15, Wookey wrote: > How is the usrmerge done? bind-mounting? hardlinks? rename(2) > Is dpkg-shlibdeps the only thing that is going to wrong if files stop > having a canonical location in the system? It's a pretty major change > having every library (and a load of

  1   2   3   4   5   6   7   >