Bug#978503: etsf-io: uscan fails due to gone download page

[Andrius Merkys]

Source: etsf-io
Version: 1.0.4-5
Severity: normal

Old download page of etsf-io is now gone [1], as etsf-io seems to have
switched to GitHub [2]. However, the releases are not tagged there, thus
fetching tarballs with meaningful version numbers is impossible for the
time being. I have opened an issue requesting to tag releases [3].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978414
[2] https://github.com/ElectronicStructureLibrary/libetsf_io
[3] https://github.com/ElectronicStructureLibrary/libetsf_io/issues/1

Andrius

Bug#977960: [Pkg-javascript-devel] Bug#977960: dangling /usr/share/javascript/jquery/jquery.js symlink

[Xavier]

Le 27/12/2020 à 19:04, Thorsten Glaser a écrit :
> Package: node-jquery
> Version: 3.5.1+dfsg+~3.5.5-3
> Followup-For: Bug #977960
> X-Debbugs-Cc: t...@mirbsd.de
> 
> Even for the latest versions of these packages, adequate reports:
> 
> node-jquery: broken-symlink /usr/share/nodejs/jquery/dist/jquery.js -> 
> ../../nodejs/jquery/dist/jquery.js
> node-jquery: broken-symlink /usr/share/nodejs/jquery/dist/jquery.min.js -> 
> ../../nodejs/jquery/dist/jquery.min.js
> node-jquery: broken-symlink 
> /usr/share/nodejs/jquery/dist/jquery.min.js.brotli -> 
> ../../nodejs/jquery/dist/jquery.min.js.brotli
> node-jquery: broken-symlink /usr/share/nodejs/jquery/dist/jquery.min.js.gz -> 
> ../../nodejs/jquery/dist/jquery.min.js.gz
> node-jquery: broken-symlink /usr/share/nodejs/jquery/dist/jquery.min.map -> 
> ../../nodejs/jquery/dist/jquery.min.map
> node-jquery: broken-symlink 
> /usr/share/nodejs/jquery/dist/jquery.min.map.brotli -> 
> ../../nodejs/jquery/dist/jquery.min.map.brotli
> node-jquery: broken-symlink /usr/share/nodejs/jquery/dist/jquery.min.map.gz 
> -> ../../nodejs/jquery/dist/jquery.min.map.gz
> libjs-jquery: broken-symlink /usr/share/javascript/jquery/jquery.js -> 
> ../../nodejs/jquery/dist/jquery.js
> libjs-jquery: broken-symlink /usr/share/javascript/jquery/jquery.min.js -> 
> ../../nodejs/jquery/dist/jquery.min.js
> libjs-jquery: broken-symlink 
> /usr/share/javascript/jquery/jquery.min.js.brotli -> 
> ../../nodejs/jquery/dist/jquery.min.js.brotli
> libjs-jquery: broken-symlink /usr/share/javascript/jquery/jquery.min.js.gz -> 
> ../../nodejs/jquery/dist/jquery.min.js.gz
> libjs-jquery: broken-symlink /usr/share/javascript/jquery/jquery.min.map -> 
> ../../nodejs/jquery/dist/jquery.min.map
> libjs-jquery: broken-symlink 
> /usr/share/javascript/jquery/jquery.min.map.brotli -> 
> ../../nodejs/jquery/dist/jquery.min.map.brotli
> libjs-jquery: broken-symlink /usr/share/javascript/jquery/jquery.min.map.gz 
> -> ../../nodejs/jquery/dist/jquery.min.map.gz
> 
> And indeed, these are circular:
> 
> $ ls -la /usr/share/nodejs/jquery/dist /usr/share/javascript/jquery
> lrwxrwxrwx 1 root root   29 May  6  2020 /usr/share/javascript/jquery -> 
> /usr/share/nodejs/jquery/dist
> 
> /usr/share/nodejs/jquery/dist:
> total 8
> drwxr-xr-x 2 root root 4096 Dec 27 18:57 .
> drwxr-xr-x 3 root root 4096 Dec 27 18:57 ..
> lrwxrwxrwx 1 root root   34 Dec 24 14:20 jquery.js -> 
> ../../nodejs/jquery/dist/jquery.js
> lrwxrwxrwx 1 root root   38 Dec 24 14:20 jquery.min.js -> 
> ../../nodejs/jquery/dist/jquery.min.js
> lrwxrwxrwx 1 root root   45 Dec 24 14:20 jquery.min.js.brotli -> 
> ../../nodejs/jquery/dist/jquery.min.js.brotli
> lrwxrwxrwx 1 root root   41 Dec 24 14:20 jquery.min.js.gz -> 
> ../../nodejs/jquery/dist/jquery.min.js.gz
> lrwxrwxrwx 1 root root   39 Dec 24 14:20 jquery.min.map -> 
> ../../nodejs/jquery/dist/jquery.min.map
> lrwxrwxrwx 1 root root   46 Dec 24 14:20 jquery.min.map.brotli -> 
> ../../nodejs/jquery/dist/jquery.min.map.brotli
> lrwxrwxrwx 1 root root   42 Dec 24 14:20 jquery.min.map.gz -> 
> ../../nodejs/jquery/dist/jquery.min.map.gz

I'm still unable to reproduce this and didn't receive help from anyone,
even if I'm not the author of this breakage.
Anyway, I removed all links from libjs-jquery (3.5.1+dfsg+~3.5.5-4). If
you consider that the bug is fixed, please close it, else let's wait for
someone smarter than me to step in.

Bug#977293: Read .xlsx from stdin, write .csv to stdout

[Sébastien Hinderer]

Thanks a lot, Andrius.

Yes, I saw that the problem was the (non-)seakability of the file. Not
sure why this is needed, though.

And thanks a lot for having linked the bug report with the upstream
issue!

Sébastien.

Bug#977293: Read .xlsx from stdin, write .csv to stdout

[Andrius Merkys]

reopen 977293
forwarded https://github.com/dilshod/xlsx2csv/issues/213
thanks

Dear Sébastien,

On 2020-12-27 18:16, Sébastien Hinderer wrote:
> Andrius Merkys (2020/12/14 08:16 +0200):
>> Have you tried using /dev/stdin and /dev/stdout on the command line?
>> This usually does the trick for commands not accepting '-'.
> I tried finally and it does not work. It produces the following error:
>
> Traceback (most recent call last):
>   File "/usr/bin/xlsx2csv", line 1129, in 
> xlsx2csv.convert(outfile, sheetid)
>   File "/usr/bin/xlsx2csv", line 216, in convert
> self._convert(sheetid, outfile)
>   File "/usr/bin/xlsx2csv", line 266, in _convert
> outfile = open(outfile, 'w+', encoding=self.options['outputencoding'], 
> newline="")
> io.UnsupportedOperation: File or stream is not seekable.

It seems that xlsx2csv requires seekable files/streams. Then /dev/stdout
cannot be used, alas. Talking to upstream is the right course of action.

> Bug reported upstream at https://github.com/dilshod/xlsx2csv/issues/213
>
> I did try to add the Forwarded: pseudo-header, I hope it worked.

Thanks for reporting this upstream! Forwarded: pseudo-header works only
for new bug reports, for existing ones you have to use the control
server [1]. I have reopened the bug and added forward address on the top
three lines of this e-mail.

[1] https://www.debian.org/Bugs/server-control

Best,
Andrius

Bug#971170: Acknowledgement (sddm: Lots of errors: TypeError: Cannot read property)

[Helge Kreutzmann]

Hello Norbert,
On Mon, Dec 28, 2020 at 03:21:34PM +0900, Norbert Preining wrote:
> On Mon, 28 Dec 2020, Helge Kreutzmann wrote:
> > now with 0.19.0-2 the strings changed:
> 
> Interesting, I don't see any of those in my journallog ...
> 
> > Dec 27 22:30:07 samd sddm-greeter[879122]: 
> > file:///usr/share/sddm/themes/debian-theme/Main.qml:162: TypeError: Cannot 
> > read property 'gridUnit' of null
> 
> My debian-theme points to (via /etc/alternatives) to 
> /usr/share/sddm/themes/debian-breeze
> 
> Which theme are you using? Maybe there is something badly set up?
 
lrwxrwxrwx 1 root root  29 26. Mär 2017 /etc/alternatives/sddm-debian-theme -> 
/usr/share/sddm/themes/breeze

I did not configure anything in the system, at least none to my
knowledge. (Except of course using the UI).

Greetings

   Helge



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


signature.asc
Description: PGP signature

Bug#971170: Acknowledgement (sddm: Lots of errors: TypeError: Cannot read property)

[Norbert Preining]

Hi

On Mon, 28 Dec 2020, Helge Kreutzmann wrote:
> now with 0.19.0-2 the strings changed:

Interesting, I don't see any of those in my journallog ...

> Dec 27 22:30:07 samd sddm-greeter[879122]: 
> file:///usr/share/sddm/themes/debian-theme/Main.qml:162: TypeError: Cannot 
> read property 'gridUnit' of null

My debian-theme points to (via /etc/alternatives) to 
/usr/share/sddm/themes/debian-breeze

Which theme are you using? Maybe there is something badly set up?

Best

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#971170: Acknowledgement (sddm: Lots of errors: TypeError: Cannot read property)

[Helge Kreutzmann]

Hello,
now with 0.19.0-2 the strings changed:
Dec 27 22:30:00 samd sddm-greeter[879122]: :406:376: Could not add child 
element to parent element because the types are incorrect.
Dec 27 22:30:00 samd sddm-greeter[879122]: :407:130: Could not add child 
element to parent element because the types are incorrect.
Dec 27 22:30:00 samd sddm-greeter[879122]: :408:130: Could not add child 
element to parent element because the types are incorrect.
Dec 27 22:30:00 samd sddm-greeter[879122]: :408:393: Could not add child 
element to parent element because the types are incorrect.
Dec 27 22:30:00 samd sddm-greeter[879122]: :409:130: Could not add child 
element to parent element because the types are incorrect.
Dec 27 22:30:00 samd sddm-greeter[879122]: :410:129: Could not add child 
element to parent element because the types are incorrect.
Dec 27 22:30:00 samd sddm-greeter[879122]: :411:129: Could not add child 
element to parent element because the types are incorrect.
Dec 27 22:30:00 samd sddm-greeter[879122]: :412:129: Could not add child 
element to parent element because the types are incorrect.
Dec 27 22:30:00 samd sddm-greeter[879122]: :413:129: Could not add child 
element to parent element because the types are incorrect.
Dec 27 22:30:00 samd sddm-greeter[879122]: :413:379: Could not add child 
element to parent element because the types are incorrect.
Dec 27 22:30:00 samd sddm-greeter[879122]: :413:631: Could not add child 
element to parent element because the types are incorrect.
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/share/sddm/themes/debian-theme/Main.qml:455: TypeError: Cannot read 
property 'largeSpacing' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/share/sddm/themes/debian-theme/Main.qml:460: TypeError: Cannot read 
property 'gridUnit' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/share/sddm/themes/debian-theme/Main.qml:162: TypeError: Cannot read 
property 'gridUnit' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/components.3/TextField.qml:42:
 TypeError: Cannot read property 'gridUnit' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/components.3/TextField.qml:146:
 TypeError: Cannot read property 'iconSizes' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/components.3/TextField.qml:122:
 TypeError: Cannot read property 'iconSizes' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/components.3/mobiletextselection/MobileCursor.qml:45:
 TypeError: Cannot read property 'gridUnit' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/components.3/mobiletextselection/MobileCursor.qml:32:
 TypeError: Cannot read property 'gridUnit' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/components.3/mobiletextselection/MobileCursor.qml:23:
 TypeError: Cannot read property 'devicePixelRatio' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/components.3/mobiletextselection/MobileCursor.qml:14:
 TypeError: Cannot read property 'gridUnit' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/components.3/TextField.qml:38:
 TypeError: Cannot read property 'gridUnit' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/components.3/TextField.qml:146:
 TypeError: Cannot read property 'iconSizes' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/components.3/TextField.qml:122:
 TypeError: Cannot read property 'iconSizes' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/components.3/mobiletextselection/MobileCursor.qml:45:
 TypeError: Cannot read property 'gridUnit' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/components.3/mobiletextselection/MobileCursor.qml:32:
 TypeError: Cannot read property 'gridUnit' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/components.3/mobiletextselection/MobileCursor.qml:23:
 TypeError: Cannot read property 'devicePixelRatio' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/components.3/mobiletextselection/MobileCursor.qml:14:
 TypeError: Cannot read property 'gridUnit' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/components.3/TextField.qml:38:
 TypeError: Cannot read property 'gridUnit' of null
Dec 27 22:30:07 samd sddm-greeter[879122]: 

Bug#978502: ITP: astunparse -- AST unparser for Python

[Aron Xu]

Package: wnpp
Severity: wishlist

* Package name: astunparse
  Version : 1.6.3
  Upstream Author : Simon Percivall 
* URL : https://github.com/simonpercivall/astunparse
* License : BSD-3-Clause and PFSL
  Programming Lang: Python
  Description : AST unparser for Python

Bug#978501: ITP: easydict -- Javascript-like properties dot notation for python dicts

[Aron Xu]

Package: wnpp
Severity: wishlist

* Package name: easydict
  Version : 1.9
  Upstream Author : Mathieu Leplatre 
* URL : https://github.com/makinacorpus/easydict
* License : LGPL-3
  Programming Lang: Python
  Description : Javascript-like properties dot notation for python dicts

Bug#976917: simavr: FTBFS on ppc64el: obj-powerpc64le-linux-gnu/avr_adc.d:5: *** missing separator. Stop.

[Milan Kupcevic]

tags 976917 unreproducible moreinfo
severity 976917 normal
thanks


On 12/9/20 3:41 AM, Lucas Nussbaum wrote:
[...]
> 
> During a rebuild of all packages in sid, your package failed to build
> on ppc64el. At the same time, it did not fail on amd64.
> 
> I'm marking this bug as severity:serious since your package currently has
> ppc64el binary packages in unstable (so this is a regression).
> 
[...]
>> obj-powerpc64le-linux-gnu/avr_adc.d:5: *** missing separator.  Stop.



Hi Lucas,

Your make reports a "missing separator" in line 5 of a dependency file
which was produced on your build machine by gcc -MMD while running gcc
10.2.1-1.

Given that I was not able to reproduce this bug in Debian testing with
gcc 10.2.1-1 nor in Debian sid with gcc 10.2.1-3 on two different
ppc64el machines, I'm downgrading severity of this bug to normal and
tagging it as unreproducible.

Please find attached build log and buildinfo files for comparison and
let me know if you are able to reproduce this bug in your environment.


Milan
 dpkg-buildpackage -us -uc -ui
dpkg-buildpackage: info: source package simavr
dpkg-buildpackage: info: source version 1.6+dfsg-3
dpkg-buildpackage: info: source distribution sid
dpkg-buildpackage: info: source changed by Milan Kupcevic 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture ppc64el
 fakeroot debian/rules clean
dh clean
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/home/milan/simavr-1.6+dfsg'
rm -f examples.tar
rm -f debian/examples/board_simduino/ATmegaBOOT_168_atmega328.ihex
dh_auto_clean
make -j16 clean
make[2]: Entering directory '/home/milan/simavr-1.6+dfsg'
make -C simavr clean
make[3]: Entering directory '/home/milan/simavr-1.6+dfsg/simavr'
rm -rf obj-powerpc64le-linux-gnu
rm -rf run_avr *.a *.so *.exe
rm -f sim_core_*.h
make[3]: Leaving directory '/home/milan/simavr-1.6+dfsg/simavr'
make -C tests clean
make[3]: Entering directory '/home/milan/simavr-1.6+dfsg/tests'
rm -rf obj-powerpc64le-linux-gnu
rm -f *.axf *.vcd
make[3]: Leaving directory '/home/milan/simavr-1.6+dfsg/tests'
make -C examples clean
make[3]: Entering directory '/home/milan/simavr-1.6+dfsg/examples'
for bi in board_ds1338 board_hd44780 board_i2ctest board_ledramp board_simduino 
board_ssd1306 board_timer_64led; do make -C $bi clean; done
make[4]: Entering directory '/home/milan/simavr-1.6+dfsg/examples/board_ds1338'
rm -rf obj-powerpc64le-linux-gnu
rm -rf *.hex *.a *.axf ds1338demo *.vcd .*.swo .*.swp .*.swm .*.swn
make[4]: Leaving directory '/home/milan/simavr-1.6+dfsg/examples/board_ds1338'
make[4]: Entering directory '/home/milan/simavr-1.6+dfsg/examples/board_hd44780'
rm -rf obj-powerpc64le-linux-gnu
rm -rf *.hex *.a *.axf charlcd *.vcd .*.swo .*.swp .*.swm .*.swn
make[4]: Leaving directory '/home/milan/simavr-1.6+dfsg/examples/board_hd44780'
make[4]: Entering directory '/home/milan/simavr-1.6+dfsg/examples/board_i2ctest'
rm -rf obj-powerpc64le-linux-gnu
rm -rf *.hex *.a *.axf i2ctest *.vcd .*.swo .*.swp .*.swm .*.swn
make[4]: Leaving directory '/home/milan/simavr-1.6+dfsg/examples/board_i2ctest'
make[4]: Entering directory '/home/milan/simavr-1.6+dfsg/examples/board_ledramp'
rm -rf obj-powerpc64le-linux-gnu
rm -rf *.a *.axf ledramp *.vcd *.hex
make[4]: Leaving directory '/home/milan/simavr-1.6+dfsg/examples/board_ledramp'
make[4]: Entering directory 
'/home/milan/simavr-1.6+dfsg/examples/board_simduino'
rm -rf obj-powerpc64le-linux-gnu
rm -rf *.a *.axf simduino *.vcd *.hex
make[4]: Leaving directory '/home/milan/simavr-1.6+dfsg/examples/board_simduino'
make[4]: Entering directory '/home/milan/simavr-1.6+dfsg/examples/board_ssd1306'
rm -rf obj-powerpc64le-linux-gnu
rm -rf *.hex *.a *.axf ssd1306demo *.vcd .*.swo .*.swp .*.swm .*.swn
make[4]: Leaving directory '/home/milan/simavr-1.6+dfsg/examples/board_ssd1306'
make[4]: Entering directory 
'/home/milan/simavr-1.6+dfsg/examples/board_timer_64led'
rm -rf obj-powerpc64le-linux-gnu
rm -rf *.a *.axf timer_64led *.vcd *.hex
make[4]: Leaving directory 
'/home/milan/simavr-1.6+dfsg/examples/board_timer_64led'
make[3]: Leaving directory '/home/milan/simavr-1.6+dfsg/examples'
make -C examples/parts clean
make[3]: Entering directory '/home/milan/simavr-1.6+dfsg/examples/parts'
rm -rf obj-powerpc64le-linux-gnu
rm -rf *.hex *.a *.axf *.vcd .*.swo .*.swp .*.swm .*.swn *.so *.o
make[3]: Leaving directory '/home/milan/simavr-1.6+dfsg/examples/parts'
make -C doc clean
make[3]: Entering directory '/home/milan/simavr-1.6+dfsg/doc'
rm -f .tags*
rm -rf fresh/
make[3]: Leaving directory '/home/milan/simavr-1.6+dfsg/doc'
make[2]: Leaving directory '/home/milan/simavr-1.6+dfsg'
make[1]: Leaving directory '/home/milan/simavr-1.6+dfsg'
   dh_clean
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building simavr using existing ./simavr_1.6+dfsg.orig.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building simavr in simavr_1.6+dfsg-3.debian.tar.xz

Bug#978500: facter: package deploys ruby code but no gem

[Gabriel Filion]

Package: facter
Version: 3.14.12-1+b2
Severity: normal

Hello,

The "facter" package currently does not ship the .gemspec file that gets
generated during build. This means that facter is not visible as an installed
system-wide gem.

The impact of this is that other packages that depend on the "facter" gem,
will require a hack in order to remove facter from the gemspec dependencies.
Also, gems installed manually may end up installing a second copy of facter on
the system.


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

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.utf8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages facter depends on:
ii  libboost-program-options1.74.0  1.74.0-5
ii  libc6   2.31-6
ii  libfacter3.14.123.14.12-1+b2
ii  libgcc-s1   10.2.1-3
ii  libleatherman1.12.1 1.12.1+dfsg-1.1
ii  libstdc++6  10.2.1-3
ii  ruby1:2.7+2

facter recommends no packages.

facter suggests no packages.

-- no debconf information

Bug#978499: fop: reproducible builds: Support using SOURCE_DATE_EPOCH for timestamps in PDF files

[Vagrant Cascadian]

Package: fop
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Several packages use fop to generate PDF files in Debian packages, but
the resulting PDF files have embedding timestamp information in the
CreationDate of the PDF:

  
https://tests.reproducible-builds.org/debian/issues/unstable/timestamps_in_pdf_generated_by_apache_fop_issue.html


For example, in xorg-docs:

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

  /usr/share/doc/xorg-docs/xlfd/xlfd.pdf.gz
  
  CreationDate:·"D:20201225182038-12'00'"
  vs.
  CreationDate:·"D:20220129025203+14'00'"


The attached patch fixes this by adding support for the
SOURCE_DATE_EPOCH environment variable to fop, which embeds the
specified timestamp rather than the current time:

  https://reproducible-builds.org/docs/source-date-epoch/


Thanks for maintaining fop!


live well,
  vagrant
From 25826ea9c86d01a8392cf593b9aa93c72b469b19 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 28 Dec 2020 02:48:21 +
Subject: [PATCH] PDFInfo.java: Support SOURCE_DATE_EPOCH environment variable.

https://reproducible-builds.org/docs/source-date-epoch/
---
 fop-core/src/main/java/org/apache/fop/pdf/PDFInfo.java | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/fop-core/src/main/java/org/apache/fop/pdf/PDFInfo.java b/fop-core/src/main/java/org/apache/fop/pdf/PDFInfo.java
