Bug#961195: transition: glibc

[Adrian Bunk]

On Sat, Jul 04, 2020 at 12:14:49AM +0200, Aurelien Jarno wrote:
>...
>   - nageru_2.0.0-3: This package is using lld as the linker instead of
> ld, and it is over picky about the usage of the __*_finite functions
> in dynamic libraries (here libx264.so). The package builds fine with
> ld, so it looks an LLVM issue to me. The easiest workaround is to
> binNMU x264 as part of the transition.
>...

zita-resampler also seems to need a binNMU:
https://buildd.debian.org/status/package.php?p=nageru

...
ld.lld: error: 
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libzita-resampler.so:
 undefined reference to __exp_finite
...

> Aurelien

cu
Adrian

Bug#965353: [Pkg-javascript-devel] Bug#965353: Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined

[Xavier]

Le 26/07/2020 à 18:54, Pirate Praveen a écrit :
> 
> 
> On Sun, Jul 26, 2020 at 19:35, Adrian Bunk  wrote:
>> On Sun, Jul 26, 2020 at 09:55:47PM +0530, Pirate Praveen wrote:
>>>  I'm wondering if this will require another bootstraping cycle as
>>> node-babel7
>>>  autopkgtest is also broken and it depends on itself.
>>
>> If the problem is in node-lodash and gets fixed there,
>> shouldn't this fix everything?
> 
> I don't think the problem is in lodash as I can see babel upstream is
> already using lodash 4.17.19 in their yarn.lock
> https://github.com/babel/babel/blob/f7964a9ac51356f7df6404a25b27ba1cffba1ba7/yarn.lock#L7114

Hi,

our lodash build does not provide the same result than npm package.

> I think babel needs to use the same version of lodash it was built with
> and a breaking change in lodash was released as a minor/patch
> release/security release.
> 
> I think it is becoming more and more common to break API during security
> releases (we had to face this in rack/rails in ruby team).
> 
> Babel build situation is indeed a mess.

the problem is in lodash.

> They are dicussing removing lodash from babel though see
> https://github.com/babel/babel/pull/11789

Bug#936699: hg-git: Python2 removal in sid/bullseye

[Sandro Tosi]

On Fri, 30 Aug 2019 07:20:24 + Matthias Klose  wrote:
> Package: src:hg-git
> Version: 0.8.12-1.1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

there's a new alpha release from upstream
https://foss.heptapod.net/mercurial/hg-git/-/tree/0.9.0a1 which seems
to suggest some python3 porting work has been carried out already,
further commits on master
https://foss.heptapod.net/mercurial/hg-git/-/commits/branch/default
may indicate more work is needed -- but it's progress

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#957589: nemo: ftbfs with GCC-10

[Norbert Preining]

On Thu, 23 Jul 2020, Fabio Fantoni wrote:
> The gcc10 errors are already solved upstream in 4.6:
> https://github.com/linuxmint/nemo/commit/c5f66756f0e20f763b67e4a64d7e898411a605c0
> 
> I not have time to test build with gcc10 now, someone have gcc10 build
> of latest nemo to be sure is ok before close this?

Same here, will do it in a few days.

Norbert

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

Bug#957089: cjs: ftbfs with GCC-10

[Norbert Preining]

Hi Fabio,

> I see only symbols "unexpected cases" and not build errors, I not have

Yes, that is the problem. Gcc 10 seemingly breaks practically all
packages due to symbols changes - I am really surprised that this
happens, is this on purpose?

I will make updates to the packages after the long weekend we are having
here (and a online conference I somehow co-organized).

Best

Norbert

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

Bug#939259: webcheck: Python2 removal in sid/bullseye

[Sandro Tosi]

On Tue, 22 Oct 2019 22:02:22 +0200 Arthur de Jong  wrote:
>
> On Mon, 2019-09-02 at 15:09 +0200, Stefano Rivera wrote:
> > Your package either build-depends, depends on Python2, or uses
> > Python2 in the autopkg tests.  Please stop using Python2, and fix
> > this issue by one of the following actions.
> >
> > - Convert your Package to Python3.
>
> I would like to do this but it requires some time that I don't have a
> lot of available at the moment. Any help will we appreciated.
>
> The upstream repo has a lot of changes relative to the latest release
> because there was a plan to improve performance and make the tool a bit
> more lightweight (most of that was done). While the code in the repo
> should be reasonably stable it is not as nice as it could be and I
> would also like to switch to using requests and a few other things but
> it kind of lost focus on it :(
>
> Anyway, help is very welcome.
>
> I'm also not too adverse to removal from testing to help the Python 2
> migration along.

9 months have passed and i dont see any progress on this porting to
python3: last commits on https://arthurdejong.org/git/webcheck are
from 2013 (!)

Are you still interested in this program (which you wrote)? should we
just remove it from Debian entire?

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#936146: archivemail - Python 3 porting

[Sandro Tosi]

Hey Scott and Jonathan,

On Thu, 28 May 2020 13:56:59 -0400 (EDT) Scott Talbert  wrote:
> On Tue, 26 May 2020, Jonathan Dowland wrote:
>
> >> archivemail seems to be a good candidate to RM due to dead upstream.
> >> However, it still has a relatively high popcon, so people seem to be using
> >> it.
> >>
> >> I'm willing to take a stab at porting to Python 3 if anyone is available to
> >> test it?  The port effort doesn't look that bad at first glance, but I
> >> don't use this package.
> >
> > I'm happy to test anything you produce, but I'd warn you that I think
> > it's quite a significant piece of work. From what I remember when I last
> > looked at hacking a feature into it (#736327), archivemail uses the
> > older of two different APIs provided by the python "mailbox" library,
> > and only the newer one was carried forward to Python 3. So moving away
> > from that older API is a big part of the work.
>
> You were right.  This was harder than I expected.  :)  Mainly it is
> exactly as you described - the rfc822.Message class (which doesn't exist
> in Python 3) does not map exactly to the email.message.Message class.  I'm
> stuck at the moment with figuring out how to calculate the message size.
> In rfc822.Message, you could access the file handle directly and get the
> size that way.

do you have any plan on completing this port? I'm not a user of
archivemail but it looks like it should be removed, not salvaged:

* no new upstream releases since 2011 (!)
* last upload to debian in 2014
* retired from fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1777616

maybe it's time to let it go?

If i dont hear otherwise in a week, i'll file for its removal

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#936945: lightyears and python3: issue/pull-request logged upstream

[Sandro Tosi]

Hey Steve,

On Mon, 11 Nov 2019 17:14:00 +0100 Steve Cotton
 wrote:
> Package: src:lightyears
>
> forwarded 936945 https://github.com/20kly/20kly/issues/2
> tags 936945 + patch upstream
> thanks
>
> Both #936945 and #912488 are about migrating this game to something other than
> Python2. The above Github link leads to my fork with a python3-pygame port,
> there's another Github fork that's working on a Godot port.
>
> An old version of my fork's changes is in #912488.

Would you be interested in taking over maintenance of this package?
it's in rather bad shape and you clearly show interest (at least for
the application itself).

Cheers,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#966337: ITP: golang-github-creekorful-mvnparser -- Go parser for Maven POM

[Alois Micard]

Package: wnpp
Severity: wishlist
Owner: Alois Micard 

* Package name: golang-github-creekorful-mvnparser
  Version : 1.0.0-1
  Upstream Author : Aloïs Micard
* URL : https://github.com/creekorful/mvnparser
* License : Expat
  Programming Lang: Go
  Description : Go parser for maven Project Object Model (POM) file

 This Go library contains support to un-marshal Maven POM file (pom.xml).

Regards

-- 
Aloïs Micard (creekorful) 

GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2

Bug#955329: linux-image-4.9.0-12-amd64 breaks LUKS root

[David Christensen]

On 2020-07-26 18:15, David wrote:

On Mon, 27 Jul 2020 at 09:47, David Christensen
 wrote:

On 2020-03-30 02:58, deloptes wrote:

David Christensen wrote:



https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955329


I updated/ upgraded the system today and whatever broke LUKS when I
'apt-get dist-upgrade' and installed kernel 4.9.0-12-amd64 several
months ago now breaks LUKS when I try to boot the kernel that I have
been using prior and since -- 4.9.0-11-amd64.  Fortunately, LUKS still
works with my oldest available kernel, 4.9.0-9-amd64.


lsinitramfs will give you the content of the initrd


Any other suggestions?


Hi, just a few thoughts from a dumb onlooker ...

I notice that your bug 955329 is filed against the linux-image
package around 4 months ago, and that there has been no reply from the
maintainers.

Looking around for similar bugs, I found [1] this comment by one of
the maintainers:


LUKS volumes are recognised and set uo by userland, so are you sure
this is due to the kernel upgrade?


So maybe it's not helpful to focus on the kernel, and I wonder if you
would get a response or debugging assistance if you were to report
this against the cryptsetup-initramfs package.

Another suggestion, although I am far from an expert in these matters,
I wonder if (per man initramfs-tools) you have tried using a kernel
boot parameter 'break=premount' and then see what happens if you try
to run your cryptsetup command in the initramfs shell.

For example, I would try:
(initramfs) blkid
(initramfs) cryptsetup open /dev/whatever/blkid/says somename
(initramfs) blkid

and expect to see /dev/mapper/somename in the output of the last
command if it succeeds, or some clue if it does not.

You can also run commands like
(initramfs) mount
(initramfs) ls
(initramfs) cat /cryptroot/crypttab
to investigate further.

I confirm all these commands do work for me on a Debian 10 machine.

Also, if that fails, it might be useful to confirm that the drive can be
decrypted when temporarily connected to another working system.

Hope this helps.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827342#10


Thanks for the suggestions.


Given the motherboard is circa 2011, Debian 9 has reached end of 
maintenance, and the lack of response on my initial bug report, I doubt 
this bug will be fixed.  Even if I had some success in debugging the 
issue and submitted reports and/or patches, I don't know if or what the 
Debian project would do with them.



It's time to put in a fresh system drive and try something newer that is 
actively supported.



David

Bug#966331: mathomatic: Build with libedit

[tony mancill]

Hello Bastian,

On Sun, Jul 26, 2020 at 11:24:23PM +0200, Bastian Germann wrote:
> Package: mathomatic
> Severity: normal
> 
> Debian's editline package is not updated in a long time. There is the
> alternative package libedit which stems from the same source but is
> properly maintained in Debian. This patch builds mathomatic with that
> instead.

Thank you for the patch.  I will apply this and upload soon.

Thank you,
tony


signature.asc
Description: PGP signature

Bug#966336: libjpeg-turbo8-dev has no installation candidate

[Jos Spencer]

Package: libjpeg-turbo8-dev
Severity: normal
Tags: newcomer

Dear Maintainer,

Attempting to install libjpeg-turbo8-dev gives an error about having no 
installation candidate.
Installing libjpeg62-turbo-dev is a viable workaround

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-18362-Microsoft
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: unable to detect

Versions of packages libjpeg-turbo8-dev depends on:
ii  libc6-dev [libc-dev]  2.27-3ubuntu1
pn  libjpeg-turbo8

libjpeg-turbo8-dev recommends no packages.

libjpeg-turbo8-dev suggests no packages.

Bug#965353: [Pkg-javascript-devel] Bug#965353: Bug#965353: Bug#965353: Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined

[Nicolas Mora]

Le 20-07-26 à 18 h 01, Pirate Praveen a écrit :
> 
>>
>> File in node-lodash unstable package:
>> 4.17.19+dfsg-1 _baseOrderBy.js https://paste.debian.net/1157886/
>>
I made a dirty hack to check my theory and it looks like if I patch this
file by replacing 'isArray' with 'Array.IsArray' or if I append 'isArray
= require('./isArray')', I'm able to build broken packages like
node-babel7 or glewlwyd.

The only way I found to patch the package node-lodash is to manually
change the file lodash.js here:
https://salsa.debian.org/js-team/node-lodash/-/blob/master/lodash.js#L3724
and replacing 'isArray' with 'Array.IsArray'.

/Nicolas

Bug#955329: linux-image-4.9.0-12-amd64 breaks LUKS root

[David]

On Mon, 27 Jul 2020 at 09:47, David Christensen
 wrote:
> On 2020-03-30 02:58, deloptes wrote:
> > David Christensen wrote:

> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955329
>
> I updated/ upgraded the system today and whatever broke LUKS when I
> 'apt-get dist-upgrade' and installed kernel 4.9.0-12-amd64 several
> months ago now breaks LUKS when I try to boot the kernel that I have
> been using prior and since -- 4.9.0-11-amd64.  Fortunately, LUKS still
> works with my oldest available kernel, 4.9.0-9-amd64.
>
> > lsinitramfs will give you the content of the initrd
>
> Any other suggestions?

Hi, just a few thoughts from a dumb onlooker ...

I notice that your bug 955329 is filed against the linux-image
package around 4 months ago, and that there has been no reply from the
maintainers.

Looking around for similar bugs, I found [1] this comment by one of
the maintainers:

> LUKS volumes are recognised and set uo by userland, so are you sure
> this is due to the kernel upgrade?

So maybe it's not helpful to focus on the kernel, and I wonder if you
would get a response or debugging assistance if you were to report
this against the cryptsetup-initramfs package.

Another suggestion, although I am far from an expert in these matters,
I wonder if (per man initramfs-tools) you have tried using a kernel
boot parameter 'break=premount' and then see what happens if you try
to run your cryptsetup command in the initramfs shell.

For example, I would try:
(initramfs) blkid
(initramfs) cryptsetup open /dev/whatever/blkid/says somename
(initramfs) blkid

and expect to see /dev/mapper/somename in the output of the last
command if it succeeds, or some clue if it does not.

You can also run commands like
(initramfs) mount
(initramfs) ls
(initramfs) cat /cryptroot/crypttab
to investigate further.

I confirm all these commands do work for me on a Debian 10 machine.

Also, if that fails, it might be useful to confirm that the drive can be
decrypted when temporarily connected to another working system.

Hope this helps.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827342#10

Bug#966283: calibre: Literal "<>" characters in text file not converted properly

[Norbert Preining]

severity 966283 minor
tags 966283 + moreinfo unreproducible
thanks

Hi

> Converting a text file (to epub) which included many lines like
> "
>  = 
> "
> resulted in just the character "=". 

To add to Yokota-san's excellent answer, I cannot reproduce this.
I created a text document:

***
This is a test document for Calibre txt to epub conversion.
We need to make sure that calibre detects the correct
type of input.

 = 

That is from the example send to the bug report.
Some more variables

 = some value
 = another value
 = 343434
 = 42
 = 2.4e-7

More running text to make sure we have a decent content.

 = more variables
 = have no idea what it should be
 = 100

End of the document
**

and it converted fine using
ebook-convert bla.txt bla.epub
and the generated epub shows fine.

Best

Norbert

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

Bug#966249: appstream-generator FTBFS with gdc: error: undefined identifier ‘JSONType’

[Matthias Klumpp]

