Bug#1010506: keepass2 sometimes aborts during start-up.

[Jeroen Witmond]

Package: keepass2
Version: 2.47+dfsg-2
Severity: normal
X-Debbugs-Cc: jeroen.n.witm...@gmail.com

Dear Maintainer,

keepass2 sometimes aborts during start-up.

Nowadays I start keepass2 on this machine with command `keepass2 > 
keepass2-`date +%Y%m%d-%H%M%S`.txt 2>&1` to capture the crash output:



=
Native Crash Reporting
=
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=

=
Native stacktrace:
=
 (No frames) 


=
Telemetry Dumper:
=
Pkilling 0xb179b440 from 0xb6fa0240
Pkilling 0xb4723440 from 0xb6fa0240
Entering thread summarizer pause from 0xb6fa0240
Finished thread summarizer pause from 0xb6fa0240.

Waiting for dumping threads to resume

=
External Debugger Dump:
=
[New LWP 2346]
[New LWP 2347]
[New LWP 2352]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
0xb6da84d4 in __GI___wait4 (pid=2411, stat_loc=0xbe8536d8, options=0, 
usage=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:27
27  ../sysdeps/unix/sysv/linux/wait4.c: No such file or directory.
  Id   Target Id  Frame 
* 1Thread 0xb6fa0240 (LWP 2344) "cli" 0xb6da84d4 in __GI___wait4 
(pid=2411, stat_loc=0xbe8536d8, options=0, usage=0x0) at 
../sysdeps/unix/sysv/linux/wait4.c:27
  2Thread 0xb63ff440 (LWP 2346) "SGen worker" futex_wait_cancelable 
(private=0, expected=0, futex_word=0x447698) at 
../sysdeps/nptl/futex-internal.h:186
  3Thread 0xb4723440 (LWP 2347) "Finalizer"   
futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=1, 
futex_word=0x43f73c) at ../sysdeps/nptl/futex-internal.h:323
  4Thread 0xb179b440 (LWP 2352) "cli" 0xb6e970c4 in __libc_accept 
(fd=3, addr=..., len=0x0) at ../sysdeps/unix/sysv/linux/accept.c:26

Thread 4 (Thread 0xb179b440 (LWP 2352) "cli"):
#0  0xb6e970c4 in __libc_accept (fd=3, addr=..., len=0x0) at 
../sysdeps/unix/sysv/linux/accept.c:26
#1  0x002d08ec in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 3 (Thread 0xb4723440 (LWP 2347) "Finalizer"):
#0  futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, 
expected=1, futex_word=0x43f73c) at ../sysdeps/nptl/futex-internal.h:323
#1  do_futex_wait (sem=sem@entry=0x43f73c, abstime=0x0, clockid=0) at 
sem_waitcommon.c:117
#2  0xb6e95c80 in __new_sem_wait_slow (sem=0x43f73c, abstime=0x0, clockid=0) at 
sem_waitcommon.c:285
#3  0x002c2120 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 2 (Thread 0xb63ff440 (LWP 2346) "SGen worker"):
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x447698) at 
../sysdeps/nptl/futex-internal.h:186
#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x0, 
cond=0x447670) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x447670, mutex=0x0) at pthread_cond_wait.c:638
#3  0x00327c84 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (Thread 0xb6fa0240 (LWP 2344) "cli"):
#0  0xb6da84d4 in __GI___wait4 (pid=2411, stat_loc=0xbe8536d8, options=0, 
usage=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:27
#1  0x0009f73c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
[Inferior 1 (process 2344) detached]

=
Basic Fault Address Reporting
=
Memory around native instruction pointer (0xb6f5eaac):0xb6f5ea9c  0c 20 42 e0 
40 20 52 e2 03 00 00 3a 10 0b b1 ec  . B.@ R:
0xb6f5eaac  10 0b a0 ec 40 20 52 e2 fb ff ff 2a 3f 00 12 e3  @ R*?...
0xb6f5eabc  10 00 00 0a 82 ed b0 e1 08 4b b1 2c 04 2b b1 4c  .K.,.+.L
0xb6f5eacc  08 4b a0 2c 04 2b a0 4c 82 ee b0 e1 02 7b b1 2c  .K.,.+.L.{.,

=
Managed Stacktrace:
=
=


The crash also produces a file mono_crash.0.3.json:

Bug#1010475: wiki.debian.org: wrong link to libreoffice-kf5

[Paul Wise]

On Tue, 2022-05-03 at 04:53 +, Felipe Maia wrote:

> Before closing the bug, can I change the severity level from "normal"
> to "minor" with the following control command:
> 
> Control: severity -1 minor
> 
> Besides being just typo fix, which should be classified as "minor",
> I would like to do it because I'm learning to manage bugs and to use
> the BTS.

Sounds good, please do.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1010505: golang-gopkg-libgit2-git2go.v31 autopkgtest failure with libgit2 1.3

[Peter Michael Green]

Package: golang-gopkg-libgit2-git2go.v31
Version: 31.4.3-4
Severity: serious

The autopkgtest for golang-gopkg-libgit2-git2go.v31 is failing with 
libgit2 1.3

and hence blocking the transition.

https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-gopkg-libgit2-git2go.v31/21329197/log.gz




github.com/libgit2/git2go/v31
# github.com/libgit2/git2go/v31
src/github.com/libgit2/git2go/v31/git_system_dynamic.go:11:3: error: #error "Invalid 
libgit2 version; this git2go supports libgit2 between v1.1.0 and v1.1.0"
11 | # error "Invalid libgit2 version; this git2go supports libgit2 between 
v1.1.0 and v1.1.0"
   |   ^

Bug#1010104: cqrlog: missing AppStream metadata

[tony mancill]

On Sat, Apr 30, 2022 at 09:37:06AM -0700, tony mancill wrote:
> On Fri, Apr 29, 2022 at 01:52:42PM +0200, asciiw...@seznam.cz wrote:

> > ah, the AppData file seems to be in the cqrlog-data package (along with 
> > desktop icon files), not the main cqrlog one. I am however not sure whether 
> > this is supported by GNOME Software / KDE Discover and the Debian/Ubuntu 
> > AppStream generator itself[1]. GNOME Software on Ubuntu 22.04 (which uses 
> > cqrlog 2.5.2-1 package synced from Debian) does not seem to display valid 
> > metadata for the cqrlog package - it uses autogenerated metadata from its 
> > desktop file (and no icon) instead.
> 
> Hi Daniel,
> 
> :facepalm:  I didn't look closely enough.  Thank you for pointing this
> out.  Since cqrlog depends on cqrlog-data with the same source version,
> I think this should be fairly simple to move into cqrlog.

The update is ready.  It feels a little odd to have cqrlog declare
Breaks/Replaces on the previous cqrlog-data in order to hint APT to do
the right thing during an upgrade.  That, we have the following:

Package: cqrlog
Depends: cqrlog-data (= ${source:Version}), ..
Breaks: cqrlog-data (<< 2.5.2-2)
Replaces: cqrlog-data (<< 2.5.2-2)

  and

Package: cqrlog-data
Breaks: cqrlog (<< 2.4.0)
Replaces: cqrlog (<< 2.4.0)

Since the version in stable is > 2.4.0, I'm interested in thoughts on
whether I can drop the Breaks/Depends in this upload of cqrlog-data to
avoid having a circular Breaks/Replaces relationship between cqrlog and
cqrlog-data if someone tried to update directly from oldstable
(2.3.0-2).

Regards,
tony

Bug#1010148: openmsx: patch for ftbfs on riscv64

[Bo YU]

Hi,
On Sat, Apr 30, 2022 at 06:09:08PM +, Dr. Bas Wijnen wrote:

Thanks for the patch. I'm on vacation at the moment. I'll upload it after next
week, unless the new release is out sooner, in which case I'll upload that
which apparently also fixes this problem.


Thank you also. The damn gmail move email from @debian.org to spam 
automatically :(

There I noticed the same ftbfs for openmsx-debugger:

https://buildd.debian.org/status/package.php?p=openmsx-debugger=sid

I will compile it locally with one-line patch and send it for you if everything
is ok.

BR,
Bo



On Mon, Apr 25, 2022 at 07:07:02PM +0800, Bo YU wrote:

Package: openmsx
Version: 17.0-2
Followup-For: Bug #1010148
Control: tags -1 patch

Dear Maintainer,

sorry, I don't know why can attach patch if `repotbug --mutt`?
send patch again.



Last-Update: 2022-04-25

--- openmsx-17.0.orig/build/detectsys.py
+++ openmsx-17.0/build/detectsys.py
@@ -53,6 +53,8 @@ def detectCPU():
return 'sheb' if cpu.endswith('eb') else 'sh'
elif cpu == 'avr32':
return 'avr32'
+   elif cpu == 'riscv64':
+   return 'riscv64'
elif cpu == '':
# Python couldn't figure it out.
os = system().lower()

Bug#737564: dump should accomodate backups of media named by their UUID

[Alexander Zangerl]

retitle 737564 dump: change dumpdates to support incrementals by UUID=blah
thanks

doing backups for uuid- and label-backed devices has worked since the switch
to libblkid (roughly around 2004), ie. "dump -0f someplace UUID=whatever" and
"dump -0f otherplace LABEL=tagyoureit" has and does work fine.

there are two uuid-related issues:

a) the documentation isn't uptodate, files-to-dump in dump.8 only
says mountpoint or device, and doesn't mention what
libblkid gained us, ie. it doesn't mention looking up devices by TOKEN=value.

that is easy to fix and i'll take care of that on the next upload.

b), which is the core of this bug report - dumpdates always only
saves the device name, hence doesn't find reordered devices.

i think the least messy way out is to rework the dumpdates stuff to
stop canonicalising the memorised device name, and instead park
whatever the user gave us for the device lookup. ie: if you dump -u /dev/sdy
then "/dev/sdy" will be saved, just as before, but if you
dump -u LABEL=foobardiddly then dumpdates will hold "LABEL=foobardiddly".

pro: 100% backwards compatible, and minimal amount of code change.
contra: you cannot mix incremental dumps of /dev/sdxyz with UUID=whatever
and expect dump to find one by the other. i think that's quite acceptable
a limitation, as long as it makes it into the documentation.

i'll be working on this Real Soon Now(tm).

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Never trust a computer you can't throw out the window. - S. Hunt


signature.asc
Description: Digital Signature

Bug#1010500: mutt: Testing upgrade to 2.2.3-2 breaks sending mail

[Kevin J. McCarthy]

On Mon, 02 May 2022 19:20:29 -0400 ant  wrote:

Package: mutt
Version: 2.2.3-1


Just checking this is for 2.2.3-2.  That update switched to the gsasl 
library, which unfortunately needs some bugs worked out with its mutt 
implementation.  :-(


From the debug log, it looks like you have $smtp_authenticators set. 
What happens if you unset that variable, does authentication work in 
that case?  What if you explicitly set $smtp_authenticators to "login" 
or "plain"?


I'll try to see if I can duplicate the problem, but I don't have access 
to a smtp server supporting cram-md5.  Is the server you are using 
accessible for me to try (and of course fail) authenticating with?


-Kevin


signature.asc
Description: PGP signature

Bug#1010501: RM: votca-tools -- ROM; superceded by votca

[Nicholas Breen]

Package: ftp.debian.org
Severity: normal


The recent acceptance of src:votca into the archive (thank you!) covers
an upstream merger of its formerly separate components: votca-tools,
votca-csg, and votca-xtp.  Please remove those three when convenient.



--
Nicholas Breen
nbr...@debian.org

Bug#1010475: wiki.debian.org: wrong link to libreoffice-kf5

[Paul Wise]

On Mon, 2022-05-02 at 12:32 +0200, Yngve Spjeld-Landro wrote:

> Page 
> https://wiki.debian.org/Wayland#LibreOffice_.28supported.2C_not_by_default.29
> contains errors with regard to libreoffice-kf5: it is written and
> referred to as being libreoiffice-kf5.

Felipe Maia already fixed this issue, but if you see any other issues,
feel free to register an account and edit the wiki yourself. 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1010475: wiki.debian.org: wrong link to libreoffice-kf5

[Paul Wise]

On Mon, 2022-05-02 at 22:49 +, Felipe Maia wrote:

> It's my first time fixing a bug here on Debian.

Congrats :)

> I have been following the Web-Team's work for while now.
> 
> I replied to the BTS email as Paul Wise (pabs) usually do (I think so
> :)).

Great :)

> Can I close the bug according to the instructions on
> ?

Yes please! For the version in the message, maybe use the page name and
revision number, or even just a link to the diff.

> Let me know if I did something wrong or if you have any tips or
> suggestions on how to improve.

Everything looks good.

In case you want to contribute to the website too:

https://www.debian.org/devel/website

Check out this page for other ways to contribute to Debian:

https://www.debian.org/intro/help 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1010493: ltrace: diff for NMU version 0.7.3-6.3

[Joao Eriberto Mota Filho]

Control: tags 1010493 + patch
Control: tags 1010493 + pending

Dear maintainer,

I've prepared an NMU for ltrace (versioned as 0.7.3-6.3) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,

Eriberto

