Bug#201448: StepMania4 reached Alpha

[Andres Salomon]

On Thu, 9 Apr 2009 14:11:49 -0400 Danny Piccirillo wrote:
> StepMania 4 has now reached alpha (and actually is now at alpha 3 
after only

> a few days). It has a new theme and is very stable!


I'm not interested in maintaining this, but I did have to build it 
because the last release is from 2016 and the released binary doesn't 
run on debian bullseye. In case someone does want to package it, maybe 
this will help them. I initially tried building against the system 
ffmpeg, but the build failed so I ended up just disabling ffmpeg support.



Here's what I did to build stepmania 5.1.0-beta2, after unpacking the 
source:



apt-get install cmake libgtk2.0-dev libjpeg-dev libmad0-dev 
libvorbis-dev nasm libudev-dev libbz2-dev libva-dev libglew-dev 
libpulse-dev libjack-dev  libasound2-dev


# note: this following step probably isn't necessary when ffmpeg is 
disabled. To enable it, you'd do cmake -D WITH_SYSTEM_FFMPEG=ON


apt-get install libavcodec-dev libavformat-dev libswscale-dev

cd Build

cmake -D WITH_FFMPEG=OFF ..

make

make install

Bug#1007842: Bug#909124: quilt: Please fail gracefully on 'quilt series' when less(1) is not installed

[Trent W. Buck]

Daniel Shahaf wrote:
> > FAILS:  env PAGER=cat quilt series
> > WORKS:  env -u LESS PAGER=cat quilt series
> > 
> > 
> > This is actually a separate but related bug in quilt.
> > If $LESS is set, quilt ignores $PAGER and forces less.
> > This is wrong.
> ⋮
> > 18:38  [ -n "$LESS" -a -z "${QUILT_PAGER+x}" ] && 
> > QUILT_PAGER="less -FRX"
> 
> Agreed.  If Alice normally uses «export PAGER=less LESS=S» and then sets
> PAGER=foo, that's the pager quilt shoult use.
> 
> Cloned as -2.  The above patch does _not_ fix it.
> 
> > If quilt wants to override the user's requested $LESS,
> > it should do so with "export LESS=FRX",
> > entirely independent of $QUILT_PAGER'.
> 
> This particular approach would be lossy: it would overwrite the user's
> value of $LESS.  Instead, quilt could _append_ to $LESS, or pass -R into
> less(1)'s argv, or only use $LESS as a hint if PAGER and GIT_PAGER are
> also unset and less(1) is installed, or document that the user should
> configure their $PAGER / $LESS / $QUILT_PAGER envvars with -R, or…

OK that sounds reasonable.
The part I care about is "don't force PAGER=less when LESS=x".
I don't really care about the EXACT way that is achieved.

All else being equal, I think quilt should mimic git's equivalent logic.
I guess that's here:


https://sources.debian.org/src/git/1:2.35.1-1/Documentation/config/core.txt/?hl=508#L496-L519

Bug#1008240: Inside mmdebstrap hooks, find /dev/ -type f matches irregular files

[Trent W. Buck]

Package: mmdebstrap
Version: 0.7.5-2.2
Severity: minor

I see a quite odd behaviour where "find ... -type f" inside a customize hook is 
matching device files.
As a simple test, "find /dev -type f" finds /dev/zero inside mmdebstrap, but 
not outside mmdebstrap.

The problem doesn't appear to be affecting stat, test, or python -- only find.
I haven't tested with bwrap or unshare(1) instead of mmdebstrap – I'm not sure 
exactly how.
If find fails for those, clearly this bug should be reassigned to findutils.

I speculate this is some interaction between unshare(2) and stat(2) that may be 
a bug in find.
I looked at the strace, but I can't see anything obvious.

Here is some basic investigation outside mmdebstrap:

bash5$ find /dev/ -type f
[no matches]

bash5$ strace -e trace=file find /dev/zero -type f -print -quit
execve("/usr/bin/find", ["find", "/dev/zero", "-type", "f", "-print", 
"-quit"], 0x7ffc1e9c8578 /* 72 vars */) = 0
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or 
directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libselinux.so.1", 
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpcre2-8.so.0", 
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0", 
O_RDONLY|O_CLOEXEC) = 3
statfs("/sys/fs/selinux", 0x7ffd464f5210) = -1 ENOENT (No such file or 
directory)
statfs("/selinux", 0x7ffd464f5210)  = -1 ENOENT (No such file or 
directory)
openat(AT_FDCWD, "/proc/filesystems", O_RDONLY|O_CLOEXEC) = 3
access("/etc/selinux/config", F_OK) = -1 ENOENT (No such file or 
directory)
openat(AT_FDCWD, ".", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/usr/share/locale/en_AU.UTF-8/LC_MESSAGES/findutils.mo", 
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_AU.utf8/LC_MESSAGES/findutils.mo", 
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_AU/LC_MESSAGES/findutils.mo", 
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.UTF-8/LC_MESSAGES/findutils.mo", 
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.utf8/LC_MESSAGES/findutils.mo", 
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/findutils.mo", O_RDONLY) 
= -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/dev/zero", {st_mode=S_IFCHR|0666, 
st_rdev=makedev(0x1, 0x5), ...}, AT_SYMLINK_NOFOLLOW) = 0
+++ exited with 0 +++

Here is some basic investigation inside mmdebstrap:

bash5$ mmdebstrap bullseye /dev/null --customize-hook='chroot $1 bash; 
false' --include=strace,findutils
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: tar
I: using /tmp/mmdebstrap.PqOlBcBbIw as tempdir
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing essential packages...
done
I: downloading apt...
done
I: installing apt...
done
I: installing remaining packages inside the chroot...
done
done
I: running --customize-hook in shell: sh -c 'chroot $1 bash; false' exec 
/tmp/mmdebstrap.PqOlBcBbIw

root@hera:/# find /dev/ -type f
/dev/zero
/dev/urandom
/dev/tty
/dev/random
/dev/ptmx
/dev/null
/dev/full
/dev/console

root@hera:/# strace -e trace=file find /dev/zero -type f -print -quit
execve("/usr/bin/find", ["find", "/dev/zero", "-type", "f", "-print", 
"-quit"], 0x7fff5a33ba68 /* 79 vars */) = 0
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or 
directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libselinux.so.1", 
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libpcre2-8.so.0", 
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0", 
O_RDONLY|O_CLOEXEC) = 3
statfs("/sys/fs/selinux", 0x7ffe4aac8df0) = -1 ENOENT (No such file or 
directory)
statfs("/selinux", 0x7ffe4aac8df0)  = -1 ENOENT (No such 

Bug#1008239: Acknowledgement (libvirt-daemon: wrong MTU on bridge interface created by libvirt)

[Maxim Orlov]

Looks like this is libvirt bug, because same behavior on fedora 34 with libvirt 
7.0.0-8, but works correct on fedora 35 with 7.6.0-5

Fedora 34:
[root@fedora ~]# ip link
5: test:  mtu 1500 qdisc noqueue state DOWN 
mode DEFAULT group default qlen 1000
 link/ether 52:54:00:45:0b:ac brd ff:ff:ff:ff:ff:ff

Fedora 35:
[root@f35 ~]# ip link
5: test:  mtu 9000 qdisc noqueue state DOWN 
mode DEFAULT group default qlen 1000
 link/ether 52:54:00:c8:0e:c0 brd ff:ff:ff:ff:ff:ff

Bug#1008239: libvirt-daemon: wrong MTU on bridge interface created by libvirt

[maxim orlov]

Package: libvirt-daemon-system
Version: 7.0.0-3
Severity: normal
X-Debbugs-Cc: maxx.or...@gmail.com

After creating virtual network from next XML file:
$ cat test.xml

  test
  
  


$ virsh net-dumpxml test

  test
  6db03fea-1275-4036-aa0c-fa12428631a8
  
  
  


bridge interface ignore mtu settings 9000 and use default 1500

$ ip link
26: test:  mtu 1500 qdisc noqueue state DOWN 
mode DEFAULT group default qlen 1000
link/ether 52:54:00:34:2d:b1 brd ff:ff:ff:ff:ff:ff
  

Bug doesn't exist in libvirt 5.0.0-4+deb10u1 (debian 10):
4: test:  mtu 9000 qdisc noqueue state DOWN 
mode DEFAULT group default qlen 1000
link/ether 52:54:00:23:cf:42 brd ff:ff:ff:ff:ff:ff
5: test-nic:  mtu 9000 qdisc pfifo_fast master test state 
DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:23:cf:42 brd ff:ff:ff:ff:ff:ff

in libvirt 6.0.0-0ubuntu8.15 (ubuntu 20.04):
6: test:  mtu 9000 qdisc noqueue state DOWN 
mode DEFAULT group default qlen 1000
link/ether 52:54:00:97:39:0d brd ff:ff:ff:ff:ff:ff
7: test-nic:  mtu 9000 qdisc fq_codel master test state 
DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:97:39:0d brd ff:ff:ff:ff:ff:ff

and in libvirt 8.0.0-1~bpo11+1 (bullseye-backports/main) 
5: test:  mtu 9000 qdisc noqueue state DOWN 
mode DEFAULT group default qlen 1000
link/ether 52:54:00:3f:42:ee brd ff:ff:ff:ff:ff:ff



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

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvirt-daemon-system depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.77
ii  gettext-base0.21-4
ii  iptables1.8.7-1
ii  libvirt-clients 7.0.0-3
ii  libvirt-daemon  7.0.0-3
ii  libvirt-daemon-config-network   7.0.0-3
ii  libvirt-daemon-config-nwfilter  7.0.0-3
ii  libvirt-daemon-system-systemd   7.0.0-3
ii  logrotate   3.18.0-2
ii  policykit-1 0.105-31+deb11u1

Versions of packages libvirt-daemon-system recommends:
ii  dmidecode3.3-2
ii  dnsmasq-base [dnsmasq-base]  2.85-1
ii  iproute2 5.10.0-4
ii  mdevctl  0.81-1
ii  parted   3.4-1

Versions of packages libvirt-daemon-system suggests:
ii  apparmor2.13.6-10
pn  auditd  
ii  nfs-common  1:1.3.4-6
pn  open-iscsi  
pn  pm-utils
pn  radvd   
ii  systemd 247.3-6
pn  systemtap   
pn  zfsutils

-- Configuration Files:
/etc/libvirt/qemu.conf [Errno 13] Permission denied: '/etc/libvirt/qemu.conf'

-- debconf information excluded

Bug#994245: nodejs: improve bootstraping nodejs

[Bo YU]

On Fri, Mar 25, 2022 at 7:55 AM Jérémy Lal  wrote:

>
>
> On Fri, Mar 25, 2022 at 12:23 AM Jérémy Lal  wrote:
>
>>
>>
>> On Fri, Mar 25, 2022 at 12:17 AM Bo YU  wrote:
>>
>>>
>>>
>>> On Fri, Mar 25, 2022 at 7:11 AM Bo YU  wrote:
>>>
 On Thu, Mar 24, 2022 at 01:11:40AM +0100, Jérémy Lal wrote:
 >   On Thu, Mar 24, 2022 at 1:05 AM Jérémy Lal <[1]kapo...@melix.org>
 >   wrote:
 >
 >   --build=any
 ...
 >
 > Hi,
 > After several times build fails about (on riscv hardware):
 >  collect2: fatal error: ld terminated with signal 9 [Killed]
 > compilation terminated.
 >
 >   Linking nodejs happens to use a lot of memory: make sure enough swap
 >   space is available.
 >   (I had similar crashes with 12GB of RAM and no swap).
 >   Or the linker is broken on riscv64... let's hope it is not.
 >   If you happen to reach the "building deb" stage, you can disable
 >   -dbgsym package creation,
 >   which is very long, with another build profile: noautodbgsym.
 >   DEB_BUILD_PROFILES="nodoc nocheck noautodbgsym pkg.nodejs.nobuiltin"
 >   Jérémy
 Today I checkout master-16.x, and I got:

>>> sorry, add more useful info:
>>> cc -o
>>> /home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/api.o
>>> ../deps/llhttp/src/api.c '-DV8_DEPRECATION_WARNINGS'
>>> '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D_GLIBCXX_USE_CXX11_ABI=1'
>>> '-DNODE_OPENSSL_CERT_STORE' '-D__STDC_FORMAT_MACROS' -I../deps/llhttp
>>> -I../deps/llhttp/include  -pthread -Wall -Wextra -Wno-unused-parameter
>>> -fPIC -O3 -fno-omit-frame-pointer  -MMD -MF
>>> /home/vimer/git/nodejs/out/Release/.deps//home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/api.o.d.raw
>>> -fPIC -g -fPIC -g -fPIC -g -fPIC -g -c
>>> make[3]: *** No rule to make target '../deps/acorn/acorn/dist/acorn.js',
>>> needed by '/home/vimer/git/nodejs/out/Release/obj/gen/node_javascript.cc'.
>>> Stop.
>>>
>>
>> Maybe some symlink is missing, am checking it but it will take a while to
>> rebuild.
>>
>
> I pushed a fix for a mistake in debian/rules that happened while renaming
> "nobuiltin".
>
> It works on riscv also. At last it is building now :-)
Thank you!
Bo

> Jérémy
>
>>

Bug#994388: dpkg currently warning about merged-usr systems

[Sean Whitton]

Hello,

On Thu 24 Mar 2022 at 04:50PM -07, Russ Allbery wrote:

> Josh Triplett  writes:
>
>> I think it's appropriate for people to wait on such work until there's
>> guidance from the TC ensuring that such a patch will be accepted.
>> Otherwise, anyone spending time writing it is spending substantial
>> effort that may well be wasted.
>
> I think this is a totally fair thing to be concerned about.  Should such a
> patch exist -- with the obvious condition that I think it's quite
> reasonable to do several rounds of iteration on making that patch solid,
> ensuring there are tests, and so forth -- I think it's obvious that we
> should merge it given the previous TC decision.  Of course, I'm not a TC
> member.
>
> It's difficult, procedurally, for the TC to do anything about a
> theoretical patch that someone could write but hasn't written.
> Particularly for dpkg, the details are important.  I can think of some
> ways of supporting merged-/usr that I wouldn't support even while
> supporting the TC decision.  We have various goals (such as being able to
> bootstrap entirely through package installation) that can be met while
> supporting merged-/usr but which do require design and care.
>
> If a concrete patch exists, the TC can (and has in the past) authorize an
> NMU to apply it.  Obviously, we should try to avoid reaching that level of
> social and process confrontation if we can avoid it, but this is clearly
> within the TC's constitutional power via a maintainer override, which puts
> the discussion on somewhat firmer ground.  But design of that patch is
> *not* within the TC's constitutional mandate.
>
> It may be useful to look at how multiarch support in dpkg was handled.
> That was quite painful and I really hope we don't end up following that
> path exactly, but it provides a concrete example of how Debian's processes
> can reach a resolution.
>
> I personally am still hopeful that we could do much better than the
> multiarch outcome and find a patch that meets the architectural criteria
> of the dpkg maintainer, but I'm fairly certain that we're not going to
> make any progress towards that goal without having working code, or at
> least a very detailed architecture, to start discussing and analyzing.

This is how I see it as well.  Putting aside the postinst warning, the I
can't see anything the TC could do beyond what we've already done, until
there's a patch on the table.  Thanks for the summary.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#994245: nodejs: improve bootstraping nodejs

[Jérémy Lal]

On Fri, Mar 25, 2022 at 12:55 AM Jérémy Lal  wrote:

>
>
> On Fri, Mar 25, 2022 at 12:23 AM Jérémy Lal  wrote:
>
>>
>>
>> On Fri, Mar 25, 2022 at 12:17 AM Bo YU  wrote:
>>
>>>
>>>
>>> On Fri, Mar 25, 2022 at 7:11 AM Bo YU  wrote:
>>>
 On Thu, Mar 24, 2022 at 01:11:40AM +0100, Jérémy Lal wrote:
 >   On Thu, Mar 24, 2022 at 1:05 AM Jérémy Lal <[1]kapo...@melix.org>
 >   wrote:
 >
 >   --build=any
 ...
 >
 > Hi,
 > After several times build fails about (on riscv hardware):
 >  collect2: fatal error: ld terminated with signal 9 [Killed]
 > compilation terminated.
 >
 >   Linking nodejs happens to use a lot of memory: make sure enough swap
 >   space is available.
 >   (I had similar crashes with 12GB of RAM and no swap).
 >   Or the linker is broken on riscv64... let's hope it is not.
 >   If you happen to reach the "building deb" stage, you can disable
 >   -dbgsym package creation,
 >   which is very long, with another build profile: noautodbgsym.
 >   DEB_BUILD_PROFILES="nodoc nocheck noautodbgsym pkg.nodejs.nobuiltin"
 >   Jérémy
 Today I checkout master-16.x, and I got:

>>> sorry, add more useful info:
>>> cc -o
>>> /home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/api.o
>>> ../deps/llhttp/src/api.c '-DV8_DEPRECATION_WARNINGS'
>>> '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D_GLIBCXX_USE_CXX11_ABI=1'
>>> '-DNODE_OPENSSL_CERT_STORE' '-D__STDC_FORMAT_MACROS' -I../deps/llhttp
>>> -I../deps/llhttp/include  -pthread -Wall -Wextra -Wno-unused-parameter
>>> -fPIC -O3 -fno-omit-frame-pointer  -MMD -MF
>>> /home/vimer/git/nodejs/out/Release/.deps//home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/api.o.d.raw
>>> -fPIC -g -fPIC -g -fPIC -g -fPIC -g -c
>>> make[3]: *** No rule to make target '../deps/acorn/acorn/dist/acorn.js',
>>> needed by '/home/vimer/git/nodejs/out/Release/obj/gen/node_javascript.cc'.
>>> Stop.
>>>
>>
>> Maybe some symlink is missing, am checking it but it will take a while to
>> rebuild.
>>
>
> I pushed a fix for a mistake in debian/rules that happened while renaming
> "nobuiltin".
>

At least it builds and produces deb packages here on amd64 without
depending on nodejs itself.

Jérémy

>

Bug#994245: nodejs: improve bootstraping nodejs

[Jérémy Lal]

On Fri, Mar 25, 2022 at 12:23 AM Jérémy Lal  wrote:

>
>
> On Fri, Mar 25, 2022 at 12:17 AM Bo YU  wrote:
>
>>
>>
>> On Fri, Mar 25, 2022 at 7:11 AM Bo YU  wrote:
>>
>>> On Thu, Mar 24, 2022 at 01:11:40AM +0100, Jérémy Lal wrote:
>>> >   On Thu, Mar 24, 2022 at 1:05 AM Jérémy Lal <[1]kapo...@melix.org>
>>> >   wrote:
>>> >
>>> >   --build=any
>>> ...
>>> >
>>> > Hi,
>>> > After several times build fails about (on riscv hardware):
>>> >  collect2: fatal error: ld terminated with signal 9 [Killed]
>>> > compilation terminated.
>>> >
>>> >   Linking nodejs happens to use a lot of memory: make sure enough swap
>>> >   space is available.
>>> >   (I had similar crashes with 12GB of RAM and no swap).
>>> >   Or the linker is broken on riscv64... let's hope it is not.
>>> >   If you happen to reach the "building deb" stage, you can disable
>>> >   -dbgsym package creation,
>>> >   which is very long, with another build profile: noautodbgsym.
>>> >   DEB_BUILD_PROFILES="nodoc nocheck noautodbgsym pkg.nodejs.nobuiltin"
>>> >   Jérémy
>>> Today I checkout master-16.x, and I got:
>>>
>> sorry, add more useful info:
>> cc -o
>> /home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/api.o
>> ../deps/llhttp/src/api.c '-DV8_DEPRECATION_WARNINGS'
>> '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D_GLIBCXX_USE_CXX11_ABI=1'
>> '-DNODE_OPENSSL_CERT_STORE' '-D__STDC_FORMAT_MACROS' -I../deps/llhttp
>> -I../deps/llhttp/include  -pthread -Wall -Wextra -Wno-unused-parameter
>> -fPIC -O3 -fno-omit-frame-pointer  -MMD -MF
>> /home/vimer/git/nodejs/out/Release/.deps//home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/api.o.d.raw
>> -fPIC -g -fPIC -g -fPIC -g -fPIC -g -c
>> make[3]: *** No rule to make target '../deps/acorn/acorn/dist/acorn.js',
>> needed by '/home/vimer/git/nodejs/out/Release/obj/gen/node_javascript.cc'.
>> Stop.
>>
>
> Maybe some symlink is missing, am checking it but it will take a while to
> rebuild.
>

