Bug#925251: stretch-pu: package file/1:5.30-1+deb9u2

[Christoph Biedl]

Salvatore Bonaccorso wrote...

> Is this still something it is worth to pursue and adress those two
> CVEs pending for stretch or is the regression risk to high?

In my opinion it is worth to pursue it - so let me rebase upon the
latest releas in Debian 9 ("stretch") and upload to (old)s-p-u soon,
just after another round of regression tests. Then there's a lot of time
to let things mature.

Adam (for the stable release team), can I just go ahead, or would you
like to see an updated patch first?

From the neverending story departement,

Christoph


signature.asc
Description: PGP signature

Bug#951037: mtools: DEB_BUILD_MAINT_OPTIONS wrongly quoted -> all lfs and hardning options gone

[Helmut Grohne]

Package: mtools
Version: 4.0.23-2
Severity: important

Hi Chris,

in your last upload, you updated DEB_BUILD_MAINT_OPTIONS to include lfs
flags. Unfortunately, you applied shell-style quoting to a make
variable, which make preserves. dh does not like the extra quotes:

https://buildd.debian.org/status/fetch.php?pkg=mtools=arm64=4.0.23-2=1581075192=0
| dh: warning: invalid flag in DEB_BUILD_MAINT_OPTIONS: "hardening=+all
| dh: warning: unknown future feature in DEB_BUILD_MAINT_OPTIONS variable: lfs"

This results in all hardening and lfs being removed. Please remove the
quotes from the variable.

Helmut

Bug#951036: rmdir: failed to remove '/etc/pcmcia': Directory not empty

[積丹尼 Dan Jacobson]

Package: pcmciautils
Version: 018-10
Severity: minor

Purging configuration files for pcmciautils (018-10) ...
rmdir: failed to remove '/etc/pcmcia': Directory not empty

There was a /etc/pcmcia/atmel.conf there.

Bug#950879: bridge-utils: DSA and other VLAN aware bridges needs VLAN filtering

[Santiago Garcia Mantinan]

Hi!

> The attached patch adds the missing bridge_vlan_aware aka
> enable VLAN filtering support.

Great, thanks for the patch, I'll take a look at it and do some tests, if
everything looks ok I'll upload a new version soon.

Regards.
-- 
Manty/BestiaTester -> http://manty.net

Bug#951035: dpkg: warning: while removing anbox, directory '/var/lib/anbox' not empty so not removed

[積丹尼 Dan Jacobson]

Package: anbox
Severity: minor
Version: 0.0~git20191115-1

Purging configuration files for anbox (0.0~git20191115-1) ...
dpkg: warning: while removing anbox, directory '/var/lib/anbox' not empty so 
not removed

# du -s /var/lib/anbox/*
318268  /var/lib/anbox/android.img
20  /var/lib/anbox/cache
12  /var/lib/anbox/containers
70284   /var/lib/anbox/data
4   /var/lib/anbox/devices
4260/var/lib/anbox/logs
4   /var/lib/anbox/rootfs
8   /var/lib/anbox/state

If intentionally not deleted, perhaps print a message.

Bug#941122:

[Markus Lindberg]

linux-image-5.3.0-0.bpo.2-amd64 seems to be working which is available
via buster-backports.

I tried suspending a laptop and waking it up and no latency is produced
while running a ping against another node on my LAN.

--
Markus

Bug#951034: ITP: bdf2sfd -- BDF to SFD converter

[Gürkan Myczko]

Package: wnpp
Severity: wishlist

* Package name: bdf2sfd
  Version : 1.0
  Upstream Authors: Frederic Cambus
* URL : https://github.com/fcambus/bdf2sfd
* License : BSD-2-clause
  Description : BDF to SFD converter
 This is a BDF to SFD converter, allowing to vectorize bitmap fonts. It 
works
 by converting each pixel of a glyph to a polygon, which produces large 
and

 unoptimized SFD files that should be post-processed using FontForge.
 .
 It was originally created to generate OpenType versions of Spleen, and 
is
 released in the hope it can be useful to convert other fonts as well. 
Please
 be aware that it works best on fonts proportional to 8x16. Other sizes 
will
 work but the aspect ratio will not be preserved. There is currently 
little

 interest in addressing the issue.

Package is available at http://phd-sid.ethz.ch/debian/bdf2sfd/

Bug#945522: has to be fixed in brial

[Matthias Klose]

Control: reassign -1 src:python-bleach

On 2/9/20 11:54 AM, Tobias Hansen wrote:
> Hi Matthias,
> 
> you reassigned the two bugs #945522 and #949029 to brial, however I don't see 
> any connection to brial. Neither beancount nor python-bleach depends on 
> brial, which is a math library for dealing with polynomials over boolean 
> rings by the way.
> 
> Did you confuse brial with something else?

yes, I did. reassigning.

> 
> Best,
> Tobias
> 
> On Sat, 8 Feb 2020 11:00:29 +0100 Matthias Klose  wrote:
>> Control: reassign -1 src:brial
>>
>> this has to be fixed in brial.  Changing the standard library just for the
>> distro isn't going to work.  Yes, it's unfortunate that such a change was
>> released, but IMO it's too late to fix there.
>>
>>
>>

Bug#950981: touchpad stopped working reliably

[Timo Aaltonen]

On 10.2.2020 8.34, Michael Biebl wrote:

Am 10.02.20 um 07:15 schrieb Timo Aaltonen:

On 9.2.2020 11.20, Michael Biebl wrote:

On Sun, 09 Feb 2020 09:17:49 +0100 Michael Biebl 
wrote:


Device:   SynPS/2 Synaptics TouchPad
Kernel:   /dev/input/event5
Group:    8
Seat: seat0, default
Size: 74x43mm
Capabilities: pointer gesture
Tap-to-click: disabled
Tap-and-drag: enabled
Tap drag lock:    disabled
Left-handed:  disabled
Nat.scrolling:    disabled
Middle emulation: disabled
Calibration:  n/a
Scroll methods:   *two-finger edge
Click methods:    *button-areas clickfinger
Disable-w-typing: enabled
Accel profiles:   none
Rotation: n/a


I re-installed 1.15.1 and here's the same output

Device:   SynPS/2 Synaptics TouchPad
Kernel:   /dev/input/event5
Group:    8
Seat: seat0, default
Size: 53x24mm
Capabilities: pointer gesture
Tap-to-click: disabled
Tap-and-drag: enabled
Tap drag lock:    disabled
Left-handed:  disabled
Nat.scrolling:    disabled
Middle emulation: disabled
Calibration:  n/a
Scroll methods:   *two-finger edge
Click methods:    *button-areas clickfinger
Disable-w-typing: enabled
Accel profiles:   none
Rotation: n/a

Notice how the size is much smaller.
I suspect what happens is, that when I swipe into the outer areas
libinput simply ignores those events due to the wrong dimensions.

74x43mm appears like the correct size, 53x24mm is way too small



alright, needs to be reported upstream:

https://gitlab.freedesktop.org/libinput/libinput/issues


Can you give me some hints which information I should include in the
upstream bug report?



the libinput output above for starters, they'll ask for more if needed

--
t

Bug#950981: touchpad stopped working reliably

[Michael Biebl]

Am 10.02.20 um 07:15 schrieb Timo Aaltonen:
> On 9.2.2020 11.20, Michael Biebl wrote:
>> On Sun, 09 Feb 2020 09:17:49 +0100 Michael Biebl 
>> wrote:
>>
>>> Device:   SynPS/2 Synaptics TouchPad
>>> Kernel:   /dev/input/event5
>>> Group:    8
>>> Seat: seat0, default
>>> Size: 74x43mm
>>> Capabilities: pointer gesture
>>> Tap-to-click: disabled
>>> Tap-and-drag: enabled
>>> Tap drag lock:    disabled
>>> Left-handed:  disabled
>>> Nat.scrolling:    disabled
>>> Middle emulation: disabled
>>> Calibration:  n/a
>>> Scroll methods:   *two-finger edge
>>> Click methods:    *button-areas clickfinger
>>> Disable-w-typing: enabled
>>> Accel profiles:   none
>>> Rotation: n/a
>>
>> I re-installed 1.15.1 and here's the same output
>>
>> Device:   SynPS/2 Synaptics TouchPad
>> Kernel:   /dev/input/event5
>> Group:    8
>> Seat: seat0, default
>> Size: 53x24mm
>> Capabilities: pointer gesture
>> Tap-to-click: disabled
>> Tap-and-drag: enabled
>> Tap drag lock:    disabled
>> Left-handed:  disabled
>> Nat.scrolling:    disabled
>> Middle emulation: disabled
>> Calibration:  n/a
>> Scroll methods:   *two-finger edge
>> Click methods:    *button-areas clickfinger
>> Disable-w-typing: enabled
>> Accel profiles:   none
>> Rotation: n/a
>>
>> Notice how the size is much smaller.
>> I suspect what happens is, that when I swipe into the outer areas
>> libinput simply ignores those events due to the wrong dimensions.
>>
>> 74x43mm appears like the correct size, 53x24mm is way too small
>>
> 
> alright, needs to be reported upstream:
> 
> https://gitlab.freedesktop.org/libinput/libinput/issues

Can you give me some hints which information I should include in the
upstream bug report?

Bug#951003: libmath-gmp-perl: FTBFS with gmp 6.2.0: test failure

[Steven Robbins]

On Sun, 09 Feb 2020 18:04:33 +0100 gregor herrmann  wrote:
> Source: libmath-gmp-perl
> Version: 2.19-1
> Severity: serious
> Tags: upstream ftbfs sid bullseye
> Justification: fails to build from source (but built successfully in the 
past)

I created a minimal pull request for this:
https://salsa.debian.org/perl-team/modules/packages/libmath-gmp-perl/
merge_requests/1

-Steve


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

Bug#950981: touchpad stopped working reliably

[Timo Aaltonen]

On 9.2.2020 11.20, Michael Biebl wrote:

On Sun, 09 Feb 2020 09:17:49 +0100 Michael Biebl  wrote:


Device:   SynPS/2 Synaptics TouchPad
Kernel:   /dev/input/event5
Group:8
Seat: seat0, default
Size: 74x43mm
Capabilities: pointer gesture
Tap-to-click: disabled
Tap-and-drag: enabled
Tap drag lock:disabled
Left-handed:  disabled
Nat.scrolling:disabled
Middle emulation: disabled
Calibration:  n/a
Scroll methods:   *two-finger edge
Click methods:*button-areas clickfinger
Disable-w-typing: enabled
Accel profiles:   none
Rotation: n/a


I re-installed 1.15.1 and here's the same output

Device:   SynPS/2 Synaptics TouchPad
Kernel:   /dev/input/event5
Group:8
Seat: seat0, default
Size: 53x24mm
Capabilities: pointer gesture
Tap-to-click: disabled
Tap-and-drag: enabled
Tap drag lock:disabled
Left-handed:  disabled
Nat.scrolling:disabled
Middle emulation: disabled
Calibration:  n/a
Scroll methods:   *two-finger edge
Click methods:*button-areas clickfinger
Disable-w-typing: enabled
Accel profiles:   none
Rotation: n/a

Notice how the size is much smaller.
I suspect what happens is, that when I swipe into the outer areas
libinput simply ignores those events due to the wrong dimensions.

74x43mm appears like the correct size, 53x24mm is way too small



alright, needs to be reported upstream:

https://gitlab.freedesktop.org/libinput/libinput/issues


--
t

Bug#951033: cura: UI not usable in 4.4.1

[Mateusz Skowroński]

Package: cura
Version: 4.4.1-1
Severity: normal

Dear Maintainer,
After upgrading to 4.4.1 the UI is not usable. See screenshot. The dialog is
all messed up.
Appimage version works as expected.

Deleting the config folder is even worse. I can't get past the settings wizard.

Cheers,
Mateusz



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

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

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

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

cura suggests no packages.

Bug#951032: python-qtpy: FTBFS due to typo in debian/control

[Jeremy L. Gaddis]

Package: python-qtpy
Version: 1.9.0-1
Severity: grave
Tags: ftbfs

Approximately 13 hours ago, commit 1e833c44 introduced a typo in the
"Depends:" field for the "python3-qtpy" package in the ("python-qtpy"
source package's) "debian/control" file.

As a result, the "python3-qtpy" binary package and packages which
depend on it, such as "git-cola", are not installable:

[snip]
$ sudo apt install git-cola
...
The following packages have unmet dependencies:
 git-cola : Depends: python3-qtpy but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
[snip]

The most recent build of the "python-qtpy" source package on
ci.debian.net failed for this reason, as can be seen in the test log
[0].

The typo exists on line 35 [1] of the "debian/control" file.

Line 35 currently reads:

[snip]
 python3-pyqt5.qtquic,
[snip]

This should obviously read "python3-pyqt5.qtquick," instead.

[0]: 
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-qtpy/4246249/log.gz

[1]: 
https://salsa.debian.org/python-team/modules/python-qtpy/blob/1e833c442dc9d63b2c4328f57a9ad42c4bfc7d24/debian/control#L35

Thanks,
-Jeremy

--
Jeremy L. Gaddis

Bug#950822: systemd-sysusers hangs if nis is enabled in a systemd-nspawn container

[Ryutaroh Matsumoto]

I prepared a qemu-x86-64 disk image that can reproduce this symptom at
https://drive.google.com/drive/folders/1ObSUu3DCF2r4tzcGrykhBCRpPSemHNiu

After logging in as root with password root,
systemd-nspawn -M container1 -n -b
reproduces the symptom, that is,
/bin/systemd-sysusers talks with rpcbind.socket
before rpcbind.service is started, and hangs up.

Ryutaroh

Bug#950994: Discourage package in contrib to install the real program via another package manager

[Olek Wojnar]

On 2/9/20 8:43 AM, Shengjing Zhu wrote:
> Source: debian-policy
> Severity: wishlist
>
> I find there are two packages[1] in archive now installing real
> program using
> snap[2]. The two packages in main are definitely against policy. But the
> maintainer is moving them to contrib, which has no problem with
> current policy.

Since I'm the maintainer of those two packages, I figured I'd chime in
here. :)

> Technically snap is a package manager just like apt/dpkg.
> I don't think there is any benefit to do this. People want to use snap
> could
> just install with snap, no need to call apt.

1) Perhaps surprisingly, I agree in principle that installing from an
external source should not be "encouraged" under normal circumstances.

2) However, this illustrates a use case that perhaps has not come up in
the past. As I explained in one of the bug reports against my packages,
the rationale for this was to provide a temporary alternate
functionality for end users while upstream goes through a period of
instability.

    2a) Ideally, I would have preferred to remove the packages in
question from Debian and have a system that would have presented users
with options for alternate sources of that package. I may try to hack
something together for my packages because I agree with a comment on one
of those bugs that transitioning to an alternate package source should
not be done without explicit user action.

    2b) In a general sense though, this seems like a mechanism that may
have value beyond these two packages. For example, would it be possible
for maintainers to list alternate sources of a package in a new field in
d/control? Then, if a package must be removed from Debian either
temporarily or permanently, users could be presented with alternate
options for that package. Or if certain users want the bleeding-edge
version they can easily get to it instead of pestering a maintainer to
package something that is not stable enough for Debian.

    2c) The problem with saying a user could just install from
snap/flatpak/etc is that a user may not know what other options are out
there and may not know if they are authoritative (e.g. many but not all
packages are created by the upstream authors). What I am proposing
(well, more like thinking about at the moment, and looking for feedback)
is a system to create an equivalence between the official Debian package
and the same package in other systems. Does anyone else see value in
such a construct?

> Another package manager in subject could be snap, flatpak, pip, nix, etc.
>
> [1] https://tracker.debian.org/pkg/cyphesis-cpp
>     https://tracker.debian.org/pkg/ember
> [2] https://tracker.debian.org/pkg/snapd

