Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"

[Vasudev Kamath]

Aurelien Jarno  writes:

> Hi,
>
> On 2022-09-26 09:45, Vasudev Kamath wrote:
>> And post removing /usr/lib version of libc it seems to work fine and no
>> crash is happening.
>> 
>> └─(09:44:30 on master)──> expr   
>>  
>>   1 ↵ ──(Mon,Sep26)─┘
>> expr: missing operand
>> Try 'expr --help' for more information.
>> ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
>> └─(09:44:39 on master)──>
>
> Thanks for all the details. It's great that your system is now fixed. Do
> you have an idea why libc6 2.34 ended up in /usr/lib/x86_64-linux-gnu?
> I do not see any explanation from the glibc side. Did you attempt a
> usrmerge migration that failed after moving some files, or do you think
> it's unrelated? 
>

I seriously did not have a clue why system was in this state. I had
installed system back in 2019 and just keep updating. Also it was not
just glibc, a whole bunch of packages were in this state and it took me a
while to fix the entire system. (Had to write script to automate entire
process).

I don't remember me attempting to install usrmerge but not sure if it
came via some dependency and failed to install. Feels weird why system
was in such a state.

Cheers,
Vasudev

Bug#1019694: pikepdf: FTBFS with qpdf 11.0.0

[James Barlow]

Upgrading to pikepdf 6.0.2 will resolve this issue. pikepdf 5 is not 
compatible with qpdf 11.

-James

On Tue, 13 Sep 2022 15:58:00 +0200 Sebastian Ramacher 
 wrote:

> Source: pikepdf
> Version: 5.1.1+dfsg-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in 
the past)

>
> 


>
> In file included from src/qpdf/object_convert.cpp:22:
> /usr/include/qpdf/PointerHolder.hh:31:3: warning: #warning 
"POINTERHOLDER_TRANSITION is not defined -- see qpdf/PointerHolder.hh" 
[-Wcpp]
>31 | # warning "POINTERHOLDER_TRANSITION is not defined -- see 
qpdf/PointerHolder.hh"

>   |   ^~~
> In file included from src/qpdf/object_convert.cpp:31:
> src/qpdf/pikepdf.h: In static member function ‘static 
pybind11::handle 
pybind11::detail::type_caster::cast(const 
QPDFObjectHandle*, pybind11::return_value_policy, pybind11::handle)’:
> src/qpdf/pikepdf.h:96:26: error: ‘QPDFObject::object_type_e’ has 
not been declared

>96 | case QPDFObject::object_type_e::ot_null:
>   |  ^
> src/qpdf/pikepdf.h:99:26: error: ‘QPDFObject::object_type_e’ has 
not been declared

>99 | case QPDFObject::object_type_e::ot_integer:
>   |  ^
> src/qpdf/pikepdf.h:102:26: error: ‘QPDFObject::object_type_e’ 
has not been declared

>   102 | case QPDFObject::object_type_e::ot_boolean:
>   |  ^
> src/qpdf/pikepdf.h:105:26: error: ‘QPDFObject::object_type_e’ 
has not been declared

>   105 | case QPDFObject::object_type_e::ot_real:
>   |  ^
> src/qpdf/object_convert.cpp: In function ‘pybind11::object 
decimal_from_pdfobject(QPDFObjectHandle)’:
> src/qpdf/object_convert.cpp:159:40: error: 
‘QPDFObject::object_type_e’ has not been declared
>   159 | if (h.getTypeCode() == 
QPDFObject::object_type_e::ot_integer) {

>   |^
> src/qpdf/object_convert.cpp:162:47: error: 
‘QPDFObject::object_type_e’ has not been declared
>   162 | } else if (h.getTypeCode() == 
QPDFObject::object_type_e::ot_real) {

>   |   ^
> src/qpdf/object_convert.cpp:165:47: error: 
‘QPDFObject::object_type_e’ has not been declared
>   165 | } else if (h.getTypeCode() == 
QPDFObject::object_type_e::ot_boolean) {

>   |   ^
> 


> Build finished at 2022-09-13T09:19:36Z
>
>
> Cheers
> --
> Sebastian Ramacher
>
>

Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"

[Aurelien Jarno]

Hi,

On 2022-09-26 09:45, Vasudev Kamath wrote:
> And post removing /usr/lib version of libc it seems to work fine and no
> crash is happening.
> 
> └─(09:44:30 on master)──> expr
>   
> 1 ↵ ──(Mon,Sep26)─┘
> expr: missing operand
> Try 'expr --help' for more information.
> ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
> └─(09:44:39 on master)──>

Thanks for all the details. It's great that your system is now fixed. Do
you have an idea why libc6 2.34 ended up in /usr/lib/x86_64-linux-gnu?
I do not see any explanation from the glibc side. Did you attempt a
usrmerge migration that failed after moving some files, or do you think
it's unrelated? 

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1020572: lintian-brush shouldn't add a build dependency to pkg-js-tools

[Yadd]

On 26/09/2022 06:41, Jelmer Vernooij wrote:

On Fri, Sep 23, 2022 at 03:48:42PM +0200, Yadd wrote:

now lintian-brush replaces build dependency to dh-sequence-nodejs by
"pkg-js-tools | dh-sequence-nodejs". This change is wrong:
dh-sequence-nodejs is provided by dh-nodejs, not pkg-js-tools (which has
a lot of dependencies and depends on dh-nodejs).

Question, why this change, is dh-sequence-nodejs not enough ?


Do you have an example where it did this? It shouldn't normally do
this, so perhaps it's hitting some sort of corner case.

Jelmer


Hi,

an example here: 
https://salsa.debian.org/js-team/node-i18next/-/commit/da05bcd0


lintian-brush added a dependency to "pkg-js-tools | dh-sequence-nodejs" 
while there were already a dependency to dh-sequence-nodejs


Cheers,
Yadd

Bug#1020726: rust-log: please provide feature kv_unstable_serde

[Jonas Smedegaard]

Quoting Peter Green (2022-09-25 23:41:52)
> > Please provide feature kv_unstable_serde, needed for packages I am
> > preparing for Debian.
> 
> This requires the serde feature in value-bag to be enabled, which
> in turn requires sval and serde_fmt
> 
> sval is currently in NEw 
> https://ftp-master.debian.org/new/rust-sval_1.0.0~alpha.5-1.html
> 
> I don't see any evidence that anyone is currently working on serde_fmt

Too bad.  it then takes longer to get rust-async-std into Debian :-(


 - 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#1020572: lintian-brush shouldn't add a build dependency to pkg-js-tools

[Jelmer Vernooij]

On Fri, Sep 23, 2022 at 03:48:42PM +0200, Yadd wrote:
> now lintian-brush replaces build dependency to dh-sequence-nodejs by
> "pkg-js-tools | dh-sequence-nodejs". This change is wrong:
> dh-sequence-nodejs is provided by dh-nodejs, not pkg-js-tools (which has
> a lot of dependencies and depends on dh-nodejs).
> 
> Question, why this change, is dh-sequence-nodejs not enough ?

Do you have an example where it did this? It shouldn't normally do
this, so perhaps it's hitting some sort of corner case.

Jelmer


signature.asc
Description: PGP signature

Bug#1020760: Acknowledgement (apt-file: not clear how to do EOL matching)

[Curt Sampson]

Oh, it occurs to me that perhaps the "patterns" described in the
manpage are not patterns (like regex or shell glob patterns) at all,
but just plain substrings. If that's the case, the documentation
should be changed to make this clear.

On Mon, Sep 26, 2022 at 12:03 PM Debian Bug Tracking System
 wrote:
>
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1020760: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020760.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  APT Development Team 
>
> If you wish to submit further information on this problem, please
> send it to 1020...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 1020760: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020760
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems



-- 
Curt Sampson  +81 90 7737 2974

To iterate is human, to recurse divine.
- L Peter Deutsch

Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"

[Vasudev Kamath]

Vasudev Kamath  writes:

> Post installation of usrmerge this output is changed
>
> └─(09:37:07 on master)──> ls -ld /lib/x86_64-linux-gnu/libc.so.6  
>   
> 1 ↵ ──(Mon,Sep26)─┘
> -rwxr-xr-x 1 root root 2061320 Sep 23 01:32 /lib/x86_64-linux-gnu/libc.so.6
> ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
> └─(09:37:20 on master)──> ls -ld /usr/lib/x86_64-linux-gnu/libc.so.6  
>   
> ──(Mon,Sep26)─┘
> -rwxr-xr-x 1 root root 2049032 Sep 11 03:35 
> /usr/lib/x86_64-linux-gnu/libc.so.6
> ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
> └─(09:37:25 on master)──> ls -ld /lib 
>   
> ──(Mon,Sep26)─┘
> drwxr-xr-x 9 root root 4096 Sep 26 09:32 /lib
> ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
> └─(09:38:14 on master)──>
>
> So looks like my system is not in sane state. Do I need to just delete
> /usr/lib/ libc and try this?.

From objdump -p output it looks like /lib version is the 2.35

3 0x00 0x069691b2 GLIBC_2.32
GLIBC_2.31
34 0x00 0x069691b3 GLIBC_2.33
GLIBC_2.32
35 0x00 0x069691b4 GLIBC_2.34
GLIBC_2.33
36 0x00 0x069691b5 GLIBC_2.35
GLIBC_2.34
37 0x00 0x0963cf85 GLIBC_PRIVATE
GLIBC_2.35

and /usr/lib version is 2.34

GLIBC_2.30
33 0x00 0x069691b2 GLIBC_2.32
GLIBC_2.31
34 0x00 0x069691b3 GLIBC_2.33
GLIBC_2.32
35 0x00 0x069691b4 GLIBC_2.34
GLIBC_2.33
36 0x00 0x0963cf85 GLIBC_PRIVATE
GLIBC_2.34

And post removing /usr/lib version of libc it seems to work fine and no
crash is happening.

└─(09:44:30 on master)──> expr  

1 ↵ ──(Mon,Sep26)─┘
expr: missing operand
Try 'expr --help' for more information.
┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
└─(09:44:39 on master)──>

Cheers,
Vasudev

Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"

[Vasudev Kamath]

Vasudev Kamath  writes:
>
> └─(09:09:40 on master)──> ls -ld /lib 
>   
> ──(Mon,Sep26)─┘
> drwxr-xr-x 9 root root 4096 Sep 23 14:37 /lib
> ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
> └─(09:12:50 on master)──> ls -l /lib/x86_64-linux-gnu/libc.so.6   
>   
> ──(Mon,Sep26)─┘
> -rwxr-xr-x 1 root root 2049032 Sep 11 03:35 /lib/x86_64-linux-gnu/libc.so.6
> ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
> └─(09:13:06 on master)──> ls -l /usr/lib/x86_64-linux-gnu/libc.so.6   
>   
> ──(Mon,Sep26)─┘
> -rwxr-xr-x 1 root root 2049032 Sep 11 03:35 
> /usr/lib/x86_64-linux-gnu/libc.so.6
> ┌─(~/.emacs.d)─
>
> Is it that if I install usrmerge and then upgrade libc it should work?

Post installation of usrmerge this output is changed

└─(09:37:07 on master)──> ls -ld /lib/x86_64-linux-gnu/libc.so.6

1 ↵ ──(Mon,Sep26)─┘
-rwxr-xr-x 1 root root 2061320 Sep 23 01:32 /lib/x86_64-linux-gnu/libc.so.6
┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
└─(09:37:20 on master)──> ls -ld /usr/lib/x86_64-linux-gnu/libc.so.6

──(Mon,Sep26)─┘
-rwxr-xr-x 1 root root 2049032 Sep 11 03:35 /usr/lib/x86_64-linux-gnu/libc.so.6
┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
└─(09:37:25 on master)──> ls -ld /lib   

──(Mon,Sep26)─┘
drwxr-xr-x 9 root root 4096 Sep 26 09:32 /lib
┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
└─(09:38:14 on master)──>

So looks like my system is not in sane state. Do I need to just delete
/usr/lib/ libc and try this?.

Cheers,
Vasudev

Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"

[Vasudev Kamath]

>
> I have looked at the coredump you sent me:
>
> $ eu-unstrip -n --core 
> core.expr.1000.d5ff83e0fd69439497afd17511de3417.85280.166392358300
> 0x5604c0781000+0x1e000 
> b919757cbc30fbb64b14498222499d972fd80acd@0x5604c0781368 . - /usr/bin/expr
> 0x7fbfabc0+0x201000 
> ef3afb43092687d7fcc8167fabdee73f4a3287f1@0x7fbfabc00380 - - 
> /usr/lib/x86_64-linux-gnu/libc.so.6
> 0x7ffdc5bde000+0x1000 c35c947b072ff69b395cd326b83b24630f2c5065@0x7ffdc5bde54c 
> . - linux-vdso.so.1
> 0x7fbfac04c000+0x362b8 
> a03c3b14d371da908a3f22007b3f0c73d1f9f634@0x7fbfac04c248 
> /lib64/ld-linux-x86-64.so.2 - ld-linux-x86-64.so.2
> 0x7fbfabfc9000+0x80bc8 
> 25c73b398493c695a013a6d9d493a8316aac0fa0@0x7fbfabfc9248 
> /usr/lib/x86_64-linux-gnu/libgmp.so.10 - libgmp.so.10
>
> ef3afb43092687d7fcc8167fabdee73f4a3287f1 
>   => comes from libc6 version 2.34-8
> a03c3b14d371da908a3f22007b3f0c73d1f9f634
>   => comes from libc6 version 2.35-1
>
> So the crash is likely due to a mismatch between glibc. I believe this
> is due to an issue with usrmerge as the paths reported by your core file
> seems to show that your system is merged, while reportbug says
> "merged-usr: no".
>
> By using a non usrmerged system, with libc6 2.34-8 duplicated in both
> /lib/x86_64-linux-gnu/ and /usr/lib/x86_64-linux-gnu, and upgrading it
> to libc6 2.35-1, I am able to reproduce your issue with expr:
>
> $ expr
> *** stack smashing detected ***: terminated
> Aborted

Interesting. I had put init-system-helpers on hold because it was
reported with some issue and I see usrmerge package is not installed on
my system.

usrmerge:
  Installed: (none)
  Candidate: 31
  Version table:
 31 500
500 http://deb.debian.org/debian sid/main amd64 Packages
500 http://deb.debian.org/debian sid/main i386 Packages
 30+nmu1 -1
100 /var/lib/dpkg/status

>> > And if I understand you right the stack smashing
>> > is from "autoreconf --version".
>> > But I could not find it executing any "expr" processes in my test VM.
>> 
>> Actually just invoking autoconf was crashing and just executing expr itself 
>> was also crashing. If needed I can install latest libc and provide any 
>> required information. Do let me know
>
> Before trying to upgrade again, we should ensure your system is in a
> sane state. Could you please send us the output of:
>
> ls -ld /lib
> ls -l /lib/x86_64-linux-gnu/libc.so.6
> ls -l /usr/lib/x86_64-linux-gnu/libc.so.6

└─(09:09:40 on master)──> ls -ld /lib   

──(Mon,Sep26)─┘
drwxr-xr-x 9 root root 4096 Sep 23 14:37 /lib
┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
└─(09:12:50 on master)──> ls -l /lib/x86_64-linux-gnu/libc.so.6 

──(Mon,Sep26)─┘
-rwxr-xr-x 1 root root 2049032 Sep 11 03:35 /lib/x86_64-linux-gnu/libc.so.6
┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
└─(09:13:06 on master)──> ls -l /usr/lib/x86_64-linux-gnu/libc.so.6 

──(Mon,Sep26)─┘
-rwxr-xr-x 1 root root 2049032 Sep 11 03:35 /usr/lib/x86_64-linux-gnu/libc.so.6
┌─(~/.emacs.d)─

Is it that if I install usrmerge and then upgrade libc it should work?

Thanks and Regards,
Vasudev

Bug#1018105: gimp: crashes when adding text to image

[guy]

Package: gimp
Version: 2.99.10-1
Followup-For: Bug #1018105
X-Debbugs-Cc: otsd...@proton.me

Dear Maintainer,
Same bug. Seg crash when trying to add text or manipulate text layer. 100%
failure on any attempt. Started on previous 2.10.32-1. No problem with previous
versions.


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

Kernel: Linux 6.0.0-rc6-siduction-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 gimp depends on:
ii  gimp-data2.99.10-1
ii  graphviz 2.42.2-7
ii  libaa1   1.4p5-50
ii  libappstream-glib8   0.8.1-1
ii  libarchive13 3.6.0-1
ii  libasound2   1.2.7.2-1
ii  libbabl-0.1-01:0.1.96-1
ii  libbz2-1.0   1.0.8-5+b1
ii  libc62.35-1
ii  libcairo21.16.0-6
ii  libfontconfig1   2.13.1-4.5
ii  libfreetype6 2.12.1+dfsg-3
ii  libgcc-s112.2.0-3
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libgegl-0.4-01:0.4.38-1+b1
ii  libgexiv2-2  0.14.0-1+b1
ii  libgimp-3.0-02.99.10-1
ii  libglib2.0-0 2.74.0-1
ii  libgs9   9.56.1~dfsg-1
ii  libgtk-3-0   3.24.34-3
ii  libgudev-1.0-0   237-2
ii  libharfbuzz0b5.2.0-2
ii  libheif1 1.13.0-1
ii  libilmbase25 2.5.7-2+b1
ii  libjpeg62-turbo  1:2.1.2-1+b1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libjxl0.70.7.0~git20220805.980c90f-3
ii  liblcms2-2   2.13.1-1+b1
ii  liblzma5 5.2.5-2.1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.5-1 1.6.0-2
ii  libopenexr25 2.5.7-1
ii  libopenjp2-7 2.5.0-1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  libpangoft2-1.0-01.50.10+ds-1
ii  libpng16-16  1.6.38-2
ii  libpoppler-glib8 22.08.0-2.1
ii  librsvg2-2   2.54.5+dfsg-1
ii  libstdc++6   12.2.0-3
ii  libtiff5 4.4.0-4
ii  libwebp7 1.2.2-2+b1
ii  libwebpdemux21.2.2-2+b1
ii  libwebpmux3  1.2.2-2+b1
ii  libwmf-0.2-7 0.2.12-5
ii  libwmflite-0.2-7 0.2.12-5
ii  libx11-6 2:1.8.1-2
ii  libxcursor1  1:1.2.1-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-1
ii  libxmu6  2:1.1.3-3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-4.1
ii  zlib1g   1:1.2.11.dfsg-4.1

Versions of packages gimp recommends:
ii  ghostscript  9.56.1~dfsg-1

Versions of packages gimp suggests:
ii  gimp-data-extras  1:2.0.2-1.1
ii  gimp-help-en [gimp-help]  2.10.0-1
pn  gjs   
pn  gvfs-backends 
pn  luajit
ii  python3   3.10.6-1

-- no debconf information

Bug#1010717: aide-common: Also Debian sid is affected

[Kamil Jonca]

Package: aide-common
Version: 0.17.4-2
Followup-For: Bug #1010717
X-Debbugs-Cc: kjo...@poczta.onet.pl

I am not sure if this bug should be against aide-common and not against 
spamassasin package, but it seems 
that expressions in "21_aide_spamassassin" file cannot deal with non - numbers 
version e.g.
4.0.0~rc3-1

KJ



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

Kernel: Linux 5.19.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 aide-common depends on:
ii  aide   0.17.4-2
ii  bsd-mailx [mailx]  8.1.2-0.20220412cvs-1
ii  debconf [debconf-2.0]  1.5.79
ii  liblockfile1   1.17-1+b1
ii  mailutils [mailx]  1:3.15-3
ii  ucf3.0043

Versions of packages aide-common recommends:
ii  cron  3.0pl1-149

aide-common suggests no packages.

-- debconf information:
  aide/aideinit: false
  aideinit/copynew: false
  aideinit/overwritenew: true

Bug#1020760: apt-file: not clear how to do EOL matching

[Curt Sampson]

Package: apt-file
Version: 3.2.2

It's not clear how to anchor a non-`-F` search to end of line. I've
tried adding a dollar sign at the end (e.g. `apt-file search
'n/bash$'`, `apt-file search n/bash\$`) but that doesn't appear to
work. The manual page doesn't actually explain what a "pattern" even
is. It should be updated to document the pattern language and,
ideally, explain this particular point if it's possible to do this
with the pattern language.

cjs
-- 
Curt Sampson  +81 90 7737 2974

To iterate is human, to recurse divine.
- L Peter Deutsch

Bug#1019696: workaround

[Judit Foglszinger]

Attached a suggestion from IRC for a workaround - the author is ok with sharing 
it here -
I mostly just want to throw it there, for the case someone feels inspired by it 
;)
Have tested it with gallery-dl, but not any more packages.
>From a8ac7e35dceda4dd732f2bff05bac51ffab5927f Mon Sep 17 00:00:00 2001
Subject: [PATCH] Fixing handling of github address

See bug #1019696
devscripts: uscan does not work with github anymore -
https://bugs.debian.org/1019696
---
 lib/Devscripts/Uscan/WatchLine.pm | 16 
 lib/Devscripts/Uscan/http.pm  |  2 +-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/lib/Devscripts/Uscan/WatchLine.pm b/lib/Devscripts/Uscan/WatchLine.pm
index 272a8d8..d5494f8 100644
--- a/lib/Devscripts/Uscan/WatchLine.pm
+++ b/lib/Devscripts/Uscan/WatchLine.pm
@@ -726,6 +726,22 @@ EOF
 $filepattern .= '(?:\?.*)?';
 }
 
