Bug#954318: libreoffice-impress-nogui: depend on libreoffice-draw-nogui (in addition/instead of libreoffice-draw)

[Jochen Sprickerhof]

Package: libreoffice-impress-nogui
Version: 1:6.4.2-1
Severity: normal

As subject says and discussed in #debian-devel.

Thanks!

Jochen

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 5.4.0-3-armmp (SMP w/8 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreoffice-impress-nogui depends on:
ii  libc62.30-2
ii  libetonyek-0.1-1 0.1.9-3
ii  libgcc-s110-20200312-2
ii  libmwaw-0.3-30.3.15-2
ii  libodfgen-0.1-1  0.1.7-1
ii  libreoffice-core-nogui   1:6.4.2-1
ii  libreoffice-draw 1:6.4.2-1
ii  librevenge-0.0-0 0.0.4-6+b1
ii  libstaroffice-0.0-0  0.0.6-1
ii  libstdc++6   10-20200312-2
ii  libuno-cppu3 1:6.4.2-1
ii  libuno-cppuhelpergcc3-3  1:6.4.2-1
ii  libuno-sal3  1:6.4.2-1
ii  libuno-salhelpergcc3-3   1:6.4.2-1
ii  uno-libs-private 1:6.4.2-1
ii  ure  1:6.4.2-1

libreoffice-impress-nogui recommends no packages.

Versions of packages libreoffice-impress-nogui suggests:
pn  bluez  

Versions of packages libreoffice-draw depends on:
ii  libavahi-client3 0.7-5
ii  libavahi-common3 0.7-5
ii  libc62.30-2
ii  libcdr-0.1-1 0.1.6-1
ii  libdbus-1-3  1.12.16-2
ii  libfreehand-0.1-10.1.2-2
ii  libgcc-s110-20200312-2
ii  libglib2.0-0 2.64.1-1
ii  libmspub-0.1-1   0.1.4-1+b2
ii  libmwaw-0.3-30.3.15-2
ii  libodfgen-0.1-1  0.1.7-1
ii  libpagemaker-0.0-0   0.0.4-1
ii  libqxp-0.0-0 0.0.2-1
ii  libreoffice-core-nogui   1:6.4.2-1
ii  librevenge-0.0-0 0.0.4-6+b1
ii  libstaroffice-0.0-0  0.0.6-1
ii  libstdc++6   10-20200312-2
ii  libuno-cppu3 1:6.4.2-1
ii  libuno-cppuhelpergcc3-3  1:6.4.2-1
ii  libuno-sal3  1:6.4.2-1
ii  libuno-salhelpergcc3-3   1:6.4.2-1
ii  libvisio-0.1-1   0.1.7-1
ii  libwpg-0.3-3 0.3.3-1
ii  libxml2  2.9.10+dfsg-4
ii  libzmf-0.0-0 0.0.2-1+b2
ii  uno-libs-private 1:6.4.2-1
ii  ure  1:6.4.2-1
ii  zlib1g   1:1.2.11.dfsg-2

-- debconf-show failed

Bug#954317: RM: orthanc [s390x] -- RoM; ANAIS

[Sébastien Jodogne]

Package: ftp.debian.org
Severity: normal

One unit test fails on s390x architecture:
https://buildd.debian.org/status/fetch.php?pkg=orthanc&arch=s390x&ver=1.6.0%2Bdfsg-1&stamp=1584552281&raw=0

[ RUN  ] ParsedDicomFile.ToJsonFlags2
/<>/UnitTestsSources/FromDcmtkTests.cpp:732: Failure
Expected equality of these values:
  "Pixels"
  v["7fe0,0010"].asString()
Which is: "iPexsl"
[  FAILED  ] ParsedDicomFile.ToJsonFlags2 (0 ms)

The "iPexsl" value indicates a problem related to endianness in
Orthanc. As the upstream package has not access to a Big-endian
computer, we cannot reproduce this issue.

Bug#944352: scummvm: screen gets black and/or flickering in full screen mode using X11 sessions

[Thorsten Ehlers]

Dear maintainer,

mesa 20.0.2-1 update released today fixed the problem for me so this bug
report can be closed.

Thanks to all Debian maintainers! :)

Thorsten

Bug#561919: 親愛的，我需要你的幫助。

[Rebekah Issah]

你好，

可以用英語交流嗎？我使用Google翻譯器將英語翻譯成您的語言，以便您更好地理解。

我是也門婦女麗貝卡·伊薩（Rebekah
Issah）夫人。我希望由於也門長時間的內亂/戰爭以及基地組織武裝分子的日常生活威脅而遷移到貴國。在2018年3月23日針對我們的家庭的襲擊中，我已經失去了家人，丈夫，兒子和女兒的死亡之手，以結束我們的家庭。在十字路口時，我不在附近。當襲擊襲擊了我們的房屋，殺死了我心愛的丈夫，兒子和女兒並燒毀房屋時，我正在醫院接受檢查。這封信給我流淚。他（我的已故丈夫）是在也門石油城非常成功的承包商，在他過早去世之前，他曾私下經營金粉和金條。可以預料的是，他留下了一些合理的錢，我希望將這些錢投資到您所在國家的房地產，旅遊業，酒店管理和其他有趣的領域。

您可能知道，也可能不知道，美國和歐盟實施的製裁幾乎不可能在也門成功進行任何類型的投資，甚至將資金從這裡轉移到世界其他地方。因此，我非常有信心地與您聯繫，希望您能幫助我將這筆錢用於您的國家進行投資：

請我想知道以這種方式為我提供幫助的方便程度。我可動用的全部資本為九百萬美元。我把錢偷偷地鎖在行李箱裡，然後把錢存放在薩那的紅十字會上。我寫給您的真誠意圖是懇請您接受存錢罐。這是因為戰後我們無法從這裡進行任何銀行轉帳。這些是我現在關注的主要問題。我會給您總金額的20％，作為您幫助我的好處。

我必須抓住這次機會，因為除了信任別人，我別無選擇。為了避免家庭血統的終結，我無法冒著生命危險。自從我丈夫，兒子和女兒去世以來，作為一個女人。我應該在和平的環境中過上體面的生活，我將搬遷到您的國家，並根據法律，您的建議和支持投資這筆錢；我們可以共同努力並實現。

我們期待您的積極回應，並在收到您的信息後為您提供更多詳細信息。

您忠誠的，

麗貝卡一世

Bug#954316: /usr/bin/ncal: ncal -y does not fit in 80x25

[Ben Wong]

Package: bsdmainutils
Version: 11.1.2+b1
Severity: normal
File: /usr/bin/ncal

Dear Maintainer,

According to the man page for ncal, its strangely compact output was
designed specifically so it will fit an entire year on an 80 column by
25 row screen. At some point somebody made an "improvement" to ncal
which added two extra blank lines between the months. This defeats
ncal's raison d'être.

Please remove the extra blank lines. (Lines 10 and 19 in the listing below.)

What I would expect:

$ ncal -y | wc -l
25

What currently is output:

$ ncal -y | wc -l
27
$ ncal -y | cat -n
 12020
 2  January   February  March April 

 3  Su 5 12 19 262  9 16 23 1  8 15 22 295 12 19 26 
  
 4  Mo 6 13 20 273 10 17 24 2  9 16 23 306 13 20 27 
  
 5  Tu 7 14 21 284 11 18 25 3 10 17 24 317 14 21 28 
  
 6  We  1  8 15 22 295 12 19 26 4 11 18 251  8 15 22 29 
  
 7  Th  2  9 16 23 306 13 20 27 5 12 19 262  9 16 23 30 
  
 8  Fr  3 10 17 24 317 14 21 28 6 13 20 273 10 17 24
  
 9  Sa  4 11 18 251  8 15 22 29 7 14 21 284 11 18 25
  
10  
11  May   June  July  August

12  Su 3 10 17 24 31 7 14 21 285 12 19 262  9 16 23 
30
13  Mo 4 11 18 25 1  8 15 22 296 13 20 273 10 17 24 
31
14  Tu 5 12 19 26 2  9 16 23 307 14 21 284 11 18 25 
  
15  We 6 13 20 27 3 10 17 241  8 15 22 295 12 19 26 
  
16  Th 7 14 21 28 4 11 18 252  9 16 23 306 13 20 27 
  
17  Fr  1  8 15 22 29 5 12 19 263 10 17 24 317 14 21 28 
  
18  Sa  2  9 16 23 30 6 13 20 274 11 18 251  8 15 22 29 
  
19  
20  September October   November  December  

21  Su 6 13 20 274 11 18 25 1  8 15 22 296 13 20 27 
  
22  Mo 7 14 21 285 12 19 26 2  9 16 23 307 14 21 28 
  
23  Tu  1  8 15 22 296 13 20 27 3 10 17 241  8 15 22 29 
  
24  We  2  9 16 23 307 14 21 28 4 11 18 252  9 16 23 30 
  
25  Th  3 10 17 241  8 15 22 29 5 12 19 263 10 17 24 31 
  
26  Fr  4 11 18 252  9 16 23 30 6 13 20 274 11 18 25
  
27  Sa  5 12 19 263 10 17 24 31 7 14 21 285 12 19 26
  

Thanks!



-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages bsdmainutils depends on:
ii  bsdutils 1:2.33.1-0.1
ii  debianutils  4.8.6.1
ii  libbsd0  0.9.1-2
ii  libc62.28-10
ii  libtinfo66.1+20181013-2+deb10u2

bsdmainutils recommends no packages.

Versions of packages bsdmainutils suggests:
ii  cpp 4:8.3.0-1
pn  vacation
ii  wamerican [wordlist]2018.04.16-1
ii  wbrazilian [wordlist]   3.0~beta4-22
ii  wbulgarian [wordlist]   4.1-7
ii  wcatalan [wordlist] 0.20111230b-12
ii  wdanish [wordlist]  1.6.36-11
ii  wdutch [wordlist]   1:2.10-6
ii  wfrench [wordlist]  1.2.4-1
ii  whois   5.4.3
ii  witalian [wordlist] 1.10
ii  wngerman [wordlist] 20161207-7
ii  wnorwegian [wordlist]   2.2-4
ii  wpolish [wordlist]  20180621-1
ii  wportuguese [wordlist]  20171225-3
ii  wspanish [wordlist] 1.0.28
ii  wswedish [wordlist] 1.4.5-2.2

-- no debconf information

Bug#932617: any update on this as I still got it today with the update (again)

[shirish शिरीष]

Replying in-line  :-

On 19/03/2020, mario.limoncie...@dell.com  wrote:
> 1.3.9.2?  You mean 1.3.9-2?
>
> They were supposed to be removed about 5 months ago.  The preinst, postrm,
> and postinst has the stuff for doing these:
> https://salsa.debian.org/efi-team/fwupd/-/blob/debian/debian/fwupd.preinst
> https://salsa.debian.org/efi-team/fwupd/-/blob/debian/debian/fwupd.postrm
> https://salsa.debian.org/efi-team/fwupd/-/blob/debian/debian/fwupd.postinst
>

Yup, I meant 1.3.9-2 . Interestingly, I got the following when trying
to purge fwupd -

$ sudo aptitude purge fwupd fwupd-amd64-signed libflashrom1 libftdi1-2
libfwupdplugin1 -y
The following packages will be REMOVED:
  fwupd{p} fwupd-amd64-signed{pu} libflashrom1{pu} libftdi1-2{pu}