In summary, as snap/flatpak/etc increase in popularity I think it may be
a good idea to have a formalized method for Debian package maintainers
to designate authoritative equivalent sources for their packages, if
they wish to do so.

-Olek




signature.asc
Description: OpenPGP digital signature

Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system

[Olek Wojnar]

Hmm.. some good points to ponder. Thanks! Let me think on that a little
and I'll respond more fully.

-Olek

On 2/9/20 5:12 PM, Manuel A. Fernandez Montecelo wrote:
> Hello Olek,
>
> Em sáb., 8 de fev. de 2020 às 18:25, Olek Wojnar  escreveu:
>>> I don't think taht using this package as an empty shell and a gateway to 
>>> install
>>> the "snap" package [1] is a valid use of the packaging system.
>> Not only is this use listed in Policy [1] under the contrib section
>> (where I'm moving the two packages I've done this with, pending NEW) but
>> a number of other packages (in contrib) do exactly the same thing. Flash
>> [2] being the obvious example. I'd also like to point out that I asked
>> about this course of action back in December [3] and no one raised any
>> concerns. So it's a little frustrating that after I've done all the work
>> to convert the packages I'm now getting feedback saying I shouldn't have
>> done it.
> I am sorry that you made the work and noone told you about this.
> Maybe I am in the minority and most people don't see it this way,
> don't know.
>
> I simply stumbled upon the package by chance, and I didn't have time
> to follow mailing lists regularly in the last months, and I think that
> I haven't read debian-games for years.
>
>
> But to the point about the installation of snaps and "flash", as far
> as I see it, there are two fundamental differences:
>
> 1) For flash, and I guess that most packages of contrib, the items
> that are download are checksummed [1], so we know what the script
> installs, and we have to manually approve new versions.  If the
> download is known to be compromised, users will not install new
> versions (and we can do removal of existing versions in some cases, if
> we only find that it's a security problem after users install it, at
> least in some cases).
>
>   
> [1]https://sources.debian.org/src/flashplugin-nonfree/1:3.7/update-flashplugin-nonfree/
>
> This does not happen with the installation of these snaps, as far as I
> can see -- it will take whatever is there, the latest version, no
> checksumming or pinning to known-good versions, and there's no
> guarantee that if tomorrow someone takes over that package and
> installs malware, that users installing it from Debian will not use
> it.  Once users install the snaps, it's completely outside of Debian's
> control, I think.
>
>
> 2) These kind of methods are done for special packages like firmware,
> very popular apps like flash (at the time), etc, or *data* packages
> from games.  It's a "known evil" thing to do, still we do it because
> it's somewhat needed by many users -- nowadays you can easily live
> without flash, but it was not so easy in the web 10 years ago; it's
> impossible to install some computers without firmware, etc.
>
> But I don't see the need to do it with a very marginal package like
> Ember.  Either people are happy to run the older version from 2016, or
> if not, they would have already updated it by some means, like maybe
> using themselves the snap package.
>
> So I don't think that it's worth promoting things that are a bit
> against the philosophy of Debian/traditional distros, like snaps
> (adding layers of overhead and duplication, and potentially security
> vulnerabilities) due to a package with very low popcon and which use
> is not critical, it's just a game.
>
>
> 3) Aside from that, I would be more OK with it if, before installing,
> there were clear indications of what's going on for people that might
> be unaware of what Snaps are, and that fail to notice the change in
> description of the package.
>
> As I understand it, there's no indication that you'll install a snap
> package if you just do "apt-get upgrade".  That's the part that I
> think it's more troubling, that you can end up installing snap
> packages without even noticing -- maybe because you happened to have
> "ember" installed in the past and you wanted to check it up one time
> long ago, and are not even using it very actively in the last
> months/years.
>
> If you have something like a debconf question asking users if they
> want to install the snap package, or invoke snap and you decide if you
> want to install it or not without the configuration of the package
> failing if you reject, etc, then I think that it's much more
> reasonable.
>
>
>>> Otherwise, if this was an accepted practice, we could start to have many
>>> packages which are just a way to install snap packages, which can easily 
>>> contain
>>> security vulnerabilities and install not free software, specially if the 
>>> version
>>> is not restricted in some way.  And this not generally expected by users of
>>> Debian, IMO.
>> This is a fair concern. However, I think that users *do* expect this of
>> packages in contrib. Pabs made a good argument in a different bug report
>> about this issue and convinced me. I'm going with that.
> This and cyphesis are the only packages that depend on snapd, which
> are not app-managers from 

Bug#951031: libtool: remove dates from .info and .html documentation

[Vagrant Cascadian]

Package: libtool
Version: 2.4.6-12
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The date gets embedded in some of the .info and .html documentation.

Please consider applying the attached patch to remove them.


live well,
  vagrant
From d5520a1bdf85b868b872ca3e1c2ca60c4613a3c2 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 10 Feb 2020 03:09:45 +
Subject: Patch to remove dates from .info and .html documentation

---
 ...ve-date-from-libtool-texinfo-file-to.patch | 29 +++
 debian/patches/series |  1 +
 2 files changed, 30 insertions(+)
 create mode 100644 debian/patches/remove-date-from-libtool-texinfo-file-to.patch

diff --git a/debian/patches/remove-date-from-libtool-texinfo-file-to.patch b/debian/patches/remove-date-from-libtool-texinfo-file-to.patch
new file mode 100644
index 000..88cfdd3
--- /dev/null
+++ b/debian/patches/remove-date-from-libtool-texinfo-file-to.patch
@@ -0,0 +1,29 @@
+From: Vagrant Cascadian 
+Date: Mon, 10 Feb 2020 03:05:43 +
+X-Dgit-Generated: 2.4.6-12 e840405d77a841463dcf6eee1e8e10a82ae8b59d
+Subject: Remove date from libtool texinfo file to ensure reproducible builds
+
+regardless of when it is built.
+
+---
+
+--- libtool-2.4.6.orig/doc/libtool.texi
 libtool-2.4.6/doc/libtool.texi
+@@ -18,7 +18,7 @@
+ @set objdir .libs
+ 
+ @copying
+-This manual is for GNU Libtool (version @value{VERSION}, @value{UPDATED}).
++This manual is for GNU Libtool (version @value{VERSION}).
+ 
+ Copyright @copyright{} 1996-2015 Free Software Foundation, Inc.
+ 
+@@ -43,7 +43,7 @@ the section entitled ``GNU Free Document
+ 
+ @titlepage
+ @title GNU Libtool
+-@subtitle For version @value{VERSION}, @value{UPDATED}
++@subtitle For version @value{VERSION}
+ @author Gordon Matzigkeit
+ @author Alexandre Oliva
+ @author Thomas Tanner
diff --git a/debian/patches/series b/debian/patches/series
index 4503119..9a7831d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -26,3 +26,4 @@ libtool-eval-nm.patch
 0050-documentation.patch
 0055-pass-flags-unchanged.patch
 0060-ar.patch
+remove-date-from-libtool-texinfo-file-to.patch
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#951030: Bug#950859: cegui-mk2: FTBFS with boost171 and new cmake and symbol changes

[Olek Wojnar]

Hi Dimitri,

On Sat, Feb 8, 2020 at 7:37 PM Dimitri John Ledkov  wrote:

> Yes there is a way.
>
> You can provide libcegui-mk2-x.y.z-boost171
> And then rewrite shlib deps to require a dep on
> libcegui-mk2-x.y.z-boost171 ( >= X.y.z)
>
> That way things that build against this new lib get the right dep, and
> whenever cegui is NMUed for new boost Abi autochanges.
>
> However, when you switch to this scheme either the library package needs
> to change name, or you need to declare breaks on your reverse deps, to
> prevent partial upgrade
>
> Boost does similar to encode python versions and icu. And many other deb
> languages do similar things like ocaml, gch, etc.
>

Thanks for the recommendation! Unfortunately, that's a bit more than I can
do in the near future so I've split this off from the rest of your bug
report so that I can hopefully work on it at some point in the future.
Patches welcome of course if this is something you're more familiar with
and have the time! ;)

-Olek


>
> On Sat, 8 Feb 2020, 17:48 Olek Wojnar,  wrote:
>
>> Hi Dimitri,
>>
>> Thanks for the bug report, and thanks for the patch!
>>
>> On 2/7/20 8:49 AM, Dimitri John Ledkov wrote:
>> > Package: cegui-mk2
>> > Version: 0.8.7-5
>> > Severity: serious
>> > Tags: patch
>> > Justification: ftbfs
>> >
>> > Dear Maintainer,
>> >
>> > cegui-mk2 ftbfs with new cmake & boost1.71 due to change in cmake
>> > policy w.r.t. boost version detection (it is now more normal). See
>> patch attached.
>>
>> Thank goodness for them making it more normal! I was not a fan of that
>> old system.
>>
>> > I am currently in process of migrating to boost1.71 in Ubuntu, which
>> > has not started yet in Debian but is upcoming.
>> >
>> > When built against boost1.71 symbols are dropped and changed. It seems
>> > as if cegui-mk2 re-exports boost symbols, and thus boost abi change in
>> > templates leakes in the change of cegui-mk2 libraries ABI change.
>> >
>> > How should this be handled?
>> >
>> > Is there a new upstream release of cegui that we can package in
>> > experimental, always built against boost1.71 with new symbols?
>>
>> No, upstream has not done a new release in a while. Although I can (and
>> plan to) package the current version in experimental once boost1.71
>> lands there. Since I don't follow Boost, a notification in this bug
>> report would be appreciated.
>>
>> > Or shall i just blindly update the symbols file, rebuild ember and
>> > hope for the best?
>> >
>> > How was this handled in cegui-mk2 before, when boost changed without
>> > cegui-mk2 new upstream releases?
>>
>> I've only recently taken a more-active role in maintaining this package.
>> I think I previously only submitted a few NMUs. But, I believe that what
>> you listed is exactly what happened. I know I saw that with Ember (which
>> I *have* been maintaining for a while).
>>
>> If you have any suggestions for a better, less-reactive, way forward on
>> this I'm certainly open to it!
>>
>> > I would like to avoid diverging ABI between ubuntu & debian here.
>>
>> Absolutely! I'm a big fan of keeping Debian and Ubuntu closely
>> synchronized.
>>
>> -Olek
>>
>>
>>

Bug#947740: git: Please backport Git 2.24 to Buster

[Sean Whitton]

Hello Jonathan,

On Wed 15 Jan 2020 at 06:40AM -07, Sean Whitton wrote:

> Had chance to look at this yet?  It's blocking updating the backport of
> git-annex.  Thanks!

Just to let you know, unless you ask me not to, I'll go ahead and upload
git to buster-backports soon.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#950822: systemd-sysusers hangs if nis is enabled in a systemd-nspawn container

[Ryutaroh Matsumoto]

From: Michael Biebl 
Date: Sun, 9 Feb 2020 08:53:33 +0100
> Not sure what the right solution is. One might be, that the nis NSS
> module handles this situation (rpcbind.socket running, rpcbind.service
> not running) better, or that rpcbind.socket changes its ordering to
> avoid this situation.
> 
> I do think this should be fixed on the nis/rpcbind side though.

I reassigned this report to the rpcbind Debian package...

Ryutaroh

Bug#906063: Building package with SOURCE_ONLY_CHANGES=yes generates invalid *_source.changes file

[Sergio Durigan Junior]

On Monday, November 11 2019, Agustin Martin wrote:

> On Mon, Aug 13, 2018 at 04:08:37PM -0400, Sergio Durigan Junior wrote:
>> Hi there,
>> 
>> While building the cvc4 package for upload, I tried setting
>> SOURCE_ONLY_CHANGES=yes in order to generate a *_source.changes file.
>> Everything was apparently fine, but when I tried to upload to changes
>> file, I got the following error:
>> 
>>   $ dput ftp-master cvc4_1.6-2_source.changes 
>>   Uploading cvc4 using ftp to ftp-master (host: ftp.upload.debian.org; 
>> directory: /pub/UploadQueue/)
>>   running allowed-distribution: check whether a local profile permits 
>> uploads to the target distribution
>>   running protected-distribution: warn before uploading to distributions 
>> where a special policy applies
>>   running checksum: verify checksums before uploading
>>   Bad checksums on cvc4_1.6-2_source.changes: Checksum mismatch for file 
>> cvc4_1.6-2.dsc: b65d2b868fd05a6aeb7606e5f03a05f3 != 
>> f83d68e6a9f76c3a887d3ff6e7b498f9
>> 
>> Comparing the cvc4_1.6-2_source.changes file against the
>> cvc4_1.6-2_amd64.changes file, one can see that the checksum for the
>> cvc4_1.6-2.dsc file is indeed different between them.  In the end, I had
>> to do a normal upload.
>> 
>> I'm using gbp buildpackage with pbuilder behind the curtains, and my
>> config files are:
>> 
>>   $ cat .pbuilderrc 
>>   # Automatically sign builds.
>>   AUTO_DEBSIGN=yes
>>   PDEBUILD_PBUILDER=cowbuilder
>>   BUILDRESULT=$PWD/../
>>   SOURCE_ONLY_CHANGES=yes
>
> Hi, Sergio

Hey, Tin,

> Currently, when both arch.changes and source.changes files are present and
> --auto-debsign is enabled, pdebuild will only sign the arch.changes file. 
> See https://bugs.debian.org/932743.
>
> It may be that when signing arch.changes file it also signs .dsc and
> .buildinfo files, thus modifying them. This makes checksums into
> source.changes file no longer match those of the signed files. If that is
> the case, that source.changes file would have been useless anyway since
> it is not signed.
>
> In #932743 Mattia Rizzolo has proposed a patch to sign both .changes files,
> you may want to try it.
>
> Hope this helps.

Thanks for the explanation and the pointers.  I confess I have switched
to sbuild now (which has a similar problem, mind you!), but if I have
the time I'll give the patch a try.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#911560: [Kinda solved] Re: Network not working on Olimex LIME2 rev K ??

[Vagrant Cascadian]

On 2020-02-09, Dominique Dumont wrote:
> On Saturday, 8 February 2020 16:54:45 CET Jonas Smedegaard wrote:
>> Would be great if you could also test with patched u-boot in stable
>> Debian - so we can consider fixing this in a point release.
>
> I've tested together:
> - Debian's u-boot debian/2019.01+dfsg-7 with CONFIG_GMAC_TX_DELAY=3 tweak
> - Debian's stable partition (dated 2019-11)

Thanks for debugging the issue!

Please submit a patch to upstream fixing this in the appropriate files
in configs/*; I'd guess configs/A20-OLinuXino-Lime2-eMMC_defconfig
and/or configs/A20-OLinuXino-Lime2_defconfig.

Then I'll feel happier about backporting them to u-boot in stable and
eventually can drop the patch...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#951029: Please document unexpected behaviour in pathlib.Path('.').glob('*/') - trailing slash matches regular files

[Trent W. Buck]

Package: libpython3.7-stdlib
Version: 3.7.3-2+deb10u1
Severity: minor
File: /usr/lib/python3.7/pathlib.py

I expected pathlib glob() to behave like sh glob.
I shot myself in the foot because of an unexpected difference.
Please document this difference to protect other sysadmins.

bash5$ ls
bash5$ touch f
bash5$ mkdir d

bash5$ ls -d *
d  f
bash5$ ls -d */
d/

bash5$ dash -c 'ls -d *'
d  f
bash5$ dash -c 'ls -d */'
d/

bash5$ python3.7 -c 'import pathlib; 
print(list(pathlib.Path(".").glob("*")))'
[PosixPath('d'), PosixPath('f')]
bash5$ python3.7 -c 'import pathlib; 
print(list(pathlib.Path(".").glob("*/")))'
[PosixPath('d'), PosixPath('f')]

