Bug#995817: ERROR: Could not resolve symbol: /proc/self/exe:BEGIN_trigger

[Salvatore Bonaccorso]

Hi Vincent,

On Mon, Nov 15, 2021 at 08:32:33AM +0100, Vincent Bernat wrote:
>  ❦ 15 November 2021 07:51 +01, Salvatore Bonaccorso:
> 
> >> I have tried to just not strip the binary, but this produces a quite
> >> huge binary. I didn't get time to investigate much yet.
> >
> > Asked a bit around, and got the following hint from Niels Thykier:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595810#10
> >
> > so that might work, first exclude with -X in dh_strip and then call
> > strip manually, keeping BEGIN_trigger and END_trigger.
> >
> > Niels, thanks for the pointer!
> 
> Thanks! It works. I have uploaded the new version to unstable.

\o/ Thank you!

Regards,
Salvatore

Bug#995817: ERROR: Could not resolve symbol: /proc/self/exe:BEGIN_trigger

[Vincent Bernat]

 ❦ 15 November 2021 07:51 +01, Salvatore Bonaccorso:

>> I have tried to just not strip the binary, but this produces a quite
>> huge binary. I didn't get time to investigate much yet.
>
> Asked a bit around, and got the following hint from Niels Thykier:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595810#10
>
> so that might work, first exclude with -X in dh_strip and then call
> strip manually, keeping BEGIN_trigger and END_trigger.
>
> Niels, thanks for the pointer!

Thanks! It works. I have uploaded the new version to unstable.
-- 
Make the coupling between modules visible.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#727692: gerbv: project file does not save all settings

[Carsten Schoenert]

Hello Tobias,

upstream did release new versions of gerbv.
I've uploaded 2.8.0-1 to unstable recently.

Upstream also moved now to GitHub and there is now also a bug report
with the exact same topic as you reported in the past into the Debian BTS.

https://github.com/gerbv/gerbv/issues/65

If you have new discoveries, specially in the new version of gerbv
please forward them to the bug report on GH.

-- 
Regards
Carsten

Bug#999507: [Pkg-rust-maintainers] Bug#999507: Bug#999507: rust-tokio-signal, (build-)dependencies unsatisfiable, abandoned upstream, should this package be removed.

[Fabian Grünbichler]

On November 12, 2021 1:11 pm, Henry-Nicolas Tourneur wrote:
> 
> 
> Le ven 12 nov 2021 à 10:18, Fabian Grünbichler 
>  a écrit :
>> On November 12, 2021 6:38 am, Peter Green wrote:
>>>  Package: rust-tokio-signal
>>>  Version: 0.2.7-2
>>>  Severity: serious
>>> 
>>>  rust-tokio-signal (build-)depends on version 0.1 of rust-futures. 
>>> Upstream seems to
>>>  have abandoned the project, there was an alpha release supporting 
>>> futures 0.2, but
>>>  the code appears to have been removed from the tokio git 
>>> repository. So I presume
>>>  it is abandoned upstream.
>>> 
>>>  There are no reverse dependencies in testing, there is a single 
>>> reverse dependency
>>>  in unstable which is rc buggy and also appears to be abandoned 
>>> upstream.
>>> 
>>>  If there are no objections in a few weeks, I intend to file a 
>>> removal request.
>> 
>> same here, tokio-signal is now tokio+signal ;) accordingly, it can be
>> RMed with the rest of the legacy tokio 0.1 crates once tokio 1.0 has
>> been uploaded
>> 
> 
> I would not even wait for tokio 1.0 upload and request removal of 
> tokio-signal could be done right away.
> 
> As it stands, it is broken due to unsastifiable build dependencies and 
> it has no reverse dependencies, as Peter explained.
> 
> Fabian, I see no point in keeping tokio-signal in the archive in its 
> current state and the package is going away anyway as you mentionned it 
> being superseeded by tokio+signal.
> 
> Do you see any reasons to keep it until tokio 1.0 upload?

no, the RMs can be filed now as well of course, I just figured it's 
easier to see which ones (also third-party related crates) go into the 
RM pile once the successors are packaged, which means less effort for 
all involved parties. but doing the first batch (those part of the 
original tokio 0.1 release itself - see the tokio-process bug) now is 
fine as well, we can always do a second batch post-uploads for any 
remaining stuff.

Bug#999693: php8.1: Regular expression functions warn "Compilation failed" and return null

[Ondřej Surý]

Hi,

is your system fully upgraded?

What’s libpcre2 version?

Ondřej
--
Ondřej Surý  (He/Him)

> On 15. 11. 2021, at 2:51, Matthew Krauss  wrote:
> 
> Package: php8.1-common
> Version: 8.1.0~rc5-1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: zeros0and1o...@yahoo.com
> 
> Dear Maintainer,
> 
> After installing php8.1 on testing, I found that most PHP packages are
> failing. For instance, composer, whether installed directly from
> getcomposer.org, or through the Debian package, is broken by this bug,
> as well as likely the vast majority of PHP based software.
> 
> The problem seems to be in an underlying regexp library, I *think*,
> and seems to break most of the built in php regexp functions.
> 
> Simple demonstration, with both php7.4 and php8.1 installed:
> 
> $ php7.4 -r 'var_export(preg_replace("/foo/", "bar", "some foo here")); echo 
> "\ndone\n";'
> 'some bar here'
> done
> 
> $ php8.1 -r 'var_export(preg_replace("/foo/", "bar", "some foo here")); echo 
> "\ndone\n";'
> PHP Warning:  preg_replace(): Compilation failed: unrecognised compile-time 
> option bit(s) at offset 0 in Command line code on line 1
> NULL
> done
> 
> The php7.4 command runs correctly and is what I would expect. The php8.1 
> command generates a warning, as well as incorrect output.
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>  APT prefers testing
>  APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU threads)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages php8.1 depends on:
> ii  libapache2-mod-php8.1  8.1.0~rc5-1
> ii  php8.1-common  8.1.0~rc5-1
> 
> php8.1 recommends no packages.
> 
> php8.1 suggests no packages.
> 
> Versions of packages php8.1-common depends on:
> ii  libc6   2.31-17
> ii  libffi8 3.4.2-3
> ii  libssl1.1   1.1.1l-1
> ii  php-common  2:76
> ii  ucf 3.0043
> 
> -- no debconf information
> 

Bug#995817: ERROR: Could not resolve symbol: /proc/self/exe:BEGIN_trigger

[Salvatore Bonaccorso]

Hi Vincent,

On Sat, Nov 13, 2021 at 03:58:26PM +0100, Vincent Bernat wrote:
>  ❦ 13 November 2021 15:06 +01, Salvatore Bonaccorso:
> 
> >> > In fact, it does not happen if you have debug symbols. My patch does not
> >> > work anymore either and the previous upload did not fix this bug. Some
> >> > distributions work around that by asking "strip" to keep BEGIN_trigger.
> >> > It seems we cannot do that easily with dh_strip.
> >> 
> >> Confirmed!
> >> 
> >> No idea on the solution though.
> >
> > Any idea on how to bring that back?
> 
> I have tried to just not strip the binary, but this produces a quite
> huge binary. I didn't get time to investigate much yet.

Asked a bit around, and got the following hint from Niels Thykier:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595810#10

so that might work, first exclude with -X in dh_strip and then call
strip manually, keeping BEGIN_trigger and END_trigger.

Niels, thanks for the pointer!

Regards,
Salvatore

Bug#999446: Acknowledgement (cups: Does not print a test page: I enter name and password, but does not accept them)

[Питерцев Эдуард Николаевич]

  
  
You can close the bug. Found the reason. 
  The printer has a restriction on access: only to the lov user. 
  The root user is not included in this permission, therefore, he
  cannot print a test page through the menu in the web.
Sorry for bother


  

Bug#834724:

[Jerry Kocmen]

Bug#999417: Blank line in plymouthd.conf silently breaks it

[Trent W. Buck]

PS: I reran my test script with "sid" instead of "bullseye", and
the problem still exists in sid.  It also includes lsinitramfs output.

Trent W. Buck wrote:
> > I just tried now with plymouth version 0.9.5+git20211018-1, after adding a
> > white space in the configuration file and regenerating the initramfs (with
> > update-initramfs -u) I can see the theme in initramfs (lsinitramfs) and the
> > bgrt theme is properly used.
> > 
> > How did you regenerate the initramfs? Does lsinitramfs show you the theme
> > files inside the initramfs? Could you try with 0.9.5+git20211018-1 and see
> > if it makes a difference?
> 
> OK here's a script (attached) that should reliably show
> 1) working behaviour; then
> 2) failing behaviour.


plymouth-issue-test.sh
Description: Bourne shell script
bash5$ /home/twb/Desktop/bootstrap2020/plymouth-issue-test.sh
#!/bin/bash -v

build=(
mmdebstrap sid tmp.squashfs
--aptopt='Acquire::http::Proxy "http://localhost:3142;'
--include=plymouth-themes,linux-image-generic,init,live-boot,pigz
--dpkgopt=force-unsafe-io
--dpkgopt=force-confold # dpkg, don't pause because I edited 
plymouth.conf before you
--essential-hook='mkdir -p $1/etc/plymouth'
--essential-hook='copy-in plymouthd.conf /etc/plymouth/'
--customize-hook='download /vmlinuz vmlinuz'
--customize-hook='download /initrd.img initrd.img'
--customize-hook='chroot $1 dpkg-query -W plymouth plymouth-themes'
--customize-hook='chroot $1 lsinitramfs -l /initrd.img | grep plymouth'
)
test=(
kvm
-m 1024 # without this, not enough ram to start the 
initrd!
-hda tmp.squashfs
-kernel vmlinuz
-initrd initrd.img
-append 'splash boot=live plainroot root=/dev/sda'
)

# With no \n\n, plymouthd shows correct spinner animation on black background 
(bgrt inherits from spinner).
printf '[Daemon]\nTheme=bgrt\n' >plymouthd.conf && "${build[@]}" && "${test[@]}"
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: squashfs
I: using /tmp/mmdebstrap.0JUC5aHB_o as tempdir
W: tar2sqfs does not support extended attributes from the 'system' namespace
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing essential packages...
done
I: running --essential-hook in shell: sh -c 'mkdir -p $1/etc/plymouth' exec 
/tmp/mmdebstrap.0JUC5aHB_o
I: running special hook: copy-in plymouthd.conf /etc/plymouth/
I: downloading apt...
done
I: installing apt...
done
I: installing remaining packages inside the chroot...
done
done
done
I: running special hook: download /vmlinuz vmlinuz
I: running special hook: download /initrd.img initrd.img
I: running --customize-hook in shell: sh -c 'chroot $1 dpkg-query -W plymouth 
plymouth-themes' exec /tmp/mmdebstrap.0JUC5aHB_o
plymouth0.9.5+git20211018-1
plymouth-themes 0.9.5+git20211018-1
I: running --customize-hook in shell: sh -c 'chroot $1 lsinitramfs -l 
/initrd.img | grep plymouth' exec /tmp/mmdebstrap.0JUC5aHB_o
drwxr-xr-x   2 root root0 Nov 15 05:52 etc/plymouth
-rw-r--r--   1 1000 1000   20 Nov 15 05:51 
etc/plymouth/plymouthd.conf
-rwxr-xr-x   1 root root  151 Nov 10 15:45 
scripts/init-bottom/plymouth
-rwxr-xr-x   1 root root  472 Nov 10 15:45 
scripts/init-premount/plymouth
-rwxr-xr-x   1 root root  155 Nov 10 15:45 scripts/panic/plymouth
-rwxr-xr-x   1 root root47880 Nov 10 15:45 usr/bin/plymouth
drwxr-xr-x   3 root root0 Nov 15 05:52 
usr/lib/x86_64-linux-gnu/plymouth
-rw-r--r--   1 root root18944 Nov 10 15:45 
usr/lib/x86_64-linux-gnu/plymouth/details.so
-rw-r--r--   1 root root14664 Nov 10 15:45 
usr/lib/x86_64-linux-gnu/plymouth/label.so
drwxr-xr-x   2 root root0 Nov 15 05:52 
usr/lib/x86_64-linux-gnu/plymouth/renderers
-rw-r--r--   1 root root60416 Nov 10 15:45 
usr/lib/x86_64-linux-gnu/plymouth/renderers/drm.so
-rw-r--r--   1 root root35632 Nov 10 15:45 
usr/lib/x86_64-linux-gnu/plymouth/renderers/frame-buffer.so
-rw-r--r--   1 root root23200 Nov 10 15:45 
usr/lib/x86_64-linux-gnu/plymouth/text.so
-rw-r--r--   1 root root69032 Nov 10 15:45 
usr/lib/x86_64-linux-gnu/plymouth/two-step.so
drwxr-xr-x   2 root root0 Nov 15 05:52 usr/libexec/plymouth
-rwxr-xr-x   1 root root14600 Nov 10 15:45 
usr/libexec/plymouth/plymouthd-fd-escrow
-rwxr-xr-x   1 root root   151584 Nov 10 15:45 usr/sbin/plymouthd
drwxr-xr-x   3 root root0 Nov 15 05:52 usr/share/plymouth
-rw-r--r--   1 root root 5834 Nov 15 05:52 
usr/share/plymouth/debian-logo.png
-rw-r--r--   1 root root  139 Nov 10 15:45 
usr/share/plymouth/plymouthd.defaults
drwxr-xr-x   6 root root0 Nov 15 05:52 usr/share/plymouth/themes
drwxr-xr-x   2 root root   

Bug#999417: Blank line in plymouthd.conf silently breaks it

[Trent W. Buck]

Laurent Bigonville wrote:
> On Thu, 11 Nov 2021 06:24:53 +1100 "Trent W. Buck" 
> wrote:
> 
> > See attached example files.
> 
> Could you please explain a bit more what's not working?

Sorry, I thought my report included more information than it did.
This is the actual commit that fixed it for me:

https://github.com/cyberitsolutions/bootstrap2020/commit/af75998

The behaviour I see is that plymouth shows a splash screen, but
it uses the fallback "text" theme, with the "█ █ █" three rectangles,
with a spinner on a Tango dark grey background (#2E3436).

When plymouthd.conf contains no \n\n sequences, I see the correct bgrt theme,
with an animated spinner (white circle on black background).

> I just tried now with plymouth version 0.9.5+git20211018-1, after adding a
> white space in the configuration file and regenerating the initramfs (with
> update-initramfs -u) I can see the theme in initramfs (lsinitramfs) and the
> bgrt theme is properly used.
> 
> How did you regenerate the initramfs? Does lsinitramfs show you the theme
> files inside the initramfs? Could you try with 0.9.5+git20211018-1 and see
> if it makes a difference?

Let me see if I make a full test recipe... hrm, not easily.
I will instead include the "before" and "after" ramdisks and kernel.
...hrm, they're 40MB each, not really suitable for email.

The actual images are identical except for the plymouthd.conf and some 
fontconfig cache files.
That suggests the problem is inside the plymouthd C code itself.

OK here's a script (attached) that should reliably show
1) working behaviour; then
2) failing behaviour.


plymouth-issue-test.sh
Description: Bourne shell script

Bug#998809: Acknowledgement (jami: No echo cancellation on pipewire-pulse)

[Bruno Kleinert]

I found a workaround:
   1. Copy /usr/share/pipewire/pipewire-pulse.conf to
  ~/.config/pipewire/
   2. Edit and add { name = libpipewire-module-echo-cancel } into
  section context.modules = [ … ]
   3. systemctl --user restart pipewire-pulse.service
   4. Check with pavucontrol if the virtual device 'Echo Cancel
  Capture' records from the desired physical device
   5. In Jami's media settings, select 'Echo Cancel sink' and 'Echo
  Cancel source' as recording and output devices


In jami-daemon src/media/audio/pulseaudio/pulselayer.cpp I found some
"magic" related to PulseAudio's echo-cancel module, but I don't
understand how that does the trick for PulseAudio and if that is
supposed to also work with PipeWire.


signature.asc
Description: This is a digitally signed message part

Bug#997189: liboping: FTBFS: oping.c:1159:25: error: format not a string literal and no format arguments [-Werror=format-security]

[Kentaro Hayashi]

FYI: For the latter case, it seems that it has already submitted a fix as a PR.

See https://github.com/octo/liboping/pull/60/files