index 3aa5d97..79f3f42 100644
--- a/fop-core/src/main/java/org/apache/fop/pdf/PDFInfo.java
+++ b/fop-core/src/main/java/org/apache/fop/pdf/PDFInfo.java
@@ -305,7 +305,14 @@ public class PDFInfo extends PDFObject {
  * @return the requested String representation
  */
 protected static String formatDateTime(final Date time) {
-return formatDateTime(time, TimeZone.getDefault());
+// https://reproducible-builds.org/docs/source-date-epoch/
+String source_date_epoch = System.getenv("SOURCE_DATE_EPOCH");
+if (source_date_epoch != null) {
+Long sourcedate = (1000 * Long.parseLong(source_date_epoch));
+return formatDateTime(new Date(sourcedate), TimeZone.getTimeZone("Etc/UTC"));
+} else {
+return formatDateTime(time, TimeZone.getDefault());
+}
 }
 
 /**
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Bdale Garbee]

Russ Allbery  writes:

> I assumed that if option B won, some
> maintainers would drop init scripts, and therefore if folks wanted to
> maintain a set of working init scripts, they'd need to look at different
> options than ensuring they were incorporated into each package.

I agree, this was my sense of what B meant at the time, too.

Bdale


signature.asc
Description: PGP signature

Bug#977413:

[Richsrd Manwell]

Updates & upgrades.

Bug#978498: FTBFS on riscv64: machine `riscv64' not recognized

[John Scott]

Source: sofia-sip
Version: 1.12.11+20110422.1-2.1+b1
Severity: normal
X-Debbugs-CC: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

sofia-sip fails to build on RISC-V [1], and it appears this is because
the generated configure script and/or config.sub and config.guess are too
old.

Please retool Autotools as described in
/usr/share/doc/autotools-dev/README.Debian.gz provided by autotools-dev,
perhaps by using dh_autoreconf.

[1] https://buildd.debian.org/status/package.php?p=sofia-sip

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


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

Bug#978086: xscreensaver: should use scalable fonts by default and not depend on bitmap fonts

[Jamie Zawinski]

> I've found the reason why xfonts-100dpi wasn't working for me:
> on startup, the X server removes unexisting directories from the
> default FontPath

AHA! That explains it! Thanks for figuring that out.

After installing both xfonts-100dpi and gsfonts-x11 and restarting X, I get:

xset q | grep font

/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,built-ins

And after that, having •either* xfonts-100dpi or gsfonts-x11 installed makes 
both xterm and xscreensaver have correct fonts.

--
Jamie Zawinski  https://www.jwz.org/  https://www.dnalounge.com/

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Russ Allbery]

gregor herrmann  writes:

> What surprises me in this discussion: My very broad summary of the GR
> result was "systemd is the top priority, other init systems are
> supported on a best-effort basis", and now I'm reading statements which
> sound to me like "looking into new/future/niche init systems is ok-ish
> but we never meant sysvinit when we said 'alternate init systems'", and
> that's either a misunderstanding of some mails on my side or an
> interpretation I find implausible to draw from the text of the winning
> GR option.

The position that sysvinit specifically is a dead end but that Debian
should not lock ourselves into a single init system and instead be open to
using other init systems besides systemd was a position advocated by
several people during the GR debate, and if one held that position, it is
a reason to vote for the winning option B over option F (the focus on
systemd option).  Certainly my understanding at the time was that option B
was intended to represent the folks with that position, possibly among
others.

Whether the folks who voted B over other options meant it in that specific
way is, of course, somewhat unknowable, and I'm sure at least some of them
didn't.

This discussion surprises me for a somewhat different reason.  The winning
GR option contains this text, which I think is an evolution of text that I
asked for at the time to make things clearer from a Policy standpoint:

Packages may use any systemd facility at the package maintainer's
discretion, provided that this is consistent with other Policy
requirements and the normal expectation that packages shouldn't depend
on experimental or unsupported (in Debian) features of other packages.
Packages may include support for alternate init systems besides
systemd and may include alternatives for any systemd-specific
interfaces they use. Maintainers use their normal procedures for
deciding which patches to include.

I think this clearly and unambiguously says that maintainers can depend on
unit support and drop init scripts from their packages if they so choose,
and that this choice only requires as much justification as rejecting any
other patch or feature in their packages (and Debian is generally defers
to package maintainers here).

One of the GR discussion goals was to try to make all of the options clear
about the implications for whether or not maintainers could drop init
scripts from their packages or would be required to include them, and I
thought option B was one of the options that made it unambiguous that
maintainers could drop them.  I assumed that if option B won, some
maintainers would drop init scripts, and therefore if folks wanted to
maintain a set of working init scripts, they'd need to look at different
options than ensuring they were incorporated into each package.

Apparently we still, after all that discussion, weren't on the same page
about this?  That's really unfortunate, since that was one of the major
questions on which we were trying to get closure.

For the record, the current Policy language says:

Packages including a service unit may optionally include an init
script to support other init systems. In this case, the init script
should have the same name as the systemd service unit so that systemd
will ignore it and use the service unit instead. Packages may also
support other init systems by including configuration in the native
format of those init systems.

I have another pending patch that I need to finish revising that makes the
normative language here more explicit.  The intended definition of "may"
here is the one from that patch, namely:

* The term *may* and the adjective *optional* are used to clarify cases
  where it may otherwise appear that Policy is specifying a requirement or
  recommendation. In those cases, these words describe decisions that are
  truly optional and at the maintainer's discretion.

This was intended to reflect the result of the GR.

The dependency structure for indicating a logind requirement is a more
complicated question and I don't personally have any opinion about the
GR's implications for it.

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

Bug#906918: fdisk: document cfdisk resize command and shortcut

[Chris Hofstaedtler]

Control: tags -1 + help
Control: found -1 2.36.1-3

* nfb :
> the resize command for cfdisk is not documented in the cfdisk(8) man
> page, nor in the online help dialog of the tool (shown pressing 'h' or
> '?' or selecting [ Help ]). The shortcut 'r' for resizing is actually
> working but it's not documented either.

This is an upstream issue, so it would be good if this was filed
with upstream. Preferably with a (draft) patch.

Otherwise, I believe there will never be progress on this.

Chris

Bug#922103: column man page: most options need examples to make them understandable

[Chris Hofstaedtler]

* 積丹尼 Dan Jacobson  [201228 01:02]:
> OK, I am making progress at understanding -s:
> 
> $ echo axbxc|column -t -s x
> a  b  c
> 
> So it is talking about INPUT columns. The man page should mention it.

The util-linux manpage for column has to say:

  -s, --separator separators
Specify the possible input item delimiters (default is whitespace).

That should be good enough?

> Anyway, most of the options mentioned on the man page need minimal examples 
> with
> output to make clear what they do.

For other options, this needs a patch, sent upstream with a
sign-off. Otherwise this will never be done.

JFTR: what appears to be clear documentation to one person can be
lacking or confusing to another. Just saying "it needs to have
examples" will not help.

Best,
Chris

Bug#978497: ITP: golang-github-golang-freetype -- The Freetype font rasterizer in the Go programming language.

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-github-golang-freetype
  Version : release+git20170609.e2365df-1
  Upstream Author : Go
* URL : https://github.com/golang/freetype
* License : freetype or gpl-2.0+
  Programming Lang: Go
  Description : The Freetype font rasterizer in the Go programming
language.

 The Freetype font rasterizer in the Go programming language.

This is needed for perkeep.


-- 
Alexandre Viau
av...@debian.org

Bug#975435: fdisk: feature request: partition alignment for sfdisk

[Chris Hofstaedtler]

Control: tags -1 + upstream

Hello Marc Lehmann,

thank you for your mail.

* Marc Lehmann :
> sfdisk by default aligns partition sizes to one sector (at least on some
> disks) when sizes are not exactly specified. Larger alignments can be very
> useful nowadays, for example, disk encryption can be more efficient when
> the sector size for encryption is 4096 octets, requiring a partition size
> that is an exact multiple of 8 sectors.
> 
> Unfortunately, when sfidsk auto-sizes a partition and the device has
> an "odd" size and the size is not specified, sfdisk will simply (and
> correctly) use the full remaining disk, causing e.g. cryptsetup with
> --sector-size 4096 to fail.
> 
> It would be nice if it were possible to specify an alignment factor in
> bytes or sectors that would be used when creating partitions.

Sounds reasonable to me. However that's not a Debian-specific thing.
Please report this upstream.

Instructions are here:
  https://sources.debian.org/src/util-linux/2.33.1-0.1/README/

Many thanks,
Chris

Bug#856505: Light Supplier.

[top top]

Hello,
Good day.
We are manufacturers of all kinds of Light in China.
If you are interested.kindly reply to know more about us and contact us for 
your order.
We deliver worldwide at the cheapest prices.

Also we have our own professional designers to meet any of your requirements.
Sincerely,
Andy

Bug#978496: mca_op_avx.so: undefined symbol: ompi_op_base_module_t_class (ignored)

[Drew Parsons]

Package: libopenmpi3
Version: 4.1.0-2
Severity: normal

The new openmpi version seems to have introduced a new missing symbol.
It ignores the problem, but that causes problems with runtime then
failing to proceed.  Not clear to me if this should be considered an
error or a warning that needs to be worked around.

The issue appears in dolfinx python demos (e.g. the demo_poisson.py demo)
stderr gets the message:

E   subprocess.CalledProcessError: Command 
'['/usr/bin/python3', 'demo_poisson.py']' died with .

/usr/lib/python3.9/subprocess.py:524: CalledProcessError
- Captured stderr call 
-
[monte:518022] mca_base_component_repository_open: unable to open 
mca_op_avx: /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_op_avx.so: 
undefined symbol: ompi_op_base_module_t_class (ignored)
A process has executed an operation involving a call
to the fork() system call to create a child process.

As a result, the libfabric EFA provider is operating in
a condition that could result in memory corruption or
other system errors.

For the libfabric EFA provider to work safely when fork()
is called, you will need to set the following environment
variable:
  RDMAV_FORK_SAFE

However, setting this environment variable can result in
signficant performance impact to your application due to
increased cost of memory registration.

You may want to check with your application vendor to see
if an application-level alternative (of not using fork)
exists.

Your job will now abort.




If I set environment variable RDMAV_FORK_SAFE as instructed, then the
process will run successfully.  But is this the best workaround or
should some other action be taken?

It does seem odd that mca_op_avx.so references an undefined symbol,
ompi_op_base_module_t_class.



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

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

Versions of packages libopenmpi3 depends on:
ii  libc62.31-6
ii  libevent-core-2.1-7  2.1.12-stable-1
ii  libevent-pthreads-2.1-7  2.1.12-stable-1
ii  libfabric1   1.11.0-2
ii  libgcc-s110.2.1-3
ii  libhwloc-plugins 2.4.0+dfsg-2
ii  libhwloc15   2.4.0+dfsg-2
ii  libibverbs1  32.0-1+b1
ii  libnl-3-200  3.4.0-1+b1
ii  libpmix2 4.0.0~rc1-2
ii  libpsm-infinipath1   3.3+20.604758e7-6+b1
ii  libpsm2-211.2.185-1
ii  libstdc++6   10.2.1-3
ii  libucx0  1.9.0~rc1-2
ii  zlib1g   1:1.2.11.dfsg-2

libopenmpi3 recommends no packages.

libopenmpi3 suggests no packages.

-- no debconf information

Bug#978495: ITP: golang-github-bradfitz-latlong -- maps from a latitude and longitude to a timezone.

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-github-bradfitz-latlong
  Version : 0.0~git20170410.f3db6d0-1
  Upstream Author : Brad Fitzpatrick
* URL : https://github.com/bradfitz/latlong
* License : Apache-2.0
  Programming Lang: Go
  Description : The latlong package maps from a latitude and
longitude to a timezone.

This is needed for Perkeep.

-- 
Alexandre Viau
av...@debian.org

Bug#978494: binutils-arm-none-eabi: reproducible builds: Enable deterministic archives

[Vagrant Cascadian]

Package: binutils-arm-none-eabi
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps toolchain
Control: affects -1 libstdc++-arm-none-eabi
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

binutils-arm-none-eabi is not built with deterministic archives enabled,
which causes reproducibility issues in packages using it:

  
https://tests.reproducible-builds.org/debian/issues/unstable/timestamps_in_static_libraries_issue.html

The attached patch adds --enable-deterministic-archives to the configure
arguments in debian/rules.

FWIW, the --enable-deterministic-archives feature was enabled Debian's 
"binutils"
package in 2015.

With this feature enabled in binutils-arm-none-eabi, I've been able to
reproducibly build libstdc++-arm-none-eabi when using a stable build
path.


live well,
  vagrant
From d37bba76c874098a11047b70e5620a25eb81b9dc Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 26 Dec 2020 20:53:23 +
Subject: [PATCH] debian/rules: Pass --enable-deterministic-archives to
 configure.

https://tests.reproducible-builds.org/debian/issues/unstable/timestamps_in_static_libraries_issue.html
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index ff9a8c3..f95972b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -35,6 +35,7 @@ configure_flags = \
 	--enable-interwork \
 	--with-system-zlib \
 	"--with-pkgversion=$(deb_version)" \
+	--enable-deterministic-archives \
 	$(buildflags)
 
 %:
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#978493: examples.pl not linked right

[積丹尼 Dan Jacobson]

Package: imagemagick-6-doc
Version: 8:6.9.11.24+dfsg-1

Browse file:///usr/share/doc/imagemagick-6-common/html/www/examples.html
The main link
file:///usr/share/doc/imagemagick-6-common/html/source/examples.pl needs to be
file:///usr/share/doc/imagemagick-6-common/html/www/source/examples.pl !

Bug#978086: xscreensaver: should use scalable fonts by default and not depend on bitmap fonts

[Vincent Lefevre]

On 2020-12-27 08:27:13 -0800, Jamie Zawinski wrote:
> With only gsfonts-x11, I get the same results as you for
>   find /usr -name fonts.alias | xargs grep -i 'helvetica-bold-r-'
> and
>   find /usr -name fonts.dir | xargs grep -i 'urw-nimbus.*bold.*iso8859-1$'
> and
>   dlocate n019004l.pfb
> and yet
>   xterm -fn '-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1'
> does not work.
> 
> So there must be some *other* thing installed on your system that is
> not installed on mine that is making Xlib Helvetica work. I don't
> know what that is.

I've found the reason why xfonts-100dpi wasn't working for me:
on startup, the X server removes unexisting directories from the
default FontPath (even though the directory may exist later), as
I could see in the Xorg log file. So /usr/share/fonts/X11/100dpi
was initially removed. If I start a second X server, the helvetica
font can be found if only xfonts-100dpi is installed. Ditto if I
change the FontPath with "xset fp= ...".

Now, concerning gsfonts-x11, the package description says:

 This package makes the 35 PostScript fonts from the gsfonts package
 available to your X server under their "urw" names and via
 fonts.alias with the official "adobe" names, too.

So /usr/share/fonts/X11/Type1/fonts.alias provides the helvetica
font as described (via /etc/X11/fonts/Type1/gsfonts-x11.alias and
update-fonts-alias), so that the font should be found if
/usr/share/fonts/X11/Type1 is in the FontPath. I suggest that you
check this point since gsfonts-x11 was not installed initially on
your system.

Note that I use the default FontPath dynamically built by Xorg.
So nothing specific on my system.

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

Bug#978492: libtrapperkeeper-webserver-jetty9-clojure: does not provide -test jar

[Louis-Philippe Véronneau]

Package: libtrapperkeeper-webserver-jetty9-clojure
Version: 1.7.0-4
Severity: wishlist
Owner: po...@debian.org

This package currently doesn't build the -test jar file upstream
normally provides at build.

This means packages using lein to build and needing
[puppetlabs/trapperkeeper-webserver-jetty9 :classifier "test"] can't
currently be built.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature

Bug#978491: roundcube: CVE-2020-35730: XSS vulnerability via malious HTML or plaintext messages

[Guilhem Moulin]

Source: roundcube
Severity: important
Tags: security
Control: found -1 1.4.9+dfsg.1-1
Control: found -1 1.3.15+dfsg.1-1~deb10u1
Control: found -1 1.2.3+dfsg.1-4+deb9u7

In a recent post roundcube webmail upstream has announced the following
security fix:

Cross-site scripting (XSS) via HTML or Plain text messages with
malicious content (CVE-2020-35730)

1.2.x, 1.3.x and 1.4.x branches are affected.  Upstream fix:

1.4.x 
https://github.com/roundcube/roundcubemail/commit/0bceba301aa621ecc0263eac17beee2a4cef0c6d
1.3.x 
https://github.com/roundcube/roundcubemail/commit/a06ec1dcf9c972d302b16e1ac6aa079a4f6a1c3e
1.2.x 
https://github.com/roundcube/roundcubemail/commit/47e4d44f62ea16f923761d57f1773a66d51afad4

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#978490: librtas: new upstream version available

[Chris Hofstaedtler]

Source: librtas

A new upstream version, 2.0.2 is available. Please update the Debian
package.

Chris

Bug#898758: open-iscsi FTCBFS: configures for the build architecture

[Chris Hofstaedtler]

Control: tags -1 - patch

Hello Helmut,

* Helmut Grohne  [201228 00:08]:
> open-iscsi fails to cross build from source, because iscsiuio/configure
> is invoked without --host. The invocation stems from upstream's
> Makefile. The easy way to fix that is to run that configure before the
> upstream Makefile gets to do so. After doing so, open-iscsi cross builds
> sucessfully. Please consider applying the attached patch.

Thank you for sending in the patch. However, the packaging has
changed considerably since you sent the patch.
I do not know if this is still a problem (would expect so though).

Maybe you could send us a new patch?

Many thanks,
Chris

Bug#978005: [Pkg-julia-devel] Bug#978005: Bug#978005: Julia Plots scaling error with Plots.GR

[Norbert Preining]

Control: close -1

Hi,

> I am not sure who controls the modules for Julia, the problem was with two

You yourself. Debian doesn't ship any further modules but the most
basic. That means, all the modules that are installed have been pulled
in by you via Pkg.install etc.

> of the modules updated to a compatible version, and all is working again.

Well, things don't update out of blue air, you have kicked off some
update, but whatever means.

Closing this bug.

Best

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#978489: missing dependency on qml-module-qtquick-controls

[Marco d'Itri]

Package: linphone-desktop
Version: 4.2.5-2
Severity: grave

Or else linphone will crash with:

[00:50:46:566][0x5618e548aed0][Info]app/App.cpp:784: "Open Linphone app."
[00:50:46:566][0x5618e548aed0][Info]app/App.cpp:225: "Creating subwindow: 
`qrc:/ui/views/App/Calls/CallsWindow.qml`."
[00:50:46:608][0x5618e548aed0][Warning]app/App.cpp:229: 
(qrc:/ui/views/App/Calls/CallsWindow.qml:191:9: Type Chat unavailable
Chat {
^, qrc:/ui/modules/Linphone/Chat/Chat.qml:215:7: Type 
DroppableTextArea unavailable
  DroppableTextArea {
  ^, qrc:/ui/modules/Common/Form/DroppableTextArea.qml:108:5: Type 
FileDialog unavailable
FileDialog {
^, 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Dialogs/DefaultFileDialog.qml:42:1:
 module "QtQuick.Controls" version 1.2 is not installed
import QtQuick.Controls 1.2
^)

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

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

Versions of packages linphone-desktop depends on:
ii  libbctoolbox1  4.4.13-2
ii  libbelcard14.4.13-2
ii  libc6  2.31-6
ii  libgcc-s1  10.2.1-3
ii  liblinphone++104.4.21-1
ii  liblinphone10  4.4.21-1
ii  libmediastreamer11 1:4.4.21-1
ii  libqt5core5a   5.15.2+dfsg-2
ii  libqt5dbus55.15.2+dfsg-2
ii  libqt5gui5 5.15.2+dfsg-2
ii  libqt5network5 5.15.2+dfsg-2
ii  libqt5qml5 [qtdeclarative-abi-5-15-2]  5.15.2+dfsg-2
ii  libqt5quick5   5.15.2+dfsg-2
ii  libqt5quickcontrols2-5 5.15.2+dfsg-2
ii  libqt5svg5 5.15.2-2
ii  libqt5widgets5 5.15.2+dfsg-2
ii  libstdc++6 10.2.1-3
ii  linphone-common4.4.21-1
ii  qml-module-qt-labs-platform5.15.2+dfsg-2
ii  qml-module-qtgraphicaleffects  5.15.2-2
ii  qml-module-qtquick-controls2   5.15.2+dfsg-2
ii  qml-module-qtquick-dialogs 5.15.2-2
ii  qml-module-qtquick-layouts 5.15.2+dfsg-2
ii  qml-module-qtquick-window2 5.15.2+dfsg-2
ii  qml-module-qtquick25.15.2+dfsg-2

linphone-desktop recommends no packages.

linphone-desktop suggests no packages.

-- no debconf information

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#905564: /etc/default/su

[Chris Hofstaedtler]

* Gene Heskett  [201228 00:51]:
> On Sunday 27 December 2020 18:34:02 Chris Hofstaedtler wrote:
[..]
> I don't I'd be so quick to cancel/close this bug, as that is not where it 
> goes for me. My stretch does not have an /etc/default/su file. Yet su 
> works. I generally use konsole and run tde, not kde.  Fix it for 
> everybody if you are claiming a fix.

stretch does not get fixes any more. Fixes go into bullseye.
On bullseye, creating an /etc/defaults/su file with the suggested
contents works.

If you are suggesting this does not work on stretch, that might be
correct, but is of no relevance to me.

Chris

Bug#905564: /etc/default/su

[Gene Heskett]

On Sunday 27 December 2020 18:34:02 Chris Hofstaedtler wrote:

> * Gene Heskett  [201227 23:33]:
> > > unicorn:~$ cat /etc/default/su
> > > ALWAYS_SET_PATH yes
> >
> > This has been done on stretch, but has no effect on this:
> >
> > gene@coyote:~$ sudo -i
> > [sudo] password for gene:
> > root@coyote:~$ su amanda -c "geany bak-indices-configs"
> > configuration error - unknown item 'ALWAYS_SET_PATH' (notify
> > administrator)
> >
> > Is there a better fix for uptodate stretch?
>
> /etc/default/su uses "shell" format, so it should be:
> ALWAYS_SET_PATH=yes
> instead.
>
> I have updated the NEWS entry, and will close this bug with the next
> upload.

I don't I'd be so quick to cancel/close this bug, as that is not where it 
goes for me. My stretch does not have an /etc/default/su file. Yet su 
works. I generally use konsole and run tde, not kde.  Fix it for 
everybody if you are claiming a fix.

Lets have a better 2021.

> Best,
> Chris


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Bug#978483: r-cran-pbkrtest: not installable in sid

[Dirk Eddelbuettel]

On 28 December 2020 at 00:25, Aurelien Jarno wrote:
| Package: r-cran-pbkrtest
| Version: 0.5-0.1-1
| Severity: serious
| 
| r-cran-pbkrtest is currently not installable in sid:
| 
| # apt-get install r-cran-pbkrtest
| Reading package lists... Done
| Building dependency tree
| Reading state information... Done
| Some packages could not be installed. This may mean that you have
| requested an impossible situation or if you are using the unstable
| distribution that some required packages have not yet been created
| or been moved out of Incoming.
| The following information may help to resolve the situation:
| 
| The following packages have unmet dependencies:
|  r-cran-pbkrtest : Depends: r-cran-lme4 (>= 1.1.10) but it is not going to be 
installed
| E: Unable to correct problems, you have held broken packages.
| 
| There is likely a typo in the version, it should be 1.1-10 instead of
| 1.1.10.

That is auto generated (which a hand-added line break):

   Depends: ${misc:Depends}, ${R:Depends}, r-cran-lme4, r-cran-nloptr, 
r-cran-matrix, \
   r-cran-mass, r-cran-magrittr, r-cran-broom, r-cran-dplyr, r-cran-numderiv, 
r-cran-knitr

Could this be a bug in dh-r?  Also unclear where '1.1.10' comes from as:

   $ apt-cache policy r-cran-lme4
   r-cran-lme4:
 Installed: (none)
 Candidate: 1.1-26-1
 Version table:
1.1-26-1 990
   990 http://deb.debian.org/debian testing/main amd64 Packages
   500 http://http.debian.net/debian sid/main amd64 Packages
   $ 

But I think it is a regression. I had a patch against the *broken upstream*
DESCRIPTION file:

   Depends: R (>= 3.5.0), lme4 (>= 1.1.10)
   Imports: broom, dplyr, magrittr, MASS, Matrix (>= 1.2.3), methods,
   numDeriv, parallel, knitr

I re-enable the patch in pbkrtest and will try to talk to upstream to fix it.

Thanks for catching this.

Dirk


-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#905564: /etc/default/su

[Chris Hofstaedtler]

* Gene Heskett  [201227 23:33]:
> > unicorn:~$ cat /etc/default/su
> > ALWAYS_SET_PATH yes
> 
> This has been done on stretch, but has no effect on this:
> 
> gene@coyote:~$ sudo -i
> [sudo] password for gene:
> root@coyote:~$ su amanda -c "geany bak-indices-configs"
> configuration error - unknown item 'ALWAYS_SET_PATH' (notify administrator)
> 
> Is there a better fix for uptodate stretch?

/etc/default/su uses "shell" format, so it should be:
ALWAYS_SET_PATH=yes
instead.

I have updated the NEWS entry, and will close this bug with the next
upload.

Best,
Chris

Bug#978488: libscca: memory tests fundamentally broken, please disable them on riscv64

[Aurelien Jarno]

Source: libscca
Version: 20181227-1.1
Severity: normal
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

libscca fails to build on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=libscca=riscv64=20181227-1.1=1580324189=0

This is due to fundamentally broken tests assuming that memcpy and
memset can fail returning NULL, and interposing these libc functions in
the tests with functions that sometimes return NULL. This tests should
be simply removed as they do not make sense. See bug #978433 for more
details as the same code is basically replicated in dozen of packages.

A simpler way to fix the issue for riscv64 is to disable all memory
tests on this architecture, as it is already done for a long list of
cases. This is what the patch below does:

--- libscca-20181227/debian/patches/01-disable-memory-tests-on-riscv64.patch
1970-01-01 01:00:00.0 +0100
+++ libscca-20181227/debian/patches/01-disable-memory-tests-on-riscv64.patch
2020-12-27 14:51:21.0 +0100
@@ -0,0 +1,11 @@
+--- libscca-20181227.orig/tests/scca_test_memory.h
 libscca-20181227/tests/scca_test_memory.h
+@@ -28,7 +28,7 @@
+ extern "C" {
+ #endif
+ 
+-#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBSCCA_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( HAVE_ASAN )
++#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBSCCA_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( __riscv ) && !defined( HAVE_ASAN )
+ #define HAVE_SCCA_TEST_MEMORY 1
+ #endif
+ 
--- libscca-20181227/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ libscca-20181227/debian/patches/series  2020-12-27 14:51:21.0 
+0100
@@ -0,0 +1 @@
+01-disable-memory-tests-on-riscv64.patch

Regards,
Aurelien

Bug#978487: libregf: memory tests fundamentally broken, please disable them on riscv64

[Aurelien Jarno]

Source: libregf
Version: 20201007-1
Severity: normal
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

libregf fails to build on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=libregf=riscv64=20201007-1=1607177727=0

This is due to fundamentally broken tests assuming that memcpy and
memset can fail returning NULL, and interposing these libc functions in
the tests with functions that sometimes return NULL. This tests should
be simply removed as they do not make sense. See bug #978433 for more
details as the same code is basically replicated in dozen of packages.

A simpler way to fix the issue for riscv64 is to disable all memory
tests on this architecture, as it is already done for a long list of
cases. This is what the patch below does:

--- libregf-20201007/debian/patches/01-disable-memory-tests-on-riscv64.patch
1970-01-01 01:00:00.0 +0100
+++ libregf-20201007/debian/patches/01-disable-memory-tests-on-riscv64.patch
2020-12-27 14:51:19.0 +0100
@@ -0,0 +1,11 @@
+--- libregf-20201007.orig/tests/regf_test_memory.h
 libregf-20201007/tests/regf_test_memory.h
+@@ -28,7 +28,7 @@
+ extern "C" {
+ #endif
+ 
+-#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBREGF_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( HAVE_ASAN )
++#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBREGF_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( __riscv ) && !defined( HAVE_ASAN )
+ #define HAVE_REGF_TEST_MEMORY 1
+ #endif
+ 
--- libregf-20201007/debian/patches/series  2020-12-05 11:48:52.0 
+0100
+++ libregf-20201007/debian/patches/series  2020-12-27 14:51:19.0 
+0100
@@ -1 +1,2 @@
 ac-path-pkgconfig.patch
+01-disable-memory-tests-on-riscv64.patch

Regards,
Aurelien

Bug#978486: libqcow: memory tests fundamentally broken, please disable them on riscv64

[Aurelien Jarno]

Source: libqcow
Version: 20181227-1.1
Severity: normal
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

libqcow fails to build on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=libqcow=riscv64=20181227-1.1=1580584729=0

This is due to fundamentally broken tests assuming that memcpy and
memset can fail returning NULL, and interposing these libc functions in
the tests with functions that sometimes return NULL. This tests should
be simply removed as they do not make sense. See bug #978433 for more
details as the same code is basically replicated in dozen of packages.

A simpler way to fix the issue for riscv64 is to disable all memory
tests on this architecture, as it is already done for a long list of
cases. This is what the patch below does:

--- libqcow-20181227/debian/patches/01-disable-memory-tests-on-riscv64.patch
1970-01-01 01:00:00.0 +0100
+++ libqcow-20181227/debian/patches/01-disable-memory-tests-on-riscv64.patch
2020-12-27 14:51:18.0 +0100
@@ -0,0 +1,11 @@
+--- libqcow-20181227.orig/tests/qcow_test_memory.h
 libqcow-20181227/tests/qcow_test_memory.h
+@@ -28,7 +28,7 @@
+ extern "C" {
+ #endif
+ 
+-#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBQCOW_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( HAVE_ASAN )
++#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBQCOW_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( __riscv ) && !defined( HAVE_ASAN )
+ #define HAVE_QCOW_TEST_MEMORY 1
+ #endif
+ 
--- libqcow-20181227/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ libqcow-20181227/debian/patches/series  2020-12-27 14:51:18.0 
+0100
@@ -0,0 +1 @@
+01-disable-memory-tests-on-riscv64.patch

Regards,
Aurelien

Bug#978485: libpff: memory tests fundamentally broken, please disable them on riscv64

[Aurelien Jarno]

Source: libpff
Version: 20180714-2
Severity: normal
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

libpff fails to build on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=libpff=riscv64=20180714-2=1580068149=0

This is due to fundamentally broken tests assuming that memcpy and
memset can fail returning NULL, and interposing these libc functions in
the tests with functions that sometimes return NULL. This tests should
be simply removed as they do not make sense. See bug #978433 for more
details as the same code is basically replicated in dozen of packages.

A simpler way to fix the issue for riscv64 is to disable all memory
tests on this architecture, as it is already done for a long list of
cases. This is what the patch below does:

--- libpff-20180714/debian/patches/04-disable-memory-tests-on-riscv64.patch 
1970-01-01 01:00:00.0 +0100
+++ libpff-20180714/debian/patches/04-disable-memory-tests-on-riscv64.patch 
2020-12-27 15:08:04.0 +0100
@@ -0,0 +1,11 @@
+--- libpff-20180714.orig/tests/pff_test_memory.h
 libpff-20180714/tests/pff_test_memory.h
+@@ -28,7 +28,7 @@
+ extern "C" {
+ #endif
+ 
+-#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBPFF_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( HAVE_ASAN )
++#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBPFF_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( __riscv ) && !defined( HAVE_ASAN )
+ #define HAVE_PFF_TEST_MEMORY  1
+ #endif
+ 
--- libpff-20180714/debian/patches/series   2020-01-19 22:36:49.0 
+0100
+++ libpff-20180714/debian/patches/series   2020-12-27 15:08:04.0 
+0100
@@ -1,3 +1,4 @@
 01-fix-spelling-binary.patch
 02-fix-man-pages-pffexport-and-pffinfo.patch
 03-fixes-for-libpff-manpage.patch
+04-disable-memory-tests-on-riscv64.patch

Regards,
Aurelien

Bug#978484: gnu-standards: Should be marked Multi-Arch: foreign

[Fabrice BAUZAC]

Package: gnu-standards
Version: 2010.03.11-1.1
Severity: minor
Tags: patch

Dear Maintainer,

The tracker [1] reveals that the package should be marked Multi-Arch:
foreign.

[1] https://tracker.debian.org/pkg/gnu-standards

Here is a patch to fix it:

diff --git a/debian/control b/debian/control
index 1b75648..c6539ba 100644
--- a/debian/control
+++ b/debian/control
@@ -11,6 +11,7 @@ Vcs-Browser: https://salsa.debian.org/debian/gnu-standards

 Package: gnu-standards
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Description: GNU coding and package maintenance standards
  This package contains two pieces of documentation from the GNU


Thanks!

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads)
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=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[gregor herrmann]

On Sun, 27 Dec 2020 15:39:47 -0700, Sean Whitton wrote:

> On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote:
> > My reasoning is that init scripts are the end goal, and that elogind is
> > just a symptom of that end goal, and that therefore talking about
> > elogind in isolation serves no purpose.
> The GR specifically mentions elogind and not init scripts.

"Technologies /such as/ elogind …" (emph. mine) shows to me that this
is meant as an example, as a "demonstration", and not as an
exhaustive list [0]. So neither is elogind "special" nor is it the
only relevant piece of software to consider supporting. [1]


What surprises me in this discussion: My very broad summary of the GR
result was "systemd is the top priority, other init systems are
supported on a best-effort basis", and now I'm reading statements
which sound to me like "looking into new/future/niche init systems is
ok-ish but we never meant sysvinit when we said 'alternate init
systems'", and that's either a misunderstanding of some mails on my
side or an interpretation I find implausible to draw from the text of
the winning GR option.


Cheers,
gregor


[0] in German (and probably Roman) legal terms, "demonstrativ" vs.
"taxativ", cf. https://de.wikipedia.org/wiki/Enumerationsprinzip and
https://dict.leo.org/forum/viewWrongentry.php?idThread=40524=ende=en

[1] I also think that this is an example of why naming one specific
software in a normative text is not such a good idea.

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Carole King: Smackwater Jack


signature.asc
Description: Digital Signature

Bug#974563: Security update of pacemaker

[Markus Koschany]

Hello,

I have prepared a new security update of pacemaker, the latest version in the
1.1.x series. The update will fix CVE-2018-16877, CVE-2018-16878 and CVE-2020-
25654. I would appreciate it if you could test this version before it is
uploaded to stretch-security again. You can find all Debian packages at 

https://people.debian.org/~apo/lts/pacemaker/

including the source package if you prefer to compile pacemaker from source.

If I don't get any negative feedback I intend to upload pacemaker 1.1.24-
0+deb9u1 on 06.01.2021.

Regards,

Markus


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

Bug#978483: r-cran-pbkrtest: not installable in sid

[Aurelien Jarno]

Package: r-cran-pbkrtest
Version: 0.5-0.1-1
Severity: serious

r-cran-pbkrtest is currently not installable in sid:

# apt-get install r-cran-pbkrtest
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 r-cran-pbkrtest : Depends: r-cran-lme4 (>= 1.1.10) but it is not going to be 
installed
E: Unable to correct problems, you have held broken packages.

There is likely a typo in the version, it should be 1.1-10 instead of
1.1.10.

Regards,
Aurelien

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
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
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#978015: Add "image/webp webp" to /etc/mime.types ?

[Charles Plessy]

Control: forcemerge -1 971011

Le Thu, Dec 24, 2020 at 11:46:37PM +1100, Trent W. Buck a écrit :
> 
> I think the RIGHT fix is to trick Google into filing IANA paperwork so it 
> appears here:
> 
> https://www.iana.org/assignments/media-types/image.csv
> 
> I think if that is done, Debian will get it automatically.
> Is that right?

Hi Trent, that is right.

I see on the upstream mailing list that it is being discussed.

https://groups.google.com/a/webmproject.org/g/webp-discuss/c/gklBC0vn7NI/m/_bmsFb05AwAJ

In my opinion, it is unfair to call IANA's registration "paperwork",
"administrative work" or "time investment" (as in the thread linked
above).

Registration is done through a simple web form, without the need to
create an account.

https://www.iana.org/form/media-types

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#974851: mime-support: deprecated use of tempfile in run-mailcap

[Charles Plessy]

Le Sun, Nov 15, 2020 at 08:31:14PM +0530, Manoj Kummini a écrit :
> 
> I get a `tempfile deprecated' warning while using
> /usr/bin/run-mailcap on files that have a space or brackets in their
> names. I did not see this problem with filenames that did not require
> the escape character '\'.

Dear Manoj,

thank you for the report, I just prepared an update to correct that.

And you are right that the warning only appears with some filenames
tha do not require escape, as in that case run-mailcap is not going
to make a temporary copy.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#741151: gnu-standards: please update to 2013-12-17 version

[Fabrice BAUZAC]

Control: retitle -1 gnu-standards: please update from upstream
Control: severity -1 normal

This package is now over 10 years late compared to upstream, this is
getting quite annoying, especially as the popcon is not ridiculous.

Do you need help?

-- 
Fabrice Bauzac-Stehly
PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6
old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D

Bug#965564: gnu-standards: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Fabrice BAUZAC]

I confirm that debian/compat is currently 5.

Bug#577597: Still happens with util-linux 2.32-0.1 and Linux 4.17-rc7

[Chris Hofstaedtler]

Control: tags -1 + moreinfo

Hello Martin,

* Martin Steigerwald  [180531 22:38]:
> found 577597 2.32-0.1
> thanks
> 
> This issue still happens with util-linux 2.32-0.1 and on self compiled 
> Linux 4.17-rc7 with Debian Sid.

Please let me know if this is still a problem on a default install
of bullseye:

- with the Debian-built 5.9.x kernel
- with systemd
- as installed by the Debian Installer

If this happens only on non-default installs, please let me know the
differences from a default install. 

Also, please provide the kernel boot log - especially the rtc/clock
bits -, and output of
   stat /run/udev/hwclock-set
and output of
   timedatectl status
and output of 
   adjtime --print
.

Best,
Chris

Bug#978482: ITP: rx-java -- Reactive Extensions for the JVM

[Olek Wojnar]

Package: wnpp
Severity: wishlist
Owner: Olek Wojnar 

* Package name: rx-java
  Version : 3.0.7
  Upstream Author : David Karnok 
* URL : https://github.com/ReactiveX/RxJava
* License : Apache 2
  Programming Lang: Java
  Description : Reactive Extensions for the JVM
 Java VM implementation of Reactive Extensions: a library for composing
 asynchronous and event-based programs by using observable sequences.
 .
 It extends the observer pattern to support sequences of data/events and adds
 operators that allow you to compose sequences together declaratively while
 abstracting away concerns about things like low-level threading,
 synchronization, thread-safety and concurrent data structures.

This is a dependency of newer versions of Bazel.

Bug#977845: dgit: unhelpful behavior in case previous upload contained new upstream release

[Sean Whitton]

Hello,

On Mon 21 Dec 2020 at 09:01PM +01, Paul Gevers wrote:

> In the end I resorted to
> paul@mulciber ~/packages/bugs $ dgit clone f2fs-tools testing
> as unstable and testing have the same version, but that doesn't work if
> unstable and testing don't have the same version.

In this situation what it seems we want to achieve is

a) get the version you want to hack on into dgit as if `dgit clone` had
   given it you

b) make it easy to `dgit push` your new version, which is  based on the
   result of (a).

How dgit could automate this is if it could detect that the upload on
dgit-repos never made it to the archive, it could then prepare a new
repo for you as if there was nothing on dgit-repos, and then pseudomerge
that on top of the contents of dgit-repos, so a push would just work.

However, detecting whether an upload made it to the archive would
require incorporating a lot of idiosyncratic knowledge about dak into
dgit, I think, with a fair bit of guessing?  Or is the way that dak
keeps track of such things amenable to adding a new ftp-master API query
to find out?

In the meantime what I would have done is `apt-get source` followed by
`dgit import-dsc` followed by pseudomerging in the result of `dgit fetch
unstable`.  What do you think about the error message suggesting that
for this sort of situation?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#978481: mirror listing update for debian.utalca.cl

[Fabio Duran-Verdugo]

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

Submission-Type: update
Site: debian.utalca.cl
Type: leaf
Archive-architecture: amd64 i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Fabio Duran-Verdugo 
Country: CL Chile
Location: Talca
Sponsor: Escuela de Ingeniería Civil en Bioinformática, Universidad de Talca 
https://icb.utalca.cl, https://www.utalca.cl
Comment: After a data-center disaster, I got update the mirror debian.utalca.cl 
again.
 
 RSYNC_HOST=mirrors.sfo.kernel.org 
 
 And the cron is running every 6 hours.
 
 please reconsider including to repository list again.
 
 Thank you.




Trace Url: http://debian.utalca.cl/debian/project/trace/
Trace Url: http://debian.utalca.cl/debian/project/trace/ftp-master.debian.org
Trace Url: http://debian.utalca.cl/debian/project/trace/debian.utalca.cl

Bug#855203: hwclock-set: Synchronize from hwclock despite systemd presence

[Chris Hofstaedtler]

Hi,

* Lukas Wunner :
> Back in 2011, hwclock-set was amended to bail out if systemd is present.
> According to #629811 the rationale was that "systemd > 25 sets the
> hwclock itself, based on the contents of /etc/adjtime, so
> /lib/udev/hwclock-set should not do anything if running under systemd."
[..]
> But this doesn't work if the driver for the RTC is compiled as a module
> or if the kernel was compiled with CONFIG_RTC_HCTOSYS disabled.  One use
> case where both of these prerequisites are not met is the Raspberry Pi:
> Raspbian ships with a kernel which disables CONFIG_RTC_HCTOSYS and also
> compiles all RTC drivers as a module.  This makes sense because the
> Raspberry Pi does not possess an RTC.  Instead, people use add-on boards
> with various types of clocks and it wouldn't be reasonable to link all
> of their drivers into the kernel.

Is this still a problem on current Raspbian / current Raspberry Pis?

If so, does the RTC (once the module is loaded), appear as rtc0?

If all of this is true, I would ponder accepting a tight patch to
the hwclock-set udev helper. The helper should really only run when
hctosys did not happen yet.
One would still need to rely on something else for updating the RTC
later or on shutdown.

CC-ing pkg-systemd-maintainers for their input.

Chris

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Sean Whitton]

Hello Wouter,

On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote:

> My reasoning is that init scripts are the end goal, and that elogind is
> just a symptom of that end goal, and that therefore talking about
> elogind in isolation serves no purpose.

The GR specifically mentions elogind and not init scripts.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#978412: src:picolibc: fails to migrate to testing for too long: maintainer built arch:all binaries

[Keith Packard]

Paul Gevers  writes:

> Your package is only blocked because the arch:all binary package(s)
> aren't built on a buildd. Unfortunately the Debian infrastructure
> doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
> shortly do a no-changes source-only upload to DELAYED/15, closing this
> bug. Please let me know if I should delay or cancel that upload.

Oh, thanks so much for doing this upload -- I totally spaced doing a
source upload after 1.4.7 required a binary upload to go through the new
queue again for the added aarch64 binary package.

-- 
-keith


signature.asc
Description: PGP signature

Bug#978480: ITP: golang-github-muesli-termenv -- Advanced ANSI style & color support for your terminal applications

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-de...@lists.debian.org, francisco.ruvi...@riseup.net

* Package name: golang-github-muesli-termenv
  Version : 0.7.4
  Upstream Author : Christian Muehlhaeuser
* URL : https://github.com/muesli/termenv
* License : Expat
  Programming Lang: Go
  Description : Advanced ANSI style & color support for your terminal 
applications

 Termenv lets you safely use advanced styling options on the terminal.
 It gathers information about the terminal environment in terms of its
 ANSI & color support and offers you convenient methods to colorize
 and style your output, without you having to deal with all kinds of
 weird ANSI escape sequences and color conversions.

 It is a dependency for github-cli.

Bug#978451: RFS: oxygencursors/0.0.2012-06-kde4.8-4 [QA] -- Oxygen mouse cursor theme

[Christian Göttsche]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: oxygencursors
   Version : 0.0.2012-06-kde4.8-4
   Upstream Author : plasma-de...@kde.org
 * URL : https://techbase.kde.org/Projects/Oxygen
 * License : GPL-3+
   Section : x11

It builds those binary packages:

  oxygencursors - Oxygen mouse cursor theme

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/oxygencursors/oxygencursors_0.0.2012-06-kde4.8-4.dsc

Changes since the last upload:

 oxygencursors (0.0.2012-06-kde4.8-4) unstable; urgency=medium
 .
   * QA upload.
   * d/patches:
 - do not ship dolphin .directory entries
 - add no-drop and vertical-text svg images
 - enable 270dpi cursors
   * d/rules: add several common cursor symlinks (Closes: #696885)
   * d/control:
 - bump to std version 4.5.1 (no further changes)
 - add Enhances plasma-theme-oxygen
 - drop unneeded ${shlibs:Depends}
   * d/copyright: update Source and add Upstream-Contact

Regards,
Christian Göttsche

Bug#976791: closed by Debian FTP Masters (reply to Bastian Blank ) (Bug#976791: fixed in linux 5.10~rc7-1~exp1)

[Matt Corallo]

Note that this issue was not closed as CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH is still missing. The (relevant) diff 
between my (working, self-built) rc7 and 5.10.1 in exp is:


$ diff /boot/config-5.10.0-* | grep "SND\|SOUND"
< CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES=y
> # CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES is not set
< CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH=m
< CONFIG_SND_SOC_RT1308=m

On 12/13/20 6:03 AM, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the linux-image-amd64 package:

#976791: Enable CONFIG_SOUNDWIRE (and related drivers)

It has been closed by Debian FTP Masters  (reply to 
Bastian Blank ).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP Masters 
 (reply to Bastian Blank ) by
replying to this email.

Bug#978478: tegrarcm: upload required for libcrypto++ transition

[Sebastian Ramacher]

Source: tegrarcm
Version: 1.8-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org
Tags: sid bullseye

tegrarcm is in non-free and is not buildable on the buillds. So it
requires an upload to complete the libcrypto++ transition.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#978477: entropybroker: FTBFS on 32 bit architectures: error: narrowing conversion of ‘2147763207’ from ‘long unsigned int’ to ‘long int’ [-Wnarrowing]

[Sebastian Ramacher]

Source: entropybroker
Version: 2.9-4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

entropybroker FTBFS on 32 bit architectures:
| In file included from ComScire_R2000KU/qwqng.cpp:32:
| ComScire_R2000KU/qwqng.hpp:70:32: error: narrowing conversion of ‘2147763201’ 
from ‘long unsigned int’ to ‘long int’ [-Wnarrowing]
|70 | #define QNG_E_GENERAL_FAILURE  0x80044401L
|   |^~~
| ComScire_R2000KU/qwqng.cpp:786:7: note: in expansion of macro 
‘QNG_E_GENERAL_FAILURE’
|   786 |  case QNG_E_GENERAL_FAILURE:
|   |   ^

https://buildd.debian.org/status/fetch.php?pkg=entropybroker=i386=2.9-4=1609085617=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#584126: pain in ass cos depends on "default-mta"

[Markus Wanner]

On 12/27/20 5:56 PM, PICCORO McKAY Lenz wrote:
of course those packages can work with other mail suite but default (as 
just apt-get install does) install doe snot handle that! so dependences 
are wrong in all way!


Relax.  It can't be that bad.

The bug references version 0.64.2-1 (as of 2012), where courier-imap and 
courier-pop both depended on: `exim4 | mail-transport-agent`.  Nowadays, 
the dependencies are on `default-mta | mail-transport-agent`, which 
seems correct given that courier is *not* the default MTA on Debian.


Note that as per the popularity contest, many more users use 
courier-imap (0.44%) than courier-mta (0.02%), meaning that the vast 
majority of users of courier-imap actually *do* use it with an MTA other 
than courier.


I do not want to annoy that majority of users.  Nor am I aware of any 
significant warning or problem that arises should I try to use 
courier-imap in combination with courier-mta.  Just installing both 
packages works fine for me.  No matter even the order


Just install both packages.  But yes, if you want a non-default MTA, you 
need to explicitly say so.  That's intended behavior and not to be 
overridden by courier-imap.  And no, Courier is not the default and it 
is not likely to become in the future, either.


> Depends:  courier-mta | default-mta | mail-transport-agent

This clearly wouldn't change anything in case the default-mta 
(exim4-daemon-light) is already installed.  And would do the wrong thing 
(install courier-mta rather than the default-mta), if none of the above 
are installed, already, but the user chose to install only courier-imap, 
but not courier-mta.


Unless a real dependency issue (other than something boiling down to 
courier-mta not being the default MTA) comes up, I'm inclined to close 
this ticket.  So far, nothing substantial has been shown in this ticket.


Regards

Markus

Bug#978447: libnet-ldap-perl: new upstream version 0.67 available

[gregor herrmann]

On Sun, 27 Dec 2020 17:34:47 +0100, Peter Marschall wrote:

> yesterday I released a new upstream version of perl-ldap.
> It would be cool if the updated version made it into the next Debian release.

Thanks for the notice; I've uploaded the new release to unstable
right now.
 
Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Carole King: Smackwater Jack


signature.asc
Description: Digital Signature

Bug#974860: Forwarded to upstream

[Silvério Santos]

Danke Martin, gleichfalls.

After the upgrade you mentioned below the context menu not even opens when 
doing drag and drop. I have to move emails through the context menu.

On Thu, 24 Dec 2020 14:52:02 +0100 Martin Steigerwald  
wrote:
> Silvério Santos - 24.12.20, 14:18:18 CET:
> > forwarded -1 https://bugs.kde.org/show_bug.cgi?id=430787
> 
> Please retest once you upgraded to Plasma 5.20 and KF 5.77. They should 
> appear in testing soon.
> 
> Have a Merry Christmas if you celebrate it, have a quiet and peaceful 
> time,
> -- 
> Martin

Bug#940704: autopkgtests now failing

[Paolo Greppi]

I have enabled he upstream test suite on salsa, it fails with many of these:

FAIL __tests__/commands/install/integration.js
  ● Test suite failed to run

Cannot find module 'babel-plugin-transform-inline-imports-commonjs'
Require stack:
...

See: https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/1287491

Not sure how to proceed ..

Paolo

Bug#918755: Bug#978158: [upgrade-system] upgrade-system wants to delete package deluge and everything it depends on

[Chris Hofstaedtler]

Hi,

* Martin-Éric Racine  [201227 22:06]:
> Right, so in that case, there is no bug in upgrade-system.

I must disagree, see below.

> The backend 'deborphan --guess-all' simply makes broad assumptions
> about what is superflous libraries and, for some reason, it considers
> python-cffi-backend as superflous as explained in bug #918755.
> 
> In your case, the solution indeed is to add --no-guess-python to ORPHANOPTS.

[..]
> su 27. jouluk. 2020 klo 22.47 Rick Thomas (rick.tho...@pobox.com) kirjoitti:
> >
> > It looks like the problem is in deborphan.  /etc/upgrade-system.conf has
> > ORPHANOPTS="--guess-all --libdevel"

deborphan makes absolutely no promises on which packages it will
return. If upgrade-system uses deborphans output to automatically
remove packages, this is DANGEROUS, to say the least.

As said above, deborphan very clearly documents `--guess-*` (that
includes `--guess-all`) as "beware when using this!"

I believe this is a serious bug in upgrade-system's default
configuration.  Please stop this.

Chris

Bug#978005: [Pkg-julia-devel] Bug#978005: Julia Plots scaling error with Plots.GR

[Derek Woolverton]

> > Plots using GR are not scaled correctly.
>
> Please provide minimal broken examples so that we can test and try
> fixes.
>

I am not sure who controls the modules for Julia, the problem was with two
modules who's versions were not compatible.  After filing the ticket, one
of the modules updated to a compatible version, and all is working again.
If it is not Debian that is controlling this, do you know who is the
gatekeeper for these?  Not everything is at the "latest" version, so I was
guessing there was some intermediate group involved.

Thanks,
Derek W.

Bug#978474: xfwm4: Some native system applications do not follow the theme of windows.

[Andreas Ronnquist]

On Sun, 27 Dec 2020 18:04:01 -0300,
Wellington Almeida wrote:

>When changing the theme of windows in the system's appearance managers
>I noticed that some applications have not been modified.
>
>

Which programs doesn't change, and what theme are you changing to? I am
guessing you are setting a GTK3-only theme, and the programs that
doesn't change are GTK2 ones.

/Andreas Rönnquist
gus...@debian.org

Bug#978472: ITP: b3sum -- Command line tool for the BLAKE3 hash

[Adam Borowski]

On Mon, Dec 28, 2020 at 02:03:43AM +0530, karthek wrote:
> * Package name: b3sum
>   Upstream Author : Jack O'Connor 
> * URL : https://github.com/BLAKE3-team/BLAKE3
>   Description : Command line tool for the BLAKE3 hash
> 
> BLAKE3 is a cryptographic hash function that is much faster than MD5,
> SHA-1, SHA-2, SHA-3, and BLAKE2 and
> Secure, unlike MD5 and SHA-1. And secure against length extension.
> Note, This package includes binary "b3sum" which is built from official 
> multithreaded  implementation of BLAKE3 in rust.

Besides the Rust version, that upstream repository includes a C library.
You'll provide that in your packaging, right?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄ `

Bug#978474: xfwm4: Some native system applications do not follow the theme of windows.

[Wellington Almeida]

When changing the theme of windows in the system's appearance managers
I noticed that some applications have not been modified.


Em dom., 27 de dez. de 2020 às 17:45, Wellington Almeida <
wsalmei...@gmail.com> escreveu:

> Package: xfwm4
> Version: 4.16.0-1
> Severity: normal
> X-Debbugs-Cc: wsalmei...@gmail.com
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
> LANGUAGE=pt_BR:pt:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages xfwm4 depends on:
> ii  libc6 2.31-6
> ii  libcairo2 1.16.0-4
> ii  libepoxy0 1.5.4-1
> ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
> ii  libglib2.0-0  2.66.4-1
> ii  libgtk-3-03.24.24-1
> ii  libpango-1.0-01.46.2-3
> ii  libpangocairo-1.0-0   1.46.2-3
> ii  libstartup-notification0  0.12-6+b1
> ii  libwnck-3-0   3.36.0-1
> ii  libx11-6  2:1.6.12-1
> ii  libxcomposite11:0.4.5-1
> ii  libxdamage1   1:1.1.5-2
> ii  libxext6  2:1.3.3-1.1
> ii  libxfce4ui-2-04.16.0-1
> ii  libxfce4util7 4.16.0-1
> ii  libxfconf-0-3 4.16.0-2
> ii  libxfixes31:5.0.3-2
> ii  libxinerama1  2:1.1.4-2
> ii  libxpresent1  1.0.0-2+b10
> ii  libxrandr22:1.5.1-1
> ii  libxrender1   1:0.9.10-1
> ii  libxres1  2:1.2.0-4
>
> Versions of packages xfwm4 recommends:
> ii  librsvg2-common  2.50.2+dfsg-1
>
> Versions of packages xfwm4 suggests:
> ii  xfce4  4.16
>
> -- no debconf information
>

Bug#918755: Bug#978158: [upgrade-system] upgrade-system wants to delete package deluge and everything it depends on

[Martin-Éric Racine]

Right, so in that case, there is no bug in upgrade-system.

The backend 'deborphan --guess-all' simply makes broad assumptions
about what is superflous libraries and, for some reason, it considers
python-cffi-backend as superflous as explained in bug #918755.

In your case, the solution indeed is to add --no-guess-python to ORPHANOPTS.

Martin-Éric

su 27. jouluk. 2020 klo 22.47 Rick Thomas (rick.tho...@pobox.com) kirjoitti:
>
> It looks like the problem is in deborphan.  /etc/upgrade-system.conf has
> ORPHANOPTS="--guess-all --libdevel"
>
> and something about that combination leads deborphan to decide it doesn't 
> need the package "python-cffi-backend", which is a lineal dependent of 
> deborphan.  The reason that upgrade-system wants to purge deluge is that with 
> python-cffi-backend gone, deluge is missing a critical dependency.  This is 
> all described Bug#918755 .
>
> If I add "--no-guess-python" to the option list, deborphan no longer lists 
> python-cffi-backend,  but I'm concerned that doing that will have wider 
> side-effects.
>
> Details:
> rbthomas@monk:~$ deborphan --guess-all --libdevel
> python-cffi-backend
> rbthomas@monk:~$ deborphan --guess-all --no-guess-python --libdevel
> rbthomas@monk:~$
>
> Hope this helps!
> Rick
>
> On Sat, Dec 26, 2020, at 3:03 PM, Martin-Éric Racine wrote:
> > la 26. jouluk. 2020 klo 21.30 Rick Thomas (rbtho...@rcthomas.org) kirjoitti:
> > >
> > > Package: upgrade-system
> > > Version: 1.7.3.1
> > > Severity: normal
> > >
> > > --- Please enter the report below this line. ---
> > >
> > > The package "deluge" is manually (i.e. not "auto") installed on my
> > > system.  I use it daily. But when I try to run "upgrade-system" it lists
> > > deluge and a bunch of other packages that deluge depends on as needing
> > > to be removed.  Why is this?
> >
> > Check the deborphan options you have configured in
> > /etc/upgrade-system.conf for something that tries to purge python
> > packages. To manually fine-tune this, you can run 'sudo deborphan'
> > with different combinations of --guess options.
> >
> > Martin-Éric
> >

Bug#978476: RFS: pyenv/1.2.21-1 [ITP] -- Simple Python version management

[karthek]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: pyenv
   Version : 1.2.21-1
   Upstream Author : Yamashita, Yuu 
* URL : https://github.com/pyenv/pyenv
* License : Expat, GPL-3.0+
* Vcs : [fill in URL of packaging vcs]
   Section : devel

It builds those binary packages:

  pyenv-plugin-python-build - python-build  plugin for pyenv
  pyenv - Simple Python version management

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/pyenv/pyenv_1.2.21-1.dsc

Changes for the initial release:

pyenv (1.2.21-1) unstable; urgency=low
.
   * Initial release. Closes: #978149

Regards,

 karthek

Bug#974533: new upstream (20201110 ) for RAPL/Platypus fixes

[Henrique de Moraes Holschuh]

On Wed, 09 Dec 2020, Matt Taggart wrote:
> When will this get fixed in buster? I had thought it might go into the
> buster stable release update but I don't see it (but also it's non-free so
> weird).

I lost the time window for the current point release, so update
3.20201118.1 will be issued to unstable, then bpo (after it clears
testing), and will target the next stable point release.  It is mostly
the same as 3.20201110.1, it just adds the update for a Pentium-class /
Celeron-class processor model.

The 2020/11 batch of updates (20201110, 20201112, 20201118) *will* cause
regressions.  Some are new regressions, others are long-time regressions
that have not yet been fixed (some *cannot* be fixed, you *must* get a
firmware update to avoid them).

For skylake, we have *reintroduced* regressions with 3.20201110.1 and
later -- hopefully not on as many systems as before -- as we can no
longer hold back the security microcode updates for those.  If your
0x406e3 / 0x506e3 system crashes with the 202011* series of microcode
updates, you *must* get a proper firmware update, or repurpose them to
some use where the security fixes in the missing updates are irrelevant.

-- 
  Henrique Holschuh

Bug#918755: Bug#978158: [upgrade-system] upgrade-system wants to delete package deluge and everything it depends on

[Rick Thomas]

It looks like the problem is in deborphan.  /etc/upgrade-system.conf has
ORPHANOPTS="--guess-all --libdevel"

and something about that combination leads deborphan to decide it doesn't need 
the package "python-cffi-backend", which is a lineal dependent of deborphan.  
The reason that upgrade-system wants to purge deluge is that with 
python-cffi-backend gone, deluge is missing a critical dependency.  This is all 
described Bug#918755 .

If I add "--no-guess-python" to the option list, deborphan no longer lists 
python-cffi-backend,  but I'm concerned that doing that will have wider 
side-effects.

Details:
rbthomas@monk:~$ deborphan --guess-all --libdevel
python-cffi-backend
rbthomas@monk:~$ deborphan --guess-all --no-guess-python --libdevel
rbthomas@monk:~$

Hope this helps!
Rick

On Sat, Dec 26, 2020, at 3:03 PM, Martin-Éric Racine wrote:
> la 26. jouluk. 2020 klo 21.30 Rick Thomas (rbtho...@rcthomas.org) kirjoitti:
> >
> > Package: upgrade-system
> > Version: 1.7.3.1
> > Severity: normal
> >
> > --- Please enter the report below this line. ---
> >
> > The package "deluge" is manually (i.e. not "auto") installed on my
> > system.  I use it daily. But when I try to run "upgrade-system" it lists
> > deluge and a bunch of other packages that deluge depends on as needing
> > to be removed.  Why is this?
> 
> Check the deborphan options you have configured in
> /etc/upgrade-system.conf for something that tries to purge python
> packages. To manually fine-tune this, you can run 'sudo deborphan'
> with different combinations of --guess options.
> 
> Martin-Éric
>

Bug#978475: hugin lens calibration gui asserts at startup

[Oswald Buddenhagen]

Package: hugin
Version: 2020.0.0+dfsg-1
Severity: important

ASSERT INFO:
../src/gtk/bitmap.cpp(1262): assert "bmpData->m_pixbufNoMask" failed in 
SetSourceSurface(): no bitmap data

BACKTRACE:
[1] wxBitmap::SetSourceSurface(_cairo*, int, int, wxColour const*, wxColour 
const*) const
[2] wxBitmap::Draw(_cairo*, int, int, bool, wxColour const*, wxColour const*) 
const
[3] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&)
[4] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[5] wxEvtHandler::TryHereOnly(wxEvent&)
[6] wxEvtHandler::ProcessEventLocally(wxEvent&)
[7] wxEvtHandler::ProcessEvent(wxEvent&)
[8] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[9] wxWindow::GTKSendPaintEvents(_cairo*)
[10] g_closure_invoke
[11] g_signal_emit_valist
[12] g_signal_emit
[13] gtk_container_propagate_draw
[14] gtk_container_propagate_draw
[15] gtk_container_propagate_draw
[16] g_closure_invoke
[17] g_signal_emit_valist
[18] g_signal_emit
[19] gtk_container_propagate_draw
[20] g_closure_invoke
[21] g_signal_emit_valist
[22] g_signal_emit
[23] gtk_container_propagate_draw
[24] gtk_container_propagate_draw
[25] gtk_main_do_event
[26] g_signal_emit_valist
[27] g_signal_emit
[28] g_main_context_dispatch
[29] g_main_loop_run
[30] gtk_main
[31] wxGUIEventLoop::DoRun()
[32] wxEventLoopBase::Run()
[33] wxAppConsoleBase::MainLoop()
[34] wxEntry(int&, wchar_t**)
[35] __libc_start_main

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

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

Versions of packages hugin depends on:
ii  enblend 4.2-7
ii  enfuse  4.2-7
ii  hugin-tools 2020.0.0+dfsg-1
ii  libc6   2.31-6
ii  libexiv2-27 0.27.3-3
ii  libfftw3-double33.3.8-2
ii  libgcc-s1   10.2.1-3
ii  libglew2.1  2.1.0-4+b1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libglx0 1.3.2-1
ii  libgomp110.2.1-3
ii  libimage-exiftool-perl  12.13+dfsg-1
ii  liblcms2-2  2.9-4+b1
ii  libopengl0  1.3.2-1
ii  libpano13-3 2.9.20~rc2+dfsg-3
ii  libsqlite3-03.34.0-1
ii  libstdc++6  10.2.1-3
ii  libtiff54.2.0-1
ii  libvigraimpex11 1.11.1+dfsg-7+b7
ii  libwxbase3.0-0v53.0.5.1+dfsg-2
ii  libwxgtk3.0-gtk3-0v53.0.5.1+dfsg-2
ii  make4.3-4

hugin recommends no packages.

Versions of packages hugin suggests:
pn  dcraw | rawtherapee | darktable  

-- no debconf information

Bug#978474: xfwm4: Some native system applications do not follow the theme of windows.

[Wellington Almeida]

Package: xfwm4
Version: 4.16.0-1
Severity: normal
X-Debbugs-Cc: wsalmei...@gmail.com

Dear Maintainer,

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

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

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



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

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

Versions of packages xfwm4 depends on:
ii  libc6 2.31-6
ii  libcairo2 1.16.0-4
ii  libepoxy0 1.5.4-1
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
ii  libglib2.0-0  2.66.4-1
ii  libgtk-3-03.24.24-1
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libstartup-notification0  0.12-6+b1
ii  libwnck-3-0   3.36.0-1
ii  libx11-6  2:1.6.12-1
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.3-1.1
ii  libxfce4ui-2-04.16.0-1
ii  libxfce4util7 4.16.0-1
ii  libxfconf-0-3 4.16.0-2
ii  libxfixes31:5.0.3-2
ii  libxinerama1  2:1.1.4-2
ii  libxpresent1  1.0.0-2+b10
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxres1  2:1.2.0-4

Versions of packages xfwm4 recommends:
ii  librsvg2-common  2.50.2+dfsg-1

Versions of packages xfwm4 suggests:
ii  xfce4  4.16

-- no debconf information

Bug#970066: atftp: diff for NMU version 0.7.git20120829-3.2

[Salvatore Bonaccorso]

Control: tags 970066 + patch
Control: tags 970066 + pending


Dear maintainer,

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

Regards,
Salvatore
diff -u atftp-0.7.git20120829/debian/changelog atftp-0.7.git20120829/debian/changelog
--- atftp-0.7.git20120829/debian/changelog
+++ atftp-0.7.git20120829/debian/changelog
@@ -1,3 +1,10 @@
+atftp (0.7.git20120829-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix for DoS issue CVE-2020-6097 (Closes: #970066)
+
+ -- Salvatore Bonaccorso   Sun, 27 Dec 2020 21:28:40 +0100
+
 atftp (0.7.git20120829-3.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -u atftp-0.7.git20120829/tftp_def.c atftp-0.7.git20120829/tftp_def.c
--- atftp-0.7.git20120829/tftp_def.c
+++ atftp-0.7.git20120829/tftp_def.c
@@ -180,6 +180,15 @@
  return OK;
 }
 
+int
+sockaddr_family_supported(const struct sockaddr_storage *ss)
+{
+ if (ss->ss_family == AF_INET || ss->ss_family == AF_INET6)
+  return 1;
+ else
+  return 0;
+}
+
 char *
 sockaddr_print_addr(const struct sockaddr_storage *ss, char *buf, size_t len)
 {
@@ -189,7 +198,7 @@
  else if (ss->ss_family == AF_INET6)
   addr = &((const struct sockaddr_in6 *)ss)->sin6_addr;
  else
-  assert(!"sockaddr_print: unsupported address family");
+  return "sockaddr_print: unsupported address family";
  return (char *)inet_ntop(ss->ss_family, addr, buf, len);
 }
 
diff -u atftp-0.7.git20120829/tftp_def.h atftp-0.7.git20120829/tftp_def.h
--- atftp-0.7.git20120829/tftp_def.h
+++ atftp-0.7.git20120829/tftp_def.h
@@ -54,6 +54,7 @@
 inline char *Strncpy(char *to, const char *from, size_t size);
 int Gethostbyname(char *addr, struct hostent *host);
 
+int sockaddr_family_supported(const struct sockaddr_storage *ss);
 char *sockaddr_print_addr(const struct sockaddr_storage *, char *, size_t);
 #define SOCKADDR_PRINT_ADDR_LEN INET6_ADDRSTRLEN
 uint16_t sockaddr_get_port(const struct sockaddr_storage *);
diff -u atftp-0.7.git20120829/tftpd.c atftp-0.7.git20120829/tftpd.c
--- atftp-0.7.git20120829/tftpd.c
+++ atftp-0.7.git20120829/tftpd.c
@@ -644,6 +644,11 @@
  }
 
 #ifdef HAVE_WRAP
+ if (!abort && !sockaddr_family_supported(>client_info->client))
+ {
+  logger(LOG_ERR, "Connection from unsupported network address family refused");
+  abort = 1;
+ }
  if (!abort)
  {
   /* Verify the client has access. We don't look for the name but
diff -u atftp-0.7.git20120829/tftpd_mtftp.c atftp-0.7.git20120829/tftpd_mtftp.c
--- atftp-0.7.git20120829/tftpd_mtftp.c
+++ atftp-0.7.git20120829/tftpd_mtftp.c
@@ -393,6 +393,11 @@
 _size, data->data_buffer);
 
 #ifdef HAVE_WRAP
+   if (!sockaddr_family_supported())
+   {
+logger(LOG_ERR, "mtftp: Connection from unsupported network address family refused");
+continue;
+   }
/* Verify the client has access. We don't look for the name but
   rely only on the IP address for that. */
sockaddr_print_addr(, addr_str, sizeof(addr_str));

Bug#978473: Please, enable autopkgtest

[David Prévot]

Package: php-php-gettext
Severity: wishlist

Hi,

The upstream testsuite is run at buildtime. It would be nice to also run
it as autopkgtest, that would allow us to detect incompatibility earlier
(e.g., regression with new version of PHPUnit (9) as #978378).

Thanks in advance

Regards

David


signature.asc
Description: PGP signature

Bug#978472: ITP: b3sum -- Command line tool for the BLAKE3 hash

[karthek]

Package: wnpp
Severity: wishlist
Owner: karthek 
X-Debbugs-Cc: debian-de...@lists.debian.org, frustra...@karthek.com

* Package name: b3sum
  Version : 0.3.7
  Upstream Author : Jack O'Connor 
* URL : https://github.com/BLAKE3-team/BLAKE3
* License : CC0-1.0 or Apache-2.0
  Programming Lang: rust
  Description : Command line tool for the BLAKE3 hash

BLAKE3 is a cryptographic hash function that is much faster than MD5,
SHA-1, SHA-2, SHA-3, and BLAKE2 and
Secure, unlike MD5 and SHA-1. And secure against length extension.
Note, This package includes binary "b3sum" which is built from official 
multithreaded  implementation of BLAKE3 in rust.

I plan to maintain this package

Bug#978471: waybar fails to launch

[Michele Cane]

Package: waybar
Version: 0.9.4-1+b1
Severity: important

Dear Maintainer,

After upgraing my system recently waybar fails to launch.

The waybar version has not changeed therefore this must be related to some 
other package.

When launching from terminal I receive the following error:

waybar: symbol lookup error: waybar: undefined symbol: 
_ZN6spdlog7details7log_msgC1ENS_10source_locEN3fmt2v617basic_string_viewIcEENS_5level10level_enumES6_

happy to provide more details.

Best regards

Mike

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

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

Versions of packages waybar depends on:
ii  init-system-helpers  1.60
ii  libc62.31-6
ii  libdbusmenu-gtk3-4   18.10.20180917~bzr492+repack1-2
ii  libgcc-s110.2.1-3
ii  libglib2.0-0 2.66.4-1
ii  libglibmm-2.4-1v52.64.2-2
ii  libgtk-3-0   3.24.24-1
ii  libgtk-layer-shell0  0.5.2-1
ii  libgtkmm-3.0-1v5 3.24.2-2
ii  libjsoncpp24 1.9.4-4
ii  libmpdclient22.19-1
ii  libnl-3-200  3.4.0-1+b1
ii  libnl-genl-3-200 3.4.0-1+b1
ii  libpulse013.0-5
ii  libsigc++-2.0-0v52.10.4-2
ii  libspdlog1   1:1.8.1+ds-2+b1
ii  libstdc++6   10.2.1-3
ii  libudev1 247.2-3
ii  libwayland-client0   1.18.0-2~exp1.1

waybar recommends no packages.

Versions of packages waybar suggests:
pn  fonts-font-awesome  
ii  libappindicator3-1  0.4.92-8
ii  sway1.5-7

-- no debconf information

Bug#977713: scid: Circular package dependency tk8.5 vs tk8.6 prevents scid from running

[fm]

As a matter of fact, changing lines 37-38 of /usr/games/scid from

package require Tk  8.5
if {$tcl_version == 8.5} { catch {package require img::png} }

to

# package require Tk  8.5
if {$tcl_version == 8.6} { catch {package require img::png} }

seems necessary but is sufficient to have scid running.
Whether the issue is scid or tcl or tk related remains mysterious to me.

Best,
--
fm

Bug#978443: RFS: vnstat/2.6-3 -- console-based network traffic monitor

[Christian Göttsche]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: vnstat
   Version : 2.6-3
   Upstream Author : Teemu Toivola 
 * URL : https://humdi.net/vnstat/
 * License : GPL-any, GPL-2
 * Vcs : https://salsa.debian.org/debian/vnstat
   Section : net

It builds those binary packages:

  vnstati - image output support for vnStat
  vnstat - console-based network traffic monitor

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/v/vnstat/vnstat_2.6-3.dsc

Changes since the last upload:

 vnstat (2.6-3) unstable; urgency=medium
 .
   [ Debian Janitor ]
   * Set upstream metadata fields: Bug-Submit, Repository.
   * Remove obsolete field Name from debian/upstream/metadata (already
present in
 machine-readable debian/copyright).
 .
   [ Christian Göttsche ]
   * debian: run wrap-and-sort
   * d/control: bump to std version 4.5.1 (no further changes)
   * d/patches: cherry-pick fitting upstream commits for Bullseye

Regards,
 Christian Göttsche

Bug#978470: libolecf: memory tests fundamentally broken, please disable them on riscv64

[Aurelien Jarno]

Source: libolecf
Version: 20181231-1.1
Severity: normal
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

fails to build on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=libolecf=riscv64=20181231-1.1=1580597074=0

This is due to fundamentally broken tests assuming that memcpy and
memset can fail returning NULL, and interposing these libc functions in
the tests with functions that sometimes return NULL. This tests should
be simply removed as they do not make sense. See bug #978433 for more
details as the same code is basically replicated in dozen of packages.

A simpler way to fix the issue for riscv64 is to disable all memory
tests on this architecture, as it is already done for a long list of
cases. This is what the patch below does:

--- libolecf-20181231/debian/patches/01-disable-memory-tests-on-riscv64.patch   
1970-01-01 01:00:00.0 +0100
+++ libolecf-20181231/debian/patches/01-disable-memory-tests-on-riscv64.patch   
2020-12-27 15:08:03.0 +0100
@@ -0,0 +1,11 @@
+--- libolecf-20181231.orig/tests/olecf_test_memory.h
 libolecf-20181231/tests/olecf_test_memory.h
+@@ -28,7 +28,7 @@
+ extern "C" {
+ #endif
+ 
+-#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBOLECF_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( HAVE_ASAN )
++#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBOLECF_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( __riscv ) && !defined( HAVE_ASAN )
+ #define HAVE_OLECF_TEST_MEMORY1
+ #endif
+ 
--- libolecf-20181231/debian/patches/series 1970-01-01 01:00:00.0 
+0100
+++ libolecf-20181231/debian/patches/series 2020-12-27 15:08:03.0 
+0100
@@ -0,0 +1 @@
+01-disable-memory-tests-on-riscv64.patch

Regards,
Aurelien

Bug#978469: libmsiecf: memory tests fundamentally broken, please disable them on riscv64

[Aurelien Jarno]

Source: libmsiecf
Version: 20181227-1.1
Severity: normal
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

fails to build on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=libmsiecf=riscv64=20181227-1.1=1580596640=0

This is due to fundamentally broken tests assuming that memcpy and
memset can fail returning NULL, and interposing these libc functions in
the tests with functions that sometimes return NULL. This tests should
be simply removed as they do not make sense. See bug #978433 for more
details as the same code is basically replicated in dozen of packages.

A simpler way to fix the issue for riscv64 is to disable all memory
tests on this architecture, as it is already done for a long list of
cases. This is what the patch below does:

--- libmsiecf-20181227/debian/patches/01-disable-memory-tests-on-riscv64.patch  
1970-01-01 01:00:00.0 +0100
+++ libmsiecf-20181227/debian/patches/01-disable-memory-tests-on-riscv64.patch  
2020-12-27 14:51:16.0 +0100
@@ -0,0 +1,11 @@
+--- libmsiecf-20181227.orig/tests/msiecf_test_memory.h
 libmsiecf-20181227/tests/msiecf_test_memory.h
+@@ -28,7 +28,7 @@
+ extern "C" {
+ #endif
+ 
+-#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBMSIECF_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( HAVE_ASAN )
++#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBMSIECF_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( __riscv ) && !defined( HAVE_ASAN )
+ #define HAVE_MSIECF_TEST_MEMORY   1
+ #endif
+ 
--- libmsiecf-20181227/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ libmsiecf-20181227/debian/patches/series2020-12-27 14:51:16.0 
+0100
@@ -0,0 +1 @@
+01-disable-memory-tests-on-riscv64.patch

Regards,
Aurelien

Bug#978468: libluksde: memory tests fundamentally broken, please disable them on riscv64

[Aurelien Jarno]

Source: libluksde
Version: 20200205-1
Severity: normal 
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

fails to build on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=libluksde=riscv64=20200205-1=1607269155=0

This is due to fundamentally broken tests assuming that memcpy and
memset can fail returning NULL, and interposing these libc functions in
the tests with functions that sometimes return NULL. This tests should
be simply removed as they do not make sense. See bug #978433 for more
details as the same code is basically replicated in dozen of packages.

A simpler way to fix the issue for riscv64 is to disable all memory
tests on this architecture, as it is already done for a long list of
cases. This is what the patch below does:

--- libluksde-20200205/debian/patches/01-disable-memory-tests-on-riscv64.patch  
1970-01-01 01:00:00.0 +0100
+++ libluksde-20200205/debian/patches/01-disable-memory-tests-on-riscv64.patch  
2020-12-27 14:51:15.0 +0100
@@ -0,0 +1,11 @@
+--- libluksde-20200205.orig/tests/luksde_test_memory.h
 libluksde-20200205/tests/luksde_test_memory.h
+@@ -28,7 +28,7 @@
+ extern "C" {
+ #endif
+ 
+-#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBLUKSDE_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( HAVE_ASAN )
++#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBLUKSDE_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( __riscv ) && !defined( HAVE_ASAN )
+ #define HAVE_LUKSDE_TEST_MEMORY   1
+ #endif
+ 
--- libluksde-20200205/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ libluksde-20200205/debian/patches/series2020-12-27 14:51:15.0 
+0100
@@ -0,0 +1 @@
+01-disable-memory-tests-on-riscv64.patch

Regards,
Aurelien

Bug#978467: libfsxfs: memory tests fundamentally broken, please disable them on riscv64

[Aurelien Jarno]

Source: libfsxfs
Version: 20201117-1
Severity: normal 
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

fails to build on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=libfsxfs=riscv64=20201117-1=1607268287=0

This is due to fundamentally broken tests assuming that memcpy and
memset can fail returning NULL, and interposing these libc functions in
the tests with functions that sometimes return NULL. This tests should
be simply removed as they do not make sense. See bug #978433 for more
details as the same code is basically replicated in dozen of packages.

A simpler way to fix the issue for riscv64 is to disable all memory
tests on this architecture, as it is already done for a long list of
cases. This is what the patch below does:

--- libfsxfs-20201117/debian/patches/01-disable-memory-tests-on-riscv64.patch   
1970-01-01 01:00:00.0 +0100
+++ libfsxfs-20201117/debian/patches/01-disable-memory-tests-on-riscv64.patch   
2020-12-27 14:51:14.0 +0100
@@ -0,0 +1,11 @@
+--- libfsxfs-20201117.orig/tests/fsxfs_test_memory.h
 libfsxfs-20201117/tests/fsxfs_test_memory.h
+@@ -28,7 +28,7 @@
+ extern "C" {
+ #endif
+ 
+-#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBFSXFS_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( HAVE_ASAN )
++#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBFSXFS_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( __riscv ) && !defined( HAVE_ASAN )
+ #define HAVE_FSXFS_TEST_MEMORY1
+ #endif
+ 
--- libfsxfs-20201117/debian/patches/series 1970-01-01 01:00:00.0 
+0100
+++ libfsxfs-20201117/debian/patches/series 2020-12-27 14:51:14.0 
+0100
@@ -0,0 +1 @@
+01-disable-memory-tests-on-riscv64.patch

Regards,
Aurelien

Bug#978466: libfsntfs: memory tests fundamentally broken, please disable them on riscv64

[Aurelien Jarno]

Source: libfsntfs
Version: 20200921-1
Severity: normal 
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

fails to build on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=libfsntfs=riscv64=20200921-1=1604917720=0

This is due to fundamentally broken tests assuming that memcpy and
memset can fail returning NULL, and interposing these libc functions in
the tests with functions that sometimes return NULL. This tests should
be simply removed as they do not make sense. See bug #978433 for more
details as the same code is basically replicated in dozen of packages.

A simpler way to fix the issue for riscv64 is to disable all memory
tests on this architecture, as it is already done for a long list of
cases. This is what the patch below does:

--- libfsntfs-20200921/debian/patches/01-disable-memory-tests-on-riscv64.patch  
1970-01-01 01:00:00.0 +0100
+++ libfsntfs-20200921/debian/patches/01-disable-memory-tests-on-riscv64.patch  
2020-12-27 14:51:12.0 +0100
@@ -0,0 +1,11 @@
+--- libfsntfs-20200921.orig/tests/fsntfs_test_memory.h
 libfsntfs-20200921/tests/fsntfs_test_memory.h
+@@ -28,7 +28,7 @@
+ extern "C" {
+ #endif
+ 
+-#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBFSNTFS_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( HAVE_ASAN )
++#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBFSNTFS_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( __riscv ) && !defined( HAVE_ASAN )
+ #define HAVE_FSNTFS_TEST_MEMORY   1
+ #endif
+ 
--- libfsntfs-20200921/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ libfsntfs-20200921/debian/patches/series2020-12-27 14:51:12.0 
+0100
@@ -0,0 +1 @@
+01-disable-memory-tests-on-riscv64.patch

Regards,
Aurelien

Bug#978465: libfshfs: memory tests fundamentally broken, please disable them on riscv64

[Aurelien Jarno]

Source: libfshfs
Version: 20201104-1
Severity: normal 
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

fails to build on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=libfshfs=riscv64=20201104-1=1607268197=0

This is due to fundamentally broken tests assuming that memcpy and
memset can fail returning NULL, and interposing these libc functions in
the tests with functions that sometimes return NULL. This tests should
be simply removed as they do not make sense. See bug #978433 for more
details as the same code is basically replicated in dozen of packages.

A simpler way to fix the issue for riscv64 is to disable all memory
tests on this architecture, as it is already done for a long list of
cases. This is what the patch below does:

--- libfshfs-20201104/debian/patches/01-disable-memory-tests-on-riscv64.patch   
1970-01-01 01:00:00.0 +0100
+++ libfshfs-20201104/debian/patches/01-disable-memory-tests-on-riscv64.patch   
2020-12-27 14:51:11.0 +0100
@@ -0,0 +1,11 @@
+--- libfshfs-20201104.orig/tests/fshfs_test_memory.h
 libfshfs-20201104/tests/fshfs_test_memory.h
+@@ -28,7 +28,7 @@
+ extern "C" {
+ #endif
+ 
+-#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBFSHFS_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( HAVE_ASAN )
++#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBFSHFS_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( __riscv ) && !defined( HAVE_ASAN )
+ #define HAVE_FSHFS_TEST_MEMORY1
+ #endif
+ 
--- libfshfs-20201104/debian/patches/series 1970-01-01 01:00:00.0 
+0100
+++ libfshfs-20201104/debian/patches/series 2020-12-27 14:51:11.0 
+0100
@@ -0,0 +1 @@
+01-disable-memory-tests-on-riscv64.patch

Regards,
Aurelien

Bug#978464: libfsext: memory tests fundamentally broken, please disable them on riscv64

[Aurelien Jarno]

Source: libfsext
Version: 20201107-1
Severity: normal 
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

fails to build on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=libfsext=riscv64=20201107-1=1608392399=0

This is due to fundamentally broken tests assuming that memcpy and
memset can fail returning NULL, and interposing these libc functions in
the tests with functions that sometimes return NULL. This tests should
be simply removed as they do not make sense. See bug #978433 for more
details as the same code is basically replicated in dozen of packages.

A simpler way to fix the issue for riscv64 is to disable all memory
tests on this architecture, as it is already done for a long list of
cases. This is what the patch below does:

--- libfsext-20201107/debian/patches/01-disable-memory-tests-on-riscv64.patch   
1970-01-01 01:00:00.0 +0100
+++ libfsext-20201107/debian/patches/01-disable-memory-tests-on-riscv64.patch   
2020-12-27 14:51:05.0 +0100
@@ -0,0 +1,11 @@
+--- libfsext-20201107.orig/tests/fsext_test_memory.h
 libfsext-20201107/tests/fsext_test_memory.h
+@@ -28,7 +28,7 @@
+ extern "C" {
+ #endif
+ 
+-#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBFSEXT_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( HAVE_ASAN )
++#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBFSEXT_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( __riscv ) && !defined( HAVE_ASAN )
+ #define HAVE_FSEXT_TEST_MEMORY1
+ #endif
+ 
--- libfsext-20201107/debian/patches/series 1970-01-01 01:00:00.0 
+0100
+++ libfsext-20201107/debian/patches/series 2020-12-27 14:51:05.0 
+0100
@@ -0,0 +1 @@
+01-disable-memory-tests-on-riscv64.patch

Regards,
Aurelien

Bug#978463: libfsapfs: memory tests fundamentally broken, please disable them on riscv64

[Aurelien Jarno]

Source: libfsapfs
Version: 20201107-1
Severity: normal
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

fails to build on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=libfsapfs=riscv64=20201107-1=1607191812=0

This is due to fundamentally broken tests assuming that memcpy and
memset can fail returning NULL, and interposing these libc functions in
the tests with functions that sometimes return NULL. This tests should
be simply removed as they do not make sense. See bug #978433 for more
details as the same code is basically replicated in dozen of packages.

A simpler way to fix the issue for riscv64 is to disable all memory
tests on this architecture, as it is already done for a long list of
cases. This is what the patch below does:

--- libfsapfs-20201107/debian/patches/01-disable-memory-tests-on-riscv64.patch  
1970-01-01 01:00:00.0 +0100
+++ libfsapfs-20201107/debian/patches/01-disable-memory-tests-on-riscv64.patch  
2020-12-27 14:46:43.0 +0100
@@ -0,0 +1,11 @@
+--- libfsapfs-20201107.orig/tests/fsapfs_test_memory.h
 libfsapfs-20201107/tests/fsapfs_test_memory.h
+@@ -28,7 +28,7 @@
+ extern "C" {
+ #endif
+ 
+-#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBFSAPFS_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( HAVE_ASAN )
++#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBFSAPFS_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( __riscv ) && !defined( HAVE_ASAN )
+ #define HAVE_FSAPFS_TEST_MEMORY   1
+ #endif
+ 
--- libfsapfs-20201107/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ libfsapfs-20201107/debian/patches/series2020-12-27 14:46:43.0 
+0100
@@ -0,0 +1 @@
+01-disable-memory-tests-on-riscv64.patch

Regards,
Aurelien

Bug#978462: libevtx: memory tests fundamentally broken, please disable them on riscv64

[Aurelien Jarno]

Source: libevtx
Version: 20181227-1.1
Severity: normal
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

libevtx fails to build on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=libevtx=riscv64=20181227-1.1=1584612286=0

This is due to fundamentally broken tests assuming that memcpy and
memset can fail returning NULL, and interposing these libc functions in
the tests with functions that sometimes return NULL. This tests should
be simply removed as they do not make sense. See bug #978433 for more
details as the same code is basically replicated in dozen of packages.

A simpler way to fix the issue for riscv64 is to disable all memory
tests on this architecture, as it is already done for a long list of
cases. This is what the patch below does:

--- libevtx-20181227/debian/patches/01-disable-memory-tests-on-riscv64.patch
1970-01-01 01:00:00.0 +0100
+++ libevtx-20181227/debian/patches/01-disable-memory-tests-on-riscv64.patch
2020-12-27 14:36:09.0 +0100
@@ -0,0 +1,11 @@
+--- libevtx-20181227.orig/tests/evtx_test_memory.h
 libevtx-20181227/tests/evtx_test_memory.h
+@@ -28,7 +28,7 @@
+ extern "C" {
+ #endif
+ 
+-#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBEVTX_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( HAVE_ASAN )
++#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBEVTX_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( __riscv ) && !defined( HAVE_ASAN )
+ #define HAVE_EVTX_TEST_MEMORY 1
+ #endif
+ 
--- libevtx-20181227/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ libevtx-20181227/debian/patches/series  2020-12-27 14:36:09.0 
+0100
@@ -0,0 +1 @@
+01-disable-memory-tests-on-riscv64.patch

Regards,
Aurelien

Bug#978461: libbde: memory tests fundamentally broken, please disable them on riscv64

[Aurelien Jarno]

Source: libbde
Version: 20190102-1.1
Severity: normal
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

libbde fails to build on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=libbde=riscv64=20190102-1.1=1595831915=0

This is due to fundamentally broken tests assuming that memcpy and
memset can fail returning NULL, and interposing these libc functions in
the tests with functions that sometimes return NULL. This tests should
be simply removed as they do not make sense. See bug #978433 for more
details as the same code is basically replicated in dozen of packages.

A simpler way to fix the issue for riscv64 is to disable all memory
tests on this architecture, as it is already done for a long list of
cases. This is what the patch below does:

--- libbde-20190102/debian/patches/01-disable-memory-tests-on-riscv64.patch 
1970-01-01 01:00:00.0 +0100
+++ libbde-20190102/debian/patches/01-disable-memory-tests-on-riscv64.patch 
2020-12-27 13:58:56.0 +0100
@@ -0,0 +1,11 @@
+--- libbde-20190102.orig/tests/bde_test_memory.h
 libbde-20190102/tests/bde_test_memory.h
+@@ -28,7 +28,7 @@
+ extern "C" {
+ #endif
+ 
+-#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBBDE_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( HAVE_ASAN )
++#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBBDE_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( __riscv ) && !defined( HAVE_ASAN )
+ #define HAVE_BDE_TEST_MEMORY  1
+ #endif
+ 
--- libbde-20190102/debian/patches/series   1970-01-01 01:00:00.0 
+0100
+++ libbde-20190102/debian/patches/series   2020-12-27 13:58:56.0 
+0100
@@ -0,0 +1 @@
+01-disable-memory-tests-on-riscv64.patch

Regards,
Aurelien

Bug#978460: libcreg: memory tests fundamentally broken, please disable them on riscv64

[Aurelien Jarno]

Source: libcreg
Version: 20200725-1
Severity: normal
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

libcreg fails to build on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=libcreg=riscv64=20200725-1=1607267787=0

This is due to fundamentally broken tests assuming that memcpy and
memset can fail returning NULL, and interposing these libc functions in
the tests with functions that sometimes return NULL. This tests should
be simply removed as they do not make sense. See bug #978433 for more
details as the same code is basically replicated in dozen of packages.

A simpler way to fix the issue for riscv64 is to disable all memory
tests on this architecture, as it is already done for a long list of
cases. This is what the patch below does:

--- libcreg-20200725/debian/patches/01-disable-memory-tests-on-riscv64.patch
1970-01-01 01:00:00.0 +0100
+++ libcreg-20200725/debian/patches/01-disable-memory-tests-on-riscv64.patch
2020-12-27 14:35:30.0 +0100
@@ -0,0 +1,11 @@
+--- libcreg-20200725.orig/tests/creg_test_memory.h
 libcreg-20200725/tests/creg_test_memory.h
+@@ -28,7 +28,7 @@
+ extern "C" {
+ #endif
+ 
+-#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBCREG_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( HAVE_ASAN )
++#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( 
LIBCREG_DLL_IMPORT ) && !defined( __arm__ ) && !defined( __clang__ ) && 
!defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && 
!defined( __sparc__ ) && !defined( __riscv ) && !defined( HAVE_ASAN )
+ #define HAVE_CREG_TEST_MEMORY 1
+ #endif
+ 
--- libcreg-20200725/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ libcreg-20200725/debian/patches/series  2020-12-27 14:35:30.0 
+0100
@@ -0,0 +1 @@
+01-disable-memory-tests-on-riscv64.patch

Regards,
Aurelien

Bug#978459: plasma-base: A source-only upload is needed

[Boyuan Yang]

Source: plasma-base
Version: 5.20.0
Severity: important
X-Debbugs-CC: norb...@preining.info patfr...@gmail.com sgmo...@kde.org

Dear Debian plasma-base package maintainer,

Just to let you know that we need an extra source-only upload for
package plasma-base ( https://tracker.debian.org/pkg/plasma-base ) in
Debian to allow it to migrate to Debian Testing. Please fix it
following instructions on https://wiki.debian.org/SourceOnlyUpload .

Thanks,
Boyuan Yang


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

Bug#978458: freecad: Addon Manager doesn't fetch list of available addons properly

[Łukasz Stelmach]

Package: freecad
Version: 0.18~pre1+dfsg1-5
Severity: normal
Control: tags -1 + patch

Dear Maintainer,

Due to updated HTML on github, Addon Manager cannot parse the list of
addons properly. This was discussed on the forum[1] and has been fixed
in 0.18.5 (commits 258f9f15[2] and b7ab01e6[3]).

[1] https://forum.freecadweb.org/viewtopic.php?f=13=51346
[2] https://github.com/FreeCAD/FreeCAD/commit/258f9f15
[3] https://github.com/FreeCAD/FreeCAD/commit/b7ab01e6

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

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

Versions of packages freecad depends on:
ii  freecad-python2  0.18~pre1+dfsg1-5

Versions of packages freecad recommends:
pn  calculix-ccx  
pn  graphviz  

Versions of packages freecad suggests:
pn  freecad-doc 
ii  povray  1:3.7.0.8-1
ii  python-collada  0.4-3

-- no debconf information

-- 
Miłego dnia,
Łukasz Stelmach


signature.asc
Description: PGP signature

Bug#933948: Config value incorrectly parsed in init.d script

[Norbert Harrer]

Hi Markus.

I replaced my init scripts with the versions from your merge. And tried 
with various combinations of spaces and quotes. Works very well. Great 
regex/escape-fu.


Best Regads,
Norbert.

On 27.12.2020 14:32, Markus Wanner wrote:

Control: -1 severity grave
Control: -1 tags +pending

Hi,

On 11/21/20 3:46 PM, Norbert Harrer wrote:
> But in /etc/init.d/courier-mta-ssl it is parsed with sed:
>
> DO_START=$(sed -ne 's/^ESMTPDSSLSTART=\([^[:space:]]*\)/\1/p'
> /etc/courier/esmtpd-ssl | tr "A-Z" "a-z")

thanks a lot for this fine analysis.  I propose to tweak the regular 
expressions to be more resilient to quotes (single and double) as well 
as spaces (which deviates from how the shell would interpret it, though).


Please review the following merge request:
https://salsa.debian.org/debian/courier/-/merge_requests/8

Note 2: Another thing is curious: Not all courier services use the 
init.d

scripts, some have their own systemd config in /lib/systemd/system/
which bypass the init.d script


Yeah, this is unfortunate and should be addressed as well.  Thanks for 
pointing it out.


Best Regards

Markus


--
Dipl.Ing. Norbert Harrer | Software Engineer | (+43) 0699 10926825 
|nhar...@equilaris.at

Bug#978442: [pkg-php-pear] Bug#978442: Composer: Please, handle x versions as * versions

[Robin Gustafsson]

Quoting from the source code of Composer's "semver" version parser [1]:

// X Range
//
// Any of X, x, or * may be used to "stand in" for one of the numeric
values in the [major, minor, patch] tuple.
// A partial version range is treated as an X-Range, so the special
character is in fact optional.

[1] 
https://github.com/composer/semver/blob/f8c5a07/src/VersionParser.php#L408,L411

Bug#978457: phing: Not compatible with php8.0

[David Prévot]

Package: phing
Version: 2.16.1-1
Severity: important
Tags: upstream
Control: block 976811 by -1

phing is not compatible (at all) with PHP 8. A version 3 is on its way,
but has been in alpha stage for months. It will hopefully be PHP 8
compatible.


signature.asc
Description: PGP signature

Bug#978456: actiona FTCBFS: multiple reasons

[Helmut Grohne]

Source: actiona
Version: 3.10.1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

actiona fails to cross build from source for two reasons.

For one thing its common.pri hard codes the build architecture
pkg-config. qmake does have native support for pkg-config and once using
it, it automatically works for cross builds.

For running lrelease, a build dependency on qt5-qmake:native is
required.

The attached patch fixes both and makes actiona cross buildable. Please
consider applying it.

Helmut
diff --minimal -Nru actiona-3.10.1/debian/changelog 
actiona-3.10.1/debian/changelog
--- actiona-3.10.1/debian/changelog 2020-03-25 22:51:14.0 +0100
+++ actiona-3.10.1/debian/changelog 2020-12-27 12:51:53.0 +0100
@@ -1,3 +1,12 @@
+actiona (3.10.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Build-Depends: qt5-qmake:native for running lrelease.
++ cross.patch: Properly integrate pkg-config.
+
+ -- Helmut Grohne   Sun, 27 Dec 2020 12:51:53 +0100
+
 actiona (3.10.1-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru actiona-3.10.1/debian/control actiona-3.10.1/debian/control
--- actiona-3.10.1/debian/control   2020-03-25 22:51:14.0 +0100
+++ actiona-3.10.1/debian/control   2020-12-27 12:51:53.0 +0100
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Adrien Cunin 
-Build-Depends: debhelper (>= 9), qtbase5-dev, libqt5x11extras5-dev, 
libqt5xmlpatterns5-dev, qtscript5-dev, qttools5-dev, qtmultimedia5-dev, 
qttools5-dev-tools, libxtst-dev, libnotify-dev, libopencv-dev, libboost-dev, 
libxkbcommon-dev, libqt5texttospeech5-dev
+Build-Depends: debhelper (>= 9), qtbase5-dev, libqt5x11extras5-dev, 
libqt5xmlpatterns5-dev, qtscript5-dev, qttools5-dev, qtmultimedia5-dev, 
qttools5-dev-tools, libxtst-dev, libnotify-dev, libopencv-dev, libboost-dev, 
libxkbcommon-dev, libqt5texttospeech5-dev, qt5-qmake:native
 Standards-Version: 4.1.4
 Homepage: https://actiona.tools
 Vcs-Git: https://salsa.debian.org/debian/actiona.git
diff --minimal -Nru actiona-3.10.1/debian/patches/cross.patch 
actiona-3.10.1/debian/patches/cross.patch
--- actiona-3.10.1/debian/patches/cross.patch   1970-01-01 01:00:00.0 
+0100
+++ actiona-3.10.1/debian/patches/cross.patch   2020-12-27 12:51:51.0 
+0100
@@ -0,0 +1,25 @@
+--- actiona-3.10.1.orig/common.pri
 actiona-3.10.1/common.pri
+@@ -15,19 +15,10 @@
+ PKGCONFIG_OPENCV = opencv
+ }
+ 
++CONFIG += link_pkgconfig
++
+ unix:!mac {
+-!system(pkg-config --exists 'x11') {
+-error(Please install pkg-config)  #Here whe assume that 
x11 is always present, so this is to check if pkg-config is installed
+-}
+-!system(pkg-config --exists 'libnotify') {
+-error(Please install libnotify development libraries 
(libnotify-dev on Debian))
+-}
+-!system(pkg-config --exists 'xtst') {
+-error(Please install XTest development libraries (libxtst-dev 
on Debian))
+-}
+-!system(pkg-config --exists '$$PKGCONFIG_OPENCV') {
+-error(Please install OpenCV development libraries 
(libopencv-dev on Debian))
+-}
++  PKGCONFIG += x11 libnotify xtst $$PKGCONFIG_OPENCV
+ }
+ 
+ DEFINES *= ACT_VERSION=$$ACTIONA_VERSION
diff --minimal -Nru actiona-3.10.1/debian/patches/series 
actiona-3.10.1/debian/patches/series
--- actiona-3.10.1/debian/patches/series2020-03-25 22:51:14.0 
+0100
+++ actiona-3.10.1/debian/patches/series2020-12-27 12:50:59.0 
+0100
@@ -0,0 +1 @@
+cross.patch

Bug#959999: xz-utils FTBFS for musl: misdetects presence of gettex, locales go missing

[Helmut Grohne]

Control: tags -1 + fixed-upstream

Hi Sebastian,

On Sat, Dec 26, 2020 at 06:36:43PM +0100, Sebastian Andrzej Siewior wrote:
> Upstream has
> 
> |AM_GNU_GETTEXT_REQUIRE_VERSION([0.19.6])
> |AM_GNU_GETTEXT_VERSION([0.19.6])
> 
> would that work for you?

Yes. I attempted a build with those lines and it succeeded. Thanks for
checking.

Helmut