Package: ansible-mitogen
Version: 0.3.23-2
Severity: grave
Tags: upstream
Since upgrading ansible, ansible-mitogen fails with:
[ERROR]: [mux 28726] 14:11:13.061278 E mitogen: raw pickle was:
b'\x80\x02X\'\x00\x00\x00ansible_mitogen.services.ContextServiceq\x00X\x03\x00\x00\x00getq\x01cmitogen.c
On Apr 21, stefa...@debian.org wrote:
Can you provide a minimal trival playbook that triggers this?
# ansible.cfg
[defaults]
inventory = hosts.txt
strategy = mitogen_linear
# hosts.txt
[servers]
server1.example.com ansible_user=root
# server1.yaml
- hosts: server1.example.com
gather_facts:
Control: reopen -1
Still broken, now a trivial playbook fails with:
[ERROR]: Task failed: ActionBase._parse_returned_data() missing 1 required
positional argument: 'profile'
Origin: (omissis)/public/ansible/servers/server1.yaml:5:7
3
4 tasks:
5 - name: Install the scripts
^ colum
Package: ansible-lint
Version: 25.2.1-1
Severity: grave
Control: tags -1 upstream
Control: forwarded -1 https://github.com/ansible/ansible-lint/issues/4586
Since upgrading ansible, ansible-lint fails with:
Traceback (most recent call last):
File "/usr/bin/ansible-lint", line 8, in
sys.exit
Package: ansible-mitogen
Version: 0.3.22-3
Severity: grave
Since upgrading ansible, ansible-mitogen fails with:
[ERROR]: Unexpected Exception, this is probably a bug: No module named
'ansible.parsing.utils.jsonify'
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/ansibl
On Mar 31, Luca Boccassi wrote:
I am really sorry for the disruption, but unfortunately when features
need to be dropped, there's bound to be some of that. Let's keep in
mind though, that we are talking about an optional 2% popcon package.
Considering all the quality issues with systemd-resolve
On Mar 30, Julien ÉLIE wrote:
% ls *1
convdate.1 gencancel.1inews.1 nntpget.1rnews.1
simpleftp.1
delayer.1 getlist.1 innconfval.1 pgpverify.1 shlock.1 sm.1
fastrm.1grephistory.1 innmail.1 pullnews.1 shrinkfile.1
I would start by moving delayer(1), bec
On Mar 30, Julien ÉLIE wrote:
Does sm(1) for inn2 actually belong to section 1 or could it be sm(8),
considering sm is an administrative tool for the INN storage manager?
Yes: definitely section 8.
--
ciao,
Marco
signature.asc
Description: PGP signature
Package: ipmitool
Version: 1.8.19-8
Severity: serious
This package should not depend on anacron.
Even if you really believe that it is justified to automatically keep
the file up to date for a niche feature of ipmitool (I don't), then it
is TOTALLY INAPPROPRIATE to have the package depend on ana
Control: severity -1 wishlist
Maybe I was not clear enough: I will really not spend more time on
sysvinit support, so if you want this change then send a tested patch.
This is not RC, so stop adjusting the severity.
--
ciao,
Marco
signature.asc
Description: PGP signature
Package: dkms
Version: 3.1.5-1
Severity: grave
https://ci.debian.net/packages/d/dkms/testing/amd64/58509652/
This may be related to kmod now having a minor version number or maybe
with it now loading the decompression libraries with dlopen(3).
--
ciao,
Marco
signature.asc
Description: PGP si
On Feb 26, Eric Dorland wrote:
> Seeing failures install 34-2 due to conflicting files in the bash-completion
> package:
You need to upgrade bash-completion.
I will add a Breaks+Replaces in the next upload, but I want to wait
a few days for more issues to surface.
--
ciao,
Marco
signature.
On Feb 22, Santiago Vila wrote:
> It is not possible to stop running the test when we know that it will fail?
It could be run only when the source package is built, but I like the
idea of verifying the key material every time the binary package is
built too.
I will talk to the IANA people to r
Package: meld
Version: 3.22.2-1
Severity: grave
Tags: upstream patch
https://bugs.gentoo.org/941526 has the trivial fix.
$ meld
Traceback (most recent call last):
File "/usr/bin/meld", line 462, in
sys.exit(main())
^^
File "/usr/bin/meld", line 458, in main
return ru
On Dec 24, Santiago Vila wrote:
> The trick is to stop caring about "cflags" file as much as possible.
> (Autobuilders only build the package once).
Of course, but I will not do this unless the correct solution will prove to
be excessively complex.
--
ciao,
Marco
signature.asc
Description: P
Package: ansible-mitogen
Version: 0.3.18-1
Severity: grave
Using mitogen fails with:
ERROR! Your Ansible version ((2, 18, 0)) is too recent. The most recent version
supported by Mitogen for Ansible is (2, 17).x. Please check the Mitogen
release notes to see if a new version is available, otherwis
The quick and easy solution would be to rebuild dracut-install, but the
release team refused to binNMU it (#1079038).
The stupid solution would be to revert the change, and I will not do it
because I do not want to diverge from upstream.
The elegant solution would be to keep for a while both sy
On Jul 13, Paul Gevers wrote:
> On the ci.d.n infrastructure our nodes run bookworm and use the lxc backend.
> Do you do that too?
No, I just run it on bare metal.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Jul 11, Paul Gevers wrote:
> You have an arm64 system? If yes, good to know it's not systematic and
> apparently only happening on the ci.d.n infrastructure. It would be
> interesting to figure out what the differences in setup (hardware) are.
Yes. It's a Banana Pi M5 and I cannot see how this
On Jul 09, Paul Gevers wrote:
> Your package has an autopkgtest, great. However, on arm64 it recently
> started to fill the entire disk with its output file in $AUTOPKGTEST_TMP (in
> testing and unstable, I haven't checked stable). On an otherwise empty host,
> there's 63 GB free, a watchdog kick
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 /s
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
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 maint
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 t
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 missin
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 expe
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 p
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 enabled
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 everyt
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
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 de
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
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
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
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/
disappe
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
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
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 bo
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:
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 de
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 th
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 a
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-de
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 trixie
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 crea
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 "AWT-EventQueue-0"
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
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 sy
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
t
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
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 release.
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:
https://git.dpkg.org/cgit/dpkg/dpkg.git/commit?i
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 0x7fa6329f770
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 msg="C
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 liner:
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
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 .../libcrypt1_
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 libcrypt.so
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 it
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/.
--
ciao
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 j
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 r
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", wh
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`."
[00:50:46:6
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 leas
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.
--
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
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 minima
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
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
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
if
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
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 l
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
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 actu
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 option
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 upstream
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 co
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 cosmeti
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
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
The fixed package is currently in NEW.
--
ciao,
Marco
signature.asc
Description: PGP signature
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
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?
> Cur
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 your
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/getroo
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, nor
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
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
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
>
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 /libo32
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
non-merged
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 how
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 b
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
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 impl
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 an
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 conditi
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 it?
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 deb
1 - 100 of 667 matches
Mail list logo