libfwupdplugin1{pu}
0 packages upgraded, 0 newly installed, 5 to remove and 9 not upgraded.
Need to get 0 B of archives. After unpacking 6,853 kB will be freed.
(Reading database ... 795030 files and directories currently installed.)
Removing fwupd-amd64-signed (1.3.9+2) ...
Removing fwupd (1.3.9-2) ...
Removing libflashrom1:amd64 (1.2-5) ...
Removing libftdi1-2:amd64 (1.4-2+b1) ...
Removing libfwupdplugin1:amd64 (1.3.9-2) ...
Processing triggers for libc-bin (2.30-2) ...
Processing triggers for man-db (2.9.1-1) ...
Processing triggers for dbus (1.12.16-2) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
(Reading database ... 794637 files and directories currently installed.)
Purging configuration files for fwupd-amd64-signed (1.3.9+2) ...
Purging configuration files for fwupd (1.3.9-2) ...
dpkg: warning: while removing fwupd, directory '/var/lib/fwupd' not
empty so not removed
dpkg: warning: while removing fwupd, directory '/var/cache/app-info'
not empty so not removed
Processing triggers for dbus (1.12.16-2) ...
==  How can you help?  (doc: https://wiki.debian.org/how-can-i-help ) ==

-  Show old opportunities as well as new ones: how-can-i-help --old  -

/var/lib/fwupd$ ls -lh
total 24K
-rw-r--r-- 1 root root  16K Oct 14 19:23 pending.db
drwxr-xr-x 2 root root 4.0K Oct 14 19:23 pki
drwxr-xr-x 3 root root 4.0K Oct 14 19:23 remotes.d

While I manually removed /var/lib/fwupd/ entries and sub-directories I
am/was unsure about the contents of /var/cache/app-info/cache/ so left
them as they are.

/var/cache/app-info/cache$ ls -lh
total 28M
-rwxr-xr-x 1 root root 13M Dec 21 06:23 C.cache
-rwxr-xr-x 1 root root 15M Mar 19 21:07 en_IN.cache

This time when installing fwupd adequate didn't tell anything which
means there is still an issue when you try to upgrade from the old
version to the new but NO issue when you install it afresh.



>
>

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#954315: rastertopwg segfault

[Hideki Yamane]

Package: cups
Version: 2.3.1-11
Severity: important

Dear Maintainer,

 I cannot print some pdf files with cups, it gets an error with rastertopwg
 segfault.

 3月 20 11:53:04 tiny kernel: rastertopwg[31898]: segfault at 0 ip 
7f7a61751671 sp 7ffe7eb46428 error 4 in 
libc-2.30.so[7f7a61618000+14a000]
 3月 20 11:53:04 tiny kernel: Code: 84 00 00 00 00 00 0f 1f 00 31 c0 c5 f8 77 c3 
66 2e 0f 1f 84 00 00 00 00 00 89 f9 48 89 fa c5 f9 ef c0 83 e1 3f 83 f9 20 77 
1f  fd 74 0f c5 fd d7 c1 85 c0 0f 85 df 00 00 00 48 83 c7 20 83 e1
 3月 20 11:53:04 tiny systemd[1]: Started Process Core Dump (PID 31916/UID 0).
 3月 20 11:53:05 tiny systemd-coredump[31917]: Process 31898 (rastertopwg) of 
user 0 dumped core.

Stack trace of thread 31898:
#0  0x7f7a61751671 
__strlen_avx2 (libc.so.6 + 0x15e671)
#1  0x7f7a618032f9 
_cups_strlcpy (libcups.so.2 + 0x4d2f9)
#2  0x55a058ca1a36 main 
(rastertopwg + 0x1a36)
#3  0x7f7a61619e0b 
__libc_start_main (libc.so.6 + 0x26e0b)
#4  0x55a058ca21aa _start 
(rastertopwg + 0x21aa)


henrich@tiny:~ $ LANG=C gdb /usr/lib/cups/filter/rastertopwg dump
GNU gdb (Debian 9.1-2) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/cups/filter/rastertopwg...
Reading symbols from 
/usr/lib/debug/.build-id/f6/625381c79c26618988e474ae2e419e5b4222bc.debug...
[New LWP 40096]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by 
`ipp://Photosmart%205520%20series%20%5BEB8411%5D._ipp._tcp.local/ 32 henrich 
202'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
65  ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
(gdb)




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

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

Versions of packages cups depends on:
ii  cups-client2.3.1-11
ii  cups-common2.3.1-11
ii  cups-core-drivers  2.3.1-11
ii  cups-daemon2.3.1-11
ii  cups-filters   1.27.2-1
ii  cups-ppdc  2.3.1-11
ii  cups-server-common 2.3.1-11
ii  debconf [debconf-2.0]  1.5.73
ii  ghostscript9.52~dfsg-1
ii  libavahi-client3   0.7-5
ii  libavahi-common3   0.7-5
ii  libc6  2.30-2
ii  libcups2   2.3.1-11
ii  libgcc-s1  10-20200312-2
ii  libstdc++6 10-20200312-2
ii  libusb-1.0-0   2:1.0.23-2
ii  poppler-utils  0.71.0-6
ii  procps 2:3.3.16-4

Versions of packages cups recommends:
ii  avahi-daemon  0.7-5
ii  colord1.4.4-1

Versions of packages cups suggests:
ii  cups-bsd   2.3.1-11
pn  cups-pdf   
ii  foomatic-db-compressed-ppds [foomatic-db]  20200219-1
pn  smbclient  
ii  udev   245.2-1

-- debconf information:
  cupsys/backend: lpd, socket, usb, snmp, dnssd
  cupsys/raw-print: true

Bug#851747: sysvinit_2.96-2.2_source.changes ACCEPTED into unstable

[Adam Borowski]

On Fri, Mar 20, 2020 at 02:12:59AM +0100, Andreas Henriksson wrote:
> On Fri, Mar 20, 2020 at 01:33:49AM +0100, Adam Borowski wrote:
> > On Fri, Mar 20, 2020 at 01:24:31AM +0100, Andreas Henriksson wrote:
> > > I expect you to take care of this bug and others if you're now going to
> > > pretent to maintain this package!
> > 
> > You demand a change that requires a lot of work all around the archive,
> 
> I've already proven this is a bullshit excuse. Read the actual bug
> report content.

I'm refusing to discuss that part until you calm down and stop throwing
content-less insults.

> > without providing any reason _why_.
> 
> Section 3.8 can be read here:
> https://www.debian.org/doc/debian-policy/ch-binary.html#essential-packages

The "Essential" tag has three purposes:
1. must work while unpacked but unconfigured
2. doesn't require an explicit dependency
3. works in postrm purge

What's wanted here is:
> See also third paragraph of 3.5.

# Packages are not required to declare any dependencies they have on other
# packages which are marked Essential (see below), and should not do so
# unless they depend on a particular version of that package.

Without that, we'd need to add explicit dependencies everywhere.  No one
wants multi-page init or .service scripts when a short init-d-script will
suffice.  Making that harder would be a disservice.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#851747: sysvinit_2.96-2.2_source.changes ACCEPTED into unstable

[Thorsten Glaser]

On Fri, 20 Mar 2020, Axel Beckert wrote:

> No, it wasn't. The only mention of "NMU" (or "non-maintainer") I found
> in https://bugs.debian.org/851747 was about 3 hours ago in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851747#146
> 
> That's definitely far to short for a wishlist-level bug.

Additionally, you have to upload NMUs to a DELAYED queue,
unless pre-approved by a maintainer. I think that’s also
somewhere in DevRef, considering you (Andreas) start to
throw around links to policy documents…

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#851747: sysvinit_2.96-2.2_source.changes ACCEPTED into unstable

[Thorsten Glaser]

On Fri, 20 Mar 2020, Andreas Henriksson wrote:

> Section 3.8 can be read here:

Removing the Essential flag should be done with the greatest care,
though, and only after all users are moved off of implying its
presence. 3.8 also contains this:

“which means that removing functionality from the Essential set
   is very difficult and is almost never done.”

As I said, just don’t rush this. From your recent mails to the
bugreport you said there are packages to adapt first. And as I
said, bash still is Essential… so don’t rush.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#851747: sysvinit_2.96-2.2_source.changes ACCEPTED into unstable

[Andreas Henriksson]

On Fri, Mar 20, 2020 at 01:33:49AM +0100, Adam Borowski wrote:
> On Fri, Mar 20, 2020 at 01:24:31AM +0100, Andreas Henriksson wrote:
> > I expect you to take care of this bug and others if you're now going to
> > pretent to maintain this package!
> 
> You demand a change that requires a lot of work all around the archive,

I've already proven this is a bullshit excuse. Read the actual bug
report content.

> without providing any reason _why_.

Section 3.8 can be read here:
https://www.debian.org/doc/debian-policy/ch-binary.html#essential-packages

See also third paragraph of 3.5.

Regards,
Andreas Henriksson

Bug#954232: [deluge] wrong status labels

[jnqnfe]

To be more clear, the download speed and amount uploaded are swapped

On Thu, 19 Mar 2020 03:06:48 + jnq...@gmail.com wrote:
> Package: deluge
> Version: 2.0.3-2
> 
> labels in the status panel are mismatched with the values given
> 
> e.g.
> Download Speed: 1.0G (614.3 M)
> Up Speed: 7.3 K/s
> Downloaded: 6.7 G (1.1 G)
> Uploaded: 8.4 K/s

Bug#954312: systemd: FTBFS on riscv64: test-seccomp fails: Assertion 'name' failed at src/test/test-seccomp.c:49

[Michael Biebl]

Am 20.03.20 um 01:32 schrieb Michael Biebl:
> Have you tested, that seccomp is working on riscv64 with 5.5?
> Something like this should lead to a blocked ping:

Here is a better test:

# cat test.service

[Unit]
Description=test seccomp filter

[Service]
ExecStart=ping -c 1 www.debian.org
SystemCallFilter=~socket



# systemctl status test
● test.service - test seccomp filter
 Loaded: loaded (/etc/systemd/system/test.service; static; vendor
preset: enabled)
 Active: failed (Result: signal) since Fri 2020-03-20 01:33:52 CET;
3s ago
Process: 351106 ExecStart=/bin/ping -c 1 www.debian.org
(code=killed, signal=SYS)
   Main PID: 351106 (code=killed, signal=SYS)

Mär 20 01:33:52 pluto systemd[1]: Started test seccomp filter.
Mär 20 01:33:52 pluto systemd[1]: test.service: Main process exited,
code=killed, status=31/SYS
Mär 20 01:33:52 pluto systemd[1]: test.service: Failed with result 'signal'.





signature.asc
Description: OpenPGP digital signature

Bug#851747: sysvinit_2.96-2.2_source.changes ACCEPTED into unstable

[Axel Beckert]

Dear Andreas,

Andreas Henriksson wrote:
> On Thu, Mar 19, 2020 at 11:58:37PM +0100, Adam Borowski wrote:
> > On Thu, Mar 19, 2020 at 10:24:53PM +, Debian FTP Masters wrote:
> > > Accepted:
> > 
> > >  sysvinit (2.96-2.2) unstable; urgency=medium
> > >  .
> > >* Non-maintainer upload.
> > >* Drop 'Essential: yes' from sysvinit-utils (Closes: #851747)
> > 
> > WTF.
[...]
> The NMU was annouces weeks in advance

No, it wasn't. The only mention of "NMU" (or "non-maintainer") I found
in https://bugs.debian.org/851747 was about 3 hours ago in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851747#146

That's definitely far to short for a wishlist-level bug.

So thanks to Adam for reverting this brazenness.

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

Bug#851747: sysvinit_2.96-2.2_source.changes ACCEPTED into unstable

[Adam Borowski]

On Fri, Mar 20, 2020 at 01:24:31AM +0100, Andreas Henriksson wrote:
> I expect you to take care of this bug and others if you're now going to
> pretent to maintain this package!

You demand a change that requires a lot of work all around the archive,
without providing any reason _why_.

> The NMU was annouces weeks in advance so there's nothing 'fortunate' about
> mid air collisions and force-pushing to the public git repo.

Intent announced: Thu, 19 Mar 2020 22:47:45 +0100
NMU _accepted_:   Thu, 19 Mar 2020 22:24:54 +
-- that's exactly 37m09s.  And the delay between upload being done and
processed by DAK is on that order, suggesting you did that immediately
after sending the mail.

In the meantime, I've made the -3 upload (based on my analysis of the bug
you've filed), and only after hitting "dput" I tried to push to git as well
to see your NMU.  And then, I indeed force-pushed to let the repo match
the archive (and your upload is not completely lost as there's the tag).


Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#954312: systemd: FTBFS on riscv64: test-seccomp fails: Assertion 'name' failed at src/test/test-seccomp.c:49

[Michael Biebl]

Am 20.03.20 um 00:23 schrieb Aurelien Jarno:
> It happens that upstream systemd doesn't support yet riscv64. I came
> with a very simple patch to fix that issue:
> 
> --- systemd-245.2.orig/src/test/test-seccomp.c
> +++ systemd-245.2/src/test/test-seccomp.c
> @@ -72,6 +72,7 @@ static void test_architecture_table(void
> "ppc\0"
> "ppc64\0"
> "ppc64-le\0"
> +   "riscv64\0"
> "s390\0"
> "s390x\0") {
>  uint32_t c;
> 
> With this patch, test-seccomp pass successfully and the build succeed.
> I have also tested that after installing the resulting seccomp package
> the systemd boots and works fine with kernel 5.4 (i.e. without seccomp
> support) and kernel 5.5 (i.e. with seccomp support).


It looks like src/shared/seccomp-util.c would need an update too.

Have you tested, that seccomp is working on riscv64 with 5.5?
Something like this should lead to a blocked ping:


[Unit]
Description=test seccomp filter

[Service]
ExecStart=ping -c 1 www.debian.org
RestrictAddressFamilies=AF_UNIX

● test.service - test seccomp filter
 Loaded: loaded (/etc/systemd/system/test.service; static; vendor
preset: enabled)
 Active: failed (Result: exit-code) since Fri 2020-03-20 01:31:16
CET; 3s ago
Process: 350981 ExecStart=/bin/ping -c 1 www.debian.org
(code=exited, status=2)
   Main PID: 350981 (code=exited, status=2)

Mär 20 01:31:16 pluto systemd[1]: Started test seccomp filter.
Mär 20 01:31:16 pluto ping[350981]: /bin/ping: socket: Die Adressfamilie
wird von der Protokollfamilie nicht unterstützt
Mär 20 01:31:16 pluto systemd[1]: test.service: Main process exited,
code=exited, status=2/INVALIDARGUMENT
Mär 20 01:31:16 pluto systemd[1]: test.service: Failed with result
'exit-code'.


Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#851747: sysvinit_2.96-2.2_source.changes ACCEPTED into unstable

[Andreas Henriksson]

On Thu, Mar 19, 2020 at 11:58:37PM +0100, Adam Borowski wrote:
> On Thu, Mar 19, 2020 at 10:24:53PM +, Debian FTP Masters wrote:
> > Accepted:
> 
> >  sysvinit (2.96-2.2) unstable; urgency=medium
> >  .
> >* Non-maintainer upload.
> >* Drop 'Essential: yes' from sysvinit-utils (Closes: #851747)
> 
> WTF.

Indeed!

> 
> Could you please re-read the Developer's Reference, the section on doing
> NMUs?  While there are cases when small, helpful changes are not worth the
> full machinery, one that introduces (rather than fixes) a severity:critical
> bug ("breaks unrelated packages") is definitely not there.

Where's the breakage?! Please read the bug report feedback I've sent
extensive information about every possible case even for lowering
Priority to important, which was not done.

> 
> And, both Thorsten and me just told you to not rush.

Date: Wed, 18 Jan 2017 12:48:33 +

This has now been extensively discussed for over 3 years! Where's the
rush? Where's the useful input from the so called maintainers?

> 
> Fortunately, there was an upload race (one of the things that the NMU rules
> prevent) and -3 wins over -2.2 thus we won't have to revert.  But still...

I expect you to take care of this bug and others if you're now going to
pretent to maintain this package! The NMU was annouces weeks in advance
so there's nothing 'fortunate' about mid air collisions and
force-pushing to the public git repo.

Regards,
Andreas Henriksson

Bug#815639: geary: Geary won't start

[Michael Gratton]

Hi,

This is a system configuration and/or GLib bug, depending on how you 
look at it.


If you examine each $PREFIX/glib-2.0/schemas for each $PREFIX in 
$XDG_DATA_DIRS, you will find one of the prefixes before /usr/share 
contains an old schema XML file for Geary that does not contain the 
missing key. This is being found before the packaged schema in 
/usr/share, and hence GSettings cannot find the updated schema.


To fix, remove the old schema file, then recompile the schemas there 
using `glib-compile-schemas PATH/TO/SCHEMA_DIR`.


I recommend closing this bug or moving it to GLib, in case they are 
interested in fixing the root problem.


//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 

Bug#954314: neomutt: diff for NMU version 20191207+dfsg.1-1.1

[Stefano Rivera]

Package: neomutt
Version: 20191207+dfsg.1-1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for neomutt (versioned as 20191207+dfsg.1-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Diff in git: https://salsa.debian.org/mutt-team/neomutt/-/merge_requests/2

Regards.

diff -Nru neomutt-20191207+dfsg.1/debian/changelog neomutt-20191207+dfsg.1/debian/changelog
--- neomutt-20191207+dfsg.1/debian/changelog	2020-03-02 05:04:03.0 -0800
+++ neomutt-20191207+dfsg.1/debian/changelog	2020-03-19 17:09:59.0 -0700
@@ -1,3 +1,11 @@
+neomutt (20191207+dfsg.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix segfault in pager on new message received. (Closes: #953757)
+  * Fix FTBFS in non-UTC timezone. (Closes: #948895)
+
+ -- Stefano Rivera   Thu, 19 Mar 2020 17:09:59 -0700
+
 neomutt (20191207+dfsg.1-1) unstable; urgency=medium
 
   [ Andreas Henriksson ]
diff -Nru neomutt-20191207+dfsg.1/debian/patches/series neomutt-20191207+dfsg.1/debian/patches/series
--- neomutt-20191207+dfsg.1/debian/patches/series	2020-03-02 05:01:49.0 -0800
+++ neomutt-20191207+dfsg.1/debian/patches/series	2020-03-19 17:09:59.0 -0700
@@ -2,3 +2,5 @@
 debian-specific/use_usr_bin_editor.patch
 debian-specific/document_debian_defaults.patch
 misc/smime.rc.patch
+upstream/pager-segfault.patch
+upstream/test-tz.patch
diff -Nru neomutt-20191207+dfsg.1/debian/patches/upstream/pager-segfault.patch neomutt-20191207+dfsg.1/debian/patches/upstream/pager-segfault.patch
--- neomutt-20191207+dfsg.1/debian/patches/upstream/pager-segfault.patch	1969-12-31 16:00:00.0 -0800
+++ neomutt-20191207+dfsg.1/debian/patches/upstream/pager-segfault.patch	2020-03-19 17:09:59.0 -0700
@@ -0,0 +1,27 @@
+From: Pietro Cerutti 
+Date: Sat, 14 Dec 2019 16:18:28 +0100
+Subject: Fix crash in pager (#2039)
+
+Fixes #2038
+
+Bug-Upstream: https://github.com/neomutt/neomutt/issues/2038
+Origin: upstream, https://github.com/neomutt/neomutt/commit/645189415f20857fc317bb862a5b9dba33f61fa8
+Bug-Debian: https://bugs.debian.org/953757
+---
+ pager.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/pager.c b/pager.c
+index 793cdfb..1053885 100644
+--- a/pager.c
 b/pager.c
+@@ -2422,6 +2422,9 @@ int mutt_pager(const char *banner, const char *fname, PagerFlags flags, struct P
+ rd.menu->current =
+ MIN(rd.menu->current, MAX(Context->mailbox->msg_count - 1, 0));
+ struct Email *e = mutt_get_virt_email(Context->mailbox, rd.menu->current);
++if (!e)
++  continue;
++
+ index_hint = e->index;
+ 
+ bool q = Context->mailbox->quiet;
diff -Nru neomutt-20191207+dfsg.1/debian/patches/upstream/test-tz.patch neomutt-20191207+dfsg.1/debian/patches/upstream/test-tz.patch
--- neomutt-20191207+dfsg.1/debian/patches/upstream/test-tz.patch	1969-12-31 16:00:00.0 -0800
+++ neomutt-20191207+dfsg.1/debian/patches/upstream/test-tz.patch	2020-03-19 17:09:59.0 -0700
@@ -0,0 +1,94 @@
+From: Pietro Cerutti 
+Date: Wed, 29 Jan 2020 14:44:00 +
+Subject: Make sure we use the correct timezone in tests
+
+Fixes #2100
+
+Bug-Upstream: https://github.com/neomutt/neomutt/issues/2100
+Origin: upstream, https://github.com/neomutt/neomutt/commit/8aee8ba2a2e8726bf64b95d94c77dd34512b3732
+Bug-Debian: https://bugs.debian.org/948895
+---
+ test/date/mutt_date_localtime.c| 3 +++
+ test/date/mutt_date_localtime_format.c | 3 +++
+ test/date/mutt_date_make_imap.c| 3 +++
+ test/date/mutt_date_make_time.c| 3 +++
+ 4 files changed, 12 insertions(+)
+
+diff --git a/test/date/mutt_date_localtime.c b/test/date/mutt_date_localtime.c
+index dff4a89..c573445 100644
+--- a/test/date/mutt_date_localtime.c
 b/test/date/mutt_date_localtime.c
+@@ -24,11 +24,14 @@
+ #include "acutest.h"
+ #include "config.h"
+ #include "mutt/mutt.h"
++#include 
+ 
+ void test_mutt_date_localtime(void)
+ {
+   // struct tm mutt_date_localtime(time_t t);
+ 
++  setenv("TZ", "UTC", 1);
++
+   {
+ TEST_CASE("December, 2000");
+ struct tm tm = mutt_date_localtime(977745600);
+diff --git a/test/date/mutt_date_localtime_format.c b/test/date/mutt_date_localtime_format.c
+index 67907c1..23aa573 100644
+--- a/test/date/mutt_date_localtime_format.c
 b/test/date/mutt_date_localtime_format.c
+@@ -24,11 +24,14 @@
+ #include "acutest.h"
+ #include "config.h"
+ #include "mutt/mutt.h"
++#include 
+ 
+ void test_mutt_date_localtime_format(void)
+ {
+   // size_t mutt_date_localtime_format(char *buf, size_t buflen, char *format, time_t t);
+ 
++  setenv("TZ", "UTC", 1);
++
+   {
+ TEST_CHECK(mutt_date_localtime_format(NULL, 10, "apple", 0) == 0);
+   }
+diff --git a/test/date/mutt_date_make_imap.c b/test/date/mutt_date_make_imap.c
+index f814b9e..e6f33a7 100644
+--- a/test/date/mutt_date_make_imap.c
 b/test/date/mutt_date_make_imap.c
+@@ -24,11 +24,14 @@
+ #include "acutest.h"
+ #inc

Bug#954312: systemd: FTBFS on riscv64: test-seccomp fails: Assertion 'name' failed at src/test/test-seccomp.c:49

[Michael Biebl]

Thanks Aurelien.

I'd like to forward this patch to upstream. For that it would be great
if it was git am formatted, so it is properly attributed to you.

Would you mind sending me such an updated patch?

Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#954313: dh_installchangelogs: provide option to strip off old changelog entries

[Michael Biebl]

Package: debhelper
Version: 12.9
Severity: wishlist

Hi,

some packages have a very detailed debian/changelog which goes back
years or even decades.

Given that we nowadays have the ability to get changelogs on-demand via
"apt changelog", I think it would make sense if the changelog.Debian
that is installed on disk can be trimmed down.

While I surely can do that via some sed hacks in debian/rules, a nicer
option would be, if dh_installchangelogs would provide an option like
say --trim=365d / --trim=2y / etc, which would only install changelog
entries that are newer then 365 days / 2 years / etc.

2 or 3 years sounds like a good compromise to me, as this would cover
changelog entries dating back to the last stable release.

For the time being, I would make that opt-in, i.e. packages have to
override dh_installchangelogs. Maybe at some point in the future,
something like --trim=3y could be made the default behaviour with a new
compat bump.

I vaguely remember that Ubuntu does something similar in that regard.
I've CCed Julian, maybe he can provide some input.

Regards,
Michael




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

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

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  1.6.3-2
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  dwz  0.13-5
ii  file 1:5.38-4
ii  libdebhelper-perl12.9
ii  libdpkg-perl 1.19.7
ii  man-db   2.9.1-1
ii  perl 5.30.0-9
ii  po-debconf   1.0.21

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.202001

-- no debconf information

Bug#872118: mdadm: fdisk build-dependency needed (for tests)

[Andreas Henriksson]

Hi,

I've quickly looked at this again and I'm not unsure if an
fdisk build-dependency really is needed (for tests).

The tests/07autodetect file uses sfdisk, this file seems to potentially
get executed from ./test

The Makefile has a test target, but that only echos out to
run ./test as root and doesn't actually run it.

It thus doesn't look to me like the 07autodetect test is actually run
during a normal build. Invoking the ./test suite seems to be something
(only) manually done, so maybe there's no need for a (build-)dependency
after all

Regards,
Andreas Henriksson

Bug#949863: Info received (#949863: please enable CONFIG_NET_SWITCHDEV)

[Ben Hutchings]

On Mon, 9 Mar 2020 13:58:38 +0200 Tzafrir Cohen  wrote:
> Hi,
> 
> > Also: please consider this change for inclusion in a stable update, if
> > possible.
> 
> I see that this was merged into git. Thanks. What are the chances of
> this fix getting included into Debian 10.4 to allow OVS off-loading there?

I think it's reasonable, but will need to consult with the release
team.  In case this should only happen after the change has gone into
unstable and testing.

Ben.
 
-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus




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

Bug#920107: ITA: fuse-posixovl -- FUSE file system that provides POSIX functionality

[Seunghun Han]

Package: wnpp

I tend to adopt the package.

Best regards,

Seunghun

Bug#953982: wine-development: wine in Debian fails to start "Uru", but upstream wine works fine (regression)

[Michael Gilbert]

On Thu, Mar 19, 2020 at 8:28 AM Diafero wrote:
> Version 5.0-3 also seems affected.

Was the version that worked 4.21-1 or 4.21-2?

Best wishes,
Mike

Bug#954312: systemd: FTBFS on riscv64: test-seccomp fails: Assertion 'name' failed at src/test/test-seccomp.c:49

[Aurelien Jarno]

Package: systemd
Version: 245.2-1
Severity: normal
Tags: patch

Dear maintainer,

The latest version of systemd enabled seccomp support on riscv64. Thanks
for doing that. However it now fails to build due to the test
test-seccomp failing:

| 321/486 test-seccompFAIL 0.09 s (killed by 
signal 6 SIGABRT)
| 
| --- command ---
| 08:37:44 
PATH='/<>/build-deb:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games'
 SYSTEMD_KBD_MODEL_MAP='/<>/src/locale/kbd-model-map' 
SYSTEMD_LANGUAGE_FALLBACK_MAP='/<>/src/locale/language-fallback-map'
 /<>/build-deb/test-seccomp
| --- stderr ---
| Failed to read $container of PID 1, ignoring: Permission denied
| Found container virtualization none.
| /* test_seccomp_arch_to_string */
| Assertion 'name' failed at src/test/test-seccomp.c:49, function 
test_seccomp_arch_to_string(). Aborting.
| ---

The full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=systemd&arch=riscv64&ver=245.2-1&stamp=1584607125&raw=0

It happens that upstream systemd doesn't support yet riscv64. I came
with a very simple patch to fix that issue:

--- systemd-245.2.orig/src/test/test-seccomp.c
+++ systemd-245.2/src/test/test-seccomp.c
@@ -72,6 +72,7 @@ static void test_architecture_table(void
"ppc\0"
"ppc64\0"
"ppc64-le\0"
+   "riscv64\0"
"s390\0"
"s390x\0") {
 uint32_t c;

With this patch, test-seccomp pass successfully and the build succeed.
I have also tested that after installing the resulting seccomp package
the systemd boots and works fine with kernel 5.4 (i.e. without seccomp
support) and kernel 5.5 (i.e. with seccomp support).

Therefore, would it be possible to add this patch in the next upload?

Thanks,
Aurelien

-- Package-specific info:

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
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=fr 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
- no debconf information

Bug#954307: nemo-python: python 3.8 based nemo extensions fail to execute

[Norbert Preining]

On Thu, 19 Mar 2020, David Mohammed wrote:
> Tags: patch

Thanks, I'll upload soon!

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#953412: apt: segfault at 0 ip 00007f024bc54e6f sp 00007ffcc6b28d40 error 4 in libapt-pkg.so.5.0.2

[Bernhard Übelacker]

Hello,
I tried to locate the source line of the address shown
in the /var/log/messages output.
But that failed but I found in the strace output that
it loads for some reason two libapt-pkg.so files ...

...
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libapt-pkg.so.6.0", 
O_RDONLY|O_CLOEXEC) = 3
...
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libapt-pkg.so.5.0", 
O_RDONLY|O_CLOEXEC) = 3
...

Just in case if that helps.

Kind regards,
Bernhard

Bug#824603: [ext] COMPROBANTE DE FACTURA DE PAGO # 65832

[Pradeep Makand]

 

Gracias de antemano 

SWIFT ## Copia de pago.pdf.001
Description: application/rar

Bug#954310: dependency on python3-requests missing on Debian Buster

[MichaIng]

Package: cloudprint
Version: 0.14-12

Hey guys,

the current cloudprint package version on Debian Buster misses the 
dependency on python3-requests, as present on all other package versions.


The cloudprint command/python script simply fails without it:
Traceback (most recent call last):
  File "/usr/bin/cloudprint", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
3191, in 

@_call_aside
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
3175, in _call_aside

f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
3204, in _initialize_master_working_set

working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
583, in _build_master

ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
900, in require

needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
786, in resolve

raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'requests' distribution was not 
found and is required by cloudprint


Best regards,
MichaIng

Bug#954309: Remove rsyslog/system-log-daemon dependency

[MichaIng]

Package: cloudprint
Version: 0.14-13
Version: 0.14-12
Version: 0.14-8

Hey guys,

it would be great if the rsyslog dependency could be removed from this 
package. Debian comes with systemd by default, which has 
systemd-journald as integrated syslog daemon, which is practically 
anyway required for systemd to function. rsyslog in this setup does not 
provide any advantage, as long as one is familiar with using journalctl 
and does not depend on plain text log files. But keeping this choice for 
local admin would be great.


Also since Debian Stretch, the cloudprint-service package comes with a 
systemd unit (and no sysvinit service), hence expects systemd to be 
present and logs to systemd-journald in the first place.


And finally tests prove that systemd-journald as only syslog daemon does 
not break cloudprint binary or service.


Best regards,
MichaIng

Bug#954236: Proposed Buster Fix (pyhon3-bleach: New secuirty issue: mutation XSS (again))

[Salvatore Bonaccorso]

Hi Scott,

On Thu, Mar 19, 2020 at 12:20:25AM -0400, Scott Kitterman wrote:
> Upstream's 3.1.2 release had just the security fix in it.  I propose updating 
> buster with it (I put 3.1.3 in unstable, but it had non-security fixes in it.
> 
> I'm not 100% sure about if we need to modify the import path for the new test 
> since we don't use the vendored html5lib, but other than that (which I will 
> investigate), this should be good.

Given we did release a DSA for the similar issue CVE-2020-6802 for
buster we can do the same as well now for this issue (it got assigned
CVE-2020-6816).

Your plan to rebase to 3.1.2 looks good to me.

Once you have the update ready please just come back to us, if
possible add the CVE id reference as it was assigned now, but more
importantly please adjust the debian/changelog (the target
distribution needs to be buster-security).

many thanks for your work!

Regards,
Salvatore

Bug#954306: sysvinit-utils: consider lowering the Priority of sysvinit-utils to important or even optional

[Thorsten Glaser]

On Thu, 19 Mar 2020, Andreas Henriksson wrote:

> others might disagree? Input welcome.

Don’t push it. Get things fixed first, slowly.

After all, GNU bash is also still Essential and
Priority: required after years and multiple releases…
and its Installed-Size is over 47 times that of
sysvinit-utils.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#931532: could use help on this

[Bdale Garbee]

tags 931532 +needhelp
thanks

I don't have any easy way to debug LDAP issues in sudo.  If someone else
has time to chase this down and tell me what's wrong, that'd be great.

Bdale


signature.asc
Description: PGP signature

Bug#954306: sysvinit-utils: consider lowering the Priority of sysvinit-utils to important or even optional

[Adam Borowski]

On Thu, Mar 19, 2020 at 10:40:03PM +0100, Andreas Henriksson wrote:
> Please consider lowering the 'Priority: required' on the sysvinit-utils
> to something lower, eg. important or even optional.
> 
> To be able to lower to important without breakage there are likely a
> number of issues that has to be resolved first. These has previously
> been discussed in the bug report that was opened about making
> sysvinit-utils non-Essential (#851747) which has alot of discussion also
> related to a potential future priority decrease which I'm now opening
> this bug report about.

You've listed a long number of issues that would have to be solved;
they'd require a lot of work.  So it'd be good to ask: what's the benefit?

The only thing I've heard so far would be reducing the size of a minimal
install.  The package has Installed-Size: 140 kB, of which:
8.0K/lib/init/init-d-script
4.0K/lib/init/vars.sh
16K /sbin/fstab-decode
28K /sbin/killall5
4.0K/usr/share/doc/sysvinit-utils/NEWS.Debian.gz
44K /usr/share/doc/sysvinit-utils/changelog.Debian.gz
20K /usr/share/doc/sysvinit-utils/changelog.gz
4.0K/usr/share/doc/sysvinit-utils/copyright
4.0K/usr/share/man/man5/init-d-script.5.gz
4.0K/usr/share/man/man8/fstab-decode.8.gz
4.0K/usr/share/man/man8/killall5.8.gz
4.0K/usr/share/man/man8/pidof.8.gz
4.0K/bin/pidof

Just tossing away old parts of changelogs would get rid of most of the
cruft, then killall5 is a part that's easy to remove (just a few uses in the
archive).  But the rest would cause lots of busywork.

Thus, let's not do so.  Instead, let's pick low-hanging fruits elsewhere. 
For example, just recompiling /sbin/ldconfig with anything but glibc shaves
almost a megabyte from the essential set.  There's more of such bits.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#954306: sysvinit-utils: consider lowering the Priority of sysvinit-utils to important or even optional

[Andreas Henriksson]

On Thu, Mar 19, 2020 at 10:40:03PM +0100, Andreas Henriksson wrote:
[...]
> Note that (some of the) bug reports that should possibly be marked as
> blockers for this has been filed, see:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851747#126
[...]
> pidof should be moved to procps package (which is Priority: important).
> This is the only widely used tool which probably deserves to stay in the
> 'important' set.
[...]
> Someone might have to figure out if entangling the pidof transition with
> the Priority lowering is beneficial or if it's better to keep these
> issues separate.

Please note that sysvinit-utils doesn't qualify in the Priority required
set as defined by policy[1] and previously demonstrated[2].

The previously mentioned potential blockers for this are as I see it
mainly for "theoretical correctness", even if pidof stays in
sysvinit-utils package. So someone might have to make the call on which
theoreticall correctness is more impontant.

While ofcourse it would be ultimate if someone volunteered to fix every
theoretical issue, I think people likely have better things to spend
their time on and thus someone will have to decide which is worse:
- sysvinit-utils not being lowered to Priority: important and thus
  technically violating Policy.
vs
- a few packages missing dependencies (or better solution).

Any "normal" installation will have all Priority: important packages
installed anyway (and those with special-case debootstraps likely
can be expected to figure things out on their own).

I'd think lowering to Priority: optional (while still keeping pidof in
sysvinit-utils package) would be more "interesting" though, thus my
previous recommendation to move pidof to procps keeping it important
while moving the rest of sysvinit-utils package to Priority: optional.

My opinion is thus that moving to Priority: important should happen ASAP
(while moving to Priority: optional would need a bit more thought), but
others might disagree? Input welcome.

Regards,
Andreas Henriksson

[1]: Chapter 2.5 Priorities - 
https://www.debian.org/doc/debian-policy/ch-archive.html#priorities
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851747#76

Bug#954307: nemo-python: python 3.8 based nemo extensions fail to execute

[David Mohammed]

Package: nemo-python
Version: 4.4.0-2+b1
Severity: important
Tags: patch

Dear Maintainer,

   * What led up to the situation?
 python 3.8 is now the default in unstable.  Python based extensions
 no longer execute when nemo is running
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Install nemo-python in unstable
   * What was the outcome of this action?
 When nemo is run you see the following:
 ** (nemo:1355): WARNING **: 21:32:22.824: 
/usr/lib/x86_64-linux-gnu/nemo/extensions-3.0/libnemo-python.so: 
undefined symbol: PyExc_ImportError
   * What outcome did you expect instead?
 nemo to start without warnings

enc is a debdiff to resolve


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

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

Versions of packages nemo-python depends on:
ii  gir1.2-nemo-3.0 4.4.2-2
ii  libc6   2.30-2
ii  libglib2.0-02.64.1-1
ii  libgtk-3-0  3.24.14-1
ii  libnemo-extension1  4.4.2-2

nemo-python recommends no packages.

nemo-python suggests no packages.

-- no debconf information
diff -Nru nemo-python-4.4.0/debian/changelog nemo-python-4.4.0/debian/changelog
--- nemo-python-4.4.0/debian/changelog  2020-02-03 23:45:18.0 +
+++ nemo-python-4.4.0/debian/changelog  2020-03-19 21:18:08.0 +
@@ -1,3 +1,11 @@
+nemo-python (4.4.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bug-fix
+- Ensure python based extensions work with python 3.8
+
+ -- David Mohammed   Thu, 19 Mar 2020 21:18:08 +
+
 nemo-python (4.4.0-2) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru 
nemo-python-4.4.0/debian/patches/0001-nemo-python-be-compatible-with-python-3.8.patch
 
nemo-python-4.4.0/debian/patches/0001-nemo-python-be-compatible-with-python-3.8.patch
--- 
nemo-python-4.4.0/debian/patches/0001-nemo-python-be-compatible-with-python-3.8.patch
   1970-01-01 01:00:00.0 +0100
+++ 
nemo-python-4.4.0/debian/patches/0001-nemo-python-be-compatible-with-python-3.8.patch
   2020-03-19 21:18:08.0 +
@@ -0,0 +1,32 @@
+Origin: commit a528eb2b1564845c66a2c5b177ab39c8a345d2e4
+Author: Eli Schwartz 
+Last-Update: 2019-11-17
+Description: [PATCH] nemo-python: be compatible with python 3.8
+ See https://bugs.python.org/issue36721
+
+---
+ meson.build | 8 +++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/nemo-python/meson.build b/nemo-python/meson.build
+index 93377d1..3f5a8e9 100644
+--- a/meson.build
 b/meson.build
+@@ -7,7 +7,13 @@ gnome = import('gnome')
+ 
+ deps = []
+ 
+-python3 = dependency('python3')
++# In python 3.8, applications which embed python (i.e. not importable modules)
++# must use python3-embed, instead of python3. Check that first.
++# https://bugs.python.org/issue36721
++python3 = dependency('python3-embed', required: false)
++if not python3.found()
++python3 = dependency('python3')
++endif
+ nemo = dependency('libnemo-extension', required: true)
+ 
+ deps += python3
+-- 
+2.26.0.rc2
+
diff -Nru nemo-python-4.4.0/debian/patches/series 
nemo-python-4.4.0/debian/patches/series
--- nemo-python-4.4.0/debian/patches/series 2020-02-03 23:45:18.0 
+
+++ nemo-python-4.4.0/debian/patches/series 2020-03-19 21:15:45.0 
+
@@ -0,0 +1 @@
+0001-nemo-python-be-compatible-with-python-3.8.patch

Bug#949419:

[Bdale Garbee]

tags 949519 +needhelp
thanks

I don't have any easy way to debug LDAP issues.  If someone else does
and wants to chase this down and let me know where the problem is,
that'd be great.

Bdale


signature.asc
Description: PGP signature

Bug#851747: sysvinit-utils: drop Essential flag

[Andreas Henriksson]

FYI I've filed https://bugs.debian.org/954306 to track the
potential adjustment of the Priority: field, which seems to be
the majority of the discussion in this bug report.

I'm about to upload an NMU of sysvinit which drops the 'Essential: yes'
from sysvinit-utils - but still keeps 'Priority: required' unchanged
(and closing this bug report while doing so) for now.

Regards,
Andreas Henriksson

Bug#954306: sysvinit-utils: consider lowering the Priority of sysvinit-utils to important or even optional

[Andreas Henriksson]

Package: sysvinit-utils
Version: 2.96-2
Severity: wishlist

Dear Maintainer,

Please consider lowering the 'Priority: required' on the sysvinit-utils
to something lower, eg. important or even optional.

To be able to lower to important without breakage there are likely a
number of issues that has to be resolved first. These has previously
been discussed in the bug report that was opened about making
sysvinit-utils non-Essential (#851747) which has alot of discussion also
related to a potential future priority decrease which I'm now opening
this bug report about.

A summary of the discussion:

* Packages which ships an init scripts not masked by a systemd unit that
  uses /lib/init/init-d-script or /lib/init/vars.sh
  - preferable solution would be to ship a masking native systemd unit
  - Note: watch out for service files wrapping the init script!
(lintian tag 'systemd-service-file-wraps-init-script')

* Users of /sbin/fstab-decode (if any)

* Users of /bin/pidof
  - consider potentially moving/using the procps pidof implementation.
See #810018

* Users of killall5 (if any)

Note that (some of the) bug reports that should possibly be marked as
blockers for this has been filed, see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851747#126


I think to be able to accomplish lowering to Priority: optional likely
pidof should be moved to procps package (which is Priority: important).
This is the only widely used tool which probably deserves to stay in the
'important' set. (Also using the procps implementation of pidof would
mean we get rid of a pointless difference, as it seems basically every
other major linux distribution is using the procps implementation.)

I think if users of pidof start adding dependencies on sysvinit-utils
and it later gets moved to a different package there will be much
useless churn. A possible workaround for this could be to add a virtual
package 'pidof' that is provided by sysvinit-utils until pidof is
actually moved to procps and then procps provides the virtual pidof
package, while asking users to depend on pidof virtual package. This
might be overkill though.

Someone might have to figure out if entangling the pidof transition with
the Priority lowering is beneficial or if it's better to keep these
issues separate.

Regards,
Andreas Henriksson

Bug#954305: python-udatetime: shared library is not properly linked with libm

[Aurelien Jarno]

Source: python-udatetime
Version: 0.0.16-2
Severity: serious
Tags: patch

python-udatetime use the pow() math function in src/rfc3339.c, but
doesn't link with libm.so. This causes the non-versioned pow symbol to
be used, which in turn causes issues when glibc version is upgraded.

The attached patch fixes that.

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
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=fr 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- python-udatetime-0.0.16.orig/setup.py
+++ python-udatetime-0.0.16/setup.py
@@ -36,6 +36,7 @@ if __pypy__ is None:
 Extension(
 'udatetime.rfc3339',
 ['./src/rfc3339.c'],
+libraries=['m'],
 define_macros=macros,
 extra_compile_args=['-Ofast', '-std=c99']
 )

Bug#953037: lua-cgi: CVE-2014-2875

[Brian May]

On Tue, Mar 03, 2020 at 05:43:13PM +0100, Sylvain Beucler wrote:
> The following vulnerability was published for lua-cgi.
> 
> CVE-2014-2875[0]:
> | The session.lua library in CGILua 5.2 alpha 1 and 5.2 alpha 2 uses
> | weak session IDs generated based on OS time, which allows remote
> | attackers to hijack arbitrary sessions via a brute force attack. NOTE:
> | CVE-2014-10300 and CVE-2014-10400 were SPLIT from this ID.

To me it looks like the session management in the Debian package
is completely broken, and as such has no actual security issue here.

See: http://bugs.debian.org/954300 - this also includes a reference to
the upstream fix which will fix the breakage and expose the security
issue here.

Regardless, I created an upstream bug, see:
https://github.com/keplerproject/cgilua/issues/17
-- 
Brian May 

Bug#954300: lua-cgi: session closing broken on lua5.1

[Brian May]

severity 954300 important
thanks

On Fri, Mar 20, 2020 at 07:54:45AM +1100, Brian May wrote:
> As far as I can tell - please do say if I am wrong - this package is
> completely useless with LUA5.1, as packaged.

I was forgetting that lua-cgi is more then just the session management.

It is possible other parts of lua-cgi still work, although not sure I
would trust them myself. It looks like this package has not been updated
in years.

Downgrading this bug to important.
-- 
Brian May 

Bug#954304: rails: CVE-2020-5267: Possible XSS vulnerability in ActionView

[Salvatore Bonaccorso]

Source: rails
Version: 2:5.2.4.1+dfsg-1
Severity: important
Tags: security upstream
Control: found -1 2:6.0.2.1+dfsg-2
Control: found -1 2:5.2.2.1+dfsg-1
Control: found -1 2:4.2.7.1-1+deb9u1
Control: found -1 2:4.2.7.1-1

Hi,

The following vulnerability was published for rails.

CVE-2020-5267[0]:
| In ActionView before versions 6.0.2.2 and 5.2.4.2, there is a possible
| XSS vulnerability in ActionView's JavaScript literal escape helpers.
| Views that use the `j` or `escape_javascript` methods may be
| susceptible to XSS attacks. The issue is fixed in versions 6.0.2.2 and
| 5.2.4.2.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-5267
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5267
[1] https://www.openwall.com/lists/oss-security/2020/03/19/1

Regards,
Salvatore

Bug#954303: tika: CVE-2020-1950

[Salvatore Bonaccorso]

Source: tika
Version: 1.22-1
Severity: grave
Tags: security upstream
Justification: user security hole
Control: found -1  1.20-1

Hi,

The following vulnerability was published for tika.

CVE-2020-1950[0]:
Excessive memory usage (DoS) vulnerability in Apache Tika's PSDParser

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-1950
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1950
[1] https://www.openwall.com/lists/oss-security/2020/03/18/3

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

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

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

Bug#954302: tika: CVE-2020-1951

[Salvatore Bonaccorso]

Source: tika
Version: 1.22-1
Severity: grave
Tags: security upstream
Justification: user security hole
Control: found -1 1.20-1

Hi,

The following vulnerability was published for tika.

CVE-2020-1951[0]:
Infinite Loop (DoS) vulnerability in Apache Tika's PSDParser

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-1951
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1951
[1] https://www.openwall.com/lists/oss-security/2020/03/18/4

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#954301: ITP: python-rich -- library for rendering rich text and beautiful formatting to the terminal

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi 

* Package name: python-rich
  Version : 0.8.0
  Upstream Author : Will McGugan
* URL : https://github.com/willmcgugan/rich
* License : MIT
  Programming Lang: Python
  Description : library for rendering rich text and beautiful formatting to 
the terminal

 The Rich API makes it easy to add colorful text (up to 16.7 million colors)
 with styles (bold, italic, underline etc.) to your script or application. Rich
 can also render pretty tables, progress bars, markdown, syntax highlighted
 source code, and tracebacks -- out of the box.

Bug#954300: lua-cgi: session closing broken on lua5.1

[Brian May]

Package: lua-cgi
Version: 5.2~alpha2-1
Severity: serious
Justification: renders package useless

As far as I can tell - please do say if I am wrong - this package is
completely useless with LUA5.1, as packaged.

When run with the following code:

=== cut ===
session = require("cgilua.session")
session.setsessiondir(CGILUA_TMP)
cgilua.addopenfunction (session.open)
cgilua.addclosefunction (session.close)
=== cut ===

I get the following error:

=== cut ===
/usr/share/lua/5.1/cgilua/session.lua:228: attempt to index field 'session' (a 
nil value)
stack traceback:
  /usr/share/lua/5.1/cgilua/session.lua:228: in function '?'
  /usr/share/lua/5.1/cgilua.lua:538: in function
  [C]: in function 'xpcall'
  /usr/share/lua/5.1/cgilua.lua:174: in function 'pcall'
  /usr/share/lua/5.1/cgilua.lua:637: in function 'main'
  /usr/share/lua/5.1/wsapi/sapi.lua:53: in function
  (tail call): ?
=== cut ===

Where line 228 is the first line in the following function that
reference cgilua.session:

=== cut ===
function M.close ()
if next (cgilua.session.data) then
M.save (id, cgilua.session.data)
id = nil
end
end
=== cut ===

I belive this is fixed in by the upstream commit
https://github.com/keplerproject/cgilua/commit/bfc65f5df6838a2f39c98f6d8d0285fe27fbc7b3

As a work around, I tried adding:

=== cut ===
cgilua.session = session
=== cut ===

But this gives another error (which I don't entirely understand):

=== cut ===
/usr/share/lua/5.1/cgilua/session.lua:228: bad argument #1 to 'next' (table 
expected, got nil)
stack traceback:
  [C]: in function 'next'
  /usr/share/lua/5.1/cgilua/session.lua:228: in function '?'
  /usr/share/lua/5.1/cgilua.lua:538: in function
  [C]: in function 'xpcall'
  /usr/share/lua/5.1/cgilua.lua:174: in function 'pcall'
  /usr/share/lua/5.1/cgilua.lua:637: in function 'main'
  /usr/share/lua/5.1/wsapi/sapi.lua:53: in function
  (tail call): ?
=== cut ===

As the close method is broken, it looks like lua-cgi is not capable of
saving a session. I believe this also means that #953037 / CVE-2014-2875
does not apply.

https://bugs.debian.org/953037

Once I get a bug id for this bug, I plan to followup on that bug
report also.

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

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

Versions of packages lua-cgi depends on:
ii  lua-expat   1.3.0-4
ii  lua-filesystem  1.6.3-1
ii  lua-socket  3.0~rc1+git+ac3201d-4

Versions of packages lua-cgi recommends:
pn  lua-wsapi  

lua-cgi suggests no packages.

Bug#954298: RM: libperlspeak-perl/2.01-2 from buster

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
Control: clone -1 -2
Control: retitle -2 RM: libperlspeak-perl/2.01-2 from stretch

Hi

Please remove libperlspeak-perl/2.01-2 on next point release time from
buster and stretch (cloning the bug accordingly twice as two bugs are
needed).

The package is going to be removed from unstable: It is unmaintained
for ages upstream, has no reverse dependencies, hardly any users,
problematic design and security issues accordingly.

See #954297 for the removal request from unstable.

Regards,
Salvatore

Bug#954296: RFS: libkqueue/2.0.3-1.2 [NMU, RC] -- cross-platform library for kernel event notification

[Adam Borowski]

On Thu, Mar 19, 2020 at 08:34:16PM +, Sudip Mukherjee wrote:
>  * Package name: libkqueue
>Version : 2.0.3-1.2

> Changes since the last upload:
> 
>* Non-maintainer upload.
>* Fix FTBFS with GCC. (Closes: #831076)

Alas, the testsuite fails for me:

FAIL: kqtest
===
   libkqueue 2.0.3: ./test-suite.log
===

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: kqtest


[0xd000]
[0x3]
[0x0]
/lib64/ld-linux-x86-64.so.2(+0x70b6)[0x7f2547e110b6]
[0x0]
[0x0]
[0x0]
[0x47e110b6]
[0x0]
[0x7ffe9958b9c0]
[0x0]
[0x7f2547e05000]
[0x7]
[0x0]
[0x0]
/lib64/ld-linux-x86-64.so.2(+0xb51d)[0x7f2547e1551d]
[0x7ffe9958bb50]
[0x7f2547e06410]
[0x7f2547e0682f]
[0x21]
/usr/lib/x86_64-linux-gnu/libeatmydata.so(+0x53c)[0x7f2547e0053c]
[0x62696c2f]
[0x2f682f6174616479]
[0x0]
[0x7ffe9958bb50]
/lib64/ld-linux-x86-64.so.2(+0xb21f)[0x7f2547e1521f]
[0x32]
[0x7ffe9958bb50]
[0x7f2547e06440]
/lib64/ld-linux-x86-64.so.2(+0x6749)[0x7f2547e10749]
[0x32]
[0x7c]
Running 1 iterations
1: test_peer_close_detection()  
2: test_kqueue()
3: test_kevent()
4: test_ev_receipt()
5: test_kevent_socket_add() 
6: test_kevent_socket_del() 
7: test_kevent_socket_add_without_ev_add()  
8: test_kevent_socket_get() 
9: test_kevent_socket_disable_and_enable()  
10: test_kevent_socket_oneshot()
11: test_kevent_socket_clear()  
12: test_kevent_socket_dispatch()   
13: test_kevent_socket_listen_backlog() 
14: test_kevent_socket_eof()
15: test_kevent_regular_file()  
* ERROR: Program received signal 6 *
 *** TEST FAILED ***
FAIL kqtest (exit status: 1)


Full log attached.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄
sbuild (Debian sbuild) 0.79.0 (05 February 2020) on valinor.angband.pl

+==+
| libkqueue 2.0.3-1.2 (amd64)  Thu, 19 Mar 2020 20:40:32 + |
+==+

Package: libkqueue
Version: 2.0.3-1.2
Source Version: 2.0.3-1.2
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-23571471-0811-4a88-bf66-19d04e910b1b'
 with '<>'
I: NOTICE: Log filtering will replace 'build/libkqueue-wrmtEh/resolver-vpQErW' 
with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/home/kilobyte/tmp/pkg/libkqueue_2.0.3-1.2.dsc exists in 
/home/kilobyte/tmp/pkg; copying to chroot
I: NOTICE: Log filtering will replace 'build/libkqueue-wrmtEh/libkqueue-2.0.3' 
with '<>'
I: NOTICE: Log filtering will replace 'build/libkqueue-wrmtEh' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper (>= 9), dh-autoreconf, autotools-dev, 
build-essential, fakeroot
Filtered Build-Depends: debhelper (>= 9), dh-autoreconf, autotools-dev, 
build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [957 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [383 B]
Get:5 copy:/<>/apt_archive ./ Packages [461 B]
Fetched 1801 B in 0s (139 kB/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  sbuild-build-depends-main-dummy
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 892 B of archives.

Bug#954297: RM: libperlspeak-perl -- RoQA; unmaintained upstream, security issues

[Salvatore Bonaccorso]

Package: ftp.debian.org
Severity: normal

Hi

Please remove libperlspeak-perl from unstable, see #954238 for
discussion and ack from Gregor. It is unmaintained for ages upstream,
has no reverse dependencies, hardly any users, problematic design and
security issues accordingly.

Regards,
Salvatore

Bug#831076: libkqueue: diff for NMU version 2.0.3-1.2

[Sudip Mukherjee]

Control: tags 831076 + patch
Control: tags 831076 + pending

Dear maintainer,

I've prepared an NMU for libkqueue (versioned as 2.0.3-1.2) and
uploaded it to mentors for sponsoring. Please feel free to tell me if I
should remove it.

--
Regards
Sudip

diff -Nru libkqueue-2.0.3/debian/changelog libkqueue-2.0.3/debian/changelog
--- libkqueue-2.0.3/debian/changelog2014-09-11 12:55:27.0 +0100
+++ libkqueue-2.0.3/debian/changelog2020-03-19 19:47:14.0 +
@@ -1,3 +1,10 @@
+libkqueue (2.0.3-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with GCC. (Closes: #831076)
+
+ -- Sudip Mukherjee   Thu, 19 Mar 2020 19:47:14 
+
+
 libkqueue (2.0.3-1.1) unstable; urgency=medium
 
   * Non maintainer upload.
diff -Nru libkqueue-2.0.3/debian/patches/fix_ftbfs.patch 
libkqueue-2.0.3/debian/patches/fix_ftbfs.patch
--- libkqueue-2.0.3/debian/patches/fix_ftbfs.patch  1970-01-01 
01:00:00.0 +0100
+++ libkqueue-2.0.3/debian/patches/fix_ftbfs.patch  2020-03-19 
19:47:14.0 +
@@ -0,0 +1,17 @@
+Description: Appease GCC 8.1
+
+upstream: 
https://github.com/mheily/libkqueue/commit/7c9a8f227489f7c45344fc23b2854663872dc7f2
+
+---
+
+--- libkqueue-2.0.3.orig/src/common/kevent.c
 libkqueue-2.0.3/src/common/kevent.c
+@@ -101,7 +101,7 @@ kevent_flags_dump(const struct kevent *k
+ const char *
+ kevent_dump(const struct kevent *kev)
+ {
+-static __thread char buf[1024];
++static __thread char buf[2147];
+ 
+ snprintf((char *) &buf[0], sizeof(buf), 
+ "{ ident=%d, filter=%s, %s, %s, data=%d, udata=%p }",
diff -Nru libkqueue-2.0.3/debian/patches/fix_logic.patch 
libkqueue-2.0.3/debian/patches/fix_logic.patch
--- libkqueue-2.0.3/debian/patches/fix_logic.patch  1970-01-01 
01:00:00.0 +0100
+++ libkqueue-2.0.3/debian/patches/fix_logic.patch  2020-03-19 
19:47:14.0 +
@@ -0,0 +1,17 @@
+Description: Fix incorrect boolean logic in src/linux/read.c
+
+upstream: 
https://github.com/mheily/libkqueue/commit/fd76168ac6018d5ae99ce9778ba1ef4de524b632
+
+---
+
+--- libkqueue-2.0.3.orig/src/linux/read.c
 libkqueue-2.0.3/src/linux/read.c
+@@ -204,7 +204,7 @@ evfilt_read_knote_delete(struct filter *
+ if (kn->kev.flags & EV_DISABLE)
+ return (0);
+ 
+-if ((kn->kn_flags & KNFL_REGULAR_FILE && kn->kdata.kn_eventfd != -1) < 0) 
{
++if ((kn->kn_flags & KNFL_REGULAR_FILE) && (kn->kdata.kn_eventfd != -1)) {
+ if (epoll_ctl(kn->kn_epollfd, EPOLL_CTL_DEL, kn->kdata.kn_eventfd, 
NULL) < 0) {
+ dbg_perror("epoll_ctl(2)");
+ return (-1);
diff -Nru libkqueue-2.0.3/debian/patches/series 
libkqueue-2.0.3/debian/patches/series
--- libkqueue-2.0.3/debian/patches/series   2014-09-11 12:55:59.0 
+0100
+++ libkqueue-2.0.3/debian/patches/series   2020-03-19 16:58:05.0 
+
@@ -1 +1,3 @@
 replace-64bit-knote.patch
+fix_ftbfs.patch
+fix_logic.patch

Bug#954296: RFS: libkqueue/2.0.3-1.2 [NMU, RC] -- cross-platform library for kernel event notification

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "libkqueue"

 * Package name: libkqueue
   Version : 2.0.3-1.2
   Upstream Author : Mark Heily 
 * URL : https://github.com/mheily/libkqueue/wiki
 * License : [fill in]
 * Vcs : None
   Section : libs

It builds those binary packages:

  libkqueue0 - cross-platform library for kernel event notification
  libkqueue-dev - Development files for libkqueue

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libk/libkqueue/libkqueue_2.0.3-1.2.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Fix FTBFS with GCC. (Closes: #831076)


-- 
Regards
Sudip

Bug#469315: still need mailcap entries

[Bdale Garbee]

It's a decade later, and various apps including emacs still make routine use
of mailcap data.  Any chance you could just deliver a mailcap file and save
me the pain of having to drop entries on every machine I configure?

Bdale

Bug#932617: any update on this as I still got it today with the update (again)

[Mario.Limonciello]

1.3.9.2?  You mean 1.3.9-2?

They were supposed to be removed about 5 months ago.  The preinst, postrm, and 
postinst has the stuff for doing these:
https://salsa.debian.org/efi-team/fwupd/-/blob/debian/debian/fwupd.preinst
https://salsa.debian.org/efi-team/fwupd/-/blob/debian/debian/fwupd.postrm
https://salsa.debian.org/efi-team/fwupd/-/blob/debian/debian/fwupd.postinst


> -Original Message-
> From: shirish शिरीष 
> Sent: Thursday, March 19, 2020 11:02 AM
> To: 932...@bugs.debian.org
> Subject: Bug#932617: any update on this as I still got it today with the 
> update
> (again)
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi all,
> 
> See -
> 
> $ adequate fwupd
> fwupd: obsolete-conffile /etc/dbus-
> 1/system.d/org.freedesktop.fwupd.conf
> fwupd: obsolete-conffile /etc/fwupd/remotes.d/fwupd.conf
> 
> I wanna try fwupd but once the above obsolete conffiles are removed. I do
> know it's a work in progress but still. FWIW, the package got updated to
> 1.3.9.2
> 
> --
>   Regards,
>   Shirish Agarwal  शिरीष अग्रवाल
>   My quotes in this email licensed under CC 3.0
> http://creativecommons.org/licenses/by-nc/3.0/
> http://flossexperiences.wordpress.com
> 
> E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#953950: python-twisted: twisted version 14.0.2-3+deb8u1 in jessie (security) is broken

[Emilio Pozuelo Monfort]

Hi,

On 19/03/2020 13:01, Simon McVittie wrote:
> On Thu, 19 Mar 2020 at 12:33:09 +0100, Etienne Allovon wrote:
>> Subject: python-twisted: twisted version 14.0.2-3+deb8u1 in jessie
>> (security) is broken
> 
> Debian 8 'jessie' is no longer supported by the mainstream Debian
> security team

Etienne probably meant that the update comes from jessie-security, which is 
correct.

> or by the maintainers of individual packages. Instead, it

That's not necessarily correct. While many maintainers don't care about LTS,
some others do and they help provide security updates in coordination with the
LTS team.

> is maintained by the Debian LTS subproject. Please contact the debian-lts
> mailing list  if you encounter regressions
> in jessie or jessie-security packages.
> 
> (LTS people: please see the bug for details, and please make sure the
> message is getting out to LTS users that they should be contacting the
> LTS team and not the bug tracking system.)

Actually the bug tracker is a good place to report regressions in LTS, just like
it's fine for stable. reportbug has a feature to Cc the security team or the LTS
list if it detects that the package comes from such a suite. That probably
didn't work here because it was a follow-up to an already opened bug, but in
general I wouldn't see an issue with reporting a bug against the package.

In any case, thanks Etienne for reporting this regression, and thank you Simon
for letting us know.

Cheers,
Emilio

Bug#954295: git: please move diff highlighter out of /doc/ and expose it

[Adam Borowski]

Package: git
Version: 1:2.26.0~rc2-1
Severity: wishlist

Hi!
The main "git" package ships /usr/share/doc/git/contrib/diff-highlight .
Alas, this script is:
1. not configured for use within diff
2. in /usr/share/doc/ which no package is allowed to rely on
3. not exposed for non-git uses

It makes reading patches a lot easier.

I for one use the following wrappers someone once posted:
.--==[ ~/bin/git-hdiff ]
#!/bin/sh

exec git diff --color "$@" | exec hdiff
`
.--==[ ~/bin/hdiff ]
#!/bin/sh

: "${DIFF_HIGHLIGHT:=/usr/share/doc/git/contrib/diff-highlight}"
exec perl -I "$DIFF_HIGHLIGHT" -MDiffHighlight -- 
"$DIFF_HIGHLIGHT/diff-highlight.perl" | exec less -R
`

The former can be used instead of "git diff" as "git hdiff", the latter
is a post-processor for colordiff:
$ debdiff foo_*.dsc|colordiff|hdiff

I think it would be a good idea to make "git diff" default to this tool.

But, because of the /usr/share/doc/ thing, I can't even make a separate
package to use it.


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

Kernel: Linux 5.6.0-rc6-00085-ge6fd0e58416e (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages git depends on:
ii  git-man  1:2.26.0~rc2-1
ii  libc62.30-2
ii  libcurl3-gnutls  7.68.0-1
ii  liberror-perl0.17029-1
ii  libexpat12.2.9-1
ii  libpcre2-8-0 10.34-7
ii  perl 5.30.0-9
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages git recommends:
ii  ca-certificates  20190110
ii  less 551-1
ii  openssh-client [ssh-client]  1:8.2p1-4
ii  patch2.7.6-6

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-10
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
ii  git-email 1:2.26.0~rc2-1
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information

Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts

[Thorsten Glaser]

reassign 954294 libseccomp-dev
found 954294 2.4.3-1
affects 954294 src:systemd
thanks

> Here, SCMP_SYS(mmap) is an unsigned long, probably because that’s
> what the native size type is.

Nevermind, I found the real culprit. SCMP_SYS() is defined to return int.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#954294: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts)

[Thorsten Glaser]

retitle 954294 libseccomp-dev: API break: SCMP_SYS() is unsigned long
tags 954294 + patch
thanks

> Nevermind, I found the real culprit. SCMP_SYS() is defined to return int.

Patch attached. Please apply and upload, and forward this upstream.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**Author: mirabilos 
Description: Fix the return value of SCMP_SYS, it’s documented to be int
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954294

--- a/include/seccomp.h
+++ b/include/seccomp.h
@@ -197,7 +197,7 @@ struct scmp_arg_cmp {
  * Convert a syscall name into the associated syscall number
  * @param x the syscall name
  */
-#define SCMP_SYS(x)		(__SNR_##x)
+#define SCMP_SYS(x)		((int)__SNR_##x)
 
 /* Helpers for the argument comparison macros, DO NOT USE directly */
 #define _SCMP_VA_NUM_ARGS(...)	_SCMP_VA_NUM_ARGS_IMPL(__VA_ARGS__,2,1)
--- a/include/seccomp.h.in
+++ b/include/seccomp.h.in
@@ -209,7 +209,7 @@ struct scmp_arg_cmp {
  * Convert a syscall name into the associated syscall number
  * @param x the syscall name
  */
-#define SCMP_SYS(x)		(__SNR_##x)
+#define SCMP_SYS(x)		((int)__SNR_##x)
 
 /* Helpers for the argument comparison macros, DO NOT USE directly */
 #define _SCMP_VA_NUM_ARGS(...)	_SCMP_VA_NUM_ARGS_IMPL(__VA_ARGS__,2,1)

Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts

[Thorsten Glaser]

Source: systemd
Version: 245.2-1
Severity: important
Tags: upstream ftbfs
Justification: fails to build from source (but built successfully in the past), 
on non-release architecture

https://buildd.debian.org/status/fetch.php?pkg=systemd&arch=x32&ver=245.2-1&stamp=1584573299&raw=0

The failures seem to be in the testsuite (assuming the main code has
been built before it gets build) only. They boil down to multiple
instances of:

../src/test/test-seccomp.c:562:27: error: format ‘%d’ expects argument of type 
‘int’, but argument 8 has type ‘long unsigned int’ [-Werror=format=]
  562 | log_debug("arch %s: SCMP_SYS(mmap) = %d", 
seccomp_arch_to_string(arch), SCMP_SYS(mmap));

Here, SCMP_SYS(mmap) is an unsigned long, probably because that’s
what the native size type is.

If this is an int on other architectures, casting it to int might
be safe, as sizeof(long) == sizeof(int) on x32, but the safer path
would be changing it to long:

log_debug("arch %s: SCMP_SYS(mmap) = %ld", 
seccomp_arch_to_string(arch), (long)SCMP_SYS(mmap));

Similar for all other occurrences of SCMP_SYS, I guess.

Bug#949845: Constant 100% CPU usage by ovs-vswitchd

[Kees Meijs]

Hi Thomas,

Then I'll await your findings while running 2.11 ourselves. If the new
build works well at you end I'll roll out several nodes using that one
for testing.

Apart from 100% CPU usage we didn't have issues, by the way.

K.

On 18-03-2020 19:18, Thomas Goirand wrote:
> I've fixed *one* type of crash, but we saw others, with a different
> backtrace (which I could see using gdb).
>
> We're now upgrading to the version see here:
> http://shade.infomaniak.ch/buster-pu/openvswitch/
>
> This is the top of the 2.10 branch, version is:
> 2.10.4+2020.01.14.b2ccc307f1+dfsg1-1+deb10u3
>
> I don't know yet if it fixes the problem we have ...
>
> I can try to convince the release team to update to that version in
> Buster, but chances they accept is kind of low.
>

Bug#954293: ruby2.7: FTBFS on x32: misdetected as i386 or amd64

[Thorsten Glaser]

Source: ruby2.7
Version: 2.7.0-4
Severity: important
Tags: ftbfs upstream
Justification: fails to build from source on non-release arch

[…]
gcc -I. -I.ext/include/x86_64-linux-gnux32 -I./include -I. 
-I./enc/unicode/12.1.0 -DSYMBOL_PREFIX= -o coroutine/x
86/Context.o -c coroutine/x86/Context.S
coroutine/x86/Context.S: Assembler messages:
coroutine/x86/Context.S:17: Error: invalid instruction suffix for `push'
[…]

The problem lies in the top-level configure.ac:

 2303 AC_ARG_WITH(coroutine,
 2304 AS_HELP_STRING([--with-coroutine=IMPLEMENTATION], [specify the 
coroutine implementation to use]),
 2305 [rb_cv_coroutine=$withval])
 2306 AS_CASE([$rb_cv_coroutine], [yes|''], [
 2307 AC_MSG_CHECKING(native coroutine implementation for 
${target_cpu}-${target_os})
 2308 AS_CASE(["$target_cpu-$target_os"],
[…]
 2312 [x*64-linux*], [
 2313 AS_CASE(["$ac_cv_sizeof_voidp"],
 2314 [8], [ rb_cv_coroutine=amd64 ],
 2315 [4], [ rb_cv_coroutine=x86 ],
 2316 [*], [ rb_cv_coroutine= ]
 2317 )

This basically assumes there are only two x86 architectures.

For x32, the amd64 code might serve as start but won’t work as-is.
I don’t see right now everything that would need to be patched, as
it’s very sparsely commented, so I’d suggest using the generic im‐
plementation, probably ucontext.

This can be achieved by adding a *BEFORE* line 2312:

[x86_64-linux-gnux32], [
rb_cv_coroutine=ucontext
],

Please apply as patch, so we can test this on the buildd, and
forward it upstream when it works.

This is kinda important because libselinux build-depends on this.

https://buildd.debian.org/status/fetch.php?pkg=ruby2.7&arch=x32&ver=2.7.0-4&stamp=1582112521&raw=0
has the complete log of the failed build.

Bug#916693: RFP: mfgtools -- Freescale/NXP I.MX Chip image deploy tools

[Bastian Germann]

Hi Guido,

I had a look at your mfgtools package
(1.2.91+0git6b465-0pureos+librem5.2). Its copyright file only misses
libuuu/sparse_format.h's copyright notice and Apache v2 license.

For the current version 1.3.154 there are new files with 2019 or 2020
copyright year and libuuu/buffer.cpp's copyright date changes to
2018-2019. Also, libssl-dev is introduced as a new build dependency.
Therefore you should relicense the debian/patches (most of them can be
dropped) because GPL-3+ is not compatible with the OpenSSL license.

I would appreciate the package to be in Debian and volunteer to
co-maintain it if you do not want to maintain it alone.

Cheers,
Bastian

Bug#954292: RM: why3-coq [armel armhf i386 mips64el mipsel s390x] -- ROM; why3-coq no longer build on all architectures

[Ralf Treinen]

Package: ftp.debian.org
Severity: normal

Hi, the why3 source package now builds the why3-coq binary package only
on those architectures where coq is available. Please remove why3-coq
version 1.2.1-3 on the indicated architectures as it will block the
migration of why3, coq and its satellites.

Thanks -Ralf.

Bug#954291: libvirt-daemon-system-sysv: upgrading kills VMs

[Thorsten Glaser]

Dixi quod…

> To add insult to injury, it didn’t even shut it down cleanly:
> 
> tglase@tglase:~ $ virsh -c qemu:///system list
>  Id   Name State
> 
>  3MirBSD   in shutdown
> 
> 
> “virsh destroy 3” to the “rescue”…

Oh, it gets worse. Trying to restart the VM after that:

tglase@tglase:~ $ virsh -c qemu:///system start MirBSD
error: Failed to start domain MirBSD
error: internal error: qemu unexpectedly closed the monitor: 
2020-03-19T19:18:11.146627Z qemu-system-x86_64: -device 
ide-hd,bus=ide.0,unit=0,drive=libvirt-1-format,id=ide0-0-0,bootindex=1,write-cache=on:
 Failed to get "write" lock
Is another process using the image [/dev/vg-tglase/mirbsd]?

1|tglase@tglase:~ $ ps ax | fgrep qemu
12262 pts/5S+ 0:00 grep -F qemu
14125 ?Sl   752:48 /usr/bin/qemu-system-x86_64 -enable-kvm -name 
guest=MirBSD,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-MirBSD/master-key.aes
 -machine pc-i440fx-2.5,accel=kvm,usb=off,dump-guest-core=off -m 1024 -realtime 
mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 
b0994f54-15e8-bb58-2f8f-1460fc81ec6b -no-user-config -nodefaults -chardev 
socket,id=charmonitor,fd=27,server,nowait -mon 
chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot 
strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive 
file=/dev/vg-tglase/mirbsd,format=raw,if=none,id=drive-ide0-0-0,cache=none,aio=native
 -device 
ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1,write-cache=on
 -netdev tap,fd=25,id=hostnet0 -device 
e1000,netdev=hostnet0,id=net0,mac=52:54:00:49:f7:4f,bus=pci.0,addr=0x3 -chardev 
pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 
127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -object 
rng-random,id=objrng0,filename=/dev/urandom -device 
virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x5 -sandbox 
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg 
timestamp=on


It’s dead in virt-manager, but connecting via VNC might be
possible — first find out the port…

tglase@tglase:~ $ sudo netstat -anp | fgrep 14125
tcp0  0 127.0.0.1:5900  0.0.0.0:*   LISTEN  
14125/qemu-system-x

… then connect to it:

tglase@tglase-nb:~ $ vncviewer -via tglase ::5900   



Incidentally, at this point, the guest networking was already dead,
but connecting to it allowed me to proceed in shutting it down cleanly,
followed by sudo-killing the qemu process.

Thankfully, after that, starting it worked, and things work again,
including networking.

My initial assertion that it’s not okay to just kill running VMs stands.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#935198: openconnect: New upstream release 8.04 supporting Juniper Pulse Secure protocol

[Luca Boccassi]

Control: tags 935198 pending patch
Control: tags 937197 pending patch

On Tue, 20 Aug 2019 21:55:46 +0200 Adam Cecile 
wrote:
> Package: openconnect
> Version: 8.04-0~bpo10+0
> Severity: wishlist
> Tags: upstream
> 
> Hello,
> 
> Openconnect 8.04 has been released and support the new protocol used
by up-to-
> date Juniper products.
> 
> I built it by myself and it works just fine with no packaging
modification.
> 
> Thanks,
> 
> Adam.

MRs submitted with new upstream version and with a change in B-D to
python3:

https://salsa.debian.org/debian/openconnect/-/merge_requests/6
https://salsa.debian.org/debian/openconnect/-/merge_requests/5
https://salsa.debian.org/debian/openconnect/-/merge_requests/4

-- 
Kind regards,
Luca Boccassi


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

Bug#954291: libvirt-daemon-system-sysv: upgrading kills VMs

[Thorsten Glaser]

Package: libvirt-daemon-system-sysv
Version: 6.0.0-3
Severity: critical
Justification: causes serious data loss

Just a regular dist-upgrade doing this:


Unpacking libvirt-daemon-system-sysv (6.0.0-3) over (6.0.0-1) ...
[…]
Setting up libvirt-daemon-system-sysv (6.0.0-3) ...
Restarting libvirt logging daemon: /usr/sbin/virtlogd.
Restarting libvirt management daemon: /usr/sbin/libvirtd.

Running guests on default URI: MirBSD
Shutting down guests on default URI...
Starting shutdown on guest: MirBSD
Waiting for guest MirBSD to shut down, 300 seconds left
[…]


It’s inacceptable for a regular package upgrade to shut down
any running VMs without warning. The VMs may be necessary, or
might need to be shut down manually (qemu’s guest agent still
doesn’t work without native virtio in the guest even though a
serial (IIRC) control channel is specified), and killing such
a VM will introduce guest filesystem corruption.

At least issue a debconf thing like glibc does when you want
to upgrade from 2.29 to 2.30, which offers me some time to
shut down the VM manually or abort the upgrade.


To add insult to injury, it didn’t even shut it down cleanly:

tglase@tglase:~ $ virsh -c qemu:///system list
 Id   Name State

 3MirBSD   in shutdown


“virsh destroy 3” to the “rescue”…


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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libvirt-daemon-system-sysv depends on:
ii  init-system-helpers  1.57
ii  lsb-base 11.1.0

libvirt-daemon-system-sysv recommends no packages.

libvirt-daemon-system-sysv suggests no packages.

-- no debconf information

Bug#953056: py3compile: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used

[Thorsten Glaser]

Package: python3-minimal
Version: 3.8.2-1
Followup-For: Bug #953056
Control: forcemerge 953056 954250
Control: retitle 953056 py3compile: RuntimeWarning: line buffering 
(buffering=1) isn't supported in binary mode, the default buffer size will be 
used

Easy reproducer:

py3compile -p python3-idna
/usr/lib/python3.8/subprocess.py:838: RuntimeWarning: line buffering 
(buffering=1) isn't supported in binary mode, the default buffer size will be 
used
  self.stdin = io.open(p2cwrite, 'wb', bufsize)

(or any package using py3compile in its postinst)

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages python3-minimal depends on:
ii  dpkg   1.19.7
ii  python3.8-minimal  3.8.2-1

python3-minimal recommends no packages.

python3-minimal suggests no packages.

-- no debconf information

Bug#951979: Anything related to recent patch from Ubuntu?

[Håvard Flaget Aasen]

Hi,

I looked into it, you are correct, it has everything to do with the patch.

Removing 0002-Use-new-CMake-Python-discovery-with-matching-Boost-P.patch
fixes the ftbfs.

I don't know what changed when cmake upgraded from 3.15.4 -> 3.16.3 I
also don't know if this is the best solution, but for now it works. You
might see if it builds against libboost 1.71.0 which is in experimental.

The upstream author might look into this, for this patch is also a
commit upstream [1] and there are other people that probably has the
same issue [2]

I hope this gets it going again, and sorry for the trouble this patch
has created.

Håvard


[1]
https://github.com/mkeeter/antimony/commit/222ae890da81a1eacf5c528598e79a91c4bab58a
[2] https://github.com/mkeeter/antimony/issues/211

Bug#937197: openconnect: Python2 removal in sid/bullseye

[Luca Boccassi]

On Fri, 30 Aug 2019 10:10:32 +0100 David Woodhouse  wrote:
> On Fri, 2019-08-30 at 07:29 +, Matthias Klose wrote:
> > Package: src:openconnect
> > Version: 8.02-1
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org

> > Usertags: py2removal
> > 
> > Python2 becomes end-of-live upstream, and Debian aims to remove
> > Python2 from the distribution, as discussed in
> > https://lists.debian.org/debian-python/2019/07/msg00080.html

> > 
> > Your package either build-depends, depends on Python2, or uses
Python2
> > in the autopkg tests.  Please stop using Python2, and fix this
issue
> > by one of the following actions.
> 
> The OpenConnect 8.03 release converted the documentation processing
to
> use Python 3, which means that Python2 is no longer required to
build.
> I recommend updating. I will be making an 8.05 release in the next
week
> or so.
> 
> The helper script for the Juniper Host Checker system is still Python
> 2; any assistance with converting that would be most welcome. For the
> Fedora build we just removed that script from the binary package to
> eliminate the last Python 2 dependency (which is only runtime
anyway).

Do you have access to a Juniper connection to test it? The 2to3
automated conversion seems pretty simple and straightforward, and it
loads so the syntax should be correct, but I can't really test it in a
meaningful way:

--- a/trojans/tncc-wrapper.py
+++ b/trojans/tncc-wrapper.py
@@ -18,19 +18,19 @@
 
 import subprocess
 import mechanize
-import cookielib
+import http.cookiejar
 import getpass
 import sys
 import os
 import zipfile
-import urllib
+import urllib.request, urllib.parse, urllib.error
 import socket
 import ssl
 import errno
 import argparse
 import atexit
 import signal
-import ConfigParser
+import configparser
 import time
 import binascii
 import hmac
@@ -39,7 +39,7 @@ import hashlib
 def mkdir_p(path):
 try:
 os.mkdir(path)
-except OSError, exc:
+except OSError as exc:
 if exc.errno == errno.EEXIST and os.path.isdir(path):
 pass
 else:
@@ -64,9 +64,9 @@ class Tncc:
 if zipfile.ZipFile(self.tncc_jar, 'r').testzip() is not None:
 raise Exception()
 except:
-print 'Downloading tncc.jar...'
+print('Downloading tncc.jar...')
 mkdir_p(os.path.expanduser('~/.juniper_networks'))
-urllib.urlretrieve('https://' + self.vpn_host
+urllib.request.urlretrieve('https://' + self.vpn_host
+ '/dana-cached/hc/tncc.jar', self.tncc_jar)
 
 with zipfile.ZipFile(self.tncc_jar, 'r') as jar:


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

Bug#954290: kexec doesn't do reboots on systemd install?

[Brian Sammon]

Package: kexec-tools
Version: 1:2.0.20-2

When I do "dpkg-reconfigure kexec-tools" (on armhf), it asks me "Should 
kexec-tools handle reboots (sysvinit only)?"

This suggests to me that kexec-tools will/can not be used to do reboots on a 
systemd install.

Is that correct?

Can systemd support be added?

A note/explanation in README.Debian would be useful if there is a disparity in 
systemd/sysvinit with kexec.

Bug#954192: exim4-config: prdr_enable = true breaks exim4+dkimproxy when using multiple recipients

[noc]

Hi Marc,

On 2020-03-19 08:44, Marc Haber wrote:
> On Wed, Mar 18, 2020 at 06:32:05AM +0100, Niki Hammler wrote:
>> This worked flawlessly until jessie (for me, from 2008 until now). However, 
>> with prdr_enable = true, exim4 hangs when looping back the message when
>> using multiple recipients. It hangs with message:
>>
>>   353 PRDR content analysis beginning
> 
> That happens when dkimproxy re-delivers the message back to exim? What's
> the SMTP dialog before? Does exim advertise PRDR? Does the client
> request it?

Yes, it happens when dkimproxy redelivers it.
However, as I understand dkimproxy, don't think of it as a full-fledged
SMTP server. Once I connect to dkimproxy, it transparently opens back a
connection to exim. So the greeting message comes actually from exim:

mail:~# netstat -anp | grep 10028
tcp0  0 127.0.0.1:10028 0.0.0.0:*
LISTEN  6988/perl
mail:~# ps aux |grep [6]988
dkimpro+  6988  0.0  0.0  22400 16316 ?SMär18   0:00
/usr/bin/perl -I/usr/lib /usr/sbin/dkimproxy.out --domain=nobaq.net
--method=simple --conf_file=/etc/dkimproxy/dkimproxy_out.conf
--keyfile=/var/lib/dkimproxy/private.key --user=dkimproxy
--group=dkimproxy --daemonize --pidfile=/var/run/dkimproxy.out
--signature=dkim --signature=domainkeys --min_servers=5
mail:~# telnet 127.0.0.1 10028
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
220 mail.nobaq.net ESMTP Exim 4.89 Thu, 19 Mar 2020 19:15:45 +0100

dkimproxy only changes the data it passes back and forth between exim.
Since client and server are technically exim, yes, server advertises and
client requests it.

See below:

>> I verified the issue observing the traffic transmitted to dkimproxy while 
>> sending a message to only one recipient:
>>
>> # ngrep -d lo -W byline -q port 10028
>> [...]
>> T 127.0.0.1:10028 -> 127.0.0.1:48486 [AP]
>> 250 OK id=1jEPuw-0005Cq-IJ.
>>
>> T 127.0.0.1:48486 -> 127.0.0.1:10028 [AP]
>> QUIT.
>>
>> T 127.0.0.1:10028 -> 127.0.0.1:48486 [AP]
>> 221 mail.nobaq.net closing connection.
>>
>>
>> All good, just as expected.
>> Now repeating the whole thing while sending the message to TWO recipients:
>>
>> # ngrep -d lo -W byline -q port 10028
>> [...]
>> DATA.
>> [...]
>> T 127.0.0.1:10028 -> 127.0.0.1:48586 [AP]
>> 353 PRDR content analysis beginning.
> 
> The things you have left out would have been interesting.

Ok, here is the full trace. First case, only one recipient:

# ngrep -d lo -W byline -q port 10028
interface: lo (127.0.0.0/255.0.0.0)
filter: (ip or ip6) and ( port 10028 )

T 127.0.0.1:10028 -> 127.0.0.1:48486 [AP]
220 mail.nobaq.net ESMTP Exim 4.89 Wed, 18 Mar 2020 05:02:54 +0100.


T 127.0.0.1:48486 -> 127.0.0.1:10028 [AP]
EHLO mail.nobaq.net.


T 127.0.0.1:10028 -> 127.0.0.1:48486 [AP]
250-mail.nobaq.net Hello localhost [127.0.0.1].
250-SIZE 52428800.
250-8BITMIME.
250-PIPELINING.
250-PRDR.
250 HELP.


T 127.0.0.1:48486 -> 127.0.0.1:10028 [AP]
MAIL FROM: SIZE=3934.
RCPT TO:.
DATA.


T 127.0.0.1:10028 -> 127.0.0.1:48486 [AP]
250 OK.


T 127.0.0.1:10028 -> 127.0.0.1:48486 [AP]
250 Accepted.
354 Enter message, ending with "." on a line by itself.


T 127.0.0.1:48486 -> 127.0.0.1:10028 [AP]
Received: from gate.nobaq.net ([93.83.102.170]:51908
helo=[192.168.200.209]).
.by mail.nobaq.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128).
.(Exim 4.89).
.(envelope-from ).
.id 1jEPut-0005Cg-H8.
.for nhamm...@stanford.edu; Wed, 18 Mar 2020 05:02:54 +0100.
To: nhamm...@stanford.edu.
From: Nikolaus Hammler .
Autocrypt: addr=n...@hammler.net; prefer-encrypt=mutual; keydata=[SNIP]
Message-ID: <06d9bce6-f730-5b70-dfa1-52e4bc9a3...@hammler.net>.
Date: Wed, 18 Mar 2020 00:02:45 -0400.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.24).
 Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.5.0.
MIME-Version: 1.0.
Content-Type: text/plain; charset=utf-8.
Content-Language: en-US.
Content-Transfer-Encoding: 7bit.
X-SA-Exim-Connect-IP: 93.83.102.170.
X-SA-Exim-Mail-From: n...@hammler.net.
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.nobaq.net.
X-Spam-Level: .
X-Spam-Status: No, score=0.1 required=5.0
tests=ALL_TRUSTED,AWL,FSL_BULK_SIG,.
.PYZOR_CHECK,TVD_SPACE_RATIO autolearn=no autolearn_force=no.
.version=3.4.2.
Subject: test1.
X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +).
X-SA-Exim-Scanned: Yes (on mail.nobaq.net).
.
test1.
.
..


T 127.0.0.1:10028 -> 127.0.0.1:48486 [AP]
250 OK id=1jEPuw-0005Cq-IJ.


T 127.0.0.1:48486 -> 127.0.0.1:10028 [AP]
QUIT.


T 127.0.0.1:10028 -> 127.0.0.1:48486 [AP]
221 mail.nobaq.net closing connection.




Second case, having two recipients:


interface: lo (127.0.0.0/255.0.0.0)
filter: (ip or ip6) and ( port 10028 )

T 127.0.0.1:10028 -> 127.0.0.1:48586 [AP]
220 mail.nobaq.net ESMTP Exim 4.89 Wed, 18 Mar 2020 05:05:47 +0100


T 127.0.0.1:48586 -> 127.0.0.1:10028 [AP]
EHLO mail.nobaq.net


T 127.0.0.1:10028 -> 127.0.0.1:48586 [AP]
250-mail.nobaq.net Hello localhost [127.0.0.1]
250-SIZE 52428800
250-8BITMIME

Bug#953950: python-twisted: twisted version 14.0.2-3+deb8u1 in jessie (security) is broken

[Etienne Allovon]

Chris Lamb wrote:


I have just uploaded 14.0.2-3+deb8u2 and DLA-2145-2 will be announced
after sending this email. Thank you again for raising this issue.


Thanks a lot for this quick fix !
I will test it as soon as it'll be available in the repo.

Regards,

Bug#954289: openvpn: Incomplete handling of interrupted credentials prompt with auth-user-pass

[Tomáš Szaniszlo]

Package: openvpn
Version: 2.4.7-1
Severity: normal

It seems that openvpn does not handle SIGINT correctly when in client mode
with option auth-user-pass enabled. If I press ^C when presented with prompt
"Enter Auth Username: ", the terminal settings are not reset to a usable state.

Steps to reproduce:

1. Have a working config.ovpn with option auth-user-pass set
2. # openvpn config.ovpn
3. Press ^C
4. Press Enter (for empty password) and let the authentication fail

Openvpn client terminates and the client does not echo input.

Output of stty from that terminal:

speed 38400 baud; line = 0;
min = 1; time = 0;
-brkint -imaxbel iutf8
-icanon -echo

Output of stty from a new working terminal:

speed 38400 baud; line = 0;
-brkint -imaxbel iutf8



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

Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores)
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 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  iproute2   5.5.0-1
ii  libc6  2.30-2
ii  liblz4-1   1.9.2-2
ii  liblzo2-2  2.10-2
ii  libpam0g   1.3.1-5
ii  libpkcs11-helper1  1.25.1-2
ii  libssl1.1  1.1.1d-2
ii  libsystemd0244.3-1
ii  lsb-base   11.1.0

Versions of packages openvpn recommends:
ii  easy-rsa  3.0.6-1

Versions of packages openvpn suggests:
ii  openssl   1.1.1d-2
pn  openvpn-systemd-resolved  
pn  resolvconf

-- debconf information excluded

Bug#952535: patroni: test failures on arm64 and others

[Michael Banck]

Hi,

Am Dienstag, den 25.02.2020, 13:53 +0100 schrieb Gianfranco Costamagna:
> Source: patroni
> Version: 1.6.3-2
> Severity: serious
> 
> Hello, looks like your package depends on etcd, but that package is
> not working everywhere (even if built, I'll open an RC
> later today)
> 
> Can you please have a look, such as marking the test as flaky,
> restricting on amd64 and ppc64el, 

Did something change here? It seems patroni tested fine on arm64 a while
ago: 
https://ci.debian.net/data/packages/testing/arm64/p/patroni/4139544.log


> or maybe export ETCD_UNSUPPORTED_ARCH on the unsupported
> architectures?

I find it a bit hard to believe that arm64 is really an unsupported arch
for etcd these days?

But anyhow, how do you do that for autopkgtest depends?


Michael
-- 
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax:  +49 2166 9901-100
Email: michael.ba...@credativ.de

credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer

Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz

Bug#954288: transition: re2

[Stefano Rivera]

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

C++. Lots of ABI breakage...

Class members were reorganised, and mutability changed.
Upstream chose to SONAME bump.

https://github.com/google/re2/issues/243

In other news: Upstream is finally taking ownership of their soname \o/

https://release.debian.org/transitions/html/auto-re2.html looks good.

I test built all of the rev-deps (on March 3rd) and they all built,
except for clickhouse (known FTBFS: #950983).

Ben file:

title = "re2";
is_affected = .depends ~ "libre2-5" | .depends ~ "libre2-6";
is_good = .depends ~ "libre2-6";
is_bad = .depends ~ "libre2-5";


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

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

Bug#945623: cfengine3: Python2 removal in sid/bullseye

[Sandro Tosi]

On Wed, 27 Nov 2019 23:58:46 + Sandro Tosi  wrote:
> Source: cfengine3
> Version: 3.12.1-2
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

is the Recommends: python only because of:

masterfiles/modules/packages/zypper:#!/usr/bin/python
masterfiles/modules/packages/apt_get:# First try to run this script
with python3, else run with python
masterfiles/modules/packages/apt_get:command -v python3 >/dev/null
2>/dev/null  \
masterfiles/modules/packages/apt_get:&& exec python3 "$0" "$@" \
masterfiles/modules/packages/apt_get:|| exec python  "$0" "$@"
masterfiles/modules/packages/yum:#!/usr/bin/python

if so, apt_get already tries to use python3 if available, yum doesnt
require any change to work with python3 (according to 2to3) and zypper
only change is:

```
morph@zion:~/deb/tmp/cfengine3-3.12.1$ 2to3 masterfiles/modules/packages/zypper
RefactoringTool: Skipping optional fixer: buffer
RefactoringTool: Skipping optional fixer: idioms
RefactoringTool: Skipping optional fixer: set_literal
RefactoringTool: Skipping optional fixer: ws_comma
RefactoringTool: Refactored masterfiles/modules/packages/zypper
--- masterfiles/modules/packages/zypper (original)
+++ masterfiles/modules/packages/zypper (refactored)
@@ -46,7 +46,7 @@
from distutils.version import StrictVersion

ZYPPER_SUPPORTS_OLDPACKAGE=False
-package_zypper = rpm.TransactionSet().dbMatch('name', "zypper").next()
+package_zypper = next(rpm.TransactionSet().dbMatch('name', "zypper"))
if StrictVersion(package_zypper['version']) >= StrictVersion("1.6.169"):
ZYPPER_SUPPORTS_OLDPACKAGE=True

RefactoringTool: Files that need to be modified:
RefactoringTool: masterfiles/modules/packages/zypper
```

Antonio, could you please take care of fixing these modules to use a
python3 shebang (+ patch) and upload cfengine3 to unstable soon? I can
NMU it if you prefer, let me know.

Regards,
Sandro

Bug#954283: gzip: produces corrupt output files on armv5tel

[Bdale Garbee]

Jörg Mechnich  writes:

>> DEB_CPPFLAGS_MAINT_APPEND := -DUNALIGNED_OK

That was originally meant to only be enabled on amd64 .. I think that
got lost in one of the packaging style updates I accepted a while back.
Just uploaded 1.10-2 hopefully making the architecture-specificity true
again. 

Bdale


signature.asc
Description: PGP signature

Bug#953722: ITP: josm-installer -- Editor for OpenStreetMap (installer)

[Sebastiaan Couwenberg]

On 3/19/20 6:29 PM, Sebastiaan Couwenberg wrote:
> On 3/19/20 6:05 PM, John Scott wrote:
>> does this mean 
>> JOSM will be removed from main? I think that is a substantial trade-off to 
>> provide new backports. Could they both be maintained?
> 
> josm will be removed from main if it cannot be updated to newer tested
> snapshots, keeping it in the archive at an increasingly outdated
> revision makes no sense.
> 
> Because the OSM ecosystem is ever changing backports of the tested
> snapshots are essential for an OSM editor in Debian.
> 
> That's why this package was created, to make it possible for users to
> have a recent OSM editor available in Debian.
> 
> Since this package was created there has been quite a bit of work by the
> JOSM developers to accommodate package in Debian, which may allow us to
> keep the josm package mostly as-is, using the source JAR to get the code
> for the dependencies. If that works out, this ITP will be closed and the
> FTP masters will be asked to REJECT the upload of josm-installer. If it
> doesn't work out, josm-installer will become the best way to have a
> recent JOSM on Debian.

If the source JARs work out to keep josm in Debian, we could also keep
this package as an alternative. By adding an local override for the
josm-installer systemd service it's easy to have it automatically update
the latest builds of JOSM instead of tracking the tested builds we do
for the josm package.

If people want to have both, they should get involved in the maintenance
of the packages.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#954286: RFP: prometheus-redis-exporter -- Prometheus exporter for Redis metrics

[Guillem Jover]

Hi!

On Thu, 2020-03-19 at 18:30:17 +0100, Guillem Jover wrote:
> Package: wnpp
> Severity: wishlist
> Tags: patch
> 
> * Package name: prometheus-redis-exporter
>   Version : 1.4.0

Version : 1.5.2

>   Upstream Author : Oliver
> * URL : https://github.com/oliver006/redis_exporter
> * License : MIT
>   Programming Lang: Go
>   Description : Prometheus exporter for Redis metrics
> 
>  Prometheus exporter for Redis metrics. Supports Redis 2.x, 3.x, 4.x, and 5.x.
> 
> 
> Attached a tested and working packaging (based on the one from the
> prometheus-node-exporter, where Tina agreed to the relicensing to
> match upstream), where only the Uploaders, and ITP bug need to be
> filled, and the packaging imported into git.

Attached an update for the latest upstream which removed the need for
the embedded vendoring. And with few minor packaging improvements.

Thanks,
Guillem


prometheus-redis-exporter_1.5.2-1.debian.tar.xz
Description: application/xz

Bug#525077: gimp stole .ps and .pdf associations in GNOME with lenny->sid upgrade

[Francesco Ariis]

Package: gimp
Version: 2.10.8-2
Followup-For: Bug #525077

Bug is present on Debian Buster (I have no DE)

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
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.10.8-2
ii  libaa1   1.4p5-46
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u1
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgegl-0.4-00.4.12-2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgs9   9.27~dfsg-2+deb10u3
ii  libgtk2.0-0  2.24.32-3
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b2.3.1-1
ii  libheif1 1.3.2-2~deb10u1
ii  libilmbase23 2.2.1-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  liblzma5 5.2.4-1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2.1
ii  libopenexr23 2.2.1-4.1
ii  libopenjp2-7 2.3.0-2+deb10u1
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpangoft2-1.0-01.42.4-7~deb10u1
ii  libpng16-16  1.6.36-6
ii  libpoppler-glib8 0.71.0-5
ii  librsvg2-2   2.44.10-2.1
ii  libstdc++6   8.3.0-6
ii  libtiff5 4.1.0+git191117-2~deb10u1
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libwmf0.2-7  0.2.8.4-14
ii  libx11-6 2:1.6.7-1
ii  libxcursor1  1:1.1.15-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages gimp recommends:
ii  ghostscript  9.27~dfsg-2+deb10u3

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
pn  gimp-python   
pn  gvfs-backends 
ii  libasound21.1.8-1

-- no debconf information

Bug#954287: libfiu: FTBFS on amd64/unstable: Segmentation fault (core dumped)

[Chris Lamb]

Source: libfiu
Version: 1.00-6
Severity: serious
Justification: fails to build from source
X-Debbugs-CC: albert...@blitiri.com.ar

Hi,

libfiu now fails to build from source in unstable/amd64:

  […]

  ./wrap-python 3 ./test-set_prng_seed.py
  LD_LIBRARY_PATH=../../libfiu/ 
LD_PRELOAD="../../preload/run/fiu_run_preload.so 
../../preload/posix/fiu_posix_preload.so" ./tests/open.bin
  LD_LIBRARY_PATH=../../libfiu/ 
LD_PRELOAD="../../preload/run/fiu_run_preload.so 
../../preload/posix/fiu_posix_preload.so" ./tests/fread.bin
  rm tests/open.bin tests/fread.bin./wrap-python 3 ./test-fiu_ctrl.py
   tests/open64.bin tests/strdup.bin tests/pread.bin tests/pread64.bin 
tests/malloc.bin./wrap-python 3 ./test-basic.py
   tests/mmap.bin tests/fprintf.bin tests/kill.bin tests/fopen.bin
  make[4]: Leaving directory '/tmp/buildd/libfiu-1.00/tests/generated'
  ./wrap-python 3 ./test-onetime.py
  ./wrap-python 3 ./test-set_prng_seed-env.py
  make[3]: *** [Makefile:96: py-run-test-failinfo_refcount] Segmentation fault 
(core dumped)
  make[3]: *** Waiting for unfinished jobs
  make[4]: Leaving directory '/tmp/buildd/libfiu-1.00/tests/utils'
  rm test-enable_stack test-ferror test-enable_stack_by_name
  make[3]: Leaving directory '/tmp/buildd/libfiu-1.00/tests'
  make[2]: *** [Makefile:58: test] Error 2
  make[2]: Leaving directory '/tmp/buildd/libfiu-1.00'
  dh_auto_test: error: make -j9 test V=1 LC_ALL=C returned exit code 2
  make[1]: *** [debian/rules:33: override_dh_auto_test] Error 25
  make[1]: Leaving directory '/tmp/buildd/libfiu-1.00'
  make: *** [debian/rules:13: binary] Error 2
  dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

  […]

I suspect this to be Python 3.8 related. Alberto, any ideas? :)  The
full build log is attached if it helps.


Regards,

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


libfiu.1.00-6.unstable.amd64.log.txt.gz
Description: Binary data

Bug#953971: Please add at-spi2-core to the build-dependencies so the tests on hurd-i386 can succeed

[Samuel Thibault]

Laurent Bigonville, le jeu. 19 mars 2020 18:39:46 +0100, a ecrit:
> Le 16/03/20 à 08:38, Guido Günther a écrit :
> > Dear hurd maintainers,
> > On Sun, Mar 15, 2020 at 09:05:54AM +0100, Laurent Bigonville wrote:
> > > Source: libhandy
> > > Version: 0.0.12-1
> > > Severity: normal
> > > 
> > > Hi,
> > > 
> > > It seems that currently libhandy FTBFS on hurd-i386.
> > > 
> > > Adding "at-spi2-core [hurd-i386] " to the build-dependencies
> > > fixes the problem
> > Do you have an idea why this does not happen on other platforms? We
> > don't pull in at-spi2-core there either. Build log is here:
> > 
> >
> > https://buildd.debian.org/status/fetch.php?pkg=libhandy&arch=hurd-i386&ver=0.0.13-1&stamp=1584192605&raw=0
> 
> Not too sure TBH
> 
> An other option might be to pass NO_AT_BRIDGE=1 as environment variable,
> that /should/ disable the need of at-spi completely

I forgot to comment: I tried building with pbuilder, it went fine both
with and without at-spi2-core. Laurent, did you cross-check that without
at-spi2-core you get the build failure? Possibly the buildds have a
different environment that makes the build somehow fail.

Samuel

Bug#885813: bumping severity of xfce4-notes-plugin's use of libunique to Serious

[Andreas Henriksson]

Hi,

On Wed, Oct 09, 2019 at 05:34:16PM +0200, Yves-Alexis Perez wrote:
> Hi, thanks for the update. It seems that the GTK3 port isn't really complete.
> And it seems notes isn't really maintained upstream anymore. I'm adding Mike
> to the CC but we might end up completely dropping xfce4-notes-plugin from
> Debian in the end.

There doesn't seem to have been any movement since your comment on the
upstream bug report. The xfce4-notes-plugin is now the only remaining
package in unstable that still depends on libunique, so it looks to me
like it might be time to make the final call on this. What do you think?
I'd really like to finally be able to remove libunique.

If your decision is we need to drop xfce4-notes-plugin then it seems
xfce4-goodies metapackage will need its dependency removed, then we can
request the other removals!

I'm happy to send salsa merge-request and/or do NMU if you are busy.

Regards,
Andreas Henriksson

Bug#953971: Please add at-spi2-core to the build-dependencies so the tests on hurd-i386 can succeed

[Laurent Bigonville]

Le 16/03/20 à 08:38, Guido Günther a écrit :

Dear hurd maintainers,
On Sun, Mar 15, 2020 at 09:05:54AM +0100, Laurent Bigonville wrote:

Source: libhandy
Version: 0.0.12-1
Severity: normal

Hi,

It seems that currently libhandy FTBFS on hurd-i386.

Adding "at-spi2-core [hurd-i386] " to the build-dependencies
fixes the problem

Do you have an idea why this does not happen on other platforms? We
don't pull in at-spi2-core there either. Build log is here:

   
https://buildd.debian.org/status/fetch.php?pkg=libhandy&arch=hurd-i386&ver=0.0.13-1&stamp=1584192605&raw=0


Not too sure TBH

An other option might be to pass NO_AT_BRIDGE=1 as environment variable, 
that /should/ disable the need of at-spi completely

Bug#954286: RFP: prometheus-redis-exporter -- Prometheus exporter for Redis metrics

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: prometheus-redis-exporter
  Version : 1.4.0
  Upstream Author : Oliver
* URL : https://github.com/oliver006/redis_exporter
* License : MIT
  Programming Lang: Go
  Description : Prometheus exporter for Redis metrics

 Prometheus exporter for Redis metrics. Supports Redis 2.x, 3.x, 4.x, and 5.x.


Attached a tested and working packaging (based on the one from the
prometheus-node-exporter, where Tina agreed to the relicensing to
match upstream), where only the Uploaders, and ITP bug need to be
filled, and the packaging imported into git.

Thanks,
Guillem


prometheus-redis-exporter_1.4.0-1.debian.tar.xz
Description: application/xz

Bug#953722: ITP: josm-installer -- Editor for OpenStreetMap (installer)

[Sebastiaan Couwenberg]

On 3/19/20 6:05 PM, John Scott wrote:
>> The package will be maintained with in the Debian GIS team where it will
>> eventually replace the josm package.
> 
> Because this package will need to go in contrib or non-free,

It's going to contrib.

> does this mean 
> JOSM will be removed from main? I think that is a substantial trade-off to 
> provide new backports. Could they both be maintained?

josm will be removed from main if it cannot be updated to newer tested
snapshots, keeping it in the archive at an increasingly outdated
revision makes no sense.

Because the OSM ecosystem is ever changing backports of the tested
snapshots are essential for an OSM editor in Debian.

That's why this package was created, to make it possible for users to
have a recent OSM editor available in Debian.

Since this package was created there has been quite a bit of work by the
JOSM developers to accommodate package in Debian, which may allow us to
keep the josm package mostly as-is, using the source JAR to get the code
for the dependencies. If that works out, this ITP will be closed and the
FTP masters will be asked to REJECT the upload of josm-installer. If it
doesn't work out, josm-installer will become the best way to have a
recent JOSM on Debian.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#954285: Updating prometheus-node-exporter to bullseye leaves dangling symlinks

[Stefan Bühler]

Package: prometheus-node-exporter
Version: 0.18.1+ds-2

Hi,

after updating prometheus-node-exporter I get these dangling symlinks:

lrwxrwxrwx 1 root root 54 Jul 31  2019 
/etc/systemd/system/timers.target.wants/prometheus-node-exporter-apt.timer -> 
/lib/systemd/system/prometheus-node-exporter-apt.timer
lrwxrwxrwx 1 root root 66 Jul 31  2019 
/etc/systemd/system/timers.target.wants/prometheus-node-exporter-ipmitool-sensor.timer
 -> /lib/systemd/system/prometheus-node-exporter-ipmitool-sensor.timer
lrwxrwxrwx 1 root root 68 Jul 31  2019 
/etc/systemd/system/timers.target.wants/prometheus-node-exporter-mellanox-hca-temp.timer
 -> /lib/systemd/system/prometheus-node-exporter-mellanox-hca-temp.timer
lrwxrwxrwx 1 root root 59 Jul 31  2019 
/etc/systemd/system/timers.target.wants/prometheus-node-exporter-smartmon.timer 
-> /lib/systemd/system/prometheus-node-exporter-smartmon.timer

Maybe you can somehow "properly" remove the systemd unit files in a way 
that also disables them first?

cheers,
Stefan

Bug#953950: python-twisted: twisted version 14.0.2-3+deb8u1 in jessie (security) is broken

[Chris Lamb]

Chris Lamb wrote:

> I will take charge of fixing this in jessie with the utmost urgency.

I have just uploaded 14.0.2-3+deb8u2 and DLA-2145-2 will be announced
after sending this email. Thank you again for raising this issue.


Best wishes,

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

Bug#953722: ITP: josm-installer -- Editor for OpenStreetMap (installer)

[John Scott]

> The package will be maintained with in the Debian GIS team where it will
> eventually replace the josm package.

Because this package will need to go in contrib or non-free, does this mean 
JOSM will be removed from main? I think that is a substantial trade-off to 
provide new backports. Could they both be maintained?


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

Bug#953789: merge request

[dann frazier]

fyi, I've submitted a merge proposal for these 2 issues:
  https://salsa.debian.org/hpc-team/mstflint/-/merge_requests/1

Bug#954284: puppet broken with ruby 2.7

[Laurent Bigonville]

severity 954284 serious
Thanks

On Thu, 19 Mar 2020 17:51:32 +0100 Laurent Bigonville  
wrote:



> Hello,
>
> With ruby 2.7 upload, when running the puppet cli, I get the following
> warning/error:
>
> /usr/lib/ruby/vendor_ruby/puppet/util.rb:461: warning: URI.escape is 
obsolete

> cannot load such file -- sync
>
> puppet returns a non-zero exit code
>

OK the puppet package "only" lacks of a dependency on ruby-sync gem

Bug#954284: puppet broken with ruby 2.7

[Laurent Bigonville]

Package: puppet
Version: 5.5.10-4
Severity: grave

Hello,

With ruby 2.7 upload, when running the puppet cli, I get the following
warning/error:

/usr/lib/ruby/vendor_ruby/puppet/util.rb:461: warning: URI.escape is obsolete
cannot load such file -- sync

puppet returns a non-zero exit code

Kind regards,

Laurent Bigonville

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages puppet depends on:
ii  adduser  3.118
ii  facter   3.11.0-3+b1
ii  hiera3.2.0-2
ii  init-system-helpers  1.57
ii  lsb-base 11.1.0
ii  ruby 1:2.7
ii  ruby-augeas  1:0.5.0-3+b7
ii  ruby-deep-merge  1.1.1-1
ii  ruby-shadow  2.5.0-1+b2

Versions of packages puppet recommends:
ii  debconf-utils  1.5.73
ii  lsb-release11.1.0
pn  ruby-selinux   

Versions of packages puppet suggests:
pn  ruby-hocon  
pn  ruby-rrd

-- no debconf information

Bug#954283: gzip: produces corrupt output files on armv5tel

[Jörg Mechnich]

Package: gzip
Version: 1.10-1
Severity: critical
Justification: causes serious data loss

Dear Maintainer,

the stock package from testing provides a broken gzip binary which will produce
corrupt output that fails CRC checks. Compiling the plain 1.10 sources generates
a working gzip binary.

The issue seems to be caused by

> DEB_CPPFLAGS_MAINT_APPEND := -DUNALIGNED_OK

in debian/rules. After commenting the line and rebuilding the package properly,
gzip works as expected. gzip-1.9-3 from stable obviously works as well.

Please let me know if I can assist in any way during the resolution of this 
issue.

Cheers,
Jörg

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (100, 'unstable')
Architecture: armel (armv5tel)

Kernel: Linux 5.4.0-4-marvell
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gzip depends on:
ii  dpkg  1.19.7
ii  install-info  6.7.0.dfsg.2-5
ii  libc6 2.30-2

gzip recommends no packages.

Versions of packages gzip suggests:
ii  less  551-1

-- no debconf information

Bug#954134: [d-i bullseye alpha2] installing grub fails

[Steve McIntyre]

On Thu, Mar 19, 2020 at 11:16:19AM +, Steve McIntyre wrote:
>On Thu, Mar 19, 2020 at 09:26:25AM +0100, Holger Wansing wrote:
>>Hi,
>>
>>Steve McIntyre  wrote:
>>> One silly question: what media are you using with the Thinkpad? Is it
>>> the same USB stick (or whatever) every time? Can you verify it's
>>> written OK?
>>
>>I used the same USB stick for alpha1 and alpha2, re-flashing it over and
>>over again.
>>And I have checked installation media integrity with alpha2, it reports
>>no error, "image is valid".
>
>Hmmm, OK. Wondering what's causing this then. I'll try another
>installation test on a physical machine and get back to you.

And that worked flawlessly - BIOS boot, installed on a Thinkpad X220
using very similar filesystem setup to yours.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
There's no sensation to compare with this
Suspended animation, A state of bliss

Bug#952615: hinge: FTBFS: fmt.h:22:10: fatal error: spdlog/fmt/bundled/core.h: No such file or directory

[Gilles Filippini]

Control: tag -1 + patch

Hi,

On Wed, 26 Feb 2020 17:09:48 +0100 Lucas Nussbaum  *wrote:
> Source: hinge
> Version: 0.5.0-5
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200225 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> This rebuild was done by building only architecture:any binary packages
> (binary-arch target of debian/rules).
> 
> Relevant part (hopefully):
> > cd /<>/obj-x86_64-linux-gnu/bin/maximal && /usr/bin/c++   
> > -I/<>/src/include  -g -O2 
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -std=gnu++11 
> > -fopenmp   -o CMakeFiles/get_maximal_reads.dir/maximal.cpp.o -c 
> > /<>/src/maximal/maximal.cpp
> > In file included from /usr/include/spdlog/common.h:38,
> >  from /usr/include/spdlog/spdlog.h:12,
> >  from /<>/src/consensus/draft.cpp:14:
> > /usr/include/spdlog/fmt/fmt.h:22:10: fatal error: 
> > spdlog/fmt/bundled/core.h: No such file or directory
> >22 | #include 
> >   |  ^~~
> > compilation terminated.
> > make[3]: *** [bin/consensus/CMakeFiles/draft_assembly.dir/build.make:66: 
> > bin/consensus/CMakeFiles/draft_assembly.dir/draft.cpp.o] Error 1

Patch proposal attached.

Thanks,

_g.
diff -Nru hinge-0.5.0/debian/changelog hinge-0.5.0/debian/changelog
--- hinge-0.5.0/debian/changelog2019-12-06 16:12:32.0 +0100
+++ hinge-0.5.0/debian/changelog2020-03-19 17:07:48.0 +0100
@@ -1,3 +1,10 @@
+hinge (0.5.0-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS against spdlog 1.5.0 (closes: #952615)
+
+ -- Gilles Filippini   Thu, 19 Mar 2020 17:07:48 +0100
+
 hinge (0.5.0-5) unstable; urgency=medium
 
   * Afif removed himself from Uploaders
diff -Nru hinge-0.5.0/debian/patches/series hinge-0.5.0/debian/patches/series
--- hinge-0.5.0/debian/patches/series   2019-12-06 16:12:32.0 +0100
+++ hinge-0.5.0/debian/patches/series   2020-03-19 17:07:48.0 +0100
@@ -2,3 +2,4 @@
 libspdlog-14.0.patch
 libspdlog-1:1.3.0
 2to3.patch
+spdlog-1.5.0.patch
diff -Nru hinge-0.5.0/debian/patches/spdlog-1.5.0.patch 
hinge-0.5.0/debian/patches/spdlog-1.5.0.patch
--- hinge-0.5.0/debian/patches/spdlog-1.5.0.patch   1970-01-01 
01:00:00.0 +0100
+++ hinge-0.5.0/debian/patches/spdlog-1.5.0.patch   2020-03-19 
17:07:48.0 +0100
@@ -0,0 +1,57 @@
+Index: hinge-0.5.0/src/consensus/CMakeLists.txt
+===
+--- hinge-0.5.0.orig/src/consensus/CMakeLists.txt
 hinge-0.5.0/src/consensus/CMakeLists.txt
+@@ -1,9 +1,10 @@
+ cmake_minimum_required(VERSION 3.2)
+ 
++add_definitions(-DSPDLOG_FMT_EXTERNAL)
+ add_executable(draft_assembly draft)
+-target_link_libraries(draft_assembly LAInterface ini falcon )
++target_link_libraries(draft_assembly fmt LAInterface ini falcon )
+ 
+ add_executable(consensus consensus.cpp)
+-target_link_libraries(consensus LAInterface falcon ini)
++target_link_libraries(consensus fmt LAInterface falcon ini)
+ 
+ install(TARGETS draft_assembly consensus DESTINATION ${libexec})
+Index: hinge-0.5.0/src/filter/CMakeLists.txt
+===
+--- hinge-0.5.0.orig/src/filter/CMakeLists.txt
 hinge-0.5.0/src/filter/CMakeLists.txt
+@@ -1,6 +1,7 @@
+ cmake_minimum_required(VERSION 3.2)
+ 
++add_definitions(-DSPDLOG_FMT_EXTERNAL)
+ add_executable(Reads_filter filter)
+-target_link_libraries(Reads_filter LAInterface ini )
++target_link_libraries(Reads_filter fmt LAInterface ini )
+ 
+ install(TARGETS Reads_filter DESTINATION ${libexec})
+Index: hinge-0.5.0/src/layout/CMakeLists.txt
+===
+--- hinge-0.5.0.orig/src/layout/CMakeLists.txt
 hinge-0.5.0/src/layout/CMakeLists.txt
+@@ -5,7 +5,8 @@ set(Boost_USE_STATIC_LIBS   ON)
+ FIND_PACKAGE( Boost COMPONENTS graph REQUIRED )
+ INCLUDE_DIRECTORIES( ${Boost_INCLUDE_DIR} )
+ 
++add_definitions(-DSPDLOG_FMT_EXTERNAL)
+ add_executable(hinging hinging)
+-target_link_libraries(hinging LAInterface ini  ${Boost_LIBRARIES})
++target_link_libraries(hinging fmt LAInterface ini  ${Boost_LIBRARIES})
+ 
+ install(TARGETS hinging DESTINATION ${libexec})
+Index: hinge-0.5.0/src/maximal/CMakeLists.txt
+===
+--- hinge-0.5.0.orig/src/maximal/CMakeLists.txt
 hinge-0.5.0/src/maximal/CMakeLists.txt
+@@ -1,6 +1,7 @@
+ cmake_minimum_required(VERSION 3.2)
+ 
++add_definitions(-DSPDLOG_FMT_EXTERNAL)
+ add_executable(get_maximal_reads maximal)
+-target_link_libraries(get_maximal_reads LAInterface ini )
++target_link_libraries(get_maximal_reads fmt LAInterface ini )
+ 
+ install(TARGETS get_maximal_reads DESTINATION ${libexec})


signature.asc
Description: OpenPGP digital signature

Bug#939271: python3-tornado: tornado 6 required for pcs

[Enrico Zini]

On Mon, Sep 02, 2019 at 07:45:18PM +0200, Valentin Vidić wrote:

> Please upload a new version of the tornado library to unstable
> because the new release of pcs now requires tornado 6.

It was uploaded, it was rolled back waiting for reverse dependencies to
follow.

What were the reverse dependencies and/or their bugs blocking this?


Enrico

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

Bug#954234: /etc/init.d/munin has two broken function definitions

[devel]

Hello Craig,

Thank you for your report!


Am Thu, 19 Mar 2020 14:14:42 +1100
schrieb Craig Sanders :

> Package: munin
> Version: 2.0.57-1
> 
> At the bottom of the /etc/init.d/munin script are two lines:
> 
> do_stop_cmd_override() true
> do_start_cmd_override() true
> 
> This is **NOT** how you define a shell function.

indeed - how embarrassing :(
(but see below for details)


> Without this patch (attached), upgrading munin to 2.0.57-1 leaves the package
> in a broken (installed/Failed-config, or "iF") state and results in the
> following:
> [..]

I am very confused, that this did not fail during munin's autopkgtest (or on my
system).
After digging around for a while (including successful fresh installations or
upgrades on systemd-based hosts), I think I found the issue:

  $ dash -c "foo() true"; echo $?
  0
  $ bash -c "foo() true"; echo $?
  bash: -c: line 0: syntax error near unexpected token `true'
  bash: -c: line 0: `foo() true'
  1

After taking a closer look at the man pages of both shell implementations, this
seems to be in line with their respective documentations:

1) dash
Syntax: name () command
Thus *any* command is allowed (including "true").

2) bash
Syntax: name () compound-command
Here "compound-command" means any non-trivial command, e.g. surrounded by
braces or "if ...; fi" and so on. A single command ("true") is not explicitly
mentioned and obviously is rejected.


Thus I assume, that you are using bash as your "sh" implementation?


I will fix this issue in the next packaging update. Thank you!

Cheers,
Lars

Bug#932617: any update on this as I still got it today with the update (again)

[shirish शिरीष]

Hi all,

See -

$ adequate fwupd
fwupd: obsolete-conffile /etc/dbus-1/system.d/org.freedesktop.fwupd.conf
fwupd: obsolete-conffile /etc/fwupd/remotes.d/fwupd.conf

I wanna try fwupd but once the above obsolete conffiles are removed. I
do know it's a work in progress but still. FWIW, the package got
updated to 1.3.9.2

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#919134: Python and PIE

[Giovanni Pellerano]

Hello Doko,

is there any update on this issue?

Thank you for your attention,

best,

Giovanni Pellerano

Il giorno mer 20 nov 2019 alle ore 18:45 Giovanni Pellerano
 ha scritto:
>
> Hello all,
>
> I've performed some benchmarks following the instructions provided by
> Michele 
> (https://github.com/freedomofpress/securedrop/issues/1861#issuecomment-554035468).
>
> Please find attached the results.
>
> From my tests its seems to not exist any particular performance loss;
> actually some tests results in a gain.
>
> please let me know if there is something else I could support
> retesting to possibly speed up the progress on the integration of the
> proposed patch.
>
> Best,
>
> Giovanni
>
> Il giorno sab 9 nov 2019 alle ore 18:19 Michele Orrù
>  ha scritto:
> >>
> >> seriously?  For a few months you are writing emails without subject 
> >> landing in
> >> my spam folder, and then you are starting threats?
> >
> >
> > Hi Doko,
> >
> > as I wrote privately immediately after:
> >
> >> reading back my email it sounds a lot like a threat.
> >> When I wrote the email I was just thinking that I should give a heads up 
> >> because it's been now more than one month and I don't know what else to do 
> >> besides asking other dd.
> >>
> >> So, please forgive the tone in my previous email Matthias.
> >
> >
> > I'm not trying to threaten you, I just want to help you out improve debian, 
> > and from my (naïve) perspective reaching out to other DD was the logical 
> > solution for no answer.
> >
> > That said, I'm sorry for the subject line. I'm relatively new here: I 
> > didn't know if my b.d.o email will be processed adding the issue number in 
> > the subject, and I didn't know if the subject will be embedded in the 
> > message and cause confusion. Besides email to b.d.o:
> > - I tried to reach out to you on irc, over public channels and in private;
> > - people tried to reach out to you via ubuntu bug tracker: 
> > https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1452115.
> >  Perhaps you can give me some slack, and we can all move on? Holger already 
> > told me that was stupid.
> >
> > Now that this bug has come to your attention again:
> >
> >> I also doubt very much your numbers, 2.5 - 5 times slower is not expected. 
> >> PIE
> >> has some impact, but not that bad.
> >
> >
> > Even before measuring performance loss (which could be due to intel turbo 
> > being active on my machine for a start, and I'm happy to test again so that 
> > you can double-check my steps), do you think performances are crucial for 
> > enabling PIE on /usr/bin/python3?
> >
> > If not, would you mind if I try to help out updating the package? It's a 
> > relatively easy issue and I could learn something about packaging in the 
> > process.
> > If yes, could you please explain to me how this is different from python2?
> >
> > Apologising again,
> > --
> > μ.
>
>
>
> --
> Ing. Giovanni Pellerano - Founding Member and CTO
> giovanni.peller...@hermescenter.org | +39.328.9590046
>
> HERMES - Center for Transparency and Digital Human Rights
> Associazione No Profit | Via Aretusa 34, IT-20129 Milan, Italy
> t. +39-02-87186005 (voicemail) | f. +39-02-87162573
> TaxCode: IT-97621810155 | EuropeAid: IT-2012-AOD-0806909254
> w. https://www.hermescenter.org | m. i...@hermescenter.org



-- 
Ing. Giovanni Pellerano - Founding Member and CTO
giovanni.peller...@hermescenter.org | +39.328.9590046

HERMES - Center for Transparency and Digital Human Rights
Associazione No Profit | Via Aretusa 34, IT-20129 Milan, Italy
t. +39-02-87186005 (voicemail) | f. +39-02-87162573
TaxCode: IT-97621810155 | EuropeAid: IT-2012-AOD-0806909254
w. https://www.hermescenter.org | m. i...@hermescenter.org