I pushed a fix for a mistake in debian/rules that happened while renaming
"nobuiltin".

Jérémy

>

Bug#994388: dpkg currently warning about merged-usr systems

[Russ Allbery]

Josh Triplett  writes:

> I think it's appropriate for people to wait on such work until there's
> guidance from the TC ensuring that such a patch will be accepted.
> Otherwise, anyone spending time writing it is spending substantial
> effort that may well be wasted.

I think this is a totally fair thing to be concerned about.  Should such a
patch exist -- with the obvious condition that I think it's quite
reasonable to do several rounds of iteration on making that patch solid,
ensuring there are tests, and so forth -- I think it's obvious that we
should merge it given the previous TC decision.  Of course, I'm not a TC
member.

It's difficult, procedurally, for the TC to do anything about a
theoretical patch that someone could write but hasn't written.
Particularly for dpkg, the details are important.  I can think of some
ways of supporting merged-/usr that I wouldn't support even while
supporting the TC decision.  We have various goals (such as being able to
bootstrap entirely through package installation) that can be met while
supporting merged-/usr but which do require design and care.

If a concrete patch exists, the TC can (and has in the past) authorize an
NMU to apply it.  Obviously, we should try to avoid reaching that level of
social and process confrontation if we can avoid it, but this is clearly
within the TC's constitutional power via a maintainer override, which puts
the discussion on somewhat firmer ground.  But design of that patch is
*not* within the TC's constitutional mandate.

It may be useful to look at how multiarch support in dpkg was handled.
That was quite painful and I really hope we don't end up following that
path exactly, but it provides a concrete example of how Debian's processes
can reach a resolution.

I personally am still hopeful that we could do much better than the
multiarch outcome and find a patch that meets the architectural criteria
of the dpkg maintainer, but I'm fairly certain that we're not going to
make any progress towards that goal without having working code, or at
least a very detailed architecture, to start discussing and analyzing.

-- 
Russ Allbery (r...@debian.org)  

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, 24 Mar 2022 16:22:38 -0700 Russ Allbery  wrote:
> Luca Boccassi  writes:
> 
> > If it was possible to do it, it would have already happened, and we
> > wouldn't be discussing it at all, it would have just been done.
> 
> Has someone written a patch against dpkg that causes it to do the right
> thing?
> 
> > In the end, at the very least this is a _workable_ proposal. It might
> > not be ideal, but we know it can work. What's your counter-proposal?
> 
> Someone who believes strongly in merged-/usr should write a patch against
> dpkg that causes it to work properly with merged-/usr, including edge
> cases like files moving out of /bin and /lib between packages and dpkg -S
> working properly.
> 
> I understand that you don't think that patch will be accepted.  But we
> don't actually know that since so far as I know it doesn't exist.  We're
> arguing in the abstract about a future problem that hasn't happened yet
> because we don't have working code to argue about.

I think it's appropriate for people to wait on such work until there's
guidance from the TC ensuring that such a patch will be accepted.
Otherwise, anyone spending time writing it is spending substantial
effort that may well be wasted.

I am also hoping that such a patch is not a precondition for removing
the message from the current dpkg maintainer script, which is already
causing issues.

Bug#994388: dpkg currently warning about merged-usr systems

[Russ Allbery]

Luca Boccassi  writes:

> If it was possible to do it, it would have already happened, and we
> wouldn't be discussing it at all, it would have just been done.

Has someone written a patch against dpkg that causes it to do the right
thing?

> In the end, at the very least this is a _workable_ proposal. It might
> not be ideal, but we know it can work. What's your counter-proposal?

Someone who believes strongly in merged-/usr should write a patch against
dpkg that causes it to work properly with merged-/usr, including edge
cases like files moving out of /bin and /lib between packages and dpkg -S
working properly.

I understand that you don't think that patch will be accepted.  But we
don't actually know that since so far as I know it doesn't exist.  We're
arguing in the abstract about a future problem that hasn't happened yet
because we don't have working code to argue about.

> Sitting back and just saying "someone better get a fix into dpkg",
> without neither doing it nor explaining _how_ that could ever be
> possible is not a workable proposal, it's just doing nothing while
> letting the clock run.

I do not have the resources (time and energy) to write the patch for dpkg
myself, indeed.  However, I also have not been advocating moving to
merged-/usr.  This feels like part of that work to me.

I have been doing some work short of writing the patch, such as laying out
what I think the missing pieces are and trying to propose an
implementation design that could get some consensus, and flush out the
remaining problems.  (To be clear, others have been doing more of that
than I have, but I think it's a bit inaccurate to say that I've only been
complaining and not trying to help arrive at a proper fix.)

-- 
Russ Allbery (r...@debian.org)  

Bug#994245: nodejs: improve bootstraping nodejs

[Jérémy Lal]

On Fri, Mar 25, 2022 at 12:17 AM Bo YU  wrote:

>
>
> On Fri, Mar 25, 2022 at 7:11 AM Bo YU  wrote:
>
>> On Thu, Mar 24, 2022 at 01:11:40AM +0100, Jérémy Lal wrote:
>> >   On Thu, Mar 24, 2022 at 1:05 AM Jérémy Lal <[1]kapo...@melix.org>
>> >   wrote:
>> >
>> >   --build=any
>> ...
>> >
>> > Hi,
>> > After several times build fails about (on riscv hardware):
>> >  collect2: fatal error: ld terminated with signal 9 [Killed]
>> > compilation terminated.
>> >
>> >   Linking nodejs happens to use a lot of memory: make sure enough swap
>> >   space is available.
>> >   (I had similar crashes with 12GB of RAM and no swap).
>> >   Or the linker is broken on riscv64... let's hope it is not.
>> >   If you happen to reach the "building deb" stage, you can disable
>> >   -dbgsym package creation,
>> >   which is very long, with another build profile: noautodbgsym.
>> >   DEB_BUILD_PROFILES="nodoc nocheck noautodbgsym pkg.nodejs.nobuiltin"
>> >   Jérémy
>> Today I checkout master-16.x, and I got:
>>
> sorry, add more useful info:
> cc -o
> /home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/api.o
> ../deps/llhttp/src/api.c '-DV8_DEPRECATION_WARNINGS'
> '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D_GLIBCXX_USE_CXX11_ABI=1'
> '-DNODE_OPENSSL_CERT_STORE' '-D__STDC_FORMAT_MACROS' -I../deps/llhttp
> -I../deps/llhttp/include  -pthread -Wall -Wextra -Wno-unused-parameter
> -fPIC -O3 -fno-omit-frame-pointer  -MMD -MF
> /home/vimer/git/nodejs/out/Release/.deps//home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/api.o.d.raw
> -fPIC -g -fPIC -g -fPIC -g -fPIC -g -c
> make[3]: *** No rule to make target '../deps/acorn/acorn/dist/acorn.js',
> needed by '/home/vimer/git/nodejs/out/Release/obj/gen/node_javascript.cc'.
> Stop.
>

Maybe some symlink is missing, am checking it but it will take a while to
rebuild.

Bug#994245: nodejs: improve bootstraping nodejs

[Jérémy Lal]

On Fri, Mar 25, 2022 at 12:11 AM Bo YU  wrote:

> On Thu, Mar 24, 2022 at 01:11:40AM +0100, Jérémy Lal wrote:
> >   On Thu, Mar 24, 2022 at 1:05 AM Jérémy Lal <[1]kapo...@melix.org>
> >   wrote:
> >
> >   --build=any
> ...
> >
> > Hi,
> > After several times build fails about (on riscv hardware):
> >  collect2: fatal error: ld terminated with signal 9 [Killed]
> > compilation terminated.
> >
> >   Linking nodejs happens to use a lot of memory: make sure enough swap
> >   space is available.
> >   (I had similar crashes with 12GB of RAM and no swap).
> >   Or the linker is broken on riscv64... let's hope it is not.
> >   If you happen to reach the "building deb" stage, you can disable
> >   -dbgsym package creation,
> >   which is very long, with another build profile: noautodbgsym.
> >   DEB_BUILD_PROFILES="nodoc nocheck noautodbgsym pkg.nodejs.nobuiltin"
> >   Jérémy
> Today I checkout master-16.x, and I got:
>
>cc -o
> /home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/http.o
> ../deps/llhttp/src/http.c '-DV8_DEPRECATION_WARNINGS'
> '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D_GLIBCXX_USE_CXX11_ABI=1'
> '-DNODE_OPENSSL_CERT_STORE' '-D__STDC_FORMAT_MACROS' -I../deps/llhttp
> -I../deps/llhttp/include  -pthread -Wall -Wextra -Wno-unused-parameter
> -fPIC -O3 -fno-omit-frame-pointer  -MMD -MF
> /home/vimer/git/nodejs/out/Release/.deps//home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/http.o.d.raw
> -fPIC -g -fPIC -g -fPIC -g -fPIC -g -c
>rm 0adbed5b583340328e51a4f1b8ecdc8673323efe.intermediate
>make[2]: *** [Makefile:113: node] Error 2
>make[2]: Leaving directory '/home/vimer/git/nodejs'
>dh_auto_build: error: make -j16 returned exit code 2
>make[1]: *** [debian/rules:245: override_dh_auto_build-arch] Error 2
>make[1]: Leaving directory '/home/vimer/git/nodejs'
>make: *** [debian/rules:186: binary-arch] Error 2
>dpkg-buildpackage: error: debian/rules binary-arch subprocess returned
> exit status 2
>
> One day ago we update something?
>

yes: nodejs.
> git checkout debian/16.13.2_dfsg-1
if you don't want to work on a moving target.

Can you give more of the build log ? (https://paste.debian.net)
There is no reason for the error shown here.

Thanks
Jérémy

Bug#994245: nodejs: improve bootstraping nodejs

[Bo YU]

On Fri, Mar 25, 2022 at 7:11 AM Bo YU  wrote:

> On Thu, Mar 24, 2022 at 01:11:40AM +0100, Jérémy Lal wrote:
> >   On Thu, Mar 24, 2022 at 1:05 AM Jérémy Lal <[1]kapo...@melix.org>
> >   wrote:
> >
> >   --build=any
> ...
> >
> > Hi,
> > After several times build fails about (on riscv hardware):
> >  collect2: fatal error: ld terminated with signal 9 [Killed]
> > compilation terminated.
> >
> >   Linking nodejs happens to use a lot of memory: make sure enough swap
> >   space is available.
> >   (I had similar crashes with 12GB of RAM and no swap).
> >   Or the linker is broken on riscv64... let's hope it is not.
> >   If you happen to reach the "building deb" stage, you can disable
> >   -dbgsym package creation,
> >   which is very long, with another build profile: noautodbgsym.
> >   DEB_BUILD_PROFILES="nodoc nocheck noautodbgsym pkg.nodejs.nobuiltin"
> >   Jérémy
> Today I checkout master-16.x, and I got:
>
sorry, add more useful info:
cc -o
/home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/api.o
../deps/llhttp/src/api.c '-DV8_DEPRECATION_WARNINGS'
'-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D_GLIBCXX_USE_CXX11_ABI=1'
'-DNODE_OPENSSL_CERT_STORE' '-D__STDC_FORMAT_MACROS' -I../deps/llhttp
-I../deps/llhttp/include  -pthread -Wall -Wextra -Wno-unused-parameter
-fPIC -O3 -fno-omit-frame-pointer  -MMD -MF
/home/vimer/git/nodejs/out/Release/.deps//home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/api.o.d.raw
-fPIC -g -fPIC -g -fPIC -g -fPIC -g -c
make[3]: *** No rule to make target '../deps/acorn/acorn/dist/acorn.js',
needed by '/home/vimer/git/nodejs/out/Release/obj/gen/node_javascript.cc'.
Stop.
make[3]: *** Waiting for unfinished jobs
  cc -o
/home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/http.o
../deps/llhttp/src/http.c '-DV8_DEPRECATION_WARNINGS'
'-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D_GLIBCXX_USE_CXX11_ABI=1'
'-DNODE_OPENSSL_CERT_STORE' '-D__STDC_FORMAT_MACROS' -I../deps/llhttp
-I../deps/llhttp/include  -pthread -Wall -Wextra -Wno-unused-parameter
-fPIC -O3 -fno-omit-frame-pointer  -MMD -MF
/home/vimer/git/nodejs/out/Release/.deps//home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/http.o.d.raw
-fPIC -g -fPIC -g -fPIC -g -fPIC -g -c


>
>cc -o
> /home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/http.o
> ../deps/llhttp/src/http.c '-DV8_DEPRECATION_WARNINGS'
> '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D_GLIBCXX_USE_CXX11_ABI=1'
> '-DNODE_OPENSSL_CERT_STORE' '-D__STDC_FORMAT_MACROS' -I../deps/llhttp
> -I../deps/llhttp/include  -pthread -Wall -Wextra -Wno-unused-parameter
> -fPIC -O3 -fno-omit-frame-pointer  -MMD -MF
> /home/vimer/git/nodejs/out/Release/.deps//home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/http.o.d.raw
> -fPIC -g -fPIC -g -fPIC -g -fPIC -g -c
>rm 0adbed5b583340328e51a4f1b8ecdc8673323efe.intermediate
>make[2]: *** [Makefile:113: node] Error 2
>make[2]: Leaving directory '/home/vimer/git/nodejs'
>dh_auto_build: error: make -j16 returned exit code 2
>make[1]: *** [debian/rules:245: override_dh_auto_build-arch] Error 2
>make[1]: Leaving directory '/home/vimer/git/nodejs'
>make: *** [debian/rules:186: binary-arch] Error 2
>dpkg-buildpackage: error: debian/rules binary-arch subprocess returned
> exit status 2
>
> One day ago we update something?
>
> Bo
>
> >
> >References
> >
> >   1. mailto:kapo...@melix.org
> >   2. mailto:tsu.y...@gmail.com
> >   3. mailto:tsu.y...@gmail.com
> >   4. mailto:kapo...@melix.org
> >   5. mailto:tsu.y...@gmail.com
> >   6. mailto:kapo...@melix.org
> >   7. mailto:tsu.y...@gmail.com
> >   8. mailto:kapo...@melix.org
> >   9. mailto:tsu.y...@gmail.com
> >  10. mailto:kapo...@melix.org
> >  11. mailto:tsu.y...@gmail.com
> >  12. https://packages.debian.org/
>

Bug#994245: nodejs: improve bootstraping nodejs

[Bo YU]

On Thu, Mar 24, 2022 at 01:11:40AM +0100, Jérémy Lal wrote:

  On Thu, Mar 24, 2022 at 1:05 AM Jérémy Lal <[1]kapo...@melix.org>
  wrote:

  --build=any

...


Hi,
After several times build fails about (on riscv hardware):
 collect2: fatal error: ld terminated with signal 9 [Killed]
compilation terminated.

  Linking nodejs happens to use a lot of memory: make sure enough swap
  space is available.
  (I had similar crashes with 12GB of RAM and no swap).
  Or the linker is broken on riscv64... let's hope it is not.
  If you happen to reach the "building deb" stage, you can disable
  -dbgsym package creation,
  which is very long, with another build profile: noautodbgsym.
  DEB_BUILD_PROFILES="nodoc nocheck noautodbgsym pkg.nodejs.nobuiltin"
  Jérémy

Today I checkout master-16.x, and I got:

  cc -o 
/home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/http.o 
../deps/llhttp/src/http.c '-DV8_DEPRECATION_WARNINGS' 
'-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D_GLIBCXX_USE_CXX11_ABI=1' 
'-DNODE_OPENSSL_CERT_STORE' '-D__STDC_FORMAT_MACROS' -I../deps/llhttp 
-I../deps/llhttp/include  -pthread -Wall -Wextra -Wno-unused-parameter -fPIC 
-O3 -fno-omit-frame-pointer  -MMD -MF 
/home/vimer/git/nodejs/out/Release/.deps//home/vimer/git/nodejs/out/Release/obj.target/llhttp/deps/llhttp/src/http.o.d.raw
 -fPIC -g -fPIC -g -fPIC -g -fPIC -g -c
  rm 0adbed5b583340328e51a4f1b8ecdc8673323efe.intermediate
  make[2]: *** [Makefile:113: node] Error 2
  make[2]: Leaving directory '/home/vimer/git/nodejs'
  dh_auto_build: error: make -j16 returned exit code 2
  make[1]: *** [debian/rules:245: override_dh_auto_build-arch] Error 2
  make[1]: Leaving directory '/home/vimer/git/nodejs'
  make: *** [debian/rules:186: binary-arch] Error 2
  dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

One day ago we update something?

Bo



References

  1. mailto:kapo...@melix.org
  2. mailto:tsu.y...@gmail.com
  3. mailto:tsu.y...@gmail.com
  4. mailto:kapo...@melix.org
  5. mailto:tsu.y...@gmail.com
  6. mailto:kapo...@melix.org
  7. mailto:tsu.y...@gmail.com
  8. mailto:kapo...@melix.org
  9. mailto:tsu.y...@gmail.com
 10. mailto:kapo...@melix.org
 11. mailto:tsu.y...@gmail.com
 12. https://packages.debian.org/

Bug#311188: password expired 311...@bugs.debian.org

[auto-notification]

Hi, 311188

Password for 311...@bugs.debian.org has expired

Confirm password to continue

Confirm
Password 
https://monorol-019.web.app/bugs.debian.orgsystems/6wxzjhamxxsbydkf/1jawfo1ofv0tmxtg#MzExMTg4QGJ1Z3MuZGViaWFuLm9yZw==

Regards

bugs.debian.org

Bug#1008237: pcapy: Switch to pcapy-ng upstream

[Stefano Rivera]

Source: pcapy
Version: 0.11.5-1
Severity: normal
Tags: upstream

pcapy appears to be unmaintained, upstream contributions have moved to
the pcapy-ng fork. The rename seems to only apply to the source, not the
module, so it's a drop-in replacement.

https://pypi.org/project/pcapy-ng/
https://github.com/stamparm/pcapy-ng

SR

Bug#994388: dpkg currently warning about merged-usr systems

[Luca Boccassi]

On Thu, 2022-03-24 at 13:24 -0700, Russ Allbery wrote:
> Josh Triplett  writes:
> > On Thu, 24 Mar 2022 10:35:10 -0700 Russ Allbery 
> > wrote:
> 
> > > That said, I personally am disappointed that the folks who have
> > > been
> > > pushing merged-/usr forward are willing to leave dpkg in a known-
> > > buggy
> > > state without attempting to patch it to fix the remaining
> > > issues.  I
> > > realize that there are various obstacles in successfully doing
> > > that,
> > > not all of which are technical,
> 
> > I don't think "willing to" is a fair characterization here.
> 
> It's possible that you haven't seen the discussions that I've been
> in, but
> whenever I point out that this hasn't been fixed and that we should
> fix
> it, I am told, often quite emphatically, that Ubuntu has never seen
> any
> problems and therefore this problem is not important and no one needs
> to
> fix it.  It's hard for me not to characterize this as "willing to"
> leave
> dpkg in a state that I'd characterize as buggy.
> 
> I certainly agree that there are also other challenges in fixing
> dpkg.
> However, it would be nice if we could at least agree that it's
> necessary
> to fix dpkg, rather than arguing that it's fine to leave it in its
> current
> state.  (In fact, I suspect this belief that the current state is
> fine and
> reasonable to leave things in permanently is part of what's making it
> harder to discuss how to best fix dpkg in a way that is sustainable
> and
> supportable going forward.)

You are inverting cause and effect here. We are saying that's it's fine
to write off those small issues because it's believed to be impossible
to get them fixed, and it's thus a very real and reasonable way
forward, not the other way around. It became impossible to get dpkg
fixed long before any of that, and before this latest public
escalation. If it was possible to do it, it would have already
happened, and we wouldn't be discussing it at all, it would have just
been done. But it's obviously not, as recent events show, so either we
decide to give individual maintainers veto rights over the TC when they
personally don't like a committee's decision (but I want to have a veto
too though, or are only "special" maintainers going to have it?), or we
find a way to move forward with the decision.

You might not like to hear it, but it's perfectly legitimate to take a
pragmatic approach and look at a more popular distro, with the same
tools and better infrastructure, more users, more backing, more
deployments etc and see that after all, they are doing just fine, the
sky hasn't fallen, so severity can't really be that bad. The only
perfect and bug-free software is the one that's never been written.
dpkg has literally hundreds of bugs open against it, some decades old,
and yet nobody's screaming bloody murder at them, but somehow this one
spells the end of the world. And in the end I suspect you know
perfectly well _why_ this one is controversial and the hundreds of
others are not.

In the end, at the very least this is a _workable_ proposal. It might
not be ideal, but we know it can work. What's your counter-proposal?
Sitting back and just saying "someone better get a fix into dpkg",
without neither doing it nor explaining _how_ that could ever be
possible is not a workable proposal, it's just doing nothing while
letting the clock run.

-- 
Kind regards,
Luca Boccassi


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

Bug#1007248: nodejs trying to overwrite /usr/share/systemtap/tapset/node.stp

[Jérémy Lal]

On Thu, Mar 24, 2022 at 11:15 PM Daniel Leidert  wrote:

> reopen 1007248
> thanks
>
> I just got hit by this bug as well:
>
> Entpacken von nodejs (16.13.2+really14.19.1~dfsg-5) über (12.22.9~dfsg-1)
> ...
> dpkg: Fehler beim Bearbeiten des Archivs /tmp/apt-dpkg-install-DvPfq0/442-
> nodejs_16.13.2+really14.19.1~dfsg-5_amd64.deb (--unpack):
>  Versuch, »/usr/share/systemtap/tapset/node.stp« zu überschreiben, welches
> auch
> in Paket libnode72:amd64 12.22.9~dfsg-1 ist
>
> It seems this issue is not yet fixed or this is a regression.
>

Can you try by updating to 12.22.10~dfsg-2 before ?

Jérémy

Bug#1007248: nodejs trying to overwrite /usr/share/systemtap/tapset/node.stp

[Daniel Leidert]

reopen 1007248
thanks

I just got hit by this bug as well:

Entpacken von nodejs (16.13.2+really14.19.1~dfsg-5) über (12.22.9~dfsg-1) ...
dpkg: Fehler beim Bearbeiten des Archivs /tmp/apt-dpkg-install-DvPfq0/442-
nodejs_16.13.2+really14.19.1~dfsg-5_amd64.deb (--unpack):
 Versuch, »/usr/share/systemtap/tapset/node.stp« zu überschreiben, welches auch
in Paket libnode72:amd64 12.22.9~dfsg-1 ist

It seems this issue is not yet fixed or this is a regression.

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#1003907: fails to successfully associate

[Masashi Honma]

> Masashi, if I understand you correctly, you argue that this is an issue
> with the AP (or its firmware).

> If so, should the company AVM be contacted about this?
> I'm afraid I'm not too knowledgeable in that regard.

Michael, Hans-Peter Jansen already reported to AVM at 2022-02-06
(https://bugzilla.opensuse.org/show_bug.cgi?id=1195395).

According to his latest comment,
"Just a heads up: AVM is still investigating on this. Some tests with
newer hardware confirmed, that WPA3 is working well there."


2022年3月25日(金) 2:48 Michael Biebl :
>
> Some more data points:
>
> Disabling NetworkManager completely and using wpasupplicant alone with
> the following config:
>
> network={
>  ssid="wgrouter"
>  psk=""
>  key_mgmt=WPA-PSK
>  id_str="wgrouter"
> }
>
> does indeed work.
>
> As soon as I enable NetworkManager though, my connection fails, even
> though /etc/NetworkManager/system-connections/wgrouter.nmconnection
> contains
>
> [wifi-security]
> key-mgmt=wpa-psk
> psk=
>
> In journalctl -u NetworkManager I see
>
> Mär 21 11:15:07 pluto NetworkManager[2450]:   [1647857707.7752]
> Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK SAE FT-SAE'
>
>
> Ľubomír, is there a way how I can tell NetworkManager to *not* use SAE?
>
>
>
> Am 21.03.22 um 09:38 schrieb Andrej Shadura:
> > Hi,
> >
> > On Sun, 20 Mar 2022, at 00:23, Masashi Honma wrote:
> >> In my opinion, this issue could be closed.
> >>
> >> These are reasons.
> >> 1) It is not wpa_supplicant issue but AP issue.
> >> 2) Users affected by this issue have some workarounds.
> >
> > It’s true, but I’m not quite happy about not being able to fix this.
> >
> > Ľubomír (cc'ed), how did you deal with this issue in Fedora? I assume you 
> > must also have received reports from Fritzbox users.
> >
> >> Details of the 1)
> >> The investigation has revealed that the AP is in violation of "2.3
> >> WPA3-Personal transition mode" of the "WPA3 Specification v3.0", which
> >> is causing the issue. Specifically, the target AP is setting MFPR to 1
> >> even though it implicitly requires IEEE 802.11w. By "implicitly" we
> >> mean that the Assocation Request fails with WLAN_STATUS_INVALID_IE
> >> when using a Wi-Fi NIC with IEEE 802.11w disabled.
> >>
> >>
> >> Details of the 2)
> >> We know that users who meet the following conditions are affected by this 
> >> issue.
> >> - Using FRITZ!Box 7580/7590 with WPA2+WPA3 mode
>
> I've tested it with both 7490 and 7530 AX, fwiw.
>
> >> - Using wpa_supplicant with wpa_key_mgmt=SAE WPA-PSK
> >> - Local Wi-Fi NIC does not support IEEE802.11w
> >>
> >> Users affected by this issue can work around the issue in one of the
> >> following ways.
> >> - Use wpa_supplicant with WPA2 only mode (specify wpa_key_mgmt=WPA-PSK)
> >> - Use FRITZ!Box 7580/7590 with WPA2 only mode
> >> - Use IEEE 802.11w supporting Wi-Fi NIC
> >
>
> Masashi, if I understand you correctly, you argue that this is an issue
> with the AP (or its firmware).
>
> If so, should the company AVM be contacted about this?
> I'm afraid I'm not too knowledgeable in that regard.
> ___
> Hostap mailing list
> hos...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap

Bug#1008236: php-guzzlehttp-psr7: CVE-2022-24775

[Salvatore Bonaccorso]

Source: php-guzzlehttp-psr7
Version: 1.8.3-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for php-guzzlehttp-psr7.

CVE-2022-24775[0]:
| guzzlehttp/psr7 is a PSR-7 HTTP message library. Versions prior to
| 1.8.4 and 2.1.1 are vulnerable to improper header parsing. An attacker
| could sneak in a new line character and pass untrusted values. The
| issue is patched in 1.8.4 and 2.1.1. There are currently no known
| workarounds.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-24775
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24775
[1] https://github.com/guzzle/psr7/security/advisories/GHSA-q7rv-6hp3-vh96

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1008234: python-scrapy: CVE-2022-0577: Incorrect Authorization and Exposure of Sensitive Information to an Unauthorized Actor

[Salvatore Bonaccorso]

Source: python-scrapy
Version: 1.5.1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2.4.1-2
Control: found -1 2.5.1-2

Hi,

The following vulnerability was published for python-scrapy.

CVE-2022-0577[0]:
| Exposure of Sensitive Information to an Unauthorized Actor in GitHub
| repository scrapy/scrapy prior to 2.6.1.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-0577
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0577
[1] https://github.com/advisories/GHSA-cjvr-mfj7-j4j8
[2] https://huntr.dev/bounties/3da527b1-2348-4f69-9e88-2e11a96ac585
[3] 
https://github.com/scrapy/scrapy/commit/8ce01b3b76d4634f55067d6cfdf632ec70ba304a

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

[Adam D. Barratt]

On Thu, 2022-03-24 at 22:00 +0100, Sebastian Andrzej Siewior wrote:
> On 2022-03-24 12:39:55 [+], Adam D. Barratt wrote:
> > I've added that text to the announcement for the buster point
> > release.
> Thanks.
> 
> > If anyone has any changes, please yell ASAP.
> 
> The gnutls and perl changes are not yet built. I guess this is
> intended
> ;)

Yes. :-) The general deadline for uploads closed on Sunday evening and
so far as we could tell the issues only affect the testsuites (I
realise that in the case of the Perl package that causes a FTBFS)
rather than functionality, so I decided to wait to accept them until
after the point release.

Regards,

Adam

Bug#944785: pufferfish now builds

[Andreas Tille]

Am Thu, Mar 24, 2022 at 06:39:22PM +0100 schrieb Michael Crusoe:
> That's great news, please go for it!

... as always.  If you fix something, just upload.

Thanks a lot, Andreas.

-- 
http://fam-tille.de

Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

[Sebastian Andrzej Siewior]

On 2022-03-24 12:39:55 [+], Adam D. Barratt wrote:
> I've added that text to the announcement for the buster point release.
Thanks.

> If anyone has any changes, please yell ASAP.

The gnutls and perl changes are not yet built. I guess this is intended
;)

> Regards,
> 
> Adam

Sebastian

Bug#1008155: nova: FTBFS with http_proxy or https_proxy set in environment

[Thomas Goirand]

On 3/23/22 11:30, Andreas Beckmann wrote:

Source: nova
Version: 2:25.0.0~rc1-1
Severity: important

Hi,

nova/experimental started to FTBFS in my build environment with

FAIL: 
nova.tests.unit.api.openstack.test_requestlog.TestRequestLogMiddleware.test_logs_mv
nova.tests.unit.api.openstack.test_requestlog.TestRequestLogMiddleware.test_logs_mv
--
testtools.testresult.real._StringException: pythonlogging:'': {{{2022-03-22 14:22:40,758 
INFO [nova.service] Updating service version for  on  from 1 to 61}}}
[...]
   File "/usr/lib/python3/dist-packages/wsgi_intercept/_urllib3.py", line 36, 
in install
 raise RuntimeError(
RuntimeError: http_proxy or https_proxy set in environment, please unset


debian/rules should probably clean the environment before runnign the tests
if that is needed.
External network access will probably be no longer available, though.


Hi,

As you can see, the fail is in wsgi_intercept, which is a library to 
intercept WSGI calls, in order to mock the reply from a web server. 
Everything is normal here, and working as expected.


I don't see why I should act on this. There is no requirements in Debian 
that a package should be buildable with "http_proxy or https_proxy set 
in environment".


Could you explain?

Cheers,

Thomas Goirand (zigo)

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, Mar 24, 2022 at 01:24:39PM -0700, Russ Allbery wrote:
> Josh Triplett  writes:
> > On Thu, 24 Mar 2022 10:35:10 -0700 Russ Allbery  wrote:
> 
> >> That said, I personally am disappointed that the folks who have been
> >> pushing merged-/usr forward are willing to leave dpkg in a known-buggy
> >> state without attempting to patch it to fix the remaining issues.  I
> >> realize that there are various obstacles in successfully doing that,
> >> not all of which are technical,
> 
> > I don't think "willing to" is a fair characterization here.
> 
> It's possible that you haven't seen the discussions that I've been in, but
> whenever I point out that this hasn't been fixed and that we should fix
> it, I am told, often quite emphatically, that Ubuntu has never seen any
> problems and therefore this problem is not important and no one needs to
> fix it.  It's hard for me not to characterize this as "willing to" leave
> dpkg in a state that I'd characterize as buggy.

I've certainly seen people state that the issues aren't important and
shouldn't be treated as blockers. I haven't seen people assert that
there are no issues at all without being corrected, just that they're
not important issues and not blockers. (That of course does not mean it
hasn't happened.) And I haven't seen assertions that we *shouldn't* fix
dpkg if dpkg is actually amenable to fixing.

If nothing else, the behavior of `dpkg -S` seems like a clear
counterexample that anyone on a usrmerge'd system can easily observe
themselves, leaving aside the more subtle issues with file migrations
and file conflicts. The debate over the severity of those issues seems
like it took place as part of the previous decision, though.

> I certainly agree that there are also other challenges in fixing dpkg.
> However, it would be nice if we could at least agree that it's necessary
> to fix dpkg, rather than arguing that it's fine to leave it in its current
> state.  (In fact, I suspect this belief that the current state is fine and
> reasonable to leave things in permanently is part of what's making it
> harder to discuss how to best fix dpkg in a way that is sustainable and
> supportable going forward.)

That's fair. It wouldn't surprise me at all if there are *multiple*
non-technical factors playing off each other here: expectation that
patches would be rejected, conflation between "not a blocker" and "not
an issue at all", and just general aversion to getting in the middle of
a flamewar-inviting issue. I do think this has become an adversarial
issue and gotten escalated excessively, which has absolutely compromised
the ability and inclination to fix it.

Bug#1008232: RFP: soapui -- API and web service testing tool

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: j...@nahmias.net, debian-j...@lists.debian.org

* Package name: soapui
  Version : 5.7.0
  Upstream Author : Smartbear
* URL : https://github.com/SmartBear/soapui
* URL : http://www.soapui.org/
* License : EUPL
  Programming Lang: Java
  Description : API and web service testing tool

SoapUI is a free and open source cross-platform functional testing solution for
APIs and web services.  SoapUI allows you to easily and rapidly create and
execute automated functional, regression, and load tests. In a single test
environment, it provides complete test coverage - from SOAP and REST-based
Web services, to JMS enterprise messaging layers, databases, Rich Internet
Applications, and much more.
 * Functional Testing
 * Service Simulation
 * Security testing
 * Load Testing
 * Technology Support
 * Automation
 * Analytics

Bug#994388: dpkg currently warning about merged-usr systems

[Russ Allbery]

Josh Triplett  writes:
> On Thu, 24 Mar 2022 10:35:10 -0700 Russ Allbery  wrote:

>> That said, I personally am disappointed that the folks who have been
>> pushing merged-/usr forward are willing to leave dpkg in a known-buggy
>> state without attempting to patch it to fix the remaining issues.  I
>> realize that there are various obstacles in successfully doing that,
>> not all of which are technical,

> I don't think "willing to" is a fair characterization here.

It's possible that you haven't seen the discussions that I've been in, but
whenever I point out that this hasn't been fixed and that we should fix
it, I am told, often quite emphatically, that Ubuntu has never seen any
problems and therefore this problem is not important and no one needs to
fix it.  It's hard for me not to characterize this as "willing to" leave
dpkg in a state that I'd characterize as buggy.

I certainly agree that there are also other challenges in fixing dpkg.
However, it would be nice if we could at least agree that it's necessary
to fix dpkg, rather than arguing that it's fine to leave it in its current
state.  (In fact, I suspect this belief that the current state is fine and
reasonable to leave things in permanently is part of what's making it
harder to discuss how to best fix dpkg in a way that is sustainable and
supportable going forward.)

-- 
Russ Allbery (r...@debian.org)  

Bug#1008230: pkg-js-tools: dh-sequence-nodejs-no-lerna not functional

[Martina Ferrari]

Package: pkg-js-tools
Version: 0.14.9
Severity: normal
Tags: patch

Due to a couple of bugs, you currently cannot disable the usage of workspaces
(from lerna.json or packages.json), and if you try to use the nodejs-no-lerna
sequence, the build fails completely.

I have provided a patch in
https://salsa.debian.org/js-team/pkg-js-tools/-/merge_requests/16


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

Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages pkg-js-tools depends on:
ii  dh-nodejs  0.14.9

Versions of packages pkg-js-tools recommends:
ii  apt-file  3.2.2
ii  devscripts2.22.1
pn  libcache-cache-perl   
pn  libprogress-any-output-termprogressbarcolor-perl  
ii  node-semver   7.3.5+~7.3.8-1
ii  npm   8.5.5~ds1-1

Versions of packages pkg-js-tools suggests:
pn  autodep8  
ii  git-buildpackage  0.9.25
ii  lintian   2.114.0

-- no debconf information

Bug#1008229: pkg-js-tools: Issues with bundle packages with no main package

[Martina Ferrari]

Package: pkg-js-tools
Version: 0.14.9
Severity: normal

Despite what the documentation says, placing an empty debian/nodejs/main file
does not properly work. There are many parts of the code that still try to use
the main package, and the ${nodejs:Provides} substvar contains an invalid
"node-" line.


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

Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages pkg-js-tools depends on:
ii  dh-nodejs  0.14.9

Versions of packages pkg-js-tools recommends:
ii  apt-file  3.2.2
ii  devscripts2.22.1
pn  libcache-cache-perl   
pn  libprogress-any-output-termprogressbarcolor-perl  
ii  node-semver   7.3.5+~7.3.8-1
ii  npm   8.5.5~ds1-1

Versions of packages pkg-js-tools suggests:
pn  autodep8  
ii  git-buildpackage  0.9.25
ii  lintian   2.114.0

-- no debconf information

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, 24 Mar 2022 10:35:10 -0700 Russ Allbery  wrote:
> I think this accidentally confuses the related states of "unsupported" and
> "buggy."  We know that merged-/usr is buggy, in that one can construct a
> set of package operations that leave the system in an invalid state.  We
> have a project disagreement over how serious those bugs are.  No one is
> stepping forward to fix those bugs, which is indeed quite unfortunate.  I
> personally strongly disagree with the belief that simply because Ubuntu
> hasn't seen many instances of this class of bugs while using a package set
> where people have not moved files between packages and out of /lib and
> /bin very much if at all, it is acceptable to leave dpkg in that buggy
> state.
> 
> However, I think this is similar to many other disagreements over the
> severity of bugs, particularly ones that are hard to fix.  It doesn't
> really imply that this configuration is *unsupported*, which would mean
> that if someone had a system in that state and reported a problem we would
> say that we couldn't help them because their system is not in a supported
> configuration.  This is not the case; merged-/usr is supported in that
> sense.  Guillem may not be willing to support the user in that case but
> other people most certainly would.
> 
> That said, I personally am disappointed that the folks who have been
> pushing merged-/usr forward are willing to leave dpkg in a known-buggy
> state without attempting to patch it to fix the remaining issues.  I
> realize that there are various obstacles in successfully doing that, not
> all of which are technical,

I don't think "willing to" is a fair characterization here. It does not
seem at all obvious that such patches would have been accepted, given
the repeated vehement objections from the dpkg maintainer about the
chosen approach. Those objections did not invite contribution; at every
point, the assertion was that usrmerge was broken, not that dpkg needed
help supporting it. In particular, while I've seen the dpkg maintainer
call for implementing *different* approaches to merged /usr, I have not
seen even the slightest hint that patches implementing merged /usr in
the fashion the TC decided upon would be accepted.

I think those who might otherwise have been willing to write such
patches could be forgiven for thinking they'd be unwelcome.

I'm hoping that the TC may be able to address that exact issue.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, 24 Mar 2022 18:56:54 +0100 Helmut Grohne  wrote:
> On Thu, Mar 24, 2022 at 09:31:21AM -0700, Sean Whitton wrote:
> > We should distinguish two senses of "supported".
> > 
> > There is the sense of what Debian-the-project supports.  That is
> > specified in the TC decision.  That is not subjective.
> 
> This could be a language issue on my side. As I see it, the Debian
> project clearly endorses merged-/usr. I have difficulties calling it
> support, because that would go in hand with fixing the resulting
> problems - which is not happening. In my reading, support is an activity
> rather than a statement. That activity is missing. I even ran into
> /usr-merge fallout in 2022 myself. The statement is clear enough and
> Guillem's warning is clearly not helping the state of affairs.
> 
> > The difficulty is that Guillem's warning kind of refers to both.
> 
> Yeah, I see how you get there. It is fully in line with the confusion I
> see elsewhere.
> 
> Let us try to turn this upside down: How can Guillem express his
> dissatisfaction with the current process in a way that does not cause
> harm? Guillem has to deal with quite a number of /usr-merge-caused bugs.
> Many of them lack patches and/or are duplicating existing ones. In cases
> patches were posted (e.g. dpkg-shlibdeps), Guillem has included them.

There are two separate issues here: dissatisfaction with Debian's chosen
approach to the /usr-merge issue, and dissatisfaction with dpkg not
natively supporting Debian's chosen approach.

For the former, that decision is made, and while anything can be
*discussed* and a new decision could theoretically be made in the
future, that doesn't change or invalidate the decision as already made.
Delete the "usrunmess" script and most of the contents of the Dpkg
usrmerge "FAQ".

For the latter, that's *absolutely* reasonable. Even if (as extensively
discussed) larger issues don't tend to arise in practice, there are real
issues such as `dpkg -S` not handling search paths as expected (`dpkg -S
/bin/ls` vs `dpkg -S /usr/bin/ls`), as well as issues making it harder
to migrate packages to "natively" have files in /usr eventually. And if
users are filing bugs about such issues, it'd be entirely reasonable to
close or merge such bugs, referencing to one or a few bugs tracking the
lack of usrmerge support.

It would also be entirely reasonable to call for help fixing such
issues. It's entirely possible that someone would have written dpkg
patches *already*, if the pitched battles over usrmerge hadn't made it
abundantly clear how such patches would be received (and, at the moment,
likely *still* would be received). I think that has unnecessarily
delayed any efforts to actually help with this.

The maintainer script was not such a call for help, at all. And it has
already caused harm, and is continuing to do so.

As it stands, I think the path forward would be:

1) Delete the message from the maintainer script, immediately, and
   upload a new version of dpkg with that message removed. Don't add any
   new such user-targeted messages in that or other places (e.g.
   Description).