severity 966249 whishlist
thankyou

Am Sa., 25. Juli 2020 um 15:30 Uhr schrieb Adrian Bunk :
>
> Source: appstream-generator
> Version: 0.8.2-2
> Severity: important
> Tags: ftbfs
>
> https://buildd.debian.org/status/package.php?p=appstream-generator
>
> ...
> ../src/asgen/config.d:443:61: error: undefined identifier ‘JSONType’
>   443 | suite.isImmutable = sn["immutable"].type == 
> JSONType.true_;
>   | ^
> ...

That's actually an issue with GDC, it only supports a really old
standard library version currently (will be resolved with GDC 11,
apparently), and supporting multiple standard library versions is a
massive pain. I lowered the issue priority to wishlist, since GDC has
never built this package successfully on the platforms where it is
default so far - maybe GCC 11 will resolve this for good :-)

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#966315: RFP: age -- simple, modern and secure encryption tool with small explicit keys, no config options, and UNIX-style composability

[Johan Fleury]

retitle 966315 ITP: age -- simple, modern and secure encryption tool
thanks

I started working on this package and I put my changes on salsa[1].

I could use some help/review from the Golang team to solve these 3 errors 
reported by Lintian:

* E: age: statically-linked-binary usr/bin/age-keygen
* W: age: hardening-no-pie usr/bin/age
* W: age: hardening-no-relro usr/bin/age

I fixed this by overriding `dh_auto_build` in `d/rules`, but I’m not sure if 
that’s the correct way to do it:

```
override_dh_auto_build:
dh_auto_build -O--builddirectory=_build -O--buildsystem=golang -- 
-buildmode=pie
```

[1] https://salsa.debian.org/Arcaik/age

--
Johan Fleury

signature.asc
Description: OpenPGP digital signature

Bug#955329: linux-image-4.9.0-12-amd64 breaks LUKS root

[David Christensen]

On 2020-03-30 02:58, deloptes wrote:

David Christensen wrote:



https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955329


I updated/ upgraded the system today and whatever broke LUKS when I 
'apt-get dist-upgrade' and installed kernel 4.9.0-12-amd64 several 
months ago now breaks LUKS when I try to boot the kernel that I have 
been using prior and since -- 4.9.0-11-amd64.  Fortunately, LUKS still 
works with my oldest available kernel, 4.9.0-9-amd64.




lsinitramfs will give you the content of the initrd


I was unable to understand your other suggestions, but tried to use this 
one:


2020-07-26 16:35:36 root@po ~
# lsinitramfs -l /boot/initrd.img-4.9.0-9-amd64 > 
lsinitramfs-l-initrd.img-4.9.0-9-amd64.out


2020-07-26 16:35:57 root@po ~
# lsinitramfs -l /boot/initrd.img-4.9.0-11-amd64 > 
lsinitramfs-l-initrd.img-4.9.0-11-amd64.out



The listings are very large:

2020-07-26 16:40:08 root@po ~
# wc lsinitramfs-l-initrd.img-4.9.0-*
  1243  11247 128364 lsinitramfs-l-initrd.img-4.9.0-11-amd64.out
  1243  11247 127485 lsinitramfs-l-initrd.img-4.9.0-9-amd64.out
  2486  22494 255849 total


And there are a lot of changes:

2020-07-26 16:40:50 root@po ~
# diff lsinitramfs-l-initrd.img-4.9.0-9-amd64.out 
lsinitramfs-l-initrd.img-4.9.0-11-amd64.out | grep '>' | wc

9779878  112569

2020-07-26 16:40:52 root@po ~
# diff lsinitramfs-l-initrd.img-4.9.0-9-amd64.out 
lsinitramfs-l-initrd.img-4.9.0-11-amd64.out | grep '>' | head

> drwxr-xr-x  10 root root0 Jul 26 15:46 .
> drwxr-xr-x   3 root root0 Jul 26 15:46 conf
> drwxr-xr-x   2 root root0 Jul 26 15:46 conf/conf.d
> -rw-r--r--   1 root root   76 Jul 26 15:46 
conf/conf.d/cryptroot

> -rw-r--r--   1 root root   16 Jul 26 15:46 conf/arch.conf
> drwxr-xr-x   2 root root0 Jul 26 15:46 sbin
< lrwxrwxrwx   1 root root   12 Jan  9  2020 sbin/mount.ntfs 
-> /bin/ntfs-3g
> lrwxrwxrwx   1 root root   12 Jul 26 15:46 
sbin/mount.ntfs -> /bin/ntfs-3g
< lrwxrwxrwx   1 root root   12 Jan  9  2020 
sbin/mount.ntfs-3g -> /bin/ntfs-3g
> lrwxrwxrwx   1 root root   12 Jul 26 15:46 
sbin/mount.ntfs-3g -> /bin/ntfs-3g



I doubt I can find the needle(s) in that haystack.


Any other suggestions?


David

Bug#955329: Acknowledgement (linux-image-4.9.0-12-amd64: cryptsetup (sda3_crypt) : unknown fstype, bad password or options)

[David Christensen]

On 2020-03-29 17:15, Debian Bug Tracking System wrote:


If you wish to submit further information on this problem, please
send it to 955...@bugs.debian.org.



I have been running kernel 4.9.0-11-amd64 prior to and since filing the 
subject bug report.



I have updated/ upgraded my system via 'apt-get update' and 'apt-get 
upgrade' since filing the bug, and avoiding 'apt-get dist-upgrade'.



When I updated/ upgraded today and rebooted, the problem appeared again. 
 Console session follows.



So, whatever broke LUKS with kernel 4.9.0-12-amd64 has reverted even 
deeper and now breaks LUKS with kernel 4.9.0-11-amd64.



The work-around is to boot the only earlier kernel I have available, 
4.9.0-9-amd64.



When whatever broke 4.9.0-12-amd64 and now 4.9.0-11-amd64 breaks 
4.9.0-9-amd64, my system will be useless.



David



2020-07-26 15:44:55 root@po ~
# time apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
	The following package was automatically installed and is no longer 
required:

  libmicrodns0
Use 'apt autoremove' to remove it.
The following packages have been kept back:
  linux-image-amd64
The following packages will be upgraded:
	  base-files cups cups-bsd cups-client cups-common cups-core-drivers 
cups-daemon cups-ppdc cups-server-common dbus dbus-user-session dbus-x11 
e2fslibs e2fsprogs firefox-esr
	  gir1.2-rsvg-2.0 glib-networking glib-networking-common 
glib-networking-services imagemagick imagemagick-6-common 
imagemagick-6.q16 libcomerr2 libcups2 libcupscgi1 libcupsimage2
	  libcupsmime1 libcupsppdc1 libdbus-1-3 libexif12 libgnutls30 
libmagickcore-6.q16-3 libmagickcore-6.q16-3-extra libmagickwand-6.q16-3 
libmariadbclient18 libneon27-gnutls libopenjp2-7
	  libperl5.24 libpoppler-glib8 libpoppler64 libpython3.5 
libpython3.5-minimal libpython3.5-stdlib librsvg2-2 librsvg2-common 
libservlet3.1-java libss2 perl perl-base perl-doc
	  perl-modules-5.24 poppler-utils python3.5 python3.5-minimal tzdata 
wpasupplicant xdg-utils

57 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 83.4 MB of archives.
After this operation, 438 kB disk space will be freed.
Do you want to continue? [Y/n] y
	Get:1 http://security.debian.org/debian-security stretch/updates/main 
amd64 e2fslibs amd64 1.43.4-2+deb9u2 [208 kB]
	Get:2 http://ftp.us.debian.org/debian stretch/main amd64 base-files 
amd64 9.9+deb9u13 [67.6 kB]
	Get:3 http://security.debian.org/debian-security stretch/updates/main 
amd64 e2fsprogs amd64 1.43.4-2+deb9u2 [948 kB]
	Get:4 http://ftp.us.debian.org/debian stretch/main amd64 libperl5.24 
amd64 5.24.1-3+deb9u7 [3527 kB]
	Get:5 http://security.debian.org/debian-security stretch/updates/main 
amd64 libpoppler-glib8 amd64 0.48.0-2+deb9u3 [123 kB]
	Get:6 http://security.debian.org/debian-security stretch/updates/main 
amd64 libopenjp2-7 amd64 2.1.2-1.1+deb9u5 [123 kB]
	Get:7 http://security.debian.org/debian-security stretch/updates/main 
amd64 poppler-utils amd64 0.48.0-2+deb9u3 [154 kB]
	Get:8 http://security.debian.org/debian-security stretch/updates/main 
amd64 libpoppler64 amd64 0.48.0-2+deb9u3 [1286 kB]
	Get:9 http://security.debian.org/debian-security stretch/updates/main 
amd64 libpython3.5 amd64 3.5.3-1+deb9u2 [1371 kB]
	Get:10 http://security.debian.org/debian-security stretch/updates/main 
amd64 python3.5 amd64 3.5.3-1+deb9u2 [230 kB]
	Get:11 http://security.debian.org/debian-security stretch/updates/main 
amd64 libpython3.5-stdlib amd64 3.5.3-1+deb9u2 [2169 kB]
	Get:12 http://security.debian.org/debian-security stretch/updates/main 
amd64 python3.5-minimal amd64 3.5.3-1+deb9u2 [1695 kB]
	Get:13 http://security.debian.org/debian-security stretch/updates/main 
amd64 libpython3.5-minimal amd64 3.5.3-1+deb9u2 [575 kB]
	Get:14 http://security.debian.org/debian-security stretch/updates/main 
amd64 libcomerr2 amd64 1.43.4-2+deb9u2 [63.8 kB]
	Get:15 http://security.debian.org/debian-security stretch/updates/main 
amd64 libss2 amd64 1.43.4-2+deb9u2 [68.0 kB]
	Get:16 http://security.debian.org/debian-security stretch/updates/main 
amd64 librsvg2-common amd64 2.40.21-0+deb9u1 [16.6 kB]
	Get:17 http://security.debian.org/debian-security stretch/updates/main 
amd64 librsvg2-2 amd64 2.40.21-0+deb9u1 [108 kB]
	Get:18 http://security.debian.org/debian-security stretch/updates/main 
amd64 gir1.2-rsvg-2.0 amd64 2.40.21-0+deb9u1 [15.3 kB]
	Get:19 http://security.debian.org/debian-security stretch/updates/main 
amd64 libservlet3.1-java all 8.5.54-0+deb9u3 [404 kB]
	Get:20 http://ftp.us.debian.org/debian stretch/main amd64 perl amd64 
5.24.1-3+deb9u7 [218 kB]
	Get:21 http://ftp.us.debian.org/debian stretch/main amd64 perl-base 
amd64 5.24.1-3+deb9u7 [1346 kB]
	Get:22 http://ftp.us.debian.org/debian stretch/main amd64 
perl-modules-5.24 all 5.24.1-3+deb9u7 [2723 kB]
	Get:23 

Bug#930736: solstices and equinoxes are wrongly reported in the Russian calendar

[sergio]

"Поворот к зиме" is not a name.

Small calendar fix, that doesn't affect this bug.

-- 
sergio.
diff -Naur bsdmainutils/usr.bin/calendar/calendars/ru_RU.KOI8-R/calendar.pagan bsdmainutils-minor-fix/usr.bin/calendar/calendars/ru_RU.KOI8-R/calendar.pagan
--- bsdmainutils/usr.bin/calendar/calendars/ru_RU.KOI8-R/calendar.pagan	2018-01-30 13:07:30.0 +0300
+++ bsdmainutils-minor-fix/usr.bin/calendar/calendars/ru_RU.KOI8-R/calendar.pagan	2020-07-27 01:35:59.344754522 +0300
@@ -33,7 +33,7 @@
 21 Á×Ç.	äÅÎØ óÔÒÉÂÏÇÁ
 28 Á×Ç.	õÓÐÅÎÉÅ úÌÁÔÏÇÏÒËÉ
 14 ÓÅÎÔ.	äÅÎØ ÷ÏÌÈÁ úÍÅÅ×ÉÞÁ
-22 ÓÅÎÔ.*	ðÏ×ÏÒÏÔ Ë ÚÉÍÅ (ÏÓÅÎÎÅÅ ÒÁ×ÎÏÄÅÎÓÔ×ÉÅ)
+22 ÓÅÎÔ.*	ïÓÅÎÎÅÅ ÒÁ×ÎÏÄÅÎÓÔ×ÉÅ
 10 ÎÏÑÂ.	äÅÎØ íÁËÏÛÉ
 21 ÎÏÑÂ.	äÅÎØ ó×ÁÒÏÇÁ É óÅÍÁÒÇÌÁ
  9 ÄÅË.	äÅÎØ äÁÖØÂÏÇÁ É íÁÒÅÎÙ
diff -Naur bsdmainutils/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.pagan bsdmainutils-minor-fix/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.pagan
--- bsdmainutils/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.pagan	2020-07-23 15:53:53.0 +0300
+++ bsdmainutils-minor-fix/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.pagan	2020-07-27 01:34:34.593052438 +0300
@@ -33,7 +33,7 @@
 21 авг.	День Стрибога
 28 авг.	Успение Златогорки
 14 сент.	День Волха Змеевича
-22 сент.*	Поворот к зиме (осеннее равноденствие)
+22 сент.*	Осеннее равноденствие
 10 нояб.	День Макоши
 21 нояб.	День Сварога и Семаргла
  9 дек.	День Дажьбога и Марены

Bug#930736: solstices and equinoxes are wrongly reported in the Russian calendar

[sergio]

On 23/07/2020 20:24, Michael Meskes wrote:

> So you are saying the caledar file is not correct, right?

Nope, calendar file is correct!


1.

faketime '20 Jun 2019' calendar
says that Winter Solstice was Jun 21 (see my translation)

2.
% grep 'Зимнее солнцестояние'
bsdmainutils/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.pagan

21 дек.*Зимнее солнцестояние

Зимнее солнцестояние -> Winter Solstice
дек -> Dec


% faketime '20 Jun 2020' calendar | grep 'Зимнее солнцестояние'
Jun 21* Зимнее солнцестояние



-- 
sergio.

Bug#965135: git-annex: segfault when uploading (causing data-loss) to s3)

[kpcyrd]

I've tried working around this by automatically restarting the command on
crash, this has caused data-loss for me. `git annex list` showed the
file to be available in `here` only, but after running `git annex
fsck` on it git-annex noticed the local file is not available anymore
and updating the index to "available in 0 remotes". It seems

git annex move

Is currently not safe to use.

Bug#966220: ITP: golang-github-evilsocket-islazy -- Set of opinionated packages, objects, helpers and functions

[Francisco Vilmar Cardoso Ruviaro]

Hi,

I chose GP-3 as the safest approach, but I asked the upstream if we could use
GPL-3+.

https://github.com/evilsocket/islazy/issues/11

Regards,
-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00

Bug#966288: [Pkg-puppet-devel] Bug#966288: mcollective - RM for bullseye?