+# Handle github.com addresses specially
+if (!$self->shared->{bare} and $self->mode ne 'git' and $base =~ m%^https?://github\.com/% and $base !~ m%tags$%) {
+uscan_verbose "GitHub re-write rule.  Abandon all hope ye who enter here.";
+my ($user, $repo) = $base =~ m%^https?://github\.com/([^\/]+)/([^\/]+)/%;
+$base =~ s%^https?://github\.com/%https://api.github.com/repos/%;
+if ($base =~ m%tags$%) {
+# Yes, the full path is needed.  We can't use the provided filepattern as it needs to lack an extension.
+$filepattern = "https://api\\.github\\.com/repos/$user/$repo/tarball/refs/tags/(?:[-_v]?(\\d[-+.:~\\da-zA-Z]*))";
+} else {
+$filepattern =~ s%^.*/\)?%%;
+$filepattern =~ s%^%(?:https://api\\.github\\.com/repos/$user/$repo/tarball/(?:[-_v]?(\\d[-+.:~\\da-zA-Z]*))|https://github\\.com/$user/$repo/releases/download/v?(?:\\d[\\d\\.]*)/%;
+$filepattern =~ s%$%)%;
+}
+$self->searchmode('plain');
+}
+
 # Handle pypi.python.org addresses specially
 if (   !$self->shared->{bare}
 and $base =~ m%^https?://pypi\.python\.org/packages/source/%) {
diff --git a/lib/Devscripts/Uscan/http.pm b/lib/Devscripts/Uscan/http.pm
index 0da9798..c08bff3 100644
--- a/lib/Devscripts/Uscan/http.pm
+++ b/lib/Devscripts/Uscan/http.pm
@@ -482,7 +482,7 @@ sub parse_href {
 # exception, otherwise $mangled_version = 1
 $mangled_version = '';
 } else {
-$mangled_version = join(".",
+$mangled_version = join("",
 map { $_ if defined($_) }
   ref $match eq 'ARRAY' ? @$match : $href =~ m&^$_pattern$&);
 }
-- 
2.35.1

Bug#1020759: postal: reproducible-builds: Embedded build paths in binaries

[Vagrant Cascadian]

Source: postal
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 various binaries:

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

  /usr/bin/postal-list

  /build/1st/postal-0.76+nmu1/expand.cpp:14·(discriminator·2)
  vs.
  /build/2/postal-0.76+nmu1/2nd/expand.cpp:14·(discriminator·2)

The attached patch to debian/rules fixes this by passing the default
CFLAGS to make.

Alternately, updating to use dh and a recent debhelper compat version
might also fix this.

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

Thanks for maintaining postal!

live well,
  vagrant
From c082698686506433efbdacccdccf390bc44895e3 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 26 Sep 2022 01:39:23 +
Subject: [PATCH] debian/rules: Pass default CFLAGS to make.

---
 debian/rules | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 28345f8..517b3af 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,6 +5,8 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+CFLAGS=$(shell dpkg-buildflags --get CFLAGS)
+
 build: build-stamp
 build-stamp:
 	dh_testdir
@@ -12,7 +14,7 @@ build-stamp:
 	
 	# Add here commands to compile the package.
 	./configure --prefix=`pwd`/debian/postal/usr --without-openssl
-	$(MAKE)
+	$(MAKE) CFLAGS="$(CFLAGS)"
 
 	touch build-stamp
 
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1020758: Correct script name: msmtp -> msmtpq

[David Nebauer]

Oops, the script referred to in the original bug report should be
'msmtpq' rather than 'msmtp'.

Bug#1020758: msmtp: upgrade to current upstream version

[David Nebauer]

Package: msmtp
Version: 1.8.16-1+b1
Severity: normal
X-Debbugs-Cc: davidneba...@gmail.com

Dear Maintainer,

The upstream project (1.8.22) is 6 minor releases ahead of the packaged debian
version (1.8.16). Those releases include numerous bugfixes as well as
significant enhancements, including inheriting msmptp's key variables
from the environment, meaning the package version can be linked to
rather than having to copy and edit each new version of the script.

Can the debian version be updated to the current upstream release?

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

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

Versions of packages msmtp depends on:
ii  adduser3.129
ii  debconf [debconf-2.0]  1.5.79
ii  libc6  2.34-8
ii  libgnutls303.7.7-2
ii  libgsasl18 2.2.0-1
ii  libsecret-1-0  0.20.5-3
ii  ucf3.0043

Versions of packages msmtp recommends:
ii  ca-certificates  20211016

Versions of packages msmtp suggests:
pn  msmtp-mta  

-- debconf information:
  msmtp/tls: false
  msmtp/maildomain:
  msmtp/sysconfig: false
  msmtp/port: 25
  msmtp/host:
* msmtp/apparmor: false
  msmtp/auto_from: true

Bug#1020757: rig: reproducible-builds: Embedded build path in /usr/bin/rig

[Vagrant Cascadian]

Source: rig
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/rig:

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

  /build/1st/rig-1.11/rig.cc:303
  vs.
  /build/2/rig-1.11/2nd/rig.cc:303

The attached patch to the upstream Makefile fixes this by passing
-ffile-prefix-map argument to the CXX call.

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

Thanks for maintaining rig!

live well,
  vagrant
From 60d3e87df657bbb1ffa55ed7bea6fabde2a6ca88 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 26 Sep 2022 00:52:09 +
Subject: [PATCH] Makefile: Pass -ffile-prefix-map to CXX call to avoid
 embedding build paths.

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

diff --git a/Makefile b/Makefile
index f41c173..b4bb6f2 100644
--- a/Makefile
+++ b/Makefile
@@ -6,7 +6,7 @@ CXX=g++
 
 all: rig rig.6
 rig: rig.cc
-	${CXX} -O2 -g rig.cc -o rig -Wall -DDATADIR="\"$(DATADIR)\""
+	${CXX} -O2 -g -ffile-prefix-map=$(CURDIR)=. rig.cc -o rig -Wall -DDATADIR="\"$(DATADIR)\""
 
 rig.6: rig.6.in
 	sed s@DATADIR@"$(DATADIR)"@g < rig.6.in > rig.6
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1020756: rakarrack: reproducible-builds: Embedded build path in /usr/bin/rakarrack

[Vagrant Cascadian]

Source: rakarrack
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/rakarrack:

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

  /build/1st/rakarrack-0.6.1/build/src/../../src/main.C:166·(discriminator·3)
  vs.
  /build/2/rakarrack-0.6.1/2nd/build/src/../../src/main.C:166·(discriminator·3)

The attached patch to debian/rules fixes this by passing the default
CXXFLAGS provided by dpkg-buildflags to configure.

Alternately, updating to a newer debhelper compat level might also solve
this issue as well as other issues.

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

Thanks for maintaining rakarrack!

live well,
  vagrant
From 69e43af18c9f59fbbe5404c95e83c987ebec9c97 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 26 Sep 2022 00:48:38 +
Subject: [PATCH] debian/rules: Pass default CXXFLAGS to configure.

---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index 9276fdd..2294fb6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -46,6 +46,7 @@ $(builddir_sse)/config.status:EXTRA_CONFIG_FLAGS += --enable-sse
 			  --build=$(DEB_BUILD_GNU_TYPE)	\
 			  --prefix=/usr			\
 			  $(if $(filter $(DEB_HOST_ARCH_CPU),amd64 i386),--enable-sse2) \
+			  CXXFLAGS="$(shell dpkg-buildflags --get CXXFLAGS)" \
 			  $(EXTRA_CONFIG_FLAGS)
 
 build: build-arch
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1020755: rotter: reproducible-builds: Embedded build path in /usr/bin/rotter

[Vagrant Cascadian]

Source: rotter
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/rotter:

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

  /build/1st/rotter-0.9/src/rotter.c:478
  vs.
  /build/2/rotter-0.9/2nd/src/rotter.c:478

The attached patch to debian/rules fixes this by adding a
dh_auto_configure override which passes the default CFLAGS provided by
dpkg-buildflags.

Alternately, updating to a newer debhelper compat level might also solve
this issue as well as other issues.

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

Thanks for maintaining rotter!

live well,
  vagrant
From c364c7df7596ab2f9ef75df638fed6ed3ddf2a06 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 26 Sep 2022 00:44:03 +
Subject: [PATCH] debian/rules: Add dh_auto_configure override to pass default
 CFLAGS.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 5ca7dc2..a344d88 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,6 +3,9 @@
 %:
 	dh $@ --with=autotools_dev
 
+override_dh_auto_configure:
+	dh_auto_configure -- CFLAGS="$(shell dpkg-buildflags --get CFLAGS)"
+
 override_dh_auto_install:
 	dh_auto_install -- DESTDIR=$(CURDIR)/debian/rotter
 
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1020754: shapetools: reproducible-builds: Embedded build path in sttk.h

[Vagrant Cascadian]

Source: shapetools
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/include/sttk.h:

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

  #define·ST_ENV_DEFAULT»  "/build/1st/shapetools-1.4pl6/debian/tmp/usr"
  vs.
  #define·ST_ENV_DEFAULT»  "/build/2/shapetools-1.4pl6/2nd/debian/tmp/usr"

The attached patch fixes this in debian/rules by removing the build path
and debian/tmp from sttk.h. It is unclear to me if it would be better to
replace it with a placeholder value, or to leave the debian/tmp part; it
really depends how this define is used.

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

Thanks for maintaining shapetools!

live well,
  vagrant
From 57526fa7f4a3f45661247021c4cceb6a919de4b7 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 26 Sep 2022 00:11:40 +
Subject: [PATCH 1/2] debian/rules: Remove build path from sttk.h.

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

diff --git a/debian/rules b/debian/rules
index f7df25f..268b2e1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -363,6 +363,8 @@ binary-arch: build install
 	dh_installchangelogs -p$(p_atfs) CHANGES-1.4
 	dh_strip -a -X.a
 	dh_compress -a
+	# Remove build path for reproducible builds
+	sed -i -e "s,$(CURDIR)/debian/tmp,,g" debian/atfs-dev/usr/include/sttk.h
 	dh_fixperms -a
 	LD_LIBRARY_PATH=$(d_atfslib)/usr/lib:$$LD_LIBRARY_PATH \
 		dh_makeshlibs -V -p$(p_atfslib)
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Dominique MARTINET]

Alberto Garcia wrote on Mon, Sep 26, 2022 at 12:00:04AM +:
> I just uploaded the packages built for bullseye, same URL, the patched
> ones are available already, the unpatched ones soon.

Thanks!

I've tried the patched variant, it seems to fail in the same place?

Here's the new trace with adjusted lines:

/usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x817b3aa0 in __GI_abort () at abort.c:79
#2  0x8427958c in WTFCrashWithInfo(int, char const*, char const*, int) 
() at WTF/Headers/wtf/Assertions.h:754
#3  0x8525db20 in captureStackTrace () at 
../Source/WTF/wtf/StackTrace.cpp:79
#4  0x85232d18 in WTFReleaseLogStackTrace () at 
../Source/WTF/wtf/Assertions.cpp:602
#5  0x884e8934 in internalError () at 
../Source/WebCore/platform/network/ResourceErrorBase.cpp:97
#6  0x869e6c14 in preconnectTo () at 
../Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:733
#7  0x8689baf8 in 
callMemberFunctionImpl
 >, WebKit::NetworkResourceLoadParameters&&), 
std::tuple >, 
WebKit::NetworkResourceLoadParameters>, 0, 1> () at 
../Source/WebKit/Platform/IPC/HandleMessage.h:131
#8  callMemberFunction
 >, WebKit::NetworkResourceLoadParameters&&), 
std::tuple >, 
WebKit::NetworkResourceLoadParameters>, std::integer_sequence > () at ../Source/WebKit/Platform/IPC/HandleMessage.h:137
#9  handleMessage
 >, WebKit::NetworkResourceLoadParameters&&)> () at 
../Source/WebKit/Platform/IPC/HandleMessage.h:259
#10 didReceiveNetworkConnectionToWebProcessMessage () at 
DerivedSources/WebKit/NetworkConnectionToWebProcessMessageReceiver.cpp:357
#11 0x86b3ff1c in dispatchMessage () at 
../Source/WebKit/Platform/IPC/Connection.cpp:1150
#12 0x86b402b4 in dispatchOneIncomingMessage () at 
../Source/WebKit/Platform/IPC/Connection.cpp:1219
#13 0x8525c4b0 in operator() () at ../Source/WTF/wtf/Function.h:82
#14 performWork () at ../Source/WTF/wtf/RunLoop.cpp:133
#15 0x852b5570 in operator() () at 
../Source/WTF/wtf/glib/RunLoopGLib.cpp:80
#16 __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:79
#17 0x852b48f4 in operator() () at 
../Source/WTF/wtf/glib/RunLoopGLib.cpp:53
#18 __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:45
#19 0x81d25ab4 in g_main_context_dispatch () from 
/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#20 0x81d25e5c in ?? () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#21 0x81d261b0 in g_main_loop_run () from 
/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#22 0x852b4ef8 in run () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:108
#23 0x86b11004 in run () at 
../Source/WebKit/Shared/AuxiliaryProcessMain.h:71
#24 AuxiliaryProcessMain () at 
../Source/WebKit/Shared/AuxiliaryProcessMain.h:97
#25 0x817b3e18 in __libc_start_main (main=0x400878 <__wrap_main>, 
argc=3, argv=0xcfa17918, init=, fini=, 
rtld_fini=, stack_end=) at 
../csu/libc-start.c:308
#26 0x00400874 in _start ()



/usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0xa0afdaa0 in __GI_abort () at abort.c:79
#2  0xa35c358c in WTFCrashWithInfo(int, char const*, char const*, int) 
() at WTF/Headers/wtf/Assertions.h:754
#3  0xa45a7b20 in captureStackTrace () at 
../Source/WTF/wtf/StackTrace.cpp:79
#4  0xa457cd18 in WTFReleaseLogStackTrace () at 
../Source/WTF/wtf/Assertions.cpp:602
#5  0xa7832934 in internalError () at 
../Source/WebCore/platform/network/ResourceErrorBase.cpp:97
#6  0xa61e6f6c in internallyFailedLoadTimerFired () at 
../Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp:503
#7  0xa45ff61c in operator() () at 
../Source/WTF/wtf/glib/RunLoopGLib.cpp:177
#8  __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:169
#9  0xa45fe8f4 in operator() () at 
../Source/WTF/wtf/glib/RunLoopGLib.cpp:53
#10 __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:45
#11 0xa106fab4 in g_main_context_dispatch () from 
/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#12 0xa106fe5c in ?? () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#13 0xa10701b0 in g_main_loop_run () from 
/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#14 0xa45feef8 in run () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:108
#15 0xa62a1aac in run () at 
../Source/WebKit/Shared/AuxiliaryProcessMain.h:71
#16 AuxiliaryProcessMain () at 
../Source/WebKit/Shared/AuxiliaryProcessMain.h:97
#17 0xa0afde18 in __libc_start_main (main=0x400878 <__wrap_main>, 
argc=3, argv=0xc73c1cc8, init=, fini=, 
rtld_fini=, stack_end=) at 
../csu/libc-start.c:308
#18 0x00400874 in _start ()