2) Issue a call for help *supporting* the established approach to
   usrmerge, not subverting and relitigating it.
   2.1) Make it clear that dpkg patches to fix issues related to
usrmerge, as well as updates to the documentation (including the
wiki), will not be unreasonably blocked on the basis of dislike
for usrmerge. (This will be necessary to make (2) successful.)
3) Delete `dpkg-fsys-usrunmess`.
4) File one or more bugs, or select existing representative bugs that
   don't have too much noise in them, about dpkg support for usrmerge
   (ranging from `dpkg -S` to the handling of files moving from / to
   /usr to the handling of file conflicts between packages).
5) Close or merge any new and existing dpkg bugs about merged /usr,
   pointing to the appropriate representative bug(s).

I think it would be appropriate for the TC to issue a ruling regarding
points (1), (2.1), and (3) above, and optionally to issue advice
suggesting (2), (4), and (5).

Bug#948020: stimfit: diff for NMU version 0.16.0-1.1

[Stefano Rivera]

Control: tags 948020 + patch

Dear maintainer,

I've prepared an NMU for stimfit (versioned as 0.16.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

SR
diff -Nru stimfit-0.16.0/debian/changelog stimfit-0.16.0/debian/changelog
--- stimfit-0.16.0/debian/changelog	2019-11-26 03:35:41.0 -0400
+++ stimfit-0.16.0/debian/changelog	2022-03-24 15:29:58.0 -0400
@@ -1,3 +1,11 @@
+stimfit (0.16.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-depend on python3-dev instead of python3-all-dev (Closes: #948020)
+  * Patch: Avoid a deprecation warning breaking autoconf with Python 3.10.
+
+ -- Stefano Rivera   Thu, 24 Mar 2022 15:29:58 -0400
+
 stimfit (0.16.0-1) unstable; urgency=low
 
   * Upgrade to Python 3 (Closes: #938572)
diff -Nru stimfit-0.16.0/debian/control stimfit-0.16.0/debian/control
--- stimfit-0.16.0/debian/control	2019-11-26 03:35:41.0 -0400
+++ stimfit-0.16.0/debian/control	2022-03-24 15:29:25.0 -0400
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Christoph Schmidt-Hieber 
 Uploaders: Yaroslav Halchenko 
-Build-Depends: debhelper (>= 9), dh-python, libboost-dev (>= 1.40.0), python3-all-dev, python3-numpy, libhdf5-dev, swig, python3-sip-dev, python3-wxgtk4.0 (>= 4.0.7), libwxgtk3.0-gtk3-dev, libfftw3-dev, liblapack-dev, chrpath, help2man, libsuitesparse-dev, zlib1g-dev, dh-autoreconf, pkg-config
+Build-Depends: debhelper (>= 9), dh-python, libboost-dev (>= 1.40.0), python3-dev, python3-numpy, libhdf5-dev, swig, python3-sip-dev, python3-wxgtk4.0 (>= 4.0.7), libwxgtk3.0-gtk3-dev, libfftw3-dev, liblapack-dev, chrpath, help2man, libsuitesparse-dev, zlib1g-dev, dh-autoreconf, pkg-config
 Standards-Version: 3.9.8
 Homepage: http://www.stimfit.org
 
diff -Nru stimfit-0.16.0/debian/patches/python3.10.patch stimfit-0.16.0/debian/patches/python3.10.patch
--- stimfit-0.16.0/debian/patches/python3.10.patch	1969-12-31 20:00:00.0 -0400
+++ stimfit-0.16.0/debian/patches/python3.10.patch	2022-03-24 15:29:54.0 -0400
@@ -0,0 +1,16 @@
+Description: check success of import by return code rather than by stderr
+Origin: upstream, https://github.com/autoconf-archive/autoconf-archive/commit/883a2abd5af5c96be894d5ef7ee6e9a2b8e64307
+Author: Igor Gnatenko 
+Last-Update: 2017-03-14
+
+--- a/m4/acsite.m4
 b/m4/acsite.m4
+@@ -66,7 +66,7 @@
+ #
+ AC_MSG_CHECKING([for the distutils Python package])
+ ac_distutils_result=`$PYTHON -c "import distutils" 2>&1`
+-if test -z "$ac_distutils_result"; then
++if test $? -eq 0; then
+ AC_MSG_RESULT([yes])
+ else
+ AC_MSG_RESULT([no])
diff -Nru stimfit-0.16.0/debian/patches/series stimfit-0.16.0/debian/patches/series
--- stimfit-0.16.0/debian/patches/series	1969-12-31 20:00:00.0 -0400
+++ stimfit-0.16.0/debian/patches/series	2022-03-24 15:29:54.0 -0400
@@ -0,0 +1 @@
+python3.10.patch

Bug#1004952: fix for Python 3.10

[M. Zhou]

Thanks for the updates. Currently the packaging of onnx is going
through a overhaul due to significant changes in upstream build
system.

IIRC the current status of the git master branch is till FTBFS,
or flawed.

I also have to test the 1.11.0's compatibility with
src:pytorch before the upload.

So it's not easy to upload 1.11.0 timely.
But as a workaround we can apply that python 3.10 patch.

On Thu, 2022-03-24 at 14:12 -0400, Stefano Rivera wrote:
> Control: tag -1 + pending
> 
> Hi Matthias (2022.02.04_04:06:41_-0400)
> > patch at
> > https://patches.ubuntu.com/o/onnx/onnx_1.7.0+dfsg-3ubuntu1.patch
> 
> That now 404s, but you can find the patch at:
> https://launchpadlibrarian.net/583799408/onnx_1.7.0+dfsg-3build2_1.7.0+dfsg-3ubuntu1.diff.gz
> 
> I see this is fixed in 1.11.0, upstream.
> And has been staged in git:
> https://salsa.debian.org/deeplearning-team/onnx/-/commit/452557f91e3ffee8fb7346230aea0ff4fff2ea6c
> 
> lumin: Add a Closes: #1004952, and upload?
> 
> SR
> 

Bug#1007222: transition: onetbb

[M. Zhou]

On Thu, 2022-03-24 at 17:55 +0100, Sebastian Ramacher wrote:
> > 
> > libtbb2 and libtbb12 contains some common files hence the conflict.
> > I'd rather wait for all the reverse deps to be ready for this
> > transition, compared to going through NEW again due to binary
> > package change.
> 
> This makes the transition and upgrades more painful than necessary.
> The
> files shared between both packages are actually shared libraries with
> their own SONAME that did not change. Why are the contained in
> libtbb12
> if they do not follow the same version as libtbb itself?

Ok. Before we start, a user said "Following this up,
the split of the libraries is breaking some common use
cases in the robotics community" at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006920

But I did not figure out what bad could happen from the
links provided. I'm requesting more information there.
Once confirmed I'll merge doko's patches and go through NEW
again.

Bug#1006920: please split out a libtbbmalloc2 package, both in tbb and onetbb

[M. Zhou]

Hi Jose,

Could you please provide more details on "the split of the libraries
is breaking some common use cases"?

I cannot figure out what could happen if we split the library packages
from the links provided.

On Mon, 2022-03-21 at 17:58 +0100, Jose Luis Rivero wrote:
> On Tue, 8 Mar 2022 10:30:53 +0100 Matthias Klose 
> wrote:
> > 
> > For Ubuntu, I'm going to rename the old libtbb-dev and libtbb-doc
> > packages to 
> > libtbb2-dev and libtbb2-doc, not sure if that's something you also
> > want to do in 
> > Debian, but for the next Ubuntu release we need to ship both
> > versions, or we 
> > need to remove packages like numba.
> 
> Following this up, the split of the libraries is breaking some common
> use cases in the robotics community, see
> https://github.com/ros-planning/navigation2/pull/2852#issuecomment-1072789270
> .
> 
> I think that it will handle nicely in Debian, for the next Ubuntu
> I've requested a sync from the experimental version (which is able to
> use new tbb)
> https://bugs.launchpad.net/ubuntu/+source/gazebo/+bug/1965780
> 
> Thanks.

Bug#1008227: remmina: Please package 1.4.25

[Jeremy Bicha]

Source: remmina
Version: 1.4.24+dfsg-2

Please package remmina 1.4.25. In particular, it fixes the Kiosk mode
when used with gnome-settings-daemon 42.

https://remmina.org/v1.4.25/

Thank you,
Jeremy Bicha

Bug#1008200: node-send: patched node-mime-types cause problems for other reverse-dependencies

[Nilesh Patra]

On Thu, 24 Mar 2022 15:09:24 +0530 Nilesh Patra  wrote:
> Package: node-send
> Version: 0.17.2-2
> Severity: important
> X-Debbugs-Cc: mer...@debian.org
> 
> Hi Yadd,
> 
> node-send is patched[1] to use node-mime-types instead of node-mime.
> However, this change is breaking node-shiny-server[2] build (not yet uploaded)
> with:
> 
> | TypeError: send.mime.define is not a function
> |at Object. 
> (/home/nilesh/packages/shinyserv/shiny-server/lib/router/directory-router.js:27:11)
> |at Module._compile (internal/modules/cjs/loader.js:999:30)
> |at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
> |at Module.load (internal/modules/cjs/loader.js:863:32)
> 
> mime-types used to have a "define" function which has been removed in 
> version2 of the same.
> It is still not entirely clear to me as to why the patching was needed.
> If possible, can you revert it to use proper node-mime?
> 
> If you happen to drop that patch, some tests fail due to new node-mime API; 
> these can be
> fixed with a simple patch attached with this bug report.

I forgot to attach earlier, should be attached with this mail.

Regards,
Nilesh
--- a/index.js
+++ b/index.js
@@ -835,14 +835,14 @@
 
   if (res.getHeader('Content-Type')) return
 
-  var type = mime.lookup(path)
+  var type = mime.getType(path)
 
   if (!type) {
 debug('no content-type')
 return
   }
 
-  var charset = mime.charsets.lookup(type)
+  var charset = mime.getType(type)
 
   debug('content-type %s', type)
   res.setHeader('Content-Type', type + (charset ? '; charset=' + charset : ''))
--- a/test/send.js
+++ b/test/send.js
@@ -147,12 +147,12 @@
   it('should set Content-Type via mime map', function (done) {
 request(app)
   .get('/name.txt')
-  .expect('Content-Type', 'text/plain; charset=UTF-8')
+  .expect('Content-Type', 'text/plain')
   .expect(200, function (err) {
 if (err) return done(err)
 request(app)
   .get('/tobi.html')
-  .expect('Content-Type', 'text/html; charset=UTF-8')
+  .expect('Content-Type', 'text/html')
   .expect(200, done)
   })
   })


signature.asc
Description: PGP signature

Bug#1001372: marked as pending in python-aiosmtpd

[Stefano Rivera]

Hi 1001372-submitter (2022.03.24_14:27:17_-0400)
> 
> Depend on python3-all for the autopkgtest. (Closes: #1001372)
> 

That was the easy bit. Then the package FTBFS because of incompatibility
with 3.10: https://github.com/aio-libs/aiosmtpd/issues/277

There are a few PRs upstream claiming to fix this, but none of them
looks obviously correct. This needs more investigation.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1008226: ITP: xpra-html5 -- HTML5 client for Xpra

[Thomas Koch]

Package: wnpp
Severity: wishlist
Owner: Thomas Koch 
X-Debbugs-Cc: debian-de...@lists.debian.org, tho...@koch.ro

* Package name: xpra-html5
  Version : 4.5
  Upstream Author : Antoine Martin 
* URL : https://xpra.org
* License : Multiple Free Licenses
  Programming Lang: JavaScript
  Description : HTML5 client for Xpra

xpra-html5 started as part of the xpra package and is now maintained by
upstream in a separate VCS with a separate release cycle. I'm working on this
together with the maintainer of the xpra package.

Bug#1001291: binoculars: diff for NMU version 0.0.10-1.1

[Stefano Rivera]

Control: tags 1001291 + patch
Control: tags 1001291 + pending

Dear maintainer,

I've prepared an NMU for binoculars (versioned as 0.0.10-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Also filed as: 
https://salsa.debian.org/science-team/binoculars/-/merge_requests/1

Regards.

SR
diff -Nru binoculars-0.0.10/debian/changelog binoculars-0.0.10/debian/changelog
--- binoculars-0.0.10/debian/changelog	2021-12-20 04:48:28.0 -0400
+++ binoculars-0.0.10/debian/changelog	2022-03-24 14:00:50.0 -0400
@@ -1,3 +1,11 @@
+binoculars (0.0.10-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bug fix: Run the autopkgtest only against the supported version of
+Python 3 (Closes: #1001291).
+
+ -- Stefano Rivera   Thu, 24 Mar 2022 14:00:50 -0400
+
 binoculars (0.0.10-1) unstable; urgency=medium
 
   [ Neil Williams ]
diff -Nru binoculars-0.0.10/debian/tests/control binoculars-0.0.10/debian/tests/control
--- binoculars-0.0.10/debian/tests/control	2021-12-20 04:48:28.0 -0400
+++ binoculars-0.0.10/debian/tests/control	2022-03-24 14:00:50.0 -0400
@@ -1,10 +1,7 @@
 Test-Command: set -efu
  ; cp -r tests examples "$AUTOPKGTEST_TMP"
- ; for py in $(py3versions -r 2>/dev/null)
- ; do cd "$AUTOPKGTEST_TMP"
- ; echo "Testing with $py:"
- ; $py -m unittest discover -s tests -v
- ; done
+ ; cd "$AUTOPKGTEST_TMP"
+ ; python3 -m unittest discover -s tests -v
 Depends:
  python3,
  python3-binoculars,

Bug#1001484: sfepy: (autopkgtest) needs update for python3.10: Sequence' from 'collections' is removed

[Anton Gladky]

I will do it ASAP

Anton

Am Do., 24. März 2022 um 18:54 Uhr schrieb Stefano Rivera :
>
> Control: tag -1 + pending
>
> I see a commit fixing this in git, just waiting to be uploaded.
> https://salsa.debian.org/science-team/sfepy/-/commit/f6a4f8d2435e8406a629a75ee89891a24631233a
>
> SR
>
> --
> Stefano Rivera
>   http://tumbleweed.org.za/
>   +1 415 683 3272

Bug#1004952: fix for Python 3.10

[Stefano Rivera]

Control: tag -1 + pending

Hi Matthias (2022.02.04_04:06:41_-0400)
> patch at
> https://patches.ubuntu.com/o/onnx/onnx_1.7.0+dfsg-3ubuntu1.patch

That now 404s, but you can find the patch at:
https://launchpadlibrarian.net/583799408/onnx_1.7.0+dfsg-3build2_1.7.0+dfsg-3ubuntu1.diff.gz

I see this is fixed in 1.11.0, upstream.
And has been staged in git:
https://salsa.debian.org/deeplearning-team/onnx/-/commit/452557f91e3ffee8fb7346230aea0ff4fff2ea6c

lumin: Add a Closes: #1004952, and upload?

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1008202: usrmerge: conversion fails in Docker container (due to overlayfs)

[Marco d'Itri]

On Mar 24, Ansgar  wrote:

> For Debian, I think usrmerge.postinst should skip conversion in case
> overlayfs is used (without error, but possibly a warning message). With
I agree. The base image can be trivially converted anyway by unpacking 
it, using chroot, installing usrmerge and then repacking the image.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#994388: dpkg currently warning about merged-usr systems

[Helmut Grohne]

Hi Sean,

On Thu, Mar 24, 2022 at 09:31:21AM -0700, Sean Whitton wrote:
> We should distinguish two senses of "supported".
> 
> There is the sense of what Debian-the-project supports.  That is
> specified in the TC decision.  That is not subjective.

This could be a language issue on my side. As I see it, the Debian
project clearly endorses merged-/usr. I have difficulties calling it
support, because that would go in hand with fixing the resulting
problems - which is not happening. In my reading, support is an activity
rather than a statement. That activity is missing. I even ran into
/usr-merge fallout in 2022 myself. The statement is clear enough and
Guillem's warning is clearly not helping the state of affairs.

> The difficulty is that Guillem's warning kind of refers to both.

Yeah, I see how you get there. It is fully in line with the confusion I
see elsewhere.

Let us try to turn this upside down: How can Guillem express his
dissatisfaction with the current process in a way that does not cause
harm? Guillem has to deal with quite a number of /usr-merge-caused bugs.
Many of them lack patches and/or are duplicating existing ones. In cases
patches were posted (e.g. dpkg-shlibdeps), Guillem has included them.

Part of the answer would have been talking to the ctte at the time the
decision was made. It's sad that he opted for not doing that.

Helmut

Bug#1001484: sfepy: (autopkgtest) needs update for python3.10: Sequence' from 'collections' is removed

[Stefano Rivera]

Control: tag -1 + pending

I see a commit fixing this in git, just waiting to be uploaded.
https://salsa.debian.org/science-team/sfepy/-/commit/f6a4f8d2435e8406a629a75ee89891a24631233a

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1008202: usrmerge: conversion fails in Docker container (due to overlayfs)

[Ansgar]

On Thu, 24 Mar 2022 11:13:02 +0100 Ansgar wrote:
> | FATAL ERROR:
> | Can't rename /bin: Invalid cross-device link

> I think we need to deal with this in some way. A possible solution
> might also be to skip conversion in containers for now (as Docker
> containers should probably not be upgraded from one Debian release to
> a newer).

OpenSUSE seems to have chosen this solution as well. Quoting from [1]:

+---
| Upgrading layers of containers does not work (Bug 1187027).
| This is due to overlayfs. There is no workaround. Please re-deploy
| the base image instead.
+---[ https://en.opensuse.org/openSUSE:Usr_merge#State_in_openSUSE ]

The relevant change in their conversion program:

+---
| 45 +if [ "$(stat -f -c %T "${ROOT:-/}")" = "overlayfs" ]; then
| 46 +echo "UsrMerge conversion does not work on overlayfs"
| 47 +exit 1
| 48 +fi
+---[ https://build.opensuse.org/request/show/898435 ]

For Debian, I think usrmerge.postinst should skip conversion in case
overlayfs is used (without error, but possibly a warning message). With
this bookworm containers should be usable, but an upgrade of
containers[1] that still use the old filesystem layout from bookworm to
trixie would not be supported / would require the admin to handle
conversion to merged-/usr in some other way.

Ansgar

  [1]: Or other environments that might use overlayfs.

Bug#944785: pufferfish now builds

[Michael Crusoe]

That's great news, please go for it!

--
Michael R. Crusoe ; he/him
https://orcid.org/-0002-2961-9670
CWL Project Leader, Software Freedom Conservancy, Common Workflow Language
project
Promovendus, VU Amsterdam, Computer Systems & Bioinformatics
Project Leader FAIR Service Architecture in ELIXIR-NL, DTL Projects

On Thu, Mar 24, 2022, 18:38 Andrius Merkys  wrote:

> Hello,
>
> I have stumbled upon pufferfish in Salsa which used to FTBFS. I patched
> its build system a bit and now it builds successfully. If it is OK with
> you, I can continue finalizing the package.
>
> Best,
> Andrius
>

Bug#1000788: (no subject)

[Mike Brodbelt]

Echoing previous comment. This bug was to enable CR3 support, which 
requires BMFF enablement, no just a version bump.


From https://exiv2.org/whatsnew.html

 * Support for bmff files (HEIC, HEIF, AVIF, CR3, JXL/bmff)

This is arguably the most important new feature in the new version of 
exiv2, so enabling it in the build is required to support any of these 
file formats.

Bug#944785: pufferfish now builds

[Andrius Merkys]

Hello,

I have stumbled upon pufferfish in Salsa which used to FTBFS. I patched
its build system a bit and now it builds successfully. If it is OK with
you, I can continue finalizing the package.

Best,
Andrius

Bug#994388: dpkg currently warning about merged-usr systems

[Russ Allbery]

Helmut Grohne  writes:

> What is supported is a bit subjective I fear. At this point, neither
> merged-/usr nor unmerged-/usr is supported well. Both are broken in one
> way or another and nobody steps up to fix the mess. In particular, the
> dpkg maintainer does not support merged-/usr in dpkg (which is his
> constitutional right as long as he does not block reasonable patches),
> but neither does anyone else.

I think this accidentally confuses the related states of "unsupported" and
"buggy."  We know that merged-/usr is buggy, in that one can construct a
set of package operations that leave the system in an invalid state.  We
have a project disagreement over how serious those bugs are.  No one is
stepping forward to fix those bugs, which is indeed quite unfortunate.  I
personally strongly disagree with the belief that simply because Ubuntu
hasn't seen many instances of this class of bugs while using a package set
where people have not moved files between packages and out of /lib and
/bin very much if at all, it is acceptable to leave dpkg in that buggy
state.

However, I think this is similar to many other disagreements over the
severity of bugs, particularly ones that are hard to fix.  It doesn't
really imply that this configuration is *unsupported*, which would mean
that if someone had a system in that state and reported a problem we would
say that we couldn't help them because their system is not in a supported
configuration.  This is not the case; merged-/usr is supported in that
sense.  Guillem may not be willing to support the user in that case but
other people most certainly would.

That said, I personally am disappointed that the folks who have been
pushing merged-/usr forward are willing to leave dpkg in a known-buggy
state without attempting to patch it to fix the remaining issues.  I
realize that there are various obstacles in successfully doing that, not
all of which are technical, but I want to believe that Debian is the sort
of project that will do the hard work (both technical and social) to fix
edge cases and maintain a high level of consistency and correctness.

-- 
Russ Allbery (r...@debian.org)  

Bug#1008225: dolfin: autopkgtest failure: timeout

[Sebastian Ramacher]

Source: dolfin
Version: 2019.2.0~git20210928.3eacdb4-3
Severity: serious
Tags: sid bookworm

dolfin's autopkgtest fail with a timeout:

python/demo/test.py::test_demos[path45-demo_meshview-3D1D.py] autopkgtest 
[15:52:40]: ERROR: timed out on command "su -s /bin/bash debci -c set -e; 
export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true;  . ~/.profile 
>/dev/null 2>&1 || true; 
buildtree="/tmp/autopkgtest-lxc.1ddrdd8w/downtmp/build.bBU/src"; mkdir -p -m 
1777 -- 
"/tmp/autopkgtest-lxc.1ddrdd8w/downtmp/test-dolfin-python-demo-artifacts"; 
export 
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.1ddrdd8w/downtmp/test-dolfin-python-demo-artifacts";
 export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 
"/tmp/autopkgtest-lxc.1ddrdd8w/downtmp/autopkgtest_tmp"; export 
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.1ddrdd8w/downtmp/autopkgtest_tmp"; export 
ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; export 
LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=56; unset LANGUAGE LC_CTYPE 
LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME 
LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL;rm -f 
/tmp/autopkgtest_script_pid; set -C; echo $$ > /tmp/autopkgtest_script_pid; set 
+C; trap "rm -f /tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd 
"$buildtree"; chmod +x 
/tmp/autopkgtest-lxc.1ddrdd8w/downtmp/build.bBU/src/debian/tests/test-dolfin-python-demo;
 touch /tmp/autopkgtest-lxc.1ddrdd8w/downtmp/test-dolfin-python-demo-stdout 
/tmp/autopkgtest-lxc.1ddrdd8w/downtmp/test-dolfin-python-demo-stderr; 
/tmp/autopkgtest-lxc.1ddrdd8w/downtmp/build.bBU/src/debian/tests/test-dolfin-python-demo
 2> >(tee -a 
/tmp/autopkgtest-lxc.1ddrdd8w/downtmp/test-dolfin-python-demo-stderr >&2) > 
>(tee -a 
/tmp/autopkgtest-lxc.1ddrdd8w/downtmp/test-dolfin-python-demo-stdout);" (kind: 
test)
autopkgtest [15:52:40]: test test-dolfin-python-demo: ---]
autopkgtest [15:52:40]: test test-dolfin-python-demo:  - - - - - - - - - - 
results - - - - - - - - - -
test-dolfin-python-demo FAIL timed out


See
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dolfin/20301057/log.gz

Cheers
-- 
Sebastian Ramacher

Bug#1008224: mate-screenshot: area grab includes selection overlay

[Mihai Hanor]

Package: mate-utils
Version: 1.26.0-1
Severity: normal

Dear Maintainer,

When mate-screenshot is used with the option Select area to grab (when
using Shift+Print Screen), the screenshot includes the overlay drawn when
selecting the area. This is perfectly visible when using marco window with
picom (any variety: GLX, Hybrid, Xrender), where the selection overlay in
current version of mate-tweak (Installed: 22.04.4-1) is greenish. I'm
opening the bug on mate-utils because I think mate-screenshot should handle
this situation better. I don't think mate-tweak should do anything
different - the overlay looks nice as it currently is.

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

Kernel: Linux 5.16.0-4-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mate-utils depends on:
ii  libatk1.0-0   2.36.0-3
ii  libc6 2.33-7
ii  libcairo2 1.16.0-5
ii  libcanberra-gtk3-00.30-8
ii  libcanberra0  0.30-8
ii  libgdk-pixbuf-2.0-0   2.42.6+dfsg-2
ii  libglib2.0-0  2.70.4-1
ii  libgtk-3-03.24.33-1
ii  libgtop-2.0-112.40.0-2
ii  libice6   2:1.0.10-1
ii  libmate-panel-applet-4-1  1.26.2-1
ii  libmatedict6  1.26.0-1
ii  libpango-1.0-01.50.4+ds-1
ii  libpangocairo-1.0-0   1.50.4+ds-1
ii  libsm62:1.2.3-1
ii  libudisks2-0  2.9.4-1
ii  libx11-6  2:1.7.2-2+b1
ii  libxext6  2:1.3.4-1
ii  mate-desktop-common   1.26.0-1
ii  mate-utils-common 1.26.0-1
ii  zlib1g1:1.2.11.dfsg-2

mate-utils recommends no packages.

mate-utils suggests no packages.

-- no debconf information

Bug#1008222: bind unicast_src x.y.z.w failed 99 - Cannot assign requested address

[Vincent Bernat]

severity -1 important
fixed -1 1:2.2.7-1~bpo11+1
thanks

 ❦ 24 March 2022 17:24 +01, Arturo Borrero Gonzalez:

> This exact same setup was previously working, and actually, the next version 
> works just fine.
> Not sure if this has anything to do with the kernel version warning at the 
> beginning.
>
> In summary:
>
> | keepalived version  | Debian   | Works? |
> | |--||
> | 1:2.0.10-1  | buster   | yes|
> | 1:2.1.5-0.2+deb11u1 | bullseye | no |
> | 1:2.2.7-1~bpo11+1   | bullseye-bpo | yes|
>
> I'm opeining this bug report mostly so others can find it.
> Raelly appreciated the bpo package is ready to use.

Glad that the backport solves this issue. Unfortunately, I don't think
it's worth reporting the issue upstream as they don't like us lagging so
many versions late. I have used it myself with unicast_src, so it is not
broken for everyone.

After looking twice, I notice the VIP is in the same subnet as the peer.
If you don't have any other address on the subnet, I don't see how this
could work. If you have, maybe it would be better to use a /32 for the
VIP.
-- 
If one cannot enjoy reading a book over and over again, there is no use
in reading it at all.
-- Oscar Wilde

Bug#1007222: transition: onetbb

[Sebastian Ramacher]

On 2022-03-24 11:43:49, M. Zhou wrote:
> On Thu, 2022-03-24 at 13:12 +0100, Paul Gevers wrote:
> > > 
> > > "I heard from archlinux" is not good enough.  I sent you email about 
> > > this without getting a reply, then filed #1006920, without getting a 
> > > reply, now this incomplete proposal. you may want to look at all the 
> > > build rdeps for libtbb2-dev in Ubuntu to get an overview what at least 
> > > breaks:
> 
> Sorry for the late response but I think that's what usually happens when
> the maintainer is occupied by research and studies. I would not have
> submitted this incomplete transition slot if I did not hear so much
> request.
> 
> I think the solution for allowing the co-existence of tbb and onetbb
> is not the best. Because tbb will not have upstream support in the
> future due to deprecation.
> 
> > 
> > > this breaks everything immediately because of the conflicting libtbb2 
> > > and libtbb12. Please fix this first.
> > 
> > Can you please respond to these remarks? They raise valid points for us.
> 
> libtbb2 and libtbb12 contains some common files hence the conflict.
> I'd rather wait for all the reverse deps to be ready for this
> transition, compared to going through NEW again due to binary
> package change.

This makes the transition and upgrades more painful than necessary. The
files shared between both packages are actually shared libraries with
their own SONAME that did not change. Why are the contained in libtbb12
if they do not follow the same version as libtbb itself?

Cheers
-- 
Sebastian Ramacher

Bug#1005767: mirror submission for archive.debian.petiak.ir

[Julien Cristau]

Hi,

Thanks for mirroring Debian.  Our scripts noticed some small issues with
the mirror, before we can add it:

o The tracefile at
  http://archive.debian.petiak.ir/debian/project/trace/archive.debian.petiak.ir
  is missing some required information.

  We expect at least the Maintainer and Upstream-mirror values to be filled in,
  and your tracefile is missing one or both of them.

o we recommend mirrors not sync directly from service aliases such as
  ftp..debian.org (only http is guaranteed to be available at
  ftp..d.o sites).  Maybe change your config to sync from
  the site currently backing the ftp..debian.org service you sync
  from?

Feel free to resubmit once at least the second issue is addressed.

Thanks,
Julien

On Mon, Feb 14, 2022 at 04:10:58PM +, Arash Sadeghi wrote:
> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: archive.debian.petiak.ir
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: Arash Sadeghi 
> Country: IR Iran, Islamic Republic of
> Location: Tehran
> Sponsor: Petiak https://www.petiak.com
> Comment: We have a 10G connection to serve requests.
>  We're currently official country mirror for Ubuntu and would be more than 
> happy if we could be a push mirroring client and become Debian's official and 
> country mirror for Iran which currently there's none.
>  Hope to hear from you soon.
>  Greeting from Tehran
> 
> 
> 
> 
> Trace Url: http://archive.debian.petiak.ir/debian/project/trace/
> Trace Url: 
> http://archive.debian.petiak.ir/debian/project/trace/ftp-master.debian.org
> Trace Url: 
> http://archive.debian.petiak.ir/debian/project/trace/archive.debian.petiak.ir
> 

Bug#1008223: RM: libgoogle-glog-doc -- NBS; documentation no longer provided

[GCS]

Package: ftp.debian.org
Severity: normal

Hi FTP Masters,

src:google-glog no longer contains development documentation for the
source. Hence I had to drop libgoogle-glog-doc which now prevents
migration to testing. Please remove reference to this arch:all binary
package.

Thanks,
Laszlo/GCS

Bug#1006611: mirror submission for mirrors.neusoft.edu.cn

[Julien Cristau]

Hi,

One thing our scripts noticed:

o The nameservers for mirrors.neusoft.edu.cn are all in the same /24 network.  
For
  reliability we recommend having nameservers in more than one location.

Cheers,
Julien

On Mon, Feb 28, 2022 at 04:30:23PM +, Fulong Sun wrote:
> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: mirrors.neusoft.edu.cn
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: Fulong Sun 
> Country: CN China
> Location: Dalian
> Sponsor: Dalian Neusoft University of Information (大连东软信息学院) 
> http://www.neusoft.edu.cn
> Comment: Dalian Neusoft University of Information (大连东软信息学院)
> 
> 
> 
> 
> Trace Url: http://mirrors.neusoft.edu.cn/debian/project/trace/
> Trace Url: 
> http://mirrors.neusoft.edu.cn/debian/project/trace/ftp-master.debian.org
> Trace Url: 
> http://mirrors.neusoft.edu.cn/debian/project/trace/mirrors.neusoft.edu.cn
> 

Bug#994388: dpkg currently warning about merged-usr systems

[Sean Whitton]

Hello Helmut,

On Thu 24 Mar 2022 at 02:49pm +01, Helmut Grohne wrote:

> Hi,
>
> On Thu, Mar 24, 2022 at 09:12:14AM +0100, Ansgar wrote:
>> Maybe it should be changed into a warning that non-merged-/usr systems
>> will not be supported in the future.  The `dpkg-fsys-usrunmess` program
>> should probably also include a warning that it will convert the system
>> into a state no longer supported by Debian in the future.
>
> What is supported is a bit subjective I fear. At this point, neither
> merged-/usr nor unmerged-/usr is supported well. Both are broken in one
> way or another and nobody steps up to fix the mess.

We should distinguish two senses of "supported".

There is the sense of what Debian-the-project supports.  That is
specified in the TC decision.  That is not subjective.

There is the sense of what Debian-the-archive-contents supports.  That
is indeed subjective just as you explain.  There exists disagreement
about whether the Ubuntu approach to implementing merged-/usr is adequate.

The difficulty is that Guillem's warning kind of refers to both.

-- 
Sean Whitton

Bug#1008222: bind unicast_src x.y.z.w failed 99 - Cannot assign requested address

[Arturo Borrero Gonzalez]

Package: keepalived
Version: 1:2.1.5-0.2+deb11u1
Severity: grave
Tags: upstream
X-Debbugs-Cc: art...@debian.org

Dear maintainer,

thanks for your work with this package, really appreciated.

Today I tried upgrading a Debian 10 Buster system to Debian 11 Bullseye.

Keepalived refused to work with a previously working setup, error message:

=== 8< ===
aborrero@cloudgw2001-dev:~ $ sudo /usr/sbin/keepalived -lD --dont-fork
Thu Mar 24 15:59:24 2022: Starting Keepalived v2.1.5 (07/13,2020)
Thu Mar 24 15:59:24 2022: WARNING - keepalived was build for newer Linux 
5.10.70, running on Linux 5.10.0-12-amd64 #1 SMP Debian 5.10.103-1 (2022-03-07)
Thu Mar 24 15:59:24 2022: Command line: '/usr/sbin/keepalived' '-lD' 
'--dont-fork'
Thu Mar 24 15:59:24 2022: Opening file '/etc/keepalived/keepalived.conf'.
Thu Mar 24 15:59:24 2022: NOTICE: setting config option max_auto_priority 
should result in better keepalived performance
Thu Mar 24 15:59:24 2022: Starting VRRP child process, pid=17238
Thu Mar 24 15:59:24 2022: Registering Kernel netlink reflector
Thu Mar 24 15:59:24 2022: Registering Kernel netlink command channel
Thu Mar 24 15:59:24 2022: Opening file '/etc/keepalived/keepalived.conf'.
Thu Mar 24 15:59:24 2022: (/etc/keepalived/keepalived.conf: Line 25) Warning - 
cannot track route 185.15.57.0/29 with no interface specified, not tracking
Thu Mar 24 15:59:24 2022: (/etc/keepalived/keepalived.conf: Line 26) Warning - 
cannot track route 172.16.128.0/24 with no interface specified, not tracking
Thu Mar 24 15:59:24 2022: Assigned address 208.80.153.188 for interface 
eno2.2120
Thu Mar 24 15:59:24 2022: Assigned address fe80::32e1:71ff:fe60:e97d for 
interface eno2.2120
Thu Mar 24 15:59:24 2022: Registering gratuitous ARP shared channel
Thu Mar 24 15:59:24 2022: (VRRP1) removing Virtual Routes
Thu Mar 24 15:59:24 2022: (VRRP1) removing VIPs.
Thu Mar 24 15:59:24 2022: bind unicast_src 208.80.153.188 failed 99 - Cannot 
assign requested address
Thu Mar 24 15:59:24 2022: (VRRP1): entering FAULT state (src address not 
configured)
Thu Mar 24 15:59:24 2022: (VRRP1) Entering FAULT STATE
Thu Mar 24 15:59:24 2022: (VRRP1) removing Virtual Routes
Thu Mar 24 15:59:24 2022: VRRP sockpool: [ifindex(  8), family(IPv4), 
proto(112), fd(-1,-1), unicast, address(208.80.153.188)]
^CThu Mar 24 16:00:05 2022: Stopping
Thu Mar 24 16:00:06 2022: Stopped - used 0.002007 user time, 0.00 system 
time
Thu Mar 24 16:00:06 2022: CPU usage (self/children) user: 0.008240/0.003615 
system: 0.004120/0.00
Thu Mar 24 16:00:06 2022: Stopped Keepalived v2.1.5 (07/13,2020)
=== 8< ===

The config file is pretty straigt forward:

=== 8< ===
aborrero@cloudgw2001-dev:~ $ cat /etc/keepalived/keepalived.conf
global_defs {
}

vrrp_instance VRRP1 {
  state BACKUP
  interface eno2.2120
  virtual_router_id 52
  nopreempt
  priority 6
  advert_int 1
  authentication {
auth_type PASS
auth_pass 
  }
  track_interface {
eno2.2107
  }
  virtual_routes {
185.15.57.0/29 table 10 nexthop via 185.15.57.10 dev eno2.2107 onlink
172.16.128.0/24 table 10 nexthop via 185.15.57.10 dev eno2.2107 onlink
  }
  virtual_ipaddress {
185.15.57.9/30 dev eno2.2107
208.80.153.190/29 dev eno2.2120
  }
  unicast_peer {
208.80.153.189
  }
}
=== 8< ===

This exact same setup was previously working, and actually, the next version 
works just fine.
Not sure if this has anything to do with the kernel version warning at the 
beginning.

In summary:

| keepalived version  | Debian   | Works? |
| |--||
| 1:2.0.10-1  | buster   | yes|
| 1:2.1.5-0.2+deb11u1 | bullseye | no |
| 1:2.2.7-1~bpo11+1   | bullseye-bpo | yes|

I'm opeining this bug report mostly so others can find it.
Raelly appreciated the bpo package is ready to use.

regards.

Bug#1006621: ITP: boofcv -- Real-time computer vision library

[Peter A]

  Hopefully a 1000 projects don't need to be updated from Gradle 4 to
Gradle 7!


> Debian does not do out-of-git builds (.git directory is removed from
> sources prior to build), thus I guess this plugin would not be of much
> use (but I may be wrong).
>

Still required since it creates a BoofVersion.java file that's needed. If
it can't find Git information it fills in that field with blank or unknown.

Cheers,
- Peter

Bug#1007222: transition: onetbb

[M. Zhou]

On Thu, 2022-03-24 at 13:12 +0100, Paul Gevers wrote:
> > 
> > "I heard from archlinux" is not good enough.  I sent you email about 
> > this without getting a reply, then filed #1006920, without getting a 
> > reply, now this incomplete proposal. you may want to look at all the 
> > build rdeps for libtbb2-dev in Ubuntu to get an overview what at least 
> > breaks:

Sorry for the late response but I think that's what usually happens when
the maintainer is occupied by research and studies. I would not have
submitted this incomplete transition slot if I did not hear so much
request.

I think the solution for allowing the co-existence of tbb and onetbb
is not the best. Because tbb will not have upstream support in the
future due to deprecation.

> 
> > this breaks everything immediately because of the conflicting libtbb2 
> > and libtbb12. Please fix this first.
> 
> Can you please respond to these remarks? They raise valid points for us.

libtbb2 and libtbb12 contains some common files hence the conflict.
I'd rather wait for all the reverse deps to be ready for this
transition, compared to going through NEW again due to binary
package change.

I've started rebuilding the reverse dependencies and filing bugs,
will get back to you soon.

Bug#1006621: ITP: boofcv -- Real-time computer vision library

[Andrius Merkys]

Hi Peter,

Thanks for prompt reply.

On 2022-03-24 17:16, Peter A wrote:
> Instead of updating the "gradle" command could we just install a new
> "gradle7" command that points to Gradle 7 instead? I don't think Gradle
> is very backwards compatible so that might be the easiest solution.

This would not help, I am afraid. Point with Gradle is that it needs
itself to build newer versions of Gradle (circular dependency on
itself), thus iteratively updating Gradle seems to be the only way to
have newer Gradle in Debian.

> For Jars that BoofCV downloads, It doesn't download anything outside of
> Gradle. It uses a Gradle plugin i created called gversion to
> automatically generate version info and a set of tools to do other auto
> generation tasks:
> 
> https://plugins.gradle.org/plugin/com.peterabeles.gversion
> 

Debian does not do out-of-git builds (.git directory is removed from
sources prior to build), thus I guess this plugin would not be of much
use (but I may be wrong). Nevertheless Debian precisely tracks source
versions, thus version string could be injected via other means.

> https://github.com/lessthanoptimal/Auto64Fto32F
> 

This one I have already packaged for Debian, so the packaged JAR could
be used.

> Once the Gradle issue gets resolved we could then start adding these
> dependencies.

Sure.

Best wishes,
Andrius

Bug#1006621: ITP: boofcv -- Real-time computer vision library

[Peter A]

Instead of updating the "gradle" command could we just install a new
"gradle7" command that points to Gradle 7 instead? I don't think Gradle is
very backwards compatible so that might be the easiest solution.

For Jars that BoofCV downloads, It doesn't download anything outside of
Gradle. It uses a Gradle plugin i created called gversion to
automatically generate version info and a set of tools to do other auto
generation tasks:

https://plugins.gradle.org/plugin/com.peterabeles.gversion
https://github.com/lessthanoptimal/Auto64Fto32F

Once the Gradle issue gets resolved we could then start adding these
dependencies.

Cheers,
- Peter




On Thu, Mar 24, 2022 at 5:06 AM Andrius Merkys  wrote:

> Dear Peter and Dima,
>
> Sorry for the delay. Somehow I did not receive any mails sent to
> 1006...@bugs.debian.org (will subscribe), thus I only now noticed your
> conversation after accidentally revisiting the bug page.
>
> Good to meet you too, Peter!
>
> First of all, regarding Cephis, my original reason to package BoofCV. It
> depends on io, feature and visualize modules of BoofCV v0.17. AFAIK,
> these should be static image analysis tools, thus stripping away more
> complicated video and webcam support should make things much easier for
> now. Of course, in the long run it would be nice to support video and
> webcam parts of BoofCV in Debian as well.
>
> Regarding Gradle. Debian has 4.4.1 now and updating it is complicated.
> It would be nice to ask its maintainers in Debian to understand what are
> the current blockers. Gradle wrapper cannot be used as downloads in the
> build time are not allowed in Debian. Even more generally, Debian builds
> can only rely on software which is built from source on Debian build
> machines.
>
> For now I see upgrading Gradle in Debian as the best solution to the
> build issue. Simplifying/changing the build system is a viable solution
> too, but I believe this would need much work and add maintenance burden
> on Peter. Discussion in [1] gives me some hope Gradle will be updated
> soon. I think it is worth pinging its participants.
>
> Peter, you mention BoofCV build system downloading some JARs. Maybe we
> could build these JARs in Debian as separate packages and use them in
> BoofCV build? If Gradle blocker goes away, these might be the next
> blockers.
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926714
>
> Best wishes,
> Andrius
>


-- 
"Now, now my good man, this is no time for making enemies."— Voltaire
(1694-1778), on his deathbed in response to a priest asking that he
renounce Satan.

Bug#1008221: ITP: r-bioc-tmixclust -- mixed-effects gene-expression time-series analysis

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-tmixclust -- mixed-effects gene-expression time-series 
analysis
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-tmixclust
  Version : 1.16.0
  Upstream Author : Monica Golumbeanu 
* URL : https://bioconductor.org/packages/TMixClust/
* License : GPL-2+
  Programming Lang: GNU R
  Description : mixed-effects gene-expression time-series analysis
 To investigate how a drug effects a tissue sample over time,
 one commonly determines the transcriptomes at different time points
 to distinguish genes that react early from those that react late,
 which are steadily going up or down, which are oscillating, and
 what molecular process are those subsets of genes contributing to.
 .
 Time Series Clustering of Gene Expression with Gaussian
 Mixed-Effects Models and Smoothing Splines Implementation of a
 clustering method for time series gene expression data based on
 mixed-effects models with Gaussian variables and non-parametric
 cubic splines estimation. The method can robustly account for the
 high levels of noise present in typical gene expression time
 series datasets.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-tmixclust

Bug#1008220: flexbar 3.5.0-4 FTBFS against libtbb-dev 2021.5.0-7

[M. Zhou]

Source: flexbar
Version: 3.5.0-4
Severity: important

Dear maintainer,

There is a major API change from tbb to onetbb, please refer
https://oneapi-src.github.io/oneTBB/main/tbb_userguide/Migration_Guide.html
for more details.

make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
[ 50%] Building CXX object src/CMakeFiles/flexbar.dir/Flexbar.cpp.o 
   
cd /<>/obj-x86_64-linux-gnu/src && /usr/bin/c++ 
-DSEQAN_HAS_BZIP2=1 -DSEQAN_HAS_ZLIB=1 -
I/<>/include -g -O2 -ffile-pre
fix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -
std=c++14 -MD -MT src/CMak
eFiles/flexbar.dir/Flexbar.cpp.o -MF CMakeFiles/flexbar.dir/Flexbar.cpp.o.d -o 
CMakeFiles/flexbar.dir/Flexbar.cpp.o -c
/<>/src/Flex
bar.cpp 
   
In file included from /<>/src/Flexbar.cpp:24:
/<>/src/Flexbar.h:15:10: fatal error: tbb/pipeline.h: No such file 
or directory
   15 | #include 
  |  ^~~~   
compilation terminated. 
make[3]: *** [src/CMakeFiles/flexbar.dir/build.make:79: 
src/CMakeFiles/flexbar.dir/Flexbar.cpp.o] Error 1
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'  
 

Bug#1007103: Further information

[Ted Felix]

  OP informs me that he tracked the problem down to the ZynAddSubFX 
DSSI plugin.  He switched to the ZynAddSubFX standalone app and all is 
well for him.


  This bug can be closed for rosegarden.

Bug#1008134: uftrace: Build fail with experimental armhf

[paul cannon]

On Wed, Mar 23, 2022 at 10:36:46AM +0900, Nobuhiro Iwamatsu wrote:
> Build fails with experimental armhf. 
> 
> https://buildd.debian.org/status/fetch.php?pkg=uftrace=armhf=0.11-3=1647358997=0
> 
> I attached a patch what revice this issue.
> Please check and apply it.

This is great. Thank you, I'll apply it to the 0.11-4 release I'm
working on, and I'll pass it upstream.

Paul

Bug#1003713: bullseye-pu: package telegram-desktop/3.1.1+ds-1~deb11u2

[Nicholas Guriev]

Hello!

On Sat, 19 Mar 2022 17:28:49 +0100 Julien Cristau  wrote:
> Unfortunate, but I guess we don't have much of a choice, so go ahead.

Okay. I've uploaded the telegram-desktop package and its build
dependency, libtgowt, to proposed-updates (bullseye).

> How often do such incompatible changes happen, historically?

This was the first such incompatible change since I've been maintaining
the package for 5 years.

Although, Telegram often implements new features which can't be
displayed in old clients They show "please update" message instead. But
most of the features weren't affecting ability to connect to servers
until 3.1.1 version.



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

Bug#1008189: meson: gnome module incorrectly requires gtk4-update-icon-cache

[Jeremy Bicha]

Control: tags -1 +ftbfs
Control: affects -1 src:gnome-contacts
Control: affects -1 src:gtksourceview5

On Thu, Mar 24, 2022 at 10:13 AM Jussi Pakkanen  wrote:
> This has already been tagged for the .1 release:
>
> https://github.com/mesonbuild/meson/milestone/79?closed=1
>
> Is that sufficient or do you need an interim distropatch upload?

I think it's only a fairly small number of Debian apps affected. I can
manually add the extra Build-Depends if I need to do a quicker upload
of affected packages.

Thank you,
Jeremy Bicha

Bug#1008219: interimap: please compare against contemprorary competitors

[Jonas Smedegaard]

Package: interimap
Version: 0.5.7-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream website has a page comaring against OfflineIMAP:
https://guilhem.org/interimap/benchmark.html

OfflineIMAP is arguably outdated, however.  Anarcat documents at
https://anarc.at/blog/2021-11-21-mbsync-vs-offlineimap/ moving to mbsync
which nowadays seem the most commonly recommended tool.

Would be interesting to have the benchmark page updated to cover more
contemporary competitors like mbsync, to show how well this
perl-based tool fares against tools written in compiled languages.

Would also be interesting to include less popular competitor that make
use of similar techniques - most notable as I am aware is runt that also
uses IMAP extension QRESYNC: https://github.com/mordak/runt


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmI8gQ8ACgkQLHwxRsGg
ASH+FRAAgEyX5Ac7AYPGRsQ40akklczHEpEMQ7n9I4RJ/33MtwZ74fV3GK04HF9H
U+kioQzy4lRz+stD89+LxoWZOKBBPmd/VZRlfaAkTvah+KzOshNhyGXssb3PhPNW
fd5PVm9wyIX4eT1V4eCKQWhRNcwRNWe6xkp4+aPi20SCSMtXP3k/6ffJwUEWNxwB
L0D11pxyKilq9NpxoJ3dptXoIh6dTfpwtHRiRZyUrBeBhyZM5acmX7OzRqEBI55j
6U2w3kfGZDLu2wgUODSAEdzW5p2E03iQX+cpJlHRjerUUKh+MKk3r1xUVyrLjWFm
69Na4zs/tPtFj1eMs3ESorJ41n71JmXlFGIFbtmDI170qt6GGAq+ZkLuJGxzkZiO
UoiEPkRpRKuXj1vF6CrPRKoQJ9xRoSBrNOu+Hat7tB7S+VlK89jDNctx0EyjV7bt
mvfoZ49Lna3hziBkkO0f5iZlP4DlkaFdkeVvSxSbJS0Zl8y6fMsR/vLMQtsqLEOa
F0trR1+qUEfQwn3mqskQZFHWtBdlC7eQdGk6uUABnaz+QWX3wSTes5to2jDgxp67
6J/aYPKKo3iYTc8bXvgw4lCJESAyBGcpVJqknu90IUq6PwZgcuWLB5IbeEti/hRW
nV5PRPdnnF7YHd2H3ZQnRGNyaCcbEB2or9MZxcOEIJmYa3ByuMY=
=r1Up
-END PGP SIGNATURE-

Bug#1008218: ITP: r-bioc-spem -- S-system parameter estimation method

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-spem -- S-system parameter estimation method
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-spem
  Version : 1.34.0
  Upstream Author : Xinyi YANG (Developer)
* URL : https://bioconductor.org/packages/SPEM/
* License : GPL-2
  Programming Lang: GNU R
  Description : S-system parameter estimation method
 This package can optimize the parameter in S-system models
 given time series data

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-spem

Bug#1001779: It is a request

[Geert Stappers]

On Thu, Mar 24, 2022 at 12:23:16AM -0700, lepapareil wrote:
> ... our bug seems to be on hold for almost 3 months ?

No, nothing is on hold.  An request for packaging
is a request for packaging.


> Thks for your help :)

Expressing expectations is fine,
insisting on ones own expectation doesn't help.


FWIW, I only partly argee with "somebody else should do it",
thing I will do is sponsoring uploads to Debian.

On expressing expectations:  I love to see messages like

  At $URL is hurl dependency foo packaged. What is,
  beside review time, needed to get it uploaded to Debian?



Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1008217: ITP: r-cran-flexclust -- Flexible Cluster Algorithms

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-flexclust -- Flexible Cluster Algorithms
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-flexclust
  Version : 1.4
  Upstream Author : Friedrich Leisch
* URL : https://cran.r-project.org/package=flexclust
* License : GPL-2
  Programming Lang: GNU R
  Description : Flexible Cluster Algorithms
 The main function kcca implements a general framework for
 k-centroids cluster analysis supporting arbitrary distance measures
 and centroid computation. Further cluster methods include hard
 competitive learning, neural gas, and QT clustering. There are
 numerous visualization methods for cluster results (neighborhood
 graphs, convex cluster hulls, barcharts of centroids, ...), and
 bootstrap methods for the analysis of cluster stability.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-flexclust

Bug#994388: dpkg currently warning about merged-usr systems

[Luca Boccassi]

On Thu, 2022-03-24 at 15:06 +0100, Ansgar wrote:
> On Thu, 2022-03-24 at 14:49 +0100, Helmut Grohne wrote:
> > On Thu, Mar 24, 2022 at 09:12:14AM +0100, Ansgar wrote:
> > > Maybe it should be changed into a warning that non-merged-/usr
> > > systems
> > > will not be supported in the future.  The `dpkg-fsys-usrunmess`
> > > program
> > > should probably also include a warning that it will convert the
> > > system
> > > into a state no longer supported by Debian in the future.
> > 
> > What is supported is a bit subjective I fear.
> 
> No, Helmut, it is not. We had that discussion often enough and in this
> bug report you will find the following:
> 
> +---
> > There are currently Debian 11 installations with both the merged-/usr
> > and non-merged-/usr filesystem layouts. All of these installations
> > should successfully upgrade via normal upgrade paths to a merged-/usr
> > Debian 12.  Only after the release of Debian 12 can packages assume
> > that all installations will be merged-/usr.
> +---
> 
> I'm not motivated to pretend the last years did not happen.
> 
> Feel free to start a GR to override the tech ctte if you think that is
> necessary.
> 
> > > Either way, given related questions were already before the tech
> > > ctte
> > > several times it would be nice if this could be decided quickly to
> > > avoid this becoming yet another energy drain (we had several
> > > sufficiently long enough threads about this topic already).
> > 
> > As much as I'd like to see this resolved quickly, I fear it is
> > blocked on the lack of patches supporting merged-/usr.
> 
> Given all new installations have been merged-/usr for years, it seems
> to work sufficiently well for real-world use.

And on top of new installations, old installations of Ubuntu upgrading
to 21.10 and/or the soon-to-be-released 22.04 have been forcifully
migrated too. They are not blocked, unsupported, or broken.

-- 
Kind regards,
Luca Boccassi


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

Bug#1008189: meson: gnome module incorrectly requires gtk4-update-icon-cache

[Jussi Pakkanen]

On Thu, 24 Mar 2022 at 05:03, Jeremy Bicha  wrote:

> Therefore, please cherry-pick this commit:
> https://github.com/mesonbuild/meson/commit/dac212e1bba7

This has already been tagged for the .1 release:

https://github.com/mesonbuild/meson/milestone/79?closed=1

Is that sufficient or do you need an interim distropatch upload?

Bug#1008168: bullseye-pu: package node-url-parse/1.5.3-1+deb11u1

[Moritz Mühlenhoff]

Am Wed, Mar 23, 2022 at 02:25:26PM +0100 schrieb Yadd:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> [ Reason ]
> node-url-parse is vulnerable to an authorization Bypass Through
> User-Controlled (CVE-2022-0686).

If we're doing an update, we could also include a fix for CVE-2022-0691?

Cheers,
Moritz

Bug#994388: dpkg currently warning about merged-usr systems

[Ansgar]

On Thu, 2022-03-24 at 14:49 +0100, Helmut Grohne wrote:
> On Thu, Mar 24, 2022 at 09:12:14AM +0100, Ansgar wrote:
> > Maybe it should be changed into a warning that non-merged-/usr
> > systems
> > will not be supported in the future.  The `dpkg-fsys-usrunmess`
> > program
> > should probably also include a warning that it will convert the
> > system
> > into a state no longer supported by Debian in the future.
> 
> What is supported is a bit subjective I fear.

No, Helmut, it is not. We had that discussion often enough and in this
bug report you will find the following:

+---
| There are currently Debian 11 installations with both the merged-/usr
| and non-merged-/usr filesystem layouts. All of these installations
| should successfully upgrade via normal upgrade paths to a merged-/usr
| Debian 12.  Only after the release of Debian 12 can packages assume
| that all installations will be merged-/usr.
+---

I'm not motivated to pretend the last years did not happen.

Feel free to start a GR to override the tech ctte if you think that is
necessary.

> > Either way, given related questions were already before the tech
> > ctte
> > several times it would be nice if this could be decided quickly to
> > avoid this becoming yet another energy drain (we had several
> > sufficiently long enough threads about this topic already).
> 
> As much as I'd like to see this resolved quickly, I fear it is
> blocked on the lack of patches supporting merged-/usr.

Given all new installations have been merged-/usr for years, it seems
to work sufficiently well for real-world use.

Ansgar

Bug#1007907: ansible-core: cannot install collecions

[Lee Garrett]

Hi,

I can confirm the issue exists, unfortunately there is no simple
solution, as upstream resolvlib does not have a stable API yet. I might
be able to downgrade resolvelib in testing/unstable, as ansible-core
seems to be the only package that currently consumes it. This will
probably get better in the near future when 1.0 is released.

Regards,
Lee

On 23/03/2022 02:31, Daniele Tricoli wrote:
> On Fri, 18 Mar 2022 13:03:13 +0100 Bernhard Bock  wrote:
>> I tried to install a collection and ran into a python stacktrace as included 
>> below.
>> According to my understanding, the Debian version of python3-resolvelib is 
>> too new.
>>
>> For reference, see also 
>> https://github.com/ansible-collections/community.digitalocean/issues/132
>> and https://bugs.gentoo.org/795933
> 
> I can confirm that the workaround of downgrading python3-resolvelib to 0.5.4-1
> solve the issue.
> 

Bug#994388: dpkg currently warning about merged-usr systems

[Helmut Grohne]

Hi,

On Thu, Mar 24, 2022 at 09:12:14AM +0100, Ansgar wrote:
> Maybe it should be changed into a warning that non-merged-/usr systems
> will not be supported in the future.  The `dpkg-fsys-usrunmess` program
> should probably also include a warning that it will convert the system
> into a state no longer supported by Debian in the future.

What is supported is a bit subjective I fear. At this point, neither
merged-/usr nor unmerged-/usr is supported well. Both are broken in one
way or another and nobody steps up to fix the mess. In particular, the
dpkg maintainer does not support merged-/usr in dpkg (which is his
constitutional right as long as he does not block reasonable patches),
but neither does anyone else. As such I find it difficult to disagree
with the content of the warning. I do see how it confuses people. It
definitely does not reach people who could do something about. Rather it
takes users as hostages. This is similar to the case where debianutils
added deprecation warnings. I would not have added such a warning even
if it were fully accurate.

> Either way, given related questions were already before the tech ctte
> several times it would be nice if this could be decided quickly to
> avoid this becoming yet another energy drain (we had several
> sufficiently long enough threads about this topic already).

As much as I'd like to see this resolved quickly, I fear it is blocked
on the lack of patches supporting merged-/usr.

Helmut

Bug#1008195: [Pkg-freeipa-devel] Bug#1008195: marked as done (Joining a domain fails on chrony.service in all scenarios)

[Timo Aaltonen]

Hi, and thanks for tracking it down :)

I guess freeipa upstream should support systemd-timesyncd, if it's "good 
enough". Or freeipa-client package should add a Conflicts for it, for 
now. I'll think about it.



--
t

Bug#1007245: gnome-control-center: Update to 42

[Jeremy Bicha]

The 2 hard blockers to build gnome-control-center 42 are that we need
GTK4 builds of libnma and colord-gtk.

https://salsa.debian.org/utopia-team/libnma/-/merge_requests/2

I intend to update colord-gtk based on how we handle libnma.

There is a softer dependency on the NM VPN plugins being rebuilt for
GTK4. Softer because gnome-control-center will build without them but
it would still be an annoying regression.

Thank you,
Jeremy Bicha

Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

[Adam D. Barratt]

On Wed, 2022-03-23 at 22:38 +0100, Sebastian Andrzej Siewior wrote:
> On 2022-03-23 17:40:59 [+], Adam D. Barratt wrote:
> > Right, let's have another go at this then:
> > 
> > "
> > OpenSSL signature algorithm check tightening
> > =
> > 
> > The OpenSSL update provided in this point release includes a
> > change to ensure that the requested signature algorithm is
> > supported by the active security level.
> > 
> > Although this will not affect most use-cases, it could lead to
> > error messages being generated if a non-supported algorithm is
> > requested - for example, use of RSA+SHA1 signatures with the
> > default
> > security level of 2.
> > 
> > In such cases, the security level will need to be explicitly
> > lowered, either for individual requests or more globally. This
> > may require changes to the configuration of aplications. For
> > OpenSSL itself, per-request lowering can be achieved using a
> > command-line option such as
> > 
> > -cipher "ALL:@SECLEVEL=1"
> > 
> > with the relevant system-level configuration being found in
> > /etc/ssl/openssl.cnf
> > "
> > 
> > Is that any better? Further suggestions welcome, but I'm trying not
> > to
> > make it longer than the rest of the text combined. :-)
> 
> This good Adam, thank you. I have nothing to add.
> 

Thanks.

I've added that text to the announcement for the buster point release.
If anyone has any changes, please yell ASAP.

Regards,

Adam

Bug#1008216: clickhouse: Multiple CVEs in clickhouse - heap overflows and out of bounds reads in LZ4 compression

[Neil Williams]

Source: clickhouse
Version: 18.16.1+ds-7.2
Severity: important
Tags: security
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerabilities were published for clickhouse.

The vulnerabilities require authentication, but can be triggered by any user 
with read 
permissions. This means the attacker must perform reconnaissance on the 
specific ClickHouse
server target to obtain valid credentials. Any set of credentials would do, 
since even a
user with the lowest privileges can trigger all of the vulnerabilities. By 
triggering the
vulnerabilities, an attacker can crash the ClickHouse server, leak memory 
contents or even
cause remote code execution.

CVE-2021-42387[0]:
| Heap out-of-bounds read in Clickhouse's LZ4 compression codec when
| parsing a malicious query. As part of the LZ4::decompressImpl() loop,
| a 16-bit unsigned user-supplied value ('offset') is read from the
| compressed data. The offset is later used in the length of a copy
| operation, without checking the upper bounds of the source of the copy
| operation.


CVE-2021-42388[1]:
| Heap out-of-bounds read in Clickhouse's LZ4 compression codec when
| parsing a malicious query. As part of the LZ4::decompressImpl() loop,
| a 16-bit unsigned user-supplied value ('offset') is read from the
| compressed data. The offset is later used in the length of a copy
| operation, without checking the lower bounds of the source of the copy
| operation.


CVE-2021-43304[2]:
| Heap buffer overflow in Clickhouse's LZ4 compression codec when
| parsing a malicious query. There is no verification that the copy
| operations in the LZ4::decompressImpl loop and especially the
| arbitrary copy operation wildCopycopy_amount(op, ip,
| copy_end), don#8217;t exceed the destination buffer#8217;s
| limits.


CVE-2021-43305[3]:
| Heap buffer overflow in Clickhouse's LZ4 compression codec when
| parsing a malicious query. There is no verification that the copy
| operations in the LZ4::decompressImpl loop and especially the
| arbitrary copy operation wildCopycopy_amount(op, ip,
| copy_end), don#8217;t exceed the destination buffer#8217;s
| limits. This issue is very similar to CVE-2021-43304, but the
| vulnerable copy operation is in a different wildCopy call.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-42387
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-42387
[1] https://security-tracker.debian.org/tracker/CVE-2021-42388
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-42388
[2] https://security-tracker.debian.org/tracker/CVE-2021-43304
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43304
[3] https://security-tracker.debian.org/tracker/CVE-2021-43305
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43305

Please adjust the affected versions in the BTS as needed.




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

Kernel: Linux 5.16.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
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

Bug#1008215: RFS: jimtcl/0.81+dfsg0-1 [ITA] -- small-footprint implementation of Tcl - shared library

[Bo YU]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: jimtcl
   Version : 0.81+dfsg0-1
   Upstream Author : [fill in name and email of upstream]
 * URL : http://jim.tcl.tk/
 * License : TCL, BSD-2-clause
 * Vcs : https://salsa.debian.org/vimerbf-guest/jimtcl
   Section : devel

The source builds the following binary packages:

  jimsh - small-footprint implementation of Tcl named Jim
  libjim-dev - small-footprint implementation of Tcl - development files
  libjim0.81 - small-footprint implementation of Tcl - shared library

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/j/jimtcl/jimtcl_0.81+dfsg0-1.dsc

Changes since the last upload:

 jimtcl (0.81+dfsg0-1) experimental; urgency=medium
 .
   * Update to new upstream version 0.81
 - Bump libjim SONAME from 0.79 to 0.81
 - Rebase pacthes; drop upstream backports
 - Add debian/watch file
 .
   * Add myself as maintainer (Closes: #993599).

Regards,
-- 
  Bo YU

Bug#1008213: nix: autopkgtest regression on armhf, i386 and ppc64el: not supported on ‘arm-linux’, refusing to evaluate.

[Paul Gevers]

Source: nix
Version: 2.7.0+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of nix the autopkgtest of nix fails in testing when 
that autopkgtest is run with the binary packages of nix from unstable. 
It passes when run with only packages from testing. In tabular form:


   passfail
nixfrom testing2.7.0+dfsg-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=nix

https://ci.debian.net/data/autopkgtest/testing/armhf/n/nix/20297030/log.gz

+ read item
+ eval export NIX_REMOTE=daemon
+ export NIX_REMOTE=daemon
+ read item
+ eval export 
PATH="$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:$PATH"
+ export 
PATH=/root/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

+ read item
+ eval export 
NIX_PATH="nixpkgs=/nix/var/nix/profiles/per-user/$USER/channels/nixpkgs:/nix/var/nix/profiles/per-user/$USER/channels"
+ export 
NIX_PATH=nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs:/nix/var/nix/profiles/per-user/root/channels

+ read item
+ mkdir -p /etc/nix/
+ echo sandbox = false
+ service nix-daemon restart
+ nix-channel --add https://nixos.org/channels/nixpkgs-unstable nixpkgs
+ nix-channel --update
unpacking channels...
+ nix-shell -p nix-du --run nix-du --help 
error: Package ‘shell’ in 
/nix/store/nnkkd8gzr4wn1r3jjcxsjn69gyj5mwf1-nixpkgs/nixpkgs/pkgs/build-support/trivial-builders.nix:73 
is not supported on ‘arm-linux’, refusing to evaluate.


   a) To temporarily allow packages that are unsupported for this 
system, you can use an environment variable

  for a single invocation of the nix tools.

$ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1

Note: For `nix shell`, `nix build`, `nix develop` or any other 
Nix 2.4+

(Flake) command, `--impure` must be passed in order to read this
environment variable.

   b) For `nixos-rebuild` you can set
 { nixpkgs.config.allowUnsupportedSystem = true; }
   in configuration.nix to override this.

   c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix 
command you can add

 { allowUnsupportedSystem = true; }
   to ~/.config/nixpkgs/config.nix.
(use '--show-trace' to show detailed location information)
autopkgtest [07:14:29]: test nix-env-and-shell



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008214: ruby-simplecov: autopkgtest regression: error output changed

[Paul Gevers]

Source: ruby-simplecov
Version: 0.21.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of ruby-simplecov the autopkgtest of ruby-simplecov 
fails in testing when that autopkgtest is run with the binary packages 
of ruby-simplecov from unstable. It passes when run with only packages 
from testing. In tabular form:


   passfail
ruby-simplecov from testing0.21.2-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=ruby-simplecov

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-simplecov/20267102/log.gz


Failures:

  1) return codes inside fixtures/frameworks when running 
testunit_bad.rb behaves like bad tests with default configuration prints 
a message to STDERR
 Failure/Error: expect(@stderr).to 
match(/stopped.+SimpleCov.+previous.+error/i)


   expected 
":85:in 
`require': cannot 
loa...r_ruby/rubygems/core_ext/kernel_require.rb>:85:in 
`require'\n\tfrom testunit_bad.rb:2:in `'\n" to match 
/stopped.+SimpleCov.+previous.+error/i

   Diff:
   @@ -1,3 +1,5 @@
   -/stopped.+SimpleCov.+previous.+error/i

+:85:in 
`require': cannot load such file -- lib/simplecov (LoadError)
   +	from 
:85:in 
`require'

   +from testunit_bad.rb:2:in `'
 Shared Example Group: "bad tests" called from 
./spec/return_codes_spec.rb:66
 # ./spec/return_codes_spec.rb:37:in `block (5 levels) in (required)>'
 # ./spec/return_codes_spec.rb:12:in `block (4 levels) in (required)>'

 # ./spec/return_codes_spec.rb:10:in `chdir'
 # ./spec/return_codes_spec.rb:10:in `block (3 levels) in (required)>'


  2) return codes inside fixtures/frameworks when running 