On Sat, 23 Oct 2021 21:06:58 +0200 Lucas Nussbaum  wrote:
> > oping.c: In function ‘update_host_hook’:
> > oping.c:1640:38: error: too many arguments for format 
> > [-Werror=format-extra-args]
> >  1640 | HOST_PRINTF ("%zu bytes from %s (%s): 
> > icmp_seq=%u ttl=%i ",
> >   |  
> > ^
> > oping.c:1617:45: note: in definition of macro ‘HOST_PRINTF’
> >  1617 | # define HOST_PRINTF(...) wprintw(main_win, __VA_ARGS__)
> >   | ^~~
> > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 
> > -Wall -Werror -g -O2 -ffile-prefix-map=/<>=. 
> > -fstack-protector-strong -Wformat -Werror=format-security -c liboping.c -o 
> > liboping_la-liboping.o >/dev/null 2>&1
> > cc1: all warnings being treated as errors
> > make[4]: *** [Makefile:598: noping-oping.o] Error 1

Bug#994405: libgmp10:i386: buffer overflow due to integer overflow in mpz/inp_raw.c on 32-bit machines

[Anton Gladky]

CVE-2021-43618 is assigned to this issue.

Adrian Bunk  schrieb am Sa., 13. Nov. 2021, 21:09:

> On Fri, Sep 17, 2021 at 07:02:48AM +0200, Anton Gladky wrote:
> > Thanks, Vincent, for the information. I would still wait for CVE,
> > so we can apply a patch and track vulnerability for other
> > Debian versions (stable/oldstable/o-o-stable etc.).
>
> Hi Anton,
>
> did you manage to get a CVE assigned for this issue, or has there been
> any problem with tnat?
>
> > Regards
> >
> > Anton
>
> Thanks
> Adrian
>

Bug#999470: wsjtx: Stable backport wsjt-x 2.5.2

[tony mancill]

On Sat, Nov 13, 2021 at 12:49:11PM +0100, Christoph Berg wrote:
> Re: tony mancill
> > > It would be great if you could make a backport of wsjtx 2.5.2 for 
> > > bullseye.
> > 
> > The backport of wsjtx appears to be trivial once hamlib 4.1 or newer is
> > available in bullseye, and that backport looks relatively simple too.
> > 
> > Looking at hamlib, I see that the backport of hamlib 4.3 includes
> > libhamlib4, which declares "Breaks: wsjtx (<< 2.4.0~)".  This might be a
> > little interesting for users who expect hamlib to remain at version 4.0
> > for other reasons (although I don't know what those would be), since the
> > upgrade will require hamlib and wsjtx to update at the same time.
> > 
> > Any thoughts or concerns from others on the team about proceeding with
> > hamlib and wsjtx for bullseye-backports?
> 
> I'm not 100% sure, but I think I added that Breaks to make sure wsjtx
> is upgraded if hamlib is upgraded. wsjtx in either version should work
> fine with hamlib in either version, but the version at compile time
> needs to be the same at run time.
> 
> So the wsjtx backport is likely just wsjtx, without hamlib. Testing
> that just requires starting it up and checking if it can talk to your
> TRX properly.

Building against hamlib 4.0 (clean bullseye chroot) fails with errors
like this:

/<>/Transceiver/HamlibTransceiver.cpp:60:66: error: 
‘RIG_CAPS_MFG_NAME_CPTR’ was not declared in this scope
   60 | key = QString::fromLatin1 (rig_get_caps_cptr (rig_model, 
RIG_CAPS_MFG_NAME_CPTR)).trimmed ()
  |  
^~

There are 51 errors in total.

> Hamlib doesn't seem as compatible as the no-soname-change suggests, I
> also had to recompile fldigi to have it work with Hamlib 4.3 here (at
> least via rigctld).

In that case, it sounds like the next step is try to backport to wsjtx
2.5.x to hamlib 4.0.

Cheers,
tony

Bug#999696: i3-wm: Please Depends or Recommends dex

[Arnaud Rebillout]

Source: i3-wm
Version: 4.20-1
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

starting version 4.20, i3 uses dex to honor XDG autostart [1]. It would
be nice to have i3-wm Depends or Recommends dex then.

Cheers,

  Arnaud

[1]: https://github.com/i3/i3/blob/4.20/RELEASE-NOTES-4.20#L38

Bug#999695: systemd: emergency/rescue targets fail to stop journald

[westlake]

Package: systemd
Version: 247.3-6
Severity: normal

Upon booting up with "systemd.unit=emergency.target" to the kernel 
bootline, there are no systemd-journald services running.


However if the user boots normally into multi-user or graphical targets, 
and types "systemctl isolate emergency" or "systemctl emergency", debian 
does not stop systemd-journald services.


this is a problem noticeably if the user wants to perform work on "/" 
with "mount -o ro,remount /".


please fix this
thanks

scott

Bug#999694: postfix: postconf outputs 2 bounce_notice_recipient lines

[Vincent Lefevre]

Package: postfix
Version: 3.5.13-1
Severity: minor

zira:~> postconf | grep '^bounce_notice_recipient'
bounce_notice_recipient = postmaster
bounce_notice_recipient = postmaster

A single line would be sufficient.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages postfix depends on:
ii  adduser3.118
ii  cpio   2.13+dfsg-7
ii  debconf [debconf-2.0]  1.5.79
ii  dpkg   1.20.9
ii  e2fsprogs  1.46.4-1
ii  libc6  2.32-4
ii  libdb5.3   5.3.28+dfsg1-0.8
ii  libicu67   67.1-7
ii  libnsl21.3.0-2
ii  libsasl2-2 2.1.27+dfsg-2.3
ii  libssl1.1  1.1.1l-1
ii  lsb-base   11.1.0
ii  netbase6.3
ii  ssl-cert   1.1.1

Versions of packages postfix recommends:
ii  ca-certificates  20211016
ii  python3  3.9.7-1

Versions of packages postfix suggests:
ii  bsd-mailx [mail-reader]  8.1.2-0.20180807cvs-2
ii  emacs-gtk [mail-reader]  1:27.1+1-3.1
ii  libsasl2-modules 2.1.27+dfsg-2.3
ii  mailutils [mail-reader]  1:3.13-1
ii  mutt [mail-reader]   2.0.5-4.1
pn  postfix-cdb  
ii  postfix-doc  3.5.13-1
pn  postfix-ldap 
pn  postfix-lmdb 
pn  postfix-mysql
ii  postfix-pcre 3.5.13-1
pn  postfix-pgsql
pn  postfix-sqlite   
ii  procmail 3.22-26
pn  resolvconf   
pn  ufw  

-- debconf information:
  postfix/retry_upgrade_warning:
  postfix/procmail: true
  postfix/destinations: zira.vinc17.org, 128.119.75.86.rev.sfr.net, 
localhost.vinc17.org, , localhost
  postfix/chattr: false
  postfix/newaliases: false
  postfix/relayhost:
  postfix/kernel_version_warning:
  postfix/main_cf_conversion_warning: true
  postfix/compat_conversion_warning: true
  postfix/relay_restrictions_warning:
  postfix/mailbox_limit: 0
  postfix/bad_recipient_delimiter:
  postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
  postfix/tlsmgr_upgrade_warning:
  postfix/recipient_delim: +
  postfix/rfc1035_violation: false
  postfix/lmtp_retired_warning: true
* postfix/main_mailer_type: Internet Site
  postfix/dynamicmaps_conversion_warning:
  postfix/root_address:
  postfix/mydomain_warning:
* postfix/mailname: zira.vinc17.org
  postfix/protocols: all
  postfix/not_configured:
  postfix/sqlite_warning:

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#991609: postfix/postfix-script: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ

[Vincent Lefevre]

Control: found -1 3.5.13-1

On 2021-07-28 16:10:45 +0200, Vincent Lefevre wrote:
> I also notice this message in the logs (when postfix is started
> automatically), so that this is not new: this already occurred
> on 2020-06-05 at least.
> 
> Indeed:
> 
> -rw-r--r-- 1 root root 197624 2021-01-22 21:43:18 
> /etc/ssl/certs/ca-certificates.crt
> -rw-r--r-- 1 root root 200061 2019-09-20 11:53:51 
> /var/spool/postfix/etc/ssl/certs/ca-certificates.crt

/etc/ssl/certs/ca-certificates.crt had been updated again and
/var/spool/postfix/etc/ssl/certs/ca-certificates.crt still has
the same timestamp:

-rw-r--r-- 1 root root 195453 2021-10-19 01:46:43 
/etc/ssl/certs/ca-certificates.crt
-rw-r--r-- 1 root root 200061 2019-09-20 11:53:51 
/var/spool/postfix/etc/ssl/certs/ca-certificates.crt

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#998565: Errors due to changes in iso-codes data

[Scott Kitterman]

I looked at this a bit today and it looks like the test failures are due to 
updates in the iso-codes data used by the tests, not any real failures.  I 
think disabling the failing tests for now would be a reasonable way to keep 
this in testing (I'm interested to avoid transitive removal of xml2rfc).

Unless there's some objection to this, I will probably NMU later in the week.

Scott K

Bug#999689: reprotest: autopkgtest missing dependency on diffoscope

[Vagrant Cascadian]

Control: tags 999689 pending

On 2021-11-14, Stefano Rivera wrote:
> Fixing #988964 broke the "not need_builddeps" autopkgtest:
> https://ci.debian.net/packages/r/reprotest/unstable/amd64/
>
> It has failed since 0.7.16.
>
> The easy fix is:
> diff --git a/debian/tests/control b/debian/tests/control
> index 8132bdc..e5a47b8 100644
> --- a/debian/tests/control
> +++ b/debian/tests/control
> @@ -1,5 +1,5 @@
>  Test-Command: debian/rules autopkgtest-pytest PYTEST_MARKEXPR="not 
> need_builddeps"
> -Depends: @, python3-pytest, faketime, locales-all, fakeroot
> +Depends: @, diffoscope, python3-pytest, faketime, locales-all, fakeroot
>  
>  Test-Command: debian/rules autopkgtest-pytest 
> PYTEST_MARKEXPR="need_builddeps"
>  Depends: @, @builddeps@, fakeroot


Pushed to git:

  
https://salsa.debian.org/reproducible-builds/reprotest/-/commit/3ed09e34943e49c757ff51796acd557e91547b04

Thanks!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#999681: RFS: ii/1.8-3+ds -- minimalist FIFO and filesystem-based IRC client

[Bastian Germann]

On Sun, 14 Nov 2021 22:42:11 +0100 itd  wrote:

Changes since the last upload:

 ii (1.8-3+ds) unstable; urgency=medium
 .
   * Fix lintian: package-uses-old-debhelper-compat-version
   * autopkgtest smoke-test is superficial
   * Update Vcs-Git/Browser URL
   * Bump standards version to 4.6.0 (no changes required)
   * Update e-mail address
   * Bump debian/watch version to 4
   * Add Bug-Submit metadata
   * Add Upstream-Contact to d/copyright


What do you want to say with +ds behind the Debian revision?
Usually it is used in front of it to signal a repack.
Your package is not a repack, so please remove it.

Please remove the debhelper build dep (but keep debhelper-compat!).

Bug#999692: creates watch files with invalid URLs causing uscan to error

[Nicholas D Steeves]

Package: dh-make-elpa
Version: 0.19.1
Severity: normal

Hi,

This bug has existed for a while, but finally annoyed me enough to
file a bug.  Briefly, it seems like the URLs generated may be designed
for use with mode=git, or with the assumption that all git project
hosting sites will map a https://foo.git URL to https://foo.  Github
is a notable exception.

Here is an example of the type of manual fixup that is required for
all watch files that point to Github:

-opts="filenamemangle=s/(?:.*?)?v?(\d[\d.]*)\.tar\.gz/yaml.el.git-$1.tar.gz/" \
-https://github.com/zkry/yaml.el.git/tags \
+opts="filenamemangle=s/(?:.*?)?v?(\d[\d.]*)\.tar\.gz/yaml.el-$1.tar.gz/" \
+https://github.com/zkry/yaml.el/tags \

The tarball suffix is functionally cosmetic, of course, because uscan
creates an orig.tarball symlink.

Sorry, I will not be submitting an MR, because learning Perl isn't on
my roadmap for the near future ;-)

Regards,
Nicholas

Bug#999691: reprotest: Version check in debian/rules breaks down-stream distro versioning

[Stefano Rivera]

Source: reprotest
Version: 0.7.18
Severity: normal
Tags: patch

Adding a suffix is pretty common in a downstream distro. For example,
Ubuntu adds ubuntu1 when modifying a package, or build1 when doing a
no-change upload (Ubuntu doesn't have binNMUs).

Is the expectation that setup.py should have it's version updated in
this situation? I assume not from the + check, which would exclude
Debian NMUs and binNMUs.

Maybe just check the numeric bit? e.g.
--- a/debian/rules
+++ b/debian/rules
@@ -20,7 +20,7 @@ export PYBUILD_NAME = reprotest
 export REPROTEST_TEST_DONTVARY = fileordering,user_group,domain_host$(if 
$(shell nproc | grep --color=no -Fx 1),$(,)num_cpus,)

 override_dh_auto_configure:
-   test $$(python3 setup.py --version) = $$(echo $(DEB_VERSION) | cut -f1 
-d'+')
+   test $$(python3 setup.py --version) = $$(echo $(DEB_VERSION) | sed 
's/[^0-9.].*//')
dh_auto_configure

 override_dh_auto_build:

SR

Bug#999637: systemd: systemctl help foo.service doesn't work with file:/path/to/README.md

[Nicholas D Steeves]

reopen 999637
tag 999637 upstream
forwarded 999637 https://github.com/systemd/systemd/issues/21369
thanks

Hi Michael,

Michael Biebl  writes:

> On 15.11.21 00:09, Michael Biebl wrote:
>> 
>> On 14.11.21 04:59, Nicholas D Steeves wrote:
>
>>>    Documentation="file:/usr/share/doc/foo/README.md"
>> 
>> Hmm, systemctl help says
>> "
>>     help PATTERN...|PID...
>>     Show manual pages for one or more units, if available.
>> "
>> 
>> You are not pointing Documentation= at a man page though but an 
>> arbitrary file. Try e.g. "systemctl help rsyslog"
>
> Here is the relevant code
> https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/src/systemctl/systemctl-show.c#L792
>
>> STRV_FOREACH(p, i->documentation)
>> if (startswith(*p, "man:"))
>> show_man_page(*p + 4, false);
>> else
>> log_info("Can't show: %s", *p);
>
>
> Afaics, everything is working as documented. Thus closing the bug report.
>

Thank you for the reference, much appreciated!  So it seems that the
documentation at
https://www.freedesktop.org/software/systemd/man/systemd.unit.html is wrong.

> If you think, that systemctl help should handly arbitrary file:/ URLs, 
> please file this as a feature request upstream at
>
> https://github.com/systemd/systemd/issues/new
>

Done, and I've set the relevant tag and forwarded URL so that we'll
receive a notification if upstream is against it.

Kind regards,
Nicholas

Bug#999690: ITP: qt6-multimedia -- Qt 6 Multimedia module

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, delta...@debian.org, 
debian-qt-...@lists.debian.org

* Package name: qt6-multimedia
  Version : 6.2.1
  Upstream Author : The Qt Company Ltd.
* URL : https://www.qt.io/developers/
* License : LGPL-3 or GPL-2
  Programming Lang: C++
  Description : Qt 6 Multimedia module

Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.

The module provides QML types and C++ classes for handling multimedia
content.

Bug#999688: RM: flup -- ROM; no Python3 support; dead upstream

[tony mancill]

Package: ftp.debian.org
Severity: normal

Dear FTP Maintainers,

Please remove flup from unstable.  It is Python2-only, has no reverse
dependencies, and not part of bullseye.  I am requesting this on behalf
of John Hedges, as I have sponsored uploads since 2012, including the
most recent upload in 2015.

Related reports:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936535
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873492

> ssh mirror.ftp-master.debian.org "dak rm -Rn flup"
> Will remove the following packages from unstable:
> 
>   flup |1.0.2-5 | source
> python-flup |1.0.2-5 | all
> 
> Maintainer: John Hedges 
> 
> --- Reason ---
> 
> --
> 
> Checking reverse dependencies...
> No dependency problem found.

Thank you,
tony


signature.asc
Description: PGP signature

Bug#999689: reprotest: autopkgtest missing dependency on diffoscope

[Stefano Rivera]

Source: reprotest
Version: 0.7.17
Severity: normal
Tags: patch

Fixing #988964 broke the "not need_builddeps" autopkgtest:
https://ci.debian.net/packages/r/reprotest/unstable/amd64/

It has failed since 0.7.16.

The easy fix is:
diff --git a/debian/tests/control b/debian/tests/control
index 8132bdc..e5a47b8 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,5 +1,5 @@
 Test-Command: debian/rules autopkgtest-pytest PYTEST_MARKEXPR="not 
need_builddeps"
-Depends: @, python3-pytest, faketime, locales-all, fakeroot
+Depends: @, diffoscope, python3-pytest, faketime, locales-all, fakeroot
 
 Test-Command: debian/rules autopkgtest-pytest PYTEST_MARKEXPR="need_builddeps"
 Depends: @, @builddeps@, fakeroot

SR

Bug#999687: ITP: qt6-lottie -- Qt 6 QML API for rendering graphics and animation

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, delta...@debian.org, 
debian-qt-...@lists.debian.org

* Package name: qt6-lottie
  Version : 6.2.1
  Upstream Author : The Qt Company Ltd.
* URL : https://www.qt.io/developers/
* License : GPL-3
  Programming Lang: C++
  Description : Qt 6 QML API for rendering graphics and animation

Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.

Lottie is a family of player software for a certain json-based file
format for describing 2d vector graphics animations. 

Bug#999637: systemd: systemctl help foo.service doesn't work with file:/path/to/README.md

[Michael Biebl]

On 14.11.21 04:59, Nicholas D Steeves wrote:

Package: systemd
Version: 249.6-1
Severity: normal

Hi,

Apologies for not reporting from a sid system.  It affects systemd in
buster and bullseye as well, but I'm not sure if the version of
systemd in those version is new enough to support this type of
documentation.  Steps to reproduce:

1. Install a testing system, including the standard system tools task
2. Upgrade to sid
3. Run "systemctl help foo" for a service file that uses the following
under the [Unit] section:

   Documentation="file:/usr/share/doc/foo/README.md"


Hmm, systemctl help says
"
   help PATTERN...|PID...
   Show manual pages for one or more units, if available.
"

You are not pointing Documentation= at a man page though but an 
arbitrary file. Try e.g. "systemctl help rsyslog"


OpenPGP_signature
Description: OpenPGP digital signature

Bug#999686: pipewire-pulse: Pipewire-pulse disabling auto-mute mode

[Gert van de Kraats]

Package: pipewire-pulse
Version: 0.3.40-1
Severity: normal
Tags: upstream

Recently I installed new updates, which also installed new packages 
pipewire-

pulse and wireplumber.


2021-11-07 22:29:42 remove pipewire-media-session:i386 0.3.38-2 
2021-11-07 22:29:43 upgrade libpipewire-0.3-dev:i386 0.3.38-2 0.3.39-3
2021-11-07 22:29:45 upgrade gstreamer1.0-pipewire:i386 0.3.38-2 0.3.39-3
2021-11-07 22:29:46 upgrade libpipewire-0.3-modules:i386 0.3.38-2 0.3.39-3
2021-11-07 22:29:48 upgrade pipewire:i386 0.3.38-2 0.3.39-3
2021-11-07 22:29:49 upgrade pipewire-bin:i386 0.3.38-2 0.3.39-3
2021-11-07 22:29:51 upgrade libpipewire-0.3-0:i386 0.3.38-2 0.3.39-3
2021-11-07 22:29:53 install libwireplumber-0.4-0:i386  0.4.4-1
2021-11-07 22:29:53 install pipewire-pulse:i386  0.3.39-3
2021-11-07 22:29:54 install wireplumber:i386  0.4.4-1
2021-11-13 20:56:42 upgrade gstreamer1.0-pipewire:i386 0.3.39-3 0.3.39-4
2021-11-13 20:56:43 upgrade pipewire-pulse:i386 0.3.39-3 0.3.39-4
2021-11-13 20:56:44 upgrade pipewire-bin:i386 0.3.39-3 0.3.39-4
2021-11-13 20:56:46 upgrade libpipewire-0.3-dev:i386 0.3.39-3 0.3.39-4
2021-11-13 20:56:47 upgrade libpipewire-0.3-0:i386 0.3.39-3 0.3.39-4
2021-11-13 20:56:49 upgrade pipewire:i386 0.3.39-3 0.3.39-4
2021-11-13 20:56:50 upgrade libpipewire-0.3-modules:i386 0.3.39-3 0.3.39-4
2021-11-13 20:57:35 upgrade libpipewire-0.3-common:all 0.3.39-3 0.3.39-4
2021-11-14 14:18:59 upgrade pipewire-pulse:i386 0.3.39-4 0.3.40-1
2021-11-14 14:19:00 upgrade libpipewire-0.3-dev:i386 0.3.39-4 0.3.40-1
2021-11-14 14:19:02 upgrade gstreamer1.0-pipewire:i386 0.3.39-4 0.3.40-1
2021-11-14 14:19:02 upgrade libpipewire-0.3-modules:i386 0.3.39-4 0.3.40-1
2021-11-14 14:19:04 upgrade pipewire:i386 0.3.39-4 0.3.40-1
2021-11-14 14:19:05 upgrade pipewire-bin:i386 0.3.39-4 0.3.40-1
2021-11-14 14:19:07 upgrade libpipewire-0.3-0:i386 0.3.39-4 0.3.40-1



This caused pipewire-pulse to be used for Sound in stead of pulseaudio.

After these update(s) the internal speaker of the laptop is not going
automatically to mute, if the headphone is plugged in.

If I enable auto-mute, the internal speaker is going to mute, as wished.

As soon as I remove the headphone-plug,
auto-mute is immediately disabled at alsamixer.

If I plug-in the headphone again, the internal speaker is not going to 
mute, as

wished.

In fact this is the same bug as I reported some weeks ago at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998368 
 concerning 
pulseaudio.
The solution suggested there for pulseaudio, does not work for 
pipewire-pulse.


AutoMute does not auto mute anymore, as it did at previous versions of
pulseaudio. You now always have to manually activate AutoMute again, before
plugging in the headphone which is not very "auto".


-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 5.14.0-2-686-pae (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pipewire-pulse depends on:
ii init-system-helpers 1.60
ii pipewire 0.3.40-1

pipewire-pulse recommends no packages.

pipewire-pulse suggests no packages.

-- no debconf information

Bug#999685: ITP: pynput -- control and monitor input devices

[Benjamin Drung]

Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: pynput
  Version : 1.7.3
  Upstream Author : Moses Palmér
* URL : https://github.com/moses-palmer/pynput
* License : LGPL-3+
  Programming Lang: Python
  Description : control and monitor input devices

This library allows you to control and monitor input devices. Currently,
mouse and keyboard input and monitoring are supported.

This library is one dependency of streamdeck-ui that I want to package
and maintain as part of the Python team.

--
Benjamin Drung
Debian & Ubuntu Developer

Bug#999684: ITP: qt6-5compat -- Qt 6 Compatibility module

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, delta...@debian.org, 
debian-qt-...@lists.debian.org

* Package name: qt6-5compat
  Version : 6.2.1
  Upstream Author : The Qt Company Ltd.
* URL : https://www.qt.io/developers/
* License : LGPL-3 or GPL-2
  Programming Lang: C++
  Description : Qt 6 Compatibility module

Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.

The module contains unsupported Qt 5 APIs.

Bug#999683: ITP: qt6-3d -- Qt 6 3D library

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, delta...@debian.org, 
debian-qt-...@lists.debian.org

* Package name: qt6-3d
  Version : 6.2.1
  Upstream Author : The Qt Company Ltd.
* URL : https://www.qt.io/developers/
* License : LGPL-3 or GPL-2
  Programming Lang: C++
  Description : Qt 6 3D library

Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.

Qt 3D is a 3D framework that enables the drawing of 3D shapes and
moving them around.

Bug#999682: erlang-mode: Broken symlinks in man/man3

[Sebastian Olsson]

Package: erlang-mode
Version: 1:23.2.6+dfsg-1
Severity: normal
X-Debbugs-Cc: vis...@gmail.com

Dear Maintainer,

I installed the erlang package on an Debian bullseye docker container to 
perform the following escript:

```
#!/usr/bin/env escript
%% -*- erlang -*-
%%! -sname edts-helper

main(["release", ReleaseConfig]) ->
{ok, Conf} = file:consult(ReleaseConfig),
{ok, Spec} = reltool:get_target_spec(Conf),
reltool:eval_target_spec(Spec, code:root_dir(), "rel");
```

This failed with `"read file info /usr/lib/erlang/man/man3/LIST_EMPTY.3 
failed"}`

Investigating I realized it was because there was broken symlinks that 
`erlang-mode` installed.

```
root@10759c6aee0e:/usr/lib/erlang/man# find . -xtype l
./man3/LIST_EMPTY.3
./man3/LIST_ENTRY.3
./man3/LIST_FIRST.3
./man3/LIST_FOREACH.3
./man3/LIST_HEAD.3
./man3/LIST_HEAD_INITIALIZER.3
./man3/LIST_INIT.3
./man3/LIST_INSERT_AFTER.3
./man3/LIST_INSERT_BEFORE.3
./man3/LIST_INSERT_HEAD.3
./man3/LIST_NEXT.3
./man3/LIST_REMOVE.3
```

They all point to non-existing `man3/list.3`

After installing `erlang-manpages` I got a file called `lists.3erl.gz` but the 
links are sadly still broken.

If I remove the package `erlang-mode` the escript works.

Best regards

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.15-arch1-1 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages erlang-mode depends on:
ii  emacsen-common  3.0.4

erlang-mode recommends no packages.

Versions of packages erlang-mode suggests:
ii  erlang   1:23.2.6+dfsg-1
ii  erlang-doc   1:23.2.6+dfsg-1
ii  erlang-manpages  1:23.2.6+dfsg-1

-- no debconf information

Bug#999681: RFS: ii/1.8-3+ds -- minimalist FIFO and filesystem-based IRC client

[itd]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "ii":

 * Package name: ii
   Version : 1.8-3+ds
   Upstream Author : https://suckless.org/community/
 * URL : https://tools.suckless.org/ii/
 * License : MIT/X-Consortium-License
 * Vcs : https://salsa.debian.org/debian/ii
   Section : net

It builds those binary packages:

  ii - minimalist FIFO and filesystem-based IRC client

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/ii/

Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/i/ii/ii_1.8-3+ds.dsc

Changes since the last upload:

 ii (1.8-3+ds) unstable; urgency=medium
 .
   * Fix lintian: package-uses-old-debhelper-compat-version
   * autopkgtest smoke-test is superficial
   * Update Vcs-Git/Browser URL
   * Bump standards version to 4.6.0 (no changes required)
   * Update e-mail address
   * Bump debian/watch version to 4
   * Add Bug-Submit metadata
   * Add Upstream-Contact to d/copyright

Regards,
-- 
  itd

Bug#999676: libesmtp-dev: package is not multi-arch. I cannot install more than one arch at a time docker image, see hub.docker.com image: softplc/toolkit

[Jeremy T. Bouse]

Might I first suggest that you upgrade as 1.0.6 is in the stable branch and
no new version upgrades will go into place while 1.1.0 is available now and
packaged in both Debian and Ubuntu (which you appear to be actually running)

On Sun, Nov 14, 2021 at 3:00 PM Dick Hollenbeck  wrote:

> Package: libesmtp-dev
> Version: 1.0.6-4.3build1
> Severity: wishlist
> Tags: upstream
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers focal-updates
>   APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500,
> 'focal'), (100, 'focal-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.4.0-89-generic (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
> LANGUAGE=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages libesmtp-dev depends on:
> ii  libc6-dev  2.31-0ubuntu9.2
> ii  libesmtp6  1.0.6-4.3build1
>
> libesmtp-dev recommends no packages.
>
> libesmtp-dev suggests no packages.
>
> -- no debconf information
>

Bug#999680: criu: FTBFS on armhf: cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU

[Salvatore Bonaccorso]

Source: criu
Version: 3.16.1-1
Severity: serious
Tags: ftbfs
Justification: FTBFS
X-Debbugs-Cc: car...@debian.org

This is different from #918229, so filling a separate issue. criu on
armhf FTBFS with gcc-11:

dh clean --with python3
   dh_auto_clean
make -j4 clean
make[1]: Entering directory '/<>'
make[1]: git: No such file or directory
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.
  CLEANDocumentation
  CLEANtest/compel
  CLEANimages
  CLEANcriu/arch/arm
  CLEANcriu/pie
  CLEANcriu
  CLEANcriu/unittest
  CLEANcriu/pie
  CLEANcriu
  CLEANsoccr
  CLEANlib/c
  CLEANlib/py/images
  CLEANlib/py
  CLEANlib
  CLEANcompel
  CLEANcompel/plugins
  CLEANlib/c
  CLEANlib/py/images
  CLEANlib/py
  CLEANlib
  CLEANcrit
make[1]: Leaving directory '/<>'
   dh_clean
 debian/rules binary-arch
dh binary-arch --with python3
   dh_update_autotools_config -a
   dh_autoreconf -a
   dh_auto_configure -a
   dh_auto_build -a
make -j4 "INSTALL=install --strip-program=true"
make[1]: Entering directory '/<>'
Note: Building without setproctitle() and strlcpy() support.
  To enable these features, please install libbsd-devel (RPM) / libbsd-dev 
(DEB).
Makefile.config:41: Warn: you have libnftables installed but it has 
incompatible API
Makefile.config:42: Warn: Building without nftables support
make[1]: git: No such file or directory
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.
  GEN  .gitid
  GEN  include/common/asm
  GEN  compel/include/asm
touch .config
  GEN  compel/include/version.h
  GEN  criu/include/version.h
  GEN  include/common/config.h
  GEN  compel/plugins/include/uapi/std/asm/syscall-types.h
  DEP  compel/arch/arm/plugins/std/parasite-head.d
  GEN  compel/arch/arm/plugins/std/syscalls/syscalls.S
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
  GEN  compel/plugins/include/uapi/std/syscall-codes.h
  DEP  soccr/soccr.d
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
  GEN  compel/plugins/include/uapi/std/syscall.h
  CC   soccr/soccr.o
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
make[2]: *** [/<>/scripts/nmk/scripts/build.mk:119: soccr/soccr.o] 
Error 1
make[1]: *** [Makefile:232: soccr/built-in.o] Error 2
make[1]: *** Waiting for unfinished jobs
  DEP  compel/arch/arm/plugins/std/syscalls/syscalls.d
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
  DEP  compel/plugins/std/infect.d
  DEP  compel/plugins/std/string.d
  DEP  compel/plugins/std/log.d
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
  DEP  compel/plugins/std/fds.d
  DEP  compel/plugins/std/std.d
  DEP  compel/plugins/shmem/shmem.d
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
  DEP  compel/plugins/fds/fds.d
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
  CC   compel/plugins/std/fds.o
  CC   compel/plugins/std/std.o
  CC   compel/plugins/std/log.o
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
make[2]: *** [/<>/scripts/nmk/scripts/build.mk:214: 
compel/plugins/std/std.o] Error 1
make[2]: *** Waiting for unfinished jobs
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
make[2]: *** [/<>/scripts/nmk/scripts/build.mk:214: 
compel/plugins/std/fds.o] Error 1
make[2]: *** [/<>/scripts/nmk/scripts/build.mk:214: 
compel/plugins/std/log.o] Error 1
make[1]: *** [Makefile.compel:56: compel/plugins/std.lib.a] Error 2
  PBCC images/apparmor.pb-c.c
  PBCC images/bpfmap-data.pb-c.c
  PBCC images/fown.pb-c.c
  PBCC images/google/protobuf/descriptor.pb-c.c
  PBCC images/img-streamer.pb-c.c
  PBCC images/timens.pb-c.c
  PBCC images/macvlan.pb-c.c
  PBCC images/autofs.pb-c.c
  PBCC images/sysctl.pb-c.c
  PBCC images/time.pb-c.c
  PBCC images/binfmt-misc.pb-c.c
  PBCC images/seccomp.pb-c.c
  PBCC images/pidns.pb-c.c
  PBCC images/userns.pb-c.c
  PBCC images/cgroup.pb-c.c
  PBCC images/ext-file.pb-c.c
  PBCC images/rpc.pb-c.c
  PBCC images/siginfo.pb-c.c
  PBCC images/rlimit.pb-c.c
  PBCC images/file-lock.pb-c.c
  PBCC images/creds.pb-c.c
  PBCC images/utsns.pb-c.c
  PBCC images/ipc-desc.pb-c.c
  PBCC images/ipc-var.pb-c.c
  PBCC images/sk-opts.pb-c.c
  PBCC images/timer.pb-c.c
  PBCC images/pipe-data.pb-c.c
  PBCC images/sk-packet.pb-c.c
  PBCC images/pstree.pb-c.c
  

Bug#999679: caja: Caja inserts hyphens into filenames

[Qaz]

Package: caja
Version: 1.24.0-1
Severity: normal
X-Debbugs-Cc: qazwsx...@gmx.net

Dear Maintainer,

Caja inserts spurious hyphens into filenames in icon view whenever such
filenames are too long to fit on one line.

This bug severely affects usability because it causes unique filenames 
to be shown as not unique as explained below.

   * What led up to the situation?
Displaying a file name like "thisisaverylongfilename.txt" in Caja's icon view.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Displaying a file name like "thisisaverylongfilename.txt" in Caja's icon view.

   * What was the outcome of this action?
Caja displays the filename across two lines below the icon, like so:
   thisisaverylongfi-
  lename.txt
Note the hyphen inserted at the end of the first line which is NOT part of
the filename.

   * What outcome did you expect instead?
That Caja displays the filename without inserting any hyphen or any other
character. With the hyphen inserted it becomes impossible to distinguish
between "thisisaverylongfilename.txt" and "thisisaverylongfi-lename.txt" 
because both will be displayed with a hyphen between 'fi' and 'le'.

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages caja depends on:
ii  caja-common   1.24.0-1
ii  desktop-file-utils0.26-1
ii  gvfs  1.46.2-1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.31-9
ii  libcairo-gobject2 1.16.0-5
ii  libcairo2 1.16.0-5
ii  libcaja-extension11.24.0-1
ii  libexempi82.5.2-1
ii  libexif12 0.6.22-3
ii  libgail-3-0   3.24.24-1
ii  libgdk-pixbuf2.0-02.40.2-2
ii  libglib2.0-0  2.66.7-1
ii  libglib2.0-bin2.66.7-1
ii  libglib2.0-data   2.66.7-1
ii  libgtk-3-03.24.24-1
ii  libice6   2:1.0.10-1
ii  libmate-desktop-2-17  1.24.1-2
ii  libnotify40.7.9-3
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libselinux1   3.1-3
ii  libsm62:1.2.3-1
ii  libx11-6  2:1.7.0-2
ii  libxml2   2.9.10+dfsg-6.3+b1
ii  mate-desktop  1.24.1-2
ii  shared-mime-info  2.0-1

Versions of packages caja recommends:
ii  gvfs-backends  1.46.2-1

Versions of packages caja suggests:
ii  engrampa1.24.1-1
pn  gstreamer1.0-tools  
pn  meld

-- no debconf information

Bug#999678: apt: Please list "apt search" results in decreasing order of binary package popularity

[Bálint Réczey]

Package: apt
Version: 2.3.11
Severity: wishlist
Control: block -1 by 999677

Dear Maintainers,

I believe when looking for a package to install the more popular ones
have higher probability to be the right fit. Currently 'apt search'
results are sorted in alphabetical order, but a decreasing popularity
order would be more helpful, maybe even showing the percentage of
systems each binary package is installed on.

At the moment the popularity data is not available, but I've filed
#999677 to solve that. If you agree with the proposal please share
your thoughts on the preferred database format in the RFP bug.

Thanks,
Balint

Bug#999677: RFP: popcon-stats-data -- Debian's Popularity Contest statistics

[Bálint Réczey]

Package: wnpp
Severity: wishlist

* Package name: popcon-stats-data
  Version : 0.2024
* URL or Web page : https://popcon.debian.org/
* License : Public Domain (data)
  Description : Debian's Popularity Contest statistics

---

The shipped data would let package managers show the popularity of
packages which could let users make more informed decisions when
choosing between packages to install.

I don't believe this will change the Vim vs. Emacs battle, but when I
looked for a DICOM viewer I found a crazy amount of programs of
various quality and knowing which ones were the most widely used would
have sped up picking a good one.

Ideally the stats would be shipped in a format from which APT and
other package managers could efficiently look up the percentage of
Debian systems a particular binary package was used.

Cheers,
Balint

Bug#839940: RFS: ponymix/5-1 [ITP] -- CLI volume control for PulseAudio

[Victor]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ponymix":

 * Package name: ponymix
   Version : 5-1
   Upstream Author : Dave Reisner 
 * URL : https://github.com/falconindy/ponymix
 * License : MIT
 * Vcs : [fill in URL of packaging vcs]
   Section : utils

It builds those binary packages:

  ponymix - CLI volume control for PulseAudio

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/ponymix/

Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/p/ponymix/ponymix_5-1.dsc

Changes for the initial release:

 ponymix (5-1) experimental; urgency=low
 .
   * Initial release (Closes: #839940)

Regards,
-- 
  Victor Raphael Santos Souza

Bug#999676: libesmtp-dev: package is not multi-arch. I cannot install more than one arch at a time docker image, see hub.docker.com image: softplc/toolkit

[Dick Hollenbeck]

Package: libesmtp-dev
Version: 1.0.6-4.3build1
Severity: wishlist
Tags: upstream

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***



-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-89-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libesmtp-dev depends on:
ii  libc6-dev  2.31-0ubuntu9.2
ii  libesmtp6  1.0.6-4.3build1

libesmtp-dev recommends no packages.

libesmtp-dev suggests no packages.

-- no debconf information

Bug#992676: scipy breaks python-skbio autopkgtest: Unsupported dtype object

[Nilesh Patra]

control: fixed -1 upstream

On Thu, 7 Oct 2021 00:26:54 +0530 Nilesh Patra  wrote:
> Reported and pinged upstream here, pinging on the bug to delay
> testing removal for a bit
> 
> https://github.com/biocore/scikit-bio/issues/1757

Looks like upstream has fixed this in[1.2]

@Andreas, would you consider to cherry pick and try?

[1]: https://github.com/biocore/scikit-bio/pull/1786
[2]: https://github.com/biocore/scikit-bio/pull/1787

Nilesh


signature.asc
Description: PGP signature

Bug#992676: scipy breaks python-skbio autopkgtest: Unsupported dtype object

[Nilesh Patra]

On Thu, 7 Oct 2021 00:26:54 +0530 Nilesh Patra  wrote:
> Reported and pinged upstream here, pinging on the bug to delay
> testing removal for a bit
> 
> https://github.com/biocore/scikit-bio/issues/1757

Looks like it is fixed in upstream commits[1.2]

@Andreas would you consider cherry-picking them and try?

[1]: https://github.com/biocore/scikit-bio/pull/1786
[2]: https://github.com/biocore/scikit-bio/pull/1787

Nilesh


signature.asc
Description: PGP signature

Bug#999675: ITP: nv-codec-headers -- FFmpeg headers for interfacing with NVIDIA's codec APIs

[Sebastian Ramacher]

On 2021-11-14 19:35:23 +0100, Andrea Pappacoda wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Andrea Pappacoda 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: nv-codec-headers
>   Version : 11.1.5.0
>   Upstream Author : NVIDIA Corporation 
> * URL : https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git
> * License : Expat
>   Programming Lang: C
>   Description : FFmpeg headers for interfacing with NVIDIA's codec APIs
> 
> These headers are required to interface with NVENC from FFmpeg, and are
> required by different packages: gnome-remote-desktop uses them to improve
> Nvidia support (https://salsa.debian.org/gnome-team/gnome-remote-
> desktop/-/commit/c9d74a4e1e1ff5363679d95320ae11e12d18fd67,
> https://bugs.launchpad.net/ubuntu/+source/nv-codec-headers/+bug/1945241),
> ffmpeg would use them to enable NVENC (https://bugs.debian.org/cgi-
> bin/bugreport.cgi?bug=925941), and the yuzu emulator, a software that I'm
> trying to package, seems to require them as well (https://github.com/yuzu-
> emu/yuzu/blob/30442d8a89fd42d9b7efea86e1b2461f09219936/CMakeLists.txt#L582).
> 
> The headers are MIT (Expat) licensed, so licensing of the package itself
> shouldn't be an issue (as opposed to the non-freeness of NVENC).
> 
> Also, Ubuntu already packaged these headers
> (https://launchpad.net/ubuntu/+source/nv-codec-headers), and it seems that 
> they
> are (or used to) making use of them in ffmpeg.
> 
> The headers would be contained in a package named libffmpeg-nvenc-dev.

https://ftp-master.debian.org/new/nv-codec-headers_11.1.5.0-1.html

Cheers

> 
> 
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#999670: nvidia module parameters NVreg_RegistryDwords is not applied which breaks DDC/CI

[Andreas Beckmann]

On 14/11/2021 17.30, themightydeity wrote:

Package: nvidia-driver
Version: 470.82.00-1
Severity: normal
Tags: newcomer
X-Debbugs-Cc: themightyde...@gmail.com

As mentioned here: https://www.ddcutil.com/nvidia/ for ddcutil (DDC/CI) (i2c
communication) to work properly in nvidia's proprietary driver. This conf is
needed in modprobe:

options nvidia NVreg_RegistryDwords=RMUseSwI2c=0x01;RMI2cSpeed=100


You have these settings in /etc/modprobe.d/nvidia-extra.conf

Please try
  options nvidia-current key=value...
Perhaps the options don't get activated because of the module renaming ...

I noticed you have a /etc/modules-load.d/nouveau.conf ... does it 
somehow interfere?



Andreas

Bug#620772: bzip2 bug

[Ed Himwich]

This is still an issue in Debian Stretch with bzip2, Version 1.0.6,
6-Sept-2010.

bzip2 doesn't seem to pass the first 5000 bytes of uncompressed data from
stdin:

$ echo string | egrep string
string
$ echo string | zegrep string
string
$ echo string | bzegrep string
$

looking at the low-level programs:

$ echo string | gzip -cdfq
string
$ echo string | bzip2 -cdfq
$

Tests with cat-ing files instead of echo-ing show similar results, with
bytes after the 5000th being passed. All bytes are passed if the file is a
command line argument for bzegrep/bzip2.

Bug#996290: Fix tested successfully, correct for bullseye?

[Simon Iremonger (debian)]

I can conform that applying

https://github.com/irssi/irssi/commit/db2fed

to the irssi_1.2.3-1 debian source, builds and works on
debian bullseye i386 and amd64.

I have found no regressions, use 'saved' TLS+SASL network configs
*and* ad-hoc TLS network configs, both of which now work fine
in face of disconnects, as opposed to only the former.

I am of the view this is worthy of a routine update to the irssi
package as SSL in IRC is increasingly used/encouraged/needed for
certain auth types, and manually /connect 'ing  is not at all
a rare configuration, as well as the point that this is a relatively
simple fix to a relatively annoying and confusing problem!

This ad-hoc TLS config has been fine in previous debian releases,
just not now, all of a sudden, bullseye regression essentially!.

This could go into bullseye-updates for next point release, in my
view.

I'd like to hear from maintainer, and happy to post package files
if useful for others to view/help test.

--Simon

Bug#999674: ftp.debian.org: obsolete content in 'Debian NEW and BYHAND Packages'?

[Patrice Duroux]

Package: ftp.debian.org
Severity: normal

Hi,

Not knowing about the maintenance process of this page,
I have post the debian-user mailing-list[1] about the following fact:

> I am curious about the reason to see cockpit listed here:
> https://ftp-master.debian.org/new.html
> whereas cockpit currently is 257 in Sid:
> https://tracker.debian.org/pkg/cockpit

The nice reply[2] reminds me about the virtual package.
So here it is.

I am not sure if this has been already reported.

Cheers,
Patrice

[1] https://lists.debian.org/debian-user/2021/11/msg00374.html
[2] https://lists.debian.org/debian-user/2021/11/msg00376.html

Bug#999673: bullseye-pu: package lldpd/1.0.11-1

[Vincent Bernat]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

[ Reason ]

- - Low-severity security issue when receiving SONMP packets.
  CVE-2021-43612

- - Annoying bug where LLDP packets are encapsulated in VLAN 0 when some
  configuration directives are used. Many implementations reject such
  a packet (regression introduced in 1.0.6)

[ Impact ]

- - Someone could crash lldpd from another neighbor if the user enables
  SONMP (quite unlikely).

- - People cannot use some configuration directives.

[ Tests ]

- - Both codes are covered by tests in upstream. The SONMP tests are run
  during build as well. The VLAN 0 test is not run during build.

[ Risks ]

- - For SONMP, low risk as it is seldomly used and correctly formed
  packets are part of the tests run during build.

- - For VLAN 0, the change is trivial, tested upstream and reported OK by two 
users.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]

- - SONMP: there was a confusion about the size of a packet. The same
  variable was used for the payload size and for checking the size
  with Ethernet headers.

- - VLAN 0: when changing some settings, a struct containing the changed
  settings is transmitted. -1 was used to say "no change" but it was
  interpreted as a change.

[ Other info ]

- - Security team is OK to fix the security issue in a point release.

- - I don't think this is worth fixing the SONMP issue in Buster, but I
  can do that too. The VLAN issue is not present.


-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmGRU44SHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5++gP/jK+rA7DgjxgweFrlUezPB39QSg6wcmu
9YrUO8wyjSzZ0A51Gfh/afyJAKRKehy3tD/nWvrQumn5ZkYXMhVbock5zJbgnTmo
1ndd2CtIOlpdSceqmnxX83Qt5qj7yHLWCzyAYg+ujgO1Su/IrE6GwwWr3+OBJQdN
lwLrbDzIe+Xv+4sYLLhWjO1ApVHpJmLJYYywBWug6YkTa9hx1wixPGm76G1Z4tvc
312L+9uwJqdp85Nb8w29VgBx8nDOWZS54FaimnggmGk895beQdI4wUCGfrJ/Tqkt
K4emDeOUv5pUudDYNU98a0byf7Ahif+QVZLS0w9p32uHd7qtr1ZwkmhcO2I0W0jA
EWIC7PW3qyQqa8SrD068Sx9jEhCt69uJaQyDUV38DbCmNFjip4oK607XeLuh/WwC
R6TI3iMro3T03QSzyYyFvWLJpL0n/xHtoMb0UXWY+KE38uOQQ1Fdv3JkvxxI6q6Z
8FhpTYr1ONE9uj577aMj3bX9BkxdVKKjy48bLEkHhTd1KS/FOLpWMmnlRVNBAr8t
KDn09xcsxU+anIGunFwrATqH8sBFOqO0gvr+ylgyswQiW3L8WWM2uyG1+UoO/AeW
lwMHk+6WUuejhB/7PzA0Wcv5zfgkwahZRf2zN6ohON6IaVR6Pbn0+lSYU5rlramB
dsd1jEbkXZ36
=W7Cl
-END PGP SIGNATURE-
>From d70b8be04c6d8638e6f2cd612a07e73992fa0798 Mon Sep 17 00:00:00 2001
From: Vincent Bernat 
Date: Sun, 14 Nov 2021 15:42:12 +0100
Subject: [PATCH] Tentative security update for Bullseye

---
 debian/changelog  |  8 ++
 ...et-VLAN-tag-if-client-did-not-set-it.patch | 27 ++
 ...-overflow-when-reading-SONMP-packets.patch | 93 +++
 debian/patches/series |  2 +
 4 files changed, 130 insertions(+)
 create mode 100644 
debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
 create mode 100644 
debian/patches/0001-sonmp-fix-heap-overflow-when-reading-SONMP-packets.patch

diff --git a/debian/changelog b/debian/changelog
index bb87d8129f9e..68ae7b91d22d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+lldpd (1.0.12-1+deb11u1) bullseye; urgency=high
+
+  * d/patches: sonmp: fix heap overflow when reading SONMP packets.
+CVE-2021-43612
+  * d/patches: client: do not set VLAN tag if client did not set it
+
+ -- Vincent Bernat   Sun, 14 Nov 2021 15:41:59 +0100
+
 lldpd (1.0.12-1) unstable; urgency=medium
 
   * New upstream release.
diff --git 
a/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch 
b/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
new file mode 100644
index ..1f65986ae27e
--- /dev/null
+++ 
b/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
@@ -0,0 +1,27 @@
+From 261afbe371ab316a4bf710338f6d9183a01e083f Mon Sep 17 00:00:00 2001
+From: Vincent Bernat 
+Date: Wed, 29 Sep 2021 12:02:15 +0200
+Subject: [PATCH] client: do not set VLAN tag if client did not set it
+
+This fixes a bug where frames could be tagged with VLAN 0 after client
+configuration.
+---
+ src/daemon/client.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/daemon/client.c b/src/daemon/client.c
+index b4a08aae80a8..0d0f3ea37a19 100644
+--- a/src/daemon/client.c
 b/src/daemon/client.c
+@@ -390,7 +390,7 @@ _client_handle_set_port(struct lldpd *cfg,
+   port->p_disable_rx = port->p_disable_tx = 1;
+   break;
+   }
+-  if (set->vlan_tx_enabled >= -1) {
++  if (set->vlan_tx_enabled > -1) {
+   port->p_vlan_tx_enabled = set->vlan_tx_enabled;
+   port->p_vlan_tx_tag = 

Bug#804925: Ability to set user password to a hash

[Pascal Volk]

On 13/11/2015 00.34, martin f krafft wrote:
> Package: vmm
> Version: 0.6.2-1
> Severity: wishlist
> 
> [...]
> It'd be nice if I could invoke userpassword --hash or
> userpasswordhash or userhash and pass it the hash directly for
> unmodified storage in the database.
> [...]

Hi Martin,

this was implemented in

and is part of the current vmm-0.7.0 release.


Regards,
Pascal
-- 
Ubuntu is an ancient African word meaning “I can’t install Debian.”
 -- unknown


OpenPGP_signature
Description: OpenPGP digital signature

Bug#999672: mutt: license conflict with libsasl2

[Bastian Germann]

Package: mutt
Version: 2.0.5-4.1
Severity: important

Hi,

mutt depends on libsasl2-2, which is licensed under CMU's BSD-4-clause license and covered by the RSA-MD and OpenSSL 
licenses. All of them have an advertisement clause in place, which is known to be incompatible with GPL.

There are several possible solutions to this problem:

1) Build without SASL support.

2) Support my request at #996892.

3) Ask upstream to add a license exception for libsasl2-2, similar to the one that was required by Debian for OpenSSL 
for a long time.


Thanks for your consideration,
Bastian

Bug#999671: build-essential: I installed (and also did apt install --reinstall ) build-essential. However there is a problem that cc1,.. can not be found

[Loreno Heer]

Package: build-essential
Version: 12.9
Severity: important
X-Debbugs-Cc: loreno.h...@bluewin.ch




-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages build-essential depends on:
ii  dpkg-dev  1.20.9
ii  g++   4:11.2.0-2
ii  gcc   4:11.2.0-2
ii  libc6-dev [libc-dev]  2.32-4
ii  make  4.3-4.1

build-essential recommends no packages.

build-essential suggests no packages.

-- no debconf information



It is not possible to compile anything because cc1 is not found. reinstalling 
build essential or gcc or gcc-11 does not solve this.

Bug#994405: libgmp10:i386: buffer overflow due to integer overflow in mpz/inp_raw.c on 32-bit machines

[Anton Gladky]

Thanks, Vincent,

now I am able to reproduce the issue!

I will request CVE.

Regards

Anton

Am So., 14. Nov. 2021 um 15:44 Uhr schrieb Vincent Lefevre :
>
> On 2021-11-14 14:15:25 +0100, Anton Gladky wrote:
> > well, I was thinking that upstream should request a CVE. Neverheless
> > I could not reproduce the issue with the modern GCC-versions.
> > Even on 32bit-systems.
>
> I can still reproduce the segmentation fault under Debian/unstable.
> Simplified testcase:
>
> #include 
> #include 
>
> int main (void)
> {
>   mpz_t s;
>   mpz_init (s);
>   mpz_inp_raw (s, stdin);
>   return 0;
> }
>
> Compile with gcc -m32 and execute:
>
>   printf 12345 | ./testcase
>
> Note that even if you don't get a segmentation fault, there may be
> other erratic behaviors, such as silent memory corruption (which may
> be even worse).
>
> --
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>

Bug#999631: "works for me" - Problem obviously solved

[Wolfgang Rosner]

My box is running now for a whole night without problems, 
including multiple hours of active working with libreoffice writer.

Obviously this solution works:


create folder and file /etc/X11/xorg.conf.d/20-nouveau.conf
and put in:

Section "Device"
Identifier "NvidiaCard"
Driver "nouveau"
BusID "PCI:01:00:0" # PCI bus address of the Nvidia GPU here
EndSection


I'd recommend debian install / upgrade procedure to care for a similiar
solution, maybe adopted to the proper debianic way.

Bug#999669: heimdal: drop patch 0016 that adds base64 back

[Braiam Peguero]

Source: heimdal
Version: 7.7.0+dfsg-2
Severity: important
Tags: newcomer

Dear Maintainer,

Commit 6ef46655 added the patch "Add back in base64_encode and base64_decode",
that patch can be dropped since upstream bumped SONAME [1].

I'm unsure if a revert or a patch removing it is appropiated.



*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-proposed-updates-debug'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'testing'), (50, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-trunk-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW

[Thomas Schmitt]

Hi,

i made the experiments which i mentioned in the previous mail:

- The Pioneer drive does not go mad from READ CD for LBA -1 or from
  READ CD MSF for sector 00:01:74.

- The ASUS drive does not go mad from READ CD MSF for sector 00:01:74.

- The TSSTcorp drive tolerates READ CD MSF for sector 00:01:74 without
  a message in dmesg about USB reset. (It did that reset with READ CD for
  LBA -1 but showed no lasting problem.)

None of the drives reports success with the READ CD MSF command. So with
this command the Brasero function brasero_medium_track_written_SAO()
would return TRUE, which is wrong with the given CD.

The desire to read the Lead-in sector before the start of the payload
data simply seems not fulfillable here for the first track of a CD.

Brasero will have to abandon this idea or come up with a better read
command - which i currently fail to imagine.

-
The SCSI specs say that LBA -1 is bad:

While exploring how to encode the READ CD MFS command for 00:01:74, i found
this statement in the MMC-5 specs:
  "3.2.21 Method 1 Addressing
   [...] Method 1 logical sector numbering is not defined for
   sectors outside of the program area."
This sector numbering is in effect with command READ CD. The "program area"
is the payload part of the CD with a single track.
So READ CD with logical block address -1 is not defined.

-
Experiments with the ASUS drive:

(Anybody remembers BCD number encoding ? I can be glad that they did not
choose to use Gray codes. BCD is easy to write in hex. :))

The READ CD MSF expects an inclusive start address (here 00:01:74) and
an exclusive end address (here 00:02:00). Except the address fields it
has the same byte layout as READ CD. So the command as replacement for
the bad READ CD command

  be 00 ff ff ff ff 00 00 01 10 00 00

is

  b9 00 00 00 01 74 00 02 00 10 00 00

This does not yield a good result in form a of data, but also no bad
consequences for the drive or complaints from the transport layer in dmesg.

  $ sg_raw /dev/sr0 b9 00 00 00 01 74 00 02 00 10 00 00 --request=2352 
--outfile=tdb_data.bin
  SCSI Status: Check Condition

  Sense Information:
  Fixed format, current; Sense key: Illegal Request
  Additional sense: Invalid field in cdb

  Error 5 occurred, no data received

(I meanwhile learned that i need to tell sg_raw to expect a certain number
of bytes as reply. My choice 2352 is the size of CD-DA payload. The data
CD is supposed to deliver only 2048 bytes of payload. I tried a request
size of 2048, but the behavior of sg_raw did not change.)

In order to prove that my SCSI command is correctly encoded, i asked for
the first valid payload block at 00:02:00 = LBA 0 :

  $ sg_raw /dev/sr0 b9 00 00 00 02 00 00 02 01 10 00 00 --request=2352 
--outfile=tdb_data.bin
  SCSI Status: Good

  Writing 2352 bytes of data to tdb_data.bin

The file tdb_data.bin shows the MBR data of the Debian netinst ISO.
The same result i get with a valid READ CD command for LBA 0:

  $ sg_raw /dev/sr0 be 00 00 00 00 00 00 00 01 10 00 00 --request=2352 
--outfile=tdb_data.bin

None of these experiments caused problems like with Brasero.

-
What does PIONEER BD-RW BDR-S09 say to such commands:

  $ sg_raw /dev/sr1 b9 00 00 00 01 74 00 02 00 10 00 00 --request=2352 
--outfile=tdb_data.bin
  SCSI Status: Check Condition

  Sense Information:
  Fixed format, current; Sense key: Illegal Request
  Additional sense: Invalid field in cdb

  Error 5 occurred, no data received

The drive is still usable and dmesg shows no new complaints.
(Except blkid's graceful failures to read the Run-out blocks.)

With CDB b9 00 00 00 02 00 00 02 01 10 00 00 i get the first data block
from the CD: the isohybrid MBR, which xorriso inserted when it created
the ISO for the debian-cd project.

Now for the ugly test:

  $ sg_raw /dev/sr1 be 00 ff ff ff ff 00 00 01 10 00 00 --request=2352 
--outfile=tdb_data.bin
  SCSI Status: Check Condition

  Sense Information:
  Fixed format, current; Sense key: Illegal Request
  Additional sense: Logical block address out of range

  Error 22 occurred, no data received

It turns out that this drive and its transport layers in the kernel can
stand the bad READ CD command.
No dmesg complaints to see from this experiment. xorriso still works with
the drive.

This quite kills the theory that the kernel transport layer gets a hickup
without the help of the drive's SATA interface.

So the ASUS drive indeed has a stake in the problem.

-
And the TSSTcorp CDDVDW SH-S223B :

  $ sg_raw /dev/sr2 b9 00 00 00 01 74 00 02 00 10 00 00 --request=2352 
--outfile=tdb_data.bin
  SCSI Status: Check Condition

  Sense Information:
  Fixed format, current; Sense key: Illegal Request
  Additional sense: 

Bug#996048: [Pkg-openssl-devel] Bug#996048: postfix-mta-sts-resolver: autopkgtest doesn't handle new version of ca-certificates nicely: rehash: warning: skipping ca-certificates.crt, it does not conta

[Benjamin Hof]

Control: reassign -1 src:ca-certificates

On Monday, 08 November 2021, 15:57 +0200, Adrian Bunk wrote:
> On Tue, Oct 19, 2021 at 09:13:56AM +0200, Julien Cristau wrote:
> > On Mon, Oct 18, 2021 at 11:05:14PM +0200, Kurt Roeckx wrote:
> > > On Mon, Oct 18, 2021 at 10:40:59PM +0200, Julien Cristau wrote:
> > > > On Mon, Oct 18, 2021 at 02:50:50PM +0200, Benjamin Hof wrote:
> > > > > Hi,
> > > > > 
> > > > > I think the following change might be the relevant one:
> > > > > 
> > > > > --- a/update-ca-certificates
> > > > > +++ b/update-ca-certificates
> > > > > @@ -164,8 +164,6 @@
> > > > >done
> > > > >  fi
> > > > > 
> > > > > -rm -f "$CERTBUNDLE"
> > > > > -
> > > > >  ADDED_CNT=$(wc -l < "$ADDED")
> > > > >  REMOVED_CNT=$(wc -l < "$REMOVED")
> > > > > 
> > > > > It triggers this stderr output during openssl rehash (l. 184):
> > > > > 
> > > > > rehash: warning: skipping ca-certificates.crt,it does not contain 
> > > > > exactly one certificate or CRL
> > > > > 
> > > > Ah, that makes sense.  Annoying...
> > > > 
> > > > Kurt/Sebastian, do you think there's a chance openssl rehash could grow
> > > > some sort of ignore option so update-ca-certificates could ask it to
> > > > skip ca-certificates.crt, to avoid spitting out a warning for it?
> > > 
> > > As in rehash all files in that directory, excluding a file? I
> > > guess that's an option. I guess it's not an option to move the
> > > file to a different location.
> > > 
> > Exactly.  /etc/ssl/certs/ca-certificates.crt is the package's main
> > "interface" so I suspect it'd be quite painful to move.  Likewise moving
> > the certs and hash symlinks themselves would break packages/scripts
> > looking them up that way.
> > 
> > The other option for me would be to revert the fix for bug #920348.
> 
> In any case, there is nothing happening here specific to 
> postfix-mta-sts-resolver, the same problem would happen with
> any other package that does not permit stderr output in the
> autopkgtest when upgrading ca-certificates is tested.
> 
> The failing part of the autopkgtest is a testing->unstable upgrade of
> ca-certificates.
> 
> Any objections to reassigning this to ca-certificates?

Sure!

Kind regards,
Benjamin

Bug#989409: nss-pam-ldapd's autopkgtest fails with OpenLDAP 2.5

[Arthur de Jong]

Control: tags -1 + patch

Hi Ryan,

On Fri, 2021-06-04 at 11:19 -0700, Ryan Tandy wrote:
> Hi. The attached patch updates the test slapd config to support
> OpenLDAP 2.5 in addition to 2.4.

Thanks for the patch. I've applied it in the upstream repo and I plan
to make a new release soon.

> However the test_pamcmds script fails with the new version. The login
> with the correct password fails, the issue seems to be (from
> nslcd.log):
> 
> nslcd: [a88611]  DEBUG: got 
> LDAP_CONTROL_PASSWORDPOLICYRESPONSE (Password must be changed)
> nslcd: [a88611]  DEBUG: myldap_search(base="cn=Veronica 
> Sefcovic+uid=vsefcovic,ou=lotsofpeople,dc=test,dc=tld", 
> filter="(objectClass=*)")
> nslcd: [a88611]  ldap_result() failed: Insufficient 
> access: Operations are restricted to bind/unbind/abandon/StartTLS/modify 
> password
> 
> Still looking into it, not sure why the new ppolicy wants the
> password changed after it was just reset earlier.

Do you know at which step this failed in the test_pamcmds test? In
general I found ppolicy controls during authentication to be somewhat
confusing, especially when a password was about to expire or needed to
be changed.

This heavily depends on the LDAP server implementation but it could be
that the bind operation succeeds (with ppolicy control messages) but
the search that is done afterwards fails (e.g. because the connection
can only be used to change the password). By default nslcd does a
search operation to check whether the bind operation was actually
successful (there are LDAP servers that, for some bind operations, do
not return a proper error but do not have a working session
afterwards). This can be configured with the pam_authc_search option.

Kind regards,

-- 
-- arthur - art...@arthurdejong.org - https://arthurdejong.org/ --



signature.asc
Description: This is a digitally signed message part

Bug#960145: Description: is misleading with regards to jwm having few dependencies

[Samuel Henrique]

control: retitle -1 Please provide jwm-tiny with minimum dependencies

Hello Ivan,

Thank you for this bug report,

I have updated the description as per your suggestion on 2.4.0-1.

I'm renaming this bugreport to reflect your request to provide the
jwm-tiny package. I'm not sure when I will have time to prioritize
this, but I can accept patches from people interested in it.

If you're aware of other people who would like to have jwm-tiny, or
your use case impacts multiple users, please let me know.

Thanks,

-- 
Samuel Henrique 

Bug#999668: bullseye-pu: package jwm/2.3.7-5+deb11u1

[Samuel Henrique]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bullseye
X-Debbugs-Cc: samuel...@debian.org
Severity: normal

[ Reason ]
Fix segfault when using keyboard bindings to move a window for the
first time (uninitialized variable).
This issue is present on jwm 2.3.7, so it affects both stable and
oldstable (It also affects testing but 2.4.0 is soon gonna migrate
from unstable).

[ Impact ]
JWM will crash and exit if the user tries to move a window using the
keyboard bindings for the first time (it won't if the window gets
moved by the mouse first).

[ Tests ]
Manually reproduced the issue and confirmed that the fix addresses it.

[ Risks ]
I don't think there's a risk of a regression since the fix is a
oneliner, initializing the variable.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Backport of an upstream patch that initializes the currentClient variable.

[ Other info ]
https://bugs.debian.org/977878
https://github.com/joewing/jwm/issues/410
https://github.com/rdnvndr/jwm/commit/d0e28abd8eb8748470f07595be6da5cec05b4939

As per the latest instructions from the release team, I have gone
ahead and uploaded the fix already.

-- 
Samuel Henrique 


jwm_2.3.7-5+deb11u1.debdiff
Description: Binary data

Bug#999544: Update golang-v2ray-core to new upstream

[Roger Shimizu]

Dear Aloïs,

Personally I don't use upstream branch, and I don't think it's necessary.
But if it meet your workflow, I don't have objectection to add this branch.

My workflow is simple:
- use "uscan -dd" to download latest or specified upstream tarball
- merge debian (or master) branch with upstream tag. Maybe removing
some files in "excluded" of d/copyright is necessary.
- use gbp command to build

Hope it helps.

Cheers,
Roger

On Sun, Nov 14, 2021 at 5:49 PM Aloïs Micard  wrote:
>
> Hello Roger,
>
> On 14/11/2021 09:11, Roger Shimizu wrote:
> > Dear Aloïs,
> >
> > Thanks for your work to go packages!
> > Sorry I don't have time lately. So if you can update the packages and
> > fix the RC bugs, it'd be appreciated.
> >
>
> Sure thing. The only thing is: have you push the upstream branch on the
> repository? It looks like there's none and therefore `gbp import-orig --uscan`
> is failing:
>
> ```
> creekorful@debuild:~/code/golang-v2ray-core$ gbp import-orig --uscan
> gbp:error: Repository does not have branch 'upstream' for upstream sources. 
> If there is none see
> file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.CONVERT
> on howto create it otherwise use --upstream-branch to specify it.
> ```
>
> It could be really helpful if you either push upstream branch or explain me
> which workflow you are using.
>
> > Cheers,
> > Roger
> >
>
> Cheers,
>
> --
> Aloïs Micard 
>
> GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2

Bug#994405: libgmp10:i386: buffer overflow due to integer overflow in mpz/inp_raw.c on 32-bit machines

[Vincent Lefevre]

On 2021-11-14 14:15:25 +0100, Anton Gladky wrote:
> well, I was thinking that upstream should request a CVE. Neverheless
> I could not reproduce the issue with the modern GCC-versions.
> Even on 32bit-systems.

I can still reproduce the segmentation fault under Debian/unstable.
Simplified testcase:

#include 
#include 

int main (void)
{
  mpz_t s;
  mpz_init (s);
  mpz_inp_raw (s, stdin);
  return 0;
}

Compile with gcc -m32 and execute:

  printf 12345 | ./testcase

Note that even if you don't get a segmentation fault, there may be
other erratic behaviors, such as silent memory corruption (which may
be even worse).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#996892: cyrus-sasl2: consider handling as system library

[Bastian Germann]

On Wed, 20 Oct 2021 12:42:58 +0200 Bastian Germann wrote:
As you probably know, BSD-4-clause has the same problem (advertisement clause in 
combination with GPL) as the OpenSSL license. With cyrus-sasl2 (libsasl2-2), there is one 
important BSD-4-clause licensed package in the archive.


cyrus-sasl2 is not only covered by CMU's BSD-4-clause but also by RSA-MD and OpenSSL/SSLeay licenses 
that are problematic with GPL.

Bug#799864: RFH: cyrus-sasl2

[Bastian Germann]

On 06.11.21 00:20, Bastian Germann wrote:

On Wed, 23 Sep 2015 14:40:58 +0200 ond...@debian.org wrote:


cyrus-sasl2 needs you!  The most (all) of the members of packaging
team are dormant, and the cyrus-sasl2 feels neglected, we need a new
blood who will love and care about cyrus-sasl2.

There are not much upstream releases in past and the package is also
in semi-good shape, so it's mostly about looking at the user reported
bugs, reporting the upstream bugs to upstream bugzilla, and pulling
the patches back.  The usual drill...  If you apply remember that this
is the SASL package that's the core of many authentication protocols,
so you should be sure about every change to the package you do.


Hi Ondrej,

I have started working at the package and just uploaded a new version as NMU
with 3 days delay. Please tell me if you are okay with the changes and then I
will add myself in the uploaders list and continue working on the package,
closing the RFH.


I have just uploaded the lintian-clean 2.1.27+dfsg2-1 to DELAYED/3 with my name
in the Uploaders list. Please notify me if you are not okay with that.

Bug#998547: ping to avoid autorm

[Chris Hofstaedtler]

pinging #998547 to avoid autorm of pdns, as #998816 is still
awaiting ftpmaster processing, which would then allow pdns to
migrate.

Bug#963057: please detect static libs that contains lto .o files

[Bill Allombert]

On Sun, Nov 14, 2021 at 05:41:41AM -0800, Felix Lechner wrote:
> Hi,
> 
> On Thu, Jun 18, 2020 at 5:45 AM Bill Allombert  wrote:
> >
> > Could lintian detect static libraries that contain LTO objects files
> > instead of standard object files ?
> 
> We just implemented a tag when the use of LTO renders a static archive
> is unusable [1]:
> 
>  
> https://salsa.debian.org/lintian/lintian/-/commit/7f4621daf12355d271b943cbd1179829f7e12159
> 
> Do we need a separate tag for all uses of LTO, as requested here?
> 
> Would a classification tag be appropriate? At a minimum, it would
> allow further research into the prevalence. Thanks!

Hello Felix,

We need separate tags for the two cases, because one is a major bug 
(the .a is useless) and the other is a minor bug (the .a is uselessly
large).

Cheers,
Bill

Bug#963057: please detect static libs that contains lto .o files

[Felix Lechner]

Hi,

On Thu, Jun 18, 2020 at 5:45 AM Bill Allombert  wrote:
>
> Could lintian detect static libraries that contain LTO objects files
> instead of standard object files ?

We just implemented a tag when the use of LTO renders a static archive
is unusable [1]:

 
https://salsa.debian.org/lintian/lintian/-/commit/7f4621daf12355d271b943cbd1179829f7e12159

Do we need a separate tag for all uses of LTO, as requested here?

Would a classification tag be appropriate? At a minimum, it would
allow further research into the prevalence. Thanks!

Kind regards,
Felix Lechner

[1] https://bugs.debian.org/977596

Bug#988087: shadow: subid ranges sourced from the network store / support for nsswitch

[Salvatore Bonaccorso]

On Wed, May 05, 2021 at 10:32:28AM +0200, Salvatore Bonaccorso wrote:
> Source: shadow
> Version: 1:4.8.1-1
> Severity: wishlist
> Tags: upstream
> Forwarded: https://github.com/shadow-maint/shadow/issues/154
> X-Debbugs-Cc: car...@debian.org
> 
> Hi
> 
> This is not Debian specific, but decided to fill the bugreport to make
> aware of interest of such support. This raised in at least 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1715195 and upstream in
> https://github.com/shadow-maint/shadow/issues/154 which has now an
> implementation as
> https://github.com/shadow-maint/shadow/commit/8492dee6632e340dee76eee895c3e30877bebf45
> .

The initial support for this should be included in the new upstream
version 4.9.

Regards,
Salvatore

Bug#999666: Please ship the MaxMind ACL plugin, replacing the GeoIP plugin

[Faidon Liambotis]

Package: src:trafficserver
Version: 9.1.1+ds-1
Severity: normal

trafficserver 9.1.0 added[1] the "maxmind acl" plugin, to replace the
geoip acl plugin. The geoip plugin uses the deprecated libgeoip library,
which uses the legacy GeoIP/GeoLite databases. The maxmind plugin uses
instead the replacement libmaxminddb library (by the same upstream, and
btw with myself as the Debian maintainer), which can use the GeoIP2 or
GeoLite2 databases, or any other databases in the openly documented MMDB
format (e.g. DB-IP's databases).

Adding support in the package is just a matter of adding a
libmaxminddb-dev dependency, and shipping the generated
/usr/lib/trafficserver/modules/maxmind_acl.so. The build system
automatically detects the presence of the library and builds the plugin.

I would advise to remove the libgeoip-dev dependency and to stop
shipping the geoip plugin, as no up-to-date/accurate databases will be
available during the bookworm cycle. If you do decide in keeping that
plugin for backwards-compatibility reasons, however, I would strongly
advise to pass --with-hrw-geo-provider=maxminddb, in order to pick
maxminddb over geoip in the presence of both.

Thanks for the consideration and for caring for this package!

Regards,
Faidon

1: 
https://github.com/apache/trafficserver/commit/b757688230b82ffaa61aec401b5d026cf0e20dc0

Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW

[Thomas Schmitt]

Hi,

Mauro Sacchetto wrote:
> samiel@darkstar:~$ sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00
> --outfile=tdb_data.bin
> SCSI Status: Check Condition
>
> Sense Information:
> Fixed format, current; Sense key: Illegal Request
> Additional sense: Unaligned write command

Now we know from where that error came, which is inappropriate for
optical drives. (Maybe that the kernel created it, and not the drive.)

> Is it my test right and enough?

The main question is:

Is the drive unusable afterwards ?

(I.e. do i have identified the culprit for your drive problem ?)


> In fact I am a little surprised (although I don't know how these things are
> handled by the Debin team)
> that so far there has been no intervention by the packagers of Brasero

I understand that there is no upstream developer any more and no community
which would continue the GUI part and build it with patch proposals.
It looks like i was involved in the second youngest thread on the mailing
list, back in 2019:
  https://mail.gnome.org/archives/brasero-list/2019-January/thread.html
The youngest thread is a request for help with building Brasero. It got
no answer.

Possibly i will post a report about the problem there. Just in case some
new developer shows up.


Said that, and contrary to my statement in the previous mail, i have not
yet used up my ideas for experiments:

- Will the Pioneer drive go bad if i send the READ CD 0x command ?
  It looks like Brasero doesn't do this.

- Will READ CD MSF 00:01:74 work better ?
  Maybe with all three drives without incident and dmesg complaint ?
  (I have to study the specs, because i never used that command before.)

If the Pioneer drive goes bad too, then it might even be a kernel
problem with that obviously disliked sector address, and not a problem
only with the ASUS drive.

This could become obvious if the

  Additional sense: Unaligned write command

from your above experiment changes to my result

  >>> transport error: Host_status=0x03 [DID_TIME_OUT]

if you use kernel 5.10.


Have a nice day :)

Thomas

Bug#999665: dh_strip_nondeterminism breaks Multi-Arch: same in binNMUs

[Helmut Grohne]

Package: debhelper
Version: 13.5.2
Severity: important
X-Debbugs-Cc: debian-cr...@lists.debian.org, 
rb-gene...@lists.reproducible-builds.org

Hi,

dh_strip_nondeterminism was automatically enabled on the provision that
it wouldn't break stuff. To a large extend, that's the case.
Unfortunately, there is a corner case where it does get things wrong and
we cannot make progress as the requirements appear to conflict with one
another. The issue is reported as #950806.

The situation is that when performing a binNMU, the changelogs are
created with differing timestamps. (That's a technical limitation of our
archive implementation. In theory, binNMUs could use equal timestamps
and sbuid already has --binNMU-timestamp.) As a consequence, the
SOURCE_DATE_EPOCH differs. When dh_strip_nondeterminism fixes up files,
it actually makes them differ from one another in a coinstallationset of
Multi-Arch: same packages. Files that were previously reproducible are
made unreproducible by dh_strip_nondeterminism. The behaviour used to be
different and the most recent non-binNMU date was considered, but that
happend to break backup software as it could no longer detect
modifications from a non-binNMU to binNMU upgrade. That is how we ended
up with current situation.

So we're actually talking about a relatively small set of affected
packages. Unfortunately, libruby2.N is among them and that has a
relatively high impact. But the issue does not stop there. We've had
other high profile cases in the past. They tend to pop up at unfortunate
times.

In order for a package to actually hit the bug, two conditions must be
met simultaneously:
 * Some binary package must be marked Multi-Arch: same.
 * The build must be a binNMU.

We can estimate this set using grep-dctrl:

grep-dctrl '(' -r -F Version '.*+b[0-9]\+$' ')' --and '(' -F Multi-Arch -X same 
')' -s Package -n $PKGFILE

For unstable, that's about 2100 binary packages built from 900 source
packages at present.

Given that there is no progress for prolonged time, we have a choice:
Either we produce reproducible packages that happen to not be
installable or we produce installable packages that happen to not be
reproducible. The trade-off appears obvious to me. Keep in mind that
dh_strip_nondeterminism was enabled on the provision of not breaking
stuff. Now it does break stuff.

As such, I propose that debhelper automatically disables
dh_strip_nondeterminism if and only if both relevant conditions are met.
What do you think about this?

I think the reproducible builds folks favour a solution that involves
sourcefull uploads replacing binNMUs. The proposed workaround does not
interfere with the reproducible proposal in any way.

Do you need a patch?

Helmut

Bug#994405: libgmp10:i386: buffer overflow due to integer overflow in mpz/inp_raw.c on 32-bit machines

[Anton Gladky]

Hi Adrian,

well, I was thinking that upstream should request a CVE. Neverheless
I could not reproduce the issue with the modern GCC-versions.
Even on 32bit-systems.

Regards

Anton

Am Sa., 13. Nov. 2021 um 21:09 Uhr schrieb Adrian Bunk :
>
> On Fri, Sep 17, 2021 at 07:02:48AM +0200, Anton Gladky wrote:
> > Thanks, Vincent, for the information. I would still wait for CVE,
> > so we can apply a patch and track vulnerability for other
> > Debian versions (stable/oldstable/o-o-stable etc.).
>
> Hi Anton,
>
> did you manage to get a CVE assigned for this issue, or has there been
> any problem with tnat?
>
> > Regards
> >
> > Anton
>
> Thanks
> Adrian

Bug#999664: Package severely outdated (unmaintained?)

[Faidon Liambotis]

Package: ipv6calc
Version: 1.0.0-1.1
Severity: important

Debian is currently shipping ipv6calc 1.0.0. Upstream has released 12
new upstream releases since, and is currently at 4.0.0.

I'm marking this as important rather than as wishlist, because it feels
like the package is unmaintained/uncared for (has not received a
maintainer upload since May 2018). I contemplated marking it as RC as
well to avoid such a stale upstream version be released with bookwork.
If you as a maintainer disagree, feel free to downgrade, though.

Regards,
Faidon

Bug#985578: [Pkg-electronics-devel] Bug#985578: arduino-core-avr: Flashing bootloader fails due to invalid size

[Rock Storm]

On Sun, 2021-11-14 at 02:18 +0300, Alexander Buzin wrote:
> My system is Debian bullseye+backports. No foreign apps.
> It seems that Debian includes an ancient version of optiboot (v.4.4 of
> January 2012). It is unusable because the size of the resulting
> bootloader is too big. Current version (v.8.3) can be compiled with
> our default toolchain and produces a hex file which has correct size
> and is identical to the one on the optiboot github (see the line above
> with diff).
> Maybe this information will be of some use, because the current
> situation with non working bootloader is quite inconvenient.
>

Thank you for you addition here.

I apologise in advance, I lack the knowledge/time to thoroughly test
this. But reading this got me thinking.

Open question to all list readers, am I right in thinking that:

 - Current avr-gcc toolchain is able to successfully compile the latest
optiboot (i.e. v8.0?)

 - Current arduino package (version 2:1.8.16+dfsg1-1~bpo11+1) is happy
with the hex files generated above.

Since we simply ship the very optiboot version that Arduino ships on
its ArduinoCore-avr repository. I'd conclude there is no other solution
than to request upstream the latest optiboot be shipped in the next
release? It's probably been requested already as in [1] but has seen no
movement in 4 years. Are there any big regression issues between
optiboot's versions 4.4 and 8.0?

[1]: https://github.com/arduino/ArduinoCore-avr/issues/121

Regards,

--
Rock Storm
Open PGP: C304 34B3 632C 464C 2FAF C741 0439 CF52 C968 32FD

Bug#999663: zfs-linux: FTBFS with libabigail 2.0

[Andreas Beckmann]

Source: zfs-linux
Version: 2.0.6-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

zfs-linux recently started to FTBFS, I suspect this to be caused by the
upgrade of libabigail to 2.0:

   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/zfs-linux-2.0.6'
# Upstream provides an ABI guarantee that we validate here
/usr/bin/make checkabi
make[2]: Entering directory '/build/zfs-linux-2.0.6'
/usr/bin/make -C lib checkabi
make[3]: Entering directory '/build/zfs-linux-2.0.6/lib'
set -e ; for dir in libnvpair libuutil libzfs_core libzfs libzfsbootenv ; do \
/usr/bin/make -C $dir checkabi ; \
done
make[4]: Entering directory '/build/zfs-linux-2.0.6/lib/libnvpair'
for lib in libnvpair.la ; do \
abidiff --no-unreferenced-symbols \
--headers-dir1 ../../include \
--suppressions ${lib%.la}.suppr \
${lib%.la}.abi .libs/${lib%.la}.so ; \
done
abidiff: incompatible format version between the two input files:
'libnvpair.abi'
and
'.libs/libnvpair.so'
make[4]: *** [Makefile:1089: checkabi] Error 1
make[4]: Leaving directory '/build/zfs-linux-2.0.6/lib/libnvpair'
make[3]: *** [Makefile:964: checkabi] Error 2
make[3]: Leaving directory '/build/zfs-linux-2.0.6/lib'
make[2]: *** [Makefile:1502: checkabi] Error 2
make[2]: Leaving directory '/build/zfs-linux-2.0.6'
make[1]: *** [debian/rules:83: override_dh_auto_test] Error 2
make[1]: Leaving directory '/build/zfs-linux-2.0.6'
make: *** [debian/rules:34: binary] Error 2


Andreas


zfs-linux_2.0.6-1.log.gz
Description: application/gzip

Bug#999662: clamav-daemon: Use systemd isolation features to reduce risk by compromised clamav-daemon

[Andreas Feldner]

Package: clamav-daemon
Version: 0.103.3+dfsg-0+deb11u1
Severity: wishlist

Dear Maintainer,

clamav-daemon is currently shipped with a systemd unit file that makes
no use of systemd securty features. I found that a number of attack vectors
can be closed without inferring problems with functionality.

This is my version of /lib/systemd/system/clamav-daemon.service that seems to
work OK:


[Unit]
Description=Clam AntiVirus userspace daemon
Documentation=man:clamd(8) man:clamd.conf(5) https://www.clamav.net/documents/
# Check for database existence
ConditionPathExistsGlob=/var/lib/clamav/main.{c[vl]d,inc}
ConditionPathExistsGlob=/var/lib/clamav/daily.{c[vl]d,inc}

[Service]
ExecStart=/usr/sbin/clamd --foreground=true
User=clamav
# Reload the database
ExecReload=/bin/kill -USR2 $MAINPID
StandardOutput=syslog
TimeoutStartSec=420
PrivateTmp=true
CapabilityBoundingSet=~CAP_SETUID CAP_SETGID CAP_SETPCAP
CapabilityBoundingSet=~CAP_SYS_ADMIN
CapabilityBoundingSet=~CAP_SYS_PTRACE
RestrictNamespaces=~CLONE_NEWUSER
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
CapabilityBoundingSet=~CAP_CHOWN CAP_FSETID CAP_SETFCAP
CapabilityBoundingSet=~CAP_FOWNER CAP_IPC_OWNER
CapabilityBoundingSet=~CAP_NET_ADMIN
CapabilityBoundingSet=~CAP_SYS_MODULE
CapabilityBoundingSet=~CAP_SYS_RAWIO
CapabilityBoundingSet=~CAP_SYS_TIME

[Install]
WantedBy=multi-user.target



-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
AlertExceedsMax disabled
PreludeEnable disabled
PreludeAnalyzerName = "ClamAV"
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile disabled
TemporaryDirectory disabled
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "26214400"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "30"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
ConcurrentDatabaseReload = "yes"
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
ScanPE = "yes"
ScanELF = "yes"
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
HeuristicAlerts = "yes"
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
AlertBrokenExecutables disabled
AlertBrokenMedia disabled
AlertEncrypted disabled
StructuredCCOnly disabled
AlertEncryptedArchive disabled
AlertEncryptedDoc disabled
AlertOLE2Macros disabled
AlertPhishingSSLMismatch disabled
AlertPhishingCloak disabled
AlertPartitionIntersection disabled
ScanPDF = "yes"
ScanSWF = "yes"
ScanXMLDOCS = "yes"
ScanHWP3 = "yes"
ScanArchive = "yes"
ForceToDisk disabled
MaxScanTime = "12"
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
MaxEmbeddedPE = "10485760"
MaxHTMLNormalize = "10485760"
MaxHTMLNoTags = "2097152"
MaxScriptNormalize = "5242880"
MaxZipTypeRcg = "1048576"
MaxPartitions = "50"
MaxIconsPE = "100"
MaxRecHWP3 = "16"
PCREMatchLimit = "1"
PCRERecMatchLimit = "5000"
PCREMaxFileSize = "26214400"
OnAccessMountPath disabled
OnAccessIncludePath disabled
OnAccessExcludePath disabled
OnAccessExcludeRootUID disabled
OnAccessExcludeUID disabled
OnAccessExcludeUname disabled
OnAccessMaxFileSize = "5242880"
OnAccessDisableDDD disabled
OnAccessPrevention disabled
OnAccessExtraScanning disabled
OnAccessCurlTimeout = "5000"
OnAccessMaxThreads = "5"
OnAccessRetryAttempts disabled
OnAccessDenyOnError disabled
DevACOnly disabled
DevACDepth disabled
DevPerformance disabled
DevLiblog disabled
DisableCertCheck disabled
AlgorithmicDetection = "yes"
BlockMax disabled
PhishingAlwaysBlockSSLMismatch disabled
PhishingAlwaysBlockCloak disabled
PartitionIntersection disabled
OLE2BlockMacros disabled
ArchiveBlockEncrypted disabled

Config file: freshclam.conf
---
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
PidFile disabled

Bug#997911: lintian: bash-term-in-posix-shell false positive for '<<<' in quoted strings

[Andreas Metzler]

On 2021-10-27 Andreas Beckmann  wrote:
> Package: lintian
> Version: 2.110.0
> Severity: important

> Hi,

> src:nvidia-graphics-driver has this in its bug script:

> echo "<< $file >>"
[...]

Hello,

The curly-braces check ("{foo,bar} instead of foo bar") also has some
false positives, afaik ${VARIABLE} is perfectly legal but trigggers a
warning:
I: exim4-base: bash-term-in-posix-shell [etc/cron.daily/exim4-base:62] 
'${HOSTNAME
The line number seems to be off, BTW:
ametzler@argenau:/tmp/EXIM4$ cat -n 
exim-4.95/debian/exim4-base/etc/cron.daily/exim4-base  | grep HOSTNAME
38  if ! HOSTNAME=$(/usr/sbin/exim4 -be '${primary_hostname}'); then
39  HOSTNAME="$(hostname)"
61  | mail -s"${HOSTNAME} Daily e-mail activity report" \
65  | mail -s"${HOSTNAME} Daily e-mail activity report" \
91"${HOSTNAME}" "${E4BCD_PANICLOG_REPORT_TO}" "${HOSTNAME}" \

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#999661: Incorrect entries in /etc/apt/sources.list

[Stefan Blachmann]

Package: Base System
Version: Current
The bug described here
https://the-codeslinger.com/2020/03/26/debian-bullseye-the-repository-does-not-have-a-release-file/
is still there one and a half year later.
Please. Could somebody fix it?

Bug#985579: arduino-core-avr: Lock bit values fail verification

[Rock Storm]

Control: forwarded -1
https://github.com/arduino/ArduinoCore-avr/issues/436

Bug acknowledged. Thank you very much for reporting.

--
Rock Storm
Open PGP: C304 34B3 632C 464C 2FAF C741 0439 CF52 C968 32FD

Bug#998694: [Pkg-shadow-devel] Bug#998694: Don't timeout if you haven't asked for password yet

[Bálint Réczey]

Control: tags -1 wontfix

Hi Dan,

積丹尼 Dan Jacobson  ezt írta (időpont: 2021. nov.
6., Szo, 19:00):
>
> Package: login
> Version: 1:4.8.1-1.1
>
> (/usr/share/doc/login/copyright says
> This is Debian GNU/Linux's prepackaged version of the shadow utilities.
>
> It was downloaded from: .
> As of May 2007, this site is no longer available.)

The Homepage: https://github.com/shadow-maint/shadow info is up to
date, but the copyright file should be updated, I agree.

> OK, I'll report the bug here:
>
> Let's say the system is so overloaded that...
>
> Login: root
>
> Login timed out after 60 seconds
>
> Yes, that's right, even before the password prompt appeared!
>
> So that timeout will prevent access to the whole system!
>
> So: at least don't timeout if you haven't asked for password yet!

The timer is set right before calling pam_start() in login.c, thus it
would not be easy to delay that. If you have a system unable to show
password prompt for 1 minute it is unlikely that you can get in even
with a timeout started later.

Cheers,
Balint

> Thanks.
>
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#999660: numba: upstream release v0.54 now available

[Drew Parsons]

Source: numba
Version: 0.52.0-5
Severity: normal

llvmlite 0.37 is now packaged and migrated to testing. That clears
the way for packaging numba 0.54.

numba 0.54 has some patches that will hopefully improve reliability on
non-amd64 arches.

Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW

[Mauro Sacchetto]

Il 14/11/21 12:02, Thomas Schmitt ha scritto:

Hi,

i now have clear evidence from a run of

   sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin

that the read attempt for sector 0x (= -1) brings the
ASUS DRW-24D5MT into the unusable state.

@ Mauro Sacchetto:
Could you please try to reproduce this finding after installing sg3-utils.



I obtain

===

samiel@darkstar:~$ sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 
--outfile=tdb_data.bin

SCSI Status: Check Condition

Sense Information:
Fixed format, current; Sense key: Illegal Request
Additional sense: Unaligned write command
===

Is it my test right and enough?




-
Possible remedies:

We would need a Brasero developer to find a workaround, because not
only the bad READ CD command needs to be avoided, but also a replacement
for the code gesture to distinguish TAO CDs from SAO CDs would have to
be developed.

Maybe this distinction is not really necessary. It seems not to work
properly on the TSSTcorp drive by making a false correction of the
track size. But that would be up to a Brasero developer to decide.



In fact I am a little surprised (although I don't know how these things 
are handled by the Debin team)


that so far there has been no intervention by the packagers of Brasero

Bug#999659: perdition: failed to install, failed to uninstall (error in initscript)

[Sergey Spiridonov]

Package: perdition
Version: 2.2-3.1+b1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: s...@s73.work

Dear Maintainer,

The error happens only on first install of the perdition, see instructions 
below on how to reproduce it.

First I get an error during 

# apt install perdition

Failed to stop perdition.service: Unit perdition.service not loaded.
invoke-rc.d: initscript perdition, action "stop" failed.

That happens only if there was no perdition package installed before. If
you had perdition package installed and deleted later then error is not
happening, since the command "apt purge" does not delete one generated file.

So, to reproduce, either take host where perdition was never installed
(apt purge alone will not help here!), or  

# apt purge perdition

then delete generated file:
  
# rm /run/systemd/generator.late/perdition.service

Now "apt install" will fail. 

After installation fails, you will also not be able to delete the package:

# apt purge perdition
...
Failed to stop perdition.service: Unit perdition.service not loaded.
invoke-rc.d: initscript perdition, action "stop" failed.
dpkg: error processing package perdition (--remove):
 installed perdition package pre-removal script subprocess returned error exit 
status 5
dpkg: too many errors, stopping

Here fix is easy, just edit /var/lib/dpkg/info/perdition.prerm and replace the 
line

  invoke-rc.d perdition stop

with

  invoke-rc.d perdition stop || true

Something similar must be done for the preinstall script in order to
fix the install error.

Here is full apt install output:

# LANG=C apt install perdition
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
perdition is already the newest version (2.2-3.1+b1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Setting up perdition (2.2-3.1+b1) ...
Failed to stop perdition.service: Unit perdition.service not loaded.
invoke-rc.d: initscript perdition, action "stop" failed.
dpkg: error processing package perdition (--configure):
 installed perdition package post-installation script subprocess returned error 
exit status 5
Processing triggers for libc-bin (2.31-13+deb11u2) ...
Errors were encountered while processing:
 perdition
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)


Here is full apt purge output:

# LANG=C apt purge perdition
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  perdition*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 468 kB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 19109 files and directories currently installed.)
Removing perdition (2.2-3.1+b1) ...
Failed to stop perdition.service: Unit perdition.service not loaded.
invoke-rc.d: initscript perdition, action "stop" failed.
dpkg: error processing package perdition (--remove):
 installed perdition package pre-removal script subprocess returned error exit 
status 5
dpkg: too many errors, stopping
Errors were encountered while processing:
 perdition
Processing was halted because there were too many errors.
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)




-- System Information:
Debian Release: 11.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU:ru
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages perdition depends on:
ii  libc6   2.31-13+deb11u2
ii  libdb5.35.3.28+dfsg1-0.8
ii  libgdbm61.19-2
pn  libidn11
ii  libnsl2 1.3.0-2
ii  libpam0g1.4.0-9+deb11u1
pn  libpopt0
ii  libssl1.1   1.1.1k-1+deb11u1
pn  libvanessa-adt1 
pn  libvanessa-logger0  
pn  libvanessa-socket2  
ii  lsb-base11.1.0

perdition recommends no packages.

Versions of packages perdition suggests:
pn  perdition-ldap
pn  perdition-mysql   
pn  perdition-odbc
pn  perdition-postgresql  

-- no debconf information

Bug#812127: [Pkg-shadow-devel] Bug#812127: login: wrong German error message

[Bálint Réczey]

Control: tags -1 upstream l10n

Hi Holger,

I'm sorry for keeping this hanging for so long. I'm packaging 4.9 and
the translation has been updated upstream in the meantime:
https://github.com/shadow-maint/shadow/blob/master/po/de.po

Are the new strings OK, or do they still need updating?

Cheers,
Balint


Holger Wansing  ezt írta (időpont: 2017.
febr. 6., H, 22:12):
>
> Hi,
>
> Bálint Réczey  wrote:
> > >> > As stated, I (rather firmly) believe
> > >> >> Under no cirumstance work is possible without effective root.
> > >>
> > >> IMO this is the correct interpretation.
> > >>
> > >> The place where the message is emitted is here:
> > >> http://sources.debian.net/src/shadow/1:4.4-3/src/login.c/?hl=567#L567
> > >
> > > So you should probably change the phrase in English too, to ensure it
> > > is understood correctly? (Maybe other translators have misinterpreted it
> > > too?)
> >
> > The freeze is not a great time for making changes to the original strings. 
> > :-)
> > Let's defer the resolution of this bug after Stretch is released.
> >
> > Login may be provided by util-linux per #833256 and in that case I don't 
> > wan't
> > to ask l10n teams to update a string in every language before that string 
> > goes
> > away.
>
> Attached is an updated po file for German.
>
> I have applied the proposal by Helge, and updated the other fuzzies and
> untranslated strings as well.
>
>
> Probably you can still get it into Stretch ...
>
> So long
> Holger
>
> --
> 
> Created with Sylpheed 3.5.0 under
> D E B I A N   L I N U X   8 . 0   " J E S S I E " .
>
> Registered Linux User #311290 - https://linuxcounter.net/
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#999658: ghostwriter: No HTML preview when offline

[Flössie]

Package: ghostwriter
Version: 1.8.1-2
Severity: normal

Dear Maintainer,

ghostwriter doesn't show or update the HTML preview when the
computer is disconnected from the Internet. Looking at the
network traffic when starting ghostwriter reveals connection
attempts to "cdn.jsdelivr.net". This domain is referenced in
the MathJax code in the "3rdparty" directory of the ghostwriter
sources.

AFAIK there is no hint on the ghostwriter site nor in the
documents from Debian that an Internet connection is needed
for this editor to properly work.

Apart from the external JS sources obviously needed for the
HTML preview there is no other traffic to the net, and the
preview also works when disconnecting the computer after
ghostwriter was started.

HTH,
Flössie

-- System Information:
Debian Release: 11.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (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 ghostwriter depends on:
ii  libc62.31-13+deb11u2
ii  libgcc-s110.2.1-6
ii  libhunspell-1.7-01.7.0-3
ii  libqt5concurrent55.15.2+dfsg-9
ii  libqt5core5a 5.15.2+dfsg-9
ii  libqt5gui5   5.15.2+dfsg-9
ii  libqt5svg5   5.15.2-3
ii  libqt5webchannel55.15.2-2
ii  libqt5webengine5 5.15.2+dfsg-3
ii  libqt5webenginewidgets5  5.15.2+dfsg-3
ii  libqt5widgets5   5.15.2+dfsg-9
ii  libstdc++6   10.2.1-6

ghostwriter recommends no packages.

Versions of packages ghostwriter suggests:
pn  cmark 
pn  discount  
ii  hunspell-de-de [hunspell-dictionary]  20161207-9
pn  myspell-dictionary
pn  pandoc
pn  wkhtmltopdf   

-- no debconf information

Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW

[Thomas Schmitt]

Hi,

i now have clear evidence from a run of

  sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin

that the read attempt for sector 0x (= -1) brings the
ASUS DRW-24D5MT into the unusable state.

@ Mauro Sacchetto:
Could you please try to reproduce this finding after installing sg3-utils.


The main suspect for emitting SCSI this command is Brasero function
  brasero_medium_track_written_SAO()
in libbrasero-media/brasero-medium.c .

Code study of that function and the logs of Brasero "Copy" runs with
the Pioneer and the TSSTcorp show that bad things happen if the function
is called:

- The Pioneer drive does not trigger the log message from
 brasero_medium_track_written_SAO()
  and leaves no problem report lines in dmesg.
  So i conclude that the function was not called.

- The TSSTcorp drive triggers this message:
BraseroMedia: (at brasero-medium.c:1573) Checking for TDBs in track pregap.
  and dmesg reports a (successful / harmless ?) USB reset.

-
Possible remedies:

We would need a Brasero developer to find a workaround, because not
only the bad READ CD command needs to be avoided, but also a replacement
for the code gesture to distinguish TAO CDs from SAO CDs would have to
be developed.

Maybe this distinction is not really necessary. It seems not to work
properly on the TSSTcorp drive by making a false correction of the
track size. But that would be up to a Brasero developer to decide.

A cheaper workaround would be to identify the drive model from the
function parameter
  BraseroDeviceHandle *handle
and to return before any read attempt if it is an ASUS DRW-24D5MT
and maybe others, which still need to have been found.
Again it would be up to a Brasero developer to decide whether TRUE or
FALSE would be the best reply in this case.

Maybe it would be possible to read that sector by SCSI command
READ CD MSF with address 00:01:74.
(The track begins at 00:02:00. Brasero wants one sector before that
start which to my computation would be 00:01:74.)

-
Experiments made:

I tried the "Copy" task of Brasero with the TSSTcorp drive in its USB box
at /dev/sr2.

Other than with the Pioneer at /dev/sr1, this run reports

  BraseroMedia: (at brasero-medium.c:2062) 2 track(s) found
  BraseroMedia: (at brasero-medium.c:1645) Retrieving track information for 1
  BraseroMedia: (at brasero-medium.c:1715) Data track belongs to first session 
of multisession CD. Checking for real size (193686 sectors currently).
  BraseroMedia: (at brasero-medium.c:1573) Checking for TDBs in track pregap.
  BraseroMedia: (at brasero-medium.c:1742) Correcting track size (now 193688)

which indicates that Brasero thinks this CD was written with write
type SAO.
But i burnt it with xorriso -as cdrecord -tao. libburn's demo program
telltoc reports that blocks 193687 and 193688 are not readable and thus
supposes the CD to be burnt by TAO.
Later the log confrims telltoc's findings:

  BraseroBurn: (at burn-process.c:417) BraseroCdrdao stderr: Found L-EC error 
at sector 193686 - ignored.
  BraseroBurn: (at burn-job.c:1430) BraseroCdrdao called brasero_job_get_action
  BraseroBurn: (at burn-process.c:417) BraseroCdrdao stderr: Found L-EC error 
at sector 193687 - ignore

("L-EC error" would mean a medium problem. So the drive maybe contributes
to the confusion of Brasero. dmesg reports the same errors, probably from
blkid inspecting the medium for an UDF anchor.)

dmesg reports around the time when Brasero was inspecting the drive:

  usb 1-13: reset high-speed USB device number 5 using xhci_hcd

and with another "Copy" task again:

  usb 1-13: reset high-speed USB device number 5 using xhci_hcd

Whatever, the drive stays usable and no error of READ CD for sector
0x is reported in dmesg.


Poking manually into that drive:

  # apt-get install sg3-utils

  $ sg_raw /dev/sr2 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin
  >>> transport error: Host_status=0x03 [DID_TIME_OUT]
  Driver_status=0x00 [DRIVER_OK]
  SCSI Status: Good

and another USB device reset is reported in dmesg

  usb 1-13: reset high-speed USB device number 5 using xhci_hcd

Still the drive is usable afterwards.


Now the decisive test with /dev/sr0, the ASUS drive:

No Brasero is running.
After inserting the CD into /dev/sr0, i see in dmesg complaints about
i/o errors with the last two blocks. This time not "L-EC error" but
rather "Illegal Request", as i would expect from the specs.

The drive is usable for xorriso.

So:

  $ sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin
  SCSI Status: Check Condition
  Sense Information:
  Fixed format, current; Sense key: Illegal Request
  Additional sense: Unaligned write command

dmesg reports

  ata3.00: exception Emask 0x0 SAct 

Bug#998041: RFS: makedeb/7.1.2+bugfix1-8 -- The modern packaging tool for Debian archives.

[Bastian Germann]

Control: tags -1 moreinfo

On Thu, 4 Nov 2021 20:11:18 -0700 LEO PUVILLAND wrote:> Fixed with version 8.2.1-1, currently 
processing upload on

mentors.debian.net


Hi Leo,

Please create a watch file and test it to download the tarball.

Please use a tagged version as the origtargz.

Please check lintian output and fix at least:
E: makedeb source: build-depends-on-essential-package-without-using-version 
Build-Depends: bash
E: makedeb source: build-depends-on-essential-package-without-using-version 
Build-Depends: tar
E: makedeb: depends-on-essential-package-without-using-version Depends: bash
E: makedeb: depends-on-essential-package-without-using-version Depends: tar
E: makedeb: extended-description-is-empty
E: makedeb: python3-script-but-no-python3-dep python3 
[usr/share/makedeb/utils/missing_apt_dependencies.py] (does not satisfy python3:any | 
python3-minimal:any)

E: makedeb: wrong-path-for-interpreter /hint/bash != /bin/bash 
[etc/makepkg.conf]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/buildenv.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/buildenv/buildflags.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/buildenv/compiler.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/buildenv/debugflags.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/buildenv/lto.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/buildenv/makeflags.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/executable.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/executable/ccache.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/executable/checksum.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/executable/distcc.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/executable/fakeroot.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/executable/gpg.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/executable/gzip.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/executable/pacman.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/executable/strip.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/executable/sudo.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/executable/vcs.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/integrity.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/integrity/generate_checksum.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/integrity/generate_signature.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/integrity/verify_checksum.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/integrity/verify_signature.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/lint_config.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/lint_config/ext.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/lint_config/paths.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/lint_config/source_date_epoch.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/lint_config/variable.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/lint_package.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/lint_package/build_references.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/lint_package/dotfiles.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/lint_package/file_names.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/lint_package/missing_backup.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/lint_pkgbuild.sh]
E: makedeb: wrong-path-for-interpreter /usr/bin/bash != /bin/bash 
[usr/share/makedeb-makepkg/lint_pkgbuild/arch.sh]
E: makedeb: wrong-path-for-interpreter 

Bug#999657: xserver-xorg-core: SIGABRT on Geode LX

[Martin-Éric Racine]

Package: xserver-xorg-core
Version: 2:1.20.11-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

$ sudo LC_ALL=C coredumpctl debug 796
   PID: 796 (Xorg)
   UID: 101 (Debian-gdm)
   GID: 122 (Debian-gdm)
Signal: 6 (ABRT)
 Timestamp: Sun 2021-11-14 11:56:46 EET (35min ago)
  Command Line: /usr/lib/xorg/Xorg vt1 -displayfd 3 -auth 
/run/user/101/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty 
-novtswitch -verbose 3
Executable: /usr/lib/xorg/Xorg
 Control Group: /user.slice/user-101.slice/session-c2.scope
  Unit: session-c2.scope
 Slice: user-101.slice
   Session: c2
 Owner UID: 101 (Debian-gdm)
   Boot ID: f3a26744832345239aef0aefea90c72c
Machine ID: 1063a9d1fb9df6e371ea9f94491345ed
  Hostname: geode
   Storage: 
/var/lib/systemd/coredump/core.Xorg.101.f3a26744832345239aef0aefea90c72c.796.163688380600.zst
 (present)
 Disk Size: 1.5M
   Message: Process 796 (Xorg) of user 101 dumped core.

Found module linux-gate.so.1 with build-id: 
26cfc7f594b1cd597c1dd0029da5ca8cc8a38fcd
Found module libicudata.so.67 with build-id: 
83e8d014d7a5f6d5a428b3ee29dfa7bda5a19196
Found module libicuuc.so.67 with build-id: 
f4808c52328e01d59304fe921eea551503cb6845
Found module libxml2.so.2 with build-id: 
a228f93c55a0471c6af6f854ef01fd44263c2b6c
Found module libtinfo.so.6 with build-id: 
c96350c275bfaa792c87a215e0419d0a13bcfaca
Found module libz3.so.4 with build-id: 
2cc826025173edf6736eae4d1e3cb7204a6bbd7f
Found module libedit.so.2 with build-id: 
ebb868e816530e2391a4c11101a8a343e1a70d2e
Found module libffi.so.8 with build-id: 
73cdf5d5ebbd8539c40cde02d82f5841f0d839a8
Found module libatomic.so.1 with build-id: 
9f2e8078c39a22274be214e78fab5b3f46dffd3b
Found module libgcc_s.so.1 with build-id: 
e645d7848b6fde91618294cbcc7ee43fa13e53c0
Found module libstdc++.so.6 with build-id: 
66615284d14b0f61cc9fbe643037d0873a66e471
Found module libvulkan.so.1 with build-id: 
b37c08ebda037507a652b6566c4181b38c7f3cca
Found module libdrm_nouveau.so.2 with build-id: 
de6d2837c511a549f3974046aacdebde3719bcb2
Found module libdrm_amdgpu.so.1 with build-id: 
9c2ec3c9f40a516af0886087ba01da24e6f45145
Found module libelf.so.1 with build-id: 
6c10ac18e4c9de96b7cabf0c0115bdbaaa8009d3
Found module libdrm_radeon.so.1 with build-id: 
f56eb9fa0a13d792723fc64f182dbaf9121e8b43
Found module libsensors.so.5 with build-id: 
686675d0b0908055ba7081b1f873155d28a8753d
Found module libexpat.so.1 with build-id: 
93a838c801828692e5922d763ccaefdba2733ebe
Found module libLLVM-12.so.1 with build-id: 
42f0f6873784c93609b3de4f251969932c58638d
Found module libglapi.so.0 with build-id: 
c39e117948f1ff056758e91f09164b0fec081fa7
Found module swrast_dri.so with build-id: 
f97cd40fd941328398c07fc3bffd840a703ffc73
Found module libexa.so with build-id: 
7d820816d6768df89205424d2072bba1a94d95a8
Found module libfb.so with build-id: 
39663b5f810f6861868f3e4a1f94428b99ac13e6
Found module libint10.so with build-id: 
fc3f53c365dba85b60e9137106d62ac75ddaec62
Found module libvgahw.so with build-id: 
c9e255566c4cb25933b352cf799eda69a1261c92
Found module geode_drv.so with build-id: 
75869e0950418b46e56072e542d90f09892da7b7
Found module libxcb.so.1 with build-id: 
03195227c69b0195390b4b8b5ee188bb12cb1cd3
Found module libX11.so.6 with build-id: 
35a90bcb02a9b194371505741049efe58b4c8769
Found module libGLX.so.0 with build-id: 
c75c08d5765c67238038b85348a34845774bd92e
Found module libGLdispatch.so.0 with build-id: 
bc9e99fc57dd02a74d7e7a3ed8a792688e054354
Found module libGL.so.1 with build-id: 
fbfc96e21f8bb5dbb7fc1a821803eba49bfad018
Found module libglx.so with build-id: 
7a6f6a7ee6b4c97d85a65d556de35d2ed55db275
Found module libbrotlicommon.so.1 with build-id: 
f63efc2a7a62dd49dddfc67aec6b4fb6d7041c9c
Found module libbrotlidec.so.1 with build-id: 
f54312be9fd635f41c88a2fba6f48194b5a514e5
Found module libpng16.so.16 with build-id: 
d63474e9123664b790ae0dea7c0d3f14d756ea98
Found module libmd.so.0 with build-id: 
f9f1c69ce240aea241d9978cf6146a61d9061bd0
Found module libcap-ng.so.0 with build-id: 
aa6038a53112df6f372332a19d44df3f0226cf3e
Found module libcap.so.2 with build-id: 
dd3588996222b97eb95fbcf60452215fe44ae0c5
Found module liblz4.so.1 with build-id: 
7ccef3390a7a41278e860f86aae9ef9bfa68d5a9
Found module libzstd.so.1 with 

Bug#997046: aravis: watch file: no udates gnome anymore

[Chiara Marmo]

It has be fixed in the last version available for upload.
Thanks again for the notification.

Chiara

On Fri, Oct 22, 2021 at 12:00 PM Ben Tris  wrote:
>
>> Source: aravis
>> Severity: important
>>
>> Dear Maintainer,
>>
>> It seems the gnome download location is not used anymore, probably has to
>> be
>> changed to GitHub.
>> https://github.com/AravisProject/aravis
>>
>>
>>
>> Maybe handy.
>> https://www.gezapig.nl/Free.html
>>
>>
>>
>> -- System Information:
>> Debian Release: 10.11
>>   APT prefers oldstable-updates
>>   APT policy: (500, 'oldstable-updates'), (500,
>> 'oldstable-proposed-updates'), (500, 'oldstable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
>> Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8),
>> LANGUAGE=nl_NL.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /usr/bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>>
>>

Bug#998722: cpufetch: Cannot detect CPU model, so it dies with a buffer overflow

[Axel Beckert]

Hi Gunnar,

Gunnar Wolf wrote:
> Axel Beckert dijo [Sat, Nov 13, 2021 at 04:17:07PM +0100]:
> > reform:~$ cpufetch
> > *** buffer overflow detected ***: terminated
> > Aborted (core dumped)
> > 
> > > Now, running cpufetch from the upstream repository (v1.00, commit
> > > a5b321a) does not die and correctly prints the architecture
> > > (screenshot attached),
> > 
> > Tagging as fixed-upstream then. :-)
> 
> Well, just thinking -- I am not sure it is fixed upstream (only that
> it no longer happens in my hardware). If the result of being unable to
> detect the CPU yields a core dump, I don't think it should be marked
> as fixed-upstream.

This is a misunderstanding. I thought that it was clear that my output
was from the 0.98-1 Debian package, not from an upstream git checkout.

An upstream git checkout works for me as well:

~/cpufetch → make
cc -Wall -Wextra -pedantic -DARCH_ARM -Wno-unused-parameter -std=c99 
-fstack-protector-all -O2 -Wfloat-equal -Wshadow -Wpointer-arith 
src/common/main.c src/common/cpu.c src/common/udev.c src/common/printer.c 
src/common/args.c src/common/global.c src/arm/midr.c src/arm/uarch.c 
src/arm/soc.c src/arm/udev.c -o cpufetch
make  6.38s user 0.62s system 98% cpu 7.098 total
~/cpufetch → ./cpufetch -s legacy 

 ##     ###     SoC:
 Unknown
  ####  Technology: 
 Unknown
  #      #  Microarchitecture:  
 Cortex-A53
   ##   Max Frequency:  
 1.500 GHz
        Cores:  
 4 cores
    #       Features:   
 NEON,SHA1,SHA2,AES,CRC32
  ###       Peak Performance:   
 24.00 GFLOP/s
            

~/cpufetch → cat .git/HEAD .git/refs/heads/master
ref: refs/heads/master
a5b321a9668f4763225e54ac71ab7ee2f86fc468

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#999620: pktanon: autopkgtest regression on armhf

[Sascha Steinbiss]

Hi Paul,

> With a recent upload of pktanon the autopkgtest of pktanon fails in
> testing on armhf when that autopkgtest is run with the binary packages
> of pktanon from unstable. 
[...]
> Currently this regression is blocking the migration to testing [1]. Can
> you please investigate the situation and fix it?

I am puzzled. The recent upload only changed the watchfile and updated
Standards-Version, compat level etc -- packaging things. Nothing touched
the code or build rules.

Also, I can't reproduce the bus error when running the offending command
from the autopkgtest on a version I built on a porterbox:

(sid_armhf-dchroot)satta@abel:~/pktanon-2~git20160407.0.2bde4f2+dfsg$
../usr/bin/pktanon -c
../usr/share/doc/pktanon/examples/profiles/profile.xml
profiles/sample.pcap ./out.pcap
---
pktanon --- profile-based traffic anonymization
---
initializing PktAnon,  configuration =
../usr/share/doc/pktanon/examples/profiles/profile.xml
unknown element: pktanon-config: 37
unknown element: anonymizations: 102
istream: opened file profiles/sample.pcap
ostream: opened output file ./out.pcap
initialized
complete

statistics for input file 'profiles/sample.pcap'
  processed packets: 9
  errors in packets: 0
  elapsed time:  639us
  Mpps:  0.0141

I must admit that being unfamiliar with these architectures and not
really having an idea of where to start, I am tempted to just remove
armhf from the list of supported architectures and have the version with
the broken autopkgtest removed from unstable. Do you probably know
someone who might be more knowledgeable with such architecture-specific
issues?

Cheers
Sascha

Bug#999656: O: nam -- Network Animator for network simulation

[Adrian Bunk]

Package: wnpp
Severity: normal

The current maintainer of nam has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o
for detailed instructions how to adopt a package properly.

More information about this package:

https://tracker.debian.org/pkg/nam


Package: nam
Binary: nam, nam-examples, nam-dbg
Version: 1.15-5.2
Maintainer: Debian Network Simulators Team 
Uploaders: YunQiang Su 
Build-Depends: debhelper (>= 8), quilt (>= 0.46-7~), cmake, tcl-dev (>= 8.6), 
tk-dev (>= 8.6), libxt-dev, libxmu-headers, zlib1g-dev, libotcl1-dev (>= 
1.14+dfsg), tclcl, libtclcl1-dev (>= 1.20-4)
Architecture: any all
Standards-Version: 3.9.8
Format: 3.0 (quilt)
Files:
 935c9fec3dedd1aa4868e3d99cd7f9ca 2115 nam_1.15-5.2.dsc
 1cf6646acc2f82e59965f5969f5a9239 4365554 nam_1.15.orig.tar.gz
 a4890224ab18a2181c99c3f6a17e54c2 9324 nam_1.15-5.2.debian.tar.xz
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-netsim/nam.git
Vcs-Git: git://anonscm.debian.org/pkg-netsim/nam.git
Checksums-Sha256:
 f7ead5ee5a054e3f4067d3b586cca1917739fbf998baff77d0a384512643872b 2115 
nam_1.15-5.2.dsc
 12ed547b3a5f8903890889d40cfea4d9bd66bb9ba6be99a0c753a9763cad8882 4365554 
nam_1.15.orig.tar.gz
 689fbbcc661f1f88b9b46d74dd95e370bcf6084099dff39d36c17a6909839b12 9324 
nam_1.15-5.2.debian.tar.xz
Homepage: http://www.isi.edu/nsnam/nam/
Package-List: 
 nam deb net optional arch=any
 nam-dbg deb debug extra arch=any
 nam-examples deb net optional arch=all
Directory: pool/main/n/nam
Priority: source
Section: net

Package: nam
Version: 1.15-5.2
Installed-Size: 696
Maintainer: Debian Network Simulators Team 
Architecture: amd64
Depends: libc6 (>= 2.29), libgcc-s1 (>= 3.0), libotcl1 (>= 1.14), libstdc++6 
(>= 5), libtcl8.6 (>= 8.6.0), libtclcl1 (>= 1.20), libtk8.6 (>= 8.6.0), libx11-6
Description-en: Network Animator for network simulation
 NAM is a Tcl/TK based animation tool for viewing network simulation
 traces and real world packet traces. It supports topology layout,
 packet level animation, and various data inspection tools. NAM began
 at LBL. It has evolved substantially over the past few years. The NAM
 development effort was an ongoing collaboration with the VINT project.
 Currently, it is being developed at ISI as part of the SAMAN and Conser
 projects.
Description-md5: 9a1e6309dade59cf7084cad84aee959e
Homepage: http://www.isi.edu/nsnam/nam/
Tag: implemented-in::c++, implemented-in::tcl, role::program,
 use::simulating, works-with::network-traffic
Section: net
Priority: optional
Filename: pool/main/n/nam/nam_1.15-5.2_amd64.deb
Size: 215572
MD5sum: 5944079459d57768264b0f9ddebf87f5
SHA256: b58e2efaf012a7694b22c9096d04594755f923b2b57099a974d9a1823eed11b3

Package: nam-examples
Source: nam
Version: 1.15-5.2
Installed-Size: 4208
Maintainer: Debian Network Simulators Team 
Architecture: all
Suggests: nam
Description-en: examples of nam
 NAM is a Tcl/TK based animation tool for viewing network simulation
 traces and real world packet traces. It supports topology layout,
 packet level animation, and various data inspection tools. NAM began
 at LBL. It has evolved substantially over the past few years. The NAM
 development effort was an ongoing collaboration with the VINT project.
 Currently, it is being developed at ISI as part of the SAMAN and Conser
 projects.
 .
 This package contains examples.
Description-md5: f64781f40ee43a20a309e38945239b4a
Homepage: http://www.isi.edu/nsnam/nam/
Section: net
Priority: optional
Filename: pool/main/n/nam/nam-examples_1.15-5.2_all.deb
Size: 3390624
MD5sum: b60dd8f4ed9dbb1e2ebe55810823dce3
SHA256: 2cd424b1bf02c73b4430d3fd632051703cd065a831a7fdcd4aaf65bd2022e3f0

Package: nam-dbg
Source: nam
Version: 1.15-5.2
Installed-Size: 2064
Maintainer: Debian Network Simulators Team 
Architecture: amd64
Depends: nam (= 1.15-5.2)
Description-en: debug symboles of nam
 NAM is a Tcl/TK based animation tool for viewing network simulation
 traces and real world packet traces. It supports topology layout,
 packet level animation, and various data inspection tools. NAM began
 at LBL. It has evolved substantially over the past few years. The NAM
 development effort was an ongoing collaboration with the VINT project.
 Currently, it is being developed at ISI as part of the SAMAN and Conser
 projects.
 .
 This package contains debug symboles of NAM.
Description-md5: 4f509c309ff9a2ad860b3ed619703b23
Homepage: http://www.isi.edu/nsnam/nam/
Tag: role::debug-symbols
Section: debug
Priority: optional
Filename: pool/main/n/nam/nam-dbg_1.15-5.2_amd64.deb
Size: 530388
MD5sum: 9e7115eea1423038e80fee00276a60fe
SHA256: 0a582f2915a548c8a48add3c552ff0376a566ee7b20fd0b2444dc559cbae55a8

Bug#999655: O: tclcl -- tcl2c++ and otcldoc program from tclcl

[Adrian Bunk]

Package: wnpp
Severity: normal

The current maintainer of tclcl has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o
for detailed instructions how to adopt a package properly.

More information about this package:

https://tracker.debian.org/pkg/tclcl


Package: tclcl
Binary: tclcl, libtclcl1, libtclcl1-dev, tclcl-dev, tclcl-dbg
Version: 1.20-9.1
Maintainer: Debian Network Simulators Team 
Uploaders: YunQiang Su 
Build-Depends: debhelper (>= 9), quilt (>= 0.46-7~), cmake, tcl-dev, tk-dev, 
libxext-dev, libotcl1-dev (>= 1.14+dfsg-2~), libxt-dev
Architecture: any all
Standards-Version: 3.9.5
Format: 3.0 (quilt)
Files:
 e9b14014d408baa9c338b3506bc2c8fe 2199 tclcl_1.20-9.1.dsc
 91d48d6694ae06cd29c627df6b78534a 171728 tclcl_1.20.orig.tar.gz
 a64a48bf91602320c6a1361bb6430818 9128 tclcl_1.20-9.1.debian.tar.xz
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-netsim/tclcl.git
Vcs-Git: git://anonscm.debian.org/pkg-netsim/tclcl.git
Checksums-Sha256:
 f7c02935788d16218cf33f91a97c02dd01435dc16adce7cb0637dd4a355b05bb 2199 
tclcl_1.20-9.1.dsc
 64fd1ec4b1d1c13229e58a7e10bf8422d804c5d3f00221117eafc2aff306dc78 171728 
tclcl_1.20.orig.tar.gz
 8c40c4650e92ec41b3b82596b461e459490852b975fc25b19026a1243bc8c67b 9128 
tclcl_1.20-9.1.debian.tar.xz
Homepage: http://otcl-tclcl.sourceforge.net/tclcl/
Package-List: 
 libtclcl1 deb libs optional arch=any
 libtclcl1-dev deb libdevel optional arch=any
 tclcl deb utils optional arch=any
 tclcl-dbg deb debug extra arch=any
 tclcl-dev deb libdevel optional arch=all
Directory: pool/main/t/tclcl
Priority: source
Section: utils

Package: tclcl
Version: 1.20-9.1
Installed-Size: 78
Maintainer: Debian Network Simulators Team 
Architecture: amd64
Depends: libc6 (>= 2.3.4)
Description-en: tcl2c++ and otcldoc program from tclcl
 TclCL (Tcl with classes) is a Tcl/C++ interface used by Mash, vic,
 vat, rtp_play and nsnam. It provides a layer of C++ glue over OTcl.
 .
 This package contains bin file.
Description-md5: 4b1d3fd5a93cd819450e346247c00241
Homepage: http://otcl-tclcl.sourceforge.net/tclcl/
Tag: role::program
Section: utils
Priority: optional
Filename: pool/main/t/tclcl/tclcl_1.20-9.1_amd64.deb
Size: 30464
MD5sum: ff32c42925e6b2653663fd1772635566
SHA256: 6ec8344be032515c1c697b1138810c71defa6de25921917f0cc5275fde7ec5db

Package: libtclcl1
Source: tclcl
Version: 1.20-9.1
Installed-Size: 307
Maintainer: Debian Network Simulators Team 
Architecture: amd64
Depends: libc6 (>= 2.4), libgcc-s1 (>= 3.0), libstdc++6 (>= 5), libtcl8.6 (>= 
8.6.0)
Description-en: shared library of TclCL
 TclCL (Tcl with classes) is a Tcl/C++ interface used by Mash, vic,
 vat, rtp_play, and nsnam. It provides a layer of C++ glue over OTcl.
 .
 This package contains shared library.
Description-md5: b335d3fb92a199511d469563b769aa0c
Multi-Arch: same
Homepage: http://otcl-tclcl.sourceforge.net/tclcl/
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/t/tclcl/libtclcl1_1.20-9.1_amd64.deb
Size: 77672
MD5sum: 1677fee9e122f517adb0a4c89d411a89
SHA256: 08cec641e73629effae68ac6d73d1a0f43d1da2b3b541d72c8fecb730efee31a

Package: libtclcl1-dev
Source: tclcl
Version: 1.20-9.1
Installed-Size: 407
Maintainer: Debian Network Simulators Team 
Architecture: amd64
Replaces: tclcl-dev (<< 1.20-1)
Provides: libtclcl-dev, tclcl-dev
Depends: libtclcl1 (= 1.20-9.1)
Breaks: tclcl-dev (<< 1.20-1)
Description-en: development files of TclCL
 TclCL (Tcl with classes) is a Tcl/C++ interface used by Mash, vic,
 vat, rtp_play, and nsnam. It provides a layer of C++ glue over OTcl.
 .
 This package contains static file and header files.
Description-md5: f6b8cc6175ccfa940dd42df08fa75d58
Homepage: http://otcl-tclcl.sourceforge.net/tclcl/
Tag: devel::library, role::devel-lib
Section: libdevel
Priority: optional
Filename: pool/main/t/tclcl/libtclcl1-dev_1.20-9.1_amd64.deb
Size: 84372
MD5sum: d68ec9266fd62a0c2f178c5d0a7e0556
SHA256: c9172f3f9c43367b7fca2609a2fa4668ebf067c6de8714b660cd7c790d350452

Package: tclcl-dev
Source: tclcl
Version: 1.20-9.1
Installed-Size: 30
Maintainer: Debian Network Simulators Team 
Architecture: all
Depends: libtclcl-dev
Description-en: transitional dummy package to libtclcl-dev
 This is a transitional dummy package.
 If nothing depends on it, this package can be safely removed.
Description-md5: bb0200f4813f2983e88a4607d2d7e595
Homepage: http://otcl-tclcl.sourceforge.net/tclcl/
Tag: devel::library, role::devel-lib
Section: libdevel
Priority: optional
Filename: pool/main/t/tclcl/tclcl-dev_1.20-9.1_all.deb
Size: 18276
MD5sum: 58491f35433255719d4fce3fe7d5d349
SHA256: d2e2314b1eaee6e81784a07a4c9d84d3d82e2716cba6c7701bf7a982ea878a24

Package: tclcl-dbg
Source: tclcl
Version: 1.20-9.1
Installed-Size: 132
Maintainer: Debian Network Simulators Team 
Architecture: amd64
Depends: tclcl (= 1.20-9.1), 

Bug#999654: O: otcl -- shared library of OTcl

[Adrian Bunk]

Package: wnpp
Severity: normal

The current maintainer of otcl has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o
for detailed instructions how to adopt a package properly.

More information about this package:

https://tracker.debian.org/pkg/otcl


Package: otcl
Binary: libotcl1, otcl-shells, libotcl1-dev
Version: 1.14+dfsg-4.1
Maintainer: Debian Network Simulators Team 
Uploaders: YunQiang Su 
Build-Depends: debhelper-compat (= 13), cmake, tcl-dev, tk-dev, libxext-dev, 
libxt-dev
Architecture: any
Standards-Version: 4.6.0
Format: 3.0 (quilt)
Files:
 171d899cb63098ff28dd25690234a212 2060 otcl_1.14+dfsg-4.1.dsc
 0b80f4ed32b35395cba048152eafcb7f 144978 otcl_1.14+dfsg.orig.tar.gz
 d1a21e8e9fc5bc1585eb9afcb8caa929 5444 otcl_1.14+dfsg-4.1.debian.tar.xz
Vcs-Browser: https://salsa.debian.org/debian/otcl
Vcs-Git: https://salsa.debian.org/debian/otcl.git
Checksums-Sha256:
 a3b25cb7937e218278b26df6bb023040b0e547773f2c9559b0a44337f659caf1 2060 
otcl_1.14+dfsg-4.1.dsc
 547aad26319e60248fff182a6b7d4dad4c0a2954998ac82ccbe41b71f7ec0e49 144978 
otcl_1.14+dfsg.orig.tar.gz
 4aadd1b603f510ff4f09bde7341a52f4d16a9565a25b3a7547f680a566e262eb 5444 
otcl_1.14+dfsg-4.1.debian.tar.xz
Homepage: http://otcl-tclcl.sourceforge.net/otcl/
Package-List: 
 libotcl1 deb libs optional arch=any
 libotcl1-dev deb libdevel optional arch=any
 otcl-shells deb utils optional arch=any
Directory: pool/main/o/otcl
Priority: source
Section: libs

Package: libotcl1
Source: otcl
Version: 1.14+dfsg-4.1
Installed-Size: 82
Maintainer: Debian Network Simulators Team 
Architecture: amd64
Depends: libc6 (>= 2.4), libtcl8.6 (>= 8.6.0)
Description-en: shared library of OTcl
 OTcl, short for MIT Object Tcl, is an extension to Tcl/Tk for
 object-oriented programming. It shouldn't be confused with the
 IXI Object Tcl extension by Dean Sheenan. (Sorry, but both of them
 like the name and have been using it for a while.)
 .
 Some of OTcl's features as compared to alternatives are:
   designed to be dynamically extensible, like Tcl, from the ground up
   builds on Tcl syntax and concepts rather than importing another language
   compact yet powerful object programming system
   fairly portable implementation (2000 lines of C, without core hacks)
 .
 OTcl was created by David Wetherall as part of the VUsystem project
 at MIT. Since 1997, OTcl has been maintained as part of the Mash and
 VINT/ns efforts (with David's blessing).
 .
 This package contains shared library file.
Description-md5: c3dd0d2212218425fcc3f9171bca36e4
Multi-Arch: same
Homepage: http://otcl-tclcl.sourceforge.net/otcl/
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/o/otcl/libotcl1_1.14+dfsg-4.1_amd64.deb
Size: 30568
MD5sum: 517a04264d634343662f4ae2a1679523
SHA256: 2e9659aa07769348cd8f0ea025dbeaba193d4869cd8491179967f1c6997001da

Package: libotcl1
Source: otcl (1.14+dfsg-4)
Version: 1.14+dfsg-4+b1
Installed-Size: 79
Maintainer: Debian Network Simulators Team 
Architecture: amd64
Depends: libc6 (>= 2.4), libtcl8.6 (>= 8.6.0)
Description-en: shared library of OTcl
 OTcl, short for MIT Object Tcl, is an extension to Tcl/Tk for
 object-oriented programming. It shouldn't be confused with the
 IXI Object Tcl extension by Dean Sheenan. (Sorry, but both of them
 like the name and have been using it for a while.)
 .
 Some of OTcl's features as compared to alternatives are:
   designed to be dynamically extensible, like Tcl, from the ground up
   builds on Tcl syntax and concepts rather than importing another language
   compact yet powerful object programming system
   fairly portable implementation (2000 lines of C, without core hacks)
 .
 OTcl was created by David Wetherall as part of the VUsystem project
 at MIT. Since 1997, OTcl has been maintained as part of the Mash and
 VINT/ns efforts (with David's blessing).
 .
 This package contains shared library file.
Description-md5: c3dd0d2212218425fcc3f9171bca36e4
Multi-Arch: same
Homepage: http://otcl-tclcl.sourceforge.net/otcl/
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/o/otcl/libotcl1_1.14+dfsg-4+b1_amd64.deb
Size: 29500
MD5sum: cac4dbed2c2c7ca18f6634fa6611e04b
SHA256: 376d5c1021c197de492b972ed48c259372772d90b96dd2cc6a92ff21622a08be

Package: otcl-shells
Source: otcl
Version: 1.14+dfsg-4.1
Installed-Size: 53
Maintainer: Debian Network Simulators Team 
Architecture: amd64
Depends: libc6 (>= 2.2.5), libotcl1 (>= 1.14), libtcl8.6 (>= 8.6.0), libtk8.6 
(>= 8.6.0)
Description-en: OTcl shells
 OTcl, short for MIT Object Tcl, is an extension to Tcl/Tk for
 object-oriented programming. It shouldn't be confused with the
 IXI Object Tcl extension by Dean Sheenan. (Sorry, but both of them
 like the name and have been using it for a while.)
 .
 Some of OTcl's features as compared to alternatives 

Bug#999653: O: ns2 -- Discrete event simulator targeted at networking research

[Adrian Bunk]

Package: wnpp
Severity: normal

The current maintainer of ns2 has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o
for detailed instructions how to adopt a package properly.

More information about this package:

https://tracker.debian.org/pkg/ns2


Package: ns2
Binary: ns2, ns2-dbg, ns2-doc, ns2-examples
Version: 2.35+dfsg-3.1
Maintainer: Debian Network Simulators Team 
Uploaders: YunQiang Su 
Build-Depends: debhelper (>= 10), cmake, tcl-dev, tk-dev, libxext-dev, 
libxt-dev, libpcap0.8-dev, libotcl1-dev, tclcl, libtclcl1-dev (>= 1.20-6~), 
perl (>= 5.003), libperl4-corelibs-perl
Architecture: any all
Standards-Version: 3.9.3
Format: 3.0 (quilt)
Files:
 63b63ca0a523c257c14f92537e43d5e1 2182 ns2_2.35+dfsg-3.1.dsc
 6906602b31d53cc00249796914d580e8 39407536 ns2_2.35+dfsg.orig.tar.xz
 590bb0abecf3b83649d66a9157bf9cf2 15832 ns2_2.35+dfsg-3.1.debian.tar.xz
Vcs-Browser: http://git.debian.org/?p=pkg-netsim/ns2.git
Vcs-Git: git://git.debian.org/git/pkg-netsim/ns2.git
Checksums-Sha256:
 331de8846fd5e19b538d99afe25749873e446e3f1562101ec041c7992afd1fd4 2182 
ns2_2.35+dfsg-3.1.dsc
 a3a097194c87fedbf2a7d3c8520790dc8688874cad0373af2db0ed33e463d52e 39407536 
ns2_2.35+dfsg.orig.tar.xz
 f491be0ecd7f6ff36ba986a385f684c1c567000d5adf10e65b712db183da1b8f 15832 
ns2_2.35+dfsg-3.1.debian.tar.xz
Homepage: http://www.isi.edu/nsnam/ns/
Package-List: 
 ns2 deb net optional arch=any
 ns2-dbg deb debug extra arch=any
 ns2-doc deb doc optional arch=all
 ns2-examples deb net optional arch=all
Directory: pool/main/n/ns2
Priority: source
Section: net

Package: ns2
Version: 2.35+dfsg-3.1
Installed-Size: 15200
Maintainer: Debian Network Simulators Team 
Architecture: amd64
Depends: libc6 (>= 2.29), libgcc-s1 (>= 3.0), libotcl1 (>= 1.14), libpcap0.8 
(>= 0.9.8), libstdc++6 (>= 5.2), libtcl8.6 (>= 8.6.0), libtclcl1 (>= 1.20), 
libtk8.6 (>= 8.6.0)
Suggests: gnuplot
Description-en: Discrete event simulator targeted at networking research
 Provides substantial support for simulation of TCP, routing,
 and multicast protocols over wired and wireless (local and satellite)
 networks.
 Ns-2 is written in C++ and an Object oriented version of Tcl called OTcl.
 .
 Ns began as a variant of the REAL network simulator in 1989 and has
 evolved substantially over the past few years. In 1995 ns development
 was supported by DARPA through the VINT project  at LBL, Xerox PARC,
 UCB, and USC/ISI. Currently ns development is support through DARPA
 with SAMAN  and through NSF with CONSER, both in collaboration with
 other researchers including ACIRI. Ns has always included substantal
 contributions from other researchers, including wireless code from the
 UCB Daedelus and CMU Monarch projects and Sun Microsystems.
Description-md5: 0ddfce2763a7238c29114e99a3b0b557
Homepage: http://www.isi.edu/nsnam/ns/
Tag: role::program, use::simulating, works-with::network-traffic
Section: net
Priority: optional
Filename: pool/main/n/ns2/ns2_2.35+dfsg-3.1_amd64.deb
Size: 2528028
MD5sum: b5066fd2153df93ea8192c90f92ed727
SHA256: f9fe4cf645eea0911b64ceb811293ad71f8e5341e690d66fe4373476a8c69b4f

Package: ns2-dbg
Source: ns2
Version: 2.35+dfsg-3.1
Installed-Size: 31178
Maintainer: Debian Network Simulators Team 
Architecture: amd64
Depends: ns2 (= 2.35+dfsg-3.1)
Description-en: debug symbols of ns2
 Provides substantial support for simulation of TCP, routing,
 and multicast protocols over wired and wireless (local and satellite)
 networks.
 Ns-2 is written in C++ and an Object oriented version of Tcl called OTcl.
 .
 Ns began as a variant of the REAL network simulator in 1989 and has
 evolved substantially over the past few years. In 1995 ns development
 was supported by DARPA through the VINT project  at LBL, Xerox PARC,
 UCB, and USC/ISI. Currently ns development is support through DARPA
 with SAMAN  and through NSF with CONSER, both in collaboration with
 other researchers including ACIRI. Ns has always included substantal
 contributions from other researchers, including wireless code from the
 UCB Daedelus and CMU Monarch projects and Sun Microsystems.
 .
 This package contains debug symbols which can be used by gdb.
Description-md5: f8ad21a12a8374dc757f1c05a0feab2d
Multi-Arch: same
Homepage: http://www.isi.edu/nsnam/ns/
Build-Ids: 0abaeb5fe90e19d4d7ace52a33a5ad4209c0dee9 
13e91acb332d6c5c026575ee27a24ef7a2fab89a 
403b4a23f6925e0b2125459a94bfb9dbf2ff9774 
4186567d967519798ab7086506534e4c782f0ba1 
775269d54bd9b41f50a62fc43f0da6c68f6723c4 
9a02a0870213301f38e87d244613e66df3008e36 
b118bf080b8795c318e49dc6f42869d4cff8079d 
d8bfc529d0d8ad28938e28a309b8d56b0bb78378 
f902b745b504c9b23fb6b2248f085af50532a703
Tag: role::debug-symbols
Section: debug
Priority: optional
Filename: pool/main/n/ns2/ns2-dbg_2.35+dfsg-3.1_amd64.deb
Size: 29066240
MD5sum: 

Bug#999652: units-filter: binary-all FTBFS

[Adrian Bunk]

Source: units-filter
Version: 4.2-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=units-filter=all=4.2-2=1636821858=0

...
dh_fixperms
# replace one directory by a symlink to sphinx
rm -rf debian/units-filter/usr/share/doc/units-filter/html/_static
ln -s ../../../sphinx/themes/basic/static \
  debian/units-filter/usr/share/doc/units-filter/html/_static
ln: failed to create symbolic link 
'debian/units-filter/usr/share/doc/units-filter/html/_static': No such file or 
directory
make[1]: *** [debian/rules:24: override_dh_fixperms] Error 1

Bug#999651: coq FTBFS on bytecode architectures

[Adrian Bunk]

Source: coq
Version: 8.14.0+dfsg-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=coq=sid

...
Error: Don't know how to build
_build/default/user-contrib/Ltac2/ltac2_plugin.cmxs
Hint: did you mean _build/default/user-contrib/Ltac2/ltac2_plugin.cma?
make[3]: *** [Makefile.common:190: 
_build/default/user-contrib/Ltac2/ltac2_plugin.cmxs] Error 1

Bug#942680: [Pkg-shadow-devel] Bug#942680: passwd: vipw does not resume properly when suspended

[Bálint Réczey]

Control: fixed -1 4.8-1
Control: forwarded -1 https://github.com/shadow-maint/shadow/issues/185
Control: upstream

Todd C. Miller  ezt írta (időpont: 2019. nov. 4.,
H, 19:15):
>
> On Sat, 26 Oct 2019 07:49:33 -0500, "Serge E. Hallyn" wrote:
>
> > second option sounds nicer but sure is a lot more code.  So I'm
> > leaning towards the first.  Do you  mind creating a github issue
> > at github.com/shadow-maint/shadow for this, or would you prefer that
> > I do it?
>
> I opened a github issue and attached the patches:
> https://github.com/shadow-maint/shadow/issues/185
>
>  - todd
>

Bug#999650: ruby-oily-png FTBFS on 32bit

[Adrian Bunk]

Source: ruby-oily-png
Version: 1.2.1~dfsg-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=ruby-oily-png

...
Failures:

  1) OilyPNG::Color#compose_quick should use the background color as is when a 
fully transparent pixel is given as foreground color
 Failure/Error: expect(compose_quick(@fully_transparent, @white)).to 
be(@white)

   expected # => 4294967295
got # => 4294967295

   Compared using equal?, which compares object identity,
   but expected and actual are not the same object. Use
   `expect(actual).to eq(expected)` if you don't care about
   object identity in this example.
 # ./spec/color_spec.rb:24:in `block (3 levels) in '

  2) OilyPNG::Color#compose_quick should compose pixels correctly
 Failure/Error: expect(compose_quick(@non_opaque, @white)).to be(0x9fc2d6ff)

   expected # => 2680346367
got # => 2680346367

   Compared using equal?, which compares object identity,
   but expected and actual are not the same object. Use
   `expect(actual).to eq(expected)` if you don't care about
   object identity in this example.
 # ./spec/color_spec.rb:28:in `block (3 levels) in '

  3) OilyPNG::Color#compose_quick should compose colors exactly the same as 
