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

[Marco d'Itri]

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/^default .*dev ([^ ]+).*/\1/p')

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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

[Marco d'Itri]

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 maintainers just tell us what they want?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 through October 2023.
Fixing this issue would require backporting a significant amount of 
new features in varnish and I do not believe that it would be practical.

I am inclined to downgrade this bug because:
- this is just a DoS attack
- it only concerns people using hitch for TLS termination instead of 
  a full web server like nginx or haproxy

nginx in stable is also vulnerable, BTW.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 missing anything...

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 expensive for their operators, since it is located in 
Australia.
The only other known HTTP mirror is mentioned on 
https://wiki.gentoo.org/wiki/ClamAV_Unofficial_Signatures, with a vague 
note about it being available to the public.

Until fangfrisch will implement rsync support, I do not think that it is 
safe to include fangfrisch in a Debian release due to the possible 
effect on unsuspecting third party mirrors.

This has also been discussed upstream:
https://github.com/rseichter/fangfrisch/issues/30

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 pressing 
right-alt as Alt_R / Meta_R.)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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]   
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `tecla'.
Program terminated with signal SIGSEGV, Segmentation fault.

warning: Section `.reg-xstate/1963868' in core file too small.
#0  tecla_model_get_keycode_key (model=0x0, keycode=24)
at ../src/tecla-model.c:338
Download failed: Argomento non valido.  Continuing without source file 
./obj-x86_64-linux-gnu/../src/tecla-model.c.
338 ../src/tecla-model.c: File o directory non esistente.
[Current thread is 1 (Thread 0x7effd81ee2c0 (LWP 1963868))]
(gdb) where
#0  tecla_model_get_keycode_key (model=0x0, keycode=24)
at ../src/tecla-model.c:338
#1  0x55e0f78b72a8 in key_pressed_cb
(controller=, keyval=, keycode=, modifiers=, view=0x55e0f84828c0 [TeclaView])
at ../src/tecla-view.c:343
#6  0x7effdb17a243 in 
(instance=instance@entry=0x55e0f8516490, signal_id=, 
detail=detail@entry=0) at ../../../gobject/gsignal.c:3675
#2  0x7effdb4bcb0b in _gtk_marshal_BOOLEAN__UINT_UINT_FLAGSv
(closure=, return_value=0x7ffe1c328650, instance=, args=, marshal_data=, n_params=, param_types=0x55e0f85113c0) at gtk/gtkmarshalers.c:1748
#3  0x7effdb15f749 in _g_closure_invoke_va
(closure=0x55e0f85663c0, return_value=0x7ffe1c328650, 
instance=0x55e0f8516490, args=0x7ffe1c328750, n_params=3, 
param_types=0x55e0f85113c0)
at ../../../gobject/gclosure.c:895
#4  0x7effdb173913 in signal_emit_valist_unlocked
(instance=instance@entry=0x55e0f8516490, signal_id=signal_id@entry=99, 
detail=detail@entry=0, var_args=var_args@entry=0x7ffe1c328750)
at ../../../gobject/gsignal.c:3516
#5  0x7effdb17a186 in g_signal_emit_valist
(instance=0x55e0f8516490, signal_id=99, detail=0, var_args=0x7ffe1c328750)
--Type  for more, q to quit, c to continue without paging--c
at ../../../gobject/gsignal.c:3355
#7  0x7effdb53c0fd in gtk_event_controller_key_handle_event
(controller=0x55e0f8516490 [GtkEventControllerKey], event=, 
x=, y=)
at ../../../gtk/gtkeventcontrollerkey.c:121
#8  0x7effdb53b09a in gtk_event_controller_handle_event
(controller=controller@entry=0x55e0f8516490 [GtkEventControllerKey], 
event=event@entry=0x55e0f8e5c7b0 [GdkKeyEvent], 
target=target@entry=0x55e0f84828c0 [TeclaView], x=x@entry=0, y=y@entry=0) at 
../../../gtk/gtkeventcontroller.c:362
#9  0x7effdb67e55c in gtk_widget_run_controllers
(widget=widget@entry=0x55e0f84828c0 [TeclaView], 
event=event@entry=0x55e0f8e5c7b0 [GdkKeyEvent], 
target=target@entry=0x55e0f84828c0 [TeclaView], x=0, y=0, 
phase=phase@entry=GTK_PHASE_BUBBLE) at ../../../gtk/gtkwidget.c:4581
#10 0x7effdb685db1 in gtk_widget_event
(widget=widget@entry=0x55e0f84828c0 [TeclaView], 
event=event@entry=0x55e0f8e5c7b0 [GdkKeyEvent], 
target=target@entry=0x55e0f84828c0 [TeclaView])
at ../../../gtk/gtkwidget.c:4775
#11 0x7effdb5ac5de in gtk_propagate_event_internal
(widget=widget@entry=0x55e0f84828c0 [TeclaView], 
event=event@entry=0x55e0f8e5c7b0 [GdkKeyEvent], topmost=) at 
../../../gtk/gtkmain.c:1947
#12 0x7effdb5ac676 in gtk_propagate_event
(widget=widget@entry=0x55e0f84828c0 [TeclaView], 
event=event@entry=0x55e0f8e5c7b0 [GdkKeyEvent]) at ../../../gtk/gtkmain.c:1997
#13 0x7effdb5acd03 in gtk_main_do_event
(event=0x55e0f8e5c7b0 [GdkKeyEvent]) at ../../../gtk/gtkmain.c:1689
#14 0x7effdb6921f0 in surface_event
(surface=surface@entry=0x55e0f858c730 [GdkX11Toplevel], event=, widget=) at ../../../gtk/gtkwindow.c:4830
#15 0x7effdb80a5ea in _gdk_marshal_BOOLEAN__POINTER
(closure=closure@entry=0x55e0f82bb050, 
return_value=return_value@entry=0x7ffe1c328c90, 
n_param_values=n_param_values@entry=2, 
param_values=param_values@entry=0x7ffe1c328d20, 
invocation_hint=invocation_hint@entry=0x7ffe1c328c70, 
marshal_data=marshal_data@entry=0x0) at gdk/gdkmarshalers.c:258
#21 0x7effdb17a243 in 
(instance=instance@entry=0x55e0f858c730, signal_id=, 
detail=detail@entry=0) at ../../../gobject/gsignal.c:3675
#16 0x7effdb87f5f3 in gdk_surface_event_marshaller
(closure=0x55e0f82bb050, return_value=0x7ffe1c328c90, n_param_values=2, 
param_values=0x7ffe1c328d20, invocation_hint=0x7ffe1c328c70, marshal_data=0x0)
at ../../../gdk/gdksurface.c:433
#17 0x7effdb15f540 in g_closure_invoke
(closure=0x55e0f82bb050, return_value=0x7ffe1c328c90, n_param_values=2, 
param_values=0x7ffe1c328d20, invocation_hint=0x7ffe1c328c70)
at ../../../gobject/gclosure.c:832
#18 0x7effdb172afc in signal_emit_unlocked_R
(node=node@entry=0x7ffe1c328df0, detail=detail@entry=0, 
instance=instance@entry=0x55e0f858c730, 

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

[Marco d'Itri]

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 everything works fine without in-kernel 
decompression, because this is how the Debian kernel is configured.

-- 
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

[Marco d'Itri]

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 settings 
which are supported by the userspace loader but not by the kernel one.

-- 
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

[Marco d'Itri]

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 default for Debian kenrels).

-- 
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

[Marco d'Itri]

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

[Marco d'Itri]

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

[Marco d'Itri]

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/

[Marco d'Itri]

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/ 
disappears from time to time. Local users are expected to install local 
files in /etc/modules-load.d/ anyway.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1034958: Consequence of #951598

[Marco d'Itri]

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

[Marco d'Itri]

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

[Marco d'Itri]

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 bother requesting a freeze exception for this?

> The first build succeeds, a subsequent make distclean deletes
> src/bgpd/parse.c:
Indeed. The openbgpd upstream source packages are inconvenient because 
they contain generated files, but then distclean deletes them.
I would like to delete the generated files at build time to make sure 
that I do not make this mistake again, but it is not trivial since the 
Makefile does not exist until configure is run.
Is there an established design pattern for this situation?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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:
Then fix it as suggested, but not via fstab?
Looks like this is a documentation issue.
What do you think should be changed here, exactly?

> To continue the conversion please:
> - replace '/lib/modules/' with '/usr/lib/modules/' in /etc/fstab
> - reboot
> - try again

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 debianutils'
It is expected that /etc/shells can be edited by system administrators, 
I have been doing that forever in my career as a professional system 
administrator and until now I was not even aware of these programs from 
debianutils.
Hence my reasoning that having convert-etc-shells modify the file would 
not be harmful, and so far I am not aware of any practical problem that 
this has ever caused.

I also see that you wrote update-shells in 2021, but convert-etc-shells 
was added to usrmerge in 2016.

> If and only if usrmerge is used, convert-etc-shells turns /bin/sh into
> /usr/bin/sh. So whenever we start out merged and use usr-is-merged,
> /usr/bin/sh goes missing.
Right. But both update-shells and usr-is-merged are new to bookworm, and 
I remember that having the /usr/ paths in /etc/shells is not usually 
needed, so this explains why nobody has reported actual problems so far.

> I think the best solution here would be merging convert-etc-shells into
> update-shells.
No objections if you can do the work, I will not miss it.

> Whenever we run update-shells, it should check whether
> the system is already merged and when it is, perform the equivalent to
> convert-etc-shells. Then usrmerge can just install an empty (except for
> a comment) /usr/share/debianutils/shells.d/usrmerge to trigger
> update-shells and things become fully reproducible in all cases, because
OK.

(Also, would you mind moving /var/lib/shells.state to /var/lib/misc/?)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 this will be helpful for Varnish users.

> Especially since testing currently has 7.1, which reaches it's end of
> life on March 15 2023 and does not contain the LTS release.
stable contains 6.5.1, oldstable 6.1.1, neither of which was a LTS, and 
the sky did not fall.

> (It's not unlikely that most people who operate a CDN based on Varnish
> only use custom/patched/recent packages backported from stable
> anyway, which is perfectly fine, but then let's make that explicit
> by keeping it out of testing).
Varnish is used by much more than CDNs! Web site operators use Varnish 
all the time to cache CMSes like Wordpress and Magento, and they do not 
have the resources to build custom packages (and matching extensions).

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1029447: unmuting audio breaks video playing in browsers

[Marco d'Itri]

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 as usual, 100% reproducibile.
I have reproduced this both with Firefox and Chrome.

Installing again pipewire-media-session and rebooting fixed this.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wireplumber depends on:
ii  init-system-helpers   1.65.2
ii  libc6 2.36-8
ii  libglib2.0-0  2.74.5-1
ii  libpipewire-0.3-0 0.3.64-2
pn  libwireplumber-0.4-0  
ii  pipewire  0.3.64-2

Versions of packages wireplumber recommends:
pn  pipewire-pulse  

Versions of packages wireplumber suggests:
ii  libspa-0.2-bluetooth  0.3.64-2
pn  wireplumber-doc   

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1027760: gortr appears to be unmaintained

[Marco d'Itri]

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 let's 
ignore this for the time being.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1027760: gortr appears to be unmaintained

[Marco d'Itri]

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 release cycle.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 create some working configure
> file from it.  I do not consider my time well spent in doing so except
> if there is some consensus here on the list that configure files without
> configure.ac are "missing source".
If there is no surviving configure.ac which can generate the current 
configure file then it is quite obvious that this is not a DFSG issue, 
because no such source exists.

But if your package contains a manually edited configure file then this
is a bad practice, and experience shows that sooner or later you will 
have to deal with the resulting bugs.

Clearly, the severity of these bugs is different, at least as long as 
your package builds.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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" java.lang.IllegalAccessError: class 
net.sf.linuxorg.pcal.engine.Engine (in unnamed module @0x614635c2) cannot 
access class com.sun.org.apache.xml.internal.serialize.OutputFormat (in module 
java.xml) because module java.xml does not export 
com.sun.org.apache.xml.internal.serialize to unnamed module @0x614635c2
at net.sf.linuxorg.pcal.engine.Engine.saveToFile(Engine.java:909)
at 
net.sf.linuxorg.pcal.MainWindow.saveToFileHandler(MainWindow.java:1408)
at 
net.sf.linuxorg.pcal.MainWindow$ActionSave.saveActionCore(MainWindow.java:1547)
at 
net.sf.linuxorg.pcal.MainWindow$ActionSave.actionPerformed(MainWindow.java:1553)
at 
java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1972)
at 
java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2313)
at 
java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405)
at 
java.desktop/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262)
at 
java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:279)
at 
java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:297)
at 
java.desktop/java.awt.Component.processMouseEvent(Component.java:6626)
at 
java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3389)
at java.desktop/java.awt.Component.processEvent(Component.java:6391)
at java.desktop/java.awt.Container.processEvent(Container.java:2266)
at 
java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5001)
at 
java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2324)
at java.desktop/java.awt.Component.dispatchEvent(Component.java:4833)
at 
java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4948)
at 
java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4575)
at 
java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4516)
at 
java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2310)
at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2780)
at java.desktop/java.awt.Component.dispatchEvent(Component.java:4833)
at 
java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:722)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:716)
at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at 
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
at 
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:97)
at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:746)
at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:744)
at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at 
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:743)
at 
java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at 
java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at 
java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at 
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at 
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at 
java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pcalendar depends on:
ii  default-jre [java6-runtime] 2:1.17-73
ii  libxerces2-java 2.12.2-1
ii  openjdk-11-jre [java6-runtime]  11.0.17+8-2
ii  openjdk-17-jre [java6-runtime]  17.0.5+8-2
ii  openjdk-8-jre [java6-runtime]   8u352-ga-1