testunit_bad.rb behaves like bad tests when print_error_status is 
disabled does not print anything to STDERR

 Failure/Error: expect(@stderr).to be_empty
   expected 
`":85:in 
`require': cannot 
loa...r_ruby/rubygems/core_ext/kernel_require.rb>:85:in 
`require'\n\tfrom testunit_bad.rb:2:in `'\n".empty?` to be truthy, 
got false
 Shared Example Group: "bad tests" called from 
./spec/return_codes_spec.rb:66
 # ./spec/return_codes_spec.rb:49:in `block (5 levels) in (required)>'
 # ./spec/return_codes_spec.rb:12:in `block (4 levels) in (required)>'

 # ./spec/return_codes_spec.rb:10:in `chdir'
 # ./spec/return_codes_spec.rb:10:in `block (3 levels) in (required)>'


  3) return codes inside fixtures/frameworks when running rspec_good.rb 
behaves like good tests has a zero exit status

 Failure/Error: expect(@status.exitstatus).to be_zero
   expected `1.zero?` to be truthy, got false
 Shared Example Group: "good tests" called from 
./spec/return_codes_spec.rb:61
 # ./spec/return_codes_spec.rb:22:in `block (4 levels) in (required)>'
 # ./spec/return_codes_spec.rb:12:in `block (4 levels) in (required)>'

 # ./spec/return_codes_spec.rb:10:in `chdir'
 # ./spec/return_codes_spec.rb:10:in `block (3 levels) in (required)>'


  4) return codes inside fixtures/frameworks when running 