[Gabriel Filion]

Hi Chris,

On 2020-07-25 7:40 p.m., Chris Hofstaedtler wrote:
> Source: mcollective
> 
> Dear mcollective Maintainers,
> 
> thanks for maintaining mcollective in Debian in the past.
> 
> As you are probably aware, upstream seems to have lost interest in
> this codebase (and "replaced" it by bolt). Now, should mcollective
> stay in Debian then?

oh I personally didn't know as much, thanks for this information. (some
others on the packaging mailing list might have known.. but in any case
it's a good information point for your question, so it's quite relevant)

> Maybe it should stay as long as Puppet 5.5 is shipped, and then go
> away for 6.x?

We've recently started looking into packaging puppetserver 6.x and we're
aiming to get it in testing before bullseye is frozen. hopefully we'll
be able to manage this.

also, bolt is currently not packaged in debian, so we'll have to work on
that, too.

So in that case, we could probably remove mcollective from debian once
puppetserver and bolt are in testing.

Cheers!



signature.asc
Description: OpenPGP digital signature

Bug#923489: editline: New version available (1.16.0)

[Bastian Germann]

On Thu, 28 Feb 2019 22:25:02 +0100 Andreas Rottmann 
wrote:
> There is a new release (1.16.0) available from github. It seems there
> is no release tarball for that version, looking at
> . The latest release tarball appears
> to be editline-1.15.3.tar.xz, which is still significantly newer than
> the version in Debian.

Actually, the troglobit editline version is not the upstream for this
Debian package. It rather includes the Debian changes.

Andreas's request is actually a request to change the upstream to
troglobit's version.

Alternatively, the editline could be removed in favour of libedit. There
are only two users left: mathomatic (see #966331) and ftp-ssl.

Bug#966334: ast_json_vpack: Error building JSON ... Invalid UTF-8 string.

[Bernhard Schmidt]

Source: asterisk
Version: 1:16.2.1~dfsg-1
Severity: normal
Tags: upstream

With chan_pjsip and sorcery (Realtime configuration) the following error is
logged after hangup.

  == Spawn extension (from-lrz-pin, h, 1) exited non-zero on 
'PJSIP/7885-Y2-0034'
[2020-07-27 00:20:44] ERROR[1540]: json.c:607 ast_json_vpack: Error building 
JSON from '{s: s, s: s, s: s, s: s, s: i, s: s}': Invalid UTF-8 string.
[2020-07-27 00:20:44] ERROR[1540]:   Got 12 backtrace records
# 0: /usr/sbin/asterisk(ast_json_pack+0x99) [0x55ed0543c449]
# 1: /usr/sbin/asterisk(__ast_test_suite_event_notify+0x1be) [0x55ed054cdc0e]
# 2: /usr/sbin/asterisk(__ao2_ref+0xa6) [0x55ed053b2396]
# 3: /usr/sbin/asterisk(__ao2_ref+0xa6) [0x55ed053b2396]
# 4: /usr/lib/asterisk/modules/chan_pjsip.so(+0xb05f) [0x7f51f000c05f]
# 5: /usr/sbin/asterisk(ast_taskprocessor_execute+0xd8) [0x55ed054c4f58]
# 6: /usr/sbin/asterisk(+0x182220) [0x55ed054cf220]
# 7: /usr/sbin/asterisk(ast_taskprocessor_execute+0xd8) [0x55ed054c4f58]
# 8: /usr/sbin/asterisk(+0x181a04) [0x55ed054cea04]
# 9: /usr/sbin/asterisk(+0x18849f) [0x55ed054d549f]
#10: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3) [0x7f52131f2fa3]
#11: /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f5212f4d4cf]

This has been reported and fixed upstream

https://issues.asterisk.org/jira/browse/ASTERISK-28445

Bug#966335: mako-notifier: should provide virtual package notification-daemon

[Jonas Smedegaard]

Package: mako-notifier
Version: 1.4.1-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

At its homepage, it is described that mako-notifier
"implements the GNOME Desktop Notifications Specification."

That seems to me to be exactly what is represented in Debian
by the virtual package notification-daemon.

If correctly understood, then please have mako-notifier declare that it
"Provides: notification-daemon"

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl8eBR0ACgkQLHwxRsGg
ASG5XA/9GYxWeRQZhjMJCU5Ow8PiMyeKb3ZlAfQ7Xd1ZzCumeAgi/t00+IoFPZEK
J/QqcCap+1OuEnMiX8hWeVyat1Nws/XqdtSTgx9tqcjP/N4nsAo8cEoaJ/+k/vbX
5bNI98wm+PkGF0/qIesQgtMeiR3cqpPTMVnTDv5fXgSPYyZOvM0DkT3Gaj838Rjf
4kjuFOkuNa4rLI8gK3JTGBL0okzo257Q93SzG8CCbNvO2HTxiHZVK7c6pk5TDKLL
qKihW6tQZUFKwCvLlbqwED96vy/h5Wtjk4fuQPp4dhfsdci+ockAV8og+7/YDRm7
yJIW7+KwK42y/i+UCquLq32tYGry4dfu4vrE8BHicw6EoAiY5BNlwNJ2l+Ruywqb
9k7g2pq1A7EiFjA03LYXOhDY0XAPrIKHV+JDVp1zTPwQfWp5MbnH+NXABALUaYEg
464Mt2fJG2rqJNAuyBYowEg+oF7/MSWeI8d6FGsJEbpAA5dJKmubuk7eYW2mYqvK
vAAtYMPIoiv0kydwK52PzaaXVwLhxae0CfTubgJe4XjZ6mfgODXpSiXUcg1qviRG
8yxqFBJN0ufU299BW/SDbpKt1GrOxKEsI3FygbSV/PycY2OG8NqE+VnaQuBO+VWv
EPcWxAdB3u+Sct9RZMcm6Q21NJVUy/usmfpGDP22Sm42fzDaO90=
=rekx
-END PGP SIGNATURE-

Bug#965353: [Pkg-javascript-devel] Bug#965353: Bug#965353: Bug#965353: Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined

[Jonas Smedegaard]

Quoting Pirate Praveen (2020-07-26 21:07:19)
> Control: reopen -1
> 
> On Mon, Jul 27, 2020 at 00:32, Pirate Praveen 
>  wrote:
> > This did not fix the issue :( So we have to reopen this bug once the 
> > upload reaches the archive (which will close this bug as fixed).
> 
> Thanks to the brave new world of embedding eveything and reducing the 
> number of js packages. Complicated build systems in favor of reducing 
> the metadata size, ftw!

Only the package uploader can be blamed for embedding _everything_!

 - Jonas

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

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

signature.asc
Description: signature

Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2

[Markus Koschany]

Hello Andreas,

On Tue, 14 Jul 2020 13:57:48 +0200 Andreas Schulz
 wrote:
> Package: squid
> Version: 3.5.23-5+deb9u2.1
> Severity: important
> File: /usr/sbin/squid
> 
> Dear Maintainer,
> 
> We installed the security update deb9u2 and learned that no more
> http-access (with icap) was possible.


I am not the maintainer but I have prepared the security update for
squid3 in Stretch. So far you are the only one who reported this
problem. I had sent a request for testing but never received any
feedback. [1] Please note that Stretch is now supported by the LTS team.
We have a dedicated mailing list where you can report problems dedicated
to packages in Stretch called debian-...@lists.debian.org.

Could you set debug_options to ALL,9 (which should enable full debugging
according to the squid wiki) and reproduce the issue again? Please
attach the complete log either to this bug report or send it to me via
private email directly.

The patch for CVE-2019-12523 contains only one line that appears to
touch icap related code in src/adaptation/icap/ModXact.cc. I have
reverted this change and attached a new CVE-2019-12523.patch. Could you
apply it and report back if it makes any difference? Otherwise only the
debug log could help to narrow down the problem.

Regards,

Markus



[1] https://lists.debian.org/debian-lts/2020/07/msg00018.html
From: Markus Koschany 
Date: Tue, 30 Jun 2020 22:11:00 +0200
Subject: CVE-2019-12523

Origin: http://www.squid-cache.org/Versions/v4/changesets/squid-4-fbbdf75efd7a5cc244b4886a9d42ea458c5a3a73.patch
---
 src/HttpRequest.cc|  12 +--
 src/HttpRequest.h |   4 +-
 src/URL.h |   4 +-
 src/acl/Asn.cc|   2 +-
 src/adaptation/ecap/MessageRep.cc |   4 +-
 src/client_side.cc|   2 +-
 src/client_side_request.cc|   4 +-
 src/htcp.cc   |   2 +-
 src/icmp/net_db.cc|   2 +-
 src/icp_v2.cc |   2 +-
 src/mgr/Inquirer.cc   |   2 +-
 src/mime.cc   |   2 +-
 src/neighbors.cc  |   2 +-
 src/peer_digest.cc|   2 +-
 src/servers/FtpServer.cc  |   6 +-
 src/store_digest.cc   |   2 +-
 src/tests/testHttpRequest.cc  |  31 ++
 src/url.cc| 199 ++
 src/urn.cc|   2 +-
 src/urn.h |   2 +
 20 files changed, 192 insertions(+), 96 deletions(-)

diff --git a/src/HttpRequest.cc b/src/HttpRequest.cc
index a2c7afd..8b7ab99 100644
--- a/src/HttpRequest.cc
+++ b/src/HttpRequest.cc
@@ -320,13 +320,7 @@ HttpRequest::parseFirstLine(const char *start, const char *end)
 if (end < start)   // missing URI
 return false;
 
-char save = *end;
-
-* (char *) end = '\0'; // temp terminate URI, XXX dangerous?
-
-HttpRequest *tmp = urlParse(method, (char *) start, this);
-
-* (char *) end = save;
+HttpRequest *tmp = urlParse(method, SBuf(start, size_t(end-start)), this);
 
 if (NULL == tmp)
 return false;
@@ -540,7 +534,7 @@ HttpRequest::expectingBody(const HttpRequestMethod& unused, int64_t& theSize) co
  * If the request cannot be created cleanly, NULL is returned
  */
 HttpRequest *
-HttpRequest::CreateFromUrlAndMethod(char * url, const HttpRequestMethod& method)
+HttpRequest::CreateFromUrlAndMethod(const SBuf & url, const HttpRequestMethod& method)
 {
 return urlParse(method, url, NULL);
 }
@@ -551,7 +545,7 @@ HttpRequest::CreateFromUrlAndMethod(char * url, const HttpRequestMethod& method)
  * If the request cannot be created cleanly, NULL is returned
  */
 HttpRequest *
-HttpRequest::CreateFromUrl(char * url)
+HttpRequest::CreateFromUrl(const SBuf & url)
 {
 return urlParse(Http::METHOD_GET, url, NULL);
 }
diff --git a/src/HttpRequest.h b/src/HttpRequest.h
index cfb5a46..47f3593 100644
--- a/src/HttpRequest.h
+++ b/src/HttpRequest.h
@@ -224,9 +224,9 @@ public:
 
 static void httpRequestPack(void *obj, Packer *p);
 
-static HttpRequest * CreateFromUrlAndMethod(char * url, const HttpRequestMethod& method);
+static HttpRequest * CreateFromUrlAndMethod(const SBuf & url, const HttpRequestMethod& method);
 
-static HttpRequest * CreateFromUrl(char * url);
+static HttpRequest * CreateFromUrl(const SBuf & url);
 
 ConnStateData *pinnedConnection();
 
diff --git a/src/URL.h b/src/URL.h
index 0b75bc6..5857272 100644
--- a/src/URL.h
+++ b/src/URL.h
@@ -62,9 +62,9 @@ MEMPROXY_CLASS_INLINE(URL);
 class HttpRequest;
 class HttpRequestMethod;
 
-AnyP::ProtocolType urlParseProtocol(const char *, const char *e = NULL);
+AnyP::ProtocolType urlParseProtocol(const SBuf &);
 void urlInitialize(void);
-HttpRequest *urlParse(const HttpRequestMethod&, char *, HttpRequest *request = NULL);
+HttpRequest *urlParse(const HttpRequestMethod&, const SBuf & rawRequest, HttpRequest *request = NULL);
 const char 

Bug#966173: libc6: __atan2_finite reference in dlopened module no longer found in executable linked to libm

[Aurelien Jarno]

On 2020-07-24 15:23, Simon McVittie wrote:
> On Fri, 24 Jul 2020 at 14:36:54 +0200, Bastian Blank wrote:
> > On Fri, Jul 24, 2020 at 10:11:04AM +0100, Simon McVittie wrote:
> > > The bug (#966150) is that a version of uix86_64.so compiled with a 
> > > slightly
> > > older (2020-02-18) toolchain fails to load on an up-to-date sid system, 
> > > with:
> > > undefined symbol: __atan2_finite
> > 
> > Because the binary was not linked with -lm, the linker never saw the
> > real symbol __atan2_finite@GLIBC2_16, so the linke only emitted a reference
> > to __atan2_finite.
> 
> Right. However, note that there's no mention of __atan2_finite() in the
> source code - it's only used because older glibc would replace atan2()
> with a reference to __atan2_finite() when building with -ffast-math.

I do not see what does it change. atan2 also need to be linked with
-libm. If it is not, issues like the one you encountered might happen.
The change from atan2 to __atan2_finite when -ffast-math is in used is
purely done in the preprocessor.

> > At least dpkg-shlibdeps or so should warn about that.
> 
> For at least openarena, it doesn't seem to. I'm not sure why not.
> 
> For the next update to openarena I'm going to build it with -Wl,-z,defs
> so that missing dependencies are always fatal. However, that isn't
> always applicable: some plugin architectures (like Python extensions)
> rely on being able to pick up symbols exported by the executable, which
> are not necessarily programmatically distinguishable from symbols that
> are defined by libraries used by the executable.

This is indeed an issue, under-linking is sometimes difficult to find.
Given we now the list of affected symbols, I'll try to check if other
binaries are affected so that they can be fixed even if no users report
an issue.

> > > I've been trying to put together a standalone reproducer that only uses
> > > libdl and libm, but so far I have not been successful.
> > 
> > Something like that?
> > 
> > | % cat test.c
> > | void __atan2_finite(void);
> > | void test(void) {
> > |   __atan2_finite();
> > | }
> 
> I was aiming for something a bit closer to openarena's situation,
> where there is no explicit reference to __atan2_finite() in the source
> code: it calls atan2(), and cc -ffast-math rewrites that into a call
> to __atan2_finite(). I've now managed to make this work: see attached.
> 
> Compile them and run ./prog in a buster environment (or an outdated
> bullseye/sid environment with glibc < 2.31), then run ./prog in an
> up-to-date bullseye/sid environment without recompiling.
> 
> libmymodule.so will get a dynamic reference to __atan2_finite.
> 
> The historical result is that prog outputs 0.463648, twice.
> 
> The result in up-to-date bullseye/sid is that prog outputs 0.463648,
> once, and then fails with "undefined symbol: __atan2_finite".
> 
> Using __FINITE_MATH_ONLY__ (which is defined by -ffast-math) is necessary
> to be able to reproduce the bug this way.
> 
> If you consider this sort of thing to be too niche to be supportable,
> please feel free to close the bug.

I do consider it a bug on the openarena side, as it's basically using a
non-versioned symbol due to under-linking. However from the user point
of view, we should prevent that to happen, so I'll add the corresponding
Breaks: entry on the glibc side to ensure a flawless upgrade for the
users.

Aurelien

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

Bug#965353: [Pkg-javascript-devel] Bug#965353: Bug#965353: Bug#965353: Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined

[Pirate Praveen]

On 2020, ജൂലൈ 27 1:42:32 AM IST, Nicolas Mora  wrote:
>I'm not sure yet if this would fix the bug but in all the build log
>errors, I see that the file /usr/share/nodejs/lodash/_baseOrderBy.js is
>always the source of the error.
>
>The file _baseOrderBy.js in the package seems buggy for an unresolved reson.
>
>File in node-lodash unstable package:
>4.17.19+dfsg-1 _baseOrderBy.js https://paste.debian.net/1157886/
>
>File in node-lodash bullseye package
>4.17.15+dfsg-2 _baseOrderBy.js https://paste.debian.net/1157887/
>
>In the unstable version, the call to isArray line 24 is the root of errors.

This is possibly introduced by the security fix, but I can't be sure. Hope 
someone else can clarify.

>Also, I see that the upstream version 4.17.19 isn't tagged as latest
>release, 4.17.16 is, maybe it's worth a try to package 4.17.16 instead?
>
>https://github.com/lodash/lodash/releases

4.17.19 is correct as per 
https://github.com/lodash/lodash/issues/4837#issuecomment-655648024
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#966333: reprotest: Tests not run during build and fail with python 3.8

[Vagrant Cascadian]

Package: reprotest
Severity: normal
Version: 0.7.8

The test suite parts called by "tox" are not run, as it tries to use
python 3.6, which was not present since before buster release:

   debian/rules override_dh_auto_test
   make[1]: Entering directory '/<>'
   VIRTUALENV_DOWNLOAD=no \
   http_proxy=http://127.0.9.1:9 \
   https_proxy=https://127.0.9.1:9 \
   TOX_TESTENV_PASSENV=PYTHONIOENCODING PYTHONIOENCODING=utf-8 \
   tox -r --sitepackages -- -s
   GLOB sdist-make: /<>/setup.py
   WARNING: could not copy distfile to
   /sbuild-nonexistent/.tox/distshare
   py36 create: /<>/.tox/py36
   SKIPPED: InterpreterNotFound: python3.6
   ___ summary
   
   SKIPPED:  py36: InterpreterNotFound: python3.6
 congratulations :)

The congratulations seem a bit premature. :)

I updated the configuration to run using python 3.8, but many
non-deterministic test suite failures ensued, so reverted before the
last upload.


diff --git a/tox.ini b/tox.ini
index 06da613..d162757 100644
--- a/tox.ini
+++ b/tox.ini
@@ -1,6 +1,6 @@
 [tox]
 # envlist = coverage-clean, py35, coverage-stats
-envlist = py36
+envlist = py38
 skip_missing_interpreters = true

 [testenv:coverage-clean]

We should probably get the test suite running and passing again. :)