Since the patched variant does not resolve the problem I'm not going to
bother with the unpatched -- please ask if you'd like me to try anyway.


Meanwhile 

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Alberto Garcia]

On Sun, Sep 25, 2022 at 01:40:32PM +0900, Dominique MARTINET wrote:

> > https://people.debian.org/~berto/files/webkitgtk-2.38.0-arm64/

> You were indeed faster than me... But it looks like these packages were
> built for debian testing/bookworm (require libc6 >= 2.34), so I cannot
> test easily due to proprietary libGL and other drivers woes.

Argh, you're right, my fault!!

I just uploaded the packages built for bullseye, same URL, the patched
ones are available already, the unpatched ones soon.

Berto

Bug#1020568: pocketsphinx-python's autopkg tests fail with setuptools 65

[Samuel Thibault]

Hello,

Matthias Klose, le ven. 23 sept. 2022 15:38:42 +0200, a ecrit:
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/pocketsphinx-python/26322074/log.gz
> 
> [...]
> autopkgtest [07:48:02]: test tests: [---
> patching file setup.py
>   configure with PYTHON 3.10 ==
> /tmp/autopkgtest-lxc.wiu8e7yd/downtmp/build.lPV/src/setup.py:7:
> DeprecationWarning: The distutils package is deprecated and slated for
> removal in Python 3.12. Use setuptools or check PEP 632 for potential
> alternatives
>   from distutils import log
> /usr/lib/python3/dist-packages/_distutils_hack/__init__.py:18: UserWarning:
> Distutils was imported before Setuptools, but importing Setuptools also
> replaces the `distutils` module in `sys.modules`. This may lead to
> undesirable behaviors or errors. To avoid these issues, avoid using
> distutils directly, ensure that setuptools is installed in the traditional
> way (e.g. not an editable install), and/or make sure that setuptools is
> always imported before distutils.

Ok, I have fixed this in git, but now we are getting a different issue:

«
error: Multiple top-level packages discovered in a flat-layout: ['swig', 
'deps', 'debian', 'pocketsphinx_disabled'].
To avoid accidental inclusion of unwanted files or directories,
setuptools will not proceed with this build.
If you are trying to create a single distribution with multiple packages
on purpose, you should not rely on automatic discovery.
Instead, consider the following options:
1. set up custom discovery (`find` directive with `include` or `exclude`)
2. use a `src-layout`
3. explicitly set `py_modules` or `packages` with a list of names
To find more information, look for "package discovery" on setuptools docs.
»

I have tried to look at the setuptools documentation, but I fail to find
how to just disable automatic discovery. setup.py really does the job of
listing files etc., so I don't understand what's left to make setuptools
not perform automatic discovery, while previous versions of setuptools
were behaving just fine.

Samuel

Bug#1020753: seqtk: reproducible-builds: Embedded build path in /usr/bin/seqtk

[Vagrant Cascadian]

Source: seqtk
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/seqtk:

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

  /build/1st/seqtk-1.3/seqtk.c:1701
  vs.
  /build/2/seqtk-1.3/2nd/seqtk.c:1701

The attached patch fixes this in debian/rules by adding a dh_auto_build
override which passes the default CFLAGS.

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

Thanks for maintaining seqtk!

live well,
  vagrant
From d5471751a476b5413a1b1636602734d5bfa38c83 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 25 Sep 2022 23:42:54 +
Subject: [PATCH] debian/rules: Pass default CFLAGS to dh_auto_build.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 9d1cab7..d8c76ce 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,3 +14,6 @@ createmanpage:
 
 override_dh_auto_install:
 	echo "Ignore broken Makefile"
+
+override_dh_auto_build:
+	dh_auto_build -- CFLAGS="$(CFLAGS)"
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1020752: sjeng: reproducible-builds: differing buildid in in /usr/games/sjeng

[Vagrant Cascadian]

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

The buildid differs in /usr/games/sjeng when built with a different
build path:

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

The attached patch fixes this in debian/rules by passing
-ffile-prefix-map in CFLAGS.

Alternately, adapting this packge to use the default flags passed via
dpkg-buildflags should solve this issue as well.

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

Thanks for maintaining sjeng!

live well,
  vagrant
From a81c558a587c48c3fed1dd8fd2fa6b74c54e7608 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 25 Sep 2022 23:38:45 +
Subject: [PATCH] debian/rules: Pass -ffile-prefix-map via CFLAGS to avoid
 embedding build path.

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 0b4d87b..67dfb4b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,7 +14,7 @@ export DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 export DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 
 CC = gcc
-CFLAGS = -Wall -W -g
+CFLAGS = -Wall -W -g -ffile-prefix-map=$(CURDIR)=.
 LDFLAGS = 
 
 # C++ is not used in this version, but configure looks for it
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1019786: closed by Debian FTP Masters (reply to Laszlo Boszormenyi (GCS) ) (Bug#1019786: fixed in wxsqlite3 3.4.1~dfsg-6)

[Olly Betts]

Control: reopen -1
Control: notfixed -1 3.4.1~dfsg-6
Control: found -1 3.4.1~dfsg-6

On Sat, Sep 24, 2022 at 10:53:31PM +0200, László Böszörményi (GCS) wrote:
> On Mon, Sep 19, 2022 at 7:48 AM Olly Betts  wrote:
> > It appears that there's now only a single reverse dependency, codelite,
> > which is orphaned so I've updated it and uploaded to experimental too.
>
>  Please take care of it for Sid as well.

Done.

However, the updated wxsqlite3 source package still has a
build-dependency on libwxgtk3.0-gtk3-dev:

Build-Depends:
 debhelper-compat (= 13),
 doxygen,
 libsqlite3-dev (>= 3.15),
 libwxgtk3.2-dev,
 libwxgtk3.0-gtk3-dev

You're meant to replace the dependency on the old version, not update to depend
on both old and new!  You should be able to just drop the old B-D.

This will block the wxwidgets-3.2 transition, so reopening.

Cheers,
Olly

Bug#1020751: waili: reproducible-builds: Embedded build paths in binaries

[Vagrant Cascadian]

Source: waili
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 various binaries:

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

  /usr/lib/libwaili/test/Demo

  /build/1st/waili-19990723/include/waili/LChannel.h
  vs.
  /build/2/waili-19990723/2nd/include/waili/LChannel.h

The attached patch fixes this by using relative paths for the includes
added in CPPFLAGS.

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

Thanks for maintaining waili!

live well,
  vagrant
From 9aa609727944de9c68a74efa892e104271b16aa5 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 25 Sep 2022 23:28:45 +
Subject: [PATCH] config.Rules.Linux.g++: Use relative include path in
 CPPFLAGS.

---
 config/Rules.Linux.g++ | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config/Rules.Linux.g++ b/config/Rules.Linux.g++
index d474191..5fd6da6 100644
--- a/config/Rules.Linux.g++
+++ b/config/Rules.Linux.g++
@@ -37,7 +37,7 @@ OPTFLAGS =	-O3 -fomit-frame-pointer
 
 #changed for Debian: much cleaner; and you can move the directory around
 CFLAGS =	-Wall $(TIFFINC) $(TIFFDEF) $(OPTFLAGS) $(DEBUGFLAGS)
-CPPFLAGS =   -I$(TOPDIR)/include $(TIFFINC) $(TIFFDEF) 
+CPPFLAGS =   -I../include $(TIFFINC) $(TIFFDEF)
 
 
 #changed for debian: if -lwaili is specified, libtool fails to work
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1020750: xjump: reproducible-builds: differing buildid in in /usr/games/xjump

[Vagrant Cascadian]

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

The buildid differs in /usr/games/xjump when built with a different
build path:

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

The attached patch fixes this in debian/rules by passing
-ffile-prefix-map in CFLAGS.

Alternately, adapting this packge to use the default flags passed via
dpkg-buildflags should solve this issue as well.

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

Thanks for maintaining xjump!

live well,
  vagrant
From 9b1cc60b2ea23c754bfc120c6b9272dda1587d8a Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 25 Sep 2022 22:59:19 +
Subject: [PATCH] debian/rules: Pass -ffile-prefix-map in CFLAGS.

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 e5e8720..5826ff7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,7 +8,7 @@ build-indep: build
 
 build:
 	dh_testdir
-	make CFLAGS="-O2 -g -Wall"
+	make CFLAGS="-O2 -g -Wall -ffile-prefix-map=$(CURDIR)=."
 	touch build
 
 clean:
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1020749: gigalomania: reproducible-builds: Embedded build path in /usr/games/gigalomania

[Vagrant Cascadian]

Source: gigalomania
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/games/gigalomania:

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

  /build/1st/gigalomania-1.0+ds1/game.cpp:448
  vs.
  /build/2/gigalomania-1.0+ds1/2nd/game.cpp:448

The attached patch fixes this in debian/rules by passing
-ffile-prefix-map in CCFLAGS.

Alternately, adapting this packge to use the default flags passed via
dpkg-buildflags should solve this issue as well.

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

Thanks for maintaining gigalomania!

live well,
  vagrant
From 55ed148b652bbb21d6e88c5123fb1892f7b020d8 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 25 Sep 2022 22:47:18 +
Subject: [PATCH] debian/rules: Add -ffile-prefix-map to CCFLAGS to avoid
 embedding the build path.

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 c886a60..21c470b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,7 +10,7 @@ LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS)
 
 override_dh_auto_build:
 	$(MAKE) DATADIR="/usr/share/gigalomania" \
-	CCFLAGS="-g -O2 -Wall $(CPPFLAGS)" \
+	CCFLAGS="-g -O2 -Wall $(CPPFLAGS) -ffile-prefix-map=$(CURDIR)=." \
 	LINKPATH="$(LDFLAGS) `sdl2-config --libs` -L/usr/X11R6/lib/ -L/usr/lib" \
 	LIBS="-lSDL2_image -lSDL2_mixer `pkg-config --libs tinyxml`" all
 
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1020748: xcolmix: reproducible-builds: Embedded build path in /usr/bin/xcolmix

[Vagrant Cascadian]

Source: xcolmix
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/xcolmix:

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

  /build/1st/xcolmix-1.07/src/xcolmix.c:55
  vs.
  /build/2/xcolmix-1.07/2nd/src/xcolmix.c:55

The attached patch fixes this in debian/rules by passing
-ffile-prefix-map in STDCFLAGS.

Alternately, adapting this packge to use the default flags passed via
dpkg-buildflags should solve this issue as well.

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

Thanks for maintaining xcolmix!

live well,
  vagrant
From 45adf65a2e6d6c70b78a91064ca468748e8d3c00 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 25 Sep 2022 22:50:54 +
Subject: [PATCH] debian/rules: Pass -ffile-prefix-map in STDCFLAGS to avoid
 embedding build path.

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 6bfa94a..3bf23e2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,7 +10,7 @@ package=xcolmix
 build:
 	$(checkdir)
 
-	(cd src; make final STDLFLAGS="-L /usr/X11R6/lib" STDCFLAGS="-c -O2 -Wall $(XFINCDIR) -g")
+	(cd src; make final STDLFLAGS="-L /usr/X11R6/lib" STDCFLAGS="-c -O2 -Wall $(XFINCDIR) -g -ffile-prefix-map=$(CURDIR)=.")
 	touch build
 
 clean:
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1020747: autoconf-archive: ax_python_devel serial 32 fails with current Sid python3

[Jerome Benoit]

Package: autoconf-archive
Version: 20220903-1
Severity: serious
Tags: upstream
Justification: causes FTBFS issues

Dear Maintainer,

it appears that ax_python_devel serial 32 provided by this package
can cause FTBFS issues. I experienced it with the package grap-tool
(#101). A closer look reveals that the ad hoc python module
ax_python_devel_vpy.py fails with the current Sid Python.
My understanding is that the tuple vpy contains an unexpected string.
Unfortunately I am no familiar with Python to get further.

Cheers,
Jerome

Bug#1010957: status update? Re: Bug#1010957: man-db: unreproducible index.db: contents depend on directory read order

[Colin Watson]

This weekend's work has been:

  https://gitlab.com/cjwatson/man-db/-/compare/bb0f7086ba...5d2594d0a0

A lot of this was code rearrangement that I needed to do before I could
make progress on the real issues, but if you look at the NEWS.md diff
you'll see a number of changes that relate to this bug.  With all of
that, there are 33 lines of diff of accessdb output remaining on my
system against the result of josch's patch, which come down to two
issues:

 * unstable choice of whatis target for pages with many entries in NAME,
   some but not all of which are represented as symlinks in the
   filesystem to a file name that is not itself in NAME (there are some
   examples of this in libbsd-dev and libmd-dev)
 * some difficulty deciding exactly what to do with cross-section links
   in some cases (inetd.conf(5) → inetd(8))

I'll need a bit more concentrated hacking time here, but I'll continue
to work on these; this has been a great opportunity to clean up some
truly unpleasant bits of code.  Once I have the accessdb diff down to
zero, we'll see whether there's any further instability in the on-disk
GDBM representation, and also whether there are any other issues that
don't show up in the set of pages I have installed.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1020746: wasm32-unknown-wasi target attempts to use non-existing include paths

[Faidon Liambotis]

Package: clang-14
Version: 1:14.0.6-2
Severity: normal

Attempting to build a trivial "hello world" program for
the wasm32-unknown-wasi target with:
  clang -v -target wasm32-linux-wasi -o test.wasm test.c

...results in a cc1 command-line that includes:
   -internal-isystem /include/wasm32-wasi -internal-isystem /include
...naturally followed by:
  ignoring nonexistent directory "/include/wasm32-wasi"
  ignoring nonexistent directory "/include"

If one were to pass "-I/usr/include/wasm32-wasi" to work around this, it
becomes apparent that a similar situation is the case for -L:
  wasm-ld-14 ... -L/lib/wasm32-wasi /lib/wasm32-wasi/crt1-command.o ...

Looking at the source, sysroot is prepended on these paths, and seems to
be implied to be always expected. Presumably this originated in a world
where folks had the WASI SDK (and wasi-libc) installed in /opt.

In Debian, the wasi-libc package (the libc for this platform) uses the
/usr/include/wasm32-wasi and /usr/lib/wasm32-wasi paths. Apparently
passing --with-sysroot=/usr works around this issue, pointing clang to
the right paths in Debian.

However, it would be ideal if that indirection was not necessary, and
clang did the right thing out of the box, instead of attempting to
access nonexisting unprefixed paths like /include/.

An example, *untested* kinda hacky fix for this could take the form of
adding this to clang/lib/Driver/ToolChains/WebAssembly.cpp:

  std::string WASI::computeSysRoot() const {
if (!getDriver().SysRoot.empty())
  return getDriver().SysRoot;
  
std::string Path = "/usr";
if (getVFS().exists(Path))
  return Path;
  
return std::string();
  }

Also see #1014567 which describes my confusion upon encountering
wasi-libc. It can be resolved if this bug is accepted, or repurposed to
be a documentation wishlist bug.

Finally, note that even with the fix described in this bug, compilations
to the wasm32-linux-wasi target will not work until #1010932
(availability of compiler-rt for wasm32) is resolved.

Regards,
Faidon

Bug#1020745: ITS: swe-standard-data

[Stanislas Marquis]

Source: swe-standard-data
Version: 4-1.1
Severity: important
X-Debbugs-Cc: jald...@debian.org, pelli...@blackpatchpanel.com, 
m...@qa.debian.org, s...@astrorigin.com

Hello,

I hereby express my intent to salvage the 'swe-standard-data' package.

This is needed for the same reasons as the associated package 'libswe',
see bug #1020741.

Cheers!
--


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

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

Bug#1020695: failure to compute digest: md4 and rmd160

[Richard B. Kreckel]

W.r.t. RIPEMD160, this seems to be a mistake:
https://github.com/openssl/openssl/issues/16994
Also, Fedora seems to have worked around this.

Bug#1020744: ITP: cheat -- Create and view interactive cheatsheets

[Stanislas Marquis]

Package: wnpp
Severity: wishlist
Owner: Stanislas Marquis 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org, 
s...@astrorigin.com

* Package name: cheat
  Version : 4.3.3-1
  Upstream Author : Christopher Allen Lane 
* URL : https://github.com/cheat/cheat
* License : Expat
  Programming Lang: Go
  Description : Create and view interactive cheatsheets

'cheat' allows you to create and view interactive cheatsheets on the
command-line. It was designed to help remind *nix system administrators
of options for commands that they use frequently, but not frequently
enough to remember. It can also be used as a lightweight and flexible
note-taking application.

I intend to maintain this package within the Debian Go team.

Bug#1020743: pure-ftpd: reproducible-builds: Embedded build path in various binaries

[Vagrant Cascadian]

Source: pure-ftpd
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 various binaries:

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

  /usr/bin/pure-pw

  /build/1st/pure-ftpd-1.0.50/src/alt_arc4random.c:149
  vs.
  /build/2/pure-ftpd-1.0.50/2nd/src/alt_arc4random.c:149

The attached patch fixes this in debian/rules by passing
-ffile-prefix-map in in CFLAGS.

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

Thanks for maintaining pure-ftpd!

live well,
  vagrant
From 80d366799f5a4484582092e88315cd63d041454e Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 25 Sep 2022 21:51:30 +
Subject: [PATCH] debian/rules: Add -ffile-prefix map to CFLAGS to avoid
 embedding build path.

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 5efcf37..305ee2c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,7 +5,7 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-cfgflags=--sysconfdir=/etc/pure-ftpd CFLAGS="-O2 -DMAX_USER_LENGTH=128U -g"
+cfgflags=--sysconfdir=/etc/pure-ftpd CFLAGS="-O2 -DMAX_USER_LENGTH=128U -g -ffile-prefix-map=$(CURDIR)=."
 optflags=--with-everything --with-largefile --with-pam --with-privsep --with-tls --with-rfc2640
 bin=pure-pw pure-statsdecode pure-pwconvert
 sbin=pure-authd pure-certd pure-ftpwho pure-uploadscript pure-quotacheck pure-ftpd pure-mrtginfo
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1020704: man-db: Alias for translated man pages do not work if english one is present

[Colin Watson]

On Sun, Sep 25, 2022 at 07:18:38PM +0200, Helge Kreutzmann wrote:
> Now let's take a different example, namely systemd-importd.service
> and systemd-importd.
> 
> Again manpages-de ships only one file, i.e.
> /usr/share/man/de/man8/systemd-importd.service.8.gz
> 
> With 
> man systemd-importd.service
> I'm able to read the German version, however, with
> man systemd-importd
> I get the english version (which exists on my system, different from
> the previous example).
> 
> If I manually enter (as root)
> ln -s /usr/share/man/de/man8/systemd-importd.service.8.gz 
> /usr/share/man/de/man8/systemd-importd.8.gz
> then it works as intended, i.e. I get the German page in both cases.
> 
> For information:
> helge@twentytwo:/usr/share/man/de/man8$ lexgrog nss-myhostname.8.gz
> nss-myhostname.8.gz: "nss-myhostname - Rechnernamenauflösung für die lokal 
> konfigurierten Systemrechnernamen"
> nss-myhostname.8.gz: "libnss_myhostname.so.2 - Rechnernamenauflösung für die 
> lokal konfigurierten Systemrechnernamen"
> 
> helge@twentytwo:/usr/share/man/de/man8$ lexgrog systemd-importd.service.8.gz
> systemd-importd.service.8.gz: "systemd-importd.service - VM- und 
> Container-Abbild-Import und -Exportdienst"
> systemd-importd.service.8.gz: "systemd-importd - VM- und 
> Container-Abbild-Import und -Exportdienst"
> 
> Thus for the English → English man page the alias system works, but it
> does not work for German → German, if the English exists. If it does
> not exist, then it works.

Please add the --debug option to the man(1) invocations that don't work
as expected, and attach the output to this bug.

> I really would like to avoid adding tons of links in manpages-l10n for
> each man page with aliases and each translation (we do ship quite a
> few man pages and translations). 

While I understand this, please note section 12.1 of the Debian Policy
Manual:

  If you do not create any links (whether symlinks, hard links, or .so
  directives) in the file system to the alternate names of the man page,
  then you should not rely on man finding your man page under those
  names based solely on the information in the man page's header.

The arrangements to make things work without symlinks are extremely
complicated and fragile.  If that's what's going on here, then I would
implore you to rethink and add the symlinks (perhaps it could be
automated in your build system without too much trouble).

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1020736: libreswan: reproducible builds: Embeds build hostname in binaries

[Vagrant Cascadian]

Control: retitle 1020736 libreswan: reproducible builds: Embeds build hostname 
in binaries

Fixed title; it only embeds the hostname.


signature.asc
Description: PGP signature

Bug#1020704: man-db: Alias for translated man pages do not work if english one is present

[Colin Watson]

Control: clone -1 -2
Control: reassign -2 manpages-l10n
Control: retitle -2 manpages-l10n: add symlinks rather than relying on whatis 
references

On Sun, Sep 25, 2022 at 07:29:39PM +0200, Helge Kreutzmann wrote:
> ult_src: File /usr/share/man/de/man8/systemd-importd.service.8.gz in mantree 
> /usr/share/man/de
> candidate: 1 0 systemd-importd /usr/share/man/de 
> /usr/share/man/de/man8/systemd-importd.service.8.gz C systemd-importd 8 8
[...]
> ult_src: File /usr/share/man/man8/systemd-importd.8.gz in mantree 
> /usr/share/man
> ult_softlink: (/usr/share/man/man8/systemd-importd.service.8.gz)
> candidate: 0 0 systemd-importd /usr/share/man 
> /usr/share/man/man8/systemd-importd.service.8.gz B - 8 8
> search: 1 0 systemd-importd /usr/share/man/de 
> /usr/share/man/de/man8/systemd-importd.service.8.gz C systemd-importd 8 8 
> (dup: 0)

OK, so it finds both pages but sorts them wrongly, very probably because
the logic in compare_candidates currently considers "ID" (real page,
link of some kind, whatis reference, etc.) at a higher priority than
language.  I can certainly (carefully!) reconsider that logic, but
please fix your package to add the proper symlinks in accordance with
policy 12.1.

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1020741: ITS: libswe

[Stanislas Marquis]

Source: libswe
Version: 1.80.00.0002-1.1
Severity: important
X-Debbugs-Cc: jald...@debian.org, pelli...@blackpatchpanel.com, 
m...@qa.debian.org, s...@astrorigin.com

Hello,

I hereby express my intent to salvage the 'libswe' package. Several years
have passed and many new upstream versions, and unfortunately no
updates on the Debian side.

There is a recent bug filed against one of its components (see #1011976),
which requires that the package be updated. And another 5 years old minor
bug here (#849898).

I have also been waiting to be able to close an ITP of mine
depending on that library (see #958755). I had a few emails with the
maintainer, but he now seems to not be active at all anymore.

An updated version of the package can already be found on salsa:
https://salsa.debian.org/debian-astrology-team/libswe

The associated source package 'swe-standard-data' will also have to be updated.

Cheers!
--


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

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

Bug#1010932: wasm-ld-13: unable to find library -lgcc

[Faidon Liambotis]

Control: reassign -1 libclang-common-14-dev 1:14.0.6-2
Control: retitle -1 Please build and ship compiler-rt for wasm32/wasm64
Tags: patch

Dear maintainer,

clang in Debian right now can build to the wasm32-unknown-wasi target,
as well as the less commonly used wasm64-unknown-wasi target. However,
their use is very limited, as there is no available builtins library in
Debian.

libgcc is not available for WebAssembly. compiler-rt, however, is, and
is what the WASI SDK ships with. Unfortunately it is not being shipped
in Debian right now.

In other words, this is a request to build and ship:
  /usr/lib/llvm-14/lib/clang/14.0.6/lib/wasi/libclang_rt.builtins-wasm32.a
  /usr/lib/llvm-14/lib/clang/14.0.6/lib/wasi/libclang_rt.builtins-wasm64.a

I had success in building these in a clean llvm-toolchain tree with:
  mkdir build; cd build
  cmake \
  -DCMAKE_C_COMPILER=clang \
  -DCOMPILER_RT_STANDALONE_BUILD=ON \
  -DCOMPILER_RT_BAREMETAL_BUILD=ON \
  -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE=wasm32-unknown-wasi \
  -DCOMPILER_RT_OS_DIR=wasi \
  ../compiler-rt/lib/builtins/

The WASI SDK sets a few other options (BUILD_XRAY=OFF etc.) that I don't
know the use of:
  
https://github.com/WebAssembly/wasi-sdk/blob/a0a342ac182caf871223797c48d00138cf67e9fb/Makefile#L102

In the package's debian/rules, this could take the form of the libclc
SPIR-V build. Specifically, something like this (untested):

  debian-rtlib-wasm32-build:
  mkdir -p compiler-rt/lib/builtins/build-wasm32
  echo "Using cmake: $(CMAKE_BIN)"
  cd compiler-rt/lib/builtins/build-wasm32 && \
  $(CMAKE_BIN) ../ \
  -G $(GENERATOR) \
  -DCMAKE_C_COMPILER=$(STAGE_2_BIN_DIR)/clang \
  -DCMAKE_CXX_COMPILER=$(STAGE_2_BIN_DIR)/clang++ \
  -DCMAKE_C_FLAGS="$(opt_flags) $(STAGE_2_CFLAGS)" \
  -DCMAKE_CXX_FLAGS="$(opt_flags) $(STAGE_2_CXXFLAGS)" \
  -DCMAKE_SHARED_LINKER_FLAGS="$(STAGE_2_LDFLAGS) -L$(STAGE_2_LIB_DIR)" 
\
  -DCMAKE_MODULE_LINKER_FLAGS="$(STAGE_2_LDFLAGS) -L$(STAGE_2_LIB_DIR)" 
\
  -DCMAKE_EXE_LINKER_FLAGS="$(STAGE_2_LDFLAGS) -L$(STAGE_2_LIB_DIR)" \
  -DCMAKE_INSTALL_PREFIX=/usr \
  -DCMAKE_INSTALL_DATADIR=lib \
  -DCMAKE_INSTALL_INCLUDEDIR=include \
  -DLLVM_CONFIG=$(STAGE_2_BIN_DIR)/llvm-config \
  -DCOMPILER_RT_STANDALONE_BUILD=ON \
  -DCOMPILER_RT_BAREMETAL_BUILD=ON \
  -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE=wasm32-unknown-wasi \
  -DCOMPILER_RT_OS_DIR=wasi; \
  ninja $(NJOBS) $(VERBOSE)
  touch $@

(to be adjusted e.g. with a for loop for wasm64, plus hooked up on
dh_auto_build, clean etc.)

The resulting binaries could be shipped under libclang-common-14-dev,
or, given their architecture-independent nature, under a new Arch: all
package. I trust you know what's best here :)

Furthermore, given that a) there is no WASM port for libgcc b) Debian
defaults its rtlib to libgcc, this makes all out-of-the-box (i.e.
without --rtlib=compiler-rt) runs to fail. To address this, something
like this could be added to clang/lib/Driver/ToolChains/WebAssembly.cpp
to change the default to compiler-rt specifically for the WebAssembly
targets:

   ToolChain::RuntimeLibType WebAssembly::GetRuntimeLibType(
   const ArgList ) const {
 if (Arg* A = Args.getLastArg(options::OPT_rtlib_EQ)) {
   StringRef Value = A->getValue();
   if (Value != "compiler-rt")
 getDriver().Diag(clang::diag::err_drv_unsupported_rtlib_for_platform)
 << Value << "WebAssembly";
 }
   
 return ToolChain::RLT_CompilerRT;
   }

(This is lifted from Darwin.cpp, and is otherwise also untested.)

Hope this all helps! Apologies for not providing better patches, but
building LLVM takes many hours on machines currently available to me,
which makes iterating on this quite painful. Thank you for maintaining
LLVM in Debian -- my time spent with the package revealed its immense
complexity, and I deeply appreciate all the work it has gone into it.

Regards,
Faidon

Bug#1020717: installation-reports: bookworm alpha1 netboot install FAILED on basesystem install / usrmerge

[Cyril Brulebois]

Hi Holger,

Holger Wansing  (2022-09-25):
> Please note that an installation with alpha1 NETINST image on the same 
> hardware
> worked fine today (see #1020708).
> 
> Now, testing the bookworm alpha1 NETBOOT image on IBM T60 Thinkpad
> (i386 hardware), that failed during base system install: […]

> Sep 25 18:09:41 debootstrap: Setting up usrmerge (31) ...
> Sep 25 18:09:41 debootstrap: dpkg: usrmerge: dependency problems, but 
> configuring anyway as you requested:
> Sep 25 18:09:41 debootstrap:  usrmerge depends on perl:any.
> Sep 25 18:09:41 debootstrap:  usrmerge depends on libfile-find-rule-perl.
> Sep 25 18:09:41 debootstrap: 
> Sep 25 18:09:41 debootstrap: Can't locate autodie.pm in @INC (you may need to 
> install the autodie module) (@INC contains: /etc/perl 
> /usr/local/lib/i386-linux-gnu/perl/5.34.0 /usr/local/share/perl/5.34.0 
> /usr/lib/i386-linux-gnu/perl5/5.34 /usr/share/perl5 
> /usr/lib/i386-linux-gnu/perl-base /usr/lib/i386-linux-gnu/perl/5.34 
> /usr/share/perl/5.34 /usr/local/lib/site_perl) at 
> /usr/lib/usrmerge/convert-etc-shells line 13.
> Sep 25 18:09:41 debootstrap: BEGIN failed--compilation aborted at 
> /usr/lib/usrmerge/convert-etc-shells line 13.
> Sep 25 18:09:41 debootstrap: Setting up libfile-find-rule-perl (0.34-2) ...
> Sep 25 18:09:41 debootstrap: dpkg: error processing package usrmerge 
> (--configure):
> Sep 25 18:09:41 debootstrap:  installed usrmerge package post-installation 
> script subprocess returned error exit status 2
> Sep 25 18:09:41 debootstrap: dpkg: libfile-find-rule-perl: dependency 
> problems, but configuring anyway as you requested:
> Sep 25 18:09:41 debootstrap:  libfile-find-rule-perl depends on perl:any.
> Sep 25 18:09:41 debootstrap: 
> Sep 25 18:09:41 debootstrap: Processing triggers for libc-bin (2.34-8) ...
> Sep 25 18:09:41 debootstrap: Errors were encountered while processing:
> Sep 25 18:09:41 debootstrap:  usrmerge
> Sep 25 18:14:11 base-installer: error: exiting on error 
> base-installer/debootstrap-failed

I only followed that from afar, but I suspect the difference between
both installations is that netinst embeds init-system-helpers 1.64 (in
testing at the time the image was built), while netboot pulls 1.65.2
(in testing currently).

For the actual debootstrap issue, see #1020426 (NMU on the way).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1020726: rust-log: please provide feature kv_unstable_serde

[Peter Green]

Please provide feature kv_unstable_serde, needed for packages I am
preparing for Debian.


This requires the serde feature in value-bag to be enabled, which
in turn requires sval and serde_fmt

sval is currently in NEw 
https://ftp-master.debian.org/new/rust-sval_1.0.0~alpha.5-1.html

I don't see any evidence that anyone is currently working on serde_fmt

Bug#1016922: pkgconf: fails to find spirv

[Andrej Shadura]

Hi,

On Thu, 11 Aug 2022, at 01:08, Peter Green wrote:
> I originally saw the bug in raspbian bookworm, and decided to check it 
> in sid before filing the
> bug, but I must have screwed up somewhere.
>
> Anyway, I've just retested it in in an up to date debian sid 
> environment and confirmed it is
> reproducible there. with versoin 1.8.0-1 of pkgconf and version 
> 11.10.0-1 of glslang-dev

Thanks. Apparently, pkgconf doesn’t accept .pc files indented by spaces, which 
spirv.pc and glslang.pc are. As far as I can see, ruby-pkg-config accepts 
those, so probably pkgconf should too.

-- 
Cheers,
  Andrej

Bug#1020740: cpu-x needs to be recompiled against current libpci

[T. Joseph Carter]

Package: cpu-x
Version: 4.3.1-1
Severity: important
X-Debbugs-Cc: Mike Gabriel 

Cc to Mike Martin as Martin's email address no longer works because he
no longer works for Canonical:

https://www.omgubuntu.co.uk/2021/02/martin-wimpress-ubuntu-desktop-lead-leaving-canonical

If there's another email address to reach him at, I don't know it.

When I run cpu-x, messages about the wrong version of libpci being used
are printed:

tjcarter@aki:~$ cpu-x
CPU-X:core.c:674: pci_access is not properly initialized: it is a common issue 
when CPU-X was built with a lower libpci version.
Check that libpci 3.7.0 library is present on your system. Otherwise, please 
rebuild CPU-X.
No kernel driver in use for graphic card at path (null)
Your GPU user mode driver is unknown: 4.6 (Compatibility Profile) Mesa 
22.2.0-rc3

The message even describes how to fix it: Recompile against the current
libpci version. I did so, and:

tjcarter@aki:~/Source/cpu-x/cpu-x-4.3.1$ obj-x86_64-linux-gnu/output/bin/cpu-x 
--dump
There is no platform with OpenCL support (CL_PLATFORM_NOT_FOUND_KHR)
  >> CPU <<

* Processor *
  Vendor: AMD
   Code Name: Ryzen 7 (Matisse)
:

:
Swap: 10.24 GiB / 65.00 GiB


  >> Graphics <<

* Card 0 *
  Vendor: AMD
  Driver: amdgpu
 UMD Version: Mesa 22.2.0-rc3
:


Perhaps libpci needs to be tightened up to ensure that programs like
cpu-x get rebuilt? It appears the ABI has changed incompatibly without
bumping the soname, and this happens often enough to warrant an
explanation of how to fix it in the downstream program. (That's gotta be
frustrating for the devs!)

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

Kernel: Linux 5.19.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_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 cpu-x depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  libc62.34-8
ii  libcairo21.16.0-6
ii  libcpuid15   0.5.1+repack1-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libgl1   1.5.0-1
ii  libglfw3 3.3.8-1
ii  libglib2.0-0 2.74.0-1
ii  libgtk-3-0   3.24.34-3
ii  libncursesw6 6.3+20220423-2
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  libpci3  1:3.8.0-1
ii  libprocps8   2:3.3.17-7+b1
ii  libtinfo66.3+20220423-2
ii  procps   2:3.3.17-7+b1

cpu-x recommends no packages.

cpu-x suggests no packages.

-- no debconf information

Bug#1020739: autopkgtest regression with flask 2.2.2

[Thomas Goirand]

Source: flask-appbuilder
Version: 4.1.4+ds-1
Severity: important

Hi,

I've uploaded Flask 2.2.2 to Experimental, and its excuse page shows that
there are regressions with your package:
https://qa.debian.org/excuses.php?experimental=1=flask

Please fix them before I upload Flask 2.2.2 in Unstable, likely in a week or 2.

Cheers,

Thomas Goirand (zigo)

Bug#1020695: failure to compute digest: md4 and rmd160

[Richard B. Kreckel]

On 9/25/22 21:14, Sebastian Andrzej Siewior wrote:

See the man page for OSSL_PROVIDER-legacy.


Having to add a the extra option -provider legacy breaks otherwise 
flawless existing software.


There are no good reasons to break openssl dgst -rmd160, since RIPEMD160 
is a hash algorithm with still good security properties. It is used by a 
lot of crypto software (e.g. BitCoin...) Here is how this breaks 
Python's HashLib:

$ python
Python 3.10.7 (main, Sep  8 2022, 14:34:29) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> h = hashlib.new('ripemd160')
Traceback (most recent call last):
  File "/usr/lib/python3.10/hashlib.py", line 160, in __hash_new
return _hashlib.new(name, data, **kwargs)
ValueError: [digital envelope routines] unsupported

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.10/hashlib.py", line 166, in __hash_new
return __get_builtin_constructor(name)(data)
  File "/usr/lib/python3.10/hashlib.py", line 123, in 
__get_builtin_constructor

raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type ripemd160

  -richy.
--
Richard B. Kreckel




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020731: Please package the non-color version

[Jeremy Bicha]

Control: forwarded -1 https://github.com/googlefonts/noto-emoji/issues/390
Control: tags -1 +upstream

Google hasn't released the source for the new monochrome font yet.

When it's released, we'll likely do a new binary package for it. If
Google releases it in a separate git repo (which is what I'm guessing
they'll do), this will also be in a new source package.

Thank you,
Jeremy Bicha

Bug#1020738: RM: hubicfuse -- ROM; service is shutting down

[Stephen Kitt]

Package: ftp.debian.org
Severity: normal

Dear FTP team,

hubicfuse is only useful with the hubiC service, and that is shutting
down on September 30. The replacement is Nextcloud-based so hubicfuse
won't be any use with it.

Regards,

Stephen

Bug#1020732: debhelper: dh_auto_install should invoke cmake --install

[Andrea Pappacoda]

Il giorno dom 25 set 2022 alle 22:35:15 +02:00:00, Andrea Pappacoda 
 ha scritto:

this could be
roughly translated to `cmake --install builddir --prefix=dir --strip` 
(note

that using the DESTDIR env var instead of the --prefix option is also
supported[2]).


Sorry, --prefix and DESTDIR have different meaning also in the `cmake 
--install` command. Hence using the DESTDIR environment variable is the 
only option.

Bug#1020737: autopkgtest failures with python-werkzeug 2.2.2

[Thomas Goirand]

Source: httpbin
Version: 0.7.0+dfsg-3
Severity: important

Hi,

I'm planning to upload python-werkzeug 2.2.2 to Unstable, though your package
has autopkgtest regressions with this version. Please fix this asap.

Cheers,

Thomas Goirand (zigo)

Bug#1020736: libreswan: reproducible builds: Embeds build username and hostname in binaries

[Vagrant Cascadian]

Source: libreswan
Version: 4.6-1
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: hostname
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Ever since version 4.6-1, libreswan has been embedding the hostname in
various binaries:

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

  /usr/libexec/ipsec/_import_crl

  
./lib/libipsecconf/../../OBJ.linux.amd64.ionos5-amd64/lib/libipsecconf/lex.yy.c.tmp:1806
  vs.
  
./lib/libipsecconf/../../OBJ.linux.amd64.i-capture-the-hostname/lib/libipsecconf/lex.yy.c.tmp:1806

The attached patch fixes this by setting OBJDIR from debian/rules.

I am not positive there are not other outstanding issue, but this
*might* be enough to make libreswan build reproducibly again.

Thanks for maintaining libreswan!

live well,
  vagrant
From c68ea5c4e44bf175b1223e7bb3f3f7516a602f22 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 25 Sep 2022 20:50:29 +
Subject: [PATCH] debian/rules: Pass OBJDIR to avoid embedding hostname.

By default, OBJDIR is defined in mk/objdir.mk, which includes the
system hostname, and this value gets  embedded in the generated
binaries.
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index 5491fbf..b7dd981 100755
--- a/debian/rules
+++ b/debian/rules
@@ -31,6 +31,7 @@ NSS_AVA_MISSING=$(shell if printf '#include \nint main() { return CERT_C
 
 DEBIAN_LIBRESWAN_BUILD_FLAGS = \
 		ARCH=$(DEB_HOST_ARCH) \
+		OBJDIR=OBJ.$(DEB_HOST_ARCH_OS).$(DEB_HOST_ARCH) \
 		IPSECVERSION=$(DEB_VERSION_UPSTREAM) \
 		PREFIX=/usr \
 		FINALLIBEXECDIR=/usr/libexec/ipsec \
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1020735: autopkgtest failures with python-werkzeug 2.2.2

[Thomas Goirand]

Source: httpbin
Version: 0.7.0+dfsg-3
Severity: important

Hi,

I'm planning to upload python-werkzeug 2.2.2 to Unstable, though your package
has autopkgtest regressions with this version. Please fix this asap.

Cheers,

Thomas Goirand (zigo)

Bug#1020733: autopkgtest failures with python-werkzeug 2.2.2

[Thomas Goirand]

Source: httpbin
Version: 0.7.0+dfsg-3
Severity: important

Hi,

I'm planning to upload python-werkzeug 2.2.2 to Unstable, though your package
has autopkgtest regressions with this version. Please fix this asap.

Cheers,

Thomas Goirand (zigo)

Bug#1020732: debhelper: dh_auto_install should invoke cmake --install

[Andrea Pappacoda]

Package: debhelper
Version: 13.9.1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, this bug is really similar to #1006805, but this time the suggestion
applies to CMake.

The `cmake --install` command has existed since CMake 3.15[1], and the most
useful feature that this command has compared to plain `make install` is
support for the `--component` flag, which is really handy when doing partial
builds (-arch or -indep-only).

dh_auto_install currently invokes `cd builddir && make -j4 install DESTDIR=dir
AM_UPDATE_INFO_DIR=no "INSTALL=install --strip-program=true"`; this could be
roughly translated to `cmake --install builddir --prefix=dir --strip` (note
that using the DESTDIR env var instead of the --prefix option is also
supported[2]).

[1]: https://cmake.org/cmake/help/latest/release/3.15.html#command-line
[2]: https://cmake.org/cmake/help/latest/envvar/DESTDIR.html


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 debhelper depends on:
ii  autotools-dev20220109.1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.13.0-1
ii  dpkg 1.21.9
ii  dpkg-dev 1.21.9
ii  dwz  0.14-1
ii  file 1:5.41-4
ii  libdebhelper-perl13.9.1
ii  libdpkg-perl 1.21.9
ii  man-db   2.10.2-3
ii  perl 5.34.0-5
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCYzC7ghQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p4RxAP4331ZZNBFXG8ocKa9ekxoa8o8rv23r
ijuKJDZz2n5ppQD+M4MBTjq1jACUzPQ71lDuXfZjMhFQn3un/E8+ohCfhg4=
=DlpF
-END PGP SIGNATURE-

Bug#756456: Please split the fonts

[Hilmar Preuße]

Am 26.12.2021 um 14:35 teilte Amr Ibrahim mit:

Hi,


I also support the split. Please split the fonts into their own
packages.

There is a duplicate bug about this: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983291


I'm too interested in a package split. Here at TeX Live packaging we get 
a lot lintian warnings like:


W: texlive-fonts-extra: duplicate-font-file also in (fonts-noto-extra) 
[usr/share/texlive/texmf-dist/fonts/truetype/google/noto/NotoSansMono-SemiBold.ttf]
W: texlive-fonts-extra: duplicate-font-file also in (fonts-noto-extra) 
[usr/share/texlive/texmf-dist/fonts/truetype/google/noto/NotoSansMono-Thin.ttf]


Therefore we declare a dep on these packages and replace it by a 
reference (soft link) to the file. For fonts-noto-extra does not work 
out: replacing 20MB files in a package by a dep on a > 300MB package is 
not really an option.


+1

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020731: Please package the non-color version

[Yuri D'Elia]

Package: fonts-noto-color-emoji
Version: 2.038-1
Severity: wishlist

Noto also includes a mostly black version called simply "Noto Emoji".

https://fonts.google.com/noto/specimen/Noto+Emoji

I find this version to be a better up-to-date replacement for
fonts-symbola, as well as being more readable when emojis are
interspersed with text.

Would it be possible to have a package for it?

Thanks!

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

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

Bug#1020712: wireless-tools: Upstream contact all do no longer work

[Guus Sliepen]

On Sun, Sep 25, 2022 at 07:57:28PM +0200, Helge Kreutzmann wrote:

> I tried to contact upstream, however, this is not possible. The e-mail
> address 
> j...@hpl.hp.com
> times out, as does the homepage you reference:
> http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html

The website works for me. He has been a co-author on networking related
papers even this year, so he is still active in his field, but it's been
a long time since he has worked on Wireless Tools (which has been
deprecated for a long time now).

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#1020730: autopkgtest failures with python-werkzeug 2.2.2

[Thomas Goirand]

Source: sentry-python
Version: 1.9.4-1
Severity: important

Hi,

I'm planning to upload python-werkzeug 2.2.2 to Unstable, though your package
has autopkgtest regressions with this version. Please fix this asap.

Cheers,

Thomas Goirand (zigo)

Bug#1020729: autopkgtest failure with python-werkzeug 2.2.2

[Thomas Goirand]

Source: quart
Version: 0.14.1-1
Severity: important

Hi,

I'm planning to upload python-werkzeug 2.2.2 to Unstable, though your package
has autopkgtest regressions with this version. Please fix this asap.

Cheers,

Thomas Goirand (zigo)

Bug#1020728: autopkgtest with python-werkzeug 2.2.2

[Thomas Goirand]

Source: pytest-httpbin
Version: 1.0.0-3
Severity: important

Hi,

I'm planning to upload python-werkzeug 2.2.2 to Unstable, though your package
has autopkgtest regressions with this version. Please fix this asap.

Cheers,

Thomas Goirand (zigo)

Bug#1018724: rust-jemalloc-sys FTBFS on riscv64(gc)

[Blair Noctis]

On Mon, 29 Aug 2022 23:02:02 +0800 Blair Noctis  wrote:
> After some tests I found that its bundled, pre-generated configure script may
> be the cause. jemalloc itself successfully builds using its autogen.sh script.

The cause should be upstream config.{guess,sub} not having a riscv64gc entry.
jemalloc itself did build, but recognized as a general riscv64.

-- 
Regards,
Blair Noctis


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020727: rust-web-sys: please provide feature console

[Jonas Smedegaard]

Source: rust-web-sys
Version: 0.3.55-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please provide feature console, needed by packages I am preparing for
Debian.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmMwtJEACgkQLHwxRsGg
ASHGnw/8DVCWtJ35TqL2qz8NRqIlNDZgoY6Bz86JmXPLI0jLk4xKQQrSj2vpubo2
iuN2EWS/2lOFnzhOIGhm1q+EIP/SjZYTrDVxjjJRFZxvLzS7l5nH+FAygTbJXBaL
XX1JE7uG0wLLwIaI7Ndba9/PFDBqGPbGd+pNN2ATtFkuJvrTtas3biqAM+MZOTkl
FQlQdyRIUEH1E4/65NNSdhwWtnsxMYiRuG/ztNsFTBOrzTFyIyhaZf9MNNsWcYjh
14uChAJxRzI5L3fajMLhBVELvmzUmf3Vx28LsMcypufiNWNL63YopOMh1WZRa0JW
HbfilBKZ890+rzcBQGChoJWDatEJfSgD+RrRg0JvWVTfhCoWIpjYYvmE8p+rLWCB
4FbN4PyZ2obUMz1kFyOy9xh1HIuuCx+xqUUNG4SJSOFh5DmpMy6eMdumz7J4rM/O
cn7daGzUwToqt1lBQrTJ9M6DEuDfD/UqJdhyMBbxNc4G+QAoLGfQ1eus7mi1eBBH
6D+KJyFsCLzRzblAdMpJgO7I4WSb+3KWVXtj+Law3o+wCslEHNh5+rD/MUqUMIGa
8WsJJevzIT/HAslizF60In6f8nwCsypGHMshtEm00RdpYET0F1E/Iahklcql8y6A
QdcdA7+xe78CzhAhDpn+IOavgIMUtAFD+PD/FPE3yDvfOiEVhAg=
=D4+5
-END PGP SIGNATURE-

Bug#1020726: rust-log: please provide feature kv_unstable_serde

[Jonas Smedegaard]

Source: rust-log
Version: 0.4.17-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please provide feature kv_unstable_serde, needed for packages I am
preparing for Debian.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmMws+QACgkQLHwxRsGg
ASHpHBAAjSk05+AlDZ2ukXq+hsCwTyyK0XGVyaQPD/2AJ6uHQr0mZ0Pb3cHDRHpV
RBvcoDwzZayGXgcNlTDejcK7gciidoxZPxb77vsqsnFs530mUFzvwunzMpE4GZ7R
6x69MRwdlRhVotwFcIw6I1zRF0VyDTO3Pbvsvgc6/7SBo3VbkxeQt9K96tqDNA+M
9HrEyC6YwJ/MrOKc9ZHZ7sZrUM+a/iPqJSoM8+QrUWx81lEUy5aF+S9JYKDjl2kF
HRz1VwkffyS9c7KWG7+/dtcQjUyi+xDJCAoaXBScI3WqBfPrxXmwAp7RjDpZmByp
/0AsNJfujAfUM/bY7q4mtyLe4MPC4+wqUh5aL6mRoKG3RUsPaQtG33INERjmrE/p
o5eT0ZvEl7+AvA2nwMB1rUqlD+oHWCnjl1U+AKVS9pqddLLGUt23lXAu4zLtIJAj
8ZDtjLR+ESq1sA2EadnPXUpoS5/WALUz0Pt0Betp+4CGYvCW/IuKg3qlvKZki7jq
WhOH5CrzfhKc9tZu+OMkm7BUc6Qm8rG8ig/71y1j8TD0uT6payo3kqrw5J/Nt0dX
+FOBwY/hAtEB4zm8CXwSa6hcAM52dUpVC9d18uH1ltQtzibwRAlqPPXw6g9YAr34
CQWKsjAkXAGQM6QWpN2mFksivlVALgF6wi05r48FhG0+tUE5jro=
=Wqx9
-END PGP SIGNATURE-

Bug#1020397: reverse dependency

[Steven Robbins]

Hi,

I'll start by a short digression.  If you know the answer to this: what must I 
do to get reliable replies to bugs sent to my email box?  In my recollection 
that was routine a number of years ago but nowadays I essentially never see 
replies and only find them by happenstance -- when perusing bugs via the web 
interface.


On Fri, 23 Sep 2022 17:24:03 + (UTC) Thorsten Alteholz 
 wrote:

> Checking reverse dependencies...
> # Broken Depends:
> matrix-mirage: matrix-mirage

Yes.  That is orphaned.  I thought it would be simply removed.  Do you need me 
to file a RM bug for it?

-Steve


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

Bug#1017629: python-jsonschema: Please provide a newer upstream release (>= 4.9.0)

[Thomas Goirand]

On 9/25/22 18:11, Samuel Henrique wrote:

Hello Thomas,


FYI, 4.7.2 is uploaded to Experimental, and will go to Unstable when
OpenStack Zed will be release on the 5th of October.


Awesome, thanks for your work.


I would prefer to keep that version if it's not annoying others.
Please let me know.


ansible-lint requires jsonschema >=4.9.0 for any release >= 6.4.0 (the
latest one being 6.6.1 at this time).

Upstream's changelog between 4.7.2 and 4.9.1 seems to only contain
bugfixes, although they could surely still trigger issues with
jsonschema's deps, but maybe that would be doable?!

I would like to try going with 4.9.1 on experimental at least (now
that 4.7.2 is on unstable) so we can have an idea of possible
breakages.
Then we can discuss possibly having 4.9.1 for bookworm if you think
that's ok, and I won't push if you still want to stick to 4.7.2.
The bump from 3.2 has been quite helpful already and I understand
we're dealing with compromises where ideally we would probably want to
have more than one version available in the repos.

Cheers,


Hi,

I just uploaded version 4.9.1 to Experimental. Since most OpenStack 
packages have autopkgtest, I'm confident to upload it to unstable if I 
see no breakage. We can re-do this incrementally if needed.


Let's see what the pseudo-excuse page says in a few hours...

Cheers,

Thomas Goirand (zigo)

Bug#1020725: snapper: reproducible-builds: Embedded build path in example Makefile

[Vagrant Cascadian]

Source: snapper
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/libsnapper-dev/examples/Makefile:

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

  ACLOCAL·=·${SHELL}·'/build/1st/snapper-0.10.2/missing'·aclocal-1.16
  vs.
  ACLOCAL·=·${SHELL}·'/build/2/snapper-0.10.2/2nd/missing'·aclocal-1.16

The attached patch fixes this in debian/rules by removing the Makefile
in a dh_installexamples override. Removing the Makefile seems better
than sanitizing the build path, as in order to use it, one would have to
regenerate it from the provided Makefile.in or Makefile.am to match the
running system.

With this patch applied (and another recently submitted to fix usrmerge
issues) snapper should build reproducibly on
tests.reproducible-builds.org!

Thanks for maintaining snapper!

live well,
  vagrant
From bfce7a9e7d00177d4ff7c3b5e4e9a12457d49149 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 25 Sep 2022 19:37:56 +
Subject: [PATCH 2/2] debian/rules: Add dh_installexamples override to remove
 an example Makefile containing build paths.

This file may need to be regenerated from Makefile.am or Makefile.in
to match the system on which it is being run.

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

diff --git a/debian/rules b/debian/rules
index 241b9bb..161bad8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -36,6 +36,11 @@ override_dh_auto_install:
 	# Cleanup examples
 	make -C examples clean
 
+override_dh_installexamples:
+	dh_installexamples
+	# Remove example Makefile which contains build path for reproducible builds
+	rm -f debian/libsnapper-dev/usr/share/doc/libsnapper-dev/examples/Makefile
+
 override_dh_compress:
 	dh_compress -X.c -X.cc -X.h -X.hpp -X.am
 
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1020724: snapper: reproducible-builds: Embedded usrmerge path in libsnapper.so.6.0.1

[Vagrant Cascadian]

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

The binary path for "rm" is embedded in 
/usr/lib/x86_64-linux-gnu/libsnapper.so.6.0.1:

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

  /bin/rm
  vs.
  /usr/bin/rm

As well as several other binary paths in an example Makefile.

The attached patch fixes this in debian/rules by pasing variables to
configure to use the non-usrmerge paths, which are the most compatible
across all systems.

With this patch applied snapper should build reproducibly on
tests.reproducible-builds.org when once it migrates to testing!

Thanks for maintaining snapper!

live well,
  vagrant
From 61e138da79fe1de6f3b2ac2de2268b3523f782c8 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 25 Sep 2022 19:09:51 +
Subject: [PATCH 1/2] debian/rules: Pass variables to ensure consistent paths
 in binaries.

Use the most compatible paths for CPBIN, GREP, EGREP, FGREP, MKDIR_P,
RMBIN and SED, which differ depending on if built on a usrmerge
vs. non-usrmerge system.
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 9285363..241b9bb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,7 +12,7 @@ include /usr/share/dpkg/architecture.mk
 	dh $@
 
 override_dh_auto_configure:
-	dh_auto_configure -- --with-conf=/etc/default --disable-zypp --enable-xattrs --disable-silent-rules --disable-ext4
+	dh_auto_configure -- --with-conf=/etc/default --disable-zypp --enable-xattrs --disable-silent-rules --disable-ext4 CPBIN=/bin/cp GREP=/bin/grep EGREP='/bin/grep -E' FGREP='/bin/grep -F' MKDIR_P='/bin/mkdir -p' RMBIN=/bin/rm SED=/bin/sed
 
 override_dh_auto_install:
 	dh_auto_install
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1020723: python-omegaconf: reproducible-builds: Embedded build path in OmegaConfGrammer*.py

[Vagrant Cascadian]

Source: python-omegaconf
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 several files
/usr/lib/python3/dist-packages/omegaconf/grammar/gen/OmegaConfGrammar*.py:

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

  /usr/lib/python3/dist-packages/omegaconf/grammar/gen/OmegaConfGrammarLexer.py

  
#·Generated·from·/build/1st/python-omegaconf-2.2.2/omegaconf/grammar/OmegaConfGrammarLexer.g4·by·ANTLR·4.9.3
  vs.
  
#·Generated·from·/build/2/python-omegaconf-2.2.2/2nd/omegaconf/grammar/OmegaConfGrammarLexer.g4·by·ANTLR·4.9.3

The attached patch fixes this from the dh_auto_install override in
debian/rules by replacing the build path in these files with a
placeholder string.

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

Thanks for maintaining python-omegaconf!

live well,
  vagrant
From 6f5873415c94145a89c70978c26295fc96ac343f Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 25 Sep 2022 19:28:43 +
Subject: [PATCH] debian/rules: Replace build path in OmegaConfGrammer*.py with
 a placeholder string for reproducible builds.

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

diff --git a/debian/rules b/debian/rules
index 42ab50c..0941c33 100755
--- a/debian/rules
+++ b/debian/rules
@@ -21,6 +21,12 @@ override_dh_auto_build:
 
 override_dh_auto_install:
 	pkgos-dh_auto_install --no-py2 --in-tmp
+	# Replace build path with a placeholder string for reproducible builds
+	sed -i -e "s,$(CURDIR),BUILDPATH,g" \
+		debian/tmp/usr/lib/python3/dist-packages/omegaconf/grammar/gen/OmegaConfGrammarParserVisitor.py \
+		debian/tmp/usr/lib/python3/dist-packages/omegaconf/grammar/gen/OmegaConfGrammarParserListener.py \
+		debian/tmp/usr/lib/python3/dist-packages/omegaconf/grammar/gen/OmegaConfGrammarParser.py \
+		debian/tmp/usr/lib/python3/dist-packages/omegaconf/grammar/gen/OmegaConfGrammarLexer.py \
 
 ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
 	for i in `py3versions -rv` ; do \
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1020722: gnome-calls: Lot of records in user.log - No suitable card found

[Stefan Kropp]

Package: gnome-calls
Version: 43~rc.0-1+b1
Severity: normal

Dear Maintainer,

I'm running gnome-calls on a Laptop without SIM module - also no SIP account
configured, yet.

After staring the application there are a lot of records in /var/log/user.log.

Sep 25 20:56:22 callaudiod[1210]: No suitable card found, retrying in 3s...
Sep 25 20:56:25 callaudiod[1210]: No suitable card found, retrying in 3s...
Sep 25 20:56:28 callaudiod[1210]: No suitable card found, retrying in 3s...

grep callaudiod /var/log/user.log /var/log/user.log.1 |wc -l
13116

Those records will be also created, when I'm killing gnome-calls process.

This may the reason of the record:
https://sources.debian.org/src/callaudiod/0.1.4-2/src/cad-pulse.c/?hl=448#L448

I'm not sure if it's related to gnome-calls or callaudiod.

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

Kernel: Linux 5.19.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 gnome-calls depends on:
ii  dconf-gsettings-backend [gsettings-backe  0.40.0-3
ii  gstreamer1.0-plugins-bad  1.20.3-2
ii  gstreamer1.0-plugins-good 1.20.3-1
ii  libc6 2.34-8
ii  libcallaudio-0-1  0.1.4-1
ii  libebook-contacts-1.2-4   3.45.3-1.2
ii  libfeedback-0.0-0 0.0.0+git20220520-1
ii  libfolks260.15.5-2+b1
ii  libgee-0.8-2  0.20.6-1
ii  libglib2.0-0  2.74.0-1
ii  libgom-1.0-0  0.4-1
ii  libgstreamer1.0-0 1.20.3-1
ii  libgtk-3-03.24.34-3
ii  libhandy-1-0  1.8.0-1
ii  libmm-glib0   1.18.10-2
ii  libpeas-1.0-0 1.34.0-1
ii  libsecret-1-0 0.20.5-3
ii  libsofia-sip-ua-glib3 1.12.11+20110422.1+1e14eea~dfsg-3
ii  libsofia-sip-ua0  1.12.11+20110422.1+1e14eea~dfsg-3
ii  modemmanager  1.18.10-2

Versions of packages gnome-calls recommends:
ii  callaudiod  0.1.4-1
ii  gnome-contacts  43~rc-1

gnome-calls suggests no packages.

-- no debconf information
Thank you for using reportbug

Bug#1020721: O: microsocks -- tiny, portable SOCKS5 server

[Tong Sun]

Package: wnpp
Severity: normal

Dear Debian maintainers,

I no longer wish to be marked as the maintainer of this Debian
package. Could someone mark this package as orphaned?

Thank you.

-- Forwarded message -
From: Boyuan Yang 
Date: Sat, Sep 24, 2022 at 8:36 PM
Subject: Bug#1020667: microsocks: Please package new upstream version 1.0.3
To: 


Package: microsocks
Version: 1.0.1-2
Severity: normal
Tags: sid
X-Debbugs-CC: suntong...@users.sourceforge.net

Dear Debian microsocks package maintainer,

As shown in https://github.com/rofl0r/microsocks/releases , the microsocks
upstream has released a new version 1.0.3 in Feb 2022. Please consider
packaging it in Debian. Thanks!

Best,
Boyuan Yang
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEfncpR22H1vEdkazLwpPntGGCWs4FAmMvoYgACgkQwpPntGGC
Ws4VixAAwcfVcc3SGULKYvkU2y4oU1wCf+tjk0Yf2/GJC7kIafb0lg7ppacs7Zbm
NMgkk9T4O82W6KsyR3zlZGET3OqlEsVJvcMC1S32N0aMA1Zg87Br5h0uJwoh8CT/
bMQkwh6hWL8q9PVTei1kxsy9BuaRaq3TbK6+2DYi1qXJUufN4EEq11kFegUVIeUI
A7H1+Ed8SwuSfpXSoRAhz/WUrIEMnDY+xItDKA+6FnG3JIvijOaMAlGk6E5O/UeR
xgL0GSuMe5+/NI+KGlRdC95KoDrjTHxH8adB6imIrBIbW6PqbKtnmBpHnuyo+c7+
QxtPfunFB5fKz4DQ5KxJ1pjKttI72IDAoRUQv/gClhNbplysOoXedal5wOBJwzva
ZUDuAzVQ3tlZPkRf49J9fONO64hqIOGOVLIrxB/mSRB8sVdqI/EEUpSefl2EtDQN
KRwTUYY1IQYm3LMYAz8Njr3kR1+eIlBCsrD4UeXvVPr+7cQQxUzo6HjxznWsaaoE
7A7wnhPJV6mwxJWoydIZJu79WSfu2JM4Mtzghbd+aJ5vQBo8fPe2s6qhd9GymmSi
DgHpMP9lXCDVv/43+iTcEj5+nECKGpxRnjMnrr0HIWC8TRLyngBYaJyh21Gk2fiZ
OUfeDD7sxAte+/r+tGlBW2Qoh2AVP9jktA9+nJaVgkUVfwd1s8w=
=QUvR
-END PGP SIGNATURE-

Bug#1020720: spectacle cannot take snapshot

[anthony]

Package: spectacle
Version: kde-spectacle
Severity: important
X-Debbugs-Cc: lkphantom1...@gmail.com

Dear Maintainer,

Spectacle cannot take snapshot on my computer. I'm running KDE5 with 
kwin-wayland. When i launch the spectacle, it prints strange output to terminal:

=
libpng error: Read Error
QPixmap::scaled: Pixmap is a null pixmap
 end 

then the spectacle UI says, 'could not take a snapshot please report this bug 
here ...', with blank preview.


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

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

Bug#1020719: chibicc: reproducible-builds: Embedded build path in /usr/bin/chibicc

[Vagrant Cascadian]

Source: chibicc
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/chibicc:

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

  /build/1st/chibicc-0+git20220719+ds/codegen.c:18
  vs.
  /build/2/chibicc-0+git20220719+ds/2nd/codegen.c:18

The attached patch fixes this in debian/rules by adding a dh_auto_build
override which passes the default CFLAGS.

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

Thanks for maintaining chibicc!

live well,
  vagrant
From 5c37115b41af9fefeec01905bbac0142c33a08df Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 25 Sep 2022 18:34:21 +
Subject: [PATCH] debian/rules: Pass CFLAGS to dh_auto_build.

The default CFLAGS are ignored otherwise, which include flags to avoid
embedding the build path.

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

diff --git a/debian/rules b/debian/rules
index 167fe42..6b36119 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,3 +12,6 @@ export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
 
 %:
 	dh $@
+
+override_dh_auto_build:
+	dh_auto_build -- CFLAGS="$(CFLAGS)"
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1020718: should at least suggest the expected compressors

[Marc Haber]

Package: initramfs-tools
Version: 0.142
Severity: minor

Hi,

a few weeks ago, update-initramfs has started to complain that zstd is
not present on the systems. As I have lost the overview over the
compressor-of-the-year evolution slope, I don't have zstd installed, and
I also can only guess from the message which compressor is preferred by
update-initramfs nowadays.

It would be helpful to have a Suggests: zstd | lz4 | xz ... in the
package that would indicate the preference of compressors, giving a hint
about which compressor to install to get rid of those pesky warnings.

Greetings
Marc

Bug#1020717: installation-reports: bookworm alpha1 netboot install FAILED on basesystem install / usrmerge

[Holger Wansing]

Package: installation-reports


NOTE:
Please note that an installation with alpha1 NETINST image on the same hardware
worked fine today (see #1020708).

Now, testing the bookworm alpha1 NETBOOT image on IBM T60 Thinkpad
(i386 hardware), that failed during base system install:





Debootstrap warning
Warning: failure while configuring required packages.



Debootstrap warning
Warning: see the log for details.



Base system installation error
The debootstrap program exited with an error (return value 1).

Check /var/log/syslog or see virtual console 4 for the details.



Failed to install the base system
The base system installation into /target/ failed.

Check /var/log/syslog or see virtual console 4 for the details.



Installation step failed

An installation step failed. You can try to run the failing item again
from the menu, or skip it and choose something else. The failing step
is: Install the base system




Further info on console 4 shows:

Sep 25 18:09:39 debootstrap: Setting up libpam-modules-bin (1.5.2-2) ...
Sep 25 18:09:39 debootstrap: Setting up libpam-modules:i386 (1.5.2-2) ...
Sep 25 18:09:39 debootstrap: Setting up passwd (1:4.11.1+dfsg1-2) ...
Sep 25 18:09:39 debootstrap: Shadow passwords are now on.
Sep 25 18:09:39 debootstrap: Setting up libpam-runtime (1.5.2-2) ...
Sep 25 18:09:40 debootstrap: Setting up login (1:4.11.1+dfsg1-2) ...
Sep 25 18:09:40 debootstrap: Setting up adduser (3.129) ...
Sep 25 18:09:40 debootstrap: Setting up apt (2.5.2) ...
Sep 25 18:09:40 debootstrap: adduser: The user `_apt' already exists, but is 
not a system user. Exiting.
Sep 25 18:09:41 debootstrap: Setting up usrmerge (31) ...
Sep 25 18:09:41 debootstrap: dpkg: usrmerge: dependency problems, but 
configuring anyway as you requested:
Sep 25 18:09:41 debootstrap:  usrmerge depends on perl:any.
Sep 25 18:09:41 debootstrap:  usrmerge depends on libfile-find-rule-perl.
Sep 25 18:09:41 debootstrap: 
Sep 25 18:09:41 debootstrap: Can't locate autodie.pm in @INC (you may need to 
install the autodie module) (@INC contains: /etc/perl 
/usr/local/lib/i386-linux-gnu/perl/5.34.0 /usr/local/share/perl/5.34.0 
/usr/lib/i386-linux-gnu/perl5/5.34 /usr/share/perl5 
/usr/lib/i386-linux-gnu/perl-base /usr/lib/i386-linux-gnu/perl/5.34 
/usr/share/perl/5.34 /usr/local/lib/site_perl) at 
/usr/lib/usrmerge/convert-etc-shells line 13.
Sep 25 18:09:41 debootstrap: BEGIN failed--compilation aborted at 
/usr/lib/usrmerge/convert-etc-shells line 13.
Sep 25 18:09:41 debootstrap: Setting up libfile-find-rule-perl (0.34-2) ...
Sep 25 18:09:41 debootstrap: dpkg: error processing package usrmerge 
(--configure):
Sep 25 18:09:41 debootstrap:  installed usrmerge package post-installation 
script subprocess returned error exit status 2
Sep 25 18:09:41 debootstrap: dpkg: libfile-find-rule-perl: dependency problems, 
but configuring anyway as you requested:
Sep 25 18:09:41 debootstrap:  libfile-find-rule-perl depends on perl:any.
Sep 25 18:09:41 debootstrap: 
Sep 25 18:09:41 debootstrap: Processing triggers for libc-bin (2.34-8) ...
Sep 25 18:09:41 debootstrap: Errors were encountered while processing:
Sep 25 18:09:41 debootstrap:  usrmerge
Sep 25 18:14:11 base-installer: error: exiting on error 
base-installer/debootstrap-failed



Installation logs attached.


So long
Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076


installer-logs.tar.gz
Description: application/gzip

Bug#1018459: Maintainer proposed patch to remove dep

[Stephan Lachnit]

Hi Felix,

I'm terribly sorry that I didn't find the time to upload this earlier - I'm
glad you found another sponsor. Please feel free to annoy me with pings in
the future so that I don't forget things like this :)

Cheers,
Stephan

Bug#1020716: ITP: tryton-modules-* -- Collection of 56 base modules for the Tryton application platform

[Mathias Behrle]

X-Debbugs-CC: debian-de...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Debian Tryton Maintainers 


I am merging 56 ITPs into this one to avoid spamming d-devel with 56
single mails. All those modules are base modules published by the Tryton
project. With the packaging of those missing modules we are closing the gap
between what is available in Tryton and Debian.

As all of the following templates were created automatically, all descriptions
etc. will of course be some more reviewed.



From: Mathias Behrle 
To: Debian Bug Tracking System 
Subject: ITP: tryton-modules-purchase-secondary-unit -- Tryton application 
platform - purchase secondary unit module

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Debian Tryton Maintainers 

* Package name: tryton-modules-purchase-secondary-unit
  Version : 6.0.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : https://downloads.tryton.org/6.0
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton application platform - purchase secondary unit module

 Tryton is a high-level general purpose application platform. It is the base
 of a complete business solution as well as a comprehensive health and hospital
 information system (GNUHealth).
 .
 The purchase secondary unit module adds a secondary unit of measure on purchase
 lines.
 The secondary quantity and unit price are kept synchronized with the quantity
 and unit price.
 The secondary unit is defined on the product supplier or on the product with
 its factor against the purchase unit.


This package is another base module published by the Tryton project.From: 
Mathias Behrle 
To: Debian Bug Tracking System 
Subject: ITP: tryton-modules-production-outsourcing -- Tryton application 
platform - production outsourcing module

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Debian Tryton Maintainers 

* Package name: tryton-modules-production-outsourcing
  Version : 6.0.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : https://downloads.tryton.org/6.0
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton application platform - production outsourcing module

 Tryton is a high-level general purpose application platform. It is the base
 of a complete business solution as well as a comprehensive health and hospital
 information system (GNUHealth).
 .
 The production outsourcing module allows to outsource production order per
 routing. When such outsourced production is set to waiting, a purchase order is
 created and its cost is added to the production.
 .
 To define an outsourced production, the routing must have a *Supplier*, a
 *Service* and its *Quantity* defined. Those values will be used to create the
 purchase order. The bought quantity is computed by multiplying the *Quantity*
 by the factor between the bill of material and the production quantity.


This package is another base module published by the Tryton project.From: 
Mathias Behrle 
To: Debian Bug Tracking System 
Subject: ITP: tryton-modules-sale-gift-card -- Tryton application platform - 
sale gift card module

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Debian Tryton Maintainers 

* Package name: tryton-modules-sale-gift-card
  Version : 6.0.4
  Upstream Author : Tryton project (www.tryton.org)
* URL : https://downloads.tryton.org/6.0
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton application platform - sale gift card module

 Tryton is a high-level general purpose application platform. It is the base
 of a complete business solution as well as a comprehensive health and hospital
 information system (GNUHealth).
 .
 The *Sale Gift Card Module* manages the selling and redeeming of gift cards.
 .


This package is another base module published by the Tryton project.From: 
Mathias Behrle 
To: Debian Bug Tracking System 
Subject: ITP: tryton-modules-marketing -- Tryton application platform - 
marketing module

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Debian Tryton Maintainers 

* Package name: tryton-modules-marketing
  Version : 6.0.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : https://downloads.tryton.org/6.0
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton application platform - marketing module

 Tryton is a high-level general purpose application platform. It is the base
 of a complete business solution as well as a comprehensive health and hospital
 information system (GNUHealth).
 .
 The marketing module defines the fundamentals for marketing modules.


This package is another base module published by the Tryton project.From: 
Mathias Behrle 
To: Debian Bug Tracking System 
Subject: ITP: tryton-modules-account-statement-aeb43 -- Tryton 

Bug#1020713: initramfs-tools: RESUME=auto probably a security hole

[Christoph Anton Mitterer]

Am 25. September 2022 20:13:26 MESZ schrieb Bastian Blank :
>On Sun, Sep 25, 2022 at 08:05:29PM +0200, Christoph Anton Mitterer wrote:
>But an attacker can already modify the kernel command line.  Secure boot
>up until recently was completely incompatible with hibernation, so
>nothing here applies anyway.

As I've explained, not e.g. in a FDE scenario, where one boots from a secure 
USB stick (which is anyway the only sensible way to do it.

Neither in a scenario as that with the ATM where an attacker could *only* 
access sind service USB port, but not e.g. a keyboard or anything else. 

Cheers,
Chris.

Bug#1020715: xserver-xorg-input-joystick: reproducible-builds: Embedded build path in joystick_drv.so

[Vagrant Cascadian]

Source: xserver-xorg-input-joystick
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/lib/xorg/modules/input/joystick_drv.so:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/xserver-xorg-input-joystick.html

  /build/1st/xserver-xorg-input-joystick-1.6.3/build/src/../../src/jstk.c:298
  vs.
  /build/2/xserver-xorg-input-joystick-1.6.3/2nd/build/src/../../src/jstk.c:298

The attached patch fixes this in debian/rules by passing
-ffile-prefix-map in CFLAGS to configure.

With this patch applied xserver-xorg-input-joystick should build reproducibly on
tests.reproducible-builds.org!

Thanks for maintaining xserver-xorg-input-joystick!

live well,
  vagrant
From 3810247bbd3d038b4d8ac21016d43ca809a8f0b9 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 25 Sep 2022 18:17:21 +
Subject: [PATCH] debian/rules: Pass CFLAGS to dh_auto_configure, and include
 -ffile-prefix-map to avoid embedding build path.

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 c721608..9e13de7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 override_dh_auto_configure:
-	dh_auto_configure -- --disable-silent-rules
+	dh_auto_configure -- --disable-silent-rules CFLAGS="$(CFLAGS) -ffile-prefix-map=$(CURDIR)=."
 
 # Install in debian/tmp to retain control through dh_install:
 override_dh_auto_install:
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1020713: initramfs-tools: RESUME=auto probably a security hole

[Bastian Blank]

On Sun, Sep 25, 2022 at 08:05:29PM +0200, Christoph Anton Mitterer wrote:
> Isn't that a rather simple security hole for an attacker with local access
> to the system to easily defeat full disk encryption with dm-crypt (in
> combination with booting from a safe USB) and to a certain extent secure boot?

But an attacker can already modify the kernel command line.  Secure boot
up until recently was completely incompatible with hibernation, so
nothing here applies anyway.

Bastian

-- 
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
   stardate 4842.6

Bug#1020705: glibc: Keep DT_HASH

[Aurelien Jarno]

control: reassign 1020705 src:gcc-12
control: forcemerge 1019535 1020705

Hi,

On 2022-09-25 13:21, Jeremy Bicha wrote:
> Source: glibc
> Version: 2.36-1
> Tags: patch
> 
> Please consider restoring DT_HASH in your glibc 2.36 packaging. Here's
> an article with more details:
> 
> https://lwn.net/Articles/904892/

I already filled #1019535 which I consider is the way to go, but I am
opened for discussion. I am still waiting for an answer from the GCC
maintainer.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1020714: cryptsetup: cryptroot-* autopkgtests fall-back to shell and hang on errors

[Paul Gevers]

Source: cryptsetup
Version: 2:2.5.0-2
Severity: serious

Dear maintainer,

I was starting at some 14 hour failures in testing [1] due to
merged-/usr, which apparently you already fixed in unstable. However,
the reason for that long run was not the failure itself, but the fact
that your tests drop to shell on error and apparently waits for user
input. One failure with 2:2.5.0-3 in unstable has the same problem.

This is pretty bad for our infrastructure as normally your test is
much faster and it shouldn't wait for the time out. Can you please fix
that?

Paul

[1] https://ci.debian.net/packages/c/cryptsetup/testing/amd64/

https://ci.debian.net/data/autopkgtest/unstable/amd64/c/cryptsetup/26349209/log.gz

The partition table has been altered.
Calling ioctl() to re-read partition table.
[1.904096]  vda: vda1 vda2 vda3 vda4 vda5
Syncing disks.
+ echo -n topsec[1.908756]  vda: vda1 vda2 vda3 vda4 vda5
ret
+ cryptsetup luksFormat --batch-mode --key-file=/rootfs.key --type=luks2 
--pbkdf=argon2id --pbkdf-force-iterations=4 --pbkdf-memory=32 -- /dev/vda5
Device /dev/vda5 does not exist or access denied.
+ echo ALERT!  Couldn't setup system, dropping to a shell.
ALERT!  Couldn't setup system, dropping to a shell.
+ sh -i
# autopkgtest [19:14:06]: ERROR: timed out on command "su -s /bin/bash root -c 
set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true;  . 
~/.profile >/dev/null 2>&1 || true; 
buildtree="/tmp/autopkgtest-lxc.6pwp9hgu/downtmp/build.q7w/src"; mkdir -p -m 
1777 -- "/tmp/autopkgtest-lxc.6pwp9hgu/downtmp/cryptroot-sysvinit-artifacts"; 
export 
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.6pwp9hgu/downtmp/cryptroot-sysvinit-artifacts";
 export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 
"/tmp/autopkgtest-lxc.6pwp9hgu/downtmp/autopkgtest_tmp"; export 
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.6pwp9hgu/downtmp/autopkgtest_tmp"; export 
ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; export 
LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=64; unset LANGUAGE LC_CTYPE 
LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME 
LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL;rm -f 
/tmp/autopkgtest_script_pid; set -C; echo $$ > /tmp/autopkgtest_script_pid; set 
+C; trap "rm -f /tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd 
"$buildtree"; export AUTOPKGTEST_NORMAL_USER=debci; export 
ADT_NORMAL_USER=debci; chmod +x 
/tmp/autopkgtest-lxc.6pwp9hgu/downtmp/build.q7w/src/debian/tests/cryptroot-sysvinit;
 touch /tmp/autopkgtest-lxc.6pwp9hgu/downtmp/cryptroot-sysvinit-stdout 
/tmp/autopkgtest-lxc.6pwp9hgu/downtmp/cryptroot-sysvinit-stderr; 
/tmp/autopkgtest-lxc.6pwp9hgu/downtmp/build.q7w/src/debian/tests/cryptroot-sysvinit
 2> >(tee -a /tmp/autopkgtest-lxc.6pwp9hgu/downtmp/cryptroot-sysvinit-stderr 
>&2) > >(tee -a 
/tmp/autopkgtest-lxc.6pwp9hgu/downtmp/cryptroot-sysvinit-stdout);" (kind: test)

Bug#1020713: initramfs-tools: RESUME=auto probably a security hole

[Christoph Anton Mitterer]

Package: initramfs-tools
Version: 0.142
Severity: important
Tags: security


Hey.

According to initramfs.conf(5):
>   RESUME
>  Specifies  the  device  used  for suspend-to-disk (hibernation),
>  which the initramfs code should attempt to resume from.  If this
>  is not defined or is set to auto, mkinitramfs will automatically
>  select the largest available swap partition.  Set it to none  to
>  disable resume from disk.

AFAIAU, this means that Debians initramfs would, per default, take the
biggest swap found when booting and use that for un-hibernation.

Isn't that a rather simple security hole for an attacker with local access
to the system to easily defeat full disk encryption with dm-crypt (in
combination with booting from a safe USB) and to a certain extent secure boot?

All an attacker would need to do, is silently attack a USB stick with some
big enough swap partition to the system and wait for the rightful owner
to boot with the safe boot-USB stick (which e.g. contains the key to unlock
the encrypted system.
The initramfs on that safe boot-USB would then automatically pick up the
swap from the attacker's USB,... and then game over.



Even outside the FDE scope, I can think of scenarios where this allows attacking
a system that would otherwise be secure.
That's a bit constructed, but just in order to get the idea:

Take an ATM, which for an attacker is physically not fully available, though
some USB port is.
The machine is considered secure, as regularly it wouldn't execute anything from
USB unless the client (e.g. a debug console) authenticates.
But if the initramfs would un-hibernate from it, that woud likely circumvent 
such
protections. All the attacker would need to do is gain access to the servinging
USB port and then trigger a reboot (e.g. via power outage).



I think the simplest solution for this would be to just not automatically 
resume AND
to warn people in the manpage, that when in e.g. FDE scenarios they'd need to 
specify
a "safe" device as resume device, i.e. not /dev/disk/by-label/foo but
/dev/mapper/myCryptSwap.


I further think that even though this whole issue may sound quite
simple and not like a super complex attack like some remote code
execution, Spectre or rowhammer... it still seems to be a pretty easy
way to completely defeat e.g. full-disk-encryption in a way people may
not expect.


Cheers,
Chris.

Bug#1020711: sslh: prerm improvements - don't stop TWICE

[Andreas Henriksson]

Package: sslh
Version: 1.20-1
Severity: normal

Dear Maintainer,

I'm attaching a couple of *untested* patches that should improve the
package prerm maintainer script. The patch headers should explain what
their purpose is.


I'm also including the prerm from the binary package below for
your convenience so you can see that stop is done twice (on
systemd systems).

-8<->8-
#!/bin/sh
set -e

case "$1" in
remove|upgrade|purge)
# if sslh is running, stop it before removing
if pidof sslh >/dev/null 2>&1; then
# test if invoke-rc.d command is present on this system
if command -v invoke-rc.d >/dev/null 2>&1; then
invoke-rc.d sslh stop
# if really not, use initscript
else
/etc/init.d/sslh stop
fi
fi
;;

*)
echo "prerm called with unknown argument \`$1'" >&2
exit 1
;;
esac

# Automatically added by dh_installsystemd/12.6.1
if [ -d /run/systemd/system ] && [ "$1" = remove ]; then
deb-systemd-invoke stop 'sslh.service' >/dev/null || true
fi
# End automatically added section

exit 0
-8<->8-

Regards,
Andreas Henriksson
>From 44f17216824a2dd117b1cb13776825ce155b08b1 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson 
Date: Sun, 25 Sep 2022 19:41:31 +0200
Subject: [PATCH 1/2] Always use invoke-rc.d when stopping on remove

Rely on the 'status' argument in init script / systemd service
to check for running service (rather than open-coding it using pidof).

While at it also simplify commands since (Debian Policy mandated helper)
invoke-rc.d is part of Essential and should always be available on all
supported systems.
---
 debian/prerm | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/debian/prerm b/debian/prerm
index ee6f19b..f144910 100644
--- a/debian/prerm
+++ b/debian/prerm
@@ -4,14 +4,8 @@ set -e
 case "$1" in
 remove|upgrade|purge)
 	# if sslh is running, stop it before removing
-	if pidof sslh >/dev/null 2>&1; then
-		# test if invoke-rc.d command is present on this system
-		if command -v invoke-rc.d >/dev/null 2>&1; then
-		invoke-rc.d sslh stop
-		# if really not, use initscript
-		else
-		/etc/init.d/sslh stop
-		fi
+	if invoke-rc.d --quiet sslh status > /dev/null 2>&1 ; then
+	invoke-rc.d sslh stop
 	fi
 ;;
 
-- 
2.30.2

>From 10e914affc8ee5797a23e732158d0ec7272c3a06 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson 
Date: Sun, 25 Sep 2022 19:45:06 +0200
Subject: [PATCH 2/2] Treat systemd services same as init scripts

The package is already using dh compat 12, which means systemd services
are installed via the dh_installsystemd rather than dh_installinit (as
used to happen in some ancient dh compat level?). This seems to have
been missed when upgrading the compat.

This for example avoids prerm to try to stop the service *twice*
when using systemd. (Since #DEBHELPER# was expanded to a second
stop on top of the manually added stop command.)
---
 debian/rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/rules b/debian/rules
index c3cf9cc..ad11b3d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -21,6 +21,8 @@ override_dh_auto_install:
 # do not start daemon by default: force user to configure
 override_dh_installinit:
 	dh_installinit --no-start --no-enable
+override_dh_installsystemd:
+	dh_installsystemd --no-start --no-enable
 
 %:
 	dh $@
-- 
2.30.2

Bug#1020712: wireless-tools: Upstream contact all do no longer work

[Helge Kreutzmann]

Source: wireless-tools
Version: 30~pre9-13.1
Severity: minor

I tried to contact upstream, however, this is not possible. The e-mail
address 
j...@hpl.hp.com
times out, as does the homepage you reference:
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html

Do you know any other contact info?

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

Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1020654: C.UTF-8: surprising differences in character classes

[Thorsten Glaser]

Hi Aurelien,

>Starting with glibc 2.35, we do not patch the glibc to add C.UTF-8
>support, instead we use the upstream code which comes with the following
>NEWS entry [1]:
[…]

Thanks for the extra info.

>> They are as mandated by POSIX for the C locale. I believe I said
>> in my original 2013 proposal for a C.UTF-8 locale that it should
>> be as close to C as possible while using UTF-8 as encoding.
>
>Those are mandated for the POSIX C locale, but POSIX does not say
>anything (yet) about the C.UTF-8 locale.

Right. But, as I wrote above, my intent was to have C.UTF-8 to mirror
C as closely as possible.

>The choice made by upstream has been discussed during many years [2],
>if you disagree with it, please come back to upstream.

*sigh* but I understand your PoV.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#1020710: RFP: flycheck-grammalecte -- Adds support for Grammalecte (a french grammar checker) to flycheck.

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-emac...@lists.debian.org

* Package name: flycheck-grammalecte
  Version : 2.1
  Upstream Author : Étienne Deparis 
* URL : https://git.umaneti.net/flycheck-grammalecte/about/
* License : GPLv3
  Programming Lang: Elisp
  Description : Integrate Grammalecte with Flycheck

Integrate the french grammar and typography checker Grammalecte with
flycheck to automatically look for mistakes in your writings. It also
provides an easy way to find synonyms and antonyms for a given word
(to avoid repetitions for exemple). This package is of very little
interest for other languages.



I've been forcing myself to write in french this week (!) and I found
out I got really bad at it. A friend told me they found a metric ton
of mistakes grammalecte could easily pick up, which is even worse. But
at least it's there.

Now I don't really want to copy-paste stuff between Emacs and
LibreOffice. In fact, I would be much happier never ever starting
LibreOffice at all, but that's another story.

Point is: there's a plugin for this, and it's flycheck-grammalecte,
and we should have this fantastic thing in Debian now that Grammalecte
itself is.

Bug#1020709: unifont doesn't ship unifont_jp.hex any more

[Samuel Thibault]

Package: unifont
Version: 1:15.0.01-1
Severity: important
Tags: d-i
Control: affects -1 + bterm-unifont
Control: notfound 1:14.0.04-1

Hello,

As of version 1:15.0.01-1, the unifont package is not shipping
/usr/share/unifont/unifont_jp.hex any more, while it was shipping it in
version 1:14.0.04-1. Could you restore it? This is making the current
git tree of the bterm-unifont package fail to build:

https://salsa.debian.org/installer-team/bterm-unifont/-/jobs/3293385

Samuel

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

Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 unifont depends on:
ii  fonts-unifont  1:15.0.01-1
ii  psf-unifont1:15.0.01-1

Versions of packages unifont recommends:
ii  xfonts-unifont  1:15.0.01-1

Versions of packages unifont suggests:
ii  unifont-bin  1:15.0.01-1

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Bug#1020277: 20copyfiles: cp: not writing through dangling symlink

[Christoph Biedl]

Control: tags 1020277 confirmed pending
Control: severity 1020277 important
Control: found 1020277 1.6.10-12+deb11u1

Christoph Biedl wrote...

> Yeah, stumbled upon this as well, thanks for taking a closer look.

This affects stable as well. So I'll add this to a list of things to
include in the next stable point release.

Christoph



signature.asc
Description: PGP signature

Bug#1020707: popa3d: postinst should use policy-mandated helpers

[Andreas Henriksson]

Package: popa3d
Version: 1.0.3-1
Severity: serious
Tags: patch

Dear Maintainer,

The postinst script currently directly calls into the init script,
while Debian Policy mandate that all interactions from maintainer
scripts should happen via the policy helpers invoke-rc.d, et.al.
https://www.debian.org/doc/debian-policy/ch-opersys.html#running-init-scripts

For your convenience I've attached a patch that should fix this,
however notice that I have *not* tested it!



Bonus list of things you might want to consider looking at "while you're
in there" (some of these might be policy violations of their own, some
not):
* update_defaults is always called, should likely only be called
  when package is reconfigured or initially configured.
  Sysadms can make changes to the configuration, doesn't
  need to use dpkg-reconfigure / debconf, and loosing their config
  on package upgrades is critical severity because of data loss.
  https://www.debian.org/doc/debian-policy/ap-flowcharts.html
  
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-configuration
  https://www.debian.org/doc/debian-policy/ch-files.html#behavior
  https://www.debian.org/Bugs/Developer#severities
* update_defaults modifies conffiles in a non-policy compliant way.
  consider using the ucf tool for installing changed /etc/default/popa3d
  Using ucf will both prompt on changes and save a backup of the old
  file, as required.
* tempfile command has no cleanup (see trap example in man tempfile).
* Attempt to catch $? and conditionally exit on error, but the script
  already uses `set -e` so any command returning error will abort the
  script immediately. Was this ever tested?
* "WARNING: tempfile is deprecated; consider using mktemp instead."
* "# /var/lib/popa3d should be created by package" well it's /var
  so don't trust it to be unchanged. Should probably wrap the
  chmod/chown commands in an `if test -d /var/lib/popa3d ; then`.



Regards,
Andreas Henriksson
diff --git a/debian/postinst b/debian/postinst
index 75e32aa..4b27350 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -17,7 +17,9 @@ update_defaults()
 	update-inetd --pattern "popa3d" --remove pop3
 else
 	RUN_STANDALONE="no"
-	pidof popa3d && /etc/init.d/popa3d stop
+	if invoke-rc.d --quiet popa3d status > /dev/null 2>&1 ; then
+		invoke-rc.d popa3d stop
+	fi
 # Add service to /etc/inetd.conf
 update-inetd --group MAIL --add 'pop3\t\tstream\ttcp\tnowait\troot\t/usr/sbin/tcpd\t/usr/sbin/popa3d'
 fi

Bug#1020704: man-db: Alias for translated man pages do not work if english one is present

[Helge Kreutzmann]

Hello Colin,
and here is the requeste run with --debug:
On Sun, Sep 25, 2022 at 07:18:38PM +0200, Helge Kreutzmann wrote:
> With 
> man systemd-importd.service
> I'm able to read the German version, however, with
> man systemd-importd
> I get the english version (which exists on my system, different from
> the previous example).

Script started on 2022-09-25 19:27:01+02:00 [TERM="linux" TTY="/dev/tty3" 
COLUMNS="240" LINES="75"]
[?2004hhelge@twentytwo:~$ exitpo4a --verbose po4a.cfg
exit--debugm--debuga--debugn--debug
 --debug--debug systemd-importd
[?2004l
ruid=1000, euid=1000
rgid=1000, egid=1000
++priv_drop_count = 1
From the config file /etc/manpath.config:
  Mandatory mandir `/usr/man'.
  Mandatory mandir `/usr/share/man'.
  Mandatory mandir `/usr/local/share/man'.
  Path `/bin' mapped to mandir `/usr/share/man'.
  Path `/usr/bin' mapped to mandir `/usr/share/man'.
  Path `/sbin' mapped to mandir `/usr/share/man'.
  Path `/usr/sbin' mapped to mandir `/usr/share/man'.
  Path `/usr/local/bin' mapped to mandir `/usr/local/man'.
  Path `/usr/local/bin' mapped to mandir `/usr/local/share/man'.
  Path `/usr/local/sbin' mapped to mandir `/usr/local/man'.
  Path `/usr/local/sbin' mapped to mandir `/usr/local/share/man'.
  Path `/usr/X11R6/bin' mapped to mandir `/usr/X11R6/man'.
  Path `/usr/bin/X11' mapped to mandir `/usr/X11R6/man'.
  Path `/usr/games' mapped to mandir `/usr/share/man'.
  Path `/opt/bin' mapped to mandir `/opt/man'.
  Path `/opt/sbin' mapped to mandir `/opt/man'.
  Global mandir `/usr/man', catdir `/var/cache/man/fsstnd'.
  Global mandir `/usr/share/man', catdir `/var/cache/man'.
  Global mandir `/usr/local/man', catdir `/var/cache/man/oldlocal'.
  Global mandir `/usr/local/share/man', catdir `/var/cache/man/local'.
  Global mandir `/usr/X11R6/man', catdir `/var/cache/man/X11R6'.
  Global mandir `/opt/man', catdir `/var/cache/man/opt'.
  Global mandir `/snap/man', catdir `/var/cache/man/snap'.
  Added sections: `1', `n', `l', `8', `3', `0', `2', `3posix', `3pm', `3perl', 
`3am', `5', `4', `9', `6', `7'.
is a tty
using pager as pager
path directory /usr/local/bin is in the config file
  adding /usr/local/man to manpath
  adding /usr/local/share/man to manpath
path directory /usr/bin is in the config file
  adding /usr/share/man to manpath
path directory /bin is in the config file
path directory /usr/local/games is not in the config file
path directory /usr/games is in the config file
adding mandatory man directories
Warnung: /usr/man: Datei oder Verzeichnis nicht gefunden
add_nls_manpaths(): processing 
/usr/local/man:/usr/local/share/man:/usr/share/man
checking for locale de_DE.UTF-8
adding /usr/share/man/de to manpathlist
adding /usr/local/man to manpathlist
adding /usr/share/man to manpathlist
final search path = /usr/share/man/de:/usr/local/man:/usr/share/man
--priv_drop_count = 0
searching in /usr/share/man/de, section 1
trying section 1 with globbing
Layout is GNU (1)
update_directory_cache /usr/share/man/de: miss
globbing pattern in /usr/share/man/de: man1*
matched: /usr/share/man/de/man1
update_directory_cache /usr/share/man/de/man1: miss
globbing pattern in /usr/share/man/de/man1: systemd-importd.1*
update_directory_cache /usr/share/man/de: hit
globbing pattern in /usr/share/man/de: cat1*
Succeeded in opening /var/cache/man/de/index.db O_RDONLY
searching in /usr/local/man, section 1
trying section 1 with globbing
update_directory_cache /usr/local/man: miss
globbing pattern in /usr/local/man: man1*
update_directory_cache /usr/local/man: hit
globbing pattern in /usr/local/man: cat1*
Failed to open /var/cache/man/oldlocal/index.db O_RDONLY
searching in /usr/share/man, section 1
trying section 1 with globbing
update_directory_cache /usr/share/man: miss
globbing pattern in /usr/share/man: man1*
matched: /usr/share/man/man1
update_directory_cache /usr/share/man/man1: miss
globbing pattern in /usr/share/man/man1: systemd-importd.1*
update_directory_cache /usr/share/man: hit
globbing pattern in /usr/share/man: cat1*
Succeeded in opening /var/cache/man/index.db O_RDONLY
searching in /usr/share/man/de, section n
trying section n with globbing
update_directory_cache /usr/share/man/de: hit
globbing pattern in /usr/share/man/de: mann*
update_directory_cache /usr/share/man/de: hit
globbing pattern in /usr/share/man/de: catn*
searching in /usr/local/man, section n
trying section n with globbing
update_directory_cache /usr/local/man: hit
globbing pattern in /usr/local/man: mann*
update_directory_cache /usr/local/man: hit
globbing pattern in /usr/local/man: catn*
searching in /usr/share/man, section n
trying section n with globbing
update_directory_cache /usr/share/man: hit
globbing pattern in /usr/share/man: mann*
update_directory_cache /usr/share/man: hit
globbing pattern in /usr/share/man: catn*
searching in /usr/share/man/de, section l
trying section 

Bug#1020706: ITP: golang-github-gonvenience-text -- convenience functions for strings

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬) 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: golang-github-gonvenience-text
  Version : 1.0.7
  Upstream Author : Matthias Diester
* URL : 
https://salsa.debian.org/go-team/packages/golang-github-gonvenience-text
* License : Expat
  Programming Lang: Golang
  Description : convenience functions for strings

 This package will be maintained under Debian Go Packaging Team.
 This is dependencies of dyff (https://bugs.debian.org/1013751).

-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#1020705: glibc: Keep DT_HASH

[Jeremy Bicha]

Source: glibc
Version: 2.36-1
Tags: patch

Please consider restoring DT_HASH in your glibc 2.36 packaging. Here's
an article with more details:

https://lwn.net/Articles/904892/

Below is the patch that Ubuntu 22.10 is applying. Or you could use the
Arch Linux patch
https://github.com/archlinux/svntogit-packages/blob/packages/glibc/trunk/reenable_DT_HASH.patch


diff -pruN 2.36-1/debian/patches/restore-libc-DT_HASH.patch
2.36-0ubuntu2/debian/patches/restore-libc-DT_HASH.patch
--- 2.36-1/debian/patches/restore-libc-DT_HASH.patch 1970-01-01
00:00:00.0 +
+++ 2.36-0ubuntu2/debian/patches/restore-libc-DT_HASH.patch 2022-08-22
01:24:09.0 +
@@ -0,0 +1,32 @@
+Description: restore DT_HASH tag for libc.so.6
+ Should consider upstreaming a configure flag for this, perhaps.
+Author: Michael Hudson-Doyle
+Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29456
+Last-Update: 2022-08-22
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/Makerules
 b/Makerules
+@@ -558,6 +558,9 @@
+  -Wl,--verbose 2>/dev/null | \
+  sed > $@T \
+  -e '/^=/,/^=/!d;/^=/d' \
++  -e 's/^.*\.gnu\.hash[]*:.*$$/  .note.ABI-tag :
{ *(.note.ABI-tag) } &/' \
++  -e '/^[  ]*\.hash[   ]*:.*$$/{h;d;}' \
++  -e '/DATA_SEGMENT_ALIGN/{H;g}' \
+  -e 's/^.*\*(\.dynbss).*$$/& \
+ PROVIDE(__start___libc_freeres_ptrs = .); \
+ *(__libc_freeres_ptrs) \
+--- a/Makeconfig
 b/Makeconfig
+@@ -367,6 +367,10 @@
+ LDFLAGS.so += $(relro-LDFLAGS)
+ LDFLAGS-rtld += $(relro-LDFLAGS)
+
++hashstyle-LDFLAGS = -Wl,--hash-style=both
++LDFLAGS.so += $(hashstyle-LDFLAGS)
++LDFLAGS-rtld += $(hashstyle-LDFLAGS)
++
+ # Linker options to enable and disable DT_RELR.
+ ifeq ($(have-dt-relr),yes)
+ dt-relr-ldflag = -Wl,-z,pack-relative-relocs


Thank you,
Jeremy Bicha

Bug#1020704: man-db: Alias for translated man pages do not work if english one is present

[Helge Kreutzmann]

Package: man-db
Version: 2.10.2-3
Severity: important
Tags: l10n
X-Debbugs-Cc: Mario Blättermann , "Dr. Tobias 
Quathamer" 

Hello Colin,
I'm the Debian maintainer of manpages-l10n, I put my co-maintainer and
manpages-l10n upstream in CC.

I observed the following unexpected behaviour:

Some man pages can be called under various names. Take, for example,
nss-mymachines and libnss_mymachines.so.2. In the file system, there
is only nss-mymachines.8.gz, but if I install manpages-de (this is
assumed for the rest of this bug report) I can issue
man nss-mymachines
and
man libnss_mymachines.so.2.
to read the German man page.

I do not have the English version installed currently, thus, as
expected,
LC_ALL=C man nss-mymachines
does not find anything.

This is the part that works (as expected).

Now let's take a different example, namely systemd-importd.service
and systemd-importd.

Again manpages-de ships only one file, i.e.
/usr/share/man/de/man8/systemd-importd.service.8.gz

With 
man systemd-importd.service
I'm able to read the German version, however, with
man systemd-importd
I get the english version (which exists on my system, different from
the previous example).

If I manually enter (as root)
ln -s /usr/share/man/de/man8/systemd-importd.service.8.gz 
/usr/share/man/de/man8/systemd-importd.8.gz
then it works as intended, i.e. I get the German page in both cases.

For information:
helge@twentytwo:/usr/share/man/de/man8$ lexgrog nss-myhostname.8.gz
nss-myhostname.8.gz: "nss-myhostname - Rechnernamenauflösung für die lokal 
konfigurierten Systemrechnernamen"
nss-myhostname.8.gz: "libnss_myhostname.so.2 - Rechnernamenauflösung für die 
lokal konfigurierten Systemrechnernamen"

helge@twentytwo:/usr/share/man/de/man8$ lexgrog systemd-importd.service.8.gz
systemd-importd.service.8.gz: "systemd-importd.service - VM- und 
Container-Abbild-Import und -Exportdienst"
systemd-importd.service.8.gz: "systemd-importd - VM- und 
Container-Abbild-Import und -Exportdienst"

Thus for the English → English man page the alias system works, but it
does not work for German → German, if the English exists. If it does
not exist, then it works.

I tried to understand where these links are processed, but
unfortunately I did not manage to do so.

I really would like to avoid adding tons of links in manpages-l10n for
each man page with aliases and each translation (we do ship quite a
few man pages and translations). 

I chose the severity, as this bug prevents all users with localized
man pages to read them if they happen to call the "wrong" alias. Thus
impacting quite a bit manpages-l10n.

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

Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages man-db depends on:
ii  bsdextrautils  2.38.1-1
ii  bsdmainutils   12.1.7+nmu3
ii  debconf [debconf-2.0]  1.5.79
ii  groff-base 1.22.4-8
ii  libc6  2.34-8
ii  libgdbm6   1.23-2
ii  libpipeline1   1.5.6-3
ii  libseccomp22.5.4-1+b1
ii  zlib1g 1:1.2.11.dfsg-4.1

man-db recommends no packages.

Versions of packages man-db suggests:
ii  apparmor 3.0.7-1
ii  chromium [www-browser]   105.0.5195.125-1
ii  firefox-esr [www-browser]102.2.0esr-1
ii  groff1.22.4-8
ii  konqueror [www-browser]  4:21.12.3-1
ii  less 590-1
ii  links [www-browser]  2.27-1+b1
ii  lynx [www-browser]   2.9.0dev.10-1+b1
ii  sugar-browse-activity [www-browser]  207-1
ii  w3m [www-browser]0.5.3+git20220429-1+b1

-- debconf information:
  man-db/install-setuid: false
  man-db/auto-update: true

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1020703: unifont-bin: Mark unifont-bin Multi-Arch: foreign?

[Samuel Thibault]

Package: unifont-bin
Version: 1:15.0.01-1
Severity: normal

Hello,

AIUI, the unifont-bin package behaves the same on any architecture since
it only acts on font files in an architecture-independent way?  If so,
could you mark it Multi-Arch: foreign, so that packages depending on it
(e.g. bterm-unifont) can be cross-compiled?

Thanks,
Samuel

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

Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 unifont-bin depends on:
ii  bdf2psf   1.210
ii  fontforge 1:20220308~dfsg-1
ii  libc6 2.34-8
ii  libgd-perl2.76-4
ii  libwx-perl1:0.9932-7
ii  perl  5.34.0-5
ii  xfonts-utils  1:7.7+6

unifont-bin recommends no packages.

Versions of packages unifont-bin suggests:
ii  texinfo  6.8-6
ii  texlive  2022.20220722-1
ii  unifont  1:15.0.01-1

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Bug#1017063: fixed in gjs 1.73.1-2

[Jeremy Bicha]

On Sun, Sep 4, 2022 at 11:42 AM Paul Gevers  wrote:
> On Sat, 13 Aug 2022 01:48:54 + Debian FTP Masters
>  wrote:
> >  gjs (1.73.1-2) unstable; urgency=medium
> >  .
> >* Rebuild against latest mozjs91 (Closes: #1017063)
>
> You forgot to enforce this with a *versioned* build dependency and now
> armhf got build with the old version.
>
> But anyways. This smells a bit like an ABI breakage. Did something go
> wrong with mozjs91? And maybe we want to prevent issues during partial
> upgrades, then mozjs91 should break the old version of gjs.
>
> Normally no-change rebuilds are handled as binNMU's by the Release Team,
> is there any particular reason why you didn't do that?

Sorry, I didn't see your message until now.

I believe mozjs91 started failing to build on arm with gcc-12. Perhaps
that was related to this breakage or maybe Mozilla changed things a
bit more than usual in the 91.12 ESR release.

By not bumping the Build-Depends, gjs was able to build everywhere.
But then it couldn't migrate because on most architectures it got a
Depends on the new mozjs so that didn't really help.

Anyway, this is all fixed in Unstable as gjs now depends on mozjs102
and mozjs102 now builds on all release architectures.

I'll try to remember that a binnmu would have been better in this kind
of situation.

Thank you,
Jeremy Bicha

Bug#1020435: ruby-prof: FTBFS on ppc64el

[Antonio Terceiro]

Control: tag -1 + unreproducible
Control: severity -1 important

Hi,

On Wed, Sep 21, 2022 at 07:20:31PM +0200, Sebastian Ramacher wrote:
> Source: ruby-prof
> Version: 1.4.3-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org
> 
> https://buildd.debian.org/status/fetch.php?pkg=ruby-prof=ppc64el=1.4.3-1%2Bb1=1663720013=0
> 
>   1) Failure:
> PrinterGraphTest#test_graph_results_sorting 
> [/<>/test/printer_graph_test.rb:37]:
> Array [0.171, 0.171, 0.167, 0.167, 0.166, 0.164, 0.004, 0.004, 0.002, 0.0, 
> 0.0, 0.0, 0.0, 0.17, 0.17, 0.0, 0.0, 0.169, 0.169, 0.0, 0.0] is not sorted.
> --- expected
> +++ actual
> @@ -1 +1 @@
> -[0.171, 0.171, 0.167, 0.167, 0.166, 0.164, 0.004, 0.004, 0.002, 0.0, 0.0, 
> 0.0, 0.0, 0.17, 0.17, 0.0, 0.0, 0.169, 0.169, 0.0, 0.0]
> +[0.171, 0.171, 0.17, 0.17, 0.169, 0.169, 0.167, 0.167, 0.166, 0.164, 0.004, 
> 0.004, 0.002, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
> 
> 
> 51 runs, 687 assertions, 1 failures, 0 errors, 0 skips
> rake aborted!
> Command failed with status (1): [ruby -w -I"test" 
> /usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb
>  "test/abstract_printer_test.rb" "test/alias_test.rb" "test/basic_test.rb" 
> "test/call_tree_visitor_test.rb" "test/call_trees_test.rb" 
> "test/duplicate_names_test.rb" "test/enumerable_test.rb" 
> "test/exceptions_test.rb" "test/exclude_methods_test.rb" 
> "test/exclude_threads_test.rb" "test/fiber_test.rb" "test/gc_test.rb" 
> "test/line_number_test.rb" "test/marshal_test.rb" 
> "test/multi_printer_test.rb" "test/no_method_class_test.rb" 
> "test/printer_call_stack_test.rb" "test/printer_call_tree_test.rb" 
> "test/printer_flat_test.rb" "test/printer_graph_html_test.rb" 
> "test/printer_graph_test.rb" "test/printing_recursive_graph_test.rb" 
> "test/profile_test.rb" "test/rack_test.rb" "test/singleton_test.rb" -v]
> /usr/share/rubygems-integration/all/gems/rake-13.0.6/exe/rake:27:in ` (required)>'
> Tasks: TOP => default
> (See full trace by running task with --trace)
> ERROR: Test "ruby3.0" failed. Exiting.

Unfortunately I could not reproduce this on the ppc64el porterbox, even
trying the same random seed as the original build failure. I was
suspecting an random test failure, but I didn't see this after trying 50
builds in a row. In fact, just giving back the build on the buildd made
it succeed. I'm not saying there is no issue, so I am keeping this open
and maybe we will be able to figure it out at some point.

I hope you don't mind me downgrading this to important.


signature.asc
Description: PGP signature

Bug#1008348: Forwarding bitrotted Apertium pairs

[Tino Didriksen]

forwarded 1008348 https://github.com/apertium/organisation/issues/23
forwarded 1016319 https://github.com/apertium/organisation/issues/23
forwarded 1016320 https://github.com/apertium/organisation/issues/23
forwarded 1016336 https://github.com/apertium/organisation/issues/23
forwarded 1013638 https://github.com/apertium/organisation/issues/32
forwarded 1013648 https://github.com/apertium/organisation/issues/32
forwarded 1013646 https://github.com/apertium/organisation/issues/32
thanks

-- Tino Didriksen



OpenPGP_signature
Description: OpenPGP digital signature