pcalendar recommends no 

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

[Marco d'Itri]

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 has been inactive for over two months: do you need any help?
It is keeping cfrpki out of testing.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#926699: Transition to usrmerge has started

[Marco d'Itri]

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 systems).

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 
to support musl, which is not even a real port.
If moving crypt.h to the multiarch path only when building with musl is 
a solution then let's do that.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 the non-multilib builds.
> 
> Unfortunately the changelog doesn't mention anything why it was moved.
> 
> So either it should be moved back to /usr/include, or we need multilib
> builds for libxcrypt.
It was discussed in #1004102 (and is documented in the git commit), 
where Helmut was positive that this would not cause any issues. Helmut?

(Why can't we retire multilib for good?)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1010244: does not work with PHP 8.1

[Marco d'Itri]

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.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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?id=abd3a064ef8a9004e7ff2c9e5841e507487130ac

This is dpkg's own changelog about the Protected field:

This field is intended to make it possible to move several of the
current packages marked as Essential, so that they can be removed on
installations where these do not make sense being installed.

Protected packages have some of the properties of Essential, but not
all. These are intended to be used mostly for packages that are involved
in booting the system.

Which is clearly not what is happening here.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 0x7fa6329f7700> failed: 
loader for distro cannot handle ansible.module_utils.distro
[mux  685121] 14:38:50.354915 D mitogen: 
_get_module_via_sys_modules('ansible.module_utils.distro') -> 
[mux  685121] 14:38:50.355021 D mitogen: 
sys.modules['ansible.module_utils.distro'].__name__ is incorrect, assuming this 
is a hacky module alias and ignoring it. Got 'distro', module object: 
[mux  685121] 14:38:50.355142 D mitogen: ParentEnumerationMethod(): 
'ansible.module_utils.distro' is PKG_DIRECTORY: 
'/usr/lib/python3/dist-packages/ansible/module_utils/distro/__init__.py'
...
[mux  685121] 14:38:51.209954 D mitogen: SysModulesMethod(): 
sys.modules['ansible.module_utils.distro._distro'] absent or not a regular 
module
[mux  685121] 14:38:51.210217 D mitogen: ParentEnumerationMethod(): 
imp.find_module('_distro', [['/usr/lib/python3/dist-packages/distro']]) -> No 
module named '_distro'
[mux  685121] 14:38:51.210346 D mitogen: 
get_module_source('ansible.module_utils.distro._distro'): cannot find source
[mux  685121] 14:38:51.210449 D mitogen.responder: could not find source for 
'ansible.module_utils.distro._distro'
[mux  685121] 14:38:51.210566 D mitogen.responder: sending 
ansible.module_utils.distro._distro (0.05 KiB) to ssh.proxy.glacom.eu
[mux  685121] 14:38:51.224181 D mitogen.importer.[ssh.proxy.glacom.eu]: 
received ansible.module_utils.distro._distro
...
[mux  685121] 14:38:51.232206 D mitogen: MitogenProtocol(unix_client.685155): 
disconnecting
The full traceback is:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/ansible/executor/task_executor.py", line 
158, in run
res = self._execute()
  File "/usr/lib/python3/dist-packages/ansible/executor/task_executor.py", line 
663, in _execute
result = self._handler.run(task_vars=variables)
  File "/usr/lib/python3/dist-packages/ansible_mitogen/mixins.py", line 144, in 
run
return super(ActionModuleMixin, self).run(tmp, task_vars)
  File "/usr/lib/python3/dist-packages/ansible/plugins/action/normal.py", line 
47, in run
result = merge_hash(result, self._execute_module(task_vars=task_vars, 
wrap_async=wrap_async))
  File "/usr/lib/python3/dist-packages/ansible_mitogen/mixins.py", line 374, in 
_execute_module
self._set_temp_file_args(module_args, wrap_async)
  File "/usr/lib/python3/dist-packages/ansible_mitogen/mixins.py", line 353, in 
_set_temp_file_args
self._connection.get_good_temp_dir()
  File "/usr/lib/python3/dist-packages/ansible_mitogen/connection.py", line 
817, in get_good_temp_dir
self._connect()
  File "/usr/lib/python3/dist-packages/ansible_mitogen/connection.py", line 
839, in _connect
self._connect_stack(stack)
  File "/usr/lib/python3/dist-packages/ansible_mitogen/connection.py", line 
786, in _connect_stack
dct = mitogen.service.call(
  File "/usr/lib/python3/dist-packages/mitogen/service.py", line 126, in call
return call_context.call_service(service_name, method_name, **kwargs)
  File "/usr/lib/python3/dist-packages/mitogen/core.py", line 2284, in 
call_service
return recv.get().unpickle()
  File "/usr/lib/python3/dist-packages/mitogen/core.py", line 963, in unpickle
raise obj
mitogen.core.CallError: builtins.ModuleNotFoundError: The Mitogen master 
process was unable to serve 'ansible.module_utils.distro._distro'. It may be a 
native Python extension, or it may be missing entirely. Check the importer 
debug logs on the master for more information.
  File "", line 3669, in _dispatch_one
  File "", line 3656, in _parse_request
  File "", line 668, in import_module
  File "", line 1516, in load_module
  File "master:/usr/lib/python3/dist-packages/ansible_mitogen/target.py", line 
85, in 
import ansible_mitogen.runner
  File "", line 1516, in load_module
  File "master:/usr/lib/python3/dist-packages/ansible_mitogen/runner.py", line 
85, in 
import ansible.module_utils.basic
  File "", line 1516, in load_module
  File "master:/usr/lib/python3/dist-packages/ansible/module_utils/basic.py", 
line 152, in 
from ansible.module_utils.common.sys_info import (
  File "", line 1516, in load_module
  File 
"master:/usr/lib/python3/dist-packages/ansible/module_utils/common/sys_info.py",
 line 10, in 
from ansible.module_utils import distro
  File "", line 1516, in load_module
  File 
"master:/usr/lib/python3/dist-packages/ansible/module_utils/distro/__init__.py",
 line 45, in 
from ansible.module_utils.distro import _distro as distro
  File "", line 1491, in load_module


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 

Bug#1004253: broken for BIND in stable

[Marco d'Itri]

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="Couldn't retrieve 
BIND stats" err="failed to unmarshal XML response: strconv.ParseUint: parsing 
\"-\": invalid syntax"

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#998108: firefox freezes shortly after start

[Marco d'Itri]

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:

 sudo perl -i -pe 
's/\x49\x8B\x5C\x24\x08\x90\x48\x89\xDF\xFF\x15\x7F\xBD\x97\x03\xEB\xF5/\x4D\x8B\x6C\x24\x08\x90\x4C\x89\xEF\xFF\x15\x7F\xBD\x97\x03\xEB\xDA/'
 /usr/lib/firefox/libxul.so

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#998108: firefox freezes shortly after start

[Marco d'Itri]

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 
Firefox and opening again the link which made it freeze the first time
then it works again.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#995308: libcrypt1: symlink points to libpthread

[Marco d'Itri]

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_*.deb
> 
> I tried this out, and it worked: the effect disappeared completely, 
> reinstallation binds the links to proper files. Thank you and sorry for 
> bothering!

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#995308: libcrypt1: symlink points to libpthread

[Marco d'Itri]

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.1?
/lib/x86_64-linux-gnu/libcrypt.so.1 is part of libcrypt1 and is correct 
in the package.

> When I run apt-get reinstall libcrypt1 the link changes to 
> libpthread.so.1 again, so it is clearly this package that causes 
> trouble. As for now (09/29/2021 2:30 PM GMT) the bug keeps 
> reappearing.
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_*.deb

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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), but I will fix this 
later in a simpler way.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 just be removed (either other packages do depend on it or they 
do not), but I am not sure exactly of how much work this would require.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#979231: the new mailcap entry breaks mutt

[Marco d'Itri]

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 related
>   Depends: ifhp
QA
>   Suggests: gabedit
I am not sure about why it depends on a2ps.
>   Recommends: foomatic-filters
Yet anoter filter.

ifhp looks like something very obsolete, and the other programs probably 
could easily replace a2ps with paps.
Maybe apsfilter and magicfilter could be replaced by foomatic-filters as 
well, which is maintained.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#979231: the new mailcap entry breaks mutt

[Marco d'Itri]

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", which
breaks mutt and probably other software in fun ways.

Solution: override dh_installmime to stop installing the file until 
somebody will figure out a better plan.

It may be worth considering removing a2ps from the archive since its 
last upstream release and non-NMU uploads were from 2008 and I am being 
told that it does not support UTF-8.
paps has been mentioned as a replacement.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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:608][0x5618e548aed0][Warning]app/App.cpp:229: 
(qrc:/ui/views/App/Calls/CallsWindow.qml:191:9: Type Chat unavailable
Chat {
^, qrc:/ui/modules/Linphone/Chat/Chat.qml:215:7: Type 
DroppableTextArea unavailable
  DroppableTextArea {
  ^, qrc:/ui/modules/Common/Form/DroppableTextArea.qml:108:5: Type 
FileDialog unavailable
FileDialog {
^, 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Dialogs/DefaultFileDialog.qml:42:1:
 module "QtQuick.Controls" version 1.2 is not installed
import QtQuick.Controls 1.2
^)

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linphone-desktop depends on:
ii  libbctoolbox1  4.4.13-2
ii  libbelcard14.4.13-2
ii  libc6  2.31-6
ii  libgcc-s1  10.2.1-3
ii  liblinphone++104.4.21-1
ii  liblinphone10  4.4.21-1
ii  libmediastreamer11 1:4.4.21-1
ii  libqt5core5a   5.15.2+dfsg-2
ii  libqt5dbus55.15.2+dfsg-2
ii  libqt5gui5 5.15.2+dfsg-2
ii  libqt5network5 5.15.2+dfsg-2
ii  libqt5qml5 [qtdeclarative-abi-5-15-2]  5.15.2+dfsg-2
ii  libqt5quick5   5.15.2+dfsg-2
ii  libqt5quickcontrols2-5 5.15.2+dfsg-2
ii  libqt5svg5 5.15.2-2
ii  libqt5widgets5 5.15.2+dfsg-2
ii  libstdc++6 10.2.1-3
ii  linphone-common4.4.21-1
ii  qml-module-qt-labs-platform5.15.2+dfsg-2
ii  qml-module-qtgraphicaleffects  5.15.2-2
ii  qml-module-qtquick-controls2   5.15.2+dfsg-2
ii  qml-module-qtquick-dialogs 5.15.2-2
ii  qml-module-qtquick-layouts 5.15.2+dfsg-2
ii  qml-module-qtquick-window2 5.15.2+dfsg-2
ii  qml-module-qtquick25.15.2+dfsg-2

linphone-desktop recommends no packages.

linphone-desktop suggests no packages.

-- no debconf information

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 least unpacked.
Good point, you are right. :-(
Then we are up to plan B, which is a bit more complex but should still 
be approachable:

  Another option might be to have the new libc6 Conflict with old versions
  of Essential:yes packages that need libcrypt1, forcing those Essential:yes
  packages to get upgraded first. A quick check based on libcrypt1 reverse
  dependencies in sid shows perl-base, login and util-linux. I'm not sure
  if this list is exhaustive, though.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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

[Marco d'Itri]

On Mar 15, Aurelien Jarno  wrote:

> The kmod binaries are actually the one being used, so yes please add a
> kmod-udeb.
Does it look good to you?

https://salsa.debian.org/md/kmod/-/commit/801ce705d39efdae9411192b1c33aee8ad522cc7

drwxr-xr-x root/root 0 2020-04-05 02:14 ./
drwxr-xr-x root/root 0 2020-04-05 02:14 ./bin/
-rwxr-xr-x root/root121656 2020-04-05 02:14 ./bin/kmod
drwxr-xr-x root/root 0 2020-04-05 02:14 ./etc/
drwxr-xr-x root/root 0 2020-04-05 02:14 ./etc/modprobe.d/
-rw-r--r-- root/root   246 2020-04-05 02:14 ./etc/modprobe.d/aliases.conf
drwxr-xr-x root/root 0 2020-04-05 02:14 ./sbin/
lrwxrwxrwx root/root 0 2020-04-05 02:14 ./bin/lsmod -> kmod
lrwxrwxrwx root/root 0 2020-04-05 02:14 ./sbin/depmod -> /bin/kmod
lrwxrwxrwx root/root 0 2020-04-05 02:14 ./sbin/insmod -> /bin/kmod
lrwxrwxrwx root/root 0 2020-04-05 02:14 ./sbin/lsmod -> /bin/kmod
lrwxrwxrwx root/root 0 2020-04-05 02:14 ./sbin/modinfo -> /bin/kmod
lrwxrwxrwx root/root 0 2020-04-05 02:14 ./sbin/modprobe -> /bin/kmod
lrwxrwxrwx root/root 0 2020-04-05 02:14 ./sbin/rmmod -> /bin/kmod

drwxr-xr-x root/root 0 2020-04-05 02:14 ./
drwxr-xr-x root/root 0 2020-04-05 02:14 ./usr/
drwxr-xr-x root/root 0 2020-04-05 02:14 ./usr/lib/
-rw-r--r-- root/root 76504 2020-04-05 02:14 ./usr/lib/libkmod.so.2.3.5
lrwxrwxrwx root/root 0 2020-04-05 02:14 ./usr/lib/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 minimal version of kmod, only for use in the installation system.

 Package: libkmod2-udeb
 Source: kmod
 Version: 27-3
 Architecture: amd64
 Maintainer: Marco d'Itri 
 Installed-Size: 80
 Depends: libc6-udeb (>= 2.30)
 Section: debian-installer
 Priority: important
 Description: libkmod shared library
  This is a minimal version of libkmod2, only for use in the installation 
system.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#953562: Possibly causes unbootable state

[Marco d'Itri]

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

[Marco d'Itri]

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

[Marco d'Itri]

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 it is not actually used?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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

[Marco d'Itri]

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 ldconfig?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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

[Marco d'Itri]

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 actual legal counsel handle it
> that way.
Which Red Hat did, and nobody ever complained about in an actual court.
This is relevant, because Red Hat is a target for litigation and Debian 
is not.

Or at least to decide that the criteria is "being a derivative work" and 
not "being listed as DT_NEEDED", which would solve a lot of cases.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#952399: OpenSSL linking without license exception

[Marco d'Itri]

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 optional dependency or ask upstream for a license exception.
The large number of contributors to kmod obviously makes impossible 
getting a license exception, also considering that only Debian cares 
about linking GPL'ed software with OpenSSL.

Since only libkmod (which is LGPL'ed), and not the actual commands, is
linked with OpenSSL, and the libkmod symbols do not change depending if 
OpenSSL support is enabled or not, and the patches which introduced 
OpenSSL support did not touch the commands, then I think that the 
commands are obviously not a derivative work of OpenSSL.
You can also easily verify that the commands are not linked with OpenSSL 
by looking at the build logs of the package.

Also, the next major release of OpenSSL will be relicensed with the 
ASLv2 anyway, which is compatible with the GPLv3.

For these reasons I have no interest and no plans to do anything about 
this, and I am quite annoyed that I had to spend my time researching 
these details and then explaining them to you.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 maintainers choose to provide backward compatibility to old 
binaries but not forward compatibility from old libraries.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 conflict 
with it. I did not expect for libxcrypt1 to be still around since it was 
not shipped in buster and nobody really ever used it.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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'

[Marco d'Itri]

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 cosmetic, and it needs to be fixed in /usr/sbin/mkinitramfs
by copying modules.builtin.bin too:

-for x in modules.builtin modules.order; do
+for x in modules.builtin modules.builtin.bin modules.order; do

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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

[Marco d'Itri]

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

[Marco d'Itri]

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

[Marco d'Itri]

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?
> Currently I am not building libxcrypt2 and libxcrypt2-dev, but the 
> package is ready to do it.
> libxcrypt1-dev and libxcrypt2-dev cannot be installed at the same time, 
> but libxcrypt1 and libxcrypt2 can.
Do you have any comments on this?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 dpkg.log?

root@TMP19396:~# egrep '(libc6|libcrypt)' /var/log/dpkg.log 
2019-12-12 18:28:46 install libc6:amd64  2.28-10
2019-12-12 18:28:46 status half-installed libc6:amd64 2.28-10
2019-12-12 18:28:47 status unpacked libc6:amd64 2.28-10
2019-12-12 18:28:47 configure libc6:amd64 2.28-10 2.28-10
2019-12-12 18:28:47 status half-configured libc6:amd64 2.28-10
2019-12-12 18:28:48 status installed libc6:amd64 2.28-10
2019-12-12 18:28:57 upgrade libc6:amd64 2.28-10 2.28-10
2019-12-12 18:28:57 status half-configured libc6:amd64 2.28-10
2019-12-12 18:28:57 status unpacked libc6:amd64 2.28-10
2019-12-12 18:28:57 status half-installed libc6:amd64 2.28-10
2019-12-12 18:28:58 status unpacked libc6:amd64 2.28-10
2019-12-12 18:29:11 configure libc6:amd64 2.28-10 
2019-12-12 18:29:11 status unpacked libc6:amd64 2.28-10
2019-12-12 18:29:11 status half-configured libc6:amd64 2.28-10
2019-12-12 18:29:11 status installed libc6:amd64 2.28-10
2019-12-12 18:29:30 install libc6-dev:amd64  2.28-10
2019-12-12 18:29:30 status half-installed libc6-dev:amd64 2.28-10
2019-12-12 18:29:30 status unpacked libc6-dev:amd64 2.28-10
2019-12-12 18:29:37 configure libc6-dev:amd64 2.28-10 
2019-12-12 18:29:37 status unpacked libc6-dev:amd64 2.28-10
2019-12-12 18:29:37 status half-configured libc6-dev:amd64 2.28-10
2019-12-12 18:29:37 status installed libc6-dev:amd64 2.28-10
2019-12-12 19:31:43 install libc6:i386  2.28-10
2019-12-12 19:31:43 status half-installed libc6:i386 2.28-10
2019-12-12 19:31:44 status unpacked libc6:i386 2.28-10
2019-12-12 19:31:44 configure libc6:i386 2.28-10 
2019-12-12 19:31:44 status unpacked libc6:i386 2.28-10
2019-12-12 19:31:44 status half-configured libc6:i386 2.28-10
2019-12-12 19:31:46 status installed libc6:i386 2.28-10
2019-12-13 16:52:18 upgrade libc6:i386 2.28-10 2.29-6
2019-12-13 16:52:18 status half-configured libc6:i386 2.28-10
2019-12-13 16:52:18 status unpacked libc6:i386 2.28-10
2019-12-13 16:52:18 status half-configured libc6:amd64 2.28-10
2019-12-13 16:52:18 status half-installed libc6:i386 2.28-10
2019-12-13 16:52:19 status unpacked libc6:i386 2.29-6
2019-12-13 16:52:19 upgrade libc6:amd64 2.28-10 2.29-6
2019-12-13 16:52:19 status unpacked libc6:amd64 2.28-10
2019-12-13 16:52:19 status half-installed libc6:amd64 2.28-10
2019-12-13 16:52:20 status unpacked libc6:amd64 2.29-6
2019-12-13 16:52:20 install libcrypt1:amd64  1:4.4.10-5
2019-12-13 16:52:20 status half-installed libcrypt1:amd64 1:4.4.10-5
2019-12-13 16:52:20 status unpacked libcrypt1:amd64 1:4.4.10-5
2019-12-13 16:52:20 install libcrypt1:i386  1:4.4.10-5
2019-12-13 16:52:20 status half-installed libcrypt1:i386 1:4.4.10-5
2019-12-13 16:52:20 status unpacked libcrypt1:i386 1:4.4.10-5
2019-12-13 16:52:20 configure libcrypt1:amd64 1:4.4.10-5 
2019-12-13 16:52:20 status unpacked libcrypt1:amd64 1:4.4.10-5
2019-12-13 16:52:20 status half-configured libcrypt1:amd64 1:4.4.10-5
2019-12-13 16:52:20 status installed libcrypt1:amd64 1:4.4.10-5
2019-12-13 16:52:20 configure libc6:amd64 2.29-6 
2019-12-13 16:52:20 status unpacked libc6:amd64 2.29-6
2019-12-13 16:52:20 status half-configured libc6:amd64 2.29-6
2019-12-13 16:52:21 status installed libc6:amd64 2.29-6
2019-12-13 16:52:21 configure libcrypt1:i386 1:4.4.10-5 
2019-12-13 16:52:21 status unpacked libcrypt1:i386 1:4.4.10-5
2019-12-13 16:52:21 status half-configured libcrypt1:i386 1:4.4.10-5
2019-12-13 16:52:21 status installed libcrypt1:i386 1:4.4.10-5
2019-12-13 16:52:21 configure libc6:i386 2.29-6 
2019-12-13 16:52:21 status unpacked libc6:i386 2.29-6
2019-12-13 16:52:21 status half-configured libc6:i386 2.29-6
2019-12-13 16:52:23 status installed libc6:i386 2.29-6
2019-12-13 16:52:23 upgrade libc6-dev:amd64 2.28-10 2.29-6
2019-12-13 16:52:23 status half-configured libc6-dev:amd64 2.28-10
2019-12-13 16:52:23 status unpacked libc6-dev:amd64 2.28-10
2019-12-13 16:52:23 status half-installed libc6-dev:amd64 2.28-10
2019-12-13 16:52:23 status unpacked libc6-dev:amd64 2.29-6
2019-12-13 16:52:23 install libcrypt1-dev:amd64  1:4.4.10-5
2019-12-13 16:52:23 status half-installed libcrypt1-dev:amd64 1:4.4.10-5
2019-12-13 16:52:23 status unpacked libcrypt1-dev:amd64 1:4.4.10-5
2019-12-13 15:52:47 configure libcrypt1-dev:amd64 1:4.4.10-5 
2019-12-13 15:52:47 status unpacked libcrypt1-dev:amd64 1:4.4.10-5
2019-12-13 15:52:47 status half-configured libcrypt1-dev:amd64 1:4.4.10-5
2019-12-13 15:52:47 status installed libcrypt1-dev:amd64 1:4.4.10-5
2019-12-13 15:52:48 configure libc6-dev:amd64 2.29-6 
2019-12-13 15:52:48 status unpacked libc6-dev:amd64 2.29-6
2019-12-13 15:52:48 status half-configured libc6-dev:amd64 2.29-6
2019-12-13 15:52:48 status installed libc6-dev:amd64 2.29-6
root@TMP19396:~#

-- 
ciao,
Marco

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

[Marco d'Itri]

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/
> > > to recover access outside the chroot, by using dpkg -i --force-all
> > > first on libc6_*.deb, then libcrypt1_*.deb. Afterwards, normal recovery
> > > mechanisms apply.
> > I suspect that ldconfig would have been enough to fix this.
> > 
> > Theory A: maybe after all we really need some Pre-Depends in libc6?
> 
> A Depends should be enough, we don't need the package fully configured,
> just unpacked. In the machines that I have upgraded, libcrypt1 is
> unpacked before libc6, so it works.
> 
> I am not sure we can use a Pre-Depends given we have a dependency loop,
> libcrypt1 depends on libc6 and libc6 depends on libcrypt1. In addition
> we also have a Breaks + Replaces...
> 
> > Theory B: did we miss something related to x32?
> 
> On 2019-12-11 17:57, Thorsten Glaser wrote:
> > Given it worked in the amd64-only chroot and on another machine,
> > this most likely only fails if one has more than one architecture
> > enabled in Multi-Arch, perhaps also needs the -dev packages installed
> > to trigger.

> I thing that's the issue. Multi-Arch forces some order for all the
> versions of libc6, and also all the versions of libcrypt1.

So far I have not been able to reproduce this. My attempt:

debootstrap --arch=amd64 --variant=buildd buster mabuster 
http://ftp.it.debian.org/debian/
chroot mabuster/
dpkg --add-architecture i386
apt update
apt install whois:i386
perl -i -pe s/buster/unstable/ /etc/apt/sources.list
apt update
apt install libc6

Filtered output from apt:

Preparing to unpack .../archives/libc6_2.29-6_i386.deb ...
De-configuring libc6:amd64 (2.28-10) ...
Unpacking libc6:i386 (2.29-6) over (2.28-10) ...
Preparing to unpack .../libc6_2.29-6_amd64.deb ...
Unpacking libc6:amd64 (2.29-6) over (2.28-10) ...
Setting up libc6:amd64 (2.29-6) ...
Setting up libc6:i386 (2.29-6) ...
Preparing to unpack .../libc6-dev_2.29-6_amd64.deb ...
Unpacking libc6-dev:amd64 (2.29-6) over (2.28-10) ...
Setting up libc6-dev:amd64 (2.29-6) ...

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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, normal recovery
> mechanisms apply.
I suspect that ldconfig would have been enough to fix this.

Theory A: maybe after all we really need some Pre-Depends in libc6?

Theory B: did we miss something related to x32?

Is this an x32 perl?

> Preparing to unpack .../0-libc6_2.29-6_x32.deb ...
> De-configuring libc6:i386 (2.29-3) ...
> De-configuring libc6:amd64 (2.29-3) ...
> Unpacking libc6:x32 (2.29-6) over (2.29-3) ...
> Preparing to unpack .../1-libc6_2.29-6_amd64.deb ...
> /usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot 
> open shared object file: No such file or directory
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-vKsDE7/1-libc6_2.29-6_amd64.deb (--unpack):
>  new libc6:amd64 package pre-installation script subprocess returned error 
> exit status 127

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 it.
libxcrypt1-dev and libxcrypt2-dev cannot be installed at the same time, 
but libxcrypt1 and libxcrypt2 can.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#940596: upgrading libjbig2dec0 broke mupdf

[Marco d'Itri]

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 /usr/lib/x86_64-linux-gnu/libjbig2dec.so.0 | grep 
jbig2_ctx_new
3a40 T jbig2_ctx_new_imp
md@bongo:~$

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), 
LANGUAGE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mupdf depends on:
ii  libc62.29-1
ii  libfreetype6 2.9.1-4
ii  libharfbuzz0b2.6.1-3
ii  libjbig2dec0 0.16+20190905-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libopenjp2-7 2.3.0-2
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  zlib1g   1:1.2.11.dfsg-1+b1

mupdf recommends no packages.

Versions of packages mupdf suggests:
pn  mupdf-tools  

-- no debconf information

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 
> dance on a libc-* package then they will have to run again the 
> conversion program.
I am lowering the severity of this bug since it does not appear that it
will be fixed soon and that just running the conversion again will 
restore the correct directories layout.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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
> depending on the architecture. Note that this part is done by usrmerge,
> but doesn't appear in its description, nor in the debconf question
> asked to the user. It is important to note that it is done directly on
> the filesystem and that this change is not known to dpkg.
I do not think that describing this implementation detail would be 
generally useful to users, but you are right. This complexity is an 
effect of having to keep supporting non-merged systems, but I am not 
willing to fight that battle right now. 

> There is nothing special done with that regard in the glibc maintainer
> scripts.
Agreed.

> The usrmerge people considers that it has to be fixed in the glibc
> maintainer scripts.
I am not dead set on this, but so far it seems to me that, as long as we 
need to keep supporting non-merged systems, such a solution would both 
solve all issues and be the simplest one to implement, as long as it is 
correctly defined in scope.

> As explained above, it would mean that the preinst
> script is responsible, if usrmerge is activated, to create the
> /lib{32,64,o32,x32} -> /usr/lib{32,64,o32,x32} symlink if it doesn't
> exist. The directory might not be empty as a result of a partial
> conversion to usrmerge (yes those system will exists). In turn this
An half-converted system is (more or less) broken and it is not libc's 
responsability to fix it. Pseudocode:

# is this a merged-/usr system?
if [ -L /lib ]; then
  # has the link already been created?
  if [ -L /lib32/ ]; then
:
  # if it has not, is a directory already there?
  elif [ ! -d /lib32/ ]; then
# if not, then create it
ln -s /usr/lib32/ /lib32/
# is this needed or not?
[ -d /usr/lib32/ ] || mkdir /usr/lib32/
  fi
fi

Implementing this would cover all non-pathological cases and improve on 
the current situation.

> directory might be the one of the dynamic linker used for executing
> the maintainer scripts (dash/bash, coreutils). So this means the
> maintainer scripts have to handle the case of moving the dynamic
> linker without breaking the system.
No, it would never attempt to move any file: either e.g. /lib32/ does 
not exist, and then libc6-* would create the link, or it does, and that 
system is half-converted but it's not libc's fault, and continuing to 
install some of the files in / would not break anything.

> In short it means *the most tricky part of usrmerge has to be
> implemented and maintained in the glibc preinst scripts*. This is even
I disagree: only the most basic function would need to be implemented by 
the libc packages: creating a symlink if one is needed and it does not 
already exist.
I would definitely never propose to move to other packages the migration 
support currently implemented in usrmerge.

> more difficult as the preinst script will be executed all the time and
> not when the user ask for that. It won't ask the user for its permission
> before. It doesn't have the option to abort if something looks wrong as 
> this will lead to a system difficultly recoverable for many users if
> they are dist-upgrading their system to a new release (usually apt-get
> install -f is not enough).
As explained, I think that this code can always be successful.

> Therefore I really believe the best solution for this issue is to
> make dpkg aware of the symlink, which means creating a package
> containing this symlinks. This could be for example:
> - in base-files, for example by depending on base-files-usrmerge |
>   base-files-nousrmerge
I wonder what the base-files and deboostrap maintainers think about 
this, since it would require some changes in their packages (non-trivial 
ones in deboostrap, I think).
This also has the downside that this way it would be impossible to 
delete the /libx32/ etc links when they are not needed, since they would 
be created every time the package is updated.

> - in usrmerge after reconsidering that the package can be uninstalled
>   after the conversion.
I am not sure that this could actually work: if the converter package is 
designed to be installed on a non-merged system to convert it, what 
would happen when it tried to install a /lib/ -> /usr/lib/ link in such 
a non-merged system, where /lib/ already is a directory?
(It would also have all the downsides of the precedent point and 
moreover require installing three extra Perl modules on every Debian 
system.)
But let's assume that there would be also a base-files-usrmerge package 
just to provide the links, to be installed later: how could this be 
automated by the converter package, since dpkg does not support being 
invoked by itself?

> - directly in the libc6 and libc6-xxx packages if the TC reconsiders the
>   

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

[Marco d'Itri]

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 system, so it cannot do this.

Putting the links inside some package would not solve the problem of 
e.g. /lib32/ and /libx32/ being always created even on systems which do 
not need them.
And worse, deleting them would become impossible because they would be 
created again every time the package is upgraded.

Doing this in base-files would require having both a "base-files" and 
a "base-files-not-merged" package as long as we will keep supporting 
non-merged systems, and I think that the complexity of managing this
(in deboostrap and possibly somewhere else) makes this a non-starter.

If this were implemented in a different package then it would need to be 
Essential (and still require special-casing in debootstrap as long as we
will want to support non-merged systems), so I am not sure if this plan 
would be accepted by all the stakeholders.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 I hoped that this could be implemented, to stop having 
useles e.g. /libx32/ on all amd64 systems which will never see x32 
packages.

> As explained it's not a bug of the glibc package, but a design flaw of
> usrmerge. I am therefore reassigning the bug to debootstrap + usrmerge.
Do you have any suggestions about how you would like this to be fixed?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 base-files in buster.
I strongly object to adding this package, and its dependency 
gettext-base, to the transitive essential set.
There are many situations where this package is not needed (e.g. 
containers, where Debian is already quite suboptimal) and it is wrong to 
force it on every system because it wastes disk space and may cause 
future troubles (and it already doing this now).

This is not acceptable for a package with such a low popcon ranking.

I tried installing it (I had never heard of it before) and I see that it 
immediately complains about the version of binutils currently in 
unstable, so I also have serious doubts about the usefulness of 
a security tool which will always report an alarm.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 over a network link directly actually has a smaller footprint.
A MAJOR use case is to share /usr among different containers so that 
they use the same software (which then can be updated centrally) but 
different data and configurations.
It is a longer term goal of some projects to support booting new 
a system with empty /etc and /var directories, i.e. basically an empty 
/ partition and software coming from the (possibly read only, possibly 
snapshotted, etc) /usr partition.

> * booting with `/` only is not systematically tested in Debian anymore;
Nowadays this will surely to not work at all, at least in a default 
install. E.g. libkmod2 is in /usr/lib/.
I think that it can be safely said that Debian does not support booting 
systems with a standalone /usr/ and no initramfs.

> In Debian buster, the current testing suite, "merged `/usr`" is only 
> considered
> for implementation with symlinks (there are no proposals for simply dropping
> `/{bin,sbin,lib*}`) and is implemented in two main ways:
For clarity: I am not aware of anybody anywhere proposing to drop the 
/{bin,sbin,lib*} links, for Debian or any other distribution.

Thank you for this excellent summary.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 implementing that in 
https://salsa.debian.org/md/usrmerge/tree/initramfs, but it does not 
work because I was not able to open an interactive shell from the 
initramfs script.
Some help from people familiar with initramfs-tools would be 
appreciated.

BTW, that branch also contains a simple script which can be used to 
run the current system in KVM with a throwaway snapshot, to be able to 
try usrmerge with no consequences.

> This remains true even if the usrmerge package is subsequently removed,
> if it was ever installed. The symlinks /bin, /sbin, /lib* remain present,
A clarification: usrmerge is supposed to be removed after the conversion.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#915883: usrmerge: missing dependency on perl

[Marco d'Itri]

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 indirect dependency on perl thanks to 
libfile-find-rule-perl.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#914897: debating the wrong thing

[Marco d'Itri]

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 conditions (which I do not believe 
would be possible).

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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? As far as I know, the reason
> usrmerge exists is so that no files will be installed in /bin anymore;
> but that seems like an XY problem.
https://lists.debian.org/20181121140542.ga31...@espresso.pseudorandom.co.uk

> Also, I would like to ask why the traditional solution in Debian -- make
> a policy change that says no package can ship anything in /bin except
> for a compatibility symlink, and make that rule RC at some point in the
> future -- is not being considered. That seems like a solution that would
> cause far less pain than what we're going through right now.
This is not a solution. For a start it would take many years.
Even ignoring that, it would not bring any improvement over the current 
plan: even if your idea were executed perfectly and quickly then the 
conversion program would still be in the same exact situation as it is 
now: either everything in /bin/, /sbin and /lib (and its own 
subdirectories) was created by the packaging system, and then we already 
know that it can be converted automatically, or it was not, and then we 
know that there are a few cases when the local administrator has to 
decide what to do about things that were installed by himself in the 
past in the wrong place.
So this would make the transition unacceptably slow while providing no 
benefit at all, but it would also cost a huge amount of work to change 
many packages.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#914897: affects private debs too

[Marco d'Itri]

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 debootstrap default) for six months with 
only minor problems.
With growing adoptions we have found and addressed the bugs, and 
currently the only significant issue still open is #913883 (iptables 
doing diversions, which I am sure can be fixed).

How much experience do you have in using merged-/usr systems?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 you want to override this setting then you can create a file in 
/etc/modprobe.d/ which sorts after systemd.conf or even a new 
/etc/modprobe.d/systemd.conf which will override it completely.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 
can be safely removed from unstable (and stable too, if appropriate).

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 signature

Bug#882247:

[Marco d'Itri]

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

[Marco d'Itri]

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 sub-standard packages.
While my memory could be faulty in some way since that was 20 years ago, 
I know that my first package was first uploaded to contrib because of 
technical reasons.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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

[Marco d'Itri]

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 already expressed clearly my position.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#761658: urgency of a fix before stretch

[Marco d'Itri]

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 maintainers I am explicitly and publicly 
requesting that you do not introduce this unwanted change.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 much better goal.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 had this in jessie and it did not cause noticeable problems 
I would rather keep the names as they are.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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, since it is our "good" inetd package.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 signature

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

[Marco d'Itri]

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 Alias=.
Such a link already exists.
Is there anything else that I should do or should I close this bug?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 method from this package. At least in two ways,
> when doing:
This is being addressed in #134758.

> From casual inspection it appears that packages calling dpkg or
> dpkg-query with -S or --search can potentially break stuff. Things
I can't see why they should break: obviously any maintainer script using 
dpkg-query will query for the actual path in the package, or else it 
would not work on non-merged systems.
Over one year of experience with merged-/usr systems has not exposed any 
failures.

Lacking concrete examples of regressions and considering the fact that 
this cannot be solved by the usrmerge package, I am lowering the 
severity of this bug.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#848504: usrmerge breaks various systemd symlinks

[Marco d'Itri]

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 guess how to resolve 
the / vs. /usr files conflicts.
Check the two relevant code paths in /usr/lib/convert-usrmerge for 
details.

Before the conversion you had:
/usr/lib/systemd/system/dbus-org.freedesktop.hostname1.service => 
systemd-hostnamed.service (correct)
/usr/lib/systemd/system/systemd-hostnamed.service was missing (how is this even 
possible?)
/lib/systemd/system/dbus-org.freedesktop.hostname1.service => 
/usr/lib/systemd/system/dbus-org.freedesktop.hostname1.service (WTF?)

> So what I did not mention before (sorry), is that installing
> usrmerge actually aborted at first, because keepalived installed a
This does not matter: convert-usrmerge is idempotent.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 time to properly debug or the bug
> comes back when /usr-merged comes back as a default…
Unreproducible for me too:

# debootstrap --merged-usr --variant=minbase --include=exim4-config stretch 
root http://.../debian/
# ls -l
totale 4
drwxr-xr-x 17 root root 4096 Dec 12 04:48 root/
# chroot root/ /bin/sh -c 'getent passwd mail'
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
#

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#828351: inn2: FTBFS with openssl 1.1.0

[Marco d'Itri]

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,
Marco


signature.asc
Description: PGP signature

Bug#843073: Debian Installer Stretch Alpha 8 release

[Marco d'Itri]

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) until 
very recently.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 anymore, though I couldnt find this in
> debootstrap's changelog, so maybe I'm confused.
I can't see how this could be related to the usrmerge patch.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

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 binaries?) appear twice? (Or do I
> misunderstand how this is implemented?).
This has been the only significant issue so far.
Red Hat released RHEL7 with a merged /usr and I am not aware of any 
troubles.

> Like Guillem, I'd be a lot happier if files, especially libraries,
> only existed in the place they existed, and if we want to move that
> then we should move it in the packaging. Isn't there potential for
> autoconf or libtool to get confused too?
Apparently not.
We will never be able to remove the /{lib*,bin,sbin} symlinks (they are 
more or less all requires by ABIs), but sooner or later we should drop 
support for non-merged systems and just install everything in /usr.

-- 
ciao,
Marco


signature.asc
Description: PGP signature