We might also want to disable skip_missing_interpreters, to avoid this
happening again without noticing...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#962307: Acknowledgement (RFS: anymeal/1.0-1 ITA -- Cookbook database for storing recipes)

[Jan Wedekind]

Hi,
I have now released version 1.5. It is available here:

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

Also it can be downloaded as follows:

dget -x 
https://mentors.debian.net/debian/pool/main/a/anymeal/anymeal_1.5-1.dsc

Best regards
Jan

Bug#964438: apt-listbugs: dns error when running from cron job

[Michael Biebl]

Am 26.07.20 um 23:12 schrieb Francesco Poli:
> On Sun, 26 Jul 2020 22:48:18 +0200 Michael Biebl wrote:
> 
>> Am 26.07.20 um 22:43 schrieb Francesco Poli:
>>> On Sun, 26 Jul 2020 22:22:55 +0200 Michael Biebl wrote:
>>>
>>> [...]
 Afaics, the problem is, that your service does not properly handle the
 case, when the network is not available.
>>>
>>> It does, that's the reason why the operation is attempted hourly.
>>
>> The bug report was about apt-listbugs throwing an error if network is
>> not available.
> 
> We can argue that the service should be more silent in case of network
> errors, or maybe it's OK that it throws an error.
> But that's not the point.
> 
> The point is that the timer triggers during wake-up, while it should

Not entirely correct. The timer only triggers if the time specified in
the timer unit has elapsed while the system was asleep.

> behave as it does during a boot (wait for at least 5 min and then
> trigger hourly, with a random delay).

Again, this is a misunderstanding how OnActiveSec= works.
And even then, a 5min delay would not guarantee that network is up.



signature.asc
Description: OpenPGP digital signature

Bug#964438: apt-listbugs: dns error when running from cron job

[Michael Biebl]

Am 26.07.20 um 23:12 schrieb Francesco Poli:
> On Sun, 26 Jul 2020 22:48:18 +0200 Michael Biebl wrote:
> 
>> Am 26.07.20 um 22:43 schrieb Francesco Poli:
>>> On Sun, 26 Jul 2020 22:22:55 +0200 Michael Biebl wrote:
>>>
>>> [...]
 Afaics, the problem is, that your service does not properly handle the
 case, when the network is not available.
>>>
>>> It does, that's the reason why the operation is attempted hourly.
>>
>> The bug report was about apt-listbugs throwing an error if network is
>> not available.
> 
> We can argue that the service should be more silent in case of network
> errors, or maybe it's OK that it throws an error.
> But that's not the point.
> 
> The point is that the timer triggers during wake-up, while it should
> behave as it does during a boot (wait for at least 5 min and then
> trigger hourly, with a random delay).
> 
>>
 Even if systemd would delay timer events after a resume: How long should
 it wait? 30s, 1min? How would that robustly solve your problem? How
 would that guarantee that after 1min network is available?
>>>
>>> It should wait at least 5 min (as specified in OnActiveSec=5min),
>>
>> That is not what OnActiveSec=5min means
> 
> Then I think the systemd.timer(5) man page should be clarified.
> It states:
> 
>│OnActiveSec=   │ Defines a timer relative   │
>│   │ to the moment the timer│
>│   │ unit itself is activated.  │
> 
> I thought this meant that an OnActiveSec=5min timer triggers 5 min
> after being activated.
> And the timer is either inactive during sleep (then it's activated
> again during wake-up and it should wait 5 min before triggering) or
> considered as active during sleep (but then the OnActiveSec should have
> already happened 5 min after boot and should not happen again during
> wake-up).

The timer is activated during boot and then stays active (unless you
stop it with systemctl stop foo.timer).
You can query the state with systemctl status.
A system sleep does not deactivate a timer.




signature.asc
Description: OpenPGP digital signature

Bug#966281: snapshot.debian.org: Older source packages are reported as 403 Forbidden

[Francisco M Neto]

Thanks for the clarification. I never thought of looking for that in
the bug tracker for starfighter instead of snapshot.

I'm sending a copy of this message to 966281-d...@bugs.debian.org in
order to close the bug (assuming I'm allowed to do so).

Cheers,
Francisco

On Sat, 2020-07-25 at 22:30 +0100, Adam D. Barratt wrote:
> On Sat, 2020-07-25 at 17:49 -0300, Francisco M Neto wrote:
> > While trying to download older versions of a source package with
> > debsnap, the
> > download fails:
> [...]
> > Upon looking directly at snapshot.debian.org, trying to manually
> > download older versions of the source (for example the files under
> > https://snapshot.debian.org/package/starfighter/1.1-5/) I get a 403
> > Forbidden HTTP response.
> 
> That seems appropriate, given 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546800 , as
> referenced in https://snapshot.debian.org/removal/ (which is in turn
> linked from the front page of snapshot.debian.org).
> 
> Regards,
> 
> Adam
> 

Bug#964438: apt-listbugs: dns error when running from cron job

[Michael Biebl]

Am 26.07.20 um 23:20 schrieb Francesco Poli:
> On Sun, 26 Jul 2020 22:49:06 +0200 Michael Biebl wrote:
> 
>> Am 26.07.20 um 22:38 schrieb Francesco Poli:
>>> On Sun, 26 Jul 2020 22:06:23 +0200 Michael Biebl wrote:
> [...]
 Persistent=true is relevant when you
 reboot/power down a system. In your case, the system is suspended and
 woken up again.
>>>
>>> Exactly!
>>> So why does it trigger *immediately* during wake-up?
>>>
>>
>> Because the timer elapsed.
> 
> When?
> During sleep?

Correct


> So it catches up with missed execution chances, doesn't it?

Correct

> If this is confirmed, then maybe the bug is exactly that the Persistent
> directive does not apply to sleeping time (only to down time).

I don't consider that a bug. Persistent is only documented as affecting
a powered down system.



signature.asc
Description: OpenPGP digital signature

Bug#966332: RM: cfv -- ROM; python2-only; no external deps; no py3 support yet

[Stefan Alfredsson]

Package: ftp.debian.org
Severity: normal

The cfv package upstream is MIA; refreshed development efforts and porting
to python3 happens at https://github.com/cfv-project/cfv/commits/python3
however it is not yet mature to replace the existing package.

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936288

The intent is to re-ITP cfv again when py3 support is stable.

Cheers,
 Stefan


signature.asc
Description: Digital signature

Bug#936288: cfv: Python2 removal in sid/bullseye

[alfs]

Den 2020-07-26 kl. 13:17, skrev Moritz Mühlenhoff:

On Fri, Aug 30, 2019 at 07:13:06AM +, Matthias Klose wrote:

Package: src:cfv
Version: 1.18.3-2.1
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Hi Stefan,
given your comment at
https://github.com/cfv-project/cfv/issues/8#issuecomment-615215686, let's
proceed with removal?


Yes, I don't see any progress on the py3 port since May (and I cannot 
commit myself to implement py3 support) so I just sent the removal request.


Thanks for the reminder.

/Stefan

Bug#966331: mathomatic: Build with libedit

[Bastian Germann]

Package: mathomatic
Severity: normal

Debian's editline package is not updated in a long time. There is the
alternative package libedit which stems from the same source but is
properly maintained in Debian. This patch builds mathomatic with that
instead.
From 8cc0db797a3bf78ab12c189d339654d9ed34e6ed Mon Sep 17 00:00:00 2001
From: Bastian Germann 
Date: Sun, 26 Jul 2020 22:47:47 +0200
Subject: [PATCH] Build with libedit

---
 debian/control  |  2 +-
 debian/patches/build-with-libedit.patch | 17 +
 debian/patches/series   |  1 +
 debian/rules|  2 +-
 4 files changed, 20 insertions(+), 2 deletions(-)
 create mode 100644 debian/patches/build-with-libedit.patch

diff --git a/debian/control b/debian/control
index 1e58d78..3f0391b 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: mathomatic
 Section: math
 Priority: optional
 Maintainer: tony mancill 
-Build-Depends: debhelper-compat (= 12), libeditline-dev, rman, htmldoc, tidy
+Build-Depends: debhelper-compat (= 12), libedit-dev, rman, htmldoc, tidy
 Standards-Version: 4.4.1
 Homepage: http://www.mathomatic.org
 Vcs-Browser: https://salsa.debian.org/debian/mathomatic
diff --git a/debian/patches/build-with-libedit.patch b/debian/patches/build-with-libedit.patch
new file mode 100644
index 000..6c497d9
--- /dev/null
+++ b/debian/patches/build-with-libedit.patch
@@ -0,0 +1,17 @@
+From: Bastian Germann 
+Date: Sun, 26 Jul 2020 22:21:27 +0200
+Subject: Build with libedit
+---
+diff --git a/includes.h b/includes.h
+index 2e5667a..f9223fc 100644
+--- a/includes.h
 b/includes.h
+@@ -106,7 +106,7 @@ George Gesslein II, P.O. Box 224, Lansing, NY  14882-0224  USA.
+ #include 
+ #endif
+ #if	EDITLINE	/* Editline is a stripped down version of readline. */
+-#include 
++#include 
+ #endif
+ 
+ /* Include files from the current directory: */
diff --git a/debian/patches/series b/debian/patches/series
index a2fba86..a690f6d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
+build-with-libedit.patch
 python3.patch
diff --git a/debian/rules b/debian/rules
index 67a937b..7f0fdf4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,7 +9,7 @@ export LDFLAGS=$(shell dpkg-buildflags --get LDFLAGS)
 	dh $@
 
 override_dh_auto_build:
-	CFLAGS="$(CFLAGS) -DEDITLINE" LDLIBS="-leditline" $(MAKE)
+	CFLAGS="$(CFLAGS) -DEDITLINE" LDLIBS="-ledit" $(MAKE)
 	$(MAKE) -C primes
 	$(MAKE) pdf
 
-- 
2.28.0.rc2

Bug#966283: calibre: Literal "<>" characters in text file not converted properly

[yokota]

> Converting a text file (to epub) which included many lines like
> "
>  = 
> "
> resulted in just the character "=".
>
> As a workaround enscript will produce correct html, but the epub result
> looks fine in the calibre viewer, but produces odd underlined text on
> a nook ereader. But that is an aside, rather than the main point of this
> bug report.
>
> I attach a screen shot showing the display of the original text file and
> the calibre viewer showing the problem.


When converts from TXT format, Calibre tries to detect format type.
Your text file "/usr/share/doc/exim4-base/spec.txt.gz" seems to be
Markdown format,
so Calibre treats your text file as Markdown format.

Markdown format treats "<...>" as HTML tag. This is why "<...>"
disappears your text.

If you are familiar with Python code, check
"/usr/lib/calibre/calibre/ebooks/txt/processor.py" to view format
detection code.

If you want to disable these format detection and treat your file as
plain text file, use file converter from Calibre GUI.
Usage:
1. Push "Add books" button and import the text file to Calibre.
2. Push "Convert books" button to open converter.
3. Open "TXT input" section in converter dialog, and set "plain"
format type to disable format detection.
> Structure:
>Formatting style: plain
4. Add more options to better output.
> Structure:
>Paragraph style: off
> Common:
>Paragraph spaces: enable
5. Push "OK" button to convert your text file to ePub.

--
YOKOTA

Bug#964438: apt-listbugs: dns error when running from cron job

[Francesco Poli]

On Sun, 26 Jul 2020 22:48:18 +0200 Michael Biebl wrote:

> Am 26.07.20 um 22:43 schrieb Francesco Poli:
> > On Sun, 26 Jul 2020 22:22:55 +0200 Michael Biebl wrote:
> > 
> > [...]
> >> Afaics, the problem is, that your service does not properly handle the
> >> case, when the network is not available.
> > 
> > It does, that's the reason why the operation is attempted hourly.
> 
> The bug report was about apt-listbugs throwing an error if network is
> not available.