ChunkyPNG
 Failure/Error: expect(compose_quick(fg, bg)).to 
be(ChunkyPNG::Color.compose_quick(fg, bg))

   expected # => 2126858483
got # => 2126858483

   Compared using equal?, which compares object identity,
   but expected and actual are not the same object. Use
   `expect(actual).to eq(expected)` if you don't care about
   object identity in this example.
 # ./spec/color_spec.rb:33:in `block (3 levels) in '

Finished in 0.36245 seconds (files took 0.22531 seconds to load)
146 examples, 3 failures, 18 pending

Failed examples:

rspec ./spec/color_spec.rb:23 # OilyPNG::Color#compose_quick should use the 
background color as is when a fully transparent pixel is given as foreground 
color
rspec ./spec/color_spec.rb:27 # OilyPNG::Color#compose_quick should compose 
pixels correctly
rspec ./spec/color_spec.rb:31 # OilyPNG::Color#compose_quick should compose 
colors exactly the same as ChunkyPNG

/usr/bin/ruby2.7 
-I/usr/share/rubygems-integration/all/gems/rspec-support-3.9.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib
 /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/exe/rspec --pattern 
./spec/\*\*/\*_spec.rb --format documentation failed
ERROR: Test "ruby2.7" failed. Exiting.
dh_auto_install: error: dh_ruby --install 
/<>/ruby-oily-png-1.2.1\~dfsg/debian/ruby-oily-png returned exit code 
1
make: *** [debian/rules:8: binary-arch] Error 25