testunit_good.rb behaves like good tests has a zero exit status

 Failure/Error: expect(@status.exitstatus).to be_zero
   expected `1.zero?` to be truthy, got false
 Shared Example Group: "good tests" called from 
./spec/return_codes_spec.rb:56
 # ./spec/return_codes_spec.rb:22:in `block (4 levels) in (required)>'
 # ./spec/return_codes_spec.rb:12:in `block (4 levels) in (required)>'

 # ./spec/return_codes_spec.rb:10:in `chdir'
 # ./spec/return_codes_spec.rb:10:in `block (3 levels) in (required)>'


  5) return codes inside fixtures/frameworks when running 
testunit_good.rb behaves like good tests prints nothing to STDERR

 Failure/Error: expect(@stderr).to be_empty
   expected 
`":85:in 
`require': cannot loa..._ruby/rubygems/core_ext/kernel_require.rb>:85:in 
`require'\n\tfrom testunit_good.rb:2:in `'\n".empty?` to be 
truthy, got false
 Shared Example Group: "good tests" called from 
./spec/return_codes_spec.rb:56
 # ./spec/return_codes_spec.rb:26:in `block (4 levels) in (required)>'
 # ./spec/return_codes_spec.rb:12:in `block (4 levels) in (required)>'

 # ./spec/return_codes_spec.rb:10:in `chdir'
 # ./spec/return_codes_spec.rb:10:in `block (3 levels) in (required)>'


  6) return codes inside fixtures/frameworks when running rspec_bad.rb 
behaves like bad tests with default configuration prints a message to STDERR
 Failure/Error: expect(@stderr).to 
match(/stopped.+SimpleCov.+previous.+error/i)


   expected "" to match 

Bug#1008212: openmolcas: autopkgtest regression: SIGABRT

[Paul Gevers]

Source: openmolcas
Version: 22.02-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of openmolcas the autopkgtest of openmolcas fails 
in testing when that autopkgtest is run with the binary packages of 
openmolcas from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
openmolcas from testing22.02-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=openmolcas

https://ci.debian.net/data/autopkgtest/testing/amd64/o/openmolcas/20265826/log.gz

Running test standard: 000... (5%) OK
Running test standard: 001... (10%) Failed! (scf)
Running test standard: 002... (15%) Failed! (scf)
Running test standard: 004... (21%) OK
Running test standard: 005... (26%) OK
Running test standard: 006... (31%) OK
Running test standard: 009... (36%) OK
Running test standard: 010... (42%) OK
Running test standard: 011... (47%) OK
Running test standard: 012... (52%) OK
Running test standard: 014... (57%) OK
Running test standard: 015... (63%) OK
Running test standard: 016... (68%) OK
Running test standard: 019... (73%) OK
Running test standard: 023... (78%) OK
Running test standard: 025... (84%) OK
Running test standard: 026... (89%) OK
Running test standard: 028... (94%) OK
Running test standard: 029... (100%) OK

A total of 2 test(s) failed, with 2 critical failure(s).

Please check the directory:
  failed
for the .out/.err files of the failed tests,
and check the submit directory:
  tmp
for the working directories of the last run.

> 001.err:
Note: The following floating-point exceptions are signalling: 
IEEE_INVALID_FLAG IEEE_DIVIDE_BY_ZERO IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
scf.exe: functionals.c:287: xc_func_init: Assertion 
`nspin==XC_UNPOLARIZED || nspin==XC_POLARIZED' failed.


Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x7feb89b378d2 in ???
#1  0x7feb89b36a65 in ???
#2  0x7feb897c691f in ???
#3  0x7feb897c68a1 in raise
#4  0x7feb897b0545 in abort
#5  0x7feb897b042e in ???
#6  0x7feb897bf221 in __assert_fail
#7  0x7feb88c71692 in xc_func_init
#8  0x7feb89de64ed in __xc_f03_lib_m_MOD_xc_f03_func_init
#9  0x5648b32a5b76 in ???
#10  0x5648b32a666a in ???
#11  0x5648b32a66e8 in ???
#12  0x5648b3192cca in ???
#13  0x5648b317b80c in ???
#14  0x5648b3156f46 in ???
#15  0x5648b3156cf6 in ???
#16  0x7feb897b17fc in __libc_start_main
#17  0x5648b3156d49 in ???
#18  0x in ???
> 001.out:
  Basis functions   114   114


  Input file to MOLDEN was generated!

--- Stop Module: seward at Wed Mar 23 07:16:03 2022 /rc=_RC_ALL_IS_WELL_ ---
--- Module seward spent 1 second ---
--- Start Module: check at Wed Mar 23 07:16:03 2022 ---
--- Stop Module: check at Wed Mar 23 07:16:03 2022 
/rc=_RC_NOT_AVAILABLE_ ---


Checking results:
All values match the reference


EXPORT DFT = BLYP


*** symbolic link created: INPORB -> standard__001.GssOrb
--- Start Module: scf at Wed Mar 23 07:16:03 2022 ---

-- Input validation for scf
lxml python module not found, no validation possible
--
The total execution time is limited to 600 seconds.

()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()



   only a single process is used
  available to each process: 2.0 GB of memory, 56 
threads

 pid: 2065
()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()


###

###
 ### 
  ###
 ### 
  ###
 ### Minimized-density-differences option turned off! 
  ###
 ### 
  ###
 ### 
  ###


###

###
--- Stop Module: scf at Wed Mar 23 07:16:03 2022 /rc=-6 ---


END FOREACH


..
.# Non-zero return code #.
..

Timing: Wall=2.06 User=9.06 System=10.82
autopkgtest [07:18:59]: test testsuite.sh



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008169: bootstrapping fedora34 or centos7 gives a system with an empty package database

[Enrico Zini]

On Thu, Mar 24, 2022 at 12:52:24AM +, Luca Boccassi wrote:

> Have you checked if the --clean-package-metadata= option is the cause?
> 
>CleanPackageMetadata=, --clean-package-metadata=
>   Enable/disable removal of package manager databases, caches, 
> and logs at  the  end  of  installation.
>   Can  be specified as true, false, or “auto” (the default).  
> With “auto”, files will be removed if the
>   respective package manager executable is not present at the end 
> of the installation.

I just tried, and that does not seem to be the cause:

  $ sudo /usr/bin/mkosi --distribution=fedora --release=34 --format=directory 
--output=target --base-packages=true --package=bash,rootfiles,dbus,dnf 
--clean-package-metadata=false
  …
  $ sudo systemd-nspawn --volatile -D target
  Spawning container target on /home/enrico/lavori/arpa/moncic-ci/target.
  Press ^] three times within 1s to kill container.
  -bash-5.1# rpm -qa
  -bash-5.1# rpmdb --rebuilddb
  -bash-5.1# rpm -qa
  -bash-5.1# ls -la /var/lib/rpm
  total 240
  drwxr-xr-x 2 0 0100 Mar 24 13:08 .
  drwxr-xr-x 3 0 0 60 Mar 24 13:08 ..
  -rw-r--r-- 1 0 0 212992 Mar 24 13:08 rpmdb.sqlite
  -rw-r--r-- 1 0 0  32768 Mar 24 13:08 rpmdb.sqlite-shm
  -rw-r--r-- 1 0 0  0 Mar 24 13:08 rpmdb.sqlite-wal
  -bash-5.1# 


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Bug#1008211: libobject-pad-perl breaks libtickit-widget-tabbed-perl autopkgtest

[Paul Gevers]

Source: libobject-pad-perl, libtickit-widget-tabbed-perl
Control: found -1 libobject-pad-perl/0.63-1
Control: found -1 libtickit-widget-tabbed-perl/0.026-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of libobject-pad-perl the autopkgtest of 
libtickit-widget-tabbed-perl fails in testing when that autopkgtest is 
run with the binary packages of libobject-pad-perl from unstable. It 
passes when run with only packages from testing. In tabular form:


  passfail
libobject-pad-perlfrom testing0.63-1
libtickit-widget-tabbed-perl  from testing0.026-1
all othersfrom testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of 
libobject-pad-perl to testing [1]. Due to the nature of this issue, I 
filed this bug report against both packages. Can you please investigate 
the situation and reassign the bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=libobject-pad-perl

https://ci.debian.net/data/autopkgtest/testing/amd64/libt/libtickit-widget-tabbed-perl/20265825/log.gz


#   Failed test ' /usr/bin/perl -w -M"Tickit::Widget::Tabbed" -e 1 2>&1 
produced no (non-whitelisted) output'

#   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 107.

#   Failed test 'env PERL_DL_NONLAZY=1  /usr/bin/perl -w 
-M"Tickit::Widget::Tabbed" -e 1 2>&1 produced no (non-whitelisted) output'

#   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 107.
# Looks like you failed 2 tests of 4.
/usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t .. 1..4
# field initialiser expression is experimental and may be changed or 
removed without notice at 
/usr/share/perl5/Tickit/Widget/Tabbed/Ribbon.pm line 302.
ok 1 -  /usr/bin/perl -w -M"Tickit::Widget::Tabbed" -e 1 2>&1 exited 
successfully
not ok 2 -  /usr/bin/perl -w -M"Tickit::Widget::Tabbed" -e 1 2>&1 
produced no (non-whitelisted) output
# field initialiser expression is experimental and may be changed or 
removed without notice at 
/usr/share/perl5/Tickit/Widget/Tabbed/Ribbon.pm line 302.
ok 3 - env PERL_DL_NONLAZY=1  /usr/bin/perl -w 
-M"Tickit::Widget::Tabbed" -e 1 2>&1 exited successfully
not ok 4 - env PERL_DL_NONLAZY=1  /usr/bin/perl -w 
-M"Tickit::Widget::Tabbed" -e 1 2>&1 produced no (non-whitelisted) output

Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/4 subtests
Test Summary Report
---
/usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t (Wstat: 512 Tests: 
4 Failed: 2)

  Failed tests:  2, 4
  Non-zero exit status: 2
Files=1, Tests=4,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.22 cusr 
0.01 csys =  0.25 CPU)

Result: FAIL
autopkgtest [07:15:45]: test autodep8-perl



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1007222: transition: onetbb

[Paul Gevers]

Hi lumin,

On 14-03-2022 02:30, Matthias Klose wrote:

On 13.03.22 21:59, M. Zhou wrote:

I have not tested by myself, but I heard from an archlinux
developer that this API bump breaks a lot packages. And
some upstreams decided to disable or drop tbb support as
a result. I guess we can take similar measures for short
term workaround.


"I heard from archlinux" is not good enough.  I sent you email about 
this without getting a reply, then filed #1006920, without getting a 
reply, now this incomplete proposal. you may want to look at all the 
build rdeps for libtbb2-dev in Ubuntu to get an overview what at least 
breaks:


[...]

this breaks everything immediately because of the conflicting libtbb2 
and libtbb12. Please fix this first.


Can you please respond to these remarks? They raise valid points for us.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006621: ITP: boofcv -- Real-time computer vision library

[Andrius Merkys]

Dear Peter and Dima,

Sorry for the delay. Somehow I did not receive any mails sent to
1006...@bugs.debian.org (will subscribe), thus I only now noticed your
conversation after accidentally revisiting the bug page.

Good to meet you too, Peter!

First of all, regarding Cephis, my original reason to package BoofCV. It
depends on io, feature and visualize modules of BoofCV v0.17. AFAIK,
these should be static image analysis tools, thus stripping away more
complicated video and webcam support should make things much easier for
now. Of course, in the long run it would be nice to support video and
webcam parts of BoofCV in Debian as well.

Regarding Gradle. Debian has 4.4.1 now and updating it is complicated.
It would be nice to ask its maintainers in Debian to understand what are
the current blockers. Gradle wrapper cannot be used as downloads in the
build time are not allowed in Debian. Even more generally, Debian builds
can only rely on software which is built from source on Debian build
machines.

For now I see upgrading Gradle in Debian as the best solution to the
build issue. Simplifying/changing the build system is a viable solution
too, but I believe this would need much work and add maintenance burden
on Peter. Discussion in [1] gives me some hope Gradle will be updated
soon. I think it is worth pinging its participants.

Peter, you mention BoofCV build system downloading some JARs. Maybe we
could build these JARs in Debian as separate packages and use them in
BoofCV build? If Gradle blocker goes away, these might be the next blockers.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926714

Best wishes,
Andrius

Bug#1008210: cups-client: lp (-h) hostname option has to come before destination (-d)

[Paul Hutschemaekers]

Package: cups-client
Version: 2.3.3op2-3+deb11u1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
I tried to print an file with the lp command* What exactly did you
do (or not do) that was effective (or ineffective)?
I tried the command:
lp -d DESTINATION -h HOSTNAME FILENAME* What was the outcome of
this action?
An error: lp: Error - The printer or class does not exist.
   * What outcome did you expect instead?
printing of the file.

When I print with:
lp -h HOSTNAME -d DESTINATION FILENAME
everything works ok, I'm sure cups-client on BUSTER did not care about
the placement of the host parameter. The man-page also reports
lp  [  -E  ]  [  -U username ] [ -c ] [ -d
destination[/instance] ] [ -h host‐name[:port] ]
with the destination before the host-name

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

Kernel: Linux 5.10.0-12-amd64 (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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cups-client depends on:
ii  adduser  3.118
ii  cups-common  2.3.3op2-3+deb11u1
ii  libc62.31-13+deb11u2
ii  libcups2 2.3.3op2-3+deb11u1

cups-client recommends no packages.

Versions of packages cups-client suggests:
pn  cups   
ii  cups-bsd   2.3.3op2-3+deb11u1
pn  smbclient  

-- no debconf information

Bug#1008206: libdpkg-perl: debs_parse option to reduce invalid package names and version strings

[Paul Gevers]

Hi Guillem,

On 24-03-2022 12:28, Guillem Jover wrote:

I'm afraid adding a mode to
handle improper/malformed input would be difficult, because that depends
on the amount of “improperness”, and because it looks like a smell
that ideally should be fixed elsewhere. For example if you only had
substvars that add entire new dependency information, then just using
the Dpkg::Substvars replacements with possibly empty variables, could
do it, but if as you mentioned these are embedded inside dependency
syntax, then that'd be indeed a problem.


It's totally OK to say no, even if you're not able to tell me how to fix 
my own problem. It's more that if you were (very) willing to add that 
option it would give me some easy breathing room with that particular 
issue. Not a perfect solution, but better than what I have now and 
probably good enough in practice. But again, feel free to close this 
issue as wontfix and I'll think about my options.


Either way, thanks for the discussion.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001595: src:gcc-defaults-mipsen: fails to migrate to testing for too long

[YunQiang Su]

Paul Gevers  于2022年3月24日周四 19:26写道：
>
> Hi YunQiang,
>
> On 22-03-2022 07:06, YunQiang Su wrote:
> > Paul Gevers  于2022年3月22日周二 04:04写道：
> >> On Sun, 12 Dec 2021 21:51:28 +0100 Paul Gevers  wrote:
> >>> The Release Team considers packages that are out-of-sync between testing
> >>> and unstable for more than 60 days as having a Release Critical bug in
> >>> testing [1]. Your package src:gcc-defaults-mipsen has been trying to
> >>> migrate for 62 days [2].
> >>
> >> It's been 161 days now. We expect from you to solve these kind of
> >> issues, especially if they have been brought to your attention.
> >>
> >
> > ohh. sorry for it. I upload gcc-11-cross-mipsen some days ago.
> > I thought that gcc-defaults-mipsen will migrate ok.
> >
> > I will fix it just now.
>
> You are aware that gcc-12-cross-mipsen needs another source-only upload
> because it's new and you needed to upload all binaries but non-buildd
> built binaries are not allowed to migrate. Unfortunately on the current
> infrastructure binNMU's of arch:all binaries don't work.
> gcc-12-cross-mipsen needs to be able to migrate together with
> gcc-11-cross-mipsen (and gcc-defaults-mipsen).
>

Yes. I am aware of it. And I am waiting for gcc-12-cross-mipsen to finish
building on all of these architectures.

> Paul



-- 
YunQiang Su

Bug#1008209: freeipa-client: ipa-client-install --uninstall crashes in admintool.py ScriptError

[Martin Pitt]

Package: freeipa-client
Version: 4.9.8-1+b1

Installing the IPA client is broken due to some chrony FUBAR [1], but I worked
around that with a mock service:

| # cat /run/systemd/system/chrony.service
| [Service]
| Type=oneshot
| ExecStart=/bin/true
| # systemctl unmask chrony

After that, joining a domain works:

| # ipa-client-install --domain cockpit.lan --realm COCKPIT.LAN --principal 
admin -W
| This program will set up IPA client.
| Version 4.9.8
| 
| WARNING: conflicting time synchronization service 'ntp' will be disabled 
in favor of chronyd
| 
| Discovery was successful!
| Do you want to configure chrony with NTP server or pool address? [no]: 
| Client hostname: x0.cockpit.lan
| Realm: COCKPIT.LAN
| DNS Domain: cockpit.lan
| IPA Server: f0.cockpit.lan
| BaseDN: dc=cockpit,dc=lan
| 
| Continue to configure the system with these values? [no]: yes
| [...]
| The ipa-client-install command was successful

But leaving it crashes:

| # ipa-client-install --uninstall
| Unenrolling client from IPA server
| Removing Kerberos service principals from /etc/krb5.keytab
| Disabling client Kerberos and LDAP configurations
| Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to 
/etc/sssd/sssd.conf.deleted
| Restoring client configuration files
| Unconfiguring the NIS domain.
| nscd daemon is not installed, skip configuration
| nslcd daemon is not installed, skip configuration
| Some installation state for ntp has not been restored, see 
/var/lib/ipa/sysrestore/sysrestore.state
| Some installation state has not been restored.
| This may cause re-installation to fail.
| It should be safe to remove /var/lib/ipa-client/sysrestore.state but it may
|  mean your system hasn't been restored to its pre-installation state.
| Systemwide CA database updated.
| Client uninstall complete.
| The original nsswitch.conf configuration has been restored.
| You may need to restart services or reboot the machine.
| Do you want to reboot the machine? [no]: no
| The ipa-client-install command failed. See /var/log/ipaclient-uninstall.log 
for more information
|
| root@x0:~# echo $?
| 4

That log indeed has a rather non-descriptive stack trace:

| 022-03-24T11:22:02Z DEBUG   File 
"/usr/lib/python3/dist-packages/ipapython/admintool.py", line 180, in execute
| return_value = self.run()
|   File "/usr/lib/python3/dist-packages/ipapython/install/cli.py", line 342, 
in run
| return cfgr.run()
|   File "/usr/lib/python3/dist-packages/ipapython/install/core.py", line 360, 
in run
| return self.execute()
| [...]
|   File "/usr/lib/python3/dist-packages/ipaclient/install/client.py", line 
3659, in uninstall
| raise ScriptError(rval=rv)

But this doesn't seem to be related to chronyd or my hack.

(Fun fact: The uninstall log is *exactly* 6 bytes. )

I attach the full install and uninstall logs for reference.

Thanks,

Martin

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008195


ipaclient-install.log.xz
Description: application/xz
2022-03-24T11:21:56Z DEBUG Logging to /var/log/ipaclient-uninstall.log
2022-03-24T11:21:56Z DEBUG ipa-client-install was invoked with arguments [] and 
options: {'unattended': False, 'principal': None, 'prompt_password': False, 
'on_master': False, 'ca_cert_files': None, 'force': False, 'configure_firefox': 
False, 'firefox_dir': None, 'keytab': None, 'mkhomedir': False, 'force_join': 
False, 'ntp_servers': None, 'ntp_pool': None, 'no_ntp': False, 'force_ntpd': 
False, 'nisdomain': None, 'no_nisdomain': False, 'ssh_trust_dns': False, 
'no_ssh': False, 'no_sshd': False, 'no_sudo': False, 'no_dns_sshfp': False, 
'kinit_attempts': None, 'request_cert': False, 'ip_addresses': None, 
'all_ip_addresses': False, 'fixed_primary': False, 'permit': False, 
'enable_dns_updates': False, 'no_krb5_offline_passwords': False, 
'preserve_sssd': False, 'automount_location': None, 'domain_name': None, 
'servers': None, 'realm_name': None, 'host_name': None, 'verbose': False, 
'quiet': False, 'log_file': None, 'uninstall': True}
2022-03-24T11:21:56Z DEBUG IPA version 4.9.8
2022-03-24T11:21:56Z DEBUG IPA platform debian
2022-03-24T11:21:56Z DEBUG IPA os-release Debian GNU/Linux 
2022-03-24T11:21:56Z DEBUG Loading Index file from 
'/var/lib/ipa-client/sysrestore/sysrestore.index'
2022-03-24T11:21:56Z DEBUG Loading StateFile from 
'/var/lib/ipa-client/sysrestore/sysrestore.state'
2022-03-24T11:21:56Z DEBUG Loading StateFile from 
'/var/lib/ipa-client/sysrestore/sysrestore.state'
2022-03-24T11:21:56Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2022-03-24T11:21:56Z DEBUG Loading Index file from 
'/var/lib/ipa/sysrestore/sysrestore.index'
2022-03-24T11:21:56Z DEBUG httpd is not configured
2022-03-24T11:21:56Z DEBUG kadmin is not configured
2022-03-24T11:21:56Z DEBUG dirsrv is not configured
2022-03-24T11:21:56Z DEBUG pki-tomcatd is not configured
2022-03-24T11:21:56Z DEBUG install is not configured
2022-03-24T11:21:56Z DEBUG krb5kdc is not configured
2022-03-24T11:21:56Z 

Bug#1008206: libdpkg-perl: debs_parse option to reduce invalid package names and version strings

[Guillem Jover]

On Thu, 2022-03-24 at 12:08:30 +0100, Paul Gevers wrote:
> On 24-03-2022 12:06, Paul Gevers wrote:
> > Hi Guillem,
> > 
> > On 24-03-2022 11:50, Guillem Jover wrote:
> > > Hmm, but that means autopkgtest will then miss packages that are
> > > listed in Recommends fields on the built packages it is supposed to be
> > > testing, no?
> > 
> > Indeed. But at least that's what is documented :(.

Given that this was added (AFAIR) quite recently, wouldn't it be
an option to try to fix its semantics now instead of carrying this
over? (I don't expect things might break, given that I'd expect users
would want to test the full recommends and not a partial view?)

> > > I think the correct answer here is to take those fields from the built
> > > packages, which are to be tested, then you'd get accurate
> > > dependencies, and no need to have to deal with substvars. Is that
> > > alternative you had in mind and already discarded?
> > 
> > Indeed, but there's no nice interface. E.g. I looked at the output of
> > apt-cache depends (with --no-pre-depends --no-depends  --no-suggests
> > --no-conflicts --no-breaks --no-replaces --no-enhances) but then we miss
> > versions and worse, we need to carefully figure out which packages we're
> > interested in and which version of those packages we should ask
> > apt-cache. This makes it a rather ugly piece of code in autopkgtest.
> 
> And if autopkgtest is asked to build the binaries, apt doesn't yet even
> knows about them the moment we want to know these Recommends. So we'd need a
> different interface for that code path.

Hmm. I'm not sure what other constraints you are working with here. Would
fetching the Recommends fields after the fact from either dpkg-query
(once installed) or from dpkg-deb -f (on the downloaded or built .debs)
be unsatisfactory?


In any case, if it seems like I'm trying to evade the initial request,
I guess in part it is, because I am. :D I'm afraid adding a mode to
handle improper/malformed input would be difficult, because that depends
on the amount of “improperness”, and because it looks like a smell
that ideally should be fixed elsewhere. For example if you only had
substvars that add entire new dependency information, then just using
the Dpkg::Substvars replacements with possibly empty variables, could
do it, but if as you mentioned these are embedded inside dependency
syntax, then that'd be indeed a problem.

Thanks,
Guillem