We can argue that the service should be more silent in case of network
errors, or maybe it's OK that it throws an error.
But that's not the point.

The point is that the timer triggers during wake-up, while it should
behave as it does during a boot (wait for at least 5 min and then
trigger hourly, with a random delay).

> 
> >> Even if systemd would delay timer events after a resume: How long should
> >> it wait? 30s, 1min? How would that robustly solve your problem? How
> >> would that guarantee that after 1min network is available?
> > 
> > It should wait at least 5 min (as specified in OnActiveSec=5min),
> 
> That is not what OnActiveSec=5min means

Then I think the systemd.timer(5) man page should be clarified.
It states:

   │OnActiveSec=   │ Defines a timer relative   │
   │   │ to the moment the timer│
   │   │ unit itself is activated.  │

I thought this meant that an OnActiveSec=5min timer triggers 5 min
after being activated.
And the timer is either inactive during sleep (then it's activated
again during wake-up and it should wait 5 min before triggering) or
considered as active during sleep (but then the OnActiveSec should have
already happened 5 min after boot and should not happen again during
wake-up).

What did I fail to understand?



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgple6cInnXVS.pgp
Description: PGP signature

Bug#964438: apt-listbugs: dns error when running from cron job

[Francesco Poli]

On Sun, 26 Jul 2020 22:49:06 +0200 Michael Biebl wrote:

> Am 26.07.20 um 22:38 schrieb Francesco Poli:
> > On Sun, 26 Jul 2020 22:06:23 +0200 Michael Biebl wrote:
[...]
> >> Persistent=true is relevant when you
> >> reboot/power down a system. In your case, the system is suspended and
> >> woken up again.
> > 
> > Exactly!
> > So why does it trigger *immediately* during wake-up?
> > 
> 
> Because the timer elapsed.

When?
During sleep?

So it catches up with missed execution chances, doesn't it?

If this is confirmed, then maybe the bug is exactly that the Persistent
directive does not apply to sleeping time (only to down time).
Or, in other words, that, after sleep, every timer is necessarily
considered as Persistent=true, even when it should be Persistent=false.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpu4JQdd3Xhe.pgp
Description: PGP signature

Bug#966027: systemd: systemctl failures during upt pgrade due to missing libcryptsetup.so.12

[Michael Biebl]

Control: severity -1 minor

Am 26.07.20 um 22:59 schrieb Michael Biebl:
> Am 25.07.20 um 20:50 schrieb Sven Strickroth:
>> Hi,
>>
>> Am 23.07.2020 um 00:30 schrieb Michael Biebl:
>>> Those error messages are from systemd-tty-ask-password-agent not systemctl.
>>> Do you actually encounter any problems or is this mostly cosmetic?
>>
>> I'm not aware of actual problems.
> 
> Ok.

Downgrading, as this appears to be a cosmetic issue



signature.asc
Description: OpenPGP digital signature

Bug#966027: systemd: systemctl failures during upt pgrade due to missing libcryptsetup.so.12

[Michael Biebl]

Am 25.07.20 um 20:50 schrieb Sven Strickroth:
> Hi,
> 
> Am 23.07.2020 um 00:30 schrieb Michael Biebl:
>> Those error messages are from systemd-tty-ask-password-agent not systemctl.
>> Do you actually encounter any problems or is this mostly cosmetic?
> 
> I'm not aware of actual problems.

Ok.

>> Why does a systemctl call trigger the start of
>> systemd-tty-ask-password-agent for you? Do you have a special way to
>> start your dist-upgrade?
>> Can you provide steps how this issue can be reproduced?
> 
> I just had a normal Debian 9.13 installation and ran "apt upgrade".
> 

That is not a sufficient reproducer. I ran multiple dist-upgrades and
never encountered this particular issue.

Not sure what I should do with this bug report, tbh.



signature.asc
Description: OpenPGP digital signature

Bug#966330: e2fsprogs: FTBFS since libblkid-dev dropped libblkid.a

[Andreas Beckmann]

Source: e2fsprogs
Version: 1.45.6-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Control: found -1 1.46~WIP.2019.10.03-1

Hi,

libblkid-dev recently dropped libblkid.a causing e2fsprogs to FTBFS:

make[2]: Entering directory '/build/e2fsprogs-1.45.6/debian/BUILD-STD/e2fsck'
gcc  -Wl,-z,relro -Wl,-z,now -static -o e2fsck.static unix.o e2fsck.o super.o 
pass1.o pass1b.o pass2.o pass3.o pass4.o pass5.o journal.o badblocks.o util.o 
dirinfo.o dx_dirinfo.o ehandler.o problem.o message.o quota.o recovery.o 
region.o revoke.o ea_refcount.o rehash.o logfile.o sigcatcher.o  readahead.o 
extents.o   ../lib/libsupport.a ../lib/libext2fs.a ../lib/libcom_err.a 
-lpthread -lblkid -luuid  -luuid   ../lib/libe2p.a -ldl
/usr/bin/ld: cannot find -lblkid
/usr/bin/ld: logfile.o: in function `expand_percent_expression':
./debian/BUILD-STD/e2fsck/../../../e2fsck/logfile.c:141: warning: Using 
'getpwuid_r' in statically linked applications requires at runtime the shared 
libraries from the glibc version used for linking
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:449: e2fsck.static] Error 1


Andreas

Bug#964438: apt-listbugs: dns error when running from cron job

[Michael Biebl]

Am 26.07.20 um 22:51 schrieb Michael Biebl:
> Am 26.07.20 um 22:38 schrieb Francesco Poli:
> 
>> This is why I think the bug is in systemd.
> 
> If you are convinced, this is an issue within systemd, then you'll need
> to take this upstream yourself as I clearly don't see the issue and can
> argue the case for you.

FAOD: I can't argue the case for you




signature.asc
Description: OpenPGP digital signature

Bug#964438: apt-listbugs: dns error when running from cron job

[Michael Biebl]

Am 26.07.20 um 22:38 schrieb Francesco Poli:

> This is why I think the bug is in systemd.

If you are convinced, this is an issue within systemd, then you'll need
to take this upstream yourself as I clearly don't see the issue and can
argue the case for you.




signature.asc
Description: OpenPGP digital signature

Bug#964438: apt-listbugs: dns error when running from cron job

[Michael Biebl]

Am 26.07.20 um 22:38 schrieb Francesco Poli:
> On Sun, 26 Jul 2020 22:06:23 +0200 Michael Biebl wrote:
> 
>> Am 26.07.20 um 21:36 schrieb Francesco Poli:
> [...]
>>> Dear Michael,
>>> I am still convinced that this is a bug in systemd, as explained above.
>>> I am reassigning back the bug report to package systemd.
>>>
>>> If you think that the timer unit can be modified so that it behaves as
>>> intended, please tell me how I should modify it.
>>> Just to recap the intended behavior: the timer should trigger the
>>> corresponding oneshot service 5 min after the timer activation and then
>>> hourly, with a random delay between 0 and 20 min, *without* catching up
>>> with missed execution chances, and it should *not* trigger the service
>>> immediately during a wake-up from sleep.
>>
>> Maybe this is a misunderstanding.
> 
> It's possible. And it may well be on my side.
> Let's try and clarify...
> 
>> Persistent=true is relevant when you
>> reboot/power down a system. In your case, the system is suspended and
>> woken up again.
> 
> Exactly!
> So why does it trigger *immediately* during wake-up?
> 

Because the timer elapsed.




signature.asc
Description: OpenPGP digital signature

Bug#964438: apt-listbugs: dns error when running from cron job

[Michael Biebl]

Am 26.07.20 um 22:38 schrieb Francesco Poli:

> Yet, the timer triggers during each wake-up, without waiting.

Wait for what?




signature.asc
Description: OpenPGP digital signature

Bug#964438: apt-listbugs: dns error when running from cron job

[Francesco Poli]

On Sun, 26 Jul 2020 22:22:55 +0200 Michael Biebl wrote:

[...]
> Afaics, the problem is, that your service does not properly handle the
> case, when the network is not available.

It does, that's the reason why the operation is attempted hourly.

> Even if systemd would delay timer events after a resume: How long should
> it wait? 30s, 1min? How would that robustly solve your problem? How
> would that guarantee that after 1min network is available?

It should wait at least 5 min (as specified in OnActiveSec=5min),
because we are almost sure that immediately during wake-up is too early.
Hence, attempting the operation during wake-up is a bad idea.
If 5 min after wake-up is still too early to have a working network,
no big deal, the service will try again hourly...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpHRlr8bo_wL.pgp
Description: PGP signature

Bug#964438: apt-listbugs: dns error when running from cron job

[Francesco Poli]

On Sun, 26 Jul 2020 22:06:23 +0200 Michael Biebl wrote:

> Am 26.07.20 um 21:36 schrieb Francesco Poli:
[...]
> > Dear Michael,
> > I am still convinced that this is a bug in systemd, as explained above.
> > I am reassigning back the bug report to package systemd.
> > 
> > If you think that the timer unit can be modified so that it behaves as
> > intended, please tell me how I should modify it.
> > Just to recap the intended behavior: the timer should trigger the
> > corresponding oneshot service 5 min after the timer activation and then
> > hourly, with a random delay between 0 and 20 min, *without* catching up
> > with missed execution chances, and it should *not* trigger the service
> > immediately during a wake-up from sleep.
> 
> Maybe this is a misunderstanding.

It's possible. And it may well be on my side.
Let's try and clarify...

> Persistent=true is relevant when you
> reboot/power down a system. In your case, the system is suspended and
> woken up again.

Exactly!
So why does it trigger *immediately* during wake-up?

Was the timer inactive during sleep and then re-activated during
wake-up?
If this is the case, then it should wait at least 5 min
(OnActiveSec=5min) or trigger on the basis of the calendar scheduling
(OnCalendar=*-*-* *:20) with a random delay (RandomizedDelaySec=20min).

Was the timer still considered active during sleep?
If this is the case, then the OnActiveSec=5min trigger should not
happen at all during wake-up and the timer should just trigger on the
basis of the calendar scheduling (OnCalendar=*-*-* *:20) with a random
delay (RandomizedDelaySec=20min).

Yet, the timer triggers during each wake-up, without waiting.
This is why I think the bug is in systemd.



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpNAZsGJf6YT.pgp
Description: PGP signature

Bug#964438: apt-listbugs: dns error when running from cron job

[Michael Biebl]

Am 26.07.20 um 22:06 schrieb Michael Biebl:

>> If you think that the timer unit can be modified so that it behaves as
>> intended, please tell me how I should modify it.
>> Just to recap the intended behavior: the timer should trigger the
>> corresponding oneshot service 5 min after the timer activation and then
>> hourly, with a random delay between 0 and 20 min, *without* catching up
>> with missed execution chances, and it should *not* trigger the service
>> immediately during a wake-up from sleep.

Afaics, the problem is, that your service does not properly handle the
case, when the network is not available.
Even if systemd would delay timer events after a resume: How long should
it wait? 30s, 1min? How would that robustly solve your problem? How
would that guarantee that after 1min network is available?






signature.asc
Description: OpenPGP digital signature

Bug#966323: [Python-modules-team] Bug#966323: python3-subvertpy: missing (unversioned) Breaks+Replaces: python-subvertpy

[Andreas Beckmann]

On 7/26/20 9:51 PM, Sandro Tosi wrote:
> hm i dont think a B+R is needed here: python3-subvertpy installs a
> binary called subvertpy3-fast-export so the manpage needs to match
> that name; it's probably a relic of the py2 drop, looking at it right
> now

You know the package better than me to quickly spot the unusual case of
something "just" being misnamed ;-)


Andreas

Bug#966315: RFP: age -- simple, modern and secure encryption tool with small explicit keys, no config options, and UNIX-style composability

[Johan Fleury]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: jfle...@arcaik.net

* Package name: age
  Version : 1.0.0-beta4
  Upstream Author : Filippo Valsorda 
* URL : https://github.com/FiloSottile/age
* License : BSD-3-Clause
  Programming Lang: Golang
  Description : simple, modern and secure encryption tool with small 
explicit keys, no config options, and UNIX-style composability

Bug#965353: [Pkg-javascript-devel] Bug#965353: Bug#965353: Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined

[Nicolas Mora]

I'm not sure yet if this would fix the bug but in all the build log
errors, I see that the file /usr/share/nodejs/lodash/_baseOrderBy.js is
always the source of the error.

The file _baseOrderBy.js in the package seems buggy for an unresolved reson.

File in node-lodash unstable package:
4.17.19+dfsg-1 _baseOrderBy.js https://paste.debian.net/1157886/

File in node-lodash bullseye package
4.17.15+dfsg-2 _baseOrderBy.js https://paste.debian.net/1157887/

In the unstable version, the call to isArray line 24 is the root of errors.

Also, I see that the upstream version 4.17.19 isn't tagged as latest
release, 4.17.16 is, maybe it's worth a try to package 4.17.16 instead?

https://github.com/lodash/lodash/releases

Bug#811087: closed by Michael Tokarev (Re: Bug#811087: qemu-user-static: qemu-arm-static segfaults in armhf chroot on 'aptitude -u')

[Andreas Beckmann]

Control: reopen -1
Control: found -1 1:5.0-13

On 7/26/20 4:51 PM, Debian Bug Tracking System wrote:
> This has been fixed in qemu 5.0 (maybe earlier, but 5.0 definitely works).
> The buster version (3.1) does not work still.

Unfortunately, I can still reproduce it with the current version from
sid (on an amd64 buster/bullseye mixed host) in all three qemu pbuilder
chroots I use: armhf, arm64, ppc64el.

Andreas

Bug#823185: fixed in bmake 20200710-1

[Thorsten Glaser]

On Sun, 26 Jul 2020, Andrej Shadura wrote:

>> basically, the bmake mk files don’t even remotely contain
>> anything usable.
>
>Any more details please? :)

There’s no bsd.*.mk there, so it’s ?make, not bmake, assuming
b stands for BSD…

> I have uploaded a new version with /usr/share/mk being the NetBSD files:
>
>  * /usr/share/bmake/mk-netbsd ships NetBSD files
>  * /usr/share/bmake/mk-bmake ships bmake files
>  * /usr/share/mk is a symlink to bmake/mk-netbsd

OK. We already changed this in makefs to use /usr/share/bmake/mk-netbsd
so this isn’t affected any more, but others like csh might also need to
use  and friends. (In fact, these are the reason why users
install bmake…)

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!

Bug#966328: ITP: tllist -- A C header file only implementation of a typed linked list

[Birger Schacht]

Package: wnpp
Severity: wishlist
Owner: Birger Schacht 
X-Debbugs-Cc: debian-de...@lists.debian.org, bir...@debian.org

* Package name: tllist
  Version : 1.0.1
  Upstream Author : Daniel Eklöf
* URL : https://codeberg.org/dnkl/tllist
* License : MIT
  Programming Lang: C
  Description : A C header file only implementation of a typed linked list


Most C implementations of linked list are untyped. That is, their data
carriers are typically void *. This is error prone since your compiler
will not be able to help you correct your mistakes (oh, was it a
pointer-to-a-pointer... I thought it was just a pointer...).

tllist addresses this by using pre-processor macros to implement dynamic
types, where the data carrier is typed to whatever you want; both
primitive data types are supported as well as aggregated ones such as
structs, enums and unions.

This is a build-dependency of foot (#966327).

Bug#966329: ITP: fcft -- simple library for font loading and glyph rasterization using FontConfig, FreeType and pixman

[Birger Schacht]

Package: wnpp
Severity: wishlist
Owner: Birger Schacht 
X-Debbugs-Cc: debian-de...@lists.debian.org, bir...@debian.org

* Package name: fcft
  Version : 2.2.2
  Upstream Author : Daniel Eklöf
* URL : https://codeberg.org/dnkl/fcft
* License : MIT
  Programming Lang: C
  Description : simple library for font loading and glyph rasterization 
using FontConfig, FreeType and pixman

fcft is a small font loading and glyph rasterization library built
on-top of FontConfig, FreeType2 and pixman.

It can load and cache fonts from a fontconfig-formatted name string,
e.g. Monospace:size=12, optionally with user configured fallback fonts.

This is a build dependency of foot (#966327).

Bug#966310: debian-edu-config 2.10.65+deb10u6 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 966310 = 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: debian-edu-config
Version: 2.10.65+deb10u6

Explanation: fix loss of dynamically allocated IPv4 address

Bug#725484: A way to override blhc false-positives

[Eriberto]

Updating... The  /etc file is interesting because I will can provide
patches in Debian package to solve some bugs related to false
positives until you release a new upstream version.

Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not parse device path: Invalid argument"

[Michel Le Bihan]

Hello,

What's preventing the upstream fix from being applied to this package?

Michel Le Bihan

Bug#966327: ITP: foot -- Fast, lightweight and minimalistic Wayland terminal emulator

[Birger Schacht]

Package: wnpp
Severity: wishlist
Owner: Birger Schacht 
X-Debbugs-Cc: debian-de...@lists.debian.org, bir...@debian.org

* Package name: foot
  Version : 1.4.1
  Upstream Author : Daniel Eklöf
* URL : https://codeberg.org/dnkl/foot
* License : MIT
  Programming Lang: C
  Description : Fast, lightweight and minimalistic Wayland terminal emulator

Foot is a Wayland terminal emulator.
Features:
* Fast
* Lightweight, in dependencies, on-disk and in-memory
* Wayland native
* DE agnostic
* User configurable font fallback
* On-the-fly DPI font size adjustment
* Scrollback search
* Color emoji support
* Server/daemon mode
* Multi-seat
* Synchronized Updates support
* Sixel image support

I plan to maintain it in the swaywm-team

Bug#964438: apt-listbugs: dns error when running from cron job

[Michael Biebl]

Am 26.07.20 um 21:36 schrieb Francesco Poli:
> Control: reassign -1 systemd
> 
> 
> On Fri, 17 Jul 2020 18:11:08 +0200 Francesco Poli wrote:
> 
>> On Fri, 17 Jul 2020 01:46:06 +0200 Michael Biebl wrote:
> [...]
>>> network-online.target is only relevant during boot, once the target has
>>> been reached, it will stay up, it is not dynamic.
>>> I.e. you can't use that to delay the execution of a service after
>>> suspend-resume.
> [...]
>>>
>>> Reassigning accordingly.
>>
>> Hello Michael, thanks for your prompt reply.
>>
>> OK, I acknowledge that the network-online.target check is not reliable
>> enough, I was aware of that.
>>
>> But anyway, let's pretend the network check is completely absent.
>>
>> Why is the service triggered *immediately* during wake-up?
>> It should wait at least 5 min (OnActiveSec=5min) or be triggered on the
>> basis of the calendar scheduling (OnCalendar=*-*-* *:20) with a random
>> delay (RandomizedDelaySec=20min).
>>
>> And it should *not* catch up with missed execution chances (since the
>> timer is *not* a Persistent=true one).
>>
>> What am I missing here?
> 
> Dear Michael,
> I am still convinced that this is a bug in systemd, as explained above.
> I am reassigning back the bug report to package systemd.
> 
> If you think that the timer unit can be modified so that it behaves as
> intended, please tell me how I should modify it.
> Just to recap the intended behavior: the timer should trigger the
> corresponding oneshot service 5 min after the timer activation and then
> hourly, with a random delay between 0 and 20 min, *without* catching up
> with missed execution chances, and it should *not* trigger the service
> immediately during a wake-up from sleep.

Maybe this is a misunderstanding. Persistent=true is relevant when you
reboot/power down a system. In your case, the system is suspended and
woken up again.

> Otherwise, please investigate/fix the issue and/or forward my
> bug report upstream, as appropriate.

Not sure what I'm supposed to investigate or fix here, sorry. So I can't
forward anything upstream either.





signature.asc
Description: OpenPGP digital signature

Bug#965212: Acknowledgement (linux-image-5.6.0-0.bpo.2-amd64: Booting HPE EPYC server with linux-image-5.6.0-0.bpo.2-amd64 reboots on startup)

[Carl Perry]

After working through the dependency issues, I was able to upgrade to
the 5.7 kernel from testing and all of the problems reported on this bug
and many others went away. Feel free to close this issue.

On 2020-07-17 17:51, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 965212: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965212.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   cape...@spherecube.host
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  Debian Kernel Team 
>
> If you wish to submit further information on this problem, please
> send it to 965...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>

Bug#937090: mrtrix: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Sun, Jul 26, 2020 at 03:07:35PM -0400, Yaroslav Halchenko wrote:
> Sorry about delay. Yes, mrtrix3 is Afaik the way to go. Please file RM

Ack, I've just filed an RM bug.

Cheers,
Moritz

Bug#966326: RM: mrtrix -- RoQA; Replaced by mrtrix3

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove mrtrix. It depends on Python 2 and has been replaced
by mrtrix3. Acked by the maintainers in #937090.

Cheers,
Moritz

Bug#966323: [Python-modules-team] Bug#966323: python3-subvertpy: missing (unversioned) Breaks+Replaces: python-subvertpy

[Sandro Tosi]

> From the attached log (scroll to the bottom...):
>
>   Preparing to unpack 
> .../python3-subvertpy_0.11.0~git20191228+2423bf1-4_amd64.deb ...
>   Unpacking python3-subvertpy (0.11.0~git20191228+2423bf1-4) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/python3-subvertpy_0.11.0~git20191228+2423bf1-4_amd64.deb
>  (--unpack):
>trying to overwrite '/usr/share/man/man1/subvertpy-fast-export.1.gz', 
> which is also in package python-subvertpy 0.11.0~git20191228+2423bf1-3
>   Errors were encountered while processing:
>
> /var/cache/apt/archives/python3-subvertpy_0.11.0~git20191228+2423bf1-4_amd64.deb
>
> Since python-subvertpy is gone, the B+R against it can be unversioned.

hm i dont think a B+R is needed here: python3-subvertpy installs a
binary called subvertpy3-fast-export so the manpage needs to match
that name; it's probably a relic of the py2 drop, looking at it right
now

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#965031: python3-numpy: please clarify the license for some files in debian/copyright

[Sandro Tosi]

> I do not have a github account.
> Could you be so kind to forward my bug report upstream?

I can, but what if they have questions or they want to follow up with
*you*? am I supposed to be proxying over their questions to you, your
replies and so on? i dont really want to be in that business.

Please find a way to communicate with upstream directly: email (they
have direct addresses and various mailing lists), discord, or any
other method that works for you (and tbh, in 2020, working in
opensource and not having a gh account limits your interactions and
impact dramatically, so you may want to reconsider that at some
point).

Once you reached an agreement with upstream, just let us know

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#965031: python3-numpy: please clarify the license for some files in debian/copyright

[Francesco Poli]

On Tue, 14 Jul 2020 13:46:33 -0400 Sandro Tosi wrote:

> > Please let me know,
> 
> feel free to reach out directly to upstream at
> https://github.com/numpy/numpy/issues and bring your licence/copyright
> concerns there.

I do not have a github account.
Could you be so kind to forward my bug report upstream?

Thanks for your cooperation.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpcEu7xczJr4.pgp
Description: PGP signature

Bug#966325: sphinx-common: dh_sphinxdoc doesn't remove .doctrees from man

[Christopher Hoskin]

Package: sphinx-common
Version: 2.4.3-4
Severity: wishlist

Dear Maintainer,

The wiki page on building Sphinx documentation shows building documentation in
both PDF and man page formats:

https://wiki.debian.org/SphinxDocumentation

dh_sphinxdoc removes .doctrees from html documentationm but not from man pages
(fix_sphinx_doc returns if it doesn't detect html before drop_cruft  is
called). This leads to a lintian warning "package-contains-python-doctree-file".

Please consider if dh_sphinxdoc could drop cruft such as .doctrees from man
page as well. Alternatively, make it clear in the dh_sphinxdoc man page that
dh_sphinxdoc only applies to html documentation.

Thanks,

Christopher Hoskin


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

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

Versions of packages sphinx-common depends on:
ii  libjs-sphinxdoc  2.4.3-4

Versions of packages sphinx-common recommends:
ii  python3-sphinx  2.4.3-4

sphinx-common suggests no packages.

-- no debconf information

Bug#966324: O: tango-icon-theme -- Tango icon library

[Philipp Kern]

Package: wnpp
Severity: normal

I intend to orphan the tango-icon-theme package.

There is effectively no churn in this package - but the last upstream release
was also 11 years ago. The install base is still quite large (~28k), but votes
are awfully low.  It is also a reverse dependency of a bunch of packages:

# Broken Depends:
frescobaldi: frescobaldi
metatheme-gilouche: gnome-theme-gilouche
piuparts: piuparts-master
  piuparts-master-from-git-deps
scolasync: scolasync
superkb: superkb

# Broken Build-Depends:
code-saturne: tango-icon-theme

The package description is:
 This package contains the icons made by the Tango project.
 .
 The project's aim is to create a cross-desktop and cross-platform icon
 theme following the Icon Naming Specification by the Freedesktop project.
 The icons follow a standard and consistent style guide to look coherent.

Bug#964438: apt-listbugs: dns error when running from cron job

[Francesco Poli]

Control: reassign -1 systemd


On Fri, 17 Jul 2020 18:11:08 +0200 Francesco Poli wrote:

> On Fri, 17 Jul 2020 01:46:06 +0200 Michael Biebl wrote:
[...]
> > network-online.target is only relevant during boot, once the target has
> > been reached, it will stay up, it is not dynamic.
> > I.e. you can't use that to delay the execution of a service after
> > suspend-resume.
[...]
> > 
> > Reassigning accordingly.
> 
> Hello Michael, thanks for your prompt reply.
> 
> OK, I acknowledge that the network-online.target check is not reliable
> enough, I was aware of that.
> 
> But anyway, let's pretend the network check is completely absent.
> 
> Why is the service triggered *immediately* during wake-up?
> It should wait at least 5 min (OnActiveSec=5min) or be triggered on the
> basis of the calendar scheduling (OnCalendar=*-*-* *:20) with a random
> delay (RandomizedDelaySec=20min).
> 
> And it should *not* catch up with missed execution chances (since the
> timer is *not* a Persistent=true one).
> 
> What am I missing here?

Dear Michael,
I am still convinced that this is a bug in systemd, as explained above.
I am reassigning back the bug report to package systemd.

If you think that the timer unit can be modified so that it behaves as
intended, please tell me how I should modify it.
Just to recap the intended behavior: the timer should trigger the
corresponding oneshot service 5 min after the timer activation and then
hourly, with a random delay between 0 and 20 min, *without* catching up
with missed execution chances, and it should *not* trigger the service
immediately during a wake-up from sleep.

Otherwise, please investigate/fix the issue and/or forward my
bug report upstream, as appropriate.

Thanks for your time and understanding.
Bye.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpeq76KhLPEk.pgp
Description: PGP signature

Bug#966323: python3-subvertpy: missing (unversioned) Breaks+Replaces: python-subvertpy

[Andreas Beckmann]

Package: python3-subvertpy
Version: 0.11.0~git20191228+2423bf1-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack 
.../python3-subvertpy_0.11.0~git20191228+2423bf1-4_amd64.deb ...
  Unpacking python3-subvertpy (0.11.0~git20191228+2423bf1-4) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-subvertpy_0.11.0~git20191228+2423bf1-4_amd64.deb
 (--unpack):
   trying to overwrite '/usr/share/man/man1/subvertpy-fast-export.1.gz', which 
is also in package python-subvertpy 0.11.0~git20191228+2423bf1-3
  Errors were encountered while processing:
   
/var/cache/apt/archives/python3-subvertpy_0.11.0~git20191228+2423bf1-4_amd64.deb
 
Since python-subvertpy is gone, the B+R against it can be unversioned.


cheers,

Andreas


python-subvertpy=0.11.0~git20191228+2423bf1-3_python3-subvertpy=0.11.0~git20191228+2423bf1-4.log.gz
Description: application/gzip

Bug#937090: mrtrix: Python2 removal in sid/bullseye

[Yaroslav Halchenko]

Sorry about delay. Yes, mrtrix3 is Afaik the way to go. Please file RM

On July 26, 2020 7:20:03 AM EDT, "Moritz Mühlenhoff"  wrote:
>On Fri, Jul 10, 2020 at 01:07:27PM +0200, Andreas Tille wrote:
>> Hi Moritz,
>> 
>> On Tue, Jun 30, 2020 at 08:14:15PM +0200, Moritz Mühlenhoff wrote:
>> > 
>> > Given that there's a separate mrtrix3 source package which is
>ported to
>> > Python 3, should src:mrtrix simply be removed now?
>> 
>> I wished Michael or Yaroslav would answer this question.  I'm just
>> helping to maintain this package and do not have the slightest
>interest
>> in it - may be the interest to see it go to have less work ...
>
>Michael, Yaroslow, what do you think?
>
>Cheers,
>Moritz

Bug#965353: [Pkg-javascript-devel] Bug#965353: Bug#965353: Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined

[Pirate Praveen]

Control: reopen -1

On Mon, Jul 27, 2020 at 00:32, Pirate Praveen 
 wrote:
This did not fix the issue :( So we have to reopen this bug once the 
upload reaches the archive (which will close this bug as fixed).


Thanks to the brave new world of embedding eveything and reducing the 
number of js packages. Complicated build systems in favor of reducing 
the metadata size, ftw!

Bug#966138: connman sysvrc script

[Tom H]

I don't use connman, but I was intrigued by this bug, so I replaced
ifupdown in a VM with connman.

1) connman is taking over the resolv.conf symlink because it provides
an inbuilt dns caching server and assumes that the user wants to use
it by default.

2) The package could ship "/etc/default/connman" with
"CONNMAN_RUNSTATEDIR_RESOLVCONF=no" to reverse the current sysvrc
default. It would then diverge from the systemd default, whose service
unit doesn't source "/etc/default/connman" and sets up the resolv.conf
symlink via "[/usr]/lib/tmpfiles.d/connman_resolvconf.conf".

Bug#965353: [Pkg-javascript-devel] Bug#965353: Bug#965353: Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined

[Pirate Praveen]

On Sun, Jul 26, 2020 at 22:43, Pirate Praveen 
 wrote:



On Sun, Jul 26, 2020 at 22:24, Pirate Praveen 
 wrote:

Babel build situation is indeed a mess.


It is even worse than I estimated. We can no longer build it with npm

DEB_BUILD_PROFILES=pkg.node-babel7.npm sbuild
...

HOME=`pwd` npm i
npm ERR! code EUNSUPPORTEDPROTOCOL
npm ERR! Unsupported URL Type "link:": 
link:./eslint/babel-eslint-config-internal


we have to change it to yarn.


This did not fix the issue :( So we have to reopen this bug once the 
upload reaches the archive (which will close this bug as fixed).

Bug#823185: fixed in bmake 20200710-1

[Andrej Shadura]

Control: found -1 20200710-4

I have uploaded a new version with /usr/share/mk being the NetBSD files:

 * /usr/share/bmake/mk-netbsd ships NetBSD files
 * /usr/share/bmake/mk-bmake ships bmake files
 * /usr/share/mk is a symlink to bmake/mk-netbsd

-- 
Cheers,
  Andrej

Bug#957492: Bug#964223: linuxtv-dvb-apps: FTBFS with glibc 2.31 (uses removed stime function)

[Aurelien Jarno]

On 2020-07-19 19:35, Aurelien Jarno wrote:
> control: tag -1 + pending
> 
> Dear maintainer,
> 
> On 2020-07-13 23:44, Aurelien Jarno wrote:
> > control: severity -1 serious
> > 
> > On 2020-07-03 22:27, Aurelien Jarno wrote:
> > > Source: linuxtv-dvb-apps
> > > Version: 1.1.1+rev1500-1.2
> > > Severity: important
> > > Tags: patch upstream
> > > 
> > > linuxtv-dvb-apps fails to build from source with glibc 2.31:
> > > 
> > > | CC dvbdate
> > > | dvbdate.c: In function ‘set_time’:
> > > | dvbdate.c:312:6: warning: implicit declaration of function ‘stime’; did 
> > > you mean ‘ctime’? [-Wimplicit-function-declaration]
> > > |   312 |  if (stime(new_time)) {
> > > |   |  ^
> > > |   |  ctime
> > > | /usr/bin/ld: /tmp/cchQDddv.o: in function `set_time':
> > > | ./util/dvbdate/dvbdate.c:312: undefined reference to `stime'
> > > | /usr/bin/ld: ./util/dvbdate/dvbdate.c:312: undefined reference to 
> > > `stime'
> > > | collect2: error: ld returned 1 exit status
> > > | make[3]: *** [../../Make.rules:82: dvbdate] Error 1
> > > | make[3]: Leaving directory '/<>/util/dvbdate'
> > > | make[2]: *** [Makefile:10: all] Error 2
> > > | make[2]: Leaving directory '/<>/util'
> > > | make[1]: *** [Makefile:14: all] Error 2
> > > | make[1]: Leaving directory '/<>'
> > > | dh_auto_build: error: make -j1 returned exit code 2
> > > | make: *** [debian/rules:4: build] Error 25
> > > | dpkg-buildpackage: error: debian/rules build subprocess returned exit 
> > > status 2
> > > 
> > > The full build log is available there:
> > > http://qa-logs.debian.net/2020/06/24/linuxtv-dvb-apps_1.1.1+rev1500-1.2_unstable_glibc-exp.log
> > > 
> > > The stime function has been marked as obsolete for some time, and since
> > > glibc 2.31 it is no longer available to newly linked binaries. The
> > > clock_settime function should be used instead.
> > > 
> > > You will find attached a patch fixing that. It would be nice if it can
> > > be fixed relatively soon so that we can start the transition.
> > > 
> > 
> > Note that glibc 2.31 is now in unstable. I am therefore increasing the
> > severity to serious.
> 
> I have prepared an NMU for linuxtv-dvb-apps (versioned as
> 1.1.1+rev1500-1.3), fixing the build issue with glibc 2.31. You will
> find the diff attached. I have uploaded it to DELAYED/7. Please feel
> free to tell me if I should delay it longer or cancel it altogether.

Unfortunately the NMU failed to build as in the meantime GCC 10 became
the default compiler and linuxtv-dvb-apps doesn't build with this
version due to bug #957492.

I have therefore done a second NMU, versioned 1.1.1+rev1500-1.4, and
uploaded directly to the archive (i.e. *not* through the delayed queue).
You will find the diff attached.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog	2020-07-19 19:11:31.0 +0200
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog	2020-07-26 20:42:38.0 +0200
@@ -1,3 +1,11 @@
+linuxtv-dvb-apps (1.1.1+rev1500-1.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add a patch to fix build with gcc 10, caused by multiple definition of the
+'sid' global variable. (Closes: #957492).
+
+ -- Aurelien Jarno   Sun, 26 Jul 2020 20:42:38 +0200
+
 linuxtv-dvb-apps (1.1.1+rev1500-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/gcc-10-sid-redefinition.patch linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/gcc-10-sid-redefinition.patch
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/gcc-10-sid-redefinition.patch	1970-01-01 01:00:00.0 +0100
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/gcc-10-sid-redefinition.patch	2020-07-26 20:39:03.0 +0200
@@ -0,0 +1,10 @@
+--- linuxtv-dvb-apps-1.1.1+rev1500.orig/util/alevt/vbi.c
 linuxtv-dvb-apps-1.1.1+rev1500/util/alevt/vbi.c
+@@ -35,7 +35,6 @@ static void dvb_handler(struct vbi *vbi,
+ 
+ static u8 *rawbuf; // one common buffer for raw vbi data
+ static int rawbuf_size; // its current size
+-u_int16_t sid;
+ static char *vbi_names[]
+ 	= { "/dev/vbi", "/dev/vbi0", "/dev/video0", "/dev/dvb/adapter0/demux0",
+ 	NULL }; // default device names if none was given at the command line
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series	2020-07-19 19:11:31.0 +0200
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series	2020-07-26 20:38:59.0 +0200
@@ -10,3 +10,4 @@
 fix-build-libpng16.patch
 dst_test-no-set-id.patch
 glibc-stime.patch
+gcc-10-sid-redefinition.patch


signature.asc
Description: PGP signature

Bug#966320: dico: Python2 removal in sid/bullseye

[Sandro Tosi]

Source: dico
Version: 2.9-4
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

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

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests, in details:

(binary:dicoweb)Depends->libapache2-mod-wsgi

Please stop using Python2, and fix this issue by one of the following
actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.
  
  This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.

Bug#966321: mnemosyne: Python2 removal in sid/bullseye

[Sandro Tosi]

Source: mnemosyne
Version: 2.7.2+ds1-1
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

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

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests, in details:

(binary:mnemosyne)Depends->python2:any

Please stop using Python2, and fix this issue by one of the following
actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.
  
  This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.

Bug#966322: pycsw: Python2 removal in sid/bullseye

[Sandro Tosi]

Source: pycsw
Version: 2.4.2+dfsg-4
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

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

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests, in details:

(binary:pycsw-wsgi)Depends->libapache2-mod-wsgi

Please stop using Python2, and fix this issue by one of the following
actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.
  
  This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.

Bug#823185: fixed in bmake 20200710-1

[Thorsten Glaser]

Hi,

> Can you please provide more details?

basically, the bmake mk files don’t even remotely contain
anything usable. Adding -m /usr/share/bmake/mk-netbsd fixes
this in bullseye/sid with a versioned B-D on the new bmake.
It is not the first time {p⇒b}make’s deficiencies troubled
makefs, though…

Anyway the new makefs was ACCEPTED so…

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#966319: bridge-utils: "bridge_ports all" fails on systems using Predictable Interface names

[Martin-Éric Racine]

Package: bridge-utils
Version: 1.6-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On hosts using Predictable Network Interface Names (e.g.enp4s0) "bridge_ports 
all" in /etc/network/interfaces fails at making the bridge find any interface. 
None of the interfaces shown in "ip addr" show that br0 is their master.

The kludge is to explicitly specify all desired interfaces as a space-separate 
list. Then the bridge indeed finds all interfaces, but this obviously eschews 
the whole point of using "all" as the interfaces to bind.

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

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

Versions of packages bridge-utils depends on:
ii  libc6  2.28-10

bridge-utils recommends no packages.

Versions of packages bridge-utils suggests:
ii  ifupdown  0.8.35

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAl8dvkQACgkQrh+Cd8S0
17azTg/9EI8bg/8+bcu6jcAcGxi57UzjQb7li42cEFbyJTtxE8/ZrcWpZYHeKMQe
C5uv6iPf4fLZsF8bgo8mNGcUgvIEOml+BTXexDgWED9fui+XwKXIhYsV+hl5FMbB
4FyS1nZJSrG7dzLsDgLCnWhAaSxdt82qUaNUp0EAW08ctgczE/mh426BZ1UMcBEJ
kfle8dJIt3A/rdK7r175QN8ZXjodsqq7VDDby9JpJUqhV/loKpaimIjkuRGfUQHW
hpGj1nXKz278txF07PLdNCVuEyzQ/GRQiqlw468daH7YTbmU/stcVSeKvi1f8jBp
a9ZX2l77TZTog9gWDw1NL544xq50yJFljWKUUG5rrfzBIm7rFT0AdLaj4TO9yF8s
8jFV3Gg+PodI9zGOZIkMeh9MAQOm+DyS98tZcTKoO+jI0xYgfkoCfkUqafoF6RHi
swk3g/Z6XfX9FzyeylbzRSLQvbiJ/whyvkDoTvgvCi493Dry4uSTosb8lhh4WpMy
a0O8uqe0Ymq04XzWTPUzSLdma3qfQ27Gotapv46ChXKStjzGElJw8ghG5AdRCH7A
glC6rNErs8PawUj1/aljTudn4vQ0tt04+aVnHFXef5G9Lx5h+JNVCo5DXByFgLX1
daC5pbvSMAYNcU7eHfI9+L5qqnl3DG67GlmB06NbUF87VR8psac=
=jtvX
-END PGP SIGNATURE-

Bug#823185: fixed in bmake 20200710-1

[Andrej Shadura]

Hi,

On Sun, 26 Jul 2020, at 18:45, Thorsten Glaser wrote:
> On Fri, 24 Jul 2020, Debian FTP Masters wrote:
> 
> >* Ship bmake mk files (Closes: #823185).
> 
> Thanks for breaking bmake’s r-builddeps without notice.

Well, I did test bmake with some rbuilddeps and found no regressions; sorry if 
it didn't work for you. I didn't expect big fallout; if I did, I would have 
organised a proper transition.

Can you please provide more details?

-- 
Cheers,
  Andrej

Bug#881719: libcdio 2.1.0 and lubcdio++

[Vasyl Gello]

Hi Gabriel!

Let me explain more briefly how I see the future of Kodi from Debian according 
to my grand plan.

July 26, 2020 4:33:22 PM UTC, "Gabriel F. T. Gomes" 
 написав(-ла):
>Hmm, that's not a decision to be made lightly. Would the backport to
>buster fix any bugs or add features that users have requested?

The core feature of v19 is improved PVR experience. This is a feature users 
have long asked for.

>>This will also greatly simplify add-on management as I have prepared the full 
>>binary addon repository for Kodi.
>>Now stable has,17.6, unstable 18.7 and experimental will feature 19.0~.
>
>Perhaps I do not understand the whole picture, but addons that work
>with stable alone (i.e. stable without backports) have to be maintained
>anyway (not every stable user enables backports). I don't see how
>having an updated version in backports simplifies anything. It's
>actually the other way around, as it adds more work for us.

Of course all the bugs in addons currently hosted in stable are addressed and 
will be under my maintenance.

The updated version in backports simplifies everything, because the stable user 
will have a choice - either stick
with current Debian release and get only security fixes reported by 3rd party 
researchers, or enable backports
and get the release maintained by upstream. Since Kodi upstream does not have a 
dedicated security team
and focuses on backporting serious+ bug fixes in the branch version prior to 
current (i.e consider 19.0 as
experimental, 18.8 as stable and 17.6 as oldstable and bugfixes are ported from 
19.0 to 18.8 but not to 17.6),
this really helps the end-user and package maintainers.

>I don't think so, as it defeats the purpose of having a stable
>distribution. And, in any case, people using the stable distribution
>without backports enabled will keep using the older set of addons,
>which might have security and serios functionality bugs, so we have to
>take care of them anyway.

Again, my intention is not to blatantly discard older versions, and I will 
check if there are unfixed
CVEs affecting 17.1 and 17.6 present in oldoldstable and oldstable but I 
clearly realize it would
be purely a Debian fix as upstream only accepts security and serious functional 
regression issues
to 18.8. Given how many addons are there in old(old)stable, it is not a big 
waste of my time to check it.

Cheers!
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

signature.asc
Description: PGP signature

Bug#965353: [Pkg-javascript-devel] Bug#965353: Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined

[Pirate Praveen]

On Sun, Jul 26, 2020 at 22:24, Pirate Praveen 
 wrote:

Babel build situation is indeed a mess.


It is even worse than I estimated. We can no longer build it with npm

DEB_BUILD_PROFILES=pkg.node-babel7.npm sbuild
...

HOME=`pwd` npm i
npm ERR! code EUNSUPPORTEDPROTOCOL
npm ERR! Unsupported URL Type "link:": 
link:./eslint/babel-eslint-config-internal


we have to change it to yarn.

Bug#966312: Weird getaddrinfo

[Andrei POPESCU]

Control: reassign -1 libc6

On Du, 26 iul 20, 22:24:52, viweei wrote:
> Package: libc
> Version: 2.28
> OS: Linux debian 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) 
> x86_64
> 
> Problems caused by curl and wget domain name resolution, use curl is 
> successful, but wget fails to parse.
> 
> viweei@debian:~$ wget baidu.com
> --2020-07-26 20:06:55--  http://baidu.com/
> Resolving baidu.com (baidu.com)... failed: Temporary failure in name 
> resolution.
> wget: unable to resolve host address 'baidu.com'
> viweei@debian:~$
> viweei@debian:~$
> viweei@debian:~$ curl baidu.com
> 
> http://www.baidu.com/;>
> 
> viweei@debian:~$
> -
> 
> Screenshot:
> 
> 
> Why does curl succeed and wget fails? I guess a different method of domain 
> name resolution is used, I used Python to confirm this problem, so I wrote 
> two programs.
> 
> Firs:
> viweei@debian:~/tmp$ cat first.py
> import sys, socket
> 
> result = socket.gethostbyname('baidu.com')
> print result
> viweei@debian:~/tmp$ python first.py
> 220.181.38.148
> viweei@debian:~/tmp$
> 
> 
> Screenshot:
> 
> 
> Second program fail.?
> 
> viweei@debian:~/tmp$ cat two.py
> import sys, socket
> 
> result = socket.getaddrinfo('baidu.com',None)
> print result
> 
> viweei@debian:~/tmp$ python two.py
> Traceback (most recent call last):
>   File "two.py", line 3, in 
> result = socket.getaddrinfo('baidu.com',None)
> socket.gaierror: [Errno -3] Temporary failure in name resolution
> viweei@debian:~/tmp$
> 
> Screenshot:
> 
> 
> So it can be seen that getaddrinfo failed, but why?  In order to further 
> confirm that it is the problem of getaddrinfo, I converted the program to C 
> language.
> 
> 
> viweei@debian:~/tmp$ cat test-dns.c
> #include 
> #include 
> #include 
> 
> const char * candidate="baidu.com";
> 
> int main(int argc, char * argv[])
> {
>  struct addrinfo *ai = NULL, *curr;
>  int ret = getaddrinfo(candidate, NULL, NULL, );
> 
>  if(ret != 0){
>   printf("Error on '%s': %s.\n", candidate, gai_strerror(ret));
>   return 0;
>  }
> 
>   char ipstr[16];
>   for(curr=ai; curr != NULL; curr=curr->ai_next){
> inet_ntop(AF_INET,&(((struct sockaddr_in *)(curr->ai_addr))->sin_addr), 
> ipstr, 16);
> printf("%s\n", ipstr);
>   }
> 
>  if (ai) freeaddrinfo(ai);
>  return 0;
> }
> viweei@debian:~/tmp$ gcc test-dns.c -o test
> test-dns.c: In function 'main':
> test-dns.c:19:5: warning: implicit declaration of function 'inet_ntop' 
> [-Wimplicit-function-declaration]
>  inet_ntop(AF_INET,&(((struct sockaddr_in *)(curr->ai_addr))->sin_addr), 
> ipstr, 16);
>  ^
> viweei@debian:~/tmp$ ./test
> 39.156.69.79
> 39.156.69.79
> 39.156.69.79
> 220.181.38.148
> 220.181.38.148
> 220.181.38.148
> viweei@debian:~/tmp$
> 
> 
> Screenshot:
> 
> 
> What ? I can't believe it. Why ?   Maybe the version of libc used is 
> inconsistent? I checked the loaded so file.
> 
> viweei@debian:~/tmp$ gcc test-dns.c -o test
> test-dns.c: In function 'main':
> test-dns.c:19:5: warning: implicit declaration of function 'inet_ntop' 
> [-Wimplicit-function-declaration]
>  inet_ntop(AF_INET,&(((struct sockaddr_in *)(curr->ai_addr))->sin_addr), 
> ipstr, 16);
>  ^
> viweei@debian:~/tmp$ ./test
> 39.156.69.79
> 39.156.69.79
> 39.156.69.79
> 220.181.38.148
> 220.181.38.148
> 220.181.38.148
> viweei@debian:~/tmp$ ldd test
> linux-vdso.so.1 (0x7ffd8333c000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f42450db000)
> /lib64/ld-linux-x86-64.so.2 (0x7f42452a9000)
> viweei@debian:~/tmp$
> 
> C program use /lib/x86_64-linux-gnu/libc.so.6,   Python program use 
> /usr/lib/x86_64-linux-gnu/libc-2.28.so. 
> 
> viweei@debian:~/tmp$ ls -l /lib/x86_64-linux-gnu/libc.so.6
> lrwxrwxrwx 1 root root 12 May  2  2019 /lib/x86_64-linux-gnu/libc.so.6 -> 
> libc-2.28.so
> 
> It's the same.  I don't understand why this happens? 
> 
> In addition, I also used tcpdump to capture packets
> 
> Shell:   sudo tcpdump -X port domain
> 
> Capture Python program:
> 22:15:40.486857 IP 192.168.0.193.38931 > public1.alidns.com.domain: 21424+ A? 
> baidu.com. (27)
> 0x:  4500 0037 2627 4000 4011 6f1b c0a8 00c1  E..7&'@.@.o.
> 0x0010:  df05 0505 9813 0035 0023 a5a8 53b0 0100  ...5.#..S...
> 0x0020:  0001    0562 6169 6475 0363  .baidu.c
> 0x0030:  6f6d  0100 01om.
> 22:15:40.487020 IP 192.168.0.193.38931 > public1.alidns.com.domain: 30648+ 
> ? baidu.com. (27)
> 0x:  4500 0037 2628 4000 4011 6f1a c0a8 00c1  E..7&(@.@.o.
> 0x0010:  df05 0505 9813 0035 0023 a5a8 77b8 0100  ...5.#..w...
> 0x0020:  0001    0562 6169 6475 0363  .baidu.c
> 0x0030:  6f6d  1c00 01om.
> 22:15:40.487258 IP 192.168.0.193.40826 > public1.alidns.com.domain: 43570+ 
> PTR? 

Bug#966318: O: pdf2svg -- converts PDF documents to SVG files (one per page)

[Philipp Kern]

Package: wnpp
Severity: normal

I intend to orphan the pdf2svg package.

This is a very minimal wrapper around Poppler and Cairo, feeding one's output
into the other's input to convert PDF into SVG files. I mostly did not have
this need anymore for a long time now. It historically did not need a lot
of up-keep, but of course input that Poppler only barely understands (yay PDF)
will not transfer well into SVG.

Popcon is ~950 installs, 90 votes.

The package description is:
 pdf2svg is a tiny command-line utility using Cairo and Poppler
 to convert PDF documents into SVG files.  Multi-page PDF can be split up to
 one SVG per page by passing a file naming specification.

Bug#965353: [Pkg-javascript-devel] Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined

[Pirate Praveen]

On Sun, Jul 26, 2020 at 19:35, Adrian Bunk  wrote:

On Sun, Jul 26, 2020 at 09:55:47PM +0530, Pirate Praveen wrote:
 I'm wondering if this will require another bootstraping cycle as 
node-babel7

 autopkgtest is also broken and it depends on itself.


If the problem is in node-lodash and gets fixed there,
shouldn't this fix everything?


I don't think the problem is in lodash as I can see babel upstream is 
already using lodash 4.17.19 in their yarn.lock 
https://github.com/babel/babel/blob/f7964a9ac51356f7df6404a25b27ba1cffba1ba7/yarn.lock#L7114


I think babel needs to use the same version of lodash it was built with 
and a breaking change in lodash was released as a minor/patch 
release/security release.


I think it is becoming more and more common to break API during 
security releases (we had to face this in rack/rails in ruby team).


Babel build situation is indeed a mess.

They are dicussing removing lodash from babel though see 
https://github.com/babel/babel/pull/11789

Bug#966317: O: gcc-3.3 -- providing The GNU Standard C++ Library v3 (libstdc++5)

[Philipp Kern]

Package: wnpp
Severity: normal

I am hereby orphaning gcc-3.3, which today just builds libstdc++5.

I no longer have binaries that rely on this ancient library. IBM TSM used to
require this - but as far as I can see, there are newer binaries these days
that use the "contemporary" C++ library. For old games it seems feasible to
just copy the binary around if needed. I'd be more worried about other 32-bit
libraries breaking at this point.

I'd weakly suggest not to include this package in the next Debian release,
but there might still be someone who cares. Popcon install count is still
around 4517, but vote is only 2, with 4514 reports not containing sufficient
information around usage.

Description: The GNU Standard C++ Library v3
 This package contains an additional runtime library for C++ programs
 built with the GNU compiler.
 .
 This package contains an old version of libstdc++ intended solely for
 compatibility with proprietary binaries that cannot be recompiled.

Kind regards
Philipp Kern

Bug#823185: fixed in bmake 20200710-1

[Thorsten Glaser]

On Fri, 24 Jul 2020, Debian FTP Masters wrote:

>* Ship bmake mk files (Closes: #823185).

Thanks for breaking bmake’s r-builddeps without notice.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general

Bug#965353: [Pkg-javascript-devel] Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined

[Adrian Bunk]

On Sun, Jul 26, 2020 at 09:55:47PM +0530, Pirate Praveen wrote:
> I'm wondering if this will require another bootstraping cycle as node-babel7
> autopkgtest is also broken and it depends on itself.

If the problem is in node-lodash and gets fixed there,
shouldn't this fix everything?

cu
Adrian

Bug#881719: libcdio 2.1.0 and lubcdio++

[Gabriel F. T. Gomes]

Hi, Vasyl,

On 26 Jul 2020, Vasyl Gello wrote:

>I need it to satisfy kodi build dependency in libcdio++. Actually, when Kodi 
>19.0 goes live officially,
>I would like to have it in unstable, testing (if it gets released before the 
>freeze takes place)

That sounds reasonable, and I'm already working on the upload to
unstable (I'll check that libcdio reverse dependencies [1] work
well with the new package, then make the upload).

[1] https://release.debian.org/transitions/html/auto-libcdio.html

>and at least,
>stable-bpo so end users have a chance to get backported, tested version 
>without upgrading the whole installation.

Hmm, that's not a decision to be made lightly. Would the backport to
buster fix any bugs or add features that users have requested?

Maintaining a package in backports is more work.

>This will also greatly simplify add-on management as I have prepared the full 
>binary addon repository for Kodi.
>Now stable has,17.6, unstable 18.7 and experimental will feature 19.0~.

Perhaps I do not understand the whole picture, but addons that work
with stable alone (i.e. stable without backports) have to be maintained
anyway (not every stable user enables backports). I don't see how
having an updated version in backports simplifies anything. It's
actually the other way around, as it adds more work for us.

>All addon sets are incompatible with each other and upstream backports only 
>security and serious+ functionality
>bug fixes. Sticking to the latest release in all branches is a good move.

I don't think so, as it defeats the purpose of having a stable
distribution. And, in any case, people using the stable distribution
without backports enabled will keep using the older set of addons,
which might have security and serios functionality bugs, so we have to
take care of them anyway.

Let me know if I got anything wrong. :)

Cheers,
Gabriel

Bug#966316: lintian: false positive acute-accent-in-manual-page in nroff comment

[Thorsten Glaser]

Package: lintian
Version: 2.85.0
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

I: makefs: acute-accent-in-manual-page usr/share/man/man8/makefs.8.gz:42

   42 .\" * ' generates ’ in gnroff, \' generates ´, so use \*(aq

While, yes, the sequence “\'” is there, it’s in a comment (the line
begins with “.\"” which is one of the ways to add comments in nroff)
and therefore a false positive. Shouldn’t be too hard to fix (but
mind there are multiple ways for commenting in nroff).

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils  2.35-1
ii  bzip2 1.0.8-4
ii  diffstat  1.63-1
ii  dpkg  1.20.5
ii  dpkg-dev  1.20.5
ii  file  1:5.38-5
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+b5
ii  libclone-perl 0.45-1
ii  libconfig-tiny-perl   2.24-1
ii  libcpanel-json-xs-perl4.19-1
ii  libdata-dpath-perl0.58-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdevel-size-perl0.83-1+b1
ii  libdpkg-perl  1.20.5
ii  libemail-address-xs-perl  1.04-1+b2
ii  libfile-basedir-perl  0.08-1
ii  libfile-find-rule-perl0.34-1
ii  libfont-ttf-perl  1.06-1
ii  libhtml-parser-perl   3.72-5
ii  libio-async-loop-epoll-perl   0.21-1
ii  libio-async-perl  0.77-3
ii  libjson-maybexs-perl  1.004002-1
ii  liblist-compare-perl  0.53-1
ii  liblist-moreutils-perl0.416-1+b5
ii  liblist-utilsby-perl  0.11-1
ii  libmoo-perl   2.004000-1
ii  libmoox-aliases-perl  0.001006-1
ii  libnamespace-clean-perl   0.27-1
ii  libpath-tiny-perl 0.114-1
ii  libsereal-decoder-perl4.017+ds-1
ii  libsereal-encoder-perl4.017+ds-1
ii  libtext-levenshteinxs-perl0.03-4+b7
ii  libtext-xslate-perl   3.5.8-1
ii  libtime-duration-perl 1.21-1
ii  libtime-moment-perl   0.44-1+b2
ii  libtimedate-perl  2.3300-1
ii  libtry-tiny-perl  0.30-1
ii  libtype-tiny-perl 1.010002-1
ii  libunicode-utf8-perl  0.62-1+b1
ii  liburi-perl   1.76-2
ii  libxml-libxml-perl2.0134+dfsg-2
ii  libxml-writer-perl0.625-1
ii  libyaml-libyaml-perl  0.82+repack-1
ii  man-db2.9.3-2
ii  patchutils0.4.2-1
ii  perl [libdigest-sha-perl] 5.30.3-4
ii  t1utils   1.41-4
ii  xz-utils  5.2.4-1+b1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

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

-- no debconf information

Bug#965353: [Pkg-javascript-devel] Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined

[Pirate Praveen]

I'm wondering if this will require another bootstraping cycle as 
node-babel7 autopkgtest is also broken and it depends on itself.

Bug#916043: qemu-user-static: qemu-arm-static running armel dash breaks globbing

[Michael Tokarev]

Control: tag -1 + moreinfo

[ https://bugs.debian.org/916043 ]

On Sun, 09 Dec 2018 15:19:55 + Ian Campbell  wrote:
> Package: qemu-user-static
> Version: 1:2.12+dfsg-3+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> While working on a new qcontrol package, using a cross-schroot via
> qemu-arm-static on an amd64 host, I noticed that globs did not appear to be
> expanded when running dash. It appears to relate to libc 2.28-2 but only when
> running under qemu-arm-static:
...
> ijc@dagon:dash-bug$ sudo chroot 2.27-8/ dash -c 'echo *'
> bin etc lib usr
> ijc@dagon:dash-bug$ sudo chroot 2.28-2/ dash -c 'echo *'
> *

I can't reproduce this anymore with any version of qemu-user-static.
Maybe I really should have glibc_2.28-2 for this, lemme try it from
snapshot.debian.org..  nope, installing it in an armel chroot over
2.28-10 version does not change anything there.

So I don't really know what to do with this bugreport.  Tried even
jessie version of qemu, and also sid version (5.0), - it all Just Works.

Can you please try it again and see what's going in?

Thanks,

/mjt

Bug#966314: bepasty: Please provide an example uwsgi config

[James Valleroy]

Package: bepasty
Severity: wishlist
X-Debbugs-Cc: jvalle...@mailbox.org

I would like to add bepasty as an app in FreedomBox. For this purpose,
it would be nice to have an example ini configuration file for
uwsgi. In FreedomBox, we are already running uwsgi behind apache2
reverse proxy for searx and radicale apps.