Bug#958928: ffmpegfs FTCBFS: uses AC_RUN_IFELSE

[Helmut Grohne]

Control: tags -1 + fixed-upstream

On Sun, Apr 26, 2020 at 10:49:10PM +0200, Norbert Schlia wrote:
> although I dont't get that: the only difference to 1.10-2 in configure.ac is
> that the line
> 
> AC_INIT([FFMPEGFS], [1.10])
> 
> changed to
> 
> AC_INIT([FFMPEGFS], [1.98])
> 
> :)

I didn't track down which version actually introduced the issue, but
simply reported that the bug was present in version 1.98.2.

> But anyway, I added the patch and created 1.98-3. The patch has also been
> applied to 1.99 upstream.

Thank you. There is no urgency of uploading the fix to Debian right away
as many more packages are affected by similar problems. Fixing it
upstream and letting it trickle down with normal package update
procedures is good. Just don't forget to close the bug with the upstream
release.

Helmut

Bug#958130: hercules FTCBFS: make dependencies contain linker flags

[Helmut Grohne]

Hi Philipp,

On Sun, Apr 26, 2020 at 10:41:20PM +0200, Philipp Kern wrote:
> Is there a way for me to test this patch? (I also take pointers.) There
> are more references to -lltdl in there and curiously rebuilding the
> package actually drops the shlibs reference from libltdl, so I'd have
> liked to make sure the problem is actually fixed.

If you are using sbuild, you can simply add --host=$somearch to your
invocation. If you are using pbuilder, you can simply add --host-arch
$somearch to your invocation. There is no need for extra chroots or like
that. Just those extra options. After your upload, you can check
http://crossqa.debian.net/src/hercules to see the results of the
autobuilder. Beware that the service presently has a noticeable backlog,
so it may take a few days to build your package (unless you schedule it
yourself). Also be aware that since gcc-10 presently FTBFS on x86, cross
building on x86 in unstable tends to not work. At the time of this
writing, you can still cross build from amd64 to mips64el, because
mips64el didn't finish building gcc-10 yet. After that, a testing chroot
may be needed. The crossqa page tells you which hosts work with amd64 at
any given time.

In case you have further questions, don't hesitate to ask.

Helmut

Bug#143296: sntop: configure.in missing from upstream source

[Helmut Grohne]

Control: severity -1 serious

On Wed, Apr 17, 2002 at 10:41:40AM -0400, Mark W. Eichin wrote:
> The 1.4.2 upstream tarball only contains "configure", clearly
> generated from autoconf 2.13, but no configure.in.  (Granted, it
> doesn't look like much is actually tested there, in fact nothing at
> all, but an empty configure.in doesn't generate that result...)

Regardless of whether upstream is dead (and unable to provide
configure.in), the fact that it is missing voids DFSG #2 and effectively
voids DFSG #3 as configure cannot be modified in a reasonable way. DFSG
issues are generally release-critical.

A possible route would be reverse-engineering the configure script.

Helmut

Bug#958276: (no subject)

[Buck]

> As explained in 958277, removing or renaming packaged files is not
> supported.

Right.  958277 is what happens when I do not remove or rename the default 
profiles/ in /usr.

This bug is what happens when I do.  So if you want to close this bug because 
it is unrecommended use of simple-cdd, that makes sense.

> I'm not sure what error you're referring to; should this just be merged
> with your later bug? https://bugs.debian.org/958277

No, these are different.  This bug is what happens when I tried to fix 958277 
by removing the default profile, trying to force simple-cdd to use the one in 
~/my-simple-cdd/profiles.

But maybe this bug should be closed because it is not recommended use of 
simple-cdd.

Bug#958277: (no subject)

[Buck]

Yes sorry.  The command:

`~/my-simple-cdd$ build-simple-cdd`

> You may also want to use "--auto-profiles NAME" additionally

Why?  The documentation is not clear how --auto-profiles vs --profiles works.

> It would be helpful if you could provide your proposed profile in
> more detail. 

> Ideally, the exact commands you ran and the exact state of
> the directory you're running them from.

The command is above.  The state is that ~/my-simple-cdd/ has a profiles/ 
directory.  profiles/ directory contains custom.description, custom.packages, 
custom.postinst, custom.udebs, custom.preseed.  Do you want the details from 
each of these?

>* What exactly did you do (or not do) that was effective (or
>  ineffective)?

I have been changing Debian versions, thinking the problem is bugs in 
simple-cdd, tasksel, or reprepro.  Different erros come up with different 
versions.  All are being reported.

> If you want to override the built-in profiles, you need to create
> replacement files (e.g. profiles/default.preseed, profiles/default.*),
> though I would generally recommend providing additional profiles rather
> than overriding the default profiles.

I did the latter of these, added profiles/custom.X files.  However when I do 
this, I get this current error where the CD is created and it looks like a 
normal Debian installer that asks quesitons that I believe are answered in the 
custom.preseed file.

If I remove the default.X files in /usr, I get 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958276

I also tried using a default-custom (as in, a template for X.preseed that I 
found online) and this also build a default Debian install CD.

>* What was the outcome of this action?
>
>   New error: $default_desktop not defined

The error for this bug is not an error message, it is a working Debian 
installer CD that behaves different from I expect, becaues it behaves like a 
default Debian installer.

But what is reporting error 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958276 ($default_desktop) is 
the output of build-simple-cdd.

> It will read the profiles from profiles in your working directory,

This does not happen, but I am happy that you say this is what should happen.  
That tells me that there is a bug that is preventing my 
~/my-simple-cdd/profiles/custom.X files being read.  It is also possible I have 
a bad config but I don't think so because I tried a default custom config.

Can you suggest a config I should use to test, that will create a Debian 
installer that is different from default to verify that this preseed is being 
read?

Bug#958948: simple-cdd on stretch fails with reprepro errors

[Buck]

Package: simple-cdd
Version: 0.6.5
Severity: normal

Dear Maintainer,

Running simple-cdd in default mode on fresh stretch installation fails as 
follows:

$ build-simple-cdd
2020-04-27 00:29:23 ERROR reprepro: updating package lists exited with code 255
2020-04-27 00:29:23 ERROR Last 5 lines of standard error:
2020-04-27 00:29:23 ERROR reprepro: updating package lists: of the databases 
belonging to those removed parts.
2020-04-27 00:29:23 ERROR reprepro: updating package lists: (Another reason to 
get this error is using conf/ and db/ directories
2020-04-27 00:29:23 ERROR reprepro: updating package lists:  belonging to 
different reprepro repositories).
2020-04-27 00:29:23 ERROR reprepro: updating package lists: To ignore use 
--ignore=undefinedtarget.
2020-04-27 00:29:23 ERROR reprepro: updating package lists: There have been 
errors!
2020-04-27 00:29:23 ERROR reprepro failed with exit code: 255

(Please note it does not seem possible to reply to replies to these Debian bugs 
threads so replies may not be possible.)

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

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

Versions of packages simple-cdd depends on:
ii  dctrl-tools 2.24-2+b1
ii  debian-cd   3.1.20
ii  lsb-release 9.20161125
ii  python3 3.5.3-1
ii  python3-simple-cdd  0.6.5
ii  reprepro5.1.1-1
ii  rsync   3.1.2-1+deb9u2
ii  wget1.18-5+deb9u3

Versions of packages simple-cdd recommends:
ii  dose-distcheck  5.0.1-8+deb9u1

Versions of packages simple-cdd suggests:
ii  qemu-system  1:2.8+dfsg-6+deb9u9

-- no debconf information

Bug#956729: asciidoc-base: add xsltproc to Depends

[merkys]

Hi Joseph,

On 2020-04-26 06:44, Joseph H. wrote:
> Anyway, I'll add the dependency tomorrow but note that you will also
> need to add --no-xmllint to avoid errors.

I just saw you have added xsltproc to the dependencies. Thanks a lot!

Best,
Andrius

Bug#954780: Duplicate: almost identical content already shipped with vim-runtime

[Joseph Herlant]

Control: forwarded -1 https://github.com/asciidoc/asciidoc-py3/pull/100

Hi Pavel,

Thanks for pointing it out. I had no idea Stuart got it in vim too.
I pushed a PR upstream to get rid of it in the asciidoc repo. I'll
delete vim-asciidoc once upstream signed off on its removal.

Thanks,
Joseph

Bug#958949: firefox-esr gives me warnings about sandbox violations, no idea what to make of it

[shirish शिरीष]

Package: firefox-esr
Version: 68.7.0esr-1
Severity: normal

Dear Maintainer,
I get warnings such as these -

Sandbox: seccomp sandbox violation: pid 1699426, tid 1699426, syscall
315, args 1699426 140347346664256 56 0 17 140347346664256.

Now the only thing which comes on mozillawiki is this link [1] which
appears not to have written to the casual user. Shouldn't any
violation in userspace should be a matter of security team as well. I
would like to hear your thoughts on the matter before involving the
security team hence reporting it in the archive first. FWIW, I get the
warnings both in regular firefox session as well as in --safe-mode.
[2]

1. https://wiki.mozilla.org/Security/Sandbox/Seccomp
2. $ firefox --safe-mode

-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.9.1
ii  fontconfig2.13.1-4
ii  libasound21.2.2-2.1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.30-4
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-2
ii  libdbus-glib-1-2  0.110-5
ii  libevent-2.1-72.1.11-stable-1
ii  libffi7   3.3-4
ii  libfontconfig12.13.1-4
ii  libfreetype6  2.10.1-2
ii  libgcc-s1 10-20200418-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-4
ii  libglib2.0-0  2.64.2-1
ii  libgtk-3-03.24.18-1
ii  libjsoncpp1   1.7.4-3.1
ii  libnspr4  2:4.25-1
ii  libnss3   2:3.49.1-1
ii  libpango-1.0-01.44.7-4
ii  libsqlite3-0  3.31.1-5
ii  libstartup-notification0  0.12-6
ii  libstdc++610-20200418-1
ii  libx11-6  2:1.6.9-2
ii  libx11-xcb1   2:1.6.9-2
ii  libxcb-shm0   1.14-2
ii  libxcb1   1.14-2
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.16-4
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.2.2-1+b1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-7
ii  libgtk2.0-02.24.32-4
ii  pulseaudio 13.0-5

-- no debconf information

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

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

Bug#958950: RM: torch3 -- RoQA; Deprecated Upstream

[Mo Zhou]

Package: ftp.debian.org
Severity: normal

I'm not the maintainer.

Torch3 is already dead. We should remove it.
There is an RFP for its successor Torch5, but Torch5 had never entered archive
Torch7 had been packaged for buster (lua-torch-* packages), but removed due to 
deprecation
The successor of Torch7 is Pytorch.

I'm working on packaging pytorch.

Bug#958947: RM: sleef [armel mips64el mipsel s390x] -- ROM; remove nolonger supported architectures

[Mo Zhou]

Package: ftp.debian.org
Severity: normal

(please explain the reason for the removal here)

upstream broke the support for armel, mips*, and s390x in the latest
release

I'd like to request for removal of these architectures to unblock
migration

Note: this was a request for a partial removal from testing, converted in one 
for unstable

Bug#958945: lintian,debhelper: lintian emits missing-dependency-on-libc on auto-generated dbgsym package

[Axel Beckert]

Control: reassign -1 lintian 2.68.0
Control: retitle -1 lintian: Should emit an error on non-debug files in dbgsym 
packages

Hi again,

Axel Beckert wrote:
> From upstream's (generated) Makefile:
> 
> 
> linstall: | libipt_NETFLOW.so libip6t_NETFLOW.so
> @echo " *"
> install -D libipt_NETFLOW.so 
> $(DESTDIR)$(IPTABLES_MODULES)/libipt_NETFLOW.so
> install -D libip6t_NETFLOW.so 
> $(DESTDIR)$(IPTABLES_MODULES)/libip6t_NETFLOW.so
> 

There's one more interesting (surely generated) snippet in there:


IPTABLES_MODULES = /usr/lib/debug/.dwz/x86_64-linux-gnu/iptables.debug


Makefile.in looks like this in the same place:


IPTABLES_MODULES = @IPTABLES_MODULES@


configure replaces this as follows:


s!@IPTABLES_MODULES@!$IPTLIB!


And from the build log:


Iptables module path: /usr/lib/debug/.dwz/x86_64-linux-gnu/iptables.debug (from 
binary)


And indeed, the way to determine this value seems to be buggy:


$ strings /sbin/iptables | grep '^/.*lib.*/.*tables'
/usr/lib/debug/.dwz/x86_64-linux-gnu/iptables.debug


I searched the output of "strings /sbin/iptables" for other, similar
paths, but there's just none:


$ strings /sbin/iptables | grep 'usr'
/usr/lib/debug/.dwz/x86_64-linux-gnu/iptables.debug
$ strings /sbin/iptables | grep 'lib'
/lib64/ld-linux-x86-64.so.2
libmnl.so.0
libnftnl.so.11
libxtables.so.12
libc.so.6
__libc_start_main
/usr/lib/debug/.dwz/x86_64-linux-gnu/iptables.debug
$ strings /sbin/iptables | grep 'x86'
/lib64/ld-linux-x86-64.so.2
/usr/lib/debug/.dwz/x86_64-linux-gnu/iptables.debug


So the main issue here seems upstream's self-written configure script
that fails on recent iptables binaries.

> Maybe lintian should warn about non-debug stuff in dbgsym packages?
> I'll probably later retitle and reassign the bug report to lintian
> accordingly — once I've better understood wtf is going on here.

I'm convinced now that lintian should emit such a warning. Retitling
and reassigning accordingly.

This tag should be very likely of severity "error".

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

Bug#955807: transition: netcdf

[Sebastiaan Couwenberg]

On 4/25/20 9:09 PM, Sebastian Ramacher wrote:
> On 2020-04-25 17:23:03, Sebastiaan Couwenberg wrote:
>> vtk7 (7.1.1+dfsg2-3) was just uploaded and it FTBFS as reported in #958817.
>>
>> Since it's a key package the RC bug won't trigger autoremoval of it and
>> its rdeps like lammps.
>>
>> If #958817 is not fixed soon, rebuilds in testing-proposed-updates like
>> for hdf5 may be required to enable migration of netcdf and the affected
>> packages.
> 
> I don't think this will be necessary. libnetcdf15 and libnetcdf18 are
> co-installable so netcdf should be smooth-updatable.

netcdf and most rdeps have migrated to testing. eccodes & vtk7 should
migrated tomorrow. gdal on armel & mips* still need to migrate as well.

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#958945: lintian,debhelper: lintian emits missing-dependency-on-libc on auto-generated dbgsym package

[Axel Beckert]

Hi,

Axel Beckert wrote:
> E: iptables-netflow-dkms-dbgsym: missing-dependency-on-libc needed by 
> usr/lib/debug/.dwz/x86_64-linux-gnu/iptables.debug/libip6t_NETFLOW.so and 1 
> others
> 
> Since I can't really influence the automatic debug symbol package, this
> must be either a false positive in Lintian or a bug in debhelper.

The issue actually might be elsewhere and the error issued by Lintian
might be correct. I though actually still don't know what happens
here, especially not why.

>From upstream's (generated) Makefile:


linstall: | libipt_NETFLOW.so libip6t_NETFLOW.so
@echo " *"
install -D libipt_NETFLOW.so 
$(DESTDIR)$(IPTABLES_MODULES)/libipt_NETFLOW.so
install -D libip6t_NETFLOW.so 
$(DESTDIR)$(IPTABLES_MODULES)/libip6t_NETFLOW.so


For some reason this causes the file paths mentioned in the lintian
warning to be used:



$ make -n DESTDIR=debian/tmp linstall
echo " *"
install -D libipt_NETFLOW.so 
debian/tmp/usr/lib/debug/.dwz/x86_64-linux-gnu/iptables.debug/libipt_NETFLOW.so
install -D libip6t_NETFLOW.so 
debian/tmp/usr/lib/debug/.dwz/x86_64-linux-gnu/iptables.debug/libip6t_NETFLOW.so
$ echo $IPTABLES_MODULES

$


So I suspect this is the cause for the then likely correct but kinda
misleading lintian warning.

Maybe lintian should warn about non-debug stuff in dbgsym packages?
I'll probably later retitle and reassign the bug report to lintian
accordingly — once I've better understood wtf is going on here.

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

Bug#955603: those modules are STILL IN RECENT SERVERS like r128 (rage) and openchrome via boards

[PICCORO McKAY Lenz]

those modules are STILL IN RECENT SERVERS like r128 (rage) and
openchrome via boards

proliant hp and DELL ones!

-- 
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#955603: r128 has updates recently

[PICCORO McKAY Lenz]

https://www.phoronix.com/scan.php?page=news_item=ATI-RAGE-128-DDX-6.11.0

2020-04-26 23:32 GMT-04:00, PICCORO McKAY Lenz :
> those modules are STILL IN RECENT SERVERS like r128 (rage) and
> openchrome via boards
>
> proliant hp and DELL ones!
>
> --
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
>


-- 
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#958946: libparse-debianchangelog-perl: "Unknown option: s" despite the following help message advertises "-s"

[Axel Beckert]

Package: libparse-debianchangelog-perl
Version: 1.2.0-13
Severity: normal

parsechangelog's usage message is inconsistent with regards to
implemented options (highlighting with ^ added by myself):

$ parsechangelog -s 12.1.1 ~/debhelper/debhelper/debian/changelog
Unknown option: s
^
Usage:
parsechangelog [options] [changelogfile]

 Options:
--help, -h  print usage information
--version, -V   print version information
--file, -lchangelog file to parse, defaults
to 'debian/changelog'
-F ignored if changelogformat = 'debian'
for compatibility with dpkg-dev
-L  ignored for compatibility with dpkg-dev
--format  see man page for list of available
output formats, defaults to 'dpkg'
for compatibility with dpkg-dev
--since, -s, -vinclude all changes later than version

--until, -uinclude all changes earlier than version
--from, -f include all changes equal or later
than version
--to, -t   include all changes up to or equal
than version
--count, -c, -n include  entries from the top
(or the tail if  is lower than 0)
--offset, -ochange the starting point for --count,
counted from the top (or the tail if
 is lower than 0)
--all   include all changes

If neither "changelogfile" nor "-l " are specified,
debian/changelog will be used. If two different files are specified the
program will abort.

If the filename is "-" the program reads the changelog from standard
input.

"--all" overrides all other range selecting options. "--count" overrides
all other range selection options except for "--all". The range
selecting options can be mixed together, but only one of "--since" and
"--from" and one of "--until" and "--to" can be specified at the same
time.

The dpkg and rfc822 formats default to showing only the first entry when
no other options are given with while the HTML and XML formats default
to showing all entries.

For a more extensive documentation of the range selecting options and
some (hopefully enlightening) examples see "COMMON OUTPUT OPTIONS" in
Parse::DebianChangelog.

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages libparse-debianchangelog-perl depends on:
ii  libcgi-pm-perl  4.46-1
ii  libclass-accessor-perl  0.51-1
ii  libio-string-perl   1.08-3
ii  liblocale-gettext-perl  1.07-4
ii  libtimedate-perl2.3200-1
ii  perl5.30.0-10

libparse-debianchangelog-perl recommends no packages.

Versions of packages libparse-debianchangelog-perl suggests:
ii  libhtml-parser-perl3.72-5
ii  libhtml-template-perl  2.97-1
ii  libxml-simple-perl 2.25-1

-- no debconf information

Bug#956779: redshift: Depends on deprecated libappindicator

[Kentaro Hayashi]

FYI:

I've created PR agaist upstream use AyatanaIndicator3:
https://github.com/jonls/redshift/pull/757

Bug#958652: ITP: foxi -- ONNXIFI with Facebook Extension

[Mo Zhou]

Control: close -1

It's pointness to package this standalone. It's never used by any other
package than pytorch. And pytorch only needs a small part of its code.
The rest part of foxi, that pytorch does not need, FTBFS.

So I choose to embed the necessary files of foxi to src:pytorch

Bug#945834: ITP: trisycl -- Generic system-wide modern C++ for heterogeneous platforms with SYCL from Khronos Group

[Mo Zhou]

Control: close -1

TriSYCL is cooperating with intel. Maintaing the LLVM/SYCL is already
difficult enough for the open source community, let alone two
implemtnations.

We should wait for intel to upstream their SYCL component to LLVM
upstream.

Bug#711135: Submission Reopened: CLOUD COMPUTING 2020 || October 25 - 29, 2020 - Nice, France

[CLOUD COMPUTING 2020]

Greetings,

Note that CLOUD COMPUTING 2020 scheduled earlier in the year has been moved to 
October 25 - 29, 2020 in Nice, France. As such, we have additional time to 
reopen submissions to the conference.

In order to accommodate a large number of situations, we are offering the 
option for either physical presence or virtual participation. We would be 
delighted if all authors manage to attend, but are aware that special 
circumstances are best handled by having flexible options.

The new submission deadline is June 1.

Please consider to contribute to and/or forward to the appropriate groups the 
following opportunity to submit and publish original scientific results to:

- CLOUD COMPUTING 2020: The Eleventh International Conference on Cloud 
Computing, GRIDs, and Virtualization

Authors of selected papers will be invited to submit extended article versions 
to one of the IARIA Journals: http://www.iariajournals.org

=


CLOUD COMPUTING 2020: The Eleventh International Conference on Cloud Computing, 
GRIDs, and Virtualization

Event schedule: October 25 - 29, 2020 - Nice, France

Main page: https://www.iaria.org/conferences2020/CLOUDCOMPUTING20.html

Submission: https://www.iaria.org/conferences2020/SubmitCLOUDCOMPUTING20.html


Contributions:

- regular papers [in the proceedings, digital library]

- short papers (work in progress) [in the proceedings, digital library]

- ideas: two pages [in the proceedings, digital library]

- extended abstracts: two pages [in the proceedings, digital library]

- posters: two pages [in the proceedings, digital library]

- posters:  slide only [slide-deck posted at www.iaria.org]

- presentations: slide only [slide-deck posted at www.iaria.org]

- demos: two pages [posted at www.iaria.org]


Deadlines

Submission: June 1, 2020

Notification: July 1, 2020

Registration: July 14, 2020

Camera-ready: July 20, 2020


Call for papers: https://www.iaria.org/conferences2020/CfPCLOUDCOMPUTING20.html

Committees: https://www.iaria.org/conferences2020/ComCLOUDCOMPUTING20.html



Extended versions of selected papers will be published in IARIA Journals:  
http://www.iariajournals.org

Print proceedings will be available via Curran Associates, Inc.: 
http://www.proceedings.com/9769.html

Articles will be archived in the free access ThinkMind Digital Library: 
http://www.thinkmind.org


The topics suggested by the conference can be discussed in term of concepts, 
state of the art, research, standards, implementations, running experiments, 
applications, and industrial case studies. Authors are invited to submit 
complete unpublished papers, which are not under review in any other conference 
or journal in the following, but not limited to, topic areas.

All tracks are open to both research and industry contributions, in terms of 
Regular papers, Posters, Work in progress, Technical/marketing/business 
presentations, Demos, Tutorials, and Panels.

Before submission, please check and comply with the editorial rules: 
http://www.iaria.org/editorialrules.html



Topics:

TRENDS: New trends

Fog-computing; Mobile Edge Computing; Cloudlets; Hosted Cloud services (WebRTC, 
Containers, Cloud micro-services); Cloud computing and SDN/NFV; Cloud computing 
and 5G; Cloud computing and LTE Pro 4.5; Cloud computing ad Big Data; High 
performance computing (HPC) in the Cloud; Superfluid Clouds; Mobile Apps to the 
public Clouds; Vehicular Cloud networks; Cloud orchestration features; 
Converged edge systems; Cloud federation; Micro-cloud provider federation; 
Open-implementation Cloud infrastructures; Untrusted Cloud environments; 
Multiple Clouds and data centers; Power Constrained VMs; Cloud Green 
abstraction layer

CLOUD: Cloud computing

Cloud economics; Core cloud services; Cloud technologies; Cloud computing; 
On-demand computing models; Hardware-as-a-service; Software-as-a-service [SaaS 
applications]; Platform-as-service; Storage as a service in cloud; 
Data-as-a-Service; Service-oriented architecture (SOA); Cloud computing 
programming and application development; Scalability, discovery of services and 
data in Cloud computing infrastructures; Trust and clouds; Client-cloud 
computing challenges; Geographical constraints for deploying clouds

CLOUD: Challenging features

Privacy, security, ownership and reliability issues; Performance and QoS; 
Dynamic resource provisioning; Power-efficiency and Cloud computing; Load 
balancing; Application streaming; Cloud SLAs; Business models and pricing 
policies; Cloud service subscription models; Cloud standardized SLA; 
Cloud-related privacy; Cloud-related control; Managing applications in the 
clouds; Mobile clouds; Roaming services in Clouds; Agent-based cloud computing; 
Cloud brokering; Cloud contracts (machine readable); Cloud security; Security 
and assurance properties in cloud environments; Big Data Analytics in clouds; 
Cloud computing back-end solutions; Cloud applications portability; 
Cloud-native application design; 

Bug#958945: lintian,debhelper: lintian emits missing-dependency-on-libc on auto-generated dbgsym package

[Axel Beckert]

Package: lintian,debhelper
Severity: important
Version: debhelper/13 lintian/2.68.0

Hi,

while preparing the iptables-netflow/2.5-1 upload lintian emits this
packaging error (both with dh compat 11 as well as with level 12):

E: iptables-netflow-dkms-dbgsym: missing-dependency-on-libc needed by 
usr/lib/debug/.dwz/x86_64-linux-gnu/iptables.debug/libip6t_NETFLOW.so and 1 
others

Since I can't really influence the automatic debug symbol package, this
must be either a false positive in Lintian or a bug in debhelper. Filing
against both packages for now. Feel free to reassign as needed.

The generated and accused dbgsym-package with still dh compat level 11
looks like this:

$ debc
iptables-netflow-dkms-dbgsym_2.5-1_amd64.deb

 new Debian package, version 2.0.
 size 6264 bytes: control archive=516 bytes.
 321 bytes,11 lines  control  
 207 bytes, 2 lines  md5sums  
 Package: iptables-netflow-dkms-dbgsym
 Source: iptables-netflow
 Version: 2.5-1
 Auto-Built-Package: debug-symbols
 Architecture: amd64
 Maintainer: Axel Beckert 
 Installed-Size: 59
 Depends: iptables-netflow-dkms (= 2.5-1)
 Section: debug
 Priority: optional
 Description: debug symbols for iptables-netflow-dkms
drwxr-xr-x root/root 0 2020-04-27 03:26 ./
drwxr-xr-x root/root 0 2020-04-27 03:26 ./usr/
drwxr-xr-x root/root 0 2020-04-27 03:26 ./usr/lib/
drwxr-xr-x root/root 0 2020-04-27 03:26 ./usr/lib/debug/
drwxr-xr-x root/root 0 2020-04-27 03:26 ./usr/lib/debug/.dwz/
drwxr-xr-x root/root 0 2020-04-27 03:26 
./usr/lib/debug/.dwz/x86_64-linux-gnu/
drwxr-xr-x root/root 0 2020-04-27 03:26 
./usr/lib/debug/.dwz/x86_64-linux-gnu/iptables.debug/
-rw-r--r-- root/root 23752 2020-04-27 03:26 
./usr/lib/debug/.dwz/x86_64-linux-gnu/iptables.debug/libip6t_NETFLOW.so
-rw-r--r-- root/root 23752 2020-04-27 03:26 
./usr/lib/debug/.dwz/x86_64-linux-gnu/iptables.debug/libipt_NETFLOW.so
drwxr-xr-x root/root 0 2020-04-27 03:26 ./usr/share/
drwxr-xr-x root/root 0 2020-04-27 03:26 ./usr/share/doc/
lrwxrwxrwx root/root 0 2020-04-27 03:26 
./usr/share/doc/iptables-netflow-dkms-dbgsym -> iptables-netflow-dkms

[... other packages ...]

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Bug#949921: buster-pu: package uim_1.8.8-4+deb10u3

[Takatsugu Nokubi]

The correct things is, "no need to fix".
However we upload a changed package, it was unnecessary things,
anyway it don't affect anything for other packages, so we need to be
accept buster-pu changes.
Could you do it?

2020年4月27日(月) 0:01 Adam D. Barratt :
>
> On Thu, 2020-01-30 at 19:24 +0900, Takatsugu Nokubi wrote:
> > 2020年1月30日(木) 10:21 Takatsugu Nokubi :
> > > > > This fix is not necessary in unstable, because libuim-data is
> > > > > removed
> > > > > on unstable.
> > > >
> > > > It was incorrect. I'll update unstable for this issue.
> > >
> > > I uploaded unstable.
> >
> > Sorry, it was incorrect, the first message (no need to fix) is
> > correct.
> >
>
> Are you sure? libuim-data certainly still seems to be in unstable:
>
> libuim-data | 1:1.8.8-6.1| unstable | all
> uim| 1:1.8.8-6.1| unstable   | source,
> amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
>
> Regards,
>
> Adam
>

Bug#958944: libraw1394-11: Typo in German description of package

[Thorsten Ehlers]

Package: libraw1394-11
Version: 2.1.2-2
Severity: minor

Dear Maintainer,

apt show libraw1394-11 outputs:

Description: Bibliothek zum Direktzugriff auf den IEEE-1394- (Firewire-) Bus
libwar1394 [...]

libwar1394 -> libraw1394

Regards,
Thorsten



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

Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libraw1394-11 depends on:
ii  libc6  2.30-4

libraw1394-11 recommends no packages.

Versions of packages libraw1394-11 suggests:
pn  libraw1394-doc  

-- no debconf information

Bug#958943: cura: Cura 4.5.0-1 crashes on start

[Hendrie Bosch]

Package: cura
Version: 4.5.0-1
Severity: normal
Tags: d-i

Dear Maintainer,

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

   * What led up to the situation?
I was trying to start Cura

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I typed: $ cura
Also with the same outcome: $ sudo cura

   * What was the outcome of this action?
/usr/lib/python3/dist-packages/UM/PluginRegistry.py:4: DeprecationWarning: the
imp module is deprecated in favour of importlib; see the module's documentation
for alternative uses
  import imp
Traceback (most recent call last):
  File "/usr/bin/cura", line 21, in 
from cura.CrashHandler import CrashHandler
  File "/usr/lib/python3/dist-packages/cura/CrashHandler.py", line 27, in

from UM.Application import Application
  File "/usr/lib/python3/dist-packages/UM/Application.py", line 9, in 
from UM.Controller import Controller
  File "/usr/lib/python3/dist-packages/UM/Controller.py", line 4, in 
from UM.Scene.Scene import Scene
  File "/usr/lib/python3/dist-packages/UM/Scene/Scene.py", line 13, in 
from UM.Mesh.ReadMeshJob import ReadMeshJob  # To reload a mesh when its
file was changed.
  File "/usr/lib/python3/dist-packages/UM/Mesh/ReadMeshJob.py", line 8, in

from UM.FileHandler.ReadFileJob import ReadFileJob
  File "/usr/lib/python3/dist-packages/UM/FileHandler/ReadFileJob.py", line 5,
in 
from UM.FileHandler.FileHandler import FileHandler
  File "/usr/lib/python3/dist-packages/UM/FileHandler/FileHandler.py", line 12,
in 
from UM.PluginRegistry import PluginRegistry
  File "/usr/lib/python3/dist-packages/UM/PluginRegistry.py", line 21, in

from UM.Trust import Trust
  File "/usr/lib/python3/dist-packages/UM/Trust.py", line 9, in 
from cryptography.hazmat.backends import default_backend
ModuleNotFoundError: No module named 'cryptography'

   * What outcome did you expect instead?
Cura to start up.




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

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

Versions of packages cura depends on:
ii  cura-engine 1:4.5.0-2+b1
ii  fdm-materials   4.5.0-1
ii  fonts-open-sans 1.11-1
ii  python3 3.8.2-3
ii  python3-charon  4.5.0-1
ii  python3-pyqt5   5.14.2+dfsg-1+b1
ii  python3-pyqt5.qtopengl  5.14.2+dfsg-1+b1
ii  python3-requests2.23.0+dfsg-2
ii  python3-savitar 4.5.0-1+b1
ii  python3-serial  3.4-5.1
ii  python3-shapely 1.7.0-1+b1
ii  python3-uranium 4.5.0-1
ii  qml-module-qt-labs-folderlistmodel  5.12.5-5
ii  qml-module-qt-labs-settings 5.12.5-5
ii  qml-module-qtqml-models25.12.5-5
ii  qml-module-qtquick-controls 5.12.5-1+b1
ii  qml-module-qtquick-controls25.12.5+dfsg-2+b1
ii  qml-module-qtquick-dialogs  5.12.5-1+b1
ii  uranium-plugins 4.5.0-1

Versions of packages cura recommends:
ii  python3-zeroconf  0.23.0-1

cura suggests no packages.

-- no debconf information

Bug#958941: irqtop: bad home link into synaptic

[Axel Beckert]

Control: tag -1 + moreinfo unreproducible

Hi Jiff,

Jiff wrote:
> Package: irqtop
[...)
> the home link of irqtop into synaptic is bad, it points to
> https://github.com/aabc/ipt-netflow

Thanks for caring, but the link works for me and it's also the
expected URL.

In case you meant that the link is not broken, but just the wrong
website, please note that irqtop comes indeed from the ipt_netflow
upstream project and has no separate website. See
https://github.com/aabc/ipt-netflow/blob/master/irqtop

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

Bug#958942: RFP: complete-alias -- BASH Completion for shell aliases

[Christoph Anton Mitterer]

Package: wnpp
Severity: wishlist

* Package name: complete-alias
  Version : git
  Upstream Author : https://github.com/cykerway
* URL : https://github.com/cykerway/complete-alias
* License : GPL3
  Programming Lang: BASH
  Description : BASH Completion for shell aliases

A tool to simply get BASH completion for shell aliases.

If packaged, it would be nice if bash-completion could suggest it.

Bug#919557: [Pkg-mozext-maintainers] Bug#919557: Bug#919557: Bug#919557: Bug#922944: handling symbolic links in webextensions

[Ximin Luo]

Control: tags -1 + patch

Ximin Luo:
> Dmitry Smirnov:
>> On Sunday, 26 April 2020 9:25:06 AM AEST Ximin Luo wrote:
>>> The source code doesn't mention any particular reason, and one person on
>>> the upstream bug report mentions it in such an off-the-cuff and
>>> non-explanatory way I can't take it into account as a serious data point.
>>> We shouldn't just let a mere mention of "security" scare us into not
>>> touching stuff and using our own reasoning to fix bugs.
>>>
>>> And I *did* think about the possible security considerations, as I
>>> explained in my previous email, and derived my suggested patch based on
>>> these considerations. (FWIW, I have done and am doing various types of
>>> security work professionally, and I'm confident about this type of
>>> reasoning in general.)
>>
>> Did you consider the possibility of users having a mix of packaged and non-
>> packaged extensions? I think it is reasonable to contain/sandbox extensions 
>> to prevent peeking to various file system locations through symlinks.
>>
>> Once Firefox is patched to allow symlinks, the threat might be from 
>> malicious 
>> symlinks in non-packaged extensions.
>>
> 
> Yes, I covered this already. My suggested patch (B) would only traverse 
> symlinks when the extension being loaded (the symlink being resolved) is 
> itself underneath /usr/share/webext, other extensions would still not be 
> allowed to traverse symlinks.
> 
> Please do read through my first email in full.
> 

Please see my attached patches, they work to fix the bug and I can now undo my 
local umatrix workarounds, and firefox will traverse the symlinks fine.

IMO both of these patches should be applied. Although the second one is 
slightly more intrusive, it results in much more flexible behaviour. 
Specifically, firefox resolves extension directories if they are symlinks, so a 
single "extensions directory" does not suffice for the typical Debian method of 
symlinking stuff from /usr/share/webext.

In patch 1 to avoid complexity, only one single extensions directory is 
whitelisted, and that is /usr/share/webext. This means extensions installed 
directly into /usr/share/mozilla/extensions (e.g. uBlock) still won't work with 
symlinks.

In patch 2, we avoid resolving extension directories if they are symlinks. 
Then, anything installed into /usr/share/mozilla/extensions will be allowed to 
traverse symlinks, including extensions that are symlinked into that directory.

By looking at the surrounding code, it is fairly clear that the patch only 
affects unpacked system extensions and nothing else, so it should be 
uncontroversial. However it does go a bit deeper into firefox internals, and I 
am unclear exactly why one part of it works - but empirically it works, I have 
tested it quite thoroughly. More testing is of course welcome, as well as any 
feedback.

(It is possible to shortcut part of the Debian build process for firefox, and 
sudo cp libxul.so and omni.ja into /usr/lib/firefox as soon as they have been 
built. However you will need to rm -rf ~/.cache/mozilla/firefox/*/startupCache/ 
for firefox to see the updates to omni.ja. If you install the debs, this step 
should be unnecessary, however it takes about 20-30 more minutes to produce 
them.)

Best,
X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
--- a/netwerk/protocol/res/ExtensionProtocolHandler.cpp
+++ b/netwerk/protocol/res/ExtensionProtocolHandler.cpp
@@ -578,11 +578,8 @@
   // allow a resource from outside of the extension dir.
   return false;
 #else
-  if (!mozilla::IsDevelopmentBuild()) {
-return false;
-  }
 
-  // On Mac and Linux unpackaged dev builds, system extensions use
+  // On Mac and Linux builds (including Debian), system extensions use
   // symlinks to point to resources in the repo dir which we have to
   // allow loading. Before we allow an unpacked extension to load a
   // resource outside of the extension dir, we make sure the extension
@@ -633,13 +630,22 @@
 #if !defined(XP_WIN)
 Result ExtensionProtocolHandler::AppDirContains(
 nsIFile* aExtensionDir) {
-  MOZ_ASSERT(mozilla::IsDevelopmentBuild());
   MOZ_ASSERT(!IsNeckoChild());
 
   // On the first invocation, set mAppDir
   if (!mAlreadyCheckedAppDir) {
 mAlreadyCheckedAppDir = true;
+// below defs copied from nsXREDirProvider.cpp
+#if defined(XP_MACOSX)
 MOZ_TRY(NS_GetSpecialDirectory(NS_GRE_DIR, getter_AddRefs(mAppDir)));
+#else
+#  if defined(__OpenBSD__) || defined(__FreeBSD__)
+static const char* const sysLExtDir2 = "/usr/local/share/webext";
+#  else
+static const char* const sysLExtDir2 = "/usr/share/webext";
+#  endif
+MOZ_TRY(NS_NewNativeLocalFile(nsDependentCString(sysLExtDir2), false, getter_AddRefs(mAppDir)));
+#endif
 if (MOZ_LOG_TEST(gExtProtocolLog, LogLevel::Debug)) {
   nsAutoCString appDirPath;
   Unused << mAppDir->GetNativePath(appDirPath);
--- a/netwerk/protocol/res/ExtensionProtocolHandler.cpp

Bug#958941: irqtop: bad home link into synaptic

[Jiff]

Package: irqtop
Version: 2.3-5
Severity: minor

Dear Mai n'tainer,

the home link of irqtop into synaptic is bad, it points to
https://github.com/aabc/ipt-netflow

Regards
JY



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

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

Versions of packages irqtop depends on:
ii  ruby 1:2.5.1
ii  ruby-curses  1.2.4-1+b1

Versions of packages irqtop recommends:
ii  ethtool  1:4.19-1

irqtop suggests no packages.

-- no debconf information

Bug#958940: dget apropos two dashes

[積丹尼 Dan Jacobson]

Package: devscripts
Version: 2.20.2
Severity: minor
File: /usr/share/man/man1/dget.1.gz

Something's causing two dashes:
$ apropos deb|grep -C 1 dget
devscripts (1)   - scripts to ease the lives of Debian developers
dget (1) - - Download Debian source and binary packages
diff2patches (1) - Extract non-debian/ patches from .diff.gz files

Bug#958939: ghi: Always shows "/usr/lib/ruby/vendor_ruby/ghi/client.rb:100: warning: URI.escape is obsolete"

[Axel Beckert]

Package: ghi
Version: 1.2.0-1

Dear ghi Package Maintainers,

I receive this warning every time I call ghi.

Upon initial login:


$ ghi config --auth 
Enter 's GitHub password (never stored):   
⠤/usr/lib/ruby/vendor_ruby/ghi/client.rb:100: warning: URI.escape is obsolete
 ✔
Two-factor authentication code: 
/usr/lib/ruby/vendor_ruby/ghi/client.rb:100: warning: URI.escape is obsolete
Your ~/.gitconfig has been modified by way of:

[…]


Upon simple usage:


$ ghi
⠠/usr/lib/ruby/vendor_ruby/ghi/client.rb:100: warning: URI.escape is obsolete
[…]


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

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages ghi depends on:
ii  git   1:2.26.2-1
ii  ruby  1:2.7+1
ii  ruby-pygments.rb  1.2.1-1

Versions of packages ghi recommends:
ii  less  551-1
ii  most  5.0.0a-4+b1

ghi suggests no packages.

-- no debconf information

Bug#958938: dbab: dbab-get-list when offline

[Kevin Ryde]

Package: dbab
Version: 1.3.3-1
Severity: wishlist
File: /usr/sbin/dbab-get-list

When offline, running dbab-get-list zaps
/etc/dnsmasq.d/dbab-map.trashsites.conf to a 0 length file.
It'd be good if it left it unchanged when unable to freshen.

I've struck this doing a package upgrade when offline.  Or instead say
if the weekly cron run suggested in the man page happens when the
network is down then you lose blocking until next week.

I suppose dbab-get-list would want to download to a file and if
successful then subtract /etc/dbab/dbab.list- etc.  On error it might
exit 1.  Except I see dbab-get-list runs from postinst so of course
don't want an error exit to break that.


Incidentally, maybe dbab-map.trashsites.conf could start with a comment
line (as allowed by dnsmasq) like

# generated by dbab-get-list -- DO NOT EDIT

since /etc/dnsmasq.d also contains human-edited files.
(Likewise dbab-map.adblock.conf from dbab-add-list.)


-- System Information:
Debian Release: bullseye/sid
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dbab depends on:
ii  curl  7.67.0-2
ii  dnsmasq   2.80-1.1
ii  dnsutils  1:9.11.5.P4+dfsg-5.1+b1
ii  perl  5.30.0-9

Bug#958932: lintian: debhelper compat level 13 is no longer experimental

[Felix Lechner]

Hi,

On Sun, Apr 26, 2020 at 3:54 PM Chris Lamb  wrote:
>
> I do not follow how
> making this minor change would affect the rest of Lintian in the
> dramatic way you describe.

Following a conversation on IRC with mapreri last week I made the
changes below. They caused build failures in almost all test artifacts
on stable. The debian-compat (= 13) facility is not available.

Are you saying we could simply make the second change but not the
first? I am fine with that.

Please know, however, that mapreri asked for both. Debhelper compat
level 13 is now recommended.

09:19 < mapreri> P: django-housekeeping source:
package-uses-experimental-debhelper-compat-version 13
09:20 < mapreri> lechner: ↑ debhelper now recommends 13, please update
lintian :)

Kind regards
Felix Lechner

* * *

Author: Felix Lechner 
Date:   Mon Apr 20 11:33:53 2020 -0700

Bump recommended debhelper compat-level to 13; move experimental to 14.

diff --git a/data/debhelper/compat-level b/data/debhelper/compat-level
index 2bb3b786d..a1bce7ee4 100644
--- a/data/debhelper/compat-level
+++ b/data/debhelper/compat-level
@@ -1,8 +1,8 @@
 # warn if no versioned depend below this level
 pedantic=10
 # warn (pedantic) if does not depend on this debhelper level
-recommended=12
+recommended=13
 # warn if below this level
 deprecated=10
 # warn if equal or above
-experimental=13
+experimental=14

Bug#958845: false positive wildcard-matches-nothing-in-dep5-copyright

[Felix Lechner]

Hi,

On Sat, Apr 25, 2020 at 2:15 PM Chris Lamb  wrote:
>
> this appears to be nondeterminstic on my local machine.

Here too. It's wild! I believe it is related to Perl's UTF-8 features.
They were recently turned on in Lintian. Strings can be 'upgraded'
anytime. According to preliminary experiments it causes mismatches
here:

   
https://salsa.debian.org/lintian/lintian/-/blob/master/checks/debian/copyright.pm#L783

The check is on my list to be rewritten. Now it is more urgent. Thanks
for reporting this bug!

Kind regards
Felix Lechner

Bug#958932: lintian: debhelper compat level 13 is no longer experimental

[Chris Lamb]

Felix Lechner wrote:

> Without debhelper-compat (= 13) on stable, all our tests fail to
> build. They cease to function. We are discussing the matter with the
> debhelper and dpkg maintainers.

As I understand it, Sven was asking that level 13 was no longer warned
about by Lintian as being an "experimental" verion. As we are not
moving Lintian itself or the default version, I do not follow how
making this minor change would affect the rest of Lintian in the
dramatic way you describe.


Regards,

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

Bug#940222: libmagic1: wrong video detection

[Christoph Biedl]

Control: tags 940222 -moreinfo +confirmed
Control: severity 940222 important

Paolo Benvenuto wrote...

> I have an .avi file on a debian server. The file command reports a wrong 
> result:
> 
> $ file -i myfile.avi
> myfile.avi: image/x-tga; charset=binary
> 
> I get the same mime type with python3 and magic.from_file().
> 
> However, the same file on my ubuntu pc (rsynced) is correctly reported as a 
> video:
> 
> $ file -i myfile.avi 
> myfile.avi: video/mpeg; charset=binary

With the help of the reproducer: This is a regression introduced[1]
upstream between 5.32 and 5.33, and fixed[2] between 5.36 and 5.37.
Mapping to distributions, this exists in Debian 10 ("buster") and
Ubutunu (not checked) 19.04 and 19.10.

About Debian 10, this warrants a fix via a point release. Scheduled.

> Weirdly , nautilus sees it correctly as a video (doesn't it use the same 
> libmagic1 library?).

Possibly nautilus uses

| shared-mime-info - FreeDesktop.org shared MIME database and spec

which - if memory serves me right - is a different implementation.

Christoph

[1] FILE5_32-72-g8e6127de
[2] FILE5_36-4-gd75e8878


signature.asc
Description: PGP signature

Bug#920978: audacious: It would be great is the qt5 ui from audacios was also put into the deb package

[Stefan Lithén]

Package: audacious
Followup-For: Bug #920978

Dear Maintainer,


>From the release notes of Audacious 4.0:

"GTK2 remains available and supported as a build option, but new features will
only be added to the Qt UI going forward."

So to not loose any features QT should be included in the debian package.


Best regards, Stefan.



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

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

Versions of packages audacious depends on:
ii  audacious-plugins 3.10.1-1
ii  dbus  1.12.16-1
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-1
ii  dbus-x11 [dbus-session-bus]   1.12.16-1
ii  gtk2-engines-pixbuf   2.24.32-3
ii  libaudcore5   3.10.1-1
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libstdc++68.3.0-6

Versions of packages audacious recommends:
ii  unzip  6.0-23+deb10u1

audacious suggests no packages.

-- no debconf information

Bug#958700: pocl: nested(?) dlopen fails

[Andreas Beckmann]

On 26/04/2020 15.07, Rebecca N. Palmer wrote:
> Control: retitle -1 pocl: nested(?) dlopen fails
> Control: reassign -1 libpocl2 1.5-2
> Control: affects -1 src:libgpuarray python3-pyopencl
> 
> ocl-icd-libopencl1 dlopen()s ICDs (at
> https://sources.debian.org/src/ocl-icd/2.2.12-4/ocl_icd_loader.c/#L184).
>  With pocl 1.5, this dlopen() fails in some conditions (returns a NULL
> pointer).  dlerror says the problem is "undefined symbol: clRetainEvent".

libpocl.so.2 1.5 uses two symbols from libOpenCL.so.1:
# nm -D /usr/lib/x86_64-linux-gnu/libpocl.so.2.5.0 | grep Retain
 U clRetainEvent
 U clRetainKernel

So I think the failure can be reduced to

dlopen("libOpenCL.so.1", RTLD_LOCAL)
dlopen("libpocl.so.2", RTLD_LOCAL)

while it succeeds with

dlopen("libOpenCL.so.1", RTLD_GLOBAL)  // aka -lOpenCL
dlopen("libpocl.so.2", RTLD_LOCAL)

Build logs say

dpkg-shlibdeps: warning: symbol clRetainKernel used by 
debian/libpocl2/usr/lib/x86_64-linux-gnu/libpocl.so.2.5.0 found in none of the 
libraries
dpkg-shlibdeps: warning: symbol clRetainEvent used by 
debian/libpocl2/usr/lib/x86_64-linux-gnu/libpocl.so.2.5.0 found in none of the 
libraries

OK, there is an upstream commit supposed to fix this.

Andreas

Bug#958936: ITP: r-cran-argparse -- Command Line Optional and Positional Argument Parser

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-argparse -- Command Line Optional and Positional Argument 
Parser
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: r-cran-argparse
  Version : 2.0.1
  Upstream Author : Trevor L Davis
* URL : https://cran.r-project.org/package=argparse
* License : GPL-2+
  Programming Lang: GNU R
  Description : Command Line Optional and Positional Argument Parser
 A command line parser to
 be used with Rscript to write "#!" shebang scripts that gracefully
 accept positional and optional arguments and automatically generate usage.

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

Bug#958828: telegram-purple: FTBFS on big endian architectures

[Ben Wiederhake]

Heyaloha,

tl;dr: wontfix (cantfix)

It's awesome to see some activity! :D

I'm effectively the maintainer of telegram-purple. Not because I
actually *develop* it forward, but because I seem to be the only person
who responds to and manages pull requests, and occasionally make a new
release or a small adjustment here and there.

You might want to read up on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809623#155 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835141 for some
history. In short: My reason for abandoning debianization is that
libtgl, the underlying library, is unmaintained, unmaintainable, already
has several unfixed known bugs, and was never meant for its current use.
I'm just waiting for the day it stops working forever. Hence the attempt
to replace libtgl by TDLib:
https://github.com/majn/telegram-purple/issues/480

You are correct, libtgl is not really portable to big endian. I tried
once, here are the ruins of the attempt:
https://github.com/BenWiederhake/tgl/tree/historic/endian-correct
(Note that quite a lot has happened since then, for example merging
'tl-parser' into 'tgl'.)
The main issue is that tgl is littered with "write(fd, ,
sizeof(somestruct))" all over the place, reading and writing and
computing with internal structs that will be reused later. The best
approaches I can see are a) rewriting, b) wrapping everything in
reads/writes that copy the data to a temporary buffer, fix all endian'd
values, and only then write it to the fd, or c) just using TDLib.
All of these option sound terrible.

telegram-purple 1.4.3 can't go into Debian. I have no idea how you
managed to sneak 1.4.1 into Debian, given how buggy it is.

Holy cow, over a hundred users! And that's not yet counting the >100
people who installed it manually!
https://qa.debian.org/popcon.php?package=telegram-purple

If you want, I'd be happy to collaborate on porting of telegram-purple
away from libtgl and to tdlib, as outlined in this issue:
https://github.com/majn/telegram-purple/issues/480
Interested in making telegram-purple 2.0.0 together? :)

Cheers,
Ben

PS: For reference: Someone made an attempt to rewrite telegram-purple,
but the code is not much more than two stubs side-by-side, and there is
no license so I can't actually use it:
https://github.com/ars3niy/tdlib-purple/issues/2

Bug#946974: systemd: hang waiting for VM ethernet card to come online

[Joshua Hudson]

I never had both at the same time. I toggled of auto eth0 when I put
the line into /etc/rc.local.

> If so, what happens if you just disable rc.local?

No network connection, and "auto eth0" causes 5 mins delay at boot.

On 4/26/20, Guus Sliepen  wrote:
> On Sun, Apr 26, 2020 at 01:09:06PM -0700, Joshua Hudson wrote:
>
>> I suspect it might be confusing since I filed two different eth0-related
>> bugs.
>>
>> In this particular instance, the DHCP server was live, and I could
>> have omitted the & from the line in rc.local and it would have come up
>> only a couple of seconds slower.
>
> Just to be sure, did you have both the /etc/rc.local file trying to run
> dhclient AND /etc/network/interfaces set to automatically bring up eth0?
> If so, what happens if you just disable rc.local?
>
> --
> Met vriendelijke groet / with kind regards,
>   Guus Sliepen 
>

Bug#925056: adopting this poor lil' orphan

[Ivan Kohler]

retitle 925056 ITA: ssmtp -- extremely simple MTA to get mail off the system to 
a mail hub
thanks

I have this in production on a number of machines, so at the very least 
worth conservatively applying things that would seem to do more good 
than harm, while considering future options (migrate to something else, 
or get ssmtp into shape?).

Co-maintainers welcome.  Looks like there is no particular active 
current "upstream" either AFAICT.

-- 
_ivan

Bug#958935: neomutt does not display contents of IMAP folders that have subfolders

[Ryan Kavanagh]

Package: neomutt
Version: 20191207+dfsg.1-1.1

neomutt does not open imap folders that have subfolders.

Instead, neomutt prints a message saying that the mailbox has been
closed, attempts to reconnect. In most cases, it prints garbage on the
screen in the region where the index should be located. Only very rarely
does it succeeds in displaying the contents of the mailbox.

neomutt successfully displays the contents of folders without
subfolders.

Please see the attached neomutt debug log, where I attempt to open the
IMAP folder "+Debian". This folder has several subfolders.

My current configuration files can be found here:
https://github.com/ryanakca/ryanakca-dotfiles/tree/ab8f08d77981bcf893fc54a86c97d5c27ece3f65

-- Package-specific info:
NeoMutt 20191207
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 5.5.0-2-amd64 (x86_64)
ncurses: ncurses 6.2.20200212 (compiled with 6.2.20200212)
libidn: 1.33 (compiled with 1.33)
GPGme: 1.13.1-unknown
libnotmuch: 5.2.0
hcache backends: tokyocabinet

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules {--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec 
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss 
--idn --mixmaster --sasl --tokyocabinet

Compilation CFLAGS: -g -O2 
-fdebug-prefix-map=/build/neomutt-bCiSXv/neomutt-20191207+dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include 
-I/usr/include/lua5.3 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5

Default options:
  +attach_headers_color +compose_to_sender +compress +cond_date +debug 
  +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
  +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
  +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
  +skip_quoted +smtp +status_color +timeout +tls_sni +trash 

Compile options:
  -autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens 
  +getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify 
  -locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +sasl +smime 
  -sqlite +start_color +sun_attachment +typeahead 
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to: 

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

Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.UTF-8), LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_CA.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages neomutt depends on:
ii  libc6 2.31-0experimental0
ii  libgnutls30   3.6.13-2
ii  libgpg-error0 1.37-1
ii  libgpgme111.13.1-7+b1
ii  libgssapi-krb5-2  1.17-7
ii  libidn11  1.33-2.2
ii  liblua5.3-0   5.3.3-1.1+b1
ii  libncursesw6  6.2-1
ii  libnotmuch5   0.29.3-1+b2
ii  libsasl2-22.1.27+dfsg-2
ii  libtinfo6 6.2-1
ii  libtokyocabinet9  1.4.48-13

Versions of packages neomutt recommends:
ii  libsasl2-modules  2.1.27+dfsg-2
ii  locales   2.31-0experimental0
ii  mime-support  3.64

Versions of packages neomutt suggests:
ii  aspell0.60.8-1
ii  ca-certificates   20190110
ii  gnupg 2.2.20-1
ii  ispell3.4.00-8
pn  mixmaster 
ii  opensmtpd [mail-transport-agent]  6.6.4p1-1
ii  openssl   1.1.1g-1
pn  urlview   

Versions of packages neomutt is related to:
ii  neomutt  20191207+dfsg.1-1.1

-- no debconf information

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A
[2020-04-26 17:37:44] NeoMutt-20191207 debugging at level 3
[2020-04-26 17:37:44] 

Bug#958934: bind9: named fails to start after upgrade to 9.16.2

[R. Scott Bailey]

Package: bind9
Version: 1:9.16.2-3
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

Life was good on my DNS server until my recent update to 9.16.2-3.
After upgrading, the exact configuration that was happy now fails to
start. Example:

# named -g -u bind
26-Apr-2020 17:25:50.861 starting BIND 9.16.2-Debian (Stable Release) 

26-Apr-2020 17:25:50.861 running on Linux x86_64 5.5.0-2-amd64 #1 SMP Debian 
5.5.17-1 (2020-04-15)
26-Apr-2020 17:25:50.861 built with '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=/usr/include' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' 
'--runstatedir=/run' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' 
'--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' 
'--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' 
'--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' 
'--with-libidn2' '--with-libjson-c' '--with-lmdb=/usr' '--with-gnu-ld' 
'--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' 
'--enable-filter-' '--disable-native-pkcs11' '--enable-dnstap' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/bind9-Co3jFO/bind9-9.16.2=. -fstack-protector-strong 
-Wformat -Werror=format-security -fno-strict-aliasing 
-fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 
'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
26-Apr-2020 17:25:50.861 running as: named -g -u bind
26-Apr-2020 17:25:50.861 compiled by GCC 9.3.0
26-Apr-2020 17:25:50.861 compiled with OpenSSL version: OpenSSL 1.1.1g  21 Apr 
2020
26-Apr-2020 17:25:50.861 linked to OpenSSL version: OpenSSL 1.1.1g  21 Apr 2020
26-Apr-2020 17:25:50.861 compiled with libxml2 version: 2.9.10
26-Apr-2020 17:25:50.861 linked to libxml2 version: 20910
26-Apr-2020 17:25:50.861 compiled with json-c version: 0.13.1
26-Apr-2020 17:25:50.861 linked to json-c version: 0.13.1
26-Apr-2020 17:25:50.861 compiled with zlib version: 1.2.11
26-Apr-2020 17:25:50.861 linked to zlib version: 1.2.11
26-Apr-2020 17:25:50.861 
26-Apr-2020 17:25:50.861 BIND 9 is maintained by Internet Systems Consortium,
26-Apr-2020 17:25:50.861 Inc. (ISC), a non-profit 501(c)(3) public-benefit
26-Apr-2020 17:25:50.861 corporation.  Support and training for BIND 9 are
26-Apr-2020 17:25:50.861 available at https://www.isc.org/support
26-Apr-2020 17:25:50.861 
26-Apr-2020 17:25:50.861 found 8 CPUs, using 8 worker threads
26-Apr-2020 17:25:50.861 using 8 UDP listeners per interface
26-Apr-2020 17:25:50.869 using up to 21000 sockets
26-Apr-2020 17:25:50.877 loading configuration from '/etc/bind/named.conf'
26-Apr-2020 17:25:50.881 reading built-in trust anchors from file 
'/etc/bind/bind.keys'
26-Apr-2020 17:25:50.901 looking for GeoIP2 databases in '/usr/share/GeoIP'
26-Apr-2020 17:25:50.901 using default UDP/IPv4 port range: [1024, 65535]
26-Apr-2020 17:25:50.905 using default UDP/IPv6 port range: [1024, 65535]
26-Apr-2020 17:25:50.905 listening on IPv4 interface lo, 127.0.0.1#5353
26-Apr-2020 17:25:50.913 listening on IPv4 interface br0, 16.1.1.3#5353
26-Apr-2020 17:25:50.917 listening on IPv6 interface lo, ::1#5353
26-Apr-2020 17:25:50.921 unable to set effective uid to 0: Operation not 
permitted
26-Apr-2020 17:25:50.921 Could not open '//run/named/named.pid'.
26-Apr-2020 17:25:50.921 Please check file and directory permissions or 
reconfigure the filename.
26-Apr-2020 17:25:50.921 could not open file '//run/named/named.pid': 
Permission denied
26-Apr-2020 17:25:50.921 generating session key for dynamic DNS
26-Apr-2020 17:25:50.929 unable to set effective uid to 0: Operation not 
permitted
26-Apr-2020 17:25:50.929 Could not open '//run/named/session.key'.
26-Apr-2020 17:25:50.929 Please check file and directory permissions or 
reconfigure the filename.
26-Apr-2020 17:25:50.929 could not open file '//run/named/session.key': 
Permission denied
26-Apr-2020 17:25:50.929 could not create //run/named/session.key
26-Apr-2020 17:25:50.929 failed to generate session key for dynamic DNS: 
permission denied
26-Apr-2020 17:25:50.929 sizing zone task pool based on 29 zones
26-Apr-2020 17:25:50.933 could not configure root hints from 
'/usr/share/dns/root.hints': permission denied
26-Apr-2020 17:25:50.957 loading configuration: permission denied
26-Apr-2020 17:25:50.957 exiting (due to fatal error)

Usability of entire system (and in fact, all systems on home network) is 
impaired as primary
DNS server is unresponsive and failover to secondary server (after query to 
primary times out)
induces noticeable delay in DNS lookups (and consequently nearly all network 
operations).

I am reverting to previous bind9 package as soon as I file this 

Bug#950105: eas4tbsync 1.12-1~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 950105 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: eas4tbsync
Version: 1.12-1~deb10u1

Explanation: new upstream release, restoring compatibility with newer 
Thunderbird versions

Bug#950104: dav4tbsync 1.9-1~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 950104 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: dav4tbsync
Version: 1.9-1~deb10u1

Explanation: new upstream release, restoring compatibility with newer 
Thunderbird versions

Bug#940222:

[Paolo Benvenuto]

$ hexdump -v myfile.avi
000  ba01 0044 0004 0104 8901 f8c3 
010 bb01 1200 c480 04e1 7fe1 e0b9 b8e6 20c0
020 c0bd bf00 02e0  bf01 d403  
030        
040        
050        
060        
070        
080        
090        
0a0        
0b0        
0c0        
0d0        
0e0        
0f0        
.

don Paolo Benvenuto


Il giorno dom 26 apr 2020 alle ore 17:28 Christoph Biedl <
debian.a...@manchmal.in-ulm.de> ha scritto:

> Paolo Benvenuto wrote...
>
> > on the server:
> >
> > $ file -i myfile.avi
> > myfile.avi: image/x-tga; charset=binary
> >
> > $ file --version
> > file-5.35
> > magic file from /etc/magic:/usr/share/misc/magic
> >
> >
> > on the ubuntu bionic pc:
> >
> > $ file -i myfile.avi
> > myfile.avi: video/mpeg; charset=binary
> >
> > $ file --version
> > file-5.32
> > magic file from /etc/magic:/usr/share/misc/magic
>
> At first, sorry for the long delay. That was not intended, but sometimes
> live happens.
>
> About your report, checking my collections I could not find a way to
> reproduce the issue, and upstream made a lot of changes related to that
> detection.
>
> So could you please provide a hex dump of the first 256 bytes - that
> should be enough to analyse what has happened. If possible, can you
> also re-check on Ubuntu focal and Debian sid?
>
> Regards,
>
> Christoph
>

Bug#949890: tbsync 2.11-1~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 949890 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: tbsync
Version: 2.11-1~deb10u1

Explanation: 

Bug#958933: debhelper: recommends compat level 13, but debhelper-compat (= 13) missing from stable

[Felix Lechner]

Package: debhelper
Severity: normal
Control: block 958932 by -1

Hi,

Why is debhelper-compat (= 13) not available in stable, please, when
compat level 13 is being recommended?

The lack prevents most artifacts in Lintian's test suite from building
on stable and therefore cannot be implemented in Lintian. It leads to
false positives for the tag
package-uses-experimental-debhelper-compat-version. For details,
please see the bug blocked by this one.

Kind regards
Felix Lechner

Bug#947550: RFH: salsa.debian.org/debian/dbab

[Utkarsh Gupta]

Hello Tong,

On Sun, Apr 26, 2020 at 5:52 AM Tong Sun
 wrote:
> > 1. As a general rule, always check your package by running "cme fix
> > dpkg". Once you do that, please commit the result.
> > Let me know if you don't understand the result.
>
> Which package does this `cme` come from?
> I checked
> cme - Check or edit configuration data with Config::Model
> and think it is not the one.

It indeed is the one ;)
`apt install cme` and then run `cme fix dpkg`.


Best,
Utkarsh

Bug#958928: ffmpegfs FTCBFS: uses AC_RUN_IFELSE

[Norbert Schlia]

Hi,

although I dont't get that: the only difference to 1.10-2 in 
configure.ac is that the line


AC_INIT([FFMPEGFS], [1.10])

changed to

AC_INIT([FFMPEGFS], [1.98])

:)

But anyway, I added the patch and created 1.98-3. The patch has also 
been applied to 1.99 upstream.


Thanks for your support!

Am 26.04.2020 um 21:10 schrieb Helmut Grohne:

Source: ffmpegfs
Version: 1.98.2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ffmpegfs fails to cross build from source, because it uses AC_RUN_IFELSE
without an alternative for cross compilation. In this case,
AC_RUN_IFELSE is entirely unnecessary, because AC_CHECK_SIZEOF works.
Please consider applying the attached patch.

Helmut

Bug#925872: kcalc: Comma displays with three digit negative number fixed ?

[Ivan Kohler]

On Fri, Jan 10, 2020 at 10:40:40PM +0100, Aurélien COUDERC wrote:
> Dear Ivan,
> 
> thanks for taking the time to report this bug and help make Debian better.
> 
> I cannot reproduce the issue you describe on the current Debian stable (10/
> buster), so I believe it has been fixed since you reported the bug.
> It would be useful if you could retest on a more recent version and confirm 
> whether the bug is fixed for you too.

Confirmed.


-- 
_ivan

Bug#958932: lintian: debhelper compat level 13 is no longer experimental

[Felix Lechner]

Hi Sven,

On Sun, Apr 26, 2020 at 12:54 PM Sven Joachim  wrote:
>
>  you might want to wait for its migration before uploading a lintian fix.

I have been told that compat level 13 has been available for a while
(and presumably in testing), but we do lack the modern and recommended
facility debhelper-compat vs. d/compat in stable (and probably also in
testing). For some reason, it is not shipped until version 13 is
released.

Without debhelper-compat (= 13) on stable, all our tests fail to
build. They cease to function. We are discussing the matter with the
debhelper and dpkg maintainers.

The resolution of this bug may have to wait until debhelper version 13
is backported to stable.

Kind regards
Felix Lechner

Bug#958661: jupyter-sphinx-theme: autopkgtest for jupyter-sphinx-theme fails

[Hilmar Preuße]

reassign 958661 src:sphinx,src:jupyter-sphinx-theme
found 958661 sphinx/2.4.3-2
found 958661 jupyter-sphinx-theme/0.0.6+ds1-9
retitle 958661 sphinx breaks jupyter-sphinx-theme autopkgtest
merge 958661 958852
thanks

Am 24.04.2020 um 09:22 teilte Hilmar Preusse mit:

> your package fails to run the autopkg test, this prevents the migration
> of TL 2020 to testing. The failure is probably caused by the upload of
> Sphinx 2.4.3. to unstable.
> 
> Please be so kind to have a look at the issue.
> 
Reported a second time, merging both bugs.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#958130: hercules FTCBFS: make dependencies contain linker flags

[Philipp Kern]

Hi Helmut,

On 18.04.20 18:24, Helmut Grohne wrote:
> Source: hercules
> Version: 3.13-1
> Tags: patch upstream
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> hercules fails to cross build from source, because an upstream
> Makefile.am includes -lltdl in a Makefile dependency. This triggers
> architecture-specific behaviour in make. It looks up the flag using the
> built-in library search path (for the build architecture). However
> libltdl is only installed for the host architecture, so the library
> isn't found and make gives up. One shouldn't list such flags in
> dependencies. Please consider applying the attached patch to make
> hercules cross buildable.

Is there a way for me to test this patch? (I also take pointers.) There
are more references to -lltdl in there and curiously rebuilding the
package actually drops the shlibs reference from libltdl, so I'd have
liked to make sure the problem is actually fixed.

Kind regards and thanks
Philipp Kern

Bug#949890: buster-pu: tbsync

[Mechtilde Stehmann]

done

Am 26.04.20 um 19:04 schrieb Adam D. Barratt:
> Control: tags -1 + confirmed
> 
> On Sun, 2020-03-22 at 11:35 +0100, Mechtilde Stehmann wrote:
>> as the attachment you find the source debdiff between the
>> current stable package and the proposed upload.
>>
>> To install this package you need the proposed updates for dav4tbsync
>> (#950104) and eas4tbsync (#950105)
> 
> As with those updates, the version here:
> 
> +tbsync (2.11-1+deb10u1) buster; urgency=medium
> +
> +  * Built for Buster (Closes: #954080)
> 
> wants to be 2.11-1~deb10u1.
> 
> With that fixed, please go ahead.
> 
> Regards,
> 
> Adam
> 

-- 
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#945492: ifup/ifdown --all causes hooks to be called not per interface, but once with IFACE==--all

[Guus Sliepen]

severity 945492 wishlist
thanks

On Tue, Nov 26, 2019 at 11:16:56AM +1300, martin f krafft wrote:

> root@lotus:/etc/network/if-pre-up.d# ifup -a
> IFACE==--all
> run-parts: /etc/network/if-pre-up.d/000debug exited with return code 1
> ifup: pre-up script failed
> 
> Arguably, the hooks should be called once for each interface that is 
> brought up/down, with $IFACE set accordingly, not just once for all 
> of them.

It is called for all of them with $IFACE set accordingly, but in
addition, for each invocation of ifup -a, the scripts are run with
IFACE=--all.

This is documented behaviour, and some users' setups might depend on it.
I'll have to check whether this is still used by scripts provided by
other Debian packages, and if not then perhaps we can phase this out.

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


signature.asc
Description: PGP signature

Bug#946974: systemd: hang waiting for VM ethernet card to come online

[Guus Sliepen]

On Sun, Apr 26, 2020 at 01:09:06PM -0700, Joshua Hudson wrote:

> I suspect it might be confusing since I filed two different eth0-related bugs.
> 
> In this particular instance, the DHCP server was live, and I could
> have omitted the & from the line in rc.local and it would have come up
> only a couple of seconds slower.

Just to be sure, did you have both the /etc/rc.local file trying to run
dhclient AND /etc/network/interfaces set to automatically bring up eth0?
If so, what happens if you just disable rc.local?

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


signature.asc
Description: PGP signature

Bug#840336: elpa-markdown-mode: Freezes Emacs when using TeX input mode in a header

[Nicholas D Steeves]

Control: notfound -1 markdown-mode/2.3+154-2
Control: notfound -1 markdown-mode/2.3+210-1

On Tue, Mar 12, 2019 at 01:42:58PM +0100, Salman Mohammadi wrote:
> Dear Maintainer,
> 
> I cannot reproduce this bug on Debian Buster. Would you please check if
> the current issue is still valid? A newer version of markdown-mode is in
> the repository and it seems that this bug has been resolved in newer
> versions.
> 

Confirmed unreproducible on buster (emacs_1:26.1+1-3.2+deb10u1 and
elpa-markdown-mode_2.3+154-2).

Confirmed unreproducible on sid (emacs_1:26.3+1-1 and
elpa-markdown-mode_2.3+210-1).


signature.asc
Description: PGP signature

Bug#946974: systemd: hang waiting for VM ethernet card to come online

[Joshua Hudson]

I suspect it might be confusing since I filed two different eth0-related bugs.

In this particular instance, the DHCP server was live, and I could
have omitted the & from the line in rc.local and it would have come up
only a couple of seconds slower.

Bug#946974: systemd: hang waiting for VM ethernet card to come online

[Guus Sliepen]

Am 18.12.19 um 17:58 schrieb Joshua:

> systemd gets stuck in boot waiting for eth0 to start.
> 
> /etc/network/interfaces looks like:
> 
> source /etc/network/interfaces.d/*
> auto lo
> iface lo inet loopback
> iface eth0 inet dhcp
> 
> /etc/rc.local looks like:
> #!/bin/sh
> dhclient eth0 &
> 
> If I add a line "auto eth0" to interfaces, systemd will hang on boot
> for six and a half minutes, and even so if I remove the dhclient eth0
> line from /etc/rc.local, eth0 will not be brought up.

If you don't have a working DHCP server, then indeed with "auto eth0" it
will wait for the dhclient binary to time out, which can be a long time.
If your setup doesn't require a network to be available before starting
other daemons, then I suggest using "allow-hotplug eth0" instead of
"auto eth0". With allow-hotplug, ifupdown runs in the background
whenever udev detects eth0, and will not block systemd from booting.

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


signature.asc
Description: PGP signature

Bug#798762: Lintian tag pre-depends-directly-on-multiarch-support too much debhelper-centric

[Sven Joachim]

On 2018-01-23 11:15 +0530, Chris Lamb wrote:

> tags 798762 + moreinfo
> thanks
>
> Hi,
>
>> Lintian tag pre-depends-directly-on-multiarch-support too much
>> debhelper-centric
>
> It seems like this was not applied. That sucks. However, do we still
> need this now that the issue (and the stable release in question) was
> quite some time ago?

Perhaps the tag could be dropped entirely now?  Thankfully the
multiarch-support package is gone for good, and any package
pre-depending on it will simply not be installable in unstable and
testing, so the chance of anyone reintroducing such a predependency
should be rather low.

Cheers,
   Sven

Bug#927433: gosa 2.7.4+reloaded2-13+deb9u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 927433 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: gosa
Version: 2.7.4+reloaded2-13+deb9u2

Explanation: tighten check on LDAP success/failure [CVE-2019-11187]; fix 
compatibility with newer PHP versions; backport several other patches

Bug#958192: xdg-utils 1.1.1-1+deb9u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 958192 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: xdg-utils
Version: 1.1.1-1+deb9u2

Explanation: sanitise window name before sending it over D-Bus; correctly 
handle directories with names containing spaces; create the "applications" 
directory if needed

Bug#950854: node-anymatch 2.0.0-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 950854 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: node-anymatch
Version: 2.0.0-1+deb10u1

Explanation: remove unnecessary dependencies

Bug#958850: gosa 2.7.4+reloaded2-13+deb9u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 958850 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: gosa
Version: 2.7.4+reloaded2-13+deb9u3

Explanation: replace (un)serialize with json_encode/json_decode to mitigate PHP 
object injection [CVE-2019-14466]

Bug#949062: ifupdown: Bonding interface gets the wrong MAC address when configured for the first time

[Guus Sliepen]

reassign 949062 ifenslave
thanks

The bond options are processed by the ifenslave package, so reassigning
it there. The ifenslave package can then install an override for
systemd's MACAddressPolicy.

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


signature.asc
Description: PGP signature

Bug#947142: python-oslo.utils 3.36.5-0+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 947142 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: python-oslo.utils
Version: 3.36.5-0+deb10u1

Explanation: fix leak of sensitive information via mistral logs [CVE-2019-3866]

Bug#958814: cups 2.2.10-6+deb10u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 958814 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: cups
Version: 2.2.10-6+deb10u3

Explanation: fix heap buffer overflow [CVE-2020-3898] and "the `ippReadIO` 
function may under-read an extension field" [CVE-2019-8842]

Bug#893439: libdbi 0.9.0-4+deb9u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 893439 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: libdbi
Version: 0.9.0-4+deb9u2

Explanation: comment out _error_handler() call again, fixing issues with 
consumers

Bug#948333: frr 6.0.2-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 948333 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: frr
Version: 6.0.2-2+deb10u1

Explanation: fix extended next hop capability

Bug#950104: buster-pu: dav4tbsync

[Mechtilde Stehmann]

done

Am 26.04.20 um 18:57 schrieb Adam D. Barratt:
> Control: tags -1 + confirmed
> 
> On Sun, 2020-03-22 at 11:42 +0100, Mechtilde Stehmann wrote:
>> Hello,
>>
>> as the attachment you find the source debdiff between the
>> current stable package and the proposed upload.
>>
>> To install this package you need the proposed updates for tbsync
>> (#949890) and eas4tbsync (#950105)
> 
> +dav4tbsync (1.9-1+deb10u1) buster; urgency=medium
> +
> +  * Built for Buster
> ++ tbsync depends on it
> 
> The version needs to be lower than unstable, so 1.9-1~deb10u1, please.
> With that change, feel free to go ahead.
> 
> Regards,
> 
> Adam
> 

-- 
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#958932: lintian: debhelper compat level 13 is no longer experimental

[Sven Joachim]

Package: lintian
Version: 2.68.0
Severity: normal

I have seen the following notice on a local testbuild after upgrading
the debhelper compat level:

,
| P: ncurses source: package-uses-experimental-debhelper-compat-version 13
`

The tag's description says

,
| The debhelper compatibility version used by this package is marked as
| experimental by the debhelper developer.
`

It no longer is. :-)  Note that debhelper 13 is not in testing yet, you
might want to wait for its migration before uploading a lintian fix.


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

Kernel: Linux 5.6.7-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils 2.34-6
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.38-4
ii  gettext  0.19.8.1-10
ii  gpg  2.2.20-1
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b3
ii  libarchive-zip-perl  1.68-1
ii  libcapture-tiny-perl 0.48-1
ii  libclass-xsaccessor-perl 1.19-3+b3
ii  libclone-perl0.45-1
ii  libcpanel-json-xs-perl   4.19-1
ii  libdevel-size-perl   0.83-1+b1
ii  libdigest-sha-perl   6.02-1+b2
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libhtml-parser-perl  3.72-5
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libjson-maybexs-perl 1.004000-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmoo-perl  2.004000-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.112-1
ii  libsereal-decoder-perl   4.011+ds-1
ii  libsereal-encoder-perl   4.011+ds-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3200-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.010001-1
ii  libunicode-utf8-perl 0.62-1+b1
ii  liburi-perl  1.76-2
ii  libxml-libxml-perl   2.0134+dfsg-2
ii  libxml-writer-perl   0.625-1
ii  libyaml-libyaml-perl 0.81+repack-1
ii  man-db   2.9.1-1
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.0-10
ii  t1utils  1.41-4
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.58-1

-- no debconf information

Bug#958931: buster-pu: package node-mongodb/3.1.13+~3.1.11-2+deb10u1

[Xavier Guimard]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

bson (embedded in node-mongodb) is vulnerable to Deserialization of Untrusted
Data. This upstream fix fixes both CVE-2019-2391 and CVE-2020-7610.

Cheers,
Xavier
diff --git a/debian/changelog b/debian/changelog
index 7b663b5..5ee648d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-mongodb (3.1.13+~3.1.11-2+deb10u1) buster; urgency=medium
+
+  * Throw if invalid _bsontype is detected
+(Closes: CVE-2019-2391, CVE-2020-7610)
+
+ -- Xavier Guimard   Sun, 26 Apr 2020 21:41:23 +0200
+
 node-mongodb (3.1.13+~3.1.11-2) unstable; urgency=medium
 
   * Remove bson tests (Closes: #923353)
diff --git a/debian/patches/fix-json-parsing.diff 
b/debian/patches/fix-json-parsing.diff
new file mode 100644
index 000..f4b9c44
--- /dev/null
+++ b/debian/patches/fix-json-parsing.diff
@@ -0,0 +1,73 @@
+Description: throw if invalid _bsontype is detected 
+ Closes: CVE-2019-2391, CVE-2020-7610
+Author: Matt Broadstone
+Bug: https://snyk.io/vuln/SNYK-JS-BSON-561052
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2020-04-26
+
+--- a/bson/browser_build/bson.js
 b/bson/browser_build/bson.js
+@@ -17074,6 +17074,8 @@
+   index = serializeInt32(buffer, key, value, index, true);
+ } else if (value['_bsontype'] === 'MinKey' || value['_bsontype'] 
=== 'MaxKey') {
+   index = serializeMinMax(buffer, key, value, index, true);
++} else if (typeof value['_bsontype'] !== 'undefined') {
++  throw new TypeError('Unrecognized or invalid _bsontype: ' + 
value['_bsontype']);
+ }
+   }
+ } else if (object instanceof Map) {
+@@ -17152,6 +17154,8 @@
+   index = serializeInt32(buffer, key, value, index);
+ } else if (value['_bsontype'] === 'MinKey' || value['_bsontype'] 
=== 'MaxKey') {
+   index = serializeMinMax(buffer, key, value, index);
++} else if (typeof value['_bsontype'] !== 'undefined') {
++  throw new TypeError('Unrecognized or invalid _bsontype: ' + 
value['_bsontype']);
+ }
+   }
+ } else {
+@@ -17233,6 +17237,8 @@
+   index = serializeInt32(buffer, key, value, index);
+ } else if (value['_bsontype'] === 'MinKey' || value['_bsontype'] 
=== 'MaxKey') {
+   index = serializeMinMax(buffer, key, value, index);
++} else if (typeof value['_bsontype'] !== 'undefined') {
++  throw new TypeError('Unrecognized or invalid _bsontype: ' + 
value['_bsontype']);
+ }
+   }
+ }
+@@ -17745,4 +17751,4 @@
+ /***/ })
+ /**/ ])
+ });
+-;
+\ No newline at end of file
++;
+--- a/bson/lib/bson/parser/serializer.js
 b/bson/lib/bson/parser/serializer.js
+@@ -778,6 +778,8 @@
+ index = serializeInt32(buffer, key, value, index, true);
+   } else if (value['_bsontype'] === 'MinKey' || value['_bsontype'] === 
'MaxKey') {
+ index = serializeMinMax(buffer, key, value, index, true);
++  } else if (typeof value['_bsontype'] !== 'undefined') {
++throw new TypeError('Unrecognized or invalid _bsontype: ' + 
value['_bsontype']);
+   }
+ }
+   } else if (object instanceof Map) {
+@@ -876,6 +878,8 @@
+ index = serializeInt32(buffer, key, value, index);
+   } else if (value['_bsontype'] === 'MinKey' || value['_bsontype'] === 
'MaxKey') {
+ index = serializeMinMax(buffer, key, value, index);
++  } else if (typeof value['_bsontype'] !== 'undefined') {
++throw new TypeError('Unrecognized or invalid _bsontype: ' + 
value['_bsontype']);
+   }
+ }
+   } else {
+@@ -978,6 +982,8 @@
+ index = serializeInt32(buffer, key, value, index);
+   } else if (value['_bsontype'] === 'MinKey' || value['_bsontype'] === 
'MaxKey') {
+ index = serializeMinMax(buffer, key, value, index);
++  } else if (typeof value['_bsontype'] !== 'undefined') {
++throw new TypeError('Unrecognized or invalid _bsontype: ' + 
value['_bsontype']);
+   }
+ }
+   }
diff --git a/debian/patches/series b/debian/patches/series
index a92eae2..a27d49a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 remove-privacy-leak.patch
 remove-dependency-versions.patch
+fix-json-parsing.diff

Bug#958930: mailman: CVE-2020-12137

[Salvatore Bonaccorso]

Source: mailman
Version: 1:2.1.29-1
Severity: grave
Tags: security upstream
Control: found -1 1:2.1.23-1+deb9u4
Control: found -1 1:2.1.23-1
Control: fixed -1 1:2.1.23-1+deb9u5
Control: fixed -1 1:2.1.29-1+deb10u1

Hi,

Note filling this mainly for tracking and for the "regression" from
stable. Given that, if no upload happens at point release time it
might just prop-up from stable to unstable and so include the fix as
well for bullseye.

The following vulnerability was published for mailman.

CVE-2020-12137[0]:
| GNU Mailman 2.x before 2.1.30 uses the .obj extension for scrubbed
| application/octet-stream MIME parts. This behavior may contribute to
| XSS attacks against list-archive visitors, because an HTTP reply from
| an archive web server may lack a MIME type, and a web browser may
| perform MIME sniffing, conclude that the MIME type should have been
| text/html, and execute JavaScript code.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-12137
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12137

Regards,
Salvatore

Bug#958852: texlive-base/extra breaks jupyter-sphinx-theme autopkgtest: Builder name pickle not registered or available through entry point

[Paul Gevers]

reassign 958852 src:sphinx,src:jupyter-sphinx-theme
found 958852 sphinx/2.4.3-2
found 958852 jupyter-sphinx-theme/0.0.6+ds1-9
retitle 958852 sphinx breaks jupyter-sphinx-theme autopkgtest
thanks

On 25-04-2020 23:50, Hilmar Preuße wrote:
> Am 25.04.2020 um 22:10 teilte Paul Gevers mit:
> 
> Hi Paul,
> 
>> With recent uploads of texlive-base and texlive-extra the autopkgtest of
>> jupyter-sphinx-theme fails in testing when that autopkgtest is run with
>> the binary packages of texlive-base and texlive-extra from unstable. It
>> passes when run with only packages from testing. In tabular form:
>>
> I'm not 100% sure if it is the fault of TL 2020. Please note that at the
> same time sphinx 2.4.3 was uploaded. And you'll notice that the last
> successful run was w/ sphinx 1.8.5, meanwhile it fails w/ sphinx 2.4.3.
> 
> Hence I suspect an incompatibility of jupyter-sphinx-theme & sphinx,
> which is quite unrelated to TeX Live.

So it seems. The reference run in testing already failed now on amd64.
Expecting the same to happen on arm64.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#950105: buster-pu: eas4tbsync

[Mechtilde Stehmann]

done

Am 26.04.20 um 19:01 schrieb Adam D. Barratt:
> Control: tags -1 + confirmed
> 
> On Sun, 2020-03-22 at 11:47 +0100, Mechtilde Stehmann wrote:
>> Hello,
>>
>> as the attachment you find the source debdiff between the
>> current stable package and the proposed upload.
>>
>> To install this package you need the proposed updates for dav4tbsync
>> (#950104) and tbsync (#949890)
>>
> 
> +eas4tbsync (1.12-1+deb10u1) buster; urgency=medium
> +
> +  * Built for Buster
> ++ tbsync depends on it
> 
> That wants to be 1.12-1~deb10u1, please. With that change, please go
> ahead.
> 
> Regards,
> 
> Adam
> 

-- 
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#672699: ITP: spectrum2 -- XMPP transport/gateway

[Thorsten Glaser]

outlook 672699 being worked on but yak shaving
thanks

I’ve been delegated by the current owner of this ITP bug
to work on this. I’ve got something but licence review
will need some work, we might need to work on switching
SSL implementations also… then I ran into shaving a yak:
it hard-depends on libswiften which was RoQA’d, so I’m
packaging t̲h̲a̲t̲ as well, now.

Current WIP (not yet usable):
https://salsa.debian.org/xmpp-team/spectrum2

Yak shaving WIP:
https://salsa.debian.org/xmpp-team/swift-im

bye,
//mirabilos
-- 
Thorsten Glaser (Founding Member)
Teckids e.V. — Digital freedom with youth and education
https://www.teckids.org/

Bug#958929: git: Regression due to CVE-2020-11008 fix

[Stefan Tauner]

Package: git
Version: 1:2.20.1-2+deb10u3
Severity: normal

Dear Maintainer,

the vulnerability in CVE-2020-11008 is related to the handling
of credential helpers in git. In Buster this has been fixed in
1:2.20.1-2+deb10u3. This broke my existing configuration where
repositories have credential.helper=store set. This is
documented in /usr/share/man/man1/git-credential-store.1.gz
and other files from git, git-doc etc.
I am unsure how to proceed... is this helper now unsupported?
Is this a simple regression that should be fixed?
Do other alternatives like git-credential-cache still work or
are they broken as well?



-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'stable'), (91, 'testing'), (10, 'unstable'), (5, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages git depends on:
ii  git-man  1:2.20.1-2+deb10u3
ii  libc62.28-10
ii  libcurl3-gnutls  7.64.0-4+deb10u1
ii  liberror-perl0.17027-2
ii  libexpat12.2.6-2+deb10u1
ii  libpcre2-8-0 10.32-5
ii  perl 5.28.1-6
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages git recommends:
ii  ca-certificates  20190110
ii  less 487-0.1+b1
ii  openssh-client [ssh-client]  1:7.9p1-10+deb10u2
ii  patch2.7.6-3+deb10u1

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-9
ii  git-cvs   1:2.20.1-2+deb10u3
pn  git-daemon-run | git-daemon-sysvinit  
ii  git-doc   1:2.20.1-2+deb10u3
pn  git-el
ii  git-email 1:2.20.1-2+deb10u3
pn  git-gui   
pn  git-mediawiki 
ii  git-svn   1:2.20.1-2+deb10u3
ii  gitk  1:2.20.1-2+deb10u3
pn  gitweb

-- no debconf information

Bug#958886: xca: OID LN differs warning popups at startup

[Thomas Ward]

Forwarded upstream:
https://github.com/chris2511/xca/issues/191

On 4/26/20 5:36 AM, Sander van Grieken wrote:
> Package: xca
> Version: 2.2.1-1
> Severity: normal
>
> XCA shipped oids.txt mismatches against openssl defined OIDs, causing two
> popups to appear at application startup.
>
> Warnings are also output on console:
>
>0.00 Warning: OID:  "1.3.6.1.4.1.311.20.2.3" LN differs:  "Microsoft
> Universal Principal Name"   Microsoft User Principal Name
>2.02 Warning: OID:  "1.3.6.1.4.1.311.20.2.2" LN differs:  "Microsoft
> Smartcardlogin"   Microsoft Smartcard Login
>
>
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (750, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 
> 'testing-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.5.10+ (SMP w/12 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages xca depends on:
> ii  libc6  2.30-4
> ii  libgcc-s1  10-20200418-1
> ii  libltdl7   2.4.6-14
> ii  libqt5core5a   5.12.5+dfsg-10
> ii  libqt5gui5 5.12.5+dfsg-10
> ii  libqt5sql5 5.12.5+dfsg-10
> ii  libqt5sql5-sqlite  5.12.5+dfsg-10
> ii  libqt5widgets5 5.12.5+dfsg-10
> ii  libssl1.1  1.1.1g-1
> ii  libstdc++6 10-20200418-1
>
> Versions of packages xca recommends:
> ii  libqt5sql5-mysql   5.12.5+dfsg-10
> pn  libqt5sql5-postgresql  
>
> xca suggests no packages.
>
> -- no debconf information
>
>

Bug#949259: buster-pu: package linux/4.19.67-2+deb10u1

[Ben Hutchings]

On Sun, 2020-04-26 at 20:59 +0200, Aurelien Jarno wrote:
[...]
> Well I am not sure it can be handled at the glibc level:
> - It's not clear to me how to detect the kernel support O32_FP64. We
>   indeed have a check for the kernel version in the glibc preinst check
>   in order to make sure all the syscalls used by the glibc are
>   available. New syscalls are only added in major upstream kernel
>   versions, so it's just fine to check for a minimum version.
>   Now we are talking about a change that is introduced only in Debian
>   kernels in a minor stable version. It's not clear to me which version
>   to use in the preinst check given people can use backport kernels or
>   use their own kernel.

Yes, I see the problem.  I think the kernel ought to expose the
supported ABIs through /proc, but even if that was added upstream and
in Debian kernels it wouldn't help people using older custom kernels
that do have the option enabled.

You could do a .config check (looking in /boot/config-$(uname -r) and
/proc/config.gz) but not all custom kernels will expose their config
either way.

> - Not all binaries depends on glibc. go binaries for example do not
>   depends on glibc. It's not clear to me if they will also start using
>   the new FP ABI. If so I guess we need to add the same check in all
>   their preinst scripts.

Yes I did wonder about that after writing this.

Ben.

> So overall it looks like something to me that should go in the release
> notes instead, just like we do for an ISA level raise.
> 
> Aurelien
> 
-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.




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

Bug#958916: buster-pu: package taglib/1.11.1+dfsg.1-0.3+deb10u1

[Adam D. Barratt]

On Sun, 2020-04-26 at 14:37 -0400, Boyuan Yang wrote:
> Control: tags -1 -moreinfo
> 
> Hi Adam,
> 
> 在 2020-04-26星期日的 18:23 +0100，Adam D. Barratt写道：
> > Control: tags -1 + moreinfo
> > 
> > On Sun, 2020-04-26 at 13:05 -0400, Boyuan Yang wrote:
> > > I just took over maintenance of src:taglib via the ITS process.
> > > It
> > > has a popcon of 9+ with an annoying bug 
> > > https://bugs.debian.org/915281 floating
> > > around for 4 years. It corrupts OGG files under certain
> > > circumstances
> > > and this bug is fixed in all major Linux distributions except
> > > Debian/Ubuntu.
> > > 
> > 
> > The metadata for that bug suggests that it affects the package in
> > unstable, and is not yet fixed there? Is that correct?
> 
> Currently yes, since I'm still evaluating whether I'd backport the
> patch on Sid or directly package upstream new relesae (1.12).

Thanks.

> Do we need to solve the bug on Sid/Testing first before doing a
> stable update?

Having the issue resolved in unstable is usually a prerequisite, yes.
The fix doesn't have to have reached testing (although obviously it's
expected that it /will/).

Regards,

Adam

Bug#958928: ffmpegfs FTCBFS: uses AC_RUN_IFELSE

[Helmut Grohne]

Source: ffmpegfs
Version: 1.98.2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ffmpegfs fails to cross build from source, because it uses AC_RUN_IFELSE
without an alternative for cross compilation. In this case,
AC_RUN_IFELSE is entirely unnecessary, because AC_CHECK_SIZEOF works.
Please consider applying the attached patch.

Helmut
--- ffmpegfs-1.98.orig/configure.ac
+++ ffmpegfs-1.98/configure.ac
@@ -51,22 +51,18 @@
 AC_MSG_ERROR([Integer type 'int' must be at least 4 bytes in size.]))
 
 dnl Figure out which format string to use for time_t
+AC_CHECK_SIZEOF([time_t],,[#include ])
 AC_MSG_CHECKING([size of time_t type])
-AC_RUN_IFELSE(
-  [AC_LANG_PROGRAM(
-[[#include ]],
-[[return (sizeof (time_t) == sizeof (long) ? 0 : 1);]])],
+AS_IF([test "$ac_cv_sizeof_time_t" = "$ac_cv_sizeof_long"],
   [AC_MSG_RESULT(long)
AC_DEFINE([FFMPEGFS_FORMAT_TIME_T], ["ld"], [format string for time_t])],
   [AC_MSG_RESULT(int)
AC_DEFINE([FFMPEGFS_FORMAT_TIME_T], ["d"], [format string for time_t])])
 
 dnl Figure out which format string to use for pthread_t
+AC_CHECK_SIZEOF([pthread_t],,[#include ])
 AC_MSG_CHECKING([size of pthread_t type])
-AC_RUN_IFELSE(
-  [AC_LANG_PROGRAM(
-[[#include ]],
-[[return (sizeof (pthread_t) == sizeof (long) ? 0 : 1);]])],
+AS_IF([test "$ac_cv_sizeof_pthread_t" = "$ac_cv_sizeof_long"],
   [AC_MSG_RESULT(long)
AC_DEFINE([FFMPEGFS_FORMAT_PTHREAD_T], ["lx"], [format string for pthread_t])],
   [AC_MSG_RESULT(int)

Bug#958927: transition: botan

[GCS]

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

Hi RMs,

Only one package needs to binNMUed, but better be on the safe side.
biboumi builds fine with the 2.14.0+dfsg-1 package version of Botan.

Thanks,
Laszlo/GCS

Bug#949259: buster-pu: package linux/4.19.67-2+deb10u1

[Aurelien Jarno]

Hi,

On 2020-04-26 16:37, Julien Cristau wrote:
> On Sun, Feb 16, 2020 at 04:27:11PM +, Ben Hutchings wrote:
> > This was discussed on IRC with Julien Cristau, but unfortunately I
> > didn't save a log.  The main points that came up were:
> > 
> > * Executables built for the O32 FP64 ABI require this kernel config
> >   change and older kernel versions will refuse to load them.  So the
> >   kernel needs to be upgraded before installing any binaries built
> >   for the new FP ABI.
> > 
> > * Normally the support for an additional ABI would be included in
> >   release N.0 and used in N+1.  Since this was not present in 10.0, it
> >   would be possible for users to start upgrading to bullseye while
> >   still running a kernel that does not support O32 FP64.  We need to
> >   prevent them getting a broken system.
> > 
> > * Julien proposed that libc6 would have a preinst check on the kernel
> >   when it is changed to use the new FP ABI.  Presumably all binaries
> >   built for the new FP ABI should also have a versioned dependency on
> >   at least this version of libc6.
> > 
> > So I don't see any reason not to update the kernel configuration
> > already, as it will remain compatible with the O32 FPXX binaries in
> > buster.  Only the user-space changes in unstable (libc6 and toolchain)
> > need to be carefully coordinated.
> > 
> Here's the irc log for the record:
> 
> < bwh> jcristau: While you are here, could you have a quick look at #949259?
> < jcristau> that's kind of awkward
> < jcristau> maybe it's ok because it's only mips, but...
> < bwh> but what?
> < jcristau> well i'd normally expect bullseye to run on buster r0
> < jcristau> what's the failure mode if the kernel doesn't support O32_FP64?
> < bwh> syq_: Can you answer?
> < bwh> jcristau: It looks to me like exec will fail for programs built for 
> the new FP ABI
> < jcristau> so they'll need to get a dependency on a new libc with a preinst 
> check?
> < bwh> jcristau: That seems like a reasonable approach
> < bwh> that + prominent notice in the release notes
> < syq_> jcristau: it will complain that not support such binary
> < syq_> jcristau: if kernel doesn't enable FP64
> 
> I think you can go ahead provided that:
> - enabling this support in the kernel doesn't break previously-supported
>   userspace

I think it's fine enabling support for it in the stable kernel.

> - Aurélien as glibc maintainer is OK with this plan

Well I am not sure it can be handled at the glibc level:
- It's not clear to me how to detect the kernel support O32_FP64. We
  indeed have a check for the kernel version in the glibc preinst check
  in order to make sure all the syscalls used by the glibc are
  available. New syscalls are only added in major upstream kernel
  versions, so it's just fine to check for a minimum version.
  Now we are talking about a change that is introduced only in Debian
  kernels in a minor stable version. It's not clear to me which version
  to use in the preinst check given people can use backport kernels or
  use their own kernel.
- Not all binaries depends on glibc. go binaries for example do not
  depends on glibc. It's not clear to me if they will also start using
  the new FP ABI. If so I guess we need to add the same check in all
  their preinst scripts.

So overall it looks like something to me that should go in the release
notes instead, just like we do for an ISA level raise.

Aurelien

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

Bug#958925: grub-efi: Does not sign EFI entries.

[Santiago José López Borrazás]

Package: grub-efi
Version: 2.04-7
Severity: important

Dear Maintainer,

The new version of GRUB, which is 2.0.4-7, I find a problem that does not sign,
or does not collect the EFI signature, that for this, I have to disable the
"Secure Boot" implementation, because it does not load even the of three.

I already tried with the Debian pendrive to install and load the GRUB, along
with the command "update-grub", but nothing, I have to disable the "Secure
Boot" to do this job, because it does not load.

In the previous version, which was 2.0.4-6, it did load perfectly, but this
other version, no, not even in dreams.

This that I give, is through the secondary disk, which is /dev/sda.




-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda2 / ext4 rw,noatime,nobarrier,errors=remount-ro 0 0
/dev/loop2 /snap/spotify/41 squashfs ro,nodev,relatime 0 0
/dev/loop1 /snap/core18/1705 squashfs ro,nodev,relatime 0 0
/dev/loop0 /snap/snapd/7264 squashfs ro,nodev,relatime 0 0
/dev/sda1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
/dev/sda4 /home ext4 rw,noatime,nobarrier 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

terminal_input console
terminal_output console
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-8a5321fa-c430-49f8-a226-99174412a978' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  
8a5321fa-c430-49f8-a226-99174412a978
else
  search --no-floppy --fs-uuid --set=root 
8a5321fa-c430-49f8-a226-99174412a978
fi
echo'Loading Linux 5.5.0-2-amd64 ...'
linux   /boot/vmlinuz-5.5.0-2-amd64 
root=UUID=8a5321fa-c430-49f8-a226-99174412a978 ro  quiet i915.enable_psr=0
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-5.5.0-2-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-8a5321fa-c430-49f8-a226-99174412a978' {
menuentry 'Debian GNU/Linux, with Linux 5.5.0-2-amd64' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-5.5.0-2-amd64-advanced-8a5321fa-c430-49f8-a226-99174412a978' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 
fi
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  
8a5321fa-c430-49f8-a226-99174412a978
else
  search --no-floppy --fs-uuid --set=root 
8a5321fa-c430-49f8-a226-99174412a978
fi
echo'Loading Linux 5.5.0-2-amd64 ...'
linux   /boot/vmlinuz-5.5.0-2-amd64 

Bug#958926: qemu-kvm: QEMU KVM live migration crashes when the VM is in booting state

[Rudolph Bott]

Package: qemu-kvm
Version: 1:4.2-7
Severity: important

Dear Maintainer,

During a QEMU KVM live migration the sending process crashes if the VM is 
currently in a booting state (and possibly also during a 'soft' reboot from 
inside the VM). This has been fixed upstream:

https://github.com/qemu/qemu/commit/9b3a31c745b61758aaa5466a3a9fc0526d409188

There are also bug reports available for this problem:

https://bugzilla.redhat.com/show_bug.cgi?id=1771032
https://bugzilla.redhat.com/show_bug.cgi?id=1772774

I stumbled over this problem while testing latest builds of Ganeti 
(https://github.com/ganeti/ganeti) on Debian Bullseye and Ubuntu Focal Fossa 
which both ship qemu 4.2. The Ganeti QA suite runs a series of tests against a 
cluster and issues a VM failover (QEMU shutdown on Node A and start on Node B) 
directly followed by a live migration (QEMU live migration from Node B to Node 
A). The sending QEMU process dies with this error message:

qemu-system-x86_64: /build/qemu-oknQD6/qemu-4.2/accel/kvm/kvm-all.c:653: 
kvm_log_clear_one_slot: Assertion `mem->dirty_bmap' failed.

If you add 'sleep 2' between the reboot and the live migration instructions 
everything works fine, because the QEMU VM has left the booting state by the 
time the live migration starts. From a Ganeti point of view, this only happens 
when using the "sharedfile" storage backend. When you use e.g. DRBD, the Ganeti 
commands take a bit longer to finish which gives the VM enough time to boot up.

For further reference, the same issue has been opened (and fixed) for the 
respective Ubuntu package:

https://bugs.launchpad.net/qemu-kvm/+bug/1872107

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

Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to default 
locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages qemu-kvm depends on:
ii  qemu-system-x86  1:4.2-7

qemu-kvm recommends no packages.

qemu-kvm suggests no packages.

-- debconf information excluded

Bug#948375: buster-pu: package ceph/12.2.12+dfsg-1

[Bernd Zeimetz]

Hi Julien,

> That's kind of unreadable.  We like to have the proposed diff directly
> in the p-u bug, along with a description of the changes, what they fix,
> what the risks are.

how does a 48k lines diff as text help you? Its a mix of fixes for about
70 bugs (and 12.2.13 was released already, so >>100 bugs). Of course,
you can read the diff, but you wouldn't be able to review it properly.

> Pointers to more information elsewhere are not bad,
> but they don't replace information that should be in the bug.  In this
> case the upstream changelog doesn't really provide much context on which
> if any of the fixed issues are serious enough for us to want the update
> in stable.


https://docs.ceph.com/docs/master/releases/luminous/#v12-2-11-luminous
has all the info. Including links to th ebugs and the discussion.
Including various CVEs.

It is a stable point release, like it is done for firefox and others. it
is very well tested by upstream and I will definitely not start to pick
single commit - I don't have the infrastructure to run the regression
tests and that is done by upstream in a proper way. And I hope you also
don't want to risk to ship something that slowly degrades stored data.


>> - I've basically imported the changes the Ubuntu people have done in
>>   Ubuntu together with 12.2.12. So I assume this should work well, I did
>>   not yet test it properly as I want to wait for a reply from you. I'll
>>   prepare a backport of 14.2.x as soon as it migrates to testing anyway.
>>
> A reply from us tends to not be forthcoming before the proposed changes
> have been tested, so there's a bit of a chicken and egg issue.

But I'm not wasting an enourmous amount of time if there is a chance
that you say no anyway.


>> - The issue with ceph is that upstream doesn't do QA for 32bit and our
>>   selection of unusual architectures. I don't know if it builds on all
>>   buildds without trying...
>>
> There should be porterboxes available for all our release architectures.

I'll remove 32bit for bullseye, its way too broken to fix it properly
anyway, and not supported by upstream anymore.


It is really sad that Debian was not able to ship ceph in a proper state
until now, the former maintainers had similar discussions with the
release team and its even completely broken on arm64 in stable.


Really sad about this,

Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#958916: buster-pu: package taglib/1.11.1+dfsg.1-0.3+deb10u1

[Boyuan Yang]

Control: tags -1 -moreinfo

Hi Adam,

在 2020-04-26星期日的 18:23 +0100，Adam D. Barratt写道：
> Control: tags -1 + moreinfo
> 
> On Sun, 2020-04-26 at 13:05 -0400, Boyuan Yang wrote:
> > I just took over maintenance of src:taglib via the ITS process. It
> > has a popcon of 9+ with an annoying bug 
> > https://bugs.debian.org/915281 floating
> > around for 4 years. It corrupts OGG files under certain circumstances
> > and this bug is fixed in all major Linux distributions except
> > Debian/Ubuntu.
> > 
> 
> The metadata for that bug suggests that it affects the package in
> unstable, and is not yet fixed there? Is that correct?

Currently yes, since I'm still evaluating whether I'd backport the patch on
Sid or directly package upstream new relesae (1.12).

Do we need to solve the bug on Sid/Testing first before doing a stable update?
Anyway I just prepared an upload onto Sid with the backported patch first in
case that is necessary.

-- 
Regards,
Boyuan Yang


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

Bug#958924: partclone: Version splashes and usage use "unset_name" as executable name

[наб]

Package: partclone
Version: 0.3.11-1+b3
Version: 0.3.13+dfsg-4
Severity: minor
Tags: patch

Dear Maintainer,

When invoked without path, the partclone.XXX executables all report
as "unset_name", as in the transcript below; first in buster,
then a sid chroot:


nabijaczleweli@tarta:~$ sudo partclone.fat -N
unset_name v0.3.11 http://partclone.org
Usage: unset_name [OPTIONS]
Efficiently clone to an image, device or standard output.

nabijaczleweli@tarta:~/uwu$ sudo partclone.fat -v
Partclone : v0.3.11 (09daead2d757576cd846cb758dab011801e3fb7b)

root@tarta:/# partclone.chkimg boot.img
Unknown option 'boot.img'.
unset_name v0.3.13 http://partclone.org
Usage: unset_name [OPTIONS]
Check partclone image.

root@tarta:/# partclone.fat -N
unset_name v0.3.13 http://partclone.org
Usage: unset_name [OPTIONS]
Efficiently clone to an image, device or standard output.

root@tarta:/# partclone.fat -v
Partclone : v0.3.13 (930e8a1cd88a44d50902e73cf14eb78d6a46a967)


I've narrowed this down to the save_program_name() function ignoring
argv[0] when it contains no slashes, and am attaching a patch,
based on 0.3.13+dfsg-4, that uses the full argument in that case
instead, as well as one that fixes a typo that bugged me.

If you prefer, there's also a git repository you can pull from at
.

Best,
наб


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

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

Versions of packages partclone depends on:
ii  libblkid1  2.33.1-0.1
ii  libc6  2.28-10
ii  libcom-err21.44.5-1+deb10u3
ii  libext2fs2 1.44.5-1+deb10u3
ii  libncursesw6   6.1+20181013-2+deb10u2
ii  libntfs-3g883  1:2017.3.23AR.3-3
ii  libtinfo6  6.1+20181013-2+deb10u2
ii  libuuid1   2.33.1-0.1
ii  nilfs-tools2.2.7-1

partclone recommends no packages.

partclone suggests no packages.

-- no debconf information
From 941a7e0e904c9a209571f5a45d402e9994a0c85e Mon Sep 17 00:00:00 2001
From: nabijaczleweli 
Date: Sun, 26 Apr 2020 19:38:52 +0200
Subject: [PATCH 1/2] Fix exec_name not updating to argv[0] if it contains no
 slashes

Before:
root@tarta:/# /sbin/partclone.fat -N
partclone.fat v0.3.13 http://partclone.org
Usage: partclone.fat [OPTIONS]
Efficiently clone to an image, device or standard output.

root@tarta:/# partclone.fat -N
unset_name v0.3.13 http://partclone.org
Usage: unset_name [OPTIONS]
Efficiently clone to an image, device or standard output.


After:
root@tarta:/# /sbin/partclone.fat -N
partclone.fat v0.3.13 http://partclone.org
Usage: partclone.fat [OPTIONS]
Efficiently clone to an image, device or standard output.

root@tarta:/# partclone.fat -N
partclone.fat v0.3.13 http://partclone.org
Usage: partclone.fat [OPTIONS]
Efficiently clone to an image, device or standard output.

---
 src/partclone.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/partclone.c b/src/partclone.c
index 6b83ab7..fd427de 100644
--- a/src/partclone.c
+++ b/src/partclone.c
@@ -308,6 +308,8 @@ static void save_program_name(const char* argv0) {
 	if (last_slash != 0) {
 
 		exec_name = last_slash + 1;
+	} else {
+		exec_name = argv0;
 	}
 }
 
-- 
2.20.1

From b02b6c8a47df8709d9fdf7a3f0ca09af8196ccde Mon Sep 17 00:00:00 2001
From: nabijaczleweli 
Date: Sun, 26 Apr 2020 20:15:14 +0200
Subject: [PATCH 2/2] Fix Norma[nl]ly typo in manpages

---
 docs/partclone.8   | 4 ++--
 docs/partclone.chkimg.8| 2 +-
 docs/partclone.chkimg.xml  | 2 +-
 docs/partclone.dd.8| 4 ++--
 docs/partclone.dd.xml  | 4 ++--
 docs/partclone.imager.8| 4 ++--
 docs/partclone.imager.xml  | 4 ++--
 docs/partclone.restore.8   | 4 ++--
 docs/partclone.restore.xml | 4 ++--
 docs/partclone.xml | 4 ++--
 10 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/docs/partclone.8 b/docs/partclone.8
index 8f98055..10e39be 100644
--- a/docs/partclone.8
+++ b/docs/partclone.8
@@ -75,14 +75,14 @@ The program follows the usual GNU command line syntax, with long options startin
 .PP
 \fB\-s \fR\fB\fIFILE\fR\fR, \fB\-\-source \fR\fB\fIFILE\fR\fR
 .RS 4
-Source FILE\&. The FILE could be a image file(made by partclone) or device depend on your action\&. Normanly, backup source is device, restore source is image file\&.
+Source FILE\&. The FILE could be a image file(made by partclone) or device depend on your action\&. Normally, backup source is device, restore source is image file\&.
 .sp
 Receving data from pipe line is supported ONLY for restoring, just ignore \-s 

Bug#958300: linux: enable infiniband kconfig in cloud images for Azure/HyperV

[Bastian Blank]

Hi Luca

On Mon, Apr 20, 2020 at 10:19:22AM +, Luca Boccassi wrote:
> Azure VMs can get accelerated networking for DPDK applications via the
> NETVSC driver (https://doc.dpdk.org/guides/nics/netvsc.html), but this
> requires enabling the Infiniband kernel modules.

I have to say, I'm not so sure this is actually the same thing.  This
linked documentation shows how to use DPDK on top of the netsvc device,
using uio_hv_generic.

What you are talking about is using DPDK on the Mellanox card, which is
documented here:
https://doc.dpdk.org/guides/nics/mlx4.html
https://docs.microsoft.com/en-us/azure/virtual-network/setup-dpdk

This requires the following modules:
- mlx4_ib
- ib_uverbs

Regards,
Bastian

-- 
Women are more easily and more deeply terrified ... generating more
sheer horror than the male of the species.
-- Spock, "Wolf in the Fold", stardate 3615.4

Bug#958814: buster-pu: package cups/2.2.10-6+deb10u3

[Adam D. Barratt]

On Sun, 2020-04-26 at 19:56 +0200, Didier 'OdyX' Raboud wrote:
> Le samedi, 25 avril 2020, 18.48:34 h CEST Adam D. Barratt a écrit :
> > Control: tags -1 + confirmed
> > 
> > On Sat, 2020-04-25 at 16:33 +0200, Didier 'OdyX' Raboud wrote:
> > > CVE-2020-3898 and CVE-2019-8842 got fixed in unstable, after
> > > coordinated disclosure.
> > 
> > Please go ahead.
> 
> Uploaded, thanks for the quick ACK.
> 
> Should I file a similar request for oldstable?

Assuming you'd like to update the package there, yes please. :)

Regards,

Adam

Bug#958850: stretch-pu: package gosa/2.7.4+reloaded2-13+deb9u3

[mike . gabriel]

Hi Julien,

Am Sonntag, 26. April 2020 schrieb Julien Cristau:
> Control: tag -1 moreinfo
> 
> Hi Mike,
> 
> On Sat, Apr 25, 2020 at 09:57:01PM +0200, Mike Gabriel wrote:
> > Package: release.debian.org
> > Severity: normal
> > Tags: stretch
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > 
> > Dear release team,
> > 
> > this is a follow-up for #927433 (about +deb9u2).
> > 
> > +  * debian/patches/1047_CVE-2019-14466-1_replace_unserialize_with_json_
> > +encode+json_decode.patch:
> > ++ Replace (un)serialize with json_encode/json_decode to mitigate PHP 
> > object
> > +  injection (CVE-2019-14466).
> > 
> > Since I last uploaded the stretch-pu of gosa, one more CVE issue got
> > known and already addressed in the Git branch.
> > 
> > I will follow-up with a +deb9u3 upload on the +deb9u2 upload. Luckily,
> > this one is not as massive as the +deb9u2 one.
> > 
> Which package versions fix this for buster and sid?
> 
> Cheers,
> Julien

see...
https://security-tracker.debian.org/tracker/CVE-2019-14466

in fact, CVE-2019-14466 has not been fixed in buster, yet. I thought I had, 
obviously had not. I can prepare an upload for that tomorrow.

The gosa in sid, regarding CVE-2019-14466,  got fixed in 2.7.4+reloaded3-10.

Greets,
Mike

-- 
Gesendet von meinem Sailfish Gerät

Bug#958923: RM: xul-ext-quotecolors/0.3-6 in old-stable

[Carsten Schoenert]

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

Dear RT,

the package xul-ext-quotecolors, an Thunderbird extension, isn't usable
any longer since Thunderbird ESR has moved to 68.x due API changes within
Thunderbird. It's dead from the upstream side and wont get updates in
the future, please remove the package from the old-stable release.

There is a RC bug about the non usable functionality in testing.
https://bugs.debian.org/950512

I also requested the removal from unstable
https://bugs.debian.org/958913

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

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

Bug#958922: RM: xul-ext-quotecolors/0.3-6 in stable

[Carsten Schoenert]

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

Dear RT,

the package xul-ext-quotecolors, an Thunderbird extension, isn't usable
any longer since Thunderbird ESR has moved to 68.x due API changes within
Thunderbird. It's dead from the upstream side and wont get updates in
the future, please remove the package from the stable release.

There is a RC bug about the non usable functionality in testing.
https://bugs.debian.org/950512

I also requested the removal from unstable
https://bugs.debian.org/958913

Thanks
Carsten Schoenert

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

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

Bug#958921: libgpg-error-dev: please don't ship .la files

[Pino Toscano]

Package: libgpg-error-dev
Version: 1.37-1
Severity: normal
Tags: patch
User: codeh...@debian.org
Usertags: la-file-removal

Hi,

as per Policy §10.2, .la files should not be included in the Debian 
package.  Patch attached for this.
(Of course the patch removes only the "unix" .la file, not the ones
used for the mingw toolchain.)

Thanks,
-- 
Pino
--- a/debian/libgpg-error-dev.install.in
+++ b/debian/libgpg-error-dev.install.in
@@ -3,6 +3,5 @@ usr/bin/gpgrt-config
 usr/include/* usr/include/@DEB_HOST_MULTIARCH@/
 usr/lib/*/libgpg-error.a
 usr/lib/*/libgpg-error.so
-usr/lib/*/libgpg-error.la
 usr/lib/*/pkgconfig/gpg-error.pc
 usr/share/aclocal/*.m4
--- a/debian/rules
+++ b/debian/rules
@@ -23,6 +23,7 @@ endif
 
 override_dh_auto_install-arch:
dh_auto_install --parallel --builddirectory=build
+   rm $(shell pwd)/debian/tmp/usr/lib/*/libgpg-error.la
 
 override_dh_install:
sed -e"s,@DEB_HOST_MULTIARCH@,${DEB_HOST_MULTIARCH},g" \

Bug#958920: Intent To Remove: certificatepatrol

[Christoph Biedl]

Package: src:certificatepatrol
Severity: important

Hereby I declare my intent to request removal of the certificatepatrol from
Debian in unstable. It has already been removed from testing and is
missing in relase 10 ("buster").

Rationale: This package is one of the many affected by the Mozilla
massacer, in other words, it is no longer usable with a Mozilla product
where XUL support has been removed.

While the functionality is missed a lot - I could tell a story about a
phishing attempt I could have detected earlier using that - there is
no hope the package will be made usable again. Upstream showed little
enthusiasm in a rewrite, and an issue about that[1] hasn't shown any
activty in a long time.

So give it final week in case I missed a bit - then let go.

Regards,

Christoph

[1] https://github.com/tg-x/certpatrol/issues/1


signature.asc
Description: PGP signature

Bug#958894: grub-efi-amd64-bin: Secure Boot forbids loading? module from .../multiboot.mod

[Steve McIntyre]

On Sun, Apr 26, 2020 at 06:49:15PM +0200, Fabian Greffrath wrote:
>Wouldn't it be possible to simply sign some specific grub modules? 

Sorry, no. Grub doesn't have any support for signing of modules
itself. For Secure Boot, all the desired modules have to built-in.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"

Bug#958814: buster-pu: package cups/2.2.10-6+deb10u3

[Didier 'OdyX' Raboud]

Le samedi, 25 avril 2020, 18.48:34 h CEST Adam D. Barratt a écrit :
> Control: tags -1 + confirmed
> 
> On Sat, 2020-04-25 at 16:33 +0200, Didier 'OdyX' Raboud wrote:
> > CVE-2020-3898 and CVE-2019-8842 got fixed in unstable, after
> > coordinated disclosure.
> 
> Please go ahead.

Uploaded, thanks for the quick ACK.

Should I file a similar request for oldstable?

Cheers,
OdyX

Bug#958919: ITP: mpsolve -- multiprecision polynomial solver

[Doug Torrance]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 

* Package name: mpsolve
  Version : 3.1.8
  Upstream Author : Leonardo Robol 
* URL : https://numpi.dm.unipi.it/software/mpsolve
* License : GPL
  Programming Lang: C
  Description : multiprecision polynomial solver

MPSolve stands for Multiprecision Polynomial SOLVEr. It is a software that
aims to provide an easy to use (hopefully) universal blackbox for solving
polynomials and secular equations.

Among its features you can find:

* Arbitrary precision approximation.
* Guaranteed inclusion radii for the results.
* Exploiting of polynomial structures: it can take advantage of sparsity as
  well as coefficients in a particular domain (i.e. integers or rationals).
* It can be specialized for specific classes of polynomials. As an example,
  see the roots of the Mandelbrot polynomial of degree 2.097.151 computed in
  about 10 days on a dual Xeon server.

I am interested in packaging mpsolve as it will be a dependency for
Macaulay2, a computer algebra system I eventually intend to package
(see #439888).

I will be packaging mpsolve under the umbrella of the Debian Science Team.