I'm thinking something simple like this in Doc/library/pathlib.rst:

Note that (unlike sh and bash) a pattern with a trailing slash will still 
match regular files.

PS: I guess this also applies to Doc/library/glob.rst as well?
I avoid glob.glob() because it had no way to separate the "static" part from 
the "pattern" part.
e.g. glob.glob(args.path + '/*.deb') is not safe.  pathlib fixes that, yay!


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

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

Versions of packages libpython3.7-stdlib:amd64 depends on:
ii  libbz2-1.01.0.6-9.2~deb10u1
ii  libc6 2.29-9
ii  libdb5.3  5.3.28+dfsg1-0.5
ii  libffi6   3.2.1-9
ii  liblzma5  5.2.4-1
ii  libmpdec2 2.4.2-2
ii  libncursesw6  6.1+20181013-2+deb10u2
ii  libpython3.7-minimal  3.7.3-2+deb10u1
ii  libreadline7  7.0-5
ii  libsqlite3-0  3.31.1-1
ii  libtinfo6 6.1+20181013-2+deb10u2
ii  libuuid1  2.33.1-0.1
ii  mime-support  3.62

libpython3.7-stdlib:amd64 recommends no packages.

libpython3.7-stdlib:amd64 suggests no packages.

-- no debconf information

Bug#934977: [Pkg-emacsen-addons] Bug#934977: Bug#934977: verilog-mode: unbuildable in testing due to missing B-D emacs25

[Sean Whitton]

Hello,

On Sun 09 Feb 2020 at 03:30PM -07, Nicholas D Steeves wrote:

> I've tagged this bug "elpafy" because conversion to dh-elpa is best
> practises for team-maintained packages.  I also wonder if this will
> indirectly solve #863467 ?

Kiwamu specifically wanted to be sure this package worked with xemacs,
which is why it doesn't use dh_elpa (I sponsored the upload).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#951026: Workaround

[Richard Hector]

Note a workaround is to specify the full path for the include directory:

Include /home/richard/.ssh/config.d/*

Richard

Bug#950627: Regression: Unable to config with CMake

[Brian Clinkenbeard]

I believe I am also having this issue. "find_package(SDL2 REQUIRED)" in 
CMakeLists.txt yields the following error:
-- Target architecture: x86_64


CMake Error at 
/usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 
(message):
   Could NOT find SDL2 (missing: SDL2_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 
(_FPHSA_FAILURE_MESSAGE)
   externals/cmake-modules/FindSDL2.cmake:239 
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
   CMakeLists.txt:155 (find_package)


On Tue, 04 Feb 2020 12:13:53 +0100 Felix Geyer  wrote:
 > Hi,
 >
 > On 2020-02-04 11:41, Kyuma Ohta wrote:
 > > Package: libsdl2-dev
 > > Version: 2.0.10+dfsg1-2
 > > Severity: important
 > >
 > > Dear Maintainer,
 > >
 > > From this version, building any softwares with CMake,
 > > not configurable.
 > > This is *REGRESSION* of fix of BUG #946496.
 > > Please revert this fix, or apply fixes to CMake package,
 > > FindSDL.cmake.
 >
 > What exactly is broken?
 > Can you please provide an example with the CMakeLists.txt code and the
 > log output?
 >
 > Felix
 >
 >

Bug#951020: zshdb: build-depends on emacs25

[Iain Learmonth]

On 10/02/2020 01:19, Rocky Bernstein wrote:
> And while updating the package. zshdb 1.1.0 was released a while ago. It
> should be seamless update. 

ack



signature.asc
Description: OpenPGP digital signature

Bug#951028: i3blocks: please package upstream's new version

[Alexandre Viau]

Package: i3blocks
Severity: wishlist

Hello,

i3blocks 1.5 was released, it would be great to upload it to Debian!

Cheers,

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

Bug#951020: zshdb: build-depends on emacs25

[Rocky Bernstein]

And while updating the package. zshdb 1.1.0 was released a while ago. It
should be seamless update.

On Sun, Feb 9, 2020 at 4:15 PM Ralf Treinen  wrote:

> Source: zshdb
> Version: 0.92-3
> User: trei...@debian.org
> Usertags: edos-uninstallable
> Severity: serious
>
> Hi,
>
> zshdb build-depends on emacs25, which was removed from sid.
>
> -Ralf
>
>

Bug#951027: RFP: r-cran-glmm -- Generalized Linear Mixed Models via Monte Carlo Likelihood Approximation

[Alessandro Barbieri]

Package: wnpp
Severity: wishlist

* Package name: r-cran-glmm
  Version : 1.3.0
  Upstream Author : Christina Knudson 
* URL : https://cran.r-project.org/package=glmm
* License : GPL-2
  Programming Lang: R
  Description : Generalized Linear Mixed Models via Monte Carlo Likelihood 
Approximation

Approximates the likelihood of a generalized linear mixed model using Monte 
Carlo likelihood approximation. Then maximizes the likelihood approximation to 
return maximum likelihood estimates, observed Fisher information, and other 
model information.

Bug#951026: cssh: doesn't cope with wildcard included files in .ssh/config

[Richard Hector]

Package: clusterssh
Version: 4.13.2-2
Severity: normal
Tags: upstream

Dear Maintainer,

My .ssh/config contains a single line:
Include config.d/*

config.d then naturally contains all my actual config files.

read_ssh_file appears not to cope with this, and I get this:

richard@zircon:~$ cssh sapphire
Opening to: sapphire
Use of uninitialized value $filename in hash element at 
/usr/share/perl5/App/ClusterSSH/Host.pm line 55, <$ssh_config_fh> line 1.
Use of uninitialized value $filename in open at 
/usr/share/perl5/App/ClusterSSH/Host.pm line 57, <$ssh_config_fh> line 1.

Interesingly, it works if my current directory is .ssh.


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

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

Versions of packages clusterssh depends on:
ii  libexception-class-perl 1.44-1
ii  libtry-tiny-perl0.30-1
ii  libx11-protocol-other-perl  30-1
ii  libx11-protocol-perl0.56-7
ii  openssh-client  1:7.9p1-10+deb10u2
ii  perl5.28.1-6
ii  perl-tk 1:804.033-2+b3
ii  xterm   344-1

clusterssh recommends no packages.

clusterssh suggests no packages.

-- no debconf information

Bug#950589: lintian: collection/src-orig-index mishandles tarballs with whitespace in owner field

[Chris Lamb]

Niko Tyni wrote:

> I see #895175 was a similar issue and resulted in a rather complicated
> regexp in Lintian::Collect::Package for parsing tar output (commit
> a75f3edcb099bd4b8794e2ecb7fd19e129e77f03). I expect something like that
> should work here as well. Sorry about the lack of a patch.

No worries. This is actually a bit more complicated that I thought.
Unfinished patch follows (note the FIXME):

--- a/collection/src-orig-index
+++ b/collection/src-orig-index
@@ -38,7 +38,7 @@ use lib "$ENV{'LINTIAN_ROOT'}/lib";
 
 use Lintian::Collect::Dispatcher qw(create_info);
 use Lintian::Processable::Source;
-use Lintian::Util qw(internal_error sort_file_index gzip);
+use Lintian::Util qw(internal_error sort_file_index gzip $TARTVF_REGEX);
 
 use constant EMPTY => q{};
 use constant SPACE => q{ };
@@ -183,7 +183,7 @@ sub index_orig {
 # prefix.
 my $prefix;
 for my $line (@index) {
-my ($filename) = ($line =~ /^(?:\S+\s+){5}(.*)/);
+my $filename = ($line =~ $TARTVF_REGEX)[5];
 $filename =~ s,^\./+,,o;
 my ($dirname) = ($filename =~ m,^([^/]+),);
 if (defined $dirname
@@ -212,11 +212,14 @@ sub index_orig {
 # then strip the prefix and add $compname (if any)
 if ($prefix) {
 @index = map {
-if (m,^((?:\S+\s+){5})(?:\./)?\Q$prefix\E(?:/+(.*+)?|\Z),){
-my ($data, $file) = ($1, $2);
+my @line = $_ =~ $TARTVF_REGEX;
+if (@line) {
+my $file = $line[5];
+$file =~ s/^(?:\.\/)?\Q$prefix\E\/+//;
 if ($file && $file !~ m,^(?:/++)?\Z,o){
 $file = "$compname/$file" if $compname;
-"$data$file\n";
+$line[5] = $file;
+join(' ', @line) . "\n";
 } else {
 ();
 }
@@ -228,6 +231,7 @@ sub index_orig {
 # Prefix with the compname (because that is where they will be
 # unpacked to.
 @index = map {
+# FIXME: Use $TARTVF_REGEX
 s{^((?:\S++\s++){5})(?:\./)?\Q$prefix\E(?:/+)?}
 {$1$compname/}r
 } @index;
diff --git a/lib/Lintian/Info/Package.pm b/lib/Lintian/Info/Package.pm
index 91011d8c7..ebf717875 100644
--- a/lib/Lintian/Info/Package.pm
+++ b/lib/Lintian/Info/Package.pm
@@ -30,7 +30,7 @@ use Scalar::Util qw(blessed);
 use Lintian::Path;
 use Lintian::Path::FSInfo;
 use Lintian::Util
-  qw(internal_error open_gz perm2oct normalize_pkg_path dequote_name);
+  qw(internal_error open_gz perm2oct normalize_pkg_path dequote_name 
$TARTVF_REGEX);
 
 use Moo::Role;
 use namespace::clean;
@@ -286,14 +286,7 @@ sub _fetch_index_data {
 my (%file, $perm, $operm, $ownership, $name, $raw_type, $size);
 my ($date, $time);
 
-# Parse line from output of "tar -tvf" allowing for spaces within the
-# ownership field whilst still allowing spaces in filenames. (#895175)
-#
-# Note this cannot ever be 100% reliable as the filename might contain
-# "fake" dates.
-($perm,$ownership,$size,$date,$time,$name)
-  = $line
-  =~ /^(.{10}) (.*?) (\d+) ([-\d]{10}) (?:([:\d]{5,8}(?:.\d+)?)[ 
]+)?(.*)$/;
+($perm,$ownership,$size,$date,$time,$name) = $line =~ $TARTVF_REGEX;
 croak "cannot parse tar output from $index: \"$line\""
   unless defined $perm;
 $ownership =~ s/\s+$//;
diff --git a/lib/Lintian/Util.pm b/lib/Lintian/Util.pm
index 2487f5af7..84cab8135 100644
--- a/lib/Lintian/Util.pm
+++ b/lib/Lintian/Util.pm
@@ -85,6 +85,7 @@ BEGIN {
   $PKGNAME_REGEX
   $PKGREPACK_REGEX
   $PKGVERSION_REGEX
+  $TARTVF_REGEX
 ));
 }
 
@@ -165,6 +166,19 @@ our $PKGVERSION_REGEX = qr/
  (?: - [0-9A-Za-z.+:~]+ )*   # Optional debian revision (+ 
upstreams versions with hyphens)
   /xoa;
 

§


Regards,

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

Bug#951025: [pkg-gnupg-maint] Bug#951025: gnupg: GPG tries to get passphrase from wrong place

[Werner Koch]

> my passphrase on my desktop XFCE session. However, I am not at that
> computer, so I cannot provide it with a passphrase.

After having logged into the other box with ssh -X, run in that ssh
session:

  gpg-connect-agent updatestartuptty /bye

This tells gpg-agent on which DISPLAY or tty it should pop up the
pinentry.  In contrast to gpg ssh and the ssh-agent protocol have no way
to convey the DISPLAY and other envvars to gpg-agent, thus you need to
tell it manually.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#951025: gnupg: GPG tries to get passphrase from wrong place

[Matthew Wakeling]

Package: gnupg
Version: 2.1.18-8~deb9u4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I am logged into an XFCE session on my desktop computer, and that session is 
locked. I am now working on my laptop, which is at a remote location from my 
desktop computer, and I am logged into my desktop computer using ssh, without X 
forwarding.

When I try to unlock a private key using GPG on the ssh session, it contacts 
the gpg-agent program, which pops up a requester window for my passphrase on my 
desktop XFCE session. However, I am not at that computer, so I cannot provide 
it with a passphrase.

This makes it impossible for me to unlock the private key, without travelling 
to my desktop computer.

This has only become a problem since I upgraded my desktop computer from jessie 
to stretch, and therefore from gnupg1 to gnupg2.

The problem is that passphrase prompts now are centrally controlled, which 
fundamentally breaks the way that computers are used - you log in from various 
different places. The passphrase prompt must go to the session that caused the 
passphrase to be needed. Any other action is completely insane.

I note that it is not even possible to give gnupg2 an option to tell it not to 
use an agent.

I am justifying the severity marking of this bug report, because it does 
prevent gnupg working correctly in the majority of its use cases. If there is a 
nice simple on/off switch that makes it behave sanely that I have missed, then 
please downgrade the severity and document it.


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

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

Versions of packages gnupg depends on:
ii  gnupg-agent2.1.18-8~deb9u4
ii  libassuan0 2.4.3-2
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.24-11+deb9u4
ii  libgcrypt201.7.6-2+deb9u3
ii  libgpg-error0  1.26-2
ii  libksba8   1.3.5-2
ii  libreadline7   7.0-3
ii  libsqlite3-0   3.16.2-5+deb9u1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages gnupg recommends:
ii  dirmngr 2.1.18-8~deb9u4
ii  gnupg-l10n  2.1.18-8~deb9u4

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

-- no debconf information

Bug#675122: iceweasel: Mibbit.com is being used as a "handler service" for IRC links.

[Olly Betts]

Control: reassign -1 firefox
Control: found -1 72.0.1-1

On Tue, May 29, 2012 at 11:45:15PM +0100, Andrew Wigglesworth wrote:
>* What led up to the situation?
> 
> I clicked on an "IRC link". ie. a irc:// style link.
> 
>* What was the outcome of this action?
> 
> I was offered use of a proprietary, secret code, "software as a
> service" service for IRC called Mibbit ar Mibbit.com.

This is still the case in the current firefox package.

> It is also a service permanently banned at Freenode. See:  
> http://blog.freenode.net/2009/06/new-freenode-webchat-and-why-to-use-it/

This ban is still in place - if you click to use mibbit for a freenode
channel via an irc: links it fails with:

syn Connections via mibbit are no longer supported on freenode. You may 
wish to consider using http://webchat.freenode.net instead. Further information 
over at http://bit.ly/19JILF
syn KILL: syn. syn| [0] mmm, [1] (Facility Blocked)

Even ignoring concerns about promoting non-free network services, this
makes mibbit a poor default for handling irc: links.

Cheers,
Olly

Bug#930295: apt: no bash-completion rules for autopurge and reinstall

[Paulo]

On Tue, 9 Jul 2019 09:57:02 +0200 Julian Andres Klode  wrote:
> On Mon, Jun 10, 2019 at 03:42:33PM +1000, Christopher Bayliss wrote:
> > Package: apt
> > Version: 1.8.2
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > When you type 'apt autop' 'autopurge' is not completed. The same
> > applies to 'reinstall'.
> > 
> > Add to that, if you type 'apt reinstall ' you get a list of apt
> > commands not packages.
> 
> I'm not sure they should be. They are not documented options, just
> convenience shortcuts.
> 
> -- 
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer  i speak de, en
> 
> 

Dear Mainteiner,

now apt reinstall is in man page, what you think about include it in 
bash_completion/apt script?

Thanks
kretcheu
:x

Bug#934977: [Pkg-emacsen-addons] Bug#934977: verilog-mode: unbuildable in testing due to missing B-D emacs25

[Nicholas D Steeves]

user debian-emac...@lists.debian.org
usertags 934977 elpafy
thanks

Hi Kiwamu Okabe,

Are you still active in Debian?

Ralf Treinen  writes:

> it [verilog-mode] also is unbuildable in sid. -Ralf.
>

I've tagged this bug "elpafy" because conversion to dh-elpa is best
practises for team-maintained packages.  I also wonder if this will
indirectly solve #863467 ?

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#948307: openafs-modules-dkms: Compile of the module fails for kernel 5.3.15

[Benjamin Kaduk]

On Sun, Feb 09, 2020 at 09:53:26AM +, Witold Baryluk wrote:
> Package: openafs
> Followup-For: Bug #948307
> 
> Dear Maintainer,
> 
> The 1.8.5-1 fails to compile with kernel 5.3.0-2-amd64:
> 
> Setting up openafs-modules-dkms (1.8.5-1) ...
>   Loading new openafs-1.8.5 DKMS files...
>   It is likely that 4.19.0-6-amd64 belongs to a chroot's host
>   Building for 5.3.0-2-amd64
>   Building initial module for 5.3.0-2-amd64
>   Error! Bad return status for module build on kernel: 5.3.0-2-amd64 (x86_64)
>   Consult /var/lib/dkms/openafs/1.8.5/build/make.log for more information.
>   dpkg: error processing package openafs-modules-dkms (--configure):
>installed openafs-modules-dkms package post-installation script subprocess 
> returned error exit status 10

Can you post (a subset of) the dkms make.log somewhere?
As I have said previously, openafs-1.8.5-1 is working find with the
5.4.0-3-amd64 kernel for me locally.

Thanks,

Ben

Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system

[Manuel A. Fernandez Montecelo]

Hello Olek,

Em sáb., 8 de fev. de 2020 às 18:25, Olek Wojnar  escreveu:
> > I don't think taht using this package as an empty shell and a gateway to 
> > install
> > the "snap" package [1] is a valid use of the packaging system.
>
> Not only is this use listed in Policy [1] under the contrib section
> (where I'm moving the two packages I've done this with, pending NEW) but
> a number of other packages (in contrib) do exactly the same thing. Flash
> [2] being the obvious example. I'd also like to point out that I asked
> about this course of action back in December [3] and no one raised any
> concerns. So it's a little frustrating that after I've done all the work
> to convert the packages I'm now getting feedback saying I shouldn't have
> done it.

I am sorry that you made the work and noone told you about this.
Maybe I am in the minority and most people don't see it this way,
don't know.

I simply stumbled upon the package by chance, and I didn't have time
to follow mailing lists regularly in the last months, and I think that
I haven't read debian-games for years.


But to the point about the installation of snaps and "flash", as far
as I see it, there are two fundamental differences:

1) For flash, and I guess that most packages of contrib, the items
that are download are checksummed [1], so we know what the script
installs, and we have to manually approve new versions.  If the
download is known to be compromised, users will not install new
versions (and we can do removal of existing versions in some cases, if
we only find that it's a security problem after users install it, at
least in some cases).

  
[1]https://sources.debian.org/src/flashplugin-nonfree/1:3.7/update-flashplugin-nonfree/

This does not happen with the installation of these snaps, as far as I
can see -- it will take whatever is there, the latest version, no
checksumming or pinning to known-good versions, and there's no
guarantee that if tomorrow someone takes over that package and
installs malware, that users installing it from Debian will not use
it.  Once users install the snaps, it's completely outside of Debian's
control, I think.


2) These kind of methods are done for special packages like firmware,
very popular apps like flash (at the time), etc, or *data* packages
from games.  It's a "known evil" thing to do, still we do it because
it's somewhat needed by many users -- nowadays you can easily live
without flash, but it was not so easy in the web 10 years ago; it's
impossible to install some computers without firmware, etc.

But I don't see the need to do it with a very marginal package like
Ember.  Either people are happy to run the older version from 2016, or
if not, they would have already updated it by some means, like maybe
using themselves the snap package.

So I don't think that it's worth promoting things that are a bit
against the philosophy of Debian/traditional distros, like snaps
(adding layers of overhead and duplication, and potentially security
vulnerabilities) due to a package with very low popcon and which use
is not critical, it's just a game.


3) Aside from that, I would be more OK with it if, before installing,
there were clear indications of what's going on for people that might
be unaware of what Snaps are, and that fail to notice the change in
description of the package.

As I understand it, there's no indication that you'll install a snap
package if you just do "apt-get upgrade".  That's the part that I
think it's more troubling, that you can end up installing snap
packages without even noticing -- maybe because you happened to have
"ember" installed in the past and you wanted to check it up one time
long ago, and are not even using it very actively in the last
months/years.

If you have something like a debconf question asking users if they
want to install the snap package, or invoke snap and you decide if you
want to install it or not without the configuration of the package
failing if you reject, etc, then I think that it's much more
reasonable.


> > Otherwise, if this was an accepted practice, we could start to have many
> > packages which are just a way to install snap packages, which can easily 
> > contain
> > security vulnerabilities and install not free software, specially if the 
> > version
> > is not restricted in some way.  And this not generally expected by users of
> > Debian, IMO.
>
> This is a fair concern. However, I think that users *do* expect this of
> packages in contrib. Pabs made a good argument in a different bug report
> about this issue and convinced me. I'm going with that.

This and cyphesis are the only packages that depend on snapd, which
are not app-managers from GNOME/KDE and the like, so I don't think
that users expect it? These are among the first cases that we do
something like this, unless we do it also with flatpaks or similar and
I failed to notice (which can easily happen, I have not been very
active lately on many fronts).

For games, most of the cases that I 

Bug#925836: Your mail

[Andreas Beckmann]

Control: tags -1 - buster +  sid bullseye .

On Sun, 9 Feb 2020 17:54:03 +1300 Amos Jeffries 
wrote:
> tags 925836 - sid bullseye + buster

What's the point of tagging this bug (squid: ftbfs with GCC-9) as
affecting buster? There is no (and never will be) gcc-9 in buster, so no
need for a useless RC bug there.

Andreas

Bug#951024: dbus-cpp: Invalid Vcs-Browse field

[Boyuan Yang]

Source: dbus-cpp
Version: 5.0.1-2
Severity: normal
X-Debbugs-CC: sunwea...@debian.org

Dear dbus-cpp maintainer,

The Vcs-Browser field of dbus-cpp is currently invalid:

https://salsa.debian.org/ubports-teamdbus-cpp

Please fix it.

-- 
Thanks,
Boyuan Yang


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

Bug#951019: [Pkg-deepin-devel] Bug#951019: gsettings-qt: switch upstream to ubports

[Boyuan Yang]

Hi Mike,

在 2020-02-09日的 21:03 +，Mike Gabriel写道：
> Package: src:gsettings-qt
> Severity: wishlist
> 
> Dear maintainers of gsettings-qt,
> 
> the gsettings-qt project is virtually unmaintained on Launchpad.net  
> (LP/gsettings-qt). As it turns out, the UBports people (maintaining  
> Unity8) have actually adopted the project from Canonical and continue  
> maintenance for it.
> 
> Would it be possible to switch to gitlab.com/ubports/gsettings-qt.git  
> as upstream code location?
> 
> Furthermore, would it be an option to have this project moved over to  
> the Debian UBports Team? Or at least add the team under Uploaders:  
> field?
> 
> Thanks for any kind of feedback,
> Mike (currently working on getting the Ubuntu Touch software stack  
> into Debian)

Thanks for your work on UBports-related packaging. With current status, could
you please:

  * Request the Salsa admins to move the git repo into Debian UBports team
namespace or Debian/ namespace
  * Grant me (Salsa @byang) a Maintainer role in the moved repo
  * Replace the current team maintainer with Debian UBports Team
  * Keep current uploaders in the Uploaders: list; move the Deepin Packaging
Team into the Uploaders field
  * Switch upstream and upload new versions onto Sid

This essentially hands over the maintenance of package gsettings-qt. The
Deepin Packaging Team will keep an eye on it since all Deepin Qt apps depend
on gsettings-qt.

-- 
Thanks,
Boyuan Yang


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

Bug#951023: rainloop: build-dependency on node-jquery not satisfiable

[Ralf Treinen]

Source: rainloop
Version: 1.12.1-2
Severity: serious
User: trei...@debian.org
Usertags: edos-uninstallable

Hi,

rainloop build-depends on node-jquery (< 3.0.0). The version of
node-jquery in sid, however, is 3.4.0+dfsg-1.

-Ralf.

Bug#951022: dh-make-ruby creates debian/upstream/metadata with obsolete fields

[duck]

Package: gem2deb
Version: 1.0.4
Severity: minor


Quack,

dh-make-ruby is creating debian/upstream/metadata with obsolete fields 
Name and Contact, according to the documentation (official location 
according to DEP-12):

  https://wiki.debian.org/UpstreamMetadata#Deprecated_features

Regards.
\_o<

--
Marc Dequènes

Bug#934977: verilog-mode: unbuildable in testing due to missing B-D emacs25

[Ralf Treinen]

it also is unbuildable in sid. -Ralf.

Bug#951021: libmtp: switch to libusb-1.0 on hurd

[Pino Toscano]

Source: libmtp
Version: 1.1.17-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

libmtp has been using libusb-1.0 for many years on Linux and kFreeBSD,
still using libusb on Hurd.

Considering that libusb-1.0 has been available on Hurd for some time,
let's switch libmtp to libusb-1.0 on any architecture -- patch attached.

Thanks,
--
Pino
--- a/debian/control
+++ b/debian/control
@@ -10,8 +10,7 @@ Build-Depends: autoconf,
docbook-xsl,
doxygen,
libgcrypt20-dev,
-   libusb-1.0-0-dev [!hurd-any],
-   libusb-dev [hurd-any],
+   libusb-1.0-0-dev,
pkg-config,
xsltproc
 Standards-Version: 4.5.0
@@ -76,8 +75,7 @@ Architecture: any
 Multi-Arch: same
 Section: libdevel
 Depends: libmtp9 (= ${binary:Version}),
- libusb-1.0-0-dev [!hurd-any],
- libusb-dev [hurd-any],
+ libusb-1.0-0-dev,
  ${misc:Depends}
 Description: Media Transfer Protocol (MTP) development files
  libmtp is a library for communicating with MTP aware devices in POSIX
--- a/debian/control.in
+++ b/debian/control.in
@@ -10,8 +10,7 @@ Build-Depends: autoconf,
docbook-xsl,
doxygen,
libgcrypt20-dev,
-   libusb-1.0-0-dev [!hurd-any],
-   libusb-dev [hurd-any],
+   libusb-1.0-0-dev,
pkg-config,
xsltproc
 Standards-Version: 4.5.0
@@ -76,8 +75,7 @@ Architecture: any
 Multi-Arch: same
 Section: libdevel
 Depends: libmtp@SOVERSION@ (= ${binary:Version}),
- libusb-1.0-0-dev [!hurd-any],
- libusb-dev [hurd-any],
+ libusb-1.0-0-dev,
  ${misc:Depends}
 Description: Media Transfer Protocol (MTP) development files
  libmtp is a library for communicating with MTP aware devices in POSIX

Bug#951020: zshdb: build-depends on emacs25

[Ralf Treinen]

Source: zshdb
Version: 0.92-3
User: trei...@debian.org
Usertags: edos-uninstallable
Severity: serious

Hi,

zshdb build-depends on emacs25, which was removed from sid.

-Ralf

Bug#951019: gsettings-qt: switch upstream to ubports

[Mike Gabriel]

Package: src:gsettings-qt
Severity: wishlist

Dear maintainers of gsettings-qt,

the gsettings-qt project is virtually unmaintained on Launchpad.net  
(LP/gsettings-qt). As it turns out, the UBports people (maintaining  
Unity8) have actually adopted the project from Canonical and continue  
maintenance for it.


Would it be possible to switch to gitlab.com/ubports/gsettings-qt.git  
as upstream code location?


Furthermore, would it be an option to have this project moved over to  
the Debian UBports Team? Or at least add the team under Uploaders:  
field?


Thanks for any kind of feedback,
Mike (currently working on getting the Ubuntu Touch software stack  
into Debian)

--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpfsfNaIDpKy.pgp
Description: Digitale PGP-Signatur

Bug#950608: gmp 6.2.0 crashes postgresql-pgmp (& others)

[Steven Robbins]

On Sunday, February 9, 2020 9:54:02 A.M. CST Marco Bodrato wrote:
> Ciao,
> 
>  From
> https://ci.debian.net/data/autopkgtest/testing/arm64/libm/libmath-gmp-perl/4
> 229384/log.gz I read the following:
> 
> #   Failed test 'Test worked: $x =
> Math::GMP->new("387047");Math::GMP::probab_prime($x,25);'
> #   at t/01_gmppm.t line 192.
> #  got: '2'
> # expected: '1'
> 
> 
>  From the manual of GMP
> https://gmplib.org/manual/Number-Theoretic-Functions.html I read the
> following:
> 
> Function: int mpz_probab_prime_p (const mpz_t n, int reps)
>  Determine whether n is prime. Return 2 if n is definitely prime,
> return 1 if n is probably prime (without being certain), or return 0 if
> n is definitely non-prime.
> 
> So, if the new release of the library is able to answer that the number
> 387047 is prime, and not only "probably" prime... This should not be
> marked as a regression...

Indeed!  Thanks for investigating.  An improvement could be simply that all 
tests of this function (and any similar?) should be written to expect non-
zero, rather than superficially 1 or 2.

Is there a bug for libmath-gmp-perl for this test suite issue?

Best,
-Steve


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

Bug#951018: ITP: ruby-tty-spinner -- Library for showing a spinner icon for terminal tasks that have non-deterministic time frame

[Gabriel Filion]

Package: wnpp
Severity: wishlist
Owner: Gabriel Filion 

* Package name: ruby-tty-spinner
  Version : 0.9.3
  Upstream Author : Piotr Murach 
* URL : https://ttytoolkit.org/
* License : expat
  Programming Lang: Ruby
  Description : Library for showing a spinner icon for terminal tasks that 
have non-deterministic time frame

tty-spinner provides a selection of different text-based animations that can
be shown when the user is waiting on a task run in terminal that will end some
time that is not known in the future, or for which the completion timestamp
can only be estimated.

Those tasks will usually be waiting for some I/O, for example a download or a
task that was requested from a service that will give an answer whenever the
response is ready.


This package is currently required for packaging puppet-developement-kit
(pdk), but might be needed for other ruby-based scripts expected to run in a
terminal.

I plan on maintaining this library within the ruby team. I will ask for
sponsorship from within the team to ensure that I follow the team's policies
properly.

Bug#950916: libtool-doc: trying to overwrite '/usr/share/doc/libtool/AUTHORS', which is also in package libtool

[Sven Joachim]

Control: notfound -1 2.4.6-11
Control: found -1 2.4.6-12

On 2020-02-08 10:49 +0100, Jakub Wilk wrote:

> Package: libtool-doc
> Version: 2.4.6-11
> Severity: serious
>
> The package failed to upgrade:
>
>   Preparing to unpack .../28-libtool-doc_2.4.6-12_all.deb ...
>   Unpacking libtool-doc (2.4.6-12) over (2.4.6-11) ...
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-Kxxra4/28-libtool-doc_2.4.6-12_all.deb (--unpack):
>trying to overwrite '/usr/share/doc/libtool/AUTHORS', which is also in 
> package libtool 2.4.6-12

I have not looked at the package, but I bet this is a side effect of the
debhelper compat bump from 9 to 12, see the following note in
debhelper(7) about compat level 11:

,
|  -   The dh_installdocs and dh_installexamples tools may
|  now install most of the documentation in a different
|  path to comply with the recommendation from Debian
|  policy §12.3 (since version 3.9.7).
`

>   dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
>   ...
>   Errors were encountered while processing:
>/tmp/apt-dpkg-install-Kxxra4/28-libtool-doc_2.4.6-12_all.deb
>   E: Sub-process /usr/bin/dpkg returned an error code (1)

Here is a complete list of clashing files:

,
| # dpkg --force-overwrite -i 
/var/cache/apt/archives/libtool-doc_2.4.6-12_all.deb
| (Reading database ... 14428 files and directories currently installed.)
| Preparing to unpack .../libtool-doc_2.4.6-12_all.deb ...
| Unpacking libtool-doc (2.4.6-12) ...
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/share/doc/libtool/AUTHORS', which is 
also in package libtool 2.4.6-12
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/share/doc/libtool/NEWS.gz', which is 
also in package libtool 2.4.6-12
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/share/doc/libtool/README', which is 
also in package libtool 2.4.6-12
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/share/doc/libtool/THANKS.gz', which 
is also in package libtool 2.4.6-12
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/share/doc/libtool/TODO.gz', which is 
also in package libtool 2.4.6-12
| Setting up libtool-doc (2.4.6-12) ...
`

Cheers,
   Sven

Bug#951017: RM: golang-github-prometheus-tsdb -- ROM; Obsolete, integrated into prometheus main repo

[Martina Ferrari]

Package: ftp.debian.org
Severity: normal

Upstream decided to merge the tsdb repository and go package into the main
prometheus repo, and so this package is obsolete now.

It has no reverse dependencies in sid and bullseye, although it would be needed
for buster updates or stretch-bpo if an update were to be performed there, I am
not sure if that warrants keeping the package around.

Thanks.

Bug#951013: tlp: description of configuration order misleading or order wrong

[Raphaël Halimi]

Le 09/02/2020 à 20:42, Norbert Preining a écrit :
> If this is true, local configurations as suggested in /etc/tlp.d/*.conf
> will **NOT** override the Debian /etc/tlp.conf.
> 
> Is this intended?

Yes, it is.

I had this discussion with upstream during the beta phase and he was
adamant on the fact that /etc/tlp.conf must have priority over
everything else.

The default /etc/tlp.conf has every setting commented, hence the advice
to make changes to the configuration only through /etc/tlp.d/*.conf.

Since English is not my native language, I may have missed something
here. Is your bug report filed against the respective priorities of the
different configuration files, or against the NEWS entry itself that you
find somewhat not clear ?

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#951012: buster-kernel 5.5-armhf-seccomp: syscall 403

[Julian Andres Klode]

On Sun, Feb 09, 2020 at 08:28:13PM +0100, Marc Haber wrote:
> Package: apt
> Version: 1.8.2
> Severity: minor
> 
> [severity minor because it's a rather exotic case that needs non-default
> configuration, a non-Debian kernel and a non-mainstream arch]
> 
> Hi,
> 
> I get the following message:
> | [1/4216]mh@entrada:~ $ sudo apt update
> | 0% [Working]
> |   Seccomp prevented execution of syscall 000403 on architecture 
> armhf 
> | Reading package lists... Done
> | E: Method http has died unexpectedly!
> | E: Sub-process http returned an error code (31)
> | 100 [2/4217]mh@entrada:~ $ 
> 
> if:
> 
> - buster is installed
> - the system has arch armhf (here: a Banana Pi)
> - a 5.5 kernel is in use (not yet in Debian sid, so locally compiled)
> - seccomp in apt is enabled
> 
> sid seems to work fine in this situation.

I looked into this, this is is new time64 syscall, I'll be going ahead
and whitelist all new time64 syscalls in 1.9.10.

403: clock_gettime64
404: clock_settime64
405: clock_adjtime64
406: clock_getres_time64
407: clock_nanosleep_time64
408: timer_gettime64
409: timer_settime64
410: timerfd_gettime64
411: timerfd_settime64
412: utimensat_time64
413: pselect6_time64
414: ppoll_time64

Of course, feel free to whitelist them in your apt.conf, by setting

APT::Sandbox::Seccomp::Allow { "clock_gettime64";  }

as I don't think this will get cherry-picked into stable releases.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#951016: strongswan FTBFS: missing build-depends libiptc-dev

[Helmut Grohne]

Source: strongswan
Version: 5.8.2-1
Severity: serious
Tags: ftbfs

strongswan fails to build from source in unstable, because it misses a
build dependency on libiptc-dev. The library was formerly pulled by
"something" and no longer is. The build now fails:

| checking for libiptc... no
| configure: error: Package requirements (libiptc) were not met:
| 
| No package 'libiptc' found
| 
| Consider adjusting the PKG_CONFIG_PATH environment variable if you
| installed software in a non-standard prefix.
| 
| Alternatively, you may set the environment variables libiptc_CFLAGS
| and libiptc_LIBS to avoid the need to call pkg-config.
| See the pkg-config man page for more details.
|  tail -v -n \+0 config.log

Helmut

Bug#951015: tinyirc FTCBFS: forces a build architecture CC

[Helmut Grohne]

Source: tinyirc
Version: 1:1.1.dfsg.1-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

tinyirc fails to cross build from source, because debian rules passes a
build architecture compiler to make. Instead, using dh_auto_build would
pass proper tools. Please consider applying the attached patch.

Helmut
diff --minimal -Nru tinyirc-1.1.dfsg.1/debian/changelog 
tinyirc-1.1.dfsg.1/debian/changelog
--- tinyirc-1.1.dfsg.1/debian/changelog 2012-08-22 15:26:30.0 +0200
+++ tinyirc-1.1.dfsg.1/debian/changelog 2020-02-09 20:27:53.0 +0100
@@ -1,3 +1,11 @@
+tinyirc (1:1.1.dfsg.1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make and stop
+overriding CC. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 09 Feb 2020 20:27:53 +0100
+
 tinyirc (1:1.1.dfsg.1-3) unstable; urgency=low
 
   * New maintainer (Closes: #660510).
diff --minimal -Nru tinyirc-1.1.dfsg.1/debian/rules 
tinyirc-1.1.dfsg.1/debian/rules
--- tinyirc-1.1.dfsg.1/debian/rules 2012-08-17 15:23:29.0 +0200
+++ tinyirc-1.1.dfsg.1/debian/rules 2020-02-09 20:27:51.0 +0100
@@ -17,8 +17,8 @@
-g tinyirc.c -o tinyirc -lncurses
 
 override_dh_auto_build: man
-   $(MAKE) tinyirc \
-   CC='gcc' \
+   dh_auto_build -- \
+   tinyirc \
CFLAGS='$(CPPFLAGS) $(CFLAGS) $(LDFLAGS)' \
LIBS='-lncurses' \
DEFINES='-DPOSIX -DDEFAULTSERVER=\"irc.freenode.org\" 
-DDEFAULTPORT=6667'

Bug#951013: tlp: description of configuration order misleading or order wrong

[Norbert Preining]

Package: tlp
Version: 1.2.2-1
Severity: important

Hi,

thanks for your work on tlp, much appreciating laptop user here.

One thing that bothered/surprised me with the update to 1.3.0 is the
NEWS entry:

  Settings are read in this order:

  - /usr/share/tlp/defaults.conf (intrinsic defaults)
  - /etc/tlp.d/*.conf (drop-in customizations)
  - /etc/tlp.conf (user configuration)

  In case of identical parameters, the last occurrence has precedence.

If this is true, local configurations as suggested in /etc/tlp.d/*.conf
will **NOT** override the Debian /etc/tlp.conf.

Is this intended?

Thanks

Norbert


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

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

Versions of packages tlp depends on:
ii  hdparm  9.58+ds-4
ii  iw  5.4-1
ii  lsb-base11.1.0
ii  pciutils1:3.6.4-1
ii  rfkill  2.34-0.1
ii  usbutils1:012-2
ii  wireless-tools  30~pre9-13+b1

Versions of packages tlp recommends:
ii  ethtool  1:5.4-1
ii  tlp-rdw  1.2.2-1

Versions of packages tlp suggests:
ii  acpi-call-dkms  1.1.0-5
ii  linux-cpupower  5.4.13-1
ii  smartmontools   7.1-1
pn  tp-smapi-dkms   

-- Configuration Files:
/etc/default/tlp changed [not included]

-- no debconf information

Bug#951012: buster-kernel 5.5-armhf-seccomp: syscall 403

[Marc Haber]

Package: apt
Version: 1.8.2
Severity: minor

[severity minor because it's a rather exotic case that needs non-default
configuration, a non-Debian kernel and a non-mainstream arch]

Hi,

I get the following message:
| [1/4216]mh@entrada:~ $ sudo apt update
| 0% [Working]
|   Seccomp prevented execution of syscall 000403 on architecture armhf 

| Reading package lists... Done
| E: Method http has died unexpectedly!
| E: Sub-process http returned an error code (31)
| 100 [2/4217]mh@entrada:~ $ 

if:

- buster is installed
- the system has arch armhf (here: a Banana Pi)
- a 5.5 kernel is in use (not yet in Debian sid, so locally compiled)
- seccomp in apt is enabled

sid seems to work fine in this situation.

Greetings
Marc

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "armhf";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "false";
APT::Install-Suggests "false";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Sandbox::seccomp "true";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-image-5\.5\.2-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-headers-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-headers-5\.5\.2-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-image-extra-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-image-extra-5\.5\.2-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-modules-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-modules-5\.5\.2-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-modules-extra-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-modules-extra-5\.5\.2-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-signed-image-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-signed-image-5\.5\.2-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-image-unsigned-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-image-unsigned-5\.5\.2-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^kfreebsd-image-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^kfreebsd-image-5\.5\.2-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^kfreebsd-headers-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^kfreebsd-headers-5\.5\.2-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^gnumach-image-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^gnumach-image-5\.5\.2-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^.*-modules-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^.*-modules-5\.5\.2-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^.*-kernel-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^.*-kernel-5\.5\.2-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-5\.5\.2-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-modules-.*-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-modules-.*-5\.5\.2-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-tools-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-tools-5\.5\.2-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-cloud-tools-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-cloud-tools-5\.5\.2-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-buildinfo-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-buildinfo-5\.5\.2-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-source-5\.5\.1-zgbpi-armmp-lpae$";
APT::NeverAutoRemove:: "^linux-source-5\.5\.2-zgbpi-armmp-lpae$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-modules";
APT::VersionedKernelPackages:: "linux-modules-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "linux-image-unsigned";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::VersionedKernelPackages:: "linux-cloud-tools";
APT::VersionedKernelPackages:: "linux-buildinfo";
APT::VersionedKernelPackages:: "linux-source";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";

Bug#950993: orage: calendar window doesn't work anymore

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2020-02-09 at 19:01 +, B wrote:
> > Ok. Can you run it throught gdb and when it crashes, run bt full and
> > copy the output?
> 
> I don't know how to do that, could you explain it?

Try to follow those instructions: https://wiki.xfce.org/howto/debug

You might have to install debug packages for the relevant binary packages (so
orage-dbgsym, as well as the various library involved).

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl5AXbEACgkQ3rYcyPpX
RFvHOgf/aqD8xmjlk2BbXwox1q6STdshsLpDBko1fMMa9c9WcNDOWspuZ3AuDgAA
zrG59LJ0JmXWww8cXGWjBUCX7FKrM8xyH1fcN0b162LKxrXK/rbl2ZvHzh2+N5MB
gXWD2/8g8uciRGXCgU+JQDDS+b/iET7OmYfcPqncXbnOJ9XTZaDdHCcivThOzsDT
8jh76WPLx762Hnz9ELy72Rs9+GjsAUC1PG3tBzQ9bY5dO7vRqSKffn1F7mogqbRV
ExnHrnHQhE0/cNINgxnQw3sM7GZ7mldh4yxSq3TlTum4F5xFCglkyTEd0nwa2iXA
JGQr4wVzLd5i/pdflHrFZC73NUUgQQ==
=DA4j
-END PGP SIGNATURE-

Bug#948834: glib2.0: FTBFS: SIGABRT in gsocketclient-slow test

[Simon McVittie]

Control: retitle -1 glib2.0: FTBFS: gio/tests/gsocketclient-slow.c: Error 
resolving ?localhost?: Name or service not known

On Sun, 09 Feb 2020 at 16:45:05 +0100, Mattia Rizzolo wrote:
> I see glib2.0 is also failing in the r-b infra:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/glib2.0.html
> 
> Could you perhaps check that build log?  It's likely equivalent.

# GLib-GIO-DEBUG: IPv6 DNS error: Error resolving ?localhost?: Name or service 
not known
# GLib-GIO-DEBUG: IPv4 DNS error: Error resolving ?localhost?: Name or service 
not known
**
GLib-GIO:ERROR:../../../gio/tests/gsocketclient-slow.c:30:on_connected: 
assertion failed (error == NULL): Error resolving ?localhost?: Name or service 
not known (g-resolver-error-quark, 0)

I personally think this is a pbuilder bug (see also
). The fact that
"localhost" resolves to 127.0.0.1 and/or ::1 is part of the "OS API",
and I think packages' tests should be entitled to assume that this will
happen, without needing to take special steps to achieve it.

According to #897662 this used to work - has it regressed?

We can't work around this by substituting 127.0.0.1 (as I did in dbus)
because the "happy eyeballs" algorithm that GLib is testing here includes
name resolution.

We could probably work around this in glib2.0 with a Build-Depends on
libnss-myhostname | netbase, or the other way round.

Related to 
(which is about whether the name in /etc/hostname resolves to a local
IP address, whereas this one is about whether localhost resolves to a
local IP adddress, but installing libnss-myhostname or netbase will
usually fix both those anomalous situations).

smcv

Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)

[Sudip Mukherjee]

On Fri, Feb 7, 2020 at 7:58 PM Sudip Mukherjee
 wrote:
>
> On Fri, Feb 7, 2020 at 10:17 AM Sudip Mukherjee
>  wrote:
> >
> > On Thu, Feb 6, 2020 at 10:53 PM Christian Barcenas
> >  wrote:
> > >
> > > I just noticed that your packaging repo is currently empty.
> > > Would you be able to push your current progress to Github
> > > so that it's easier to review the source package?
> >
> > Pushed now. Its without any epoch in the version. I will add the epoch
> > and push again tonight after back from $dayjob.
>
> Also pushed in wip/epoch branch with the epoch in only binary packages
> for your review. I have not yet uploaded to mentors.

And I have now pushed to mentors the package with epoch only in the
binary packages and I hope that is the consensus here.


-- 
Regards
Sudip

Bug#950470: breezy still fails with one autopkg test on the binary-indep buid

[Jelmer Vernooij]

severity 950470 important
thanks

On Sun, Feb 02, 2020 at 10:37:41AM +0100, Matthias Klose wrote:
> see
> https://buildd.debian.org/status/fetch.php?pkg=breezy=all=3.0.2-3=1580478666=0
> 
> ==
> ERROR:
> breezy.tests.per_branch.test_stacking.TestStackingConnections.test_open_stacked_relative(RemoteBranchFormat-v2)
> --
> Traceback (most recent call last):
> testtools.testresult.real._StringException: lost connection during test
> 'breezy.tests.per_branch.test_stacking.TestStackingConnections.test_open_stacked_relative(RemoteBranchFormat-v2)'
> --
> Ran 24171 tests in 6121.269s

I'm going to downgrade the importance of this since the buildds are
happy with the last build.

My suspicion is that there are still some flaky tests, but these
weren't recently introduced so this is not a regression. I'll keep
chasing them down; in the mean time, I think this should not be a
blocker for Breezy 3.0.2-4 migrating to testing.

Cheers,

Jelmer


signature.asc
Description: PGP signature

Bug#951011: RFS: tupi/0.2+git08-2 [QA] [RC] -- 2D Animation design and authoring tool

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: tupi
   Version : 0.2+git08-2
   Upstream Author : Gustav Gonzalez 
 * URL : http://www.maefloresta.com/portal
 * License : GPL-2+
 * Vcs : None
   Section : graphics

It builds those binary packages:

  tupi - 2D Animation design and authoring tool
  tupi-data - Data files for tupi (2D Animation design and authoring tool)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/tupi/tupi_0.2+git08-2.dsc

Changes since the last upload:

   * QA upload.
   * Remove non-salsa Vcs link
   * Update compat level to 12
   * Update Standards-Version to 4.5.0
   * Orphan the package. (See: #885983)
   * Fix ftbfs. (Closes: #873023)

Note:
It has some lintian warnings and I am particlulary puzzled by the one
where it says ldd could not find dependency information of
libtupidebug.so. I checked manually and information was there after
dh_auto_build. Can it be dh_strip?
I guess these warnings can be fixed later and also others can help if
this is uploaded with the rc bug fixed. I have installed this on a vm
and tested that it works.


-- 
Regards
Sudip

Bug#951010: signify and signify-openbsd names

[iandeb]

Package: signify
Version: 1.14-3

Package: signify-openbsd
Version: 28-1

The signify package is inactive since 2003

https://sourceforge.net/projects/signify

Maintaining this package with the current name prevents another software with 
the same name to be distributed with the name it's known for everywhere, 
forcing it to be renamed into 'signify-openbsd' in Debian.

signify should be renamed (signify-mail for example) and signify-openbsd should 
be renamed to signify in order to avoid confusion as signify-openbsd is widely 
used and known simply as signify everywhere else.

Bug#931574: nftables: kernel BUG at lib/list_debug.c:53

[Tim Düsterhus]

I tried once again with Debian 10.3 and thus Linux 4.19.98. I am no
longer seeing the issue. I did a test upgrade in a copy of the cloud VM
and after that worked I upgraded the original production machine as well.

I believe this bug can be closed, thanks.

> root@bastiodon ~ # dpkg -l |egrep 'nftables|zfs-|linux-image|apparmor'
> ii  libapparmor1:amd64 2.13.2-10amd64
> changehat AppArmor library
> ii  libnftables0:amd64 0.9.0-2  amd64
> Netfilter nftables high level userspace API library
> ii  libnftnl11:amd64   1.1.2-2  amd64
> Netfilter nftables userspace API library
> ii  linux-image-4.19.0-8-amd64 4.19.98-1amd64
> Linux 4.19 for 64-bit PCs (signed)
> ii  linux-image-4.9.0-12-amd64 4.9.210-1amd64
> Linux 4.9 for 64-bit PCs
> ii  linux-image-amd64  4.19+105+deb10u3 amd64
> Linux for 64-bit PCs (meta-package)
> ii  nftables   0.9.0-2  amd64
> Program to control packet filtering rules by Netfilter project
> ii  zfs-dkms   0.7.12-2+deb10u1 all  
> OpenZFS filesystem kernel modules for Linux
> ii  zfs-initramfs  0.7.12-2+deb10u1 all  
> OpenZFS root filesystem capabilities for Linux - initramfs
> ii  zfs-zed0.7.12-2+deb10u1 amd64
> OpenZFS Event Daemon

Best regards
Tim Düsterhus

Bug#950993: orage: calendar window doesn't work anymore

[Bzzzz]

On Sun, 09 Feb 2020 18:21:11 +0100
Yves-Alexis Perez  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Sun, 2020-02-09 at 16:57 +, B wrote:
> > > I tried on my own Buster installation but I can't reproduce your
> > > problem. I installed Orage and it worked just fine here (either the
> > > plugin or running from command line).
> >
> > Ra ! :/
> > Could it be something coming from xfce configuration files?
> > (although, if they come from squeeze, most of them have been updated
> > or suppressed.)
>
> I'd find it unlikely. You might want to try with a fresh user, just in
> case.

Just tried, it works ferpectly :/

> > > When you run orage from command line, what is displayed on the
> > > terminal?
> >
> > The calendar window opens (borders, frame and background) for ~500
> > ms, then disappear.
> >
> > > Is the process stuck or does it returns?
> >
> > It returns with that:
> >
> > $ orage
> > ** Message: 16:45:12.883: Orage **: 16:45:12  wakeup timer init 0
> > Segmentation fault
>
> Ok. Can you run it throught gdb and when it crashes, run bt full and
> copy the output?

I don't know how to do that, could you explain it?

> > > If you run through strace, does it outputs anything meaningful?
> >
> > No for me, but I manager to make a log file (with: strace orage >
> > orage_strace.log 2>&1), I join it as an attachement.
> >
> I'll take a look.

Bug#951009: vdr-plugin-epgsearch: starting vdr with vdr-plugin-epgsearch installed gives a segfault

[Bernd Schumacher]

Package: vdr-plugin-epgsearch
Severity: grave
Justification: renders package unusable

Dear Maintainer,

after upgrading debian buster and after checking for timer conflicts
with GUI: xlineliboutput-sxfe vdr became unstartable.

Syslog says:

Feb  9 18:14:18 tvx11-buster vdr: [9570] EPGSearch: timer conflict check started
Feb  9 18:14:18 tvx11-buster kernel: [  537.987061] EPGSearch: conf[9570]: 
segfault at 130 ip 7f8450160f75 sp 7f843f7fda50 error 4 in 
libvdr-epgsearch.so.2.4.0[7f845011+fc000]
Feb  9 18:14:18 tvx11-buster kernel: [  537.987074] Code: 0f 84 d9 00 00 00 49 
89 c4 48 8b 45 80 48 89 85 78 ff ff ff 90 49 8b 44 24 20 48 85 c0 74 22 48 8b 
95 78 ff ff ff 48 8b 52 18 <48> 39 50 30 7e 11 48 8b bd 70 ff ff ff 49 8d 74 24 
20 e8 64 31 ff
Feb  9 18:14:18 tvx11-buster systemd[1]: vdr.service: Main process exited, 
code=killed, status=11/SEGV

Workaround:
dpkg --purge vdr-plugin-epgsearch

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

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

Versions of packages vdr-plugin-epgsearch depends on:
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libstdc++6  8.3.0-6
ii  sendemail   1.56-5
ii  vdr [vdr-abi-2.4.0-debian]  2.4.0-1+b1

vdr-plugin-epgsearch recommends no packages.

vdr-plugin-epgsearch suggests no packages.

Bug#943144: keepass2: Python2 removal in sid/bullseye

[Julian Taylor]

On 23.10.19 04:33, mo...@debian.org wrote:
> Source: keepass2
> Version: 2.43+dfsg-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


The python2 dependency cannot be removed right now as the documentation
build with the python3 compatible archmage tool does not support
building html sources from chm sources anymore.

But I have filed a patch upstream to restore the functionality.
https://github.com/dottedmag/archmage/pull/17

I'll wait a bit for an upstream answer before proceeding further.

Bug#951008: gem2deb: dh-make-ruby generates insecure URLs

[duck]

Package: gem2deb
Version: 1.0.4
Severity: important


Quack,

When updating a package with the recently updated "new-upstream" script 
it calls dh-make-ruby. This results in the Homepage URL in 
debian/control to switch to insecure, and the newly generated 
debian/upstream/metadata file to contains insecure URLs.


Calling the script without --offline does not change anything (it might 
have tested available URLs).


Anyway, I think nowadays insecure URLs are exceptions and our tools must 
default to using HTTPS (and the maintainer can override if there is no 
other way to reach upstream's website).


Regards.
\_o<

--
Marc Dequènes

Bug#950842:

[Liubov Chuprikova]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/qiime2/qiime2/issues/520

Bug#950221: Taking over natsort into Debian Python Modules Team (Was: natsort 6.0 doesn't support Python 3.8)

[Agustin Henze]

Hi Andreas,

On 2/9/20 8:22 AM, Andreas Tille wrote:
[snip] > If you either give me permissions or transfer the project
according > to > > https://docs.gitlab.com/ee/user/project/settings/ > >
Navigate to your project’s Settings > General > Advanced settings. >
Under “Transfer project”, choose the namespace you want to transfer >
the project to. Confirm the transfer by typing the project’s path as >
instructed. > > to > > python-team/modules > > this would be a clean
move which forwards users of the old Salsa URL > to the new one.

Thanks for the explanation :), sadly it seems I am not the owner. It
happens to be the gitlab administrator judging by the member list.

Not sure what would be the more convenient way to solve this :/. Raising
an issue in salsa support https://salsa.debian.org/salsa/support/ may be...

Cheers,

-- 
TiN

Bug#951007: gradle: please update gradle-javascript for libsimple-http-java 6.0.1

[tony mancill]

Source: gradle
Severity: wishlist

This bug is for coordination/tracking...  Sudip Mukherjee has been kind
enough to update simple-http to modern version that has been uploaded to
experimental.  Now we need to update gradle-javascript to be able to
find simple.jar.

The full stack trace is:

* Exception is:
org.gradle.internal.service.ServiceCreationException: Could not create service 
of type ClassLoaderRegistry using 
GlobalScopeServices.createClassLoaderRegistry().
at 
org.gradle.internal.service.DefaultServiceRegistry$FactoryMethodService.invokeMethod(DefaultServiceRegistry.java:797)
at 
org.gradle.internal.service.DefaultServiceRegistry$FactoryService.create(DefaultServiceRegistry.java:748)
at 
org.gradle.internal.service.DefaultServiceRegistry$ManagedObjectProvider.getInstance(DefaultServiceRegistry.java:574)
at 
org.gradle.internal.service.DefaultServiceRegistry$SingletonService.get(DefaultServiceRegistry.java:623)
at 
org.gradle.internal.service.DefaultServiceRegistry.applyConfigureMethod(DefaultServiceRegistry.java:199)
at 
org.gradle.internal.service.DefaultServiceRegistry.findProviderMethods(DefaultServiceRegistry.java:180)
at 
org.gradle.internal.service.DefaultServiceRegistry.addProvider(DefaultServiceRegistry.java:255)
at 
org.gradle.internal.service.ServiceRegistryBuilder.build(ServiceRegistryBuilder.java:52)
at 
org.gradle.launcher.cli.BuildActionsFactory.runBuildInProcess(BuildActionsFactory.java:129)
at 
org.gradle.launcher.cli.BuildActionsFactory.createAction(BuildActionsFactory.java:90)
at 
org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.createAction(CommandLineActionFactory.java:296)
at 
org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:286)
at 
org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:264)
at 
org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:33)
at 
org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24)
at 
org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
at 
org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
at 
org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:257)
at 
org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:191)
at org.gradle.launcher.Main.doAction(Main.java:33)
at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:60)
at 
org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:37)
at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
Caused by: java.lang.IllegalArgumentException: Cannot find JAR 'simple.jar' 
required by module 'gradle-javascript' using classpath or distribution 
directory '/usr/share/gradle'
at 
org.gradle.api.internal.classpath.DefaultModuleRegistry.findDependencyJar(DefaultModuleRegistry.java:262)
at 
org.gradle.api.internal.classpath.DefaultModuleRegistry.findDependencyJars(DefaultModuleRegistry.java:152)
at 
org.gradle.api.internal.classpath.DefaultModuleRegistry.module(DefaultModuleRegistry.java:142)
at 
org.gradle.api.internal.classpath.DefaultModuleRegistry.loadOptionalModule(DefaultModuleRegistry.java:122)
at 
org.gradle.api.internal.classpath.DefaultModuleRegistry.loadModule(DefaultModuleRegistry.java:106)
at 
org.gradle.api.internal.classpath.DefaultModuleRegistry.getModule(DefaultModuleRegistry.java:86)
at 
org.gradle.api.internal.classpath.DefaultPluginModuleRegistry.loadModules(DefaultPluginModuleRegistry.java:50)
at 
org.gradle.api.internal.classpath.DefaultPluginModuleRegistry.getApiModules(DefaultPluginModuleRegistry.java:37)
at 
org.gradle.api.internal.DynamicModulesClassPathProvider.findClassPath(DynamicModulesClassPathProvider.java:48)
at 
org.gradle.api.internal.DefaultClassPathRegistry.getClassPath(DefaultClassPathRegistry.java:34)
at 
org.gradle.initialization.DefaultClassLoaderRegistry.(DefaultClassLoaderRegistry.java:31)
at 
org.gradle.internal.service.scopes.GlobalScopeServices.createClassLoaderRegistry(GlobalScopeServices.java:207)
at 

Bug#951006: ucf: Please load file names into environment when starting "a new shell to examine the situation" (DPKG_CONFFILE_OLD, DPKG_CONFFILE_NEW)

[Christoph Biedl]

Christoph Biedl wrote...

> The patch was really simple, attached.

Now really attached. Also, signature.
diff --git a/ucf b/ucf
index b192215..0c23e92 100755
--- a/ucf
+++ b/ucf
@@ -1084,6 +1084,8 @@ else
 # /dev/tty 

signature.asc
Description: PGP signature

Bug#925797: pushed patch to git

[olivier sallou]

I pushed to git a patch that seems to fix the undefined ref to InitGoogle...

Still need to test full build (very long...)

Olivier

Bug#951006: ucf: Please load file names into environment when starting "a new shell to examine the situation" (DPKG_CONFFILE_OLD, DPKG_CONFFILE_NEW)

[Christoph Biedl]

Package: ucf
Version: 3.0038+nmu1
Severity: wishlist
Tag: patch

Dear Maintainer,

many years ago, dpkg added a feature to preload some environment
variables with the names of the files that are conflicting. This allows
helper tool to aid the administrator in resolving.

Please add a similar feature to ucf, and use the same environment
variable names for obvious reasons.

The patch was really simple, attached.

Christoph

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

Kernel: Linux 5.4.18 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages ucf depends on:
ii  coreutils   8.30-3+b1
ii  debconf 1.5.73
ii  sensible-utils  0.0.12+nmu1

ucf recommends no packages.

ucf suggests no packages.

-- debconf information excluded

Bug#951005: apt-cacher-ng: Missing ftp2.fr.debian.org in deb_mirrors list

[Dominique]

Package: apt-cacher-ng
Version: 3.3.1-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?
I've noticed that some packages were not cache due to different apt 
configuration:

$ grep calibre_4.99.4+dfsg+really4.10.0+py3-2_all.deb 
/var/log/apt-cacher-ng/apt-cacher.log 
1581246487|I|24113764|192.168.0.2|ftp2.fr.debian.org/debian/pool/main/c/calibre/calibre_4.99.4+dfsg+really4.10.0+py3-2_all.deb
1581246487|O|24113835|192.168.0.2|ftp2.fr.debian.org/debian/pool/main/c/calibre/calibre_4.99.4+dfsg+really4.10.0+py3-2_all.deb
1581267436|I|24113764|192.168.0.15|debrep/pool/main/c/calibre/calibre_4.99.4+dfsg+really4.10.0+py3-2_all.deb
1581267436|O|24113835|192.168.0.15|debrep/pool/main/c/calibre/calibre_4.99.4+dfsg+really4.10.0+py3-2_all.deb

It turns out that ftp2.fr repo is not listed in deb_mirror:

$ zgrep ftp2 deb_mirrors.gz 
http://ftp2.ca.debian.org/debian/
http://ftp2.cn.debian.org/debian/
http://ftp2.de.debian.org/debian/

Coudl you add http://ftp2.fr.debian.org/debian/ in deb_mirrors list ?

All the best

Dod


-- Package-specific info:

-- System Information:
Debian Release: bullseye/sid
Architecture: armhf (armv7l)

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

Versions of packages apt-cacher-ng depends on:
ii  adduser  3.118
ii  debconf [debconf-2.0]1.5.73
ii  dpkg 1.19.7
ii  libbz2-1.0   1.0.8-2
ii  libc62.29-10
ii  libevent-2.1-7   2.1.11-stable-1
ii  libevent-pthreads-2.1-7  2.1.11-stable-1
ii  libgcc-s1 [libgcc1]  10-20200202-1
ii  libgcc1  1:10-20200202-1
ii  liblzma5 5.2.4-1+b1
ii  libssl1.11.1.1d-2
ii  libstdc++6   10-20200202-1
ii  libsystemd0  244.1-3
ii  libwrap0 7.6.q-30
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-1.2

Versions of packages apt-cacher-ng recommends:
ii  ca-certificates  20190110

Versions of packages apt-cacher-ng suggests:
pn  avahi-daemon  
pn  doc-base  
pn  libfuse2  

-- Configuration Files:
/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: 
'/etc/apt-cacher-ng/security.conf'

-- debconf information:
  apt-cacher-ng/port: keep
* apt-cacher-ng/tunnelenable: true
  apt-cacher-ng/proxy: keep
  apt-cacher-ng/gentargetmode: No automated setup
  apt-cacher-ng/bindaddress: keep
  apt-cacher-ng/cachedir: keep

Bug#950993: orage: calendar window doesn't work anymore

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2020-02-09 at 16:57 +, B wrote:
> > I tried on my own Buster installation but I can't reproduce your
> > problem. I installed Orage and it worked just fine here (either the
> > plugin or running from command line).
> 
> Ra ! :/
> Could it be something coming from xfce configuration files? (although,
> if they come from squeeze, most of them have been updated or suppressed.)

I'd find it unlikely. You might want to try with a fresh user, just in case.
> 
> > When you run orage from command line, what is displayed on the
> > terminal?
> 
> The calendar window opens (borders, frame and background) for ~500 ms,
> then disappear.
> 
> > Is the process stuck or does it returns?
> 
> It returns with that:
> 
> $ orage
> ** Message: 16:45:12.883: Orage **: 16:45:12  wakeup timer init 0
> Segmentation fault

Ok. Can you run it throught gdb and when it crashes, run bt full and copy the
output?
> 
> > If you run through strace, does it outputs anything meaningful?
> 
> No for me, but I manager to make a log file (with: strace orage >
> orage_strace.log 2>&1), I join it as an attachement.
> 
I'll take a look.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl5AP4cACgkQ3rYcyPpX
RFsAogf/TGTYtP4R1qBSLjZbuLgbbCaMbZ45lvC3+sAjPfQPTHj+CCJ2IZenTTiN
N9wzdzHALec6jdXG14KIk+/ehY3+t3E0cu0cQK+DJS/5hpwnIBKtVmrQMbr9Iv1u
4XGaeJi8d76vaKS3+7HtabX2+PbtrlI32vvXch9sF3WEy2YPTkFON6DDyInXIt8p
44AFtDpDGx2YyEZBNpNAdXI0yWzyL+R4Woh00gP7c/aosSvTKv9gwT2mZyGwrz2R
m+F7ptxjsDChf+yiK4uw0YH+I8uwGycvHS1BrEZNQEAefI6QStApkC/yYvR3fRr7
OUUO8fv/ZzeaufeDquV25Zx6fn+2eg==
=0fTL
-END PGP SIGNATURE-

Bug#951004: libmath-prime-util-gmp-perl: FTBFS with gmp 6.2.0: test failure

[gregor herrmann]

Source: libmath-prime-util-gmp-perl
Version: 0.51-1
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source (but built successfully in the past)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

libmath-prime-util-gmp-perl fails to build, apparentaly due to
changes in gmp 6.2.0:

t/50-factoring.t . 
1..164
[..]
ok 128 - squfof_factor(13)
Failed 36/164 subtests 
[..]

Test Summary Report
- ---
t/50-factoring.t   (Wstat: 11 Tests: 128 Failed: 0)
  Non-zero wait status: 11
  Parse errors: Bad plan.  You planned 164 tests but ran 128.
Files=33, Tests=3120,  5 wallclock secs ( 0.40 usr  0.08 sys +  4.36 cusr  0.40 
csys =  5.24 CPU)
Result: FAIL

Cf. also 
https://ci.debian.net/data/autopkgtest/unstable/amd64/libm/libmath-prime-util-gmp-perl/4241554/log.gz

Potential background: https://bugs.debian.org/950608#31


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl5AO6ZfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbJbw//SyO8nFSW7DoYm7OD8qnRYERiucM61OnSzlq8Ak0NmpZ/oEELidb+qS46
RDApM5DhXVuAQqVbc7KFpGOzLPQPJOP0dDTvYVNXRO7v+tE1lGTTQlPWZDPEP7Lp
i0bBTps8KD9ffnLZsZbRCqP4v4xcyPjzknJ/W6sqHjdr31YnQ/gLbpcbRQD8tttI
KJdStG6BIT483YrMHyELtxTJAjheLZeWAVoqR6Qw0AZR9Kq707TYWKOxVfXt8u8J
4Z2nfaCsSi+SGvaKzO4AHkoidc1t6rSM3Kyu7wAaOr+4jGzICQzFA/3QDOfvkU2x
iRgElsEax8Qk8FPz6sz8iK6gAuLgzDeNblaJZCjGU0JqmOx/zmZ400gmki9zrwSz
LbVEGf+WhKYcbZF35StZu8ZAflYuXlIuxC0T9aXbZf/UolajqaJbx7TYgf6xiEvO
Ksm8s4AxUd5blxtvaG5T7n0jy3O5AyzEvxu4frIAFAwc4qUmaXF7gIk/Tgn2eJnC
BbgPVOBI7cV7KVwwDRcnMwqdt7M/0BAZ/xQZy+I2qG4SE5Vqxb638l1bZArIPftK
lC6QV5wPfm0CxB7BoEnyIOtpWMMuTVZPkGm+t7uflAG1jSasF8b1n9s1YomKAXp/
O4ngeBmkIMLqX8eoO7/HjT9EYp2cxr5EnaRXQDzKON/LBvBslf4=
=flv5
-END PGP SIGNATURE-

Bug#951003: libmath-gmp-perl: FTBFS with gmp 6.2.0: test failure

[gregor herrmann]

Source: libmath-gmp-perl
Version: 2.19-1
Severity: serious
Tags: upstream ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

libmath-gmp-perl fails to build, apparentaly due to changes in gmp
6.2.0:

#   Failed test 'Test worked: $x = 
Math::GMP->new("387047");Math::GMP::probab_prime($x,25);'
#   at t/01_gmppm.t line 192.
#  got: '2'
# expected: '1'

#   Failed test 'Test worked [feature bitwise]: $x = 
Math::GMP->new("387047");Math::GMP::probab_prime($x,25);'
#   at t/01_gmppm.t line 200.
#  got: '2'
# expected: '1'
# Looks like you failed 2 tests of 974.

Cf. also 
https://ci.debian.net/data/autopkgtest/unstable/amd64/libm/libmath-gmp-perl/4241553/log.gz

Potential background: https://bugs.debian.org/950608#31


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl5AO6FfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZSLBAAxfmJoR3sKQt7cBpSx4mnq6XYUmRtijqmUxk2O1bUCz5vcS2poP0ZbV+7
0aoh3fmggdJr6euMsFkZDrliIZHtfEeBOuB6Vq4WSk4osTUiEnnk7YrVqjuOIP3r
4WuWZmeSl9CAqAf6nReC5P+YtbjCMJWTrVHLP4TkofvMKEXBaIaf+05hkNknystJ
HVGvS5kbvCJA5+l0CO+Nj4ldz2A26iQsaERMaKER7UccpjCCKUWoK/eQF+gq2a8b
rOgmASMF2gLhaHeRF23XEc23r7Oy/u8cTFIEqChEwbEy1rQ1OcMItR4FKa58SKOe
qZgCCQmmNvXLjg60WUfQ8l5RReGllTPhQ9qpkSewU61OSZ/g7/x8aiA73wkIoh8e
fCsVLB0mz97KOSMAx9M2oQI7LhqtSBpzMBZ+r1ObNrBGkZWDuqhfr0UCnSWdXT2e
5l+OjPKfLVNZnKj1kxNNiZmXlmdz1JAjk0T4NkGhYjFjNCb5lYA2KkBZKCJbDHY1
1QcSEkDOMoFUJIEQ4qxNjZ7yvozbp2f8NqH80z7Kcqf59iUhZNYbaeI8FNuhHz4T
W4vMY4CA61iwQitSeiSw5htbdEaIXiE4Y+Zt8PIL++3eBtjo8kMNtMtcFf0O3WMf
gZ/VlKEHAP6vPbkOrvRtdrndEANAqPqbzzVWrjjtBx1B/XZUdDw=
=wafi
-END PGP SIGNATURE-

Bug#951002: open-infrastructure-system-build: "lb chroot_devpts remove" gets chroot/dev/pts: target is busy

[Chris Ward]

Package: open-infrastructure-system-build
Version: 20190202-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
I am trying to build a 'live' debian image for usb stick
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
'lb config' followd by 'lb build'
   * What was the outcome of this action?
'lb build' failed part way through. The last few lines of the output were
P: Begin unmounting /sys...
[2020-02-09 16:38:07] lb chroot_selinuxfs remove
P: Begin unmounting /sys/fs/selinux...
[2020-02-09 16:38:07] lb chroot_proc remove
P: Begin unmounting /proc...
[2020-02-09 16:38:07] lb chroot_devpts remove
P: Begin unmounting /dev/pts...
umount: /ssd/tjcw/oi/freeduc2/chroot/dev/pts: target is busy.
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists...
Building dependency tree...
Reading state information...

I have put the package list I am using here
http://tjcw.freeshell.org/freeduc.list.chroot . I am configured to use debian
'buster'. The problem seems timing-dependent; 'lb build' sometimes produces an
iso and sometimes fails as described here.
   * What outcome did you expect instead?
'lb build' should complete and result in an iso file
*** End of the template - remove these template lines ***



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

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

Versions of packages open-infrastructure-system-build depends on:
ii  debootstrap  1.0.114

Versions of packages open-infrastructure-system-build recommends:
ii  apt-utils   1.8.2
ii  cpio2.12+dfsg-9
ii  live-manual-html [live-manual]  2:20151217.1
ii  wget1.20.1-1.1

Versions of packages open-infrastructure-system-build suggests:
pn  debian-keyring  
ii  gpgv2.2.12-1+deb10u1

-- no debconf information

Bug#950927: dask: autopkgtest fail with pandas 1.0

[Diane Trout]

Thanks for letting me know, I'll try working on it though i probably wont have 
much time until tuesday.

Once I have a fixed build should I send it to experimental in preparation for 
the pandas transition?

Diane

Bug#950993: orage: calendar window doesn't work anymore

[Bzzzz]

On Sun, 09 Feb 2020 17:36:54 +0100
Yves-Alexis Perez  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> control: tag -1 moreinfo unreproducible
>
> On Sun, 2020-02-09 at 12:12 +, Jiff wrote:
> > Package: orage
> > Version: 4.12.1-6
> > Severity: important
> >
> > Hi Dear Maintainer,
> >
> >* What led up to the situation?
> >
> > Yesterday buster large update to 10.3.

Hi Yves-Alexis,

> I tried on my own Buster installation but I can't reproduce your
> problem. I installed Orage and it worked just fine here (either the
> plugin or running from command line).

Ra ! :/
Could it be something coming from xfce configuration files? (although,
if they come from squeeze, most of them have been updated or suppressed.)

> When you run orage from command line, what is displayed on the
> terminal?

The calendar window opens (borders, frame and background) for ~500 ms,
then disappear.

> Is the process stuck or does it returns?

It returns with that:

$ orage
** Message: 16:45:12.883: Orage **: 16:45:12  wakeup timer init 0
Segmentation fault

> If you run through strace, does it outputs anything meaningful?

No for me, but I manager to make a log file (with: strace orage >
orage_strace.log 2>&1), I join it as an attachement.


As said above, there still may be xfce configuration files dated from
squeeze ; if it is the case, could it be the source of my problem
and if so, how could I be certain to restart xfce as fresh as a new
install?

Regards,

Jean-Yves


orage_strace.log.bz2
Description: application/bzip

Bug#950927: dask: autopkgtest fail with pandas 1.0

[Rebecca N. Palmer]

On 09/02/2020 16:29, Diane Trout wrote:

Thanks for letting me know, I'll try working on it though i probably wont have 
much time until tuesday.


Given the number of broken packages, it's likely to take longer than 
that anyway.


Ubuntu freeze is on the 27th.


Once I have a fixed build should I send it to experimental in preparation for 
the pandas transition?


If it still works with pandas 0.25 and doesn't break dask's reverse 
dependencies (I have _not_ tested either of those), it can go straight 
to unstable.


If not, either experimental or just pushing it to salsa is fine: pandas 
went to experimental mostly to check whether it builds on the non-amd64 
architectures, and dask is arch:all so doesn't have that potential 
failure point.


(Note that packages in experimental still prefer taking their 
build-dependencies from unstable, i.e. default to pandas 0.25 not 1.0.)

Bug#950993: orage: calendar window doesn't work anymore

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

control: tag -1 moreinfo unreproducible

On Sun, 2020-02-09 at 12:12 +, Jiff wrote:
> Package: orage
> Version: 4.12.1-6
> Severity: important
> 
> Hi Dear Maintainer,
> 
>* What led up to the situation?
> 
> Yesterday buster large update to 10.3.

I tried on my own Buster installation but I can't reproduce your problem. I
installed Orage and it worked just fine here (either the plugin or running
from command line).

When you run orage from command line, what is displayed on the terminal? Is
the process stuck or does it returns? If you run through strace, does it
outputs anything meaningful?

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl5ANSYACgkQ3rYcyPpX
RFtUagf5AfpwF2vdOv9EpRik/Yfl7GCI0ZzP1v8x8GXrsNbyTdJJvjVAS8+llo7n
Qd24VO90taz6hEZdRHXt6LcBUUcMQIOichnSEPrdLu4kulo8Y2M2fCMJ7xHOmRXL
U1pcnjRKf8hwoeZ0U71olx45euNsb6ighrS9g/rf0XQ8kFL8mfEbYAYeWleuJlwr
zxsl+ryqRYzAEMSATUMdXjLgcDeBkHZ7eKEiJinFu6hh1AHKTFtGuNIKhNYL3J4X
Uwn8YIYIBDPe97q0BIwXjUqcGA5sN/LLg840HjDjHSUONDf0UL2izjs71T4VRTc7
wtt+i8bNHkcIQ4hiDgk+RWTA5p1y8g==
=15MP
-END PGP SIGNATURE-

Bug#949941: byobu build depends on the removed pep8 transitional package

[Dustin Kirkland]

Fixing this now.  Thanks.

@DustinKirkland
Ubuntu Core Dev


On Mon, Jan 27, 2020 at 5:27 AM Adrian Bunk  wrote:

> Source: byobu
> Version: 5.130-1.1
> Severity: serious
> Tags: ftbfs
>
> pep8 is no longer built by src:pep8.
>

Bug#911560: [Kinda solved] Re: Network not working on Olimex LIME2 rev K ??

[Jonas Smedegaard]

Quoting Dominique Dumont (2020-02-09 17:07:12)
> On Saturday, 8 February 2020 16:54:45 CET Jonas Smedegaard wrote:
> > Would be great if you could also test with patched u-boot in stable
> > Debian - so we can consider fixing this in a point release.
> 
> I've tested together:
> - Debian's u-boot debian/2019.01+dfsg-7 with CONFIG_GMAC_TX_DELAY=3 tweak
> - Debian's stable partition (dated 2019-11)
> 
> with Lime2 Rev G2 and rev K cards.
> 
> In both case the installer starts fine, sets network correctly (with dhcp) 
> and 
> starts downloading packages.
> 
> Because I have a crappy connection and no use for a Lime2 Debian/stable 
> installation, I've stopped the tests at that point.

Great!  Very helpful.

 - 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#951001: quisk: SoapySDR support

[Christoph Berg]

> Also, how about moving quisk to the debian-hamradio-team on salsa?
> I'd be interested to work on quisk.

I should have checked Salsa before writing that,
https://salsa.debian.org/debian-hamradio-team/quisk

Thanks!
Christoph

Bug#911560: [Kinda solved] Re: Network not working on Olimex LIME2 rev K ??

[Dominique Dumont]

On Saturday, 8 February 2020 16:54:45 CET Jonas Smedegaard wrote:
> Would be great if you could also test with patched u-boot in stable
> Debian - so we can consider fixing this in a point release.

I've tested together:
- Debian's u-boot debian/2019.01+dfsg-7 with CONFIG_GMAC_TX_DELAY=3 tweak
- Debian's stable partition (dated 2019-11)

with Lime2 Rev G2 and rev K cards.

In both case the installer starts fine, sets network correctly (with dhcp) and 
starts downloading packages.

Because I have a crappy connection and no use for a Lime2 Debian/stable 
installation, I've stopped the tests at that point.

All the best

Bug#951001: quisk: SoapySDR support

[Christoph Berg]

Package: quisk
Version: 4.1.52-1
Severity: wishlist

Hi,

I just discovered quisk - afaict the only SDR application in Debian
that can transmit and not just receive. Unfortunately, it's not built
with soapysdr support which my LimeSDR would require.

Afaict all it takes is build-depending on libsoapysdr-dev and calling
"make soapy3" at build time. Please consider enabling that.

Also, how about moving quisk to the debian-hamradio-team on salsa?
I'd be interested to work on quisk.

Thanks,
Christoph DF7CB

Bug#950608: gmp 6.2.0 crashes postgresql-pgmp (& others)

[Marco Bodrato]

Ciao,

From 
https://ci.debian.net/data/autopkgtest/testing/arm64/libm/libmath-gmp-perl/4229384/log.gz 
I read the following:


#   Failed test 'Test worked: $x = 
Math::GMP->new("387047");Math::GMP::probab_prime($x,25);'

#   at t/01_gmppm.t line 192.
#  got: '2'
# expected: '1'


From the manual of GMP 
https://gmplib.org/manual/Number-Theoretic-Functions.html I read the 
following:


Function: int mpz_probab_prime_p (const mpz_t n, int reps)
Determine whether n is prime. Return 2 if n is definitely prime, 
return 1 if n is probably prime (without being certain), or return 0 if 
n is definitely non-prime.


So, if the new release of the library is able to answer that the number 
387047 is prime, and not only "probably" prime... This should not be 
marked as a regression...



Ĝis,
m

Bug#948834: glib2.0: FTBFS: SIGABRT in gsocketclient-slow test

[Mattia Rizzolo]

Hi,

On Sun, Feb 09, 2020 at 01:15:07PM +, Simon McVittie wrote:
> This is just part of Meson's summary of the successful and failed tests,
> which is quite a long way away from the test's actual output in the log.
> The test's output is what we would need to be able to have any chance of
> debugging a failure.

Right, I forgot to attach the build log here.  Fishing out my own build
log would be quite daunting, but I see glib2.0 is also failing in the
r-b infra:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/glib2.0.html

Could you perhaps check that build log?  It's likely equivalent.


FWIW, alo my own rebuild was done in pbuilder.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#936797: cannot find way to use pbcommand API

[Andreas Tille]

Hi Olivier,

On Sun, Feb 09, 2020 at 03:10:40PM +0100, olivier sallou wrote:
> pbcommand in debian (latest from github) provide a different API, but
> pbcommand doc and README all show previous API example and show usage
> of get_pbparser function, but this method is not present anymore.
> 
> It is not possible to *guess* what should be used instead.

ACK.  I also dived in several PB tools.  I think the strategy to get
their latest Git commit is helpful in some cases but does not help in
others.

Thanks for looking into it anyway

  Andreas.

-- 
http://fam-tille.de

Bug#950347: FTBFS on ppc64* : error: conflicting declaration ‘typedef long long unsigned int __u64’

[Ritesh Raj Sarraf]

Control: fixed -1 0.12.0-2


Hi Frederic,

I made an upload and this should be fixed now.
Thank you for your contribution. Appreciate it.


Ritesh

On Fri, 2020-01-31 at 16:50 +0100, Frédéric Bonnard wrote:
> Package: src:bpfcc
> Version: 0.12.0-1
> Control: tags -1 ftbfs patch
> 
> --
> 
> Dear maintainer,
> latest 0.12.0-1 fails to build here :
> https://buildd.debian.org/status/fetch.php?pkg=bpfcc=ppc64el=0.12.0-1=1580365148=0
> 
> upstream recently fixed the test :
> https://github.com/iovisor/bcc/commit/5098c9dd2538d6256a10f1a67a36ebc867549e7f
> 
> Merge request importing that patch :
> https://salsa.debian.org/debian/bpfcc/merge_requests/1
> 
> Regards,
> 
> 
> F.
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#950999: libkiokudb-perl: FTBFS with recent YAML* packages

[gregor herrmann]

Source: libkiokudb-perl
Version: 0.57-2
Severity: serious
Tags: upstream ftbfs sid bullseye
Justification: fails to build from source

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

libkiokudb-perl fails to build (and probably also to run) after the
upgrade of the various YAML* packages which by default stop loading
objects:
http://blogs.perl.org/users/tinita/2020/01/making-yamlpm-yamlsyck-and-yamlxs-safer-by-default.html

https://ci.debian.net/data/autopkgtest/testing/amd64/libk/libkiokudb-perl/4227070/log.gz

#v+
not ok 14857 - lookup 1 objects

#   Failed test 'lookup 1 objects'
#   at /usr/share/perl5/KiokuDB/Test/Fixture/Overwrite.pm line 85.
# died: Can't call method "isa" on unblessed reference at 
/usr/share/perl5/KiokuDB/LiveObjects.pm line 423.
#v-

Not sure if this comes from YAML::XS or from MooseX::YAML which needs
to be fixed anyway.


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl5AGslfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbw6Q//TnFZ57xyV7aBYQy9moEK3ZxwYXfkmqnRtxaiOkFYsKWqWaVivwrm6tXT
H6y1OeFzhr12x1luEVeI/c1/jRW7f7SYm/sqtmgKetLSvLSSk5hiO2+qXW+sQ/so
j8W5FO4MnaX9IJrvzu2JUEyZA30SiOdRWgoutRVPpi5gPAgVJ2Lp6nsVBbZNcwwK
ICqwQmwhCJBwkgGsVxppVd+xyTi2kxhpXzd2sOie/89JD8JIydekTKiSNaFV6Lbe
DhIkWp0U/hMAKzAt98U14OmRL+z+2SbncEn9As037zcWck2e5PxJMmf1X1PxpeBR
1LiCn5Ld/Vc4YG4obOjuhA5qQkrv79BFf10sfnrKdkxlFYr9cPdb4SK+6PBJ2ir5
eP8riKi18niNlsj9QS5p4+HXnzPrs3PgXTEJ/lFO3r3ebz1A4azEZBXSagok0esR
ZTHiRN0KtbMgwzk0VuT0XqCLRlLLFc14U/v4gGnCH7yDgoI3tMJVRlkXRrAnlnZq
g3002E/gK+WYF2GUknzuS2dI/cd3Qa310UGVF1AQGb2paZAHf0TjdtUUgPI7FpaU
v5dUbWc9ipHgaE4/wKaBSUsQ8fiZHu3o8Tkvd9ZKPOaAVJ/0EIhbc7exsPsPk0fl
P8+ibhDpjNczMziAJZxnLBIZGiv5fFon+htOjaptzREwRfy8xMc=
=XNWk
-END PGP SIGNATURE-

Bug#950995: [Pkg-libvirt-maintainers] Bug#950995: [arm64] virNetDevGetPhysicalFunction:1391 : internal error: The PF device for VF eth1 has no network device name

[Guido Günther]

Hi,
On Sun, Feb 09, 2020 at 03:08:53PM +0100, Marcin Juszkiewicz wrote:
> W dniu 09.02.2020 o 14:55, Guido Günther pisze:
> > Thanks for digging out the patches.  Marking as fixed in newer versions
> > then. We might want to fold this into a point release at some point.
> > Cheers,
> >  -- Guido
> 
> Any plans for 5.6.0 backport maybe?

Not from my side but if somebody steps up to maintain a backport over
the buster life cycle that'd be great.
 -- Guido

Bug#950997: libmoosex-yaml-perl: FTBFS with recent YAML* packages

[gregor herrmann]

Source: libmoosex-yaml-perl
Version: 0.04-2
Severity: serious
Tags: upstream ftbfs bullseye sid
Justification: fails to build from source (but built successfully in the past)
Forwarded: https://rt.cpan.org/Ticket/Display.html?id=131714

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

libmoosex-yaml-perl fails to build (and probably also to run) after
the upgrade of the various YAML* packages which by default stop
loading objects:
http://blogs.perl.org/users/tinita/2020/01/making-yamlpm-yamlsyck-and-yamlxs-safer-by-default.html

http://matrix.cpantesters.org/?dist=MooseX-YAML%200.04;os=linux;perl=5.31.9;reports=1
https://ci.debian.net/data/autopkgtest/testing/amd64/libm/libmoosex-yaml-perl/4227072/log.gz


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl5AGM1fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbRhhAAipYUkMnB75F5EAPD4/FvWWJjVBZef1IQGrBdB4XZwngffR3iBNgTyYTo
vCnFzRsiBUxuQIvncEpDCFjCD/kOAMmldjcjSxjFlDibYEq2vTeNQ0R9OBcTvM5F
0fiAQ9+UMuz1ZtzV/mulDCCaDyf8BVu8jrOPEkcSWGKMl9qbOnxUPd3Wm0ZqKmz9
Ojc6HezjAhb/mkvVjM39Tqkg6vdzrYPADdbk+UPKZ9wJilw6Zf8p3N3L837fC+rq
0n35lzoC2E0viGIAGs+vz2f2EEkAi3eq5ZFtBvTIztZP6Q/HrAOIK0EjnYAEq1EF
I78yxhj4umW3lnmysF0+daiRZvGTX+6BrfqccUCsKUEgK2k7/Qc0TsgG98an5To9
jPoCujEiaCPRoS5/GIuv01NN+bs4mHAHz/61LH5twYRULViEtuHB1bXo4+RmWmsj
yyVg9BpSkzbtrCWNn6vzVJJEzmev8DYZHonVhe5J03QIhsaIMeYelh2z0GAO2bsT
iYu/HIL4qXExOkQwTDqudjGisASURxTKxrfFOej70eWWg3XEuns6OSEg/nR62C/E
a54vNOjtVDkyve6e9paMEr+PcSeNUI+dPx9PfV3CqkzMsE0G6xdvW4dph9pdQyEp
rMiQb+jNgYTfaMEp7MJIuz31q7WEgy1SR5LI62bAYb4ES0WjfXc=
=SvT6
-END PGP SIGNATURE-

Bug#950998: libcgi-session-serialize-yaml-perl: FTBFS with recent YAML* packages

[gregor herrmann]

Source: libcgi-session-serialize-yaml-perl
Version: 4.26-2
Severity: serious
Tags: upstream ftbfs bullseye sid
Justification: fails to build from source
Forwarded: https://rt.cpan.org/Ticket/Display.html?id=131715

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

libcgi-session-serialize-yaml-perl fails to build (and probably also
to run) after the upgrade of the various YAML* packages which by
default stop loading objects:
http://blogs.perl.org/users/tinita/2020/01/making-yamlpm-yamlsyck-and-yamlxs-safer-by-default.html

http://matrix.cpantesters.org/?dist=CGI-Session-Serialize-yaml%204.26;os=linux;perl=5.31.9;reports=1
https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libcgi-session-serialize-yaml-perl/4227073/log.gz


Cheers,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl5AGVJfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgazmw//XWYggMyG3trAiuOHJfiAkpuZbub6JG5FIPKbceP14Susa8zzLRWCjrX8
CkcFIU4v2Q4mdWZFkLkpSS/822yNVU61A9KOGr2aF6Romd1l5pOnqFegcbh90CUW
Xv6bTuvCBa5vp8rOKeylF8YSAHVnKreREJf50t5P742xshmFh2V8OuieQsKH9aU+
POWS5+RzkQScWS/Ibpjm9bZh8o/PnJrIq7GtB1OQ0/HUXEzAMweaGvvdsKX9bSJI
CdRKpo6SPbXjAOr1qpZ7uaGazP2DQN1UExzdQ7G1+ZUv0cwQecH6hDHXpPTleNgj
RcXprHM8Mh8xrjqDTL0cg6+WXhir8b0lxGHCYr0OF5Z2Z9ITRlL4Q3COrQRhn790
Qi2Q6vJQ1+i8skKdXI7KSb40l2zQOFEB+YGn3maJTH82Vla1GTQCzJL3MlYliH4g
l8jM/N67H83dC3B9dSq/kAltnlCjC++Vktje40tkZZQCni5o0p+sO2OF9slKrcxE
O1lJ3JLWJl8DOwO/r+49rJZ+N6QAWLhufIZHua6iix0FZWIYIX4KNpD6ygLflDOS
XuFW2Ad52RyMe/q6E+qYVg6GjSNaJgexrpDrkYGjGDQgAiZlKOD+br2Newx5FKfD
Fj71reKwriXGY00yE4ecIj0JMiBhCgYG03L4+Xvaq9wHXvjxW1E=
=hxd8
-END PGP SIGNATURE-

Bug#950996: ITP: octave-matgeom -- computational geometry for Octave

[Rafael Laboissiere]

Package: wnpp
Severity: wishlist
Owner: Rafael Laboissiere 

* Package name: octave-matgeom
  Version : 1.2.2
  Upstream Author : David Legland  and Juan Pablo 
Carbajal 
* URL : https://octave.sourceforge.io/matgeom/
* License : BSD-2-clause and GPL-3+
  Programming Lang: Octave
  Description : Computational geometry for Octave

This package contain a geometry toolbox for 2D/3D geometric computing in 
Octave, a numerical computation software. It contains several hundreds of 
functions for the creation and manipulation of 2D and 3D shapes such as 
point sets, lines, polygons, 3D meshes, ellipses, etc.


This Octave add-on package is part of the Octave-Forge project.

A preliminary version of the Debianized package is available at:

https://salsa.debian.org/pkg-octave-team/octave-matgeom

Bug#950972: Perl Source has Declared it's UTF-8.

[Ralph Corderoy]

Hi,

The ‘use utf8’ declares that Perl source file's encoding is UTF-8.
The 0xa0 present in $link_format's definition hex-dumped above is
correct because it's U+00A0 encoded as 0xc2 0xa0.  The source has other
non-ASCII characters correctly UTF-8 encoded, e.g. $openquote can
contain ‘«’.

I think the problem lies with whatever takes this scripts output and
puts it into a MIME email message.  This could be confirmed by running
the script in the same manner as for the email, but saving the output in
a file to be examined for UTF-8 correctness.

$ printf 'a\xa0b\n' | iconv -f utf-8 -t utf-8
aiconv: illegal input sequence at position 1
$

-- 
Cheers, Ralph.