diff -Nru ltrace-0.7.3/debian/changelog ltrace-0.7.3/debian/changelog
--- ltrace-0.7.3/debian/changelog   2022-03-30 20:48:13.0 -0300
+++ ltrace-0.7.3/debian/changelog   2022-05-02 20:51:56.0 -0300
@@ -1,3 +1,12 @@
+ltrace (0.7.3-6.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: disabled use of -Werror to avoid a FTBFS in mipsel, alpha and
+ia64 when using DH level 13. Thanks to Paul Gevers .
+(Closes: #1010493)
+
+ -- Joao Eriberto Mota Filho   Mon, 02 May 2022 20:51:56 
-0300
+
 ltrace (0.7.3-6.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru ltrace-0.7.3/debian/rules ltrace-0.7.3/debian/rules
--- ltrace-0.7.3/debian/rules   2022-03-30 20:48:13.0 -0300
+++ ltrace-0.7.3/debian/rules   2022-05-02 20:51:07.0 -0300
@@ -4,7 +4,7 @@
dh $@
 
 override_dh_auto_configure:
-   dh_auto_configure -- --with-libunwind=no
+   dh_auto_configure -- --with-libunwind=no --disable-werror
 
 override_dh_install:
dh_install

Bug#1010493: ltrace: FTBFS on mipsel: directive argument is null

[Eriberto Mota]

Em seg., 2 de mai. de 2022 às 16:21, Paul Gevers  escreveu:
>
> Source: ltrace
> Version: 0.7.3-6.1
> Severity: serious
> Tags: ftbfs
> Justification: FTBFS
> X-Debbugs-Cc: Guilherme de Paula Xavier Segundo , 
> Joao Eriberto Mota Filho 
>
> Dear all,
>
> Thanks for fixing RC bugs in your package. However, the last upload of ltrace 
> failed to build from source on mipsel, while it built there successfully in 
> the past. Can you please have a look?
>
> Paul
>
> https://buildd.debian.org/status/fetch.php?pkg=ltrace=mipsel=0.7.3-6.2=1649617481=0
>
> Making all in mips
[...]
> cc1: all warnings being treated as errors

Thanks a lot for pointing this out Paul. The right fix will need
changes in source code and I am not able to make it. Thus, as a
workaround, I will disable werror and this action will fix the build
in some architectures.

Regards,

Eriberto

Bug#1010397: Fwd: Bug#1010397: git-annex sync fails in rsync remotes with rsync 3.2.4-1

[Joey Hess]

Sean Whitton wrote:
> > git-annex can be configured to not do its own shell escaping when accessing
> > a rsync special remote. If your remote is named "foo", you can configure it
> > that way as follows:
> >
> > git-annex enableremote foo shellescape=no
> 
> Thanks for looking into it.  Do you see this as a workaround or what
> people using newer rsync should use going forward?

That's a workaround. If it works, perhaps git-annex could probe the
rsync version and do the same thing automatically. Depends on it 
only the local rsync version matters, not the remote one.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1010397: Fwd: Bug#1010397: git-annex sync fails in rsync remotes with rsync 3.2.4-1

[Sean Whitton]

Hello,

On Mon 02 May 2022 at 12:51PM -04, Joey Hess wrote:

> Joey Hess wrote:
>> The rsync command that git-annex runs has a trailing close quote, as
>> seen in the first excerpt above. But rsync then complains about the path
>> with that close quote removed.
>>
>> I'm having a hard time not seeing this as a bug in rsync.
>
> # NEWS for rsync 3.2.4 (15 Apr 2022)
>
> ## Changes in this version:
>
> ### BEHAVIOR CHANGES:
>
>  - A new form of arg protection was added that works similarly to the older
>[`--protect-args`](rsync.1#opt) (`-s`) option but in a way that avoids
>breaking things like rrsync (the restricted rsync script): rsync now uses
>backslash escaping for sending "shell-active" characters to the remote
>shell. This includes spaces, so fetching a remote file via a simple quoted
>filename value now works by default without any extra quoting
>
> This change must be the cause of the problem.
>
> git-annex can be configured to not do its own shell escaping when accessing
> a rsync special remote. If your remote is named "foo", you can configure it
> that way as follows:
>
>   git-annex enableremote foo shellescape=no

Thanks for looking into it.  Do you see this as a workaround or what
people using newer rsync should use going forward?

-- 
Sean Whitton

Bug#1010500: mutt: Testing upgrade to 2.2.3-2 breaks sending mail

[ant]

Package: mutt
Version: 2.2.3-1
Severity: important
X-Debbugs-Cc: a...@anthive.com

Dear Maintainer,


  recent update to mutt broke sending of mail:

[2022-05-02 19:10:36] Mutt/2.2.3 (2022-04-12) debugging at level 5
[2022-05-02 19:10:36] In mutt_reflow_windows
...
[2022-05-02 19:10:59] 4< 250-AUTH PLAIN LOGIN CRAM-MD5
[2022-05-02 19:10:59] 4< 250-STARTTLS
[2022-05-02 19:10:59] 4< 250 HELP
[2022-05-02 19:10:59] 4> STARTTLS
[2022-05-02 19:10:59] 4< 220 TLS go ahead
[2022-05-02 19:10:59] SSL/TLS connection using TLS1.2 
(ECDHE-RSA/AES-256-GCM/AEAD)
...
[2022-05-02 19:11:00] 4< 250-SIZE 31457280
[2022-05-02 19:11:00] 4< 250-8BITMIME
[2022-05-02 19:11:00] 4< 250-PIPELINING
[2022-05-02 19:11:00] 4< 250-X_PIPE_CONNECT
[2022-05-02 19:11:00] 4< 250-AUTH PLAIN LOGIN CRAM-MD5
[2022-05-02 19:11:00] 4< 250 HELP
[2022-05-02 19:11:00] smtp_authenticate: Trying method ”cram-md5”
[2022-05-02 19:11:00] mutt_gsasl_get_mech() returned no usable mech
[2022-05-02 19:11:00] No authenticators available
[2022-05-02 19:11:07] mutt_free_body: unlinking 
/home/me/.mutt/tmp/mutt-ant-1000-16980-8643819149425671874.
[2022-05-02 19:11:07] Mail not sent.
[2022-05-02 19:11:08] mutt_index_menu[827]: Got op 177
[2022-05-02 19:11:08] Mailbox is unchanged.
[2022-05-02 19:11:08] mutt_buffer_pool_free: 15 of 15 returned to pool


-- Package-specific info:
Mutt 2.2.3 (2022-04-12)
Copyright (C) 1996-2022 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 5.17.0-1-amd64 (x86_64)
ncurses: ncurses 6.3.20220423 (compiled with 6.3)
libidn2: 2.3.2 (compiled with 2.3.2)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 11.2.0-19' 
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-11 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--enable-libphobos-checking=release --with-target-system-zlib=auto 
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet 
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-11-uiwEqG/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-uiwEqG/gcc-11-11.2.0/debian/tmp-gcn/usr
 --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu 
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Debian 11.2.0-19) 

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
'--includedir=${prefix}/include' '--mandir=${prefix}/share/man' 
'--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
'--libdir=${prefix}/lib/x86_64-linux-gnu' --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking 
--with-mailpath=/var/mail --enable-compressed --enable-debug --enable-fcntl 
--enable-hcache --enable-gpgme --enable-imap --enable-smtp --enable-pop 
--enable-sidebar --enable-dotlock --disable-fmemopen --with-curses 
--with-gnutls --with-gss --with-idn2 --with-mixmaster --with-sasl 
--without-gdbm --without-bdb --without-qdbm --with-tokyocabinet 
build_alias=x86_64-linux-gnu 'CFLAGS=-g -O2 
-ffile-prefix-map=/build/mutt-Z2eSdv/mutt-2.2.3=. -fstack-protector-strong 
-Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-ffile-prefix-map=/build/mutt-Z2eSdv/mutt-2.2.3=. -fstack-protector-strong 
-Wformat -Werror=format-security

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  -USE_GSASL  +USE_GSS  
+HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  +HAVE_FUTIMENS  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  

Bug#1010402: debmake-doc: Quilt configuration leads to shell error

[Osamu Aoki]

Hi,

I am a bit confused by your message.

1.17-4 is in testing and used for Debian web site web page generation now.

There is no "+" in
  https://www.debian.org/doc/manuals/maint-guide/modify.fr.html#quiltrc
as I see.

When you used text select with mouse with the text displayed by some 
pager/editor, it
might have included "+".  Sometimes, they display long overflow lines in this 
way.

Unless you tell me exactly where you get them, I will close this bug soon.

Osamu

-Original Message-
From: Philippe SWARTVAGHER 
Reply-To: Philippe SWARTVAGHER , 1010...@bugs.debian.org
To: Debian Bug Tracking System 
Subject: Bug#1010402: debmake-doc: Quilt configuration leads to shell error
Date: Sat, 30 Apr 2022 19:32:13 +0200

Package: debmake-doc
Version: 1.17-4
Severity: normal
Tags: upstream patch

Dear Maintainer,

I followed the instructions provided in this doc to setup (d)quilt,
especially the content of the ~/.quiltrc-dpkg file. But when I used
dquilt, the following error appeared:

% dquilt new fix-meson-build.patch
/home/philippe/.quiltrc-dpkg: ligne 10: + : commande introuvable
Le patch fix-meson-build.patch est maintenant au sommet

Indeed the + sign in the value of the QUILT_COLORS env var is understood
by shells (at least Bash and ZSH) as an external (unknown) command.

I provide a patch where the QUILT_COLORS value is not split accross two
lines (as it is done in
https://www.debian.org/doc/manuals/maint-guide/modify.fr.html#quiltrc).

Philippe.

Bug#679875: ace-of-penguins: Games crash when trying to view help screen

[Krzysztof Aleksander Pyrkosz]

Package: ace-of-penguins
Followup-For: Bug #679875
X-Debbugs-Cc: krzpyrk...@gmail.com

Dear Maintainer,

the source of the bug is an out of bounds access in a for loop in lib/help.c:515

int ts = (thin_space[words[i-1].flags & STYLE_BITS]
  + thin_space[words[i].flags & STYLE_BITS])/2;

Iteration starts from i = 0, accessing words[i-1] causes the crash.
The upper bound is wrong aswell. Iteration should terminate for i < nwords, not 
i <= nwords.

Bug#1010498: RFP: passt -- Unprivileged user-mode network connectivity for virtual machines and containers

[Stefano Brivio]

Sorry, wrong link, it's actually:
  https://passt.top/passt/tree/contrib/debian

Bug#1010499: Problems with theme HighContrast in Debian 11.2 и 11.3 64-bits Xfce 4.16 DoubleCmd 1.0.5

[Сергей Фёдоров]

Package: gnome-accessibility-themes
Version: 3.28-1
Severity: normal
X-Debbugs-Cc: serfyo...@yandex.ru

Dear Maintainer,

In Debian 11.2 and 11.3 64-bits Xfce 4.16, under the login of a "regular user"
, I encountered a strange thing: when running DoubleCommander with
xfce4-settings selected ("Applications→Settings→Appearance") linux-theme
"HighContrast (hicolor)" in black letters on a black background (i.e. nothing
is visible), the "Disk button panel" areas are displayed (only disk labels,
icons are normal, the hint field is normal), the "Disk List" area (only
disk labels, icons are normal, the hint field is normal), the "Status bar"
at the bottom of the left or right frame, "Directory path of the active panel"
to the left of the command line, the bottom line is the "Function Key bar"
and in some windows (not all). I haven't noticed anything in other applications
yet.

Under login "root" everything is displayed normally.

Under the login of the "ordinary user" I chose the theme "Adwaita" and
everything began to be displayed in DC normally, only in the upper and lower
panels the background became dark in Desktop Xfce.

Installed Debian 10.12.0. Installed DoubleCommander. Launched it. Everything
is displayed normally.

There is clearly a problem with the HighContrast theme in Debian 11.2 and 11.3.

For Debian 11.3 from "https://www.xfce-look .org" downloaded the light gray 
theme
"Redstar-greybird+gtk32" (https://www.xfce-look.org/p/1208044 ) 
("jayu-mon"),
which is similar to "HighContrast", but unlike it is normally displayed in DC.

Platform: x86_64-Linux-gtk2
Widgetset library: GTK 2.24.33

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

Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

-- no debconf information

Bug#1010498: RFP: passt -- Unprivileged user-mode network connectivity for virtual machines and containers

[Stefano Brivio]

Package: wnpp
Severity: wishlist

* Package name: passt
  Version : 0+git-32210fb64f7d
  Upstream Author : Stefano Brivio 
* URL : https://passt.top/
* License : AGPL-3.0-or-later AND BSD-3-Clause
  Programming Lang: C
  Description : user-mode networking daemons for virtual machines and 
containers

passt implements a translation layer between a Layer-2 network interface and
native Layer-4 sockets (TCP, UDP, ICMP/ICMPv6 echo) on a host. It doesn't
require any capabilities or privileges, and it can be used as a simple
replacement for Slirp.

pasta (same binary as passt, different command) offers equivalent functionality,
for network namespaces: traffic is forwarded using a tap interface inside the
namespace, without the need to create further interfaces on the host, hence not
requiring any capabilities or privileges.

This might become a dependency for other packages such as
libvirt and podman. Having it packaged in Debian would actually
favour adoption of this solution over libslirp/slirp4netns, which
provide a similar functionality but limited in many aspects, with
generally poorer performance and with a codebase that originates
from a very different purpose, that showed a number of security
issues in its long history.

I don't plan to maintain this package -- this is actually an RFP.

An example of Debian packaging files is available upstream at:
  https://passt.top/contrib/debian
including dh_apparmor rules for the example policy from:
  https://passt.top/passt/tree/contrib/apparmor

Bug#1010497: nodejs: autopkgtest failure: parallel/test-crypto-engine requires built artifacts

[Jérémy Lal]

Package: nodejs
Version: 16.14.2+dfsg-4
Severity: normal

That failure comes from the fact the test is expecting
some build artifacts to be present.

However nodejs currently runs its autopkgtest suite on unbuilt source.


not ok 424 parallel/test-crypto-engine
  ---
  duration_ms: 0.715
  severity: fail
  exitcode: 1
  stack: |-
node:internal/fs/utils:344
throw err;
^

Error: ENOENT: no such file or directory, access 
'/usr/bin/libtest_crypto_engine.so'
at Object.accessSync (node:fs:250:3)
at Object. 
(/tmp/autopkgtest-lxc.wzvelyzr/downtmp/build.hKK/src/test/parallel/test-crypto-engine.js:44:8)
at Module._compile (node:internal/modules/cjs/loader:1103:14)
at Object.Module._extensions..js 
(node:internal/modules/cjs/loader:1157:10)
at Module.load (node:internal/modules/cjs/loader:981:32)
at Function.Module._load (node:internal/modules/cjs/loader:822:12)
at Function.executeUserEntryPoint [as runMain] 
(node:internal/modules/run_main:77:12)
at node:internal/main/run_main_module:17:47 {
  errno: -2,
  syscall: 'access',
  code: 'ENOENT',
  path: '/usr/bin/libtest_crypto_engine.so'
}


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

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

Versions of packages nodejs depends on:
ii  libc6  2.33-7
ii  libnode93  16.14.2+dfsg-4

Versions of packages nodejs recommends:
ii  ca-certificates  20211016
ii  nodejs-doc   16.14.2+dfsg-4

Versions of packages nodejs suggests:
ii  npm  8.8.0~ds1-1

-- no debconf information

Bug#976052: ITP: zola -- static site generator

[Jonas Smedegaard]

0.15.3 draft 2, needs embedding 107 crates (60 missing, 5 broken, 20 
outdated, 22 ahead); builds in ~25 minutes; runs except subcommand serve 
which needs web assets separately packaged.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1010496: lintian: debian/changelog.dch

[Seth Arnold]

Package: lintian
Severity: normal

Dear Maintainer,

Hello, I recently noticed a few files named debian/changelog.dch in
several Ubuntu packages:

$ locate changelog.dch
/fst/trees/ubuntu/main/a/apparmor/apparmor_3.0.3-0ubuntu1/debian/changelog.dch
/fst/trees/ubuntu/main/x/x11proto-composite/x11proto-composite_0.4.2-2/debian/changelog.dch
/fst/trees/ubuntu/universe/a/android-platform-frameworks-data-binding/android-platform-frameworks-data-binding_2.2.2-3~18.04.1/debian/changelog.dch
/fst/trees/ubuntu/universe/c/comedilib/comedilib_0.8.1-5ubuntu6/debian/changelog.dch.save
/fst/trees/ubuntu/universe/d/ddtp-translations/ddtp-translations_20160408.1/debian/.changelog.dch.swp
/fst/trees/ubuntu/universe/f/filtergen/filtergen_0.12.4-5.1ubuntu1/debian/changelog.dch
/fst/trees/ubuntu/universe/l/lwm/lwm_1.2.2-2/debian/changelog.dch.save
/fst/trees/ubuntu/universe/l/lwm/lwm_1.2.2-2/debian/changelog.dch.save.1
/fst/trees/ubuntu/universe/libg/libg15/libg15_1.2.7-2ubuntu1/debian/changelog.dch.save
/fst/trees/ubuntu/universe/libg/libg15/libg15_1.2.7-2ubuntu2/debian/changelog.dch.save
/fst/trees/ubuntu/universe/m/moonshot-trust-router/moonshot-trust-router_1.4.1-1ubuntu1/debian/changelog.dch
/fst/trees/ubuntu/universe/p/parso/parso_0.5.1-0.1/debian/changelog.dch.save
/fst/trees/ubuntu/universe/p/parso/parso_0.5.2-1/debian/changelog.dch.save
/fst/trees/ubuntu/universe/p/parso/parso_0.5.2-1ubuntu1/debian/changelog.dch.save
/fst/trees/ubuntu/universe/p/parso/parso_0.7.0-1/debian/changelog.dch.save
/fst/trees/ubuntu/universe/p/parso/parso_0.8.0-0ubuntu1/debian/changelog.dch.save
/fst/trees/ubuntu/universe/p/parso/parso_0.8.1-1/debian/changelog.dch.save
/fst/trees/ubuntu/universe/r/rsstail/rsstail_1.8-1/debian/changelog.dch
/fst/trees/ubuntu/universe/s/shed/shed_1.15-4/debian/changelog.dch
/fst/trees/ubuntu/universe/t/trapperkeeper-webserver-jetty9-clojure/trapperkeeper-webserver-jetty9-clojure_4.1.0-2/debian/changelog.dch

Some of these exist in the Debian packages, as well:

https://codesearch.debian.net/search?q=debian+path%3Adebian%2Fchangelog.dch=0

I'd like to suggest a lintian warning for files matching the glob
debian/*changelog.dch*

It's possible this could or should be part of duplicate-changelog-files:
https://lintian.debian.org/tags/duplicate-changelog-files

Paul Wise pointed out to me some odd patterns in the output of:
apt-file --regex -I dsc search ^/debian/[^/]*changelog | grep -v ': 
/debian/changelog$'

Unfortunately I don't currently have working dsc indexes, so I'm not
entirely sure what these patterns look like.

Bug#858596: hello

[johnwinery]

Greeting ,I had written an earlier mail to you but without response

Bug#659460:

[johnwinery]

Greeting ,I had written an earlier mail to you but without response

Bug#1010495: iwyu: Depends: clang version is incorrect

[Alejandro Colomar]

Package: iwyu
Version: 8.18-1
Severity: important
X-Debbugs-Cc: alx.manpa...@gmail.com

Hi,

iwyu 0.18 requires clang 14.  See the dependency table here:
.

I noticed because I just upgraded my system from Debian stable to unstable,
and I until I installed (manually) clang-14, iwyu(1) didn't work:

 In file included from tmp/src/man2/add_key.2.d/add_key.c:2:
 /usr/include/x86_64-linux-gnu/sys/types.h:144:10: fatal error: 'stddef.h' file 
not found
 #include 
  ^~

After installing clang-14, the issue is fixed.
Please, fix the dependencies of the iwyu package.


Thanks,

Alex



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

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

Versions of packages iwyu depends on:
ii  clang   1:13.0-54
ii  clang-131:13.0.1-3+b2
ii  clang-141:14.0.3-1
ii  libc6   2.33-7
ii  libclang-cpp14  1:14.0.3-1
ii  libllvm14   1:14.0.3-1
ii  libstdc++6  12-20220428-1
ii  python3 3.10.4-1+b1

iwyu recommends no packages.

iwyu suggests no packages.

-- no debconf information

Bug#1010493: ltrace: FTBFS on mipsel: directive argument is null

[Paul Gevers]

Control: notfound -1 0.7.3-6.1
Control: found -1 0.7.3-6.2

On 02-05-2022 21:19, Paul Gevers wrote:

Source: ltrace
Version: 0.7.3-6.1


Oops, this goes wrong when one files bugs on a testing system.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010494: RFS: usbrelay/1.0-1 -- USB HID relay driver

[Michal Sojka]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for package "usbrelay":

 * Package name: usbrelay
   Version : 1.0-1
   Upstream Author : Darryl Bond 
 * URL : https://github.com/darrylb123/usbrelay
 * License : GPL-2+, CC-BY-SA-4.0
 * Vcs : https://salsa.debian.org/wentasah/usbrelay
   Section : electronics


The package is officially maintained by DD Jan Dittberner, but he seems
to be no longer active, at least with this package. I contribute to the
development of the upstream package and from time to time, users report
problems that are caused by too old version of the package in the Debian
archive. Having more recent version in Debian would be beneficial.

The updated package is based on the version already in Debian and
introduces two additional binary packages to cover new functionality
provided by upstream. I tried to prepare the updated package as well as
I can, but this is my first attempt to prepare official Debian packaging
so I'm open to suggestions for improvement. The packaging is inspired by
official documentation as well as by Fedora packaging, which was created
recently by other contributors.

The source builds the following binary packages:

  usbrelay - USB HID relay driver
  python3-usbrelay - Python bindings for USB HID relay driver
  usbrelayd - MQTT client for USB HID relay driver

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/u/usbrelay/usbrelay_1.0-1.dsc

Changes since the last upload:

 usbrelay (1.0-1) unstable; urgency=medium
 .
   * New upstream version 1.0
   * Drop "v" prefix from the watch file
   * Drop 0001-make-CFLAGS-LDFLAGS-and-CPPFLAGS-customizable.patch
   * Update gcc9.patch (Closes: Bug#916557)
   * Pass Debian package version to the build system
   * Use upstream man page rather than Debian one
   * Override lintian soname error
   * Add python3-usbrelay package
   * Add usbrelayd package providing interface to MQTT
   * Update udev rules
   * Bump debhelper compatibility to 13 (no changes)
   * Bump Standards-Version to 4.6.0 (no changes)
   * Update copyright information
   * Announce the hardware support using AppStream
   * Add usbrelayd(8) manpage
   * Fix spelling error

Additional comments can be found in some commit messages at
https://salsa.debian.org/wentasah/usbrelay/-/commits/master.

Regards,
--
  Michal Sojka

Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [ITP] -- Open the system file manager and optionally select files in it

[Tino Mettler]

Hi,

I uploaded a new package to my mentors account.

dget -x 
https://mentors.debian.net/debian/pool/main/s/show-in-file-manager/show-in-file-manager_1.1.4-1.dsc

The only change to the last version is a 
debian/tests/autopkgtest-pkg-python.conf
file. Now the autopkgtest-pkg-python test passes.

Thanks and regards,
Tino

Bug#934258: Current status?

[julien . puydt]

Le lundi 02 mai 2022 à 18:54 +0200, Roland Mas a écrit :
> Updated status report:
> 
> Le 26/04/2022 à 17:20, Roland Mas a écrit :
> > Le 25/04/2022 à 12:45, Roland Mas a écrit :
> > 
> > > I've been delayed for a while, but I'm back on track. I'll 
> > > push/upload a big handful of packages, both to NEW and to Salsa,
> > > and 
> > > update my TODO-list accordingly. I'll send the update to this bug
> > > too.
> > > > What are you working on?
> > > Mostly NodeJS packages…
> > > > Is there a direction where I can push?
> > > 
> > > Certainly… but give me a day or two so that I can push my work in
> > > order to avoid duplicating efforts :-)
> > > 
> > There. I'm up-to-date with my past self, and here's what's missing 
> > (we're talking about NodeJS packages).
> > 
> > Not started on my side:
> > 
> > - codemirror

There's a libjs-codemirror in Debian already, providing a node-
codemirror, so perhaps there's nothing to do.

> > - y-codemirror

Looks non trivial.

> > - vscode-debugprotocol

Looks trivial.

> > - xterm-addon-fit

Looks like it needs a more recent xterm than we have -- and only then
it's simple. That might be tricky if the rdeps need the old version
(gitlab is one of them...).

> > - nteract/transform-vdom

Looks simple.

> > - vega-embed
> > - vega-lite

Looks like a pretty deep hierarchy ; I wonder what libjs-vega in Debian
provides.

> > (…and probably dependencies behind them)
> > 

Not probably : certainly.

> > Started but not working:
> > 
> > - blueprintjs (I pushed my current state of affairs; fails to build
> > so far, but a starting point)

I saw there was a few node-blueprintjs* repositories, indeed.
( https://salsa.debian.org/js-team?filter=blueprintjs )

> > - fortawesome-fontawesome-free (see my other mail: no source 
> > available, and I don't know what to do; split the part of
> > jupyterlab 
> > that depend on it into a separate package in contrib? try to make
> > do with a previous version?)
> > 

How is it related to the existing fonts-font-awesome package?

> > 
> > Probably soon to be uploaded:
> > 
> > - react-paginate and dependencies (but I have skeleton packages for
> > that chain -- I'll push them even as WIP, and upload when ready)
> 
> > - react-highlighter (same thing)
> Done.
> > 
> > - react-json-tree which is part of redux-devtools (same thing)
> Done.

Ok.

> > I'm welcoming help in the first two sections.

I think I'm going to have a look at node-xterm.

Cheers,

J.Puydt

Bug#1001652: Package new version of Rapid Photo Downloader (0.9.27)

[Tino Mettler]

severity 1001652 serious

The program reports a python error right at start and can not be used
after that, therefore rising severity.

Bug#1001652: Package new version of Rapid Photo Downloader (0.9.27)

[Tino Mettler]

severity 1001652 serious

The program reports a python error right at start and can not be used
after that, therefore rising severity.

thanks

Bug#1010493: ltrace: FTBFS on mipsel: directive argument is null

[Paul Gevers]

Source: ltrace
Version: 0.7.3-6.1
Severity: serious
Tags: ftbfs
Justification: FTBFS
X-Debbugs-Cc: Guilherme de Paula Xavier Segundo , Joao 
Eriberto Mota Filho 

Dear all,

Thanks for fixing RC bugs in your package. However, the last upload of ltrace 
failed to build from source on mipsel, while it built there successfully in the 
past. Can you please have a look?

Paul

https://buildd.debian.org/status/fetch.php?pkg=ltrace=mipsel=0.7.3-6.2=1649617481=0

Making all in mips
make[5]: Entering directory '/<>/sysdeps/linux-gnu/mips'
/bin/bash ../../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../../..  -I../../../sysdeps/linux-gnu/mips -I../../../sysdeps/linux-gnu  
  -I../../../sysdeps  -I../../..  -Wdate-time -D_FORTIFY_SOURCE=2 -Wall 
-Wsign-compare -Wfloat-equal -Wformat-security -Werror -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o plt.lo plt.c
/bin/bash ../../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../../..  -I../../../sysdeps/linux-gnu/mips -I../../../sysdeps/linux-gnu  
  -I../../../sysdeps  -I../../..  -Wdate-time -D_FORTIFY_SOURCE=2 -Wall 
-Wsign-compare -Wfloat-equal -Wformat-security -Werror -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o regs.lo regs.c
/bin/bash ../../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../../..  -I../../../sysdeps/linux-gnu/mips -I../../../sysdeps/linux-gnu  
  -I../../../sysdeps  -I../../..  -Wdate-time -D_FORTIFY_SOURCE=2 -Wall 
-Wsign-compare -Wfloat-equal -Wformat-security -Werror -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o trace.lo trace.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../.. 
-I../../../sysdeps/linux-gnu/mips -I../../../sysdeps/linux-gnu 
-I../../../sysdeps -I../../.. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall 
-Wsign-compare -Wfloat-equal -Wformat-security -Werror -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c plt.c  -fPIC -DPIC -o .libs/plt.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../.. 
-I../../../sysdeps/linux-gnu/mips -I../../../sysdeps/linux-gnu 
-I../../../sysdeps -I../../.. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall 
-Wsign-compare -Wfloat-equal -Wformat-security -Werror -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c regs.c  -fPIC -DPIC -o .libs/regs.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../.. 
-I../../../sysdeps/linux-gnu/mips -I../../../sysdeps/linux-gnu 
-I../../../sysdeps -I../../.. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall 
-Wsign-compare -Wfloat-equal -Wformat-security -Werror -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c trace.c  -fPIC -DPIC -o .libs/trace.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../.. 
-I../../../sysdeps/linux-gnu/mips -I../../../sysdeps/linux-gnu 
-I../../../sysdeps -I../../.. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall 
-Wsign-compare -Wfloat-equal -Wformat-security -Werror -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c regs.c -o regs.o >/dev/null 2>&1
In file included from /usr/include/stdio.h:866,
 from ../../../common.h:30,
 from plt.c:30:
In function ‘fprintf’,
inlined from ‘arch_elf_add_plt_entry’ at plt.c:359:3:
/usr/include/mipsel-linux-gnu/bits/stdio2.h:105:10: error: ‘%s’ directive 
argument is null [-Werror=format-overflow=]
  105 |   return __fprintf_chk (__stream, __USE_FORTIFY_LEVEL - 1, __fmt,
  |  ^~~~
  106 | __va_arg_pack ());
  | ~
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../.. 
-I../../../sysdeps/linux-gnu/mips -I../../../sysdeps/linux-gnu 
-I../../../sysdeps -I../../.. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall 
-Wsign-compare -Wfloat-equal -Wformat-security -Werror -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c trace.c -o trace.o >/dev/null 2>&1
cc1: all warnings being treated as errors

Bug#1010409: transition: openimageio

[Matteo F. Vescovi]

Hi Sebastian!

On 2022-05-01 at 11:37 (+02), Sebastian Ramacher wrote:
> None of the reverse dependencies are currently in testing.
> Please feel free to go ahead at any time.

FTR, I've just uploaded -2 revision to unstable/sid.

Cheers.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#1010447: ibus-typing-booster: broken shebang line in emoji-picker

[Gunnar Hjalmarsson]

On 2022-05-02 18:41, Frank Dietrich wrote:

bookwork:~$ ls -litc /bin/sh /bin/dash /usr/bin/sh /usr/bin/dash
ls: cannot access '/usr/bin/sh': No such file or directory
ls: cannot access '/usr/bin/dash': No such file or directory
130809 lrwxrwxrwx 1 root root4 2022-03-23 00:56 /bin/sh -> dash
130553 -rwxr-xr-x 1 root root 123K 2022-03-23 00:56 /bin/dash


Thanks for elaborating on the behavior. I'll upload a fix.

--
Cheers,
Gunnar

Bug#1010492: fwupd: notify firmware update not only when laptop is plugged in

[Patrice Duroux]

Package: fwupd
Version: 1.7.7-1
Severity: wishlist

Dear Maintainer,

I discovered an available firmware update only by «accident» after using
directly the command line:

patrice@kos-moceratops ~ [1]> LANG=C fwupdmgr get-releases
Choose a device:
0.  Cancel
1.  03281da317dccd2b18de2bd1cc70a782df40ed7e (KXG60ZNV256G NVMe KIOXIA
256GB)
2.  a45df35ac0e948ee180fe216a5f703f32dda163f (System Firmware)
2
No releases found: Device System Firmware
[a45df35ac0e948ee180fe216a5f703f32dda163f] does not currently allow updates:
Cannot install update when not on AC power

Then I plug it in and got an available update waiting since long ago.

I mean getting the release is NOT applying for its update, isn't it?
And for sure using GNOME software (or GNOME firmware) for instance did not
notify or
alert about this neither (not even to plug in the laptop).

Thanks,
Patrice


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

Kernel: Linux 5.17.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 fwupd depends on:
ii  libc6  2.33-7
ii  libcurl3-gnutls7.83.0-1
ii  libefiboot137-6
ii  libflashrom1   1.2-5
ii  libfwupd2  1.7.7-1
ii  libfwupdplugin51.7.7-1
ii  libglib2.0-0   2.72.1-1
ii  libgnutls303.7.4-2
ii  libgudev-1.0-0 237-2
ii  libgusb2   0.3.10-1
ii  libjcat1   0.1.9-1
ii  libjson-glib-1.0-0 1.6.6-1
ii  libmbim-glib4  1.26.2-1
ii  libmbim-proxy  1.26.2-1
ii  libmm-glib01.18.6-2
ii  libpolkit-gobject-1-0  0.105-33
ii  libprotobuf-c1 1.3.3-1+b2
ii  libqmi-glib5   1.30.4-2
ii  libqmi-proxy   1.30.4-2
ii  libsmbios-c2   2.4.3-1
ii  libsqlite3-0   3.38.3-1
ii  libsystemd0250.4-1
ii  libtss2-esys-3.0.2-0   3.2.0-1
ii  libxmlb2   0.3.8-1
ii  shared-mime-info   2.2-1

Versions of packages fwupd recommends:
ii  bolt   0.9.2-1
ii  dbus   1.14.0-1
ii  fwupd-amd64-signed [fwupd-signed]  1:1.2+3
ii  python33.10.4-1+b1
pn  secureboot-db  
ii  udisks22.9.4-1

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

-- no debconf information

Bug#1010491: ruby-kramdown: 2.4 is available upstream

[Daniel Kahn Gillmor]

Package: ruby-kramdown
Version: 2.3.1-4
Severity: wishlist
Control: affects -1 + src:ruby-kramdown-rfc2629

Hi Ruby team--

The kramdown gem version 2.4 is available upstream.  The
kramdown-rfc2629 gem now depends on version 2.4 (as of kramdown-rfc
1.6.7; debian is at 1.6.6), so it'd be great to have ruby-kramdown
updated in debian.

Thanks!

--dkg


signature.asc
Description: PGP signature

Bug#1010485: plocate PRUNE_BIND_MOUNTS incompatible with btrfs subvolumes

[Steinar H. Gunderson]

On Mon, May 02, 2022 at 06:47:46PM +0200, Julian Andres Klode wrote:
> It says to make / as subvolume as well, which seems incomplete, as
> mounted at / is the subvolume @ (that's the standard Ubuntu layout);

That would be to make it at @root or similar.

> updatedb needs to parse /proc/mounts, look for subvol= flag, and
> for each subvol= traverse the shortest path (or first path it sees).

There's no way you can meaningfully say that /a is shorter than /b.
And the order Linux gives you a directory entry back is pretty much random,
so “first it sees“ would be a nightmare for incremental updatedb.

If you don't want bind mounts pruned (and that includes btrfs subvolumes
on the inside of each other), you'll need to turn off the bind mount pruning
option. Or you'd have to fix btrfs so that it doesn't implement subvolumes
as bind mounts :-)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#934258: Current status?

[Roland Mas]

Updated status report:

Le 26/04/2022 à 17:20, Roland Mas a écrit :

Le 25/04/2022 à 12:45, Roland Mas a écrit :

I've been delayed for a while, but I'm back on track. I'll 
push/upload a big handful of packages, both to NEW and to Salsa, and 
update my TODO-list accordingly. I'll send the update to this bug too.

What are you working on?

Mostly NodeJS packages…

Is there a direction where I can push?


Certainly… but give me a day or two so that I can push my work in 
order to avoid duplicating efforts :-)


There. I'm up-to-date with my past self, and here's what's missing 
(we're talking about NodeJS packages).


Not started on my side:

- codemirror

- y-codemirror

- vscode-debugprotocol

- xterm-addon-fit

- nteract/transform-vdom

- vega-embed

- vega-lite

(…and probably dependencies behind them)


Started but not working:

- blueprintjs (I pushed my current state of affairs; fails to build so 
far, but a starting point)


- fortawesome-fontawesome-free (see my other mail: no source 
available, and I don't know what to do; split the part of jupyterlab 
that depend on it into a separate package in contrib? try to make do 
with a previous version?)



Probably soon to be uploaded:

- react-paginate and dependencies (but I have skeleton packages for 
that chain -- I'll push them even as WIP, and upload when ready)



- react-highlighter (same thing)

Done.


- react-json-tree which is part of redux-devtools (same thing)

Done.

I'm welcoming help in the first two sections.

Roland.

Bug#1010397: Fwd: Bug#1010397: git-annex sync fails in rsync remotes with rsync 3.2.4-1

[Joey Hess]

Joey Hess wrote:
> The rsync command that git-annex runs has a trailing close quote, as
> seen in the first excerpt above. But rsync then complains about the path
> with that close quote removed.
> 
> I'm having a hard time not seeing this as a bug in rsync.

# NEWS for rsync 3.2.4 (15 Apr 2022)

## Changes in this version:

### BEHAVIOR CHANGES:

 - A new form of arg protection was added that works similarly to the older
   [`--protect-args`](rsync.1#opt) (`-s`) option but in a way that avoids
   breaking things like rrsync (the restricted rsync script): rsync now uses
   backslash escaping for sending "shell-active" characters to the remote
   shell. This includes spaces, so fetching a remote file via a simple quoted
   filename value now works by default without any extra quoting

This change must be the cause of the problem.

git-annex can be configured to not do its own shell escaping when accessing
a rsync special remote. If your remote is named "foo", you can configure it
that way as follows:

git-annex enableremote foo shellescape=no

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1010485: plocate PRUNE_BIND_MOUNTS incompatible with btrfs subvolumes

[Julian Andres Klode]

On Mon, May 02, 2022 at 05:46:42PM +0200, Steinar H. Gunderson wrote:
> On Mon, May 02, 2022 at 05:23:08PM +0200, Julian Andres Klode wrote:
> > plocate considers all mount points of a btrfs as bind mounts,
> > so when I have a somewhat usual case of subvolumes, e.g.
> 
> Hi,
> 
> It considers them as bind mounts because btrfs implements subvolumes
> as bind mounts. This is documented in updatedb.conf(5) (which refers to
> btrfs-subvolume(8) and shows a workaround), so I'm closing this.

It says to make / as subvolume as well, which seems incomplete, as
mounted at / is the subvolume @ (that's the standard Ubuntu layout);
the actual non-subvolume / is only mounted at /mnt for managing
snapshots (later /var/lib/apt-btrfs-snapshot).

updatedb needs to parse /proc/mounts, look for subvol= flag, and
for each subvol= traverse the shortest path (or first path it sees).

Essentially this is broken for btrfs users now unless they only
mount once. Which doesn't *always* work for various reasons, e.g.
if you want to snapshot / but not /var/log, you have to have them
be subvolumes /@ and /@log such that you backup the former. If you
had / and /var/log were a direct subvolume, you'd lose it on restore.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1010397: Fwd: Bug#1010397: git-annex sync fails in rsync remotes with rsync 3.2.4-1

[Joey Hess]

>   [2022-04-30 13:00:20.39881781] (Utility.Process) process [1635096] read: 
> rsync ["-e","'ssh' '-S' '../.git/annex/ssh/user@host-key' '-o' 
> 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-l' 'user' 
> '-T'","--progress","--inplace",
> "user@host-key:/backup/dspace/repositories/repository.git/ff7/84a/'GPGHMACSHA1--f5a2f4c1b3562feff26d0d1d6db70298087fd851/GPGHMACSHA1--f5a2f4c1b3562feff26d0d1d6db70298087fd851'"
> ,"../.git/annex/tmp/GPGHMACSHA1--f5a2f4c1b3562feff26d0d1d6db70298087fd851"]

>   rsync: [sender] change_dir 
> "/backup/dspace/repositories/repository.git/ff7/84a/'GPGHMACSHA1--f5a2f4c1b3562feff26d0d1d6db70298087fd851"
>  failed: No such file or directory (2)

The rsync command that git-annex runs has a trailing close quote, as
seen in the first excerpt above. But rsync then complains about the path
with that close quote removed.

I'm having a hard time not seeing this as a bug in rsync.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1010488: win32-loader: please annotate the wine Build-Depends with

[Paul Gevers]

Source: win32-loader
Version: 0.10.4
Severity: normal
Tags: patch
X-Debbugs-Cc: Thomas Gaugler 

Dear maintainers,

As part of my Release Team member checks, I have been investigating
why the RC buggy src:vkd3d is part of the key package set. It turns
out that vkd3d is part of the current key package set because it's
needed to build and run wine and wine is needed because it's a
Build-Depends of win32-loader. I checked the source code of
win32-loader and I got the impression wine is only used during testing
(on i386). After I mentioned this on IRC, kibi confirmed that the
content of the package didn't change without wine installed during the
build, confirming my idea.

If our analysis wasn't flawed, can you please annotate the wine
Build-Depends with the  profile to indicate it's only needed
during testing? (If there are other Build-Depends also only needed,
please mark those too.) It would make my live as a Release Team member
a tiny bit easier.

Paul

Bug#1010487: Old version is provided, 6 instead of 8

[Bjarni Ingi Gislason]

Package: rsbackup
Severity: normal

Dear Maintainer,

  The Debian uses version 6, which is out of date as the current is
version 8.

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

Kernel: Linux 5.17.3-1 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages rsbackup depends on:
pn  libboost-filesystem1.74.0  
ii  libc6  2.33-7
ii  libgcc-s1  12-20220319-1
ii  libsqlite3-0   3.38.2-1
ii  libstdc++6 12-20220319-1
ii  rsync  3.2.4-1

Versions of packages rsbackup recommends:
ii  openssh-client  1:9.0p1-1
ii  openssh-server  1:9.0p1-1

rsbackup suggests no packages.

-- 
Bjarni I. Gislason

Bug#1010069: [Pkg-javascript-devel] Bug#1010069: nodejs: FTBFS test failure on mipsel-osuosl-05.debian.org

[Jérémy Lal]

Le sam. 23 avr. 2022 à 17:18, Jérémy Lal  a écrit :

> Package: nodejs
> Version: 16.13.2+really14.19.1~dfsg-6
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the
> past)
>
>
> https://buildd.debian.org/status/fetch.php?pkg=nodejs=mipsel=16.13.2%2Breally14.19.1~dfsg-6%2Bb1=1650719824=log
>
>   ...
> not ok 185 parallel/test-buffer-writefloat
>

This test assumes a specific internal representation of NaN, which
obviously isn't the one it expects on that CPU.
Lowering severity.
I'll mark the test as flaky on that arch in the next upload.

Jérémy

Bug#1010485: plocate PRUNE_BIND_MOUNTS incompatible with btrfs subvolumes

[Julian Andres Klode]

Package: plocate
Version: 1.1.15-1
Severity: normal
X-Debbugs-Cc: juli...@ubuntu.com

plocate considers all mount points of a btrfs as bind mounts,
so when I have a somewhat usual case of subvolumes, e.g.

/dev/mapper/ubuntu--vg-root / btrfs defaults,compress=zstd,subvol=@ 0 1
/dev/mapper/ubuntu--vg-root /var/cache/squid-deb-proxy btrfs 
defaults,subvol=@squid 0 2
/dev/mapper/ubuntu--vg-root /var/log btrfs defaults,subvol=@log 0 2
/dev/mapper/ubuntu--vg-root /var/cache/apt/archives btrfs 
defaults,subvol=@apt 0 2
/dev/mapper/ubuntu--vg-root /mnt btrfs defaults 0 2

plocate does not find anything as it considers / to be a bind mount and
then updatedb exits immediately. Special casing / also would not work,
it would not locate anything in the other subvolumes.

Originally reported at 
https://bugs.launchpad.net/ubuntu/+source/plocate/+bug/1968190


-- System Information:
Debian Release: bookworm/sid
  APT prefers kinetic
  APT policy: (500, 'kinetic'), (500, 'jammy-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-25-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
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 plocate depends on:
ii  libc6   2.35-0ubuntu3
ii  libgcc-s1   12-20220319-1ubuntu1
ii  libstdc++6  12-20220319-1ubuntu1
ii  liburing2   2.1-2build1
ii  libzstd11.4.8+dfsg-3build1

plocate recommends no packages.

Versions of packages plocate suggests:
ii  powermgmt-base  1.36
ii  systemd-sysv249.11-0ubuntu3

-- Configuration Files:
/etc/updatedb.conf changed [not included]

-- no debconf information

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1010486: metapixel: reproducible-builds: Embedded build path in /usr/bin/metapixel

[Vagrant Cascadian]

Source: metapixel
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in /usr/bin/metapixel and
/usr/bin/metapixel-imagesize:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/metapixel.html

  /build/1st/metapixel-1.0.2/rwimg/readimage.c:115
  vs.
  /build/2/metapixel-1.0.2/2nd/rwimg/readimage.c:115


The attached patch to debian/rules fixes this by passing the
-ffile-prefix-map compiler flag via dh_auto_build.


With this patch applied metapixel should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining metapixel!


live well,
  vagrant
From 66bf12a0ef3d945b04d04adb8904d2146d17ab67 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 2 May 2022 15:13:03 +
Subject: [PATCH] debian/rules: Pass -ffile-prefix-map to dh_auto_build.

This avoids embedding the absolute build path in /usr/bin/metapixel*

https://reproducible-builds.org/docs/build-path/
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index d58bd31..8975aef 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,7 +8,7 @@ MANDIR = $(PREFIX)/usr/share/man
 	dh $@
 
 override_dh_auto_build:
-	dh_auto_build -- MANPAGE_XSL=/usr/share/sgml/docbook/stylesheet/xsl/nwalsh/manpages/docbook.xsl
+	dh_auto_build -- PROFILE="-ffile-prefix-map=$(CURDIR)=." MANPAGE_XSL=/usr/share/sgml/docbook/stylesheet/xsl/nwalsh/manpages/docbook.xsl
 
 override_dh_auto_install:
 	dh_auto_install -- PREFIX=$(PREFIX) BINDIR=$(BINDIR) MANDIR=$(MANDIR)
-- 
2.36.0



signature.asc
Description: PGP signature

Bug#1010480: virtualenv: skip creating of .gitignore when creating virtualenv in .

[stefanor]

Tag: -1 + upstream

This sounds like a purely upstream bug, I'd encourage you to file it at:
https://github.com/pypa/virtualenv

FWIW, I see a very similar issue:
https://github.com/pypa/virtualenv/issues/2003
that was resolved by adding a command line flag.

SR

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

Bug#1010484: src:libigloo: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Source: libigloo
Version: 0.9.0-1
Severity: serious
Control: close -1 0.9.1-1
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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:libigloo has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package failed to build from 
source on s390x while it built successfully there in the past.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=libigloo



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010483: coinor-cgl: reproducible-builds: Embedded build path in example Makefile

[Vagrant Cascadian]

Source: coinor-cgl
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in 
/usr/share/doc/coinor-libcgl-doc/examples/Makefile:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/coinor-cgl.html

  
CXXFLAGS·=·-g·-O2·-ffile-prefix-map=/build/1st/coinor-cgl-0.60.3+repack1=.·-fstack...
  vs.
  
CXXFLAGS·=·-g·-O2·-ffile-prefix-map=/build/2/coinor-cgl-0.60.3+repack1/2nd=.·-fstack...

The attached patch fixes this by replacing the build path with a
placeholder string in debian/rules.


With this patch applied coinor-cgl should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining coinor-cgl!


live well,
  vagrant
From ead6f2b5d0b1e0b03d0f607c6d91fa7ef7db8149 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 2 May 2022 13:40:30 +
Subject: [PATCH] debian/rules: Replace the build path in example Makefile with
 a placeholder string.

https://reproducible-builds.org/docs/build-path/
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index 3e66c59..d471945 100755
--- a/debian/rules
+++ b/debian/rules
@@ -18,3 +18,7 @@ override_dh_auto_configure:
 execute_after_dh_auto_build:
 	make doxydoc
 	$(RM) doxydoc/html/*.md5 doxydoc/html/*.dot doxydoc/html/*.map
+
+execute_before_dh_installexamples:
+	# Remove full build path from example Makefile
+	sed -i -e "s,prefix-map=$(CURDIR),prefix-map=BUILDPATH,g" Cgl/examples/Makefile
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1010447: ibus-typing-booster: broken shebang line in emoji-picker

[Gunnar Hjalmarsson]

Thanks Boyuan. I'm slowly getting the picture.

On my installs (both Debian and Ubuntu) I only see this:

~$ cd /
/$ ls -l bin lib* sbin
lrwxrwxrwx 1 root root  7 29 jul  2021 bin -> usr/bin
lrwxrwxrwx 1 root root  7 29 jul  2021 lib -> usr/lib
lrwxrwxrwx 1 root root  9 29 jul  2021 lib32 -> usr/lib32
lrwxrwxrwx 1 root root  9 29 jul  2021 lib64 -> usr/lib64
lrwxrwxrwx 1 root root 10 29 jul  2021 libx32 -> usr/libx32
lrwxrwxrwx 1 root root  8 29 jul  2021 sbin -> usr/sbin

But now I understand that this is not the case on all Debian systems.

So I'm thinking that I should simply add a patch which reverses this:

https://github.com/mike-fabian/ibus-typing-booster/commit/40718d53

Would that be the proper step to take?

--
Gunnar

Bug#1010369: RediSearch Upstream Needs Swapped out from version 1 to version 2

[Kevin Shenk]

Gotcha. That's too bad. Thanks much for your clarifications!

--
Kevin Shenk
Avunu LLC
On 4/30/2022 8:17:04 PM, Chris Lamb  wrote:
Hi,

> I see, that's too bad... is it easy to specify what the Redis Ltd would
> need to change to make their license compatible?

Yes, but that's not quite the issue. They are already aware of the
situation and (to reduce a very long and complex discussion into a
single sentence) the license incompatibility is essentially deliberate
and not an accidental oversight.


Regards,

--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org  chris-lamb.co.uk
`-


[73a1f1d0-fdc7-42dd-9435-5a628e5c55ae]

Bug#1010480: virtualenv: skip creating of .gitignore when creating virtualenv in .

[IOhannes m zmoelnig]

Package: virtualenv
Version: 20.14.0+ds-1
Severity: wishlist

Dear Maintainer,

'virtualenv' creates a .gitignore file that just excludes everything from git.
this is practical, if you do something like this:

```
virtualenv myenv
```

as this will just exclude everything in the myenv/ folder from git
(which is what you usually want).

now, for convenience, i find myself using the following quite often:

```
virtualenv .
```

this will (unfortunately) create a .gitignore file in my current directory
that will ignore everything (including the sources i'm currently working on)

i think, that in the special case of creating a virtualenv in the current
directory, no .gitignore file should be created (or it should be tightened to
just ignore the files managed by virtualenv, which afaict are
- /bin/
- /lib/
- /pyenv.cfg
)

luckily, virtualenv won't overwrite any existing .gitignore file (so not all is
lost).

cheers,
IOhannes m zmölnig

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

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

Versions of packages virtualenv depends on:
ii  python3-virtualenv  20.14.0+ds-1

virtualenv recommends no packages.

virtualenv suggests no packages.

-- no debconf information

Bug#1010479: mirror listing update for fastmirror.pp.ua

[Ivan Barabash]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: fastmirror.pp.ua
Type: leaf
Archive-architecture: amd64 arm64 i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Ivan Barabash 
Country: UA Ukraine
Location: Kyiv




Trace Url: http://fastmirror.pp.ua/debian/project/trace/
Trace Url: http://fastmirror.pp.ua/debian/project/trace/ftp-master.debian.org
Trace Url: http://fastmirror.pp.ua/debian/project/trace/fastmirror.pp.ua

Bug#1010342: Refuses to create directories for unburdening

[Didier 'OdyX' Raboud]

Control: tags -1 -moreinfo

30 avril 2022 00:17 "Axel Beckert"  a écrit:
> Didier 'OdyX' Raboud wrote:
>> With 0.4.2, after noticing my directories didn't get symlinked, I tried to
>> run unburden-home-dir by hand and I got the following error(s) (with or
>> without -F):
> 
> Thanks for the bug report!
> 
>> WARNING: Can't handle /home/didier/.cache: /tmp/.unburden-didier/cache not 
>> equal
>> /run/user/1000/.unburden-didier/cache at /usr/bin/unburden-home-dir line 
>> 245, <$list_fh> line 2
> 
> This basically means that to wants symlink files elsewhere than before.
> 
>> I haven't spent much time investigating; as 0.4.1.2 works for me now.
>> 
>> Anything I could do to help?
> 
> The output of "env | fgrep XDG_" might be helpful.

Here comes (that's on my other local user 'diidier'):

$ env | fgrep XDG
XDG_CACHE_HOME=/run/user/1001/.unburden-diidier/cache
XDG_CONFIG_DIRS=/home/diidier/.config/kdedefaults:/etc/xdg
XDG_CURRENT_DESKTOP=KDE
XDG_DATA_DIRS=/home/diidier/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
XDG_RUNTIME_DIR=/run/user/1001
XDG_SEAT=seat0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=KDE
XDG_SESSION_ID=3
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session2
XDG_SESSION_TYPE=x11
XDG_VTNR=7

> The weird thing is that there weren't any changes which explains that
> out of the box:
> (…)
> Then again, I noticed this, too, on one of my hosts. I thought I might
> have toyed with a non-standard config for testing one of the changes
> mentioned above and just uncommented this line in
> /etc/unburden-home-dir to make it work again:
> 
> #TARGETDIR=/tmp

According to etckeeper, this went commented (and still is) on the upgrade from 
0.3.3 to 0.4.

> (But before you do the same change, please read until the end of this
> mail and do "stat" that file.)
> 
> Actually this looks a bit like a result of this commit from 2015 between
> 0.3.3 and 0.4:
> 
> commit 65f632b73c7a78e6f30aae143eebb95e5bb15866
> Author: Axel Beckert 
> Date: Sun Jul 5 01:43:27 2015 +0200
> 
> Don't set TARGETDIR in config by default but compute a sane
> default value
> 
> The default value is determined as follows:
> 
> - Use $TARGETDIR if set in the configuration file.
> - Else use $XDG_RUNTIME_DIR/$UID if it exists.
> - Else use /run/user/$UID if it exists.
> - Else use $TMPDIR if it exists.
> - Else use /tmp/.
> 
> Requires new runtime dependency libfile-slurp-perl.
> 
> For coverage computation, the test suite is run twice, once with
> and once without $TMPDIR and $XDG_RUNTIME_DIR being set.
> 
> Closes: #780387
> 
> So I wonder if for some reason the /etc/unburden-home-dir conffile got
> updated this time while it didn't get update with quite a lot of
> previous updates.
> 
> Can you also send me the output of "stat /etc/unburden-home-dir" in
> case you didn't edit it since the update.

$ LANG=C stat /etc/unburden-home-dir
  File: /etc/unburden-home-dir
  Size: 119 Blocks: 2  IO Block: 1024   regular file
Device: fd01h/64769dInode: 34780   Links: 1
Access: (0644/-rw-r--r--)  Uid: (0/root)   Gid: (0/root)
Access: 2022-05-02 08:44:06.0 +0200
Modify: 2016-05-13 03:15:21.0 +0200
Change: 2016-05-15 19:21:02.0 +0200
 Birth: -

What I don't understand is why the symlinks currently point to /tmp, why it 
wants to change them to /run/user/… now, and why it cannot "go through" that 
change now. Refusing to update the symlinks seems overly defensive, isn't it?

Best,

Didier

Bug#1010128: Duplicates

[Stephan Verbücheln]

Another one:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010424

Bug#1010478: libmutter-10-0: gnome-shell crash to gdm after suspend, libmutter segfault. After relogin monitors.xml is ignored

[Krassy Boykinov]

Package: libmutter-10-0
Version: 42.0-4
Severity: important

gnome-shell crashes with a segfault in libmutter after suspend, only 
reproducible when connected to a Lenovo ThinkPad Thunderbolt Dock Gen. 1 
with two external monitors.
After re-login with gdm the monitors are arranged in a straight line 
(default configuration), monitors.xml is ignored. Some similarity to Bug 
#927275.


Syslog lines:
May  2 13:03:41 machine kernel: [ 1595.548042] gnome-shell[2795]: 
segfault at 20 ip 7f2581507160 sp 7fff7b47f188 error 4 in 
libmutter-10.so.0.0.0[7f2581408000+14d000]
May  2 13:03:41 machine kernel: [ 1595.548052] Code: 06 71 f0 ff 48 
8b 3d 27 89 0f 00 be 50 00 00 00 e8 05 ac f0 ff 48 89 ef 5d 48 8b 40 30 
ff e0 66 66 2e 0f 1f 84 00 00 00 00 00 <48> 8b 7f 20 e9 e7 5f f0 ff 0f 
1f 80 00 00 00 00 48 8b 47 18 48 85


Debian bookworm runs on a ThinkPad T470.


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

Kernel: Linux 5.17.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 libmutter-10-0 depends on:
ii  adwaita-icon-theme 42.0-2
ii  gsettings-desktop-schemas  42.0-1
ii  libatk1.0-02.38.0-1
ii  libc6  2.33-7
ii  libcairo-gobject2  1.16.0-5
ii  libcairo2  1.16.0-5
ii  libcanberra0   0.30-10
ii  libdrm22.4.110-1
ii  libegl11.4.0-1
ii  libfontconfig1 2.13.1-4.4
ii  libfribidi01.0.8-2.1
ii  libgbm121.3.8-1
ii  libgdk-pixbuf-2.0-02.42.8+dfsg-1
ii  libgl1 1.4.0-1
ii  libglib2.0-0   2.72.1-1
ii  libgnome-desktop-3-19  42.0-2
ii  libgraphene-1.0-0  1.10.8-1
ii  libgtk-3-0 3.24.33-1
ii  libgudev-1.0-0 237-2
ii  libice62:1.0.10-1
ii  libinput10 1.20.1-1
ii  libjson-glib-1.0-0 1.6.6-1
ii  libpango-1.0-0 1.50.6+ds-2
ii  libpangocairo-1.0-01.50.6+ds-2
ii  libpangoft2-1.0-0  1.50.6+ds-2
ii  libpipewire-0.3-0  0.3.50-2
ii  libsm6 2:1.2.3-1
ii  libstartup-notification0   0.12-6+b1
ii  libsystemd0250.4-1
ii  libudev1   250.4-1
ii  libwacom9  2.2.0-1
ii  libwayland-server0 1.20.0-1
ii  libx11-6   2:1.7.5-1
ii  libx11-xcb12:1.7.5-1
ii  libxau61:1.0.9-1
ii  libxcb-randr0  1.14-3
ii  libxcb-res01.14-3
ii  libxcb11.14-3
ii  libxcomposite1 1:0.4.5-1
ii  libxcursor11:1.2.0-2
ii  libxdamage11:1.1.5-2
ii  libxext6   2:1.3.4-1
ii  libxfixes3 1:6.0.0-1
ii  libxi6 2:1.8-1
ii  libxinerama1   2:1.1.4-3
ii  libxkbcommon-x11-0 1.4.0-1
ii  libxkbcommon0  1.4.0-1
ii  libxkbfile11:1.1.0-1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxtst6   2:1.2.3-1
ii  mutter-common  42.0-4

libmutter-10-0 recommends no packages.

libmutter-10-0 suggests no packages.

Versions of packages libmutter-10-0 is related to:
ii  libegl-mesa0 [libegl-vendor]  21.3.8-1
ii  libgl1-mesa-dri   21.3.8-1
ii  libglx-mesa0 [libglx-vendor]  21.3.8-1

-- no debconf information

*** /tmp/crashlog.txt
May  2 12:41:27 machine kernel: [ 1588.567419] PM: suspend entry (deep)

May  2 13:03:40 machine kernel: [ 1588.575546] Filesystems sync: 0.008 
seconds


May  2 13:03:40 machine kernel: [ 1588.575738] (NULL device *): 
firmware: direct-loading firmware regulatory.db


May  2 13:03:40 machine kernel: [ 1588.575756] (NULL device *): 
firmware: direct-loading firmware regulatory.db.p7s


May  2 13:03:40 machine kernel: [ 1588.576338] (NULL device *): 
firmware: direct-loading firmware iwlwifi-8265-36.ucode


May  2 13:03:40 machine kernel: [ 1588.576536] Freezing user space 
processes ... (elapsed 0.002 seconds) done.


May  2 13:03:40 machine kernel: [ 1588.578783] OOM killer disabled.

May  2 13:03:40 machine kernel: [ 1588.578784] Freezing remaining 
freezable tasks ... (elapsed 0.001 seconds) done.


May  2 13:03:40 machine kernel: [ 1588.580101] printk: Suspending 
console(s) (use no_console_suspend to debug)


May  2 13:03:40 machine kernel: [ 1588.611168] ipheth 7-2:4.2: Apple 
iPhone USB Ethernet now disconnected


May  2 13:03:40 machine kernel: [ 1588.780250] e1000e: EEE TX LPI TIMER: 
0011


May  2 13:03:40 machine kernel: [ 1589.065205] ACPI: EC: interrupt blocked

May  2 13:03:40 machine kernel: [ 1589.119294] ACPI: PM: Preparing to 
enter system sleep state S3


May  2 13:03:40 machine 

Bug#1002031: liquidprompt : does not remove temperature warning when temperature goes down

[Grégory Mounié]

Package: liquidprompt
Version: 2.0.3-1
Followup-For: Bug #1002031

Dear Maintainer,

In current github version, upstream adds around line 2473 in _lp_temperature()
an unset of lp_temperature variable.

_lp_temperature() {
(( LP_ENABLE_TEMP )) || return 2

unset lp_temperature
"$_LP_TEMP_FUNCTION"

[[ -z ${lp_temperature-} ]] && return 1
(( lp_temperature >= LP_TEMP_THRESHOLD ))
}

I had a similar issue. This solution solves my bug. It is independent of the
two measure collect program (acpi -t, sensors -u).


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

Kernel: Linux 5.17.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

liquidprompt depends on no packages.

liquidprompt recommends no packages.

Versions of packages liquidprompt suggests:
pn  acpi
ii  lm-sensors  1:3.6.0-7

-- no debconf information

Bug#1009000: Prelim Packaging

[Barak A. Pearlmutter]

I've done a prelim (UNRELEASED) packaging of 1.2, see packaging repo fork
https://salsa.debian.org/bap/paprefs

I've enabled CI, so if you go to CI/CD>Pipelines and click on the
"build" job, you should be able to download a built binary amd64
package as one of the "Job artifacts" on the right.

Bug#1010368: Maybe marshal nondeterminism?

[Johannes Schauer Marin Rodrigues]

Control: forwarded -1 https://github.com/python/cpython/issues/92132

Hi,

On Fri, 29 Apr 2022 21:00:52 -0700 Keith Amling  wrote:
> From skimming some of cpython's "marshal" code [1] my best guess is that
> first difference is between it thinking the `_m` string might have
> another reference to it (and thus adding 0x80, or FLAG_REF to it) or
> not.  This seems driven by whether or not python's object for the string
> has other references (it calls Py_REFCNT(v) to decide, see line 302).
> 
> I assume the difference is whether or not python has bothered to collect
> some other reference to the string or not.  Type "Z" is an interned
> string type, TYPE_SHORT_ASCII_INTERNED, which therefore makes sense that
> it might be shared with who knows what else.  I'm assuming this stops
> reproducing when you change it to a unique name since no one else will share
> the reference and you'll just deterministically get no FLAG_REF.

thank you! It was indeed about that line and there exists a pull request
upstream that fixes this issue:

https://github.com/python/cpython/pull/8226

Specifically, the following patch to python3.10 in Debian seems to solve this.
I also attached a full debdiff for your convenience. Thanks!

cheers, josch

>From 6c8ea7c1dacd42f3ba00440231ec0e6b1a38300d Mon Sep 17 00:00:00 2001
From: Inada Naoki 
Date: Sat, 14 Jul 2018 00:46:11 +0900
Subject: [PATCH] Use FLAG_REF always for interned strings

---
 Python/marshal.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/Python/marshal.c
+++ b/Python/marshal.c
@@ -298,9 +298,14 @@ w_ref(PyObject *v, char *flag, WFILE *p)
 if (p->version < 3 || p->hashtable == NULL)
 return 0; /* not writing object references */

-/* if it has only one reference, it definitely isn't shared */
-if (Py_REFCNT(v) == 1)
+/* If it has only one reference, it definitely isn't shared.
+ * But we use TYPE_REF always for interned string, to PYC file stable
+ * as possible.
+ */
+if (Py_REFCNT(v) == 1 &&
+!(PyUnicode_CheckExact(v) && PyUnicode_CHECK_INTERNED(v))) {
 return 0;
+}

 entry = _Py_hashtable_get_entry(p->hashtable, v);
 if (entry != NULL) {diff -Nru python3.10-3.10.4/debian/changelog python3.10-3.10.4/debian/changelog
--- python3.10-3.10.4/debian/changelog	2022-04-02 11:04:19.0 +0200
+++ python3.10-3.10.4/debian/changelog	2022-05-02 13:25:08.0 +0200
@@ -1,3 +1,10 @@
+python3.10 (3.10.4-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch to set FLAG_REF always for interned strings. Closes: #1010368
+
+ -- Johannes Schauer Marin Rodrigues   Mon, 02 May 2022 13:25:08 +0200
+
 python3.10 (3.10.4-3) unstable; urgency=medium
 
   * Build a python3.10-nopie package, diverting the python3.10
diff -Nru python3.10-3.10.4/debian/patches/series python3.10-3.10.4/debian/patches/series
--- python3.10-3.10.4/debian/patches/series	2022-04-02 11:04:19.0 +0200
+++ python3.10-3.10.4/debian/patches/series	2022-05-02 13:24:24.0 +0200
@@ -39,3 +39,4 @@
 fix-py_compile.diff
 reproducible-pyc.diff
 fix-ia64.diff
+use-FLAG_REF-always-for-interned-strings.diff
diff -Nru python3.10-3.10.4/debian/patches/use-FLAG_REF-always-for-interned-strings.diff python3.10-3.10.4/debian/patches/use-FLAG_REF-always-for-interned-strings.diff
--- python3.10-3.10.4/debian/patches/use-FLAG_REF-always-for-interned-strings.diff	1970-01-01 01:00:00.0 +0100
+++ python3.10-3.10.4/debian/patches/use-FLAG_REF-always-for-interned-strings.diff	2022-05-02 13:25:07.0 +0200
@@ -0,0 +1,37 @@
+From 5fe4c1442ded6bdc4c724935d118e996fa022eac Mon Sep 17 00:00:00 2001
+From: Inada Naoki 
+Date: Sat, 14 Jul 2018 00:46:11 +0900
+Subject: [PATCH] Use FLAG_REF always for interned strings
+
+https://bugs.debian.org/1010368
+https://github.com/python/cpython/pull/8226
+https://github.com/python/cpython/issues/92132
+
+---
+ Python/marshal.c | 9 +++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/Python/marshal.c b/Python/marshal.c
+index 4125240..341c9aa 100644
+--- a/Python/marshal.c
 b/Python/marshal.c
+@@ -298,9 +298,14 @@ w_ref(PyObject *v, char *flag, WFILE *p)
+ if (p->version < 3 || p->hashtable == NULL)
+ return 0; /* not writing object references */
+ 
+-/* if it has only one reference, it definitely isn't shared */
+-if (Py_REFCNT(v) == 1)
++/* If it has only one reference, it definitely isn't shared.
++ * But we use TYPE_REF always for interned string, to PYC file stable
++ * as possible.
++ */
++if (Py_REFCNT(v) == 1 &&
++!(PyUnicode_CheckExact(v) && PyUnicode_CHECK_INTERNED(v))) {
+ return 0;
++}
+ 
+ entry = _Py_hashtable_get_entry(p->hashtable, v);
+ if (entry != NULL) {
+-- 
+2.35.1
+


signature.asc
Description: signature

Bug#1010477: tzdata: reduce Installed-Size using deduplication

[Helmut Grohne]

Source: tzdata
Version: 2022a-1
Severity: wishlist
Tags: patch

tzdata is not a huge package, but when considering it for use in an
embedded system, the size is noticeable. Depending on the file system in
use, the size consumption may even be bigger due to the many small
files.

It turns out that a number of those files are duplicated. You can see a
report at https://dedup.debian.net/compare/tzdata/tzdata. If replacing
them with hardlinks, we can easily save 20% of reported Installed-Size.
I expect that the practical savings are bigger.

Please consider applying the attached patch. If you dislike hard links
for some reason, the same effect can be achieved using symlinks in a
similarly mechanical way.

Helmut
diff --minimal -Nru tzdata-2022a/debian/changelog tzdata-2022a/debian/changelog
--- tzdata-2022a/debian/changelog   2022-03-22 20:49:04.0 +0100
+++ tzdata-2022a/debian/changelog   2022-05-02 12:00:33.0 +0200
@@ -1,3 +1,10 @@
+tzdata (2022a-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Deduplicate files in timezone database using hard links.  Closes: #-1.
+
+ -- Helmut Grohne   Mon, 02 May 2022 12:00:33 +0200
+
 tzdata (2022a-1) unstable; urgency=high
 
   [ Aurelien Jarno ]
diff --minimal -Nru tzdata-2022a/debian/control tzdata-2022a/debian/control
--- tzdata-2022a/debian/control 2022-03-22 20:47:25.0 +0100
+++ tzdata-2022a/debian/control 2022-05-02 12:00:33.0 +0200
@@ -2,7 +2,7 @@
 Section: localization
 Priority: required
 Build-Depends: debhelper-compat (= 13)
-Build-Depends-Indep: gawk, po-debconf, symlinks
+Build-Depends-Indep: gawk, po-debconf, symlinks, rdfind
 Rules-Requires-Root: no
 Maintainer: GNU Libc Maintainers 
 Uploaders: Clint Adams , Aurelien Jarno 
diff --minimal -Nru tzdata-2022a/debian/rules tzdata-2022a/debian/rules
--- tzdata-2022a/debian/rules   2022-03-22 20:47:25.0 +0100
+++ tzdata-2022a/debian/rules   2022-05-02 12:00:32.0 +0200
@@ -76,6 +76,7 @@
echo ; \
done ) > $(TEMPLATES_FILE)
debconf-updatepo
+   rdfind -outputname /dev/null -makehardlinks true $(TZGEN)
 
 override_dh_auto_test:
# The upstream tests are related to the sources. Just skip it.
diff --minimal -Nru tzdata-2022a/debian/tzdata.lintian-overrides 
tzdata-2022a/debian/tzdata.lintian-overrides
--- tzdata-2022a/debian/tzdata.lintian-overrides1970-01-01 
01:00:00.0 +0100
+++ tzdata-2022a/debian/tzdata.lintian-overrides2022-05-02 
12:00:33.0 +0200
@@ -0,0 +1,2 @@
+# lintian bug #1010476
+tzdata: package-contains-hardlink *

Bug#1010476: lintian: package-contains-hardlink has way too many false positives

[Helmut Grohne]

Package: lintian
Version: 2.114.0

Hi,

lintian emits the tag package-contains-hardlink in a lot of situations
where that tag is not reasonable. The referenced policy entry only
quires that conffiles are not hard linked. Beyond that, the tag
description reasons that hard links could cross mount points. While
directories such as /usr can be reasonable mount points, deeper
directories are not reasonable. Hard links that fully remain inside
/usr/share seem quite reasonable to me.

If you look at the tags emitted at
https://lintian.debian.org/tags/package-contains-hardlink, you'll notice
that the majority of them apply to deeply nested hierarchies - often
owned by the relevant package.

I suggest to weaken this check. A hard link is only reported if one of
the involved locations resides within /etc or if one of the top N
directory levels differ. The value of N is up to discussion. Quite
certainly N >= 1 and to be useful, we'd likely need N <= 3.

Helmut

Bug#1010475: wiki.debian.org: wrong link to libreoffice-kf5

[Yngve Spjeld-Landro]

Package: wiki.debian.org
Severity: normal

Dear Maintainer,

Page
https://wiki.debian.org/Wayland#LibreOffice_.28supported.2C_not_by_default.29
contains errors with regard to libreoffice-kf5: it is written and referred to
as being libreoiffice-kf5.

Correct spelling is libreoffice-kf5 and the link should be
https://packages.debian.org/libreoffice-kf5.

Bug#1010471: [Pkg-javascript-devel] Bug#1010471: Bug#1010471: eslint: please move Recommends to Depends

[Jérémy Lal]

Le lun. 2 mai 2022 à 12:24, Jonas Smedegaard  a écrit :

> Quoting Jérémy Lal (2022-05-02 11:59:15)
> > Le lun. 2 mai 2022 à 11:54, Jonas Smedegaard  a écrit :
> >
> > > Quoting Jérémy Lal (2022-05-02 11:45:36)
> > > > I stand by saying as it is, putting those packages:
> > > > node-chalk
> > > > node-strip-ansi
> > > > node-text-table
> > > > in Recommends just breaks the default functionality of eslint.
> > >
> > > Ignoring recommends breaks systems.
> > >
> >
> > eslint is a build-dependency of enigmail (nothing odd about that).
> > When sbuild builds a package, it doesn't install recommended packages
> > of build-dependencies ?
>
> Correct: Build environments need recommendations explicitly declared as
> build-dependencies, when needed.
>

I don't discuss the usefulness of Recommends.

I'm trying to argue why in the particular case of eslint and of those three
packages
(mentioned above) you put in Recommends, it breaks eslint for other packages
Build-Depending on eslint.

Adding those Recommends in Build-Depends is not a good practice, IMO,
for this reasons:
- separation of concerns
- Build-Depends eslint does not install Recommends resulting in a broken
eslint
- when some eslint recommends change, build-dependent packages will just
break again !
- worse (because undetectable) build-dependent packages will uselessly
build-depend on
no longer required packages.

Is there a strong reason to put those three packages in Recommends ?
The economy of installing three additional small packages is outweighed by
the
over-engineering needed to cope with it.

Jérémy

Bug#1009017: [Bug #1009017] reproduction steps

[Attila Szalay]

Hello Mohammed Bilal,

I've checked the bug report and the attached build log but I have some
concern that it is actually related to libgit2.

The build process actually stops here:

Run-time dependency threads found: YES
Found pkg-config: /usr/bin/pkg-config (0.29.2)
Run-time dependency nanomsg found: YES 1.1.5
Found CMake: /usr/bin/cmake (3.23.0)
WARNING: CMake Toolchain: Failed to determine CMake compilers state
Run-time dependency nanopb found: NO 

and most probably the reason that it fails to detect nanopb is that the
cmake compiler has trouble compiling the test code.

A healthy run looks like this:
Run-time dependency threads found: YES
Found pkg-config: /usr/bin/pkg-config (0.29.2)
Run-time dependency nanomsg found: YES 1.1.5
Found CMake: /usr/bin/cmake (3.23.1)
Run-time dependency nanopb (modules: nanopb::protobuf-nanopb-static) found: YES 
0.4.5
Run-time dependency libgit2 found: YES 1.3.0

As you can see, the autoconfigure script not even reached checking the
libgit in the failed case. (Minor detail, in the successful case, the
CMake version is 3.23.1, not 3.23.0.

Unfortunately, based on the criticality I thought the new version of
the libgit2 library is already in unstable, so first I tried to upgrade
the criterion version and just started to investigate afterwards. So I
actually do not know if the old version is actually has any
incompatibility with the libgit2 version 1.3.0. But (with some tweak) I
was able to successfully compile the new Criterion version with the new
libgit2 version, I will simply close this ticket using the new version
Changelog.


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

Bug#1010471: [Pkg-javascript-devel] Bug#1010471: Bug#1010471: eslint: please move Recommends to Depends

[Jonas Smedegaard]

Quoting Jérémy Lal (2022-05-02 11:59:15)
> Le lun. 2 mai 2022 à 11:54, Jonas Smedegaard  a écrit :
> 
> > Quoting Jérémy Lal (2022-05-02 11:45:36)
> > > I stand by saying as it is, putting those packages:
> > > node-chalk
> > > node-strip-ansi
> > > node-text-table
> > > in Recommends just breaks the default functionality of eslint.
> >
> > Ignoring recommends breaks systems.
> >
> 
> eslint is a build-dependency of enigmail (nothing odd about that).
> When sbuild builds a package, it doesn't install recommended packages 
> of build-dependencies ?

Correct: Build environments need recommendations explicitly declared as 
build-dependencies, when needed.

That does not mean that the package is broken (as you wrote).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1010256: ITP: rust-ahash -- non-cryptographic hash function

[Jonas Smedegaard]

Quoting James McCoy (2022-05-02 03:09:12)
> The Rust team files ITPs for binary crates, not the library crates, as 
> the binary crates are generally more relevant to the broader Debian 
> audience.

Feel free to not coordinate *with the rest of Debian* what you are 
preparing *internally in the Rust team*.


> In terms of avoiding duplicate effort, the debcargo-conf repo _is_ 
> that mechansim for the Rust team.

Feel free to choose whatever mechanisms you prefer to coordinate efforts 
*internally in the Rust team*.


> You're choosing to ignore that and package things outside of the 
> team's infrastructure.

I choose to not join the Rust team.

It is *your* choice (not mine) to not coordinate *with the rest of 
Debian*.


> The Rust team isn't unique in using a single repo for all their 
> packages.

Correct.  But irrelevant for coordinating packaging preparation 
generally in Debian, which is what I am talking about.

It seems you talk about coordination *within th Rust team* (and then 
bogusly apply team rules to Debian at large).


> It would be appreciated if you worked within the team, so the packages 
> can benefit from the same infrastructure, rather than going off in a 
> different direction and stepping on existing work.

It would be appreciated if you did not accuse me of uncoordinated work 
when you really mean joining-the-team-and-coordinating-within-that-team 
which is a different matter.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1010471: [Pkg-javascript-devel] Bug#1010471: eslint: please move Recommends to Depends

[Jérémy Lal]

Le lun. 2 mai 2022 à 11:54, Jonas Smedegaard  a écrit :

> Quoting Jérémy Lal (2022-05-02 11:45:36)
> > I stand by saying as it is, putting those packages:
> > node-chalk
> > node-strip-ansi
> > node-text-table
> > in Recommends just breaks the default functionality of eslint.
>
> Ignoring recommends breaks systems.
>

eslint is a build-dependency of enigmail (nothing odd about that).
When sbuild builds a package, it doesn't install recommended packages of
build-dependencies ?

Bug#1010474: DCMTK 3.6.7

[Mathieu Malaterre]

Source: dcmtk
Version: 3.6.6-5

DCMTK 3.6.7 has been released, would be super nice to have in Debian archive.

Thanks !

Bug#1010471: [Pkg-javascript-devel] Bug#1010471: eslint: please move Recommends to Depends

[Jonas Smedegaard]

Quoting Jérémy Lal (2022-05-02 11:45:36)
> I stand by saying as it is, putting those packages:
> node-chalk
> node-strip-ansi
> node-text-table
> in Recommends just breaks the default functionality of eslint.

Ignoring recommends breaks systems.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1010471: [Pkg-javascript-devel] Bug#1010471: eslint: please move Recommends to Depends

[Jérémy Lal]

Le lun. 2 mai 2022 à 11:24, Jonas Smedegaard  a écrit :

> tags -1 wontfix
>
> Quoting Jérémy Lal (2022-05-02 09:50:54)
> > I was trying to fix "enigmail" FTBFS, and discovered that it was
> > simply missing all the packages that "eslint" recommends.
> >
> > enigmail
> > Build-Depends:
> >  eslint ,
> >  node-chalk ,
> >  node-strip-ansi ,
> >  node-text-table 
> >
> > Those three packages are not explicitely called by enigmail's eslintrc
> > config: they should just be in eslint Depends, because they are
> > required to make eslint work.
>
> Those are not _always_ needed for eslint, only _often_ which is the
> exact purpose of "Recommends.


It also breaks separation of concerns and will lead to an unmaintainable
mess,
if applied globally.

Please include those recommended packages as build-dependencies, or
> patch/override configuration to not use them: They are related to how
> eslint outputs information, and since ideally packaging should be
> verbose/terse depending on build flags you would want to manage such
> configuration anyway.


> I commonly add something like this near the top of the rules file:
>
> ESLINT = NO_COLOR=1 eslint
> JEST = jest --color=false
> MOCHA = NO_COLOR=1 mocha --no-timeout --no-color
> # normalize output with TAP where possible unless terse requested
> ifeq (,$(filter terse,$(DEB_BUILD_OPTIONS)))
> ESLINT += --format tap
> MOCHA += --reporter tap
> else
> ESLINT += --format unix
> MOCHA += --reporter dot
> endif
>
>
> ...and then call $(ESLINT)/$(JEST)/$(MOCHA) in target rules.
>

Right, though implementing "terse" is another matter.

Instead of making other packages know about eslint internals,
wouldn't it be simpler to make eslint default to a reporter that "just
works" ?

Currently enigmail just naively calls "eslint --quiet", and its .eslintrc
are innocent,
they don't select a particular output.

I stand by saying as it is, putting those packages:
node-chalk
node-strip-ansi
node-text-table
in Recommends just breaks the default functionality of eslint.

Jérémy

Bug#1010471: [Pkg-javascript-devel] Bug#1010471: eslint: please move Recommends to Depends

[Jonas Smedegaard]

tags -1 wontfix

Quoting Jérémy Lal (2022-05-02 09:50:54)
> I was trying to fix "enigmail" FTBFS, and discovered that it was 
> simply missing all the packages that "eslint" recommends.
> 
> enigmail
> Build-Depends:
>  eslint ,
>  node-chalk ,
>  node-strip-ansi ,
>  node-text-table 
> 
> Those three packages are not explicitely called by enigmail's eslintrc 
> config: they should just be in eslint Depends, because they are 
> required to make eslint work.

Those are not _always_ needed for eslint, only _often_ which is the 
exact purpose of "Recommends.

Please include those recommended packages as build-dependencies, or 
patch/override configuration to not use them: They are related to how 
eslint outputs information, and since ideally packaging should be 
verbose/terse depending on build flags you would want to manage such 
configuration anyway.

I commonly add something like this near the top of the rules file:

ESLINT = NO_COLOR=1 eslint
JEST = jest --color=false
MOCHA = NO_COLOR=1 mocha --no-timeout --no-color
# normalize output with TAP where possible unless terse requested
ifeq (,$(filter terse,$(DEB_BUILD_OPTIONS)))
ESLINT += --format tap
MOCHA += --reporter tap
else
ESLINT += --format unix
MOCHA += --reporter dot
endif


...and then call $(ESLINT)/$(JEST)/$(MOCHA) in target rules.


Hope that helps,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1010473: RFP: lexconvert -- convert phoneme codes and lexicon formats for English speech synths

[Jakub Wilk]

Package: wnpp
Severity: wishlist

* Package name: lexconvert
  Version : 0.34
  Upstream Author : Silas S. Brown 
* URL : https://github.com/ssb22/lexconvert
* License : Apache-2.0
  Programming Lang: Python
  Description : convert phoneme codes and lexicon formats for English 
speech synths

-- 
Jakub Wilk

Bug#1004244: [Pkg-javascript-devel] Bug#1004244: eslint: Please update at least to version ≥ 7

[Jonas Smedegaard]

Mainly waiting for eslint-plugin-jsdoc getting packaged for Debian.  See 
https://salsa.debian.org/js-team/eslint/-/blob/debian/latest/debian/TODO 
For more details.

Quoting Jérémy Lal (2022-05-02 10:06:06)
> - v8-compile-cache, one of the missing deps, is in NEW.

That sounds good, as it will provide a runtime speed boost, but it is 
already patched away (patch 2001 in current packaging) so not blocking 
upgrade to eslint v7.


> - @humanwhocodes/config-array should be bundled, it's barely useful 
>   outside eslint
> - @eslint/eslintrc should be bundled: "It is ESLint-specific and not 
>   intended for use in other programs."

I will consider embedding: Have updated debian/TODO.

> - node-cross-spawn is useless and can be patched away by nodejs spawn

Already patched away (patch 2005 in current packaging) so not blocking 
upgrade to eslint v7.


> - node-json-stable-stringify-without-jsonify can be patched to use 
>   node-json-stable-stringify, i guess

Already patched away (patch 2008 in current packaging) so not blocking 
upgrade to eslint v7.

Main blocker is none of those mentioned above, however, but packaging 
eslint-plugin-jsdoc that I consider too big for embedding and am 
(slowly) preparing an independent package of.  Added that detail also as 
initial paragraph of this post, for use as status message for the 
bugreport.

Thanks for your investigations,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1010256: Let go

[Geert Stappers]

Summary: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010256#41


On Sun, May 01, 2022 at 09:09:12PM -0400, James McCoy wrote:
> On Wed, Apr 27, 2022 at 04:07:43PM +0200, Jonas Smedegaard wrote:
> > 
> > Please in future consider filing ITPs to avoid such situations.
> 
> The Rust team files ITPs for binary crates, not the library crates, as
> the binary crates are generally more relevant to the broader Debian
> audience.
> 
> In terms of avoiding duplicate effort, the debcargo-conf repo _is_ that
> mechansim for the Rust team. You're choosing to ignore that and package
> things outside of the team's infrastructure.
> 
> The Rust team isn't unique in using a single repo for all their
> packages.
> 
> It would be appreciated if you worked within the team, so the packages
> can benefit from the same infrastructure, rather than going off in a
> different direction and stepping on existing work.


In addition to "my way is better, no my way is the better one"
here a link to a blog of Ian Jackson  https://diziet.dreamwidth.org/10559.html
That text, that I still don't completely comprehend, is saying
something like "the pieces do not fit".

Thing I'm trying to say:

   Let go, we known that the current tooling isn't perfect.


What I like to see is that several workflows are being explored.
And with the information it brings improve the comfort of the journey we
are making.
 

Groeten
Geert Stappers
DD


P.S.
Note to myself:  Consider there is no fight, so no need to stop a fight.
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#1010202: libmatio: FTBFS against hdf5 1.12.0 currently in experimental - 3 failed tests

[Gilles Filippini]

Hi,

Gilles Filippini a écrit le 29/04/2022 à 14:10 :

Hi Sébastien,

Sébastien Villemot a écrit le 29/04/2022 à 11:45 :

Hi Gilles,

Le mardi 26 avril 2022 à 10:38 +0200, Gilles Filippini a écrit :

Source: libmatio
Version: 1.5.23-1
Severity: important
Tags: ftbfs

While rebuilding libmatio 1.5.23 against hdf5 1.12.0, 3 testcases 
failed with:

[…]

I had an exchange with upstream, who says that libmatio 1.5.23 should
pass all tests against hdf5 1.12.2.

Is there any reason why you’re sticking to hdf5 1.12.0 instead of the
latest stable release 1.12.2?


No, no reason. I wanted to transition 1.12.0 before switching to 1.12.2, 
but the other way should be fine as well. I'll give it a try.


I've just tested a rebuild against HDF5 1.12.2, and the same 3 tests 
fail mosly the same way:


2272. mat73_compressed_read_le.at:475: testing Read directory ...
./mat73_compressed_read_le.at:478: cp $srcdir/results/dir_le.out expout
 $builddir/test_mat directory 
$srcdir/datasets/matio_test_cases_compressed_hdf_le.mat

--- /dev/null   2022-04-25 15:38:39.0 +
+++ /<>/test/testsuite.dir/at-groups/2272/stderr 
2022-05-02 08:55:13.515220334 +

@@ -0,0 +1,40 @@
+-E- test_mat: HDF5 error #000 in H5Fopen()
+  file : ../../../src/H5F.c:620
+  major: File accessibility
+  minor: Unable to open file
+-E- test_mat: HDF5 error #001 in H5VL_file_open()
+  file : ../../../src/H5VLcallback.c:3501
+  major: Virtual Object Layer
+  minor: Iteration failed
+-E- test_mat: HDF5 error #002 in H5PL__path_table_iterate()
+  file : ../../../src/H5PLpath.c:578
+  major: Plugin for dynamically loaded library
+  minor: Iteration failed
+-E- test_mat: HDF5 error #003 in H5PL__path_table_iterate_process_path()
+  file : ../../../src/H5PLpath.c:620
+  major: Plugin for dynamically loaded library
+  minor: Can't open directory or file
+-E- test_mat: HDF5 error #004 in H5VL__file_open()
+  file : ../../../src/H5VLcallback.c:3351
+  major: Virtual Object Layer
+  minor: Can't open object
+-E- test_mat: HDF5 error #005 in H5VL__native_file_open()
+  file : ../../../src/H5VLnative_file.c:97
+  major: File accessibility
+  minor: Unable to open file
+-E- test_mat: HDF5 error #006 in H5F_open()
+  file : ../../../src/H5Fint.c:1898
+  major: File accessibility
+  minor: Unable to lock file
+-E- test_mat: HDF5 error #007 in H5FD_lock()
+  file : ../../../src/H5FD.c:1625
+  major: Virtual File Layer
+  minor: Unable to lock file
+-E- test_mat: HDF5 error #008 in H5FD__sec2_lock()
+  file : ../../../src/H5FDsec2.c:1002
+  major: Virtual File Layer
+  minor: Unable to lock file
+-E- test_mat: HDF5 error #000 in H5Fclose()
+  file : ../../../src/H5F.c:707
+  major: Invalid arguments to routine
+  minor: Inappropriate type

Best,

_g.

Bug#1010472: blhc: false positive NONVERBOSE BUILD when using Meson

[duck]

Package: blhc
Version: 0.13-2


Quack,

When building dxvk I got this error:
NONVERBOSE BUILD: C++ linker for the build machine: c++ ld.bfd 2.38

You can find an example here:
  https://salsa.debian.org/aviau/dxvk/-/jobs/2726822

This is due to Meson's discovery:
C compiler for the host machine: x86_64-w64-mingw32-gcc (gcc 10.0.0 
"x86_64-w64-mingw32-gcc (GCC) 10-posix 20220324")

C linker for the host machine: x86_64-w64-mingw32-gcc ld.bfd 2.37
C++ compiler for the host machine: x86_64-w64-mingw32-g++ (gcc 10.0.0 
"x86_64-w64-mingw32-g++ (GCC) 10-posix 20220324")

C++ linker for the host machine: x86_64-w64-mingw32-g++ ld.bfd 2.37
C compiler for the build machine: ccache cc (gcc 11.3.0 "cc (Debian 
11.3.0-1) 11.3.0")

C linker for the build machine: cc ld.bfd 2.38
C++ compiler for the build machine: ccache c++ (gcc 11.3.0 "c++ (Debian 
11.3.0-1) 11.3.0")

C++ linker for the build machine: c++ ld.bfd 2.38

In case one don't use mingw-w64 then it might even match more lines.

Regards.
\_o<

--
Marc Dequènes

Bug#1010460: transition: libavif

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-libavif.html

On 2022-05-01 21:09:30, Boyuan Yang wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-CC: by...@debian.org
> Severity: normal
> 
> I plan to start another libavif transition as shown in the following
> transition tracker:
> 
> https://release.debian.org/transitions/html/auto-libavif.html
> 
> The new version of libavif library has bumped SONAME and needs a transition.
> Reverse dependencies include kimageformats and swayimg, and I have verified
> that the build would still pass with the new libavif currently in
> experimental.
> 
> Example Ben file (the one currently on auto-libavif page should be ok):
> 
> title = "libavif";
> is_affected = .depends ~ "libavif13" | .depends ~ "libavif14";
> is_good = .depends ~ "libavif14";
> is_bad = .depends ~ "libavif13";
> 
> This would be a really tiny transition, and I expect that we can finish it
> very quickly with binNMUs.

Please go ahead

Cheers

> 
> Thanks,
> Boyuan Yang



-- 
Sebastian Ramacher

Bug#1010438: transition: nodejs

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-nodejs.html

On 2022-05-01 17:17:13, Jérémy Lal wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> nodejs 16.14.2 is the current active version of nodejs:
> https://nodejs.org/en/about/releases/
> It also supports riscv64 architecture and has much better support of ppc64.
> 
> A rebuild of all (1600+) reverse-build-deps of libnode-dev/nodejs shows
> very few regressions, alerady being dealt with.

Since we need that to finish the icu transition, please go ahead.

Cheers

> 
> Ben file:
> 
> title = "nodejs";
> is_affected = .depends ~ "libnode83" | .depends ~ "libnode93";
> is_good = .depends ~ "libnode93";
> is_bad = .depends ~ "libnode83";
> 

-- 
Sebastian Ramacher

Bug#1010004: RFS: odr-dabmod/2.6.0-1 [ITP] -- DAB modulator compliant to ETSI EN 300 401

[Bastian Germann]

Am 02.05.22 um 08:27 schrieb Robin ALEXANDER:

Since the odr-dabmod package was not moved to the NEW queue yet, can I
just reload the package with the updated debian/rules file or do I also
need to modify file debian/changelog indicating the change on
debian/rules? In the latter case, do I need to change the package
version (ie. moving to 2.6.0-2 from 2.6.0-1)?


Reupload without changing the changelog.

Bug#1004244: eslint: Please update at least to version ≥ 7

[Jérémy Lal]

Source: eslint
Followup-For: Bug #1004244

About eslint 8 dependencies:
- v8-compile-cache, one of the missing deps, is in NEW.
- @humanwhocodes/config-array should be bundled, it's barely useful outside 
eslint
- @eslint/eslintrc should be bundled: "It is ESLint-specific and not intended 
for use in other programs."
- node-cross-spawn is useless and can be patched away by nodejs spawn
- node-json-stable-stringify-without-jsonify can be patched to use 
node-json-stable-stringify, i guess

So it looks good !

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

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

Bug#897025: ITP: node-v8-compile-cache -- Node.js module that enables the code cache to speed up instantiation time

[Jérémy Lal]

Package: wnpp
Followup-For: Bug #897025

Hi,

I reworked Paolo's initial packaging (to use dh-sequence-nodejs),
and uploaded node-v8-compile-cache.

This package is (the last missing) build-dep of eslint 8.

Bug#1010471: eslint: please move Recommends to Depends

[Jérémy Lal]

Source: eslint
Version: 6.4.0~dfsg+~6.1.9-5
Severity: normal

Hi,

I was trying to fix "enigmail" FTBFS, and discovered that it was
simply missing all the packages that "eslint" recommends.

enigmail
Build-Depends:
 eslint ,
 node-chalk ,
 node-strip-ansi ,
 node-text-table 

Those three packages are not explicitely called by enigmail's eslintrc config:
they should just be in eslint Depends, because they are required to make eslint 
work.

Jérémy

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

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

Bug#1009888: [Pkg-rust-maintainers] Bug#1009888: rust-h2, existing version is badly broken, new upstream needs new package

[Fabian Grünbichler]

On May 1, 2022 7:28 pm, Peter Michael Green wrote:
> 
> On 01/05/2022 14:00, Fabian Grünbichler wrote:
>> currently progress is blocked on
>> - itoa/serde_json transition (anybody working actively on that?)
> 
> I just uploaded the new itoa to experimental and took a quick look 
> through the reverse dependencies.
> 
> rust-cssparser - already broken and not in testing.
> rust-csv - built/tested fine after patching to use itoa 1, upstream also 
> has an unreleased change switching to itoa1 with no code changes.
> rust-http - fixed version in debcargo-conf (semver breaking, but all 
> rdeps are broken right now anyway)
> rust-hyper - already broken and not in testing.
> rust-num-format - already broken and not in testing.
> rust-serde-json - fixed version in debcargo-conf (not semver breaking)
> rust-serde-urlencoded - fixed upstream (semver breaking, but all rdeps 
> are broken right now anyway)
> rust-time - fixed upstream (not semver breaking)
> 
> I'm not seeing any reason not to go ahead with pushing this to unstable, 
> anyone have any comments before I go ahead?

LGTM - wasn't me who prepared those (itoa / serde_json) though ;) Carlos 
did, but they seem to not hang out on IRC atm.

Bug#1010470: ITP: node-undici -- HTTP/1.1 client written from scratch for Node.js

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: Jérémy Lal 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: node-undici
  Version : 5.0.0
  Upstream Author : Matteo Collina 
* URL : https://undici.nodejs.org
* License : Expat
  Programming Lang: JavaScript
  Description : HTTP/1.1 client written from scratch for Node.js

 This module provides the Node.js core HTTP client, using
 WebAssembly to achieve performance and pluggability.
 It brings features like:
 - redirect support
 - native mocking layer using MockAgent
 - Client, Pool, Agent are unified by a Dispatcher API
 .
 Node.js is an event-based server-side JavaScript engine.

This module is going to be a must-have for all HTTP clients that can
run on js+wasm platforms, so it is best packaged separately, as
intended by upstream Node.js.
It also features a parser generator, javascript producing C, and
the generated C compiled to WebAssembly.

Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment

[Julian Gilbey]

clone 1010437 -1
reassign -1 lxc 1:4.0.11-1
retitle -1 lxc: as root, lxc-start fails to start with cgroups/cgfsng error 
setting up limits for devices
retitle 1010437 autopkgtest-build-lxc: eatmydata gives lots of LD_PRELOAD 
warnings
thanks

I have now run the autopkgtest-build-lxc script "by hand" to see where
the issues are arising in the issue below, and I think there are two
separate things going on, hence splitting this bug report into two.
A few comments interspersed below.

On Sun, May 01, 2022 at 04:03:09PM +0100, Julian Gilbey wrote:
> Package: autopkgtest
> Version: 5.21
> Severity: normal
> 
> (I realise that posting this on debian-devel [1] was probably not the
> most appropriate place, as it's actually a bug report.)
> 
> I am not sure whether this is a bug in autopkgtest-build-lxc, a bug in
> lxc itself or a user error.  Please feel free to redirect as
> appropriate!
> 
> This is what I did:
> 
> Step 1: I installed the lxc and autopkgtest packages
> That went smoothly.  (lxc version 1:4.0.11-1, autopkgtest version
> 5.21; autopkgtest was already installed, and I installed lxc from 
> 
> Step 2: I ran the command "autopkgtest-build-lxc debian sid"
> as root.  I got various warning messages to begin with:
> 
> >
> lxc-create: autopkgtest-sid: storage/btrfs.c: btrfs_create: 938 Inappropriate 
> ioctl for device - Failed to create btrfs subvolume 
> "/var/lib/lxc/autopkgtest-sid/rootfs"
> lxc-create: autopkgtest-sid: storage/zfs.c: zfs_create: 735 Failed to create 
> zfs dataset "zfs:lxc/autopkgtest-sid": lxc-create: autopkgtest-sid: utils.c: 
> run_command_internal: 1588
> lxc-create: autopkgtest-sid: storage/lvm.c: do_lvm_create: 165 Failed to 
> create logical volume "autopkgtest-sid":   Volume group "lxc" not found
>   Cannot process volume group lxc
> lxc-create: autopkgtest-sid: storage/lvm.c: lvm_create: 623 Error creating 
> new logical volume "lvm:/dev/lxc/autopkgtest-sid" of size "1073741824 bytes"
> <
> 
> after which things ran smoothly for a bit:
> 
> >
> debootstrap is /usr/sbin/debootstrap
> Checking cache download in /var/cache/lxc/debian/rootfs-sid-amd64 ... 
> Downloading debian minimal ...
> I: Target architecture can be executed
> I: Retrieving InRelease 
> [... downloading and installing base system ...]
> I: Base system installed successfully.
> Download complete.
> <
> 
> but then there were lots of warning messages about libeatmydata.so
> interspersed with information messages; I assume that these are mostly
> harmless:
> 
> >
> Copying rootfs to /var/lib/lxc/autopkgtest-sid/rootfs...ERROR: ld.so: object 
> 'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared 
> object file): ignored.
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> Generating locales (this might take a while)...
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
>   en_GB.UTF-8ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be 
> preloaded (cannot open shared object file): ignored.
> [... lots more similar warnings and messages ...]
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> <

This looks to be similar to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963508 so I wonder
whether the apparmor settings for lxc mean that LD_PRELOAD cannot be
used with lxc, and LD_PRELOAD is needed by eatmydata.  This is a minor
issue with autopkgtest-build-lxc; maybe it should just not try using
eatmydata, or maybe there is some way to change the lxc apparmor
settings (if indeed that is the thing preventing the use of
LD_PRELOAD) to allow eatmydata?  I don't know anything about apparmor,
so I am just speculating here.


> But then I received several fatal error messages:
> 
> >
> lxc-start: autopkgtest-sid: lxccontainer.c: wait_on_daemonized_start: 867 
> Received container state "ABORTING" instead of "RUNNING"
> lxc-start: autopkgtest-sid: tools/lxc_start.c: main: 306 The container failed 
> to start
> lxc-start: autopkgtest-sid: tools/lxc_start.c: main: 309 To get more details, 
> run the container in foreground mode
> lxc-start: autopkgtest-sid: tools/lxc_start.c: main: 311 Additional 
> information can be obtained by setting the --logfile and --logpriority options
> <
> 
> Since autopkgtest-build-lxc doesn't allow a --logfile option, I
> attempted to start the container manually, using the command
>   lxc-start -n autopkgtest-sid --logfile /tmp/lxc.log --logpriority INFO
> and got the following warnings and errors in the log file (I've
> excluded the INFO entries):
> 
> >
> lxc-start autopkgtest-sid 20220501145802.680 NOTICE   conf - 
> conf.c:lxc_setup:4450 - The container "autopkgtest-sid" is set up
> lxc-start autopkgtest-sid 20220501145802.681 WARN cgfsng - 
> cgroups/cgfsng.c:get_hierarchy:142 - There is no 

Bug#1010128: Duplicates

[Stephan Verbücheln]

Duplicates:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010283
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010240

Regards

Bug#1006530: mariadb-10.6: FTBFS on x32: undefined reference to misc functions and files (regression from MariaDB 10.5)

[Laurent Bigonville]

On Tue, 15 Mar 2022 15:22:15 +1100 Daniel Black  wrote:
> The error is earlier in the logs:
>
> -- Looking for sched_getcpu - found
> -- Could NOT find PMEM (missing: PMEM_LIBRARIES PMEM_INCLUDE_DIR)
> CMake Error at storage/innobase/CMakeLists.txt:345 (MESSAGE):
> WITH_PMEM=ON cannot be satisfied
>
> When the configure stage fails, the builds outputs the
> CMakeOutput/Error logs to complement this error earlier in the logs.
> In this case its not useful but other times it is.
>
> so the architecture test in debian/rules isn't right as it adds 
WITH_PMEM=ON.

>

WITH_PMEM=ON doesn't seem explicitly added to the options on x32, so I'm 
wondering if WITH_PMEM=OFF shouldn't be added explicitly on 
architectures where libpmem is not available/supported

Bug#1010422: transition: r-api-bioc-3.15

[Nilesh Patra]

On 2 May 2022 11:54:34 am IST, Andreas Tille  wrote:
>Am Mon, May 02, 2022 at 09:39:25AM +0530 schrieb Nilesh Patra:
>> On Sun, 1 May 2022 11:42:07 +0200 =?UTF-8?B?RHlsYW4gQcOvc3Np?= 
>>  wrote:
>> > Hi,
>> > Bioconductor 3.15 has been released [1].
>> 
>> Please hold this off until r-base migrates (which should be soon)
>
>As far as I can see the testing migration is blocked by
>
>Isn't this the just discussed Graphics API issue?

There were many more of 'em blocking the transition. I cleaned that up 
yesterday and reduced it to the one remaining.

>I guess your recent upload of 0.1.2.1-3 is supposed to fix this and
>is intended to enable the migration, right?
>

Yes, let's wait until r-base migrates, I guess it'd take a day or two maybe.
Anyway we need to wait for bioc transition until we get a thumbs up from 
release team.

Migrating the graphics packages are also a mess now due to no-binNMUs. Need to 
propagate hacks to get these in testing. All of it could have been avoided if 
it was properly coordinated, but anyway.

>[1] 
>https://ci.debian.net/data/autopkgtest/testing/arm64/r/r-cran-thematic/21293099/log.gz
>

--
Best,
Nilesh

Bug#1010004: RFS: odr-dabmod/2.6.0-1 [ITP] -- DAB modulator compliant to ETSI EN 300 401

[Robin ALEXANDER]

Hi Bastian,

I just realized that I need to make a slight change to file
debian/rules by calling dh_auto_configure with an additional argument
in order to avoid compiling odr-dabmod with the option "-march=native".

Since the odr-dabmod package was not moved to the NEW queue yet, can I
just reload the package with the updated debian/rules file or do I also
need to modify file debian/changelog indicating the change on
debian/rules? In the latter case, do I need to change the package
version (ie. moving to 2.6.0-2 from 2.6.0-1)?

Have a nice week.

-- 
Robin 

Le vendredi 29 avril 2022 à 11:14 +0200, Bastian Germann a écrit :
> Am 29.04.22 um 11:07 schrieb Robin ALEXANDER:
> > As I wrote to you, I:
> >    1. Uploaded on Wednesday (April 27) the corrected versions of
> > odr-
> > dabmux (https://mentors.debian.net/package/odr-dabmux/) and odr-
> > dabmod
> > (https://mentors.debian.net/package/odr-dabmod/)
> > 
> >    2. Removed the moreinfo tag on odr-dabmux
> > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009867) and
> > odr-
> > dabmod (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010004)
> > 
> > Assuming I did everything correctly, is there anything else I must
> > do
> > to have these 2 packages pushed to the NEW queue (like what was
> > done
> > with odr-padenc)? Or is it the sponsor/you who pushes the packages
> > to
> > the NEW queue by closing the above 2 bugs (1009867 and  1010004) ?
> 
> You just have to wait until someone will review the packages.
> My comments were just to help getting the packages to a state where a
> DD would have a look at it.


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

Bug#1010422: transition: r-api-bioc-3.15

[Andreas Tille]

Am Mon, May 02, 2022 at 09:39:25AM +0530 schrieb Nilesh Patra:
> On Sun, 1 May 2022 11:42:07 +0200 =?UTF-8?B?RHlsYW4gQcOvc3Np?= 
>  wrote:
> > Hi,
> > Bioconductor 3.15 has been released [1].
> 
> Please hold this off until r-base migrates (which should be soon)

As far as I can see the testing migration is blocked by

  ∙ autopkgtest for r-cran-thematic/0.1.2.1-2: amd64: Pass, arm64: Regression ♻ 
(reference ♻), armhf: Pass, i386: Pass, ppc64el: Pass, s390x: Pass

where the autopkgtest log[1] says:

...
══ Failed tests 
── Error (test-base.R:9:3): base baselines ─
Error in `svglite_(filename, bg, width, height, pointsize, standalone, 
always_valid)`: Graphics API version mismatch
Backtrace:
▆
 1. └─thematic:::expect_doppelganger(...) at test-base.R:9:2
 2.   └─vdiffr::expect_doppelganger(name, p, ...) at 
tests/testthat/helper-vdiffr.R:12:2
 3. └─vdiffr writer(fig, testcase, title)
 4.   └─vdiffr:::svglite(file)
 5. └─vdiffr:::svglite_(...)
── Error (test-ggplot.R:31:3): ggplot baselines 
Error in `svglite_(filename, bg, width, height, pointsize, standalone, 
always_valid)`: Graphics API version mismatch
Backtrace:
▆
 1. └─thematic:::expect_doppelganger(...) at test-ggplot.R:31:2
 2.   └─vdiffr::expect_doppelganger(name, p, ...) at 
tests/testthat/helper-vdiffr.R:12:2
 3. └─vdiffr writer(fig, testcase, title)
 4.   └─vdiffr:::svglite(file)
 5. └─vdiffr:::svglite_(...)
── Error (test-ggplot.R:149:3): Scale defaults can be overridden ───
Error in `svglite_(filename, bg, width, height, pointsize, standalone, 
always_valid)`: Graphics API version mismatch
...

Isn't this the just discussed Graphics API issue?

I guess your recent upload of 0.1.2.1-3 is supposed to fix this and
is intended to enable the migration, right?

Kind regards

  Andreas.


[1] 
https://ci.debian.net/data/autopkgtest/testing/arm64/r/r-cran-thematic/21293099/log.gz

-- 
http://fam-tille.de

Bug#1010468: transition: gnat-11

[Nicolas Boulenguez]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello.

The gcc-V source package builds the Ada compiler (gnat-V) and
companion library (libgnat-V).
The default Ada compiler is selected by the gnat package.
In unstable and testing, gnat Depends: gnat-10.
In experimental, gnat Depends: gnat-11.

Ada libraries have specific requirements.
* They must Build-Depend: gnat-V (in addition to gnat).
* Each -dev package name carries a version, similar to the shared
  object version for lib packages.  Most changes in the source require
  a renaming of the -dev package, and a source upload of all reverse
  dependencies.
  In order to reduce the number of such transitions, many unrelated
  changes, like new upstream releases, are introduced with a libgnat
  transition and tested in experimental.
* Each -dev package depends on both gnat and gnat-V.

GCC builds no libgnat-V-dev package. The sources for the Ada standard
library are distributed with the compiler in the gnat-V package.  So
it is convenient to track the transition with the libgnat-V package
instead (even when the ABI is unchanged).

Ben file:

title = "gnat-11";
is_affected = .depends ~ "libgnat-8" | .depends ~ "libgnat-9" | .depends ~ 
"libgnat-10" | .depends ~ "libgnat-11";
is_good = .depends ~ "libgnat-11";
is_bad = .depends ~ "libgnat-8" | .depends ~ "libgnat-9" | .depends ~ 
"libgnat-10";

During last transition, Sebastian Ramacher has requested that the -dev
packages replace
  Depends: gnat, gnat-V
with
  Depends: gnat (>= V), gnat (<< V+1)
in order to help the migration from unstable to testing.
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975589#24)
Only a few key packages have been updated and tested in experimental,
but it seems safe to update the remaining packages during the reupload
to unstable.

dh-ada-library libxmlada gprbuild
  are ready in experimental (including a correct gnat dependency)

gprconfig-kb
  is tightly connected with gprbuild and must migrate with the other
  packages despite not depending on libgnat.
  It is ready in experimental too.

adasockets plplot
  are almost ready in experimental,
  but must manually change the -dev dependency when reuploaded to unstable
gnat, gnat-V  ->  gnat (>= V), gnat (<< V+1)

adacgi ahven anet dbusada gprbuild libalog libaunit libflorist
libgmpada libgnatcoll libgnatcoll-bindings libgnatcoll-db libgtkada
liblog4ada libncursesada libtemplates-parser libtexttools libxmlada
libxmlezout pcscada
  are almost ready in experimental, but must
  Build-Depend: dh-ada-library (>= 7.5)
  when reuploaded to unstable so that the gnat dependency is correctly
  generated during the rebuild.

These source packages produce no library and should only need a
bin-NMU in due time:
nmumusic123_16.6-2   . ANY . -m 'Rebuild with gnat-11'
nmu   topal_81-1 . ANY . -m 'Rebuild with gnat-11 for 
unstable'
nmu whitakers-words_0.2020.10.27-1.1 . ANY . -m 'Rebuild with gnat-11'

adabrowse adacontrol asis gnat-gps libaws
  are RC-buggy and have been removed from testing.
  They should not prevent the transition.
  Once the dust has settled, we will see if and when they can be
  reintroduced into Debian.

libgnatcoll-python
  was a temporary package only intended for python2 support in the
  unstable distribution.
  It should be removed after this transition.

ghdl
  should not be affected.
  It requires an explicit gnat-V, independently of the default gnat.

ada-reference-manual
  should not be affected.
  It needs gnat at build time only.

Bug#1010269: crashes immediately at start

[duck]

Control: severity -1 grave
Control: affects -1 src:dxvk


Quack,

Not sure why the severity was not raised but as it is this package is 
unusable.

It also breaks dxvk's autopkgtest which I needed before releasing fixes.

There were changes in the nls files packaging in 6.9~repack-1 but no 
problem was spotted at the time so I guess new files might be needed and 
not included but I did not have time to check this supposition.


Regards.
\_o<

--
Marc Dequènes

Bug#1009191: cctbx: please re-enable building on riscv64

[Andrius Merkys]

Hi,

On 2022-04-30 13:29, Neil Williams wrote:
>> Neil, is there a particular reason riscv64 support was disabled in
>> 2021.12+ds1-3? 
> I didn't see it as particularly likely that any real-world usage of
> cctbx was manageable on any current RISCV64 hardware. 

Thanks for explanation. I usually disable only the explicitly
unsupported architectures, or the ones that fail and would otherwise
block migration.

>> cctbx seems to build fine on riscv64 now. Can it be
>> re-enabled?
> Probably, yes. I won't have time to do an upload soon though. 
> 
> If someone else has time to do it as a team upload, go ahead. 

I will enable riscv64 and team upload.

Best,
Andrius