Bug#982949: Please allow libvirt-python 7.0.0 into bullseye

[Guido Günther]

Hi Paul,
On Wed, Feb 17, 2021 at 10:55:14PM +0100, Paul Gevers wrote:
> Hi Bernd,
> 
> On 17-02-2021 22:30, Bernd Zeimetz wrote:
> > On Wed, 2021-02-17 at 18:37 +0100, Paul Gevers wrote:
> >> libvirt-python is a key package.
> > 
> > and it should match libvirt. Having libvirt-python 6.x and libvirt 7.0
> > is (imho, ymmv...) much worse than an completely (from us) untested
> > libvirt-python.
> 
> I understood from the request that it's an option to patch 6.x. Because,
> if Guido believes it really should match, than why did he file an
> unblock request? We're only in the soft freeze right now, only *new*

I don't think I marked it as unblock request. I used "allow" here to
indicate that i'm not entirely sure if the scope is still o.k.
Sorry if it was confusing.

> packages are blocked and we age packages a bit more, so technically
> there's nothing to unblock at this moment. Currently it's still the
> maintainers call what's right for bullseye. We, as the release team, ask
> for targeted fixes. If you consider this out-of-sync to be an issue of
> its' own, than please, align with Guido and I have good faith that
> you'll do the best in Debian interest, keeping our guidelines in the
> freeze policy [1] into account. I suggest to really not wait to long,

Uploaded now.

Cheers,
 -- Guido

> because after the hard freeze starts, this indeed requires an unblock
> from us. If the package (whichever option you choose) can migrate before
> that, that would be great.
> 
> Paul
> 
> [1] https://release.debian.org/bullseye/freeze_policy.html#soft
> 

Bug#983002: plocate: updatedb fails with "/var/lib/plocate/: Operation not supported"

[Steinar H. Gunderson]

On Wed, Feb 17, 2021 at 09:30:00PM -0600, Daniel Lewart wrote:
> updatedb fails with:
>   /var/lib/plocate/: Operation not supported
> 
> However, writing to a database in a different directory works fine.

Hi,

Thanks for the bug report. Is there anything special about your
/var/lib/plocate? Unusual filesystems? SELinux permissions?

I assume this is the O_TMPFILE call somehow, but it would be nice if you
could verify by doing

  sudo strace updatedb

and seeing which call is the failing one.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#983013: [Pkg-openssl-devel] Bug#983013: m2crypto: autopkgtest needs update for new version of openssl: M2Crypto.RSA.RSAError: sslv3 rollback attack

[Sebastian Andrzej Siewior]

On 2021-02-18 08:15:15 [+0100], Paul Gevers wrote:
> 
> I copied some of the output at the bottom of this report.  I *think*
> this may be related to CVE-2020-25657 "bleichenbacher timing attacks in
> the RSA decryption API" against m2crypto, hence I file this bug against
> m2crypto.

The openssl side is aware of the situtation. Currently we want to
clarify the documentation in openssl
https://github.com/openssl/openssl/issues/14216

and then report this m2crypto upstream what should be done instead.
The bug fix triggered the problem :)

Sebastian

Bug#982903: gitlab: Internal error caused by missing gitaly-git2go binary

[Pirate Praveen]

On 2021, ഫെബ്രുവരി 18 12:15:14 AM IST, Pirate Praveen 
 wrote:
>
>
>On 2021, ഫെബ്രുവരി 17 8:27:19 PM IST, Pirate Praveen 
> wrote:
>>
>>From what I understood from the logs, the error is coming from golang-git2go 
>>and not from gitaly.
>>
>
>I got gitaly-git2go built but it is not yet ready for an upload.
>
>1. gitaly 13.7 worked but not 13.6
>2. Used snapshot.debian.org for git2go 1.0

Uploaded gitaly 13.7.5 to fasttrack-staging. If someone can confirm this, I 
will move it to fasttrack.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#983018: qdbus: Needs package downgrade from Buster to Bullseye (missing epoch in transitional package)

[Axel Beckert]

Package: qdbus
Severity: serious
Justification: §3.2 and https://wiki.debian.org/SystemDowngrade

Hi,

on one system I wondered why qdbus is still on Qt4. Then I noticed that
the version of the Qt4 qdbus package from Buster is higher (!) than the
version of the Qt5 qdbus package in Bullseye:

$ apt-cache policy qdbus
qdbus:
  Installed: 4:4.8.7+dfsg-18+deb10u1
  Candidate: 4:4.8.7+dfsg-18+deb10u1
  Version table:
 *** 4:4.8.7+dfsg-20 100
100 /var/lib/dpkg/status
 5.15.2-3 990
900 https://debian.ethz.ch/debian bullseye/main i386 Packages

>From what I can see, the proper fix is to prepend at least an epoch of
"4" to (only) the transitional package, i.e. to make the version of
qdbus in Bullseye "4:5.15.2-…" instead of just "5.15.2-…".

Even the BTS gets it partially wrong probably because of this and still
thinks the current qdbus package is built from the qt4-x11 source
package:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=qdbus;dist=unstable
(Note that it displays the correct version number, but the wrong source
package.)

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Bug#982713: minexpert2: FTBFS: [ERROR] LazyFont - Failed to read font file /usr/share/texlive/texmf-dist/fonts/opentype/public/stix2-otf/STIX2Math.otf

[Juhani Numminen]

Dear maintainer,

> [ERROR] LazyFont - Failed to read font file 
> /usr/share/texlive/texmf-dist/fonts/opentype/public/stix2-otf/STIX2Math.otf

It's easy enough to locate the files which mention the font,
it is doc/user-manuals/fop.xconf in all three affected packages.

https://codesearch.debian.net/search?q=%2Fusr%2Fshare%2Ftexlive%2Ftexmf-dist%2Ffonts%2Fopentype%2Fpublic%2Fstix2-otf%2FSTIX2Math.otf&literal=1

>From texlive-extra's build log I gather the font file may have
changed names to STIXTwoMath-Regular.otf, that is
/usr/share/texlive/texmf-dist/fonts/opentype/public/stix2-otf/STIXTwoMath-Regular.otf.

https://buildd.debian.org/status/fetch.php?pkg=texlive-extra&arch=all&ver=2020.20210202-1&stamp=1612267116&raw=0

--
Juhani

Bug#983006: apt-cacher-ng apparmor profile denies access to /proc/sys/kernel/random/uuid which is read during restarts

[intrigeri]

Control: tag -1 + patch
Control: tag -1 + upstream
Control: forwarded -1 
https://gitlab.com/apparmor/apparmor-profiles/-/merge_requests/48

Hi Paul,

Thanks for this amazing bug report!

I've send a merge request upstream and will upload to sid shortly.

Cheers!

Bug#982674: closed by Helge Kreutzmann (Already resolved)

[Laurent Bigonville]

reopen 982674
thanks

Le 17/02/21 à 19:57, Debian Bug Tracking System a écrit :


fixed 982674 4.9.1-4


Are you sure it's fixed? I can still see the w.procps manpages in -5

Bug#983019: x11vnc: flaky autopkgtest: /tmp/x11vnc_allow-connections_result: No such file or directory

[Paul Gevers]

Source: x11vnc
Version: 0.9.16-6
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails often [1].

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

I copied the output at the bottom of this report.

Paul

[1]

https://ci.debian.net/data/autopkgtest/testing/amd64/x/x11vnc/10356520/log.gz

autopkgtest [20:16:31]: test allow-connections: [---
cat: /tmp/x11vnc_allow-connections_result: No such file or directory
autopkgtest [20:16:47]: test allow-connections: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#973715: RE: Bug#973715: fwupd-amd64-signed holding off fwupd update results in segfaulting binary

[Paul Gevers]

Hi Limonciello,

On 18-02-2021 07:15, Limonciello, Mario wrote:
> I don't have the power to manually run it. So there is nothing I can do.
> With the new 1.5.6-1 upload someone will need to manually run it again.

I recognize what you say. However, *in my opinion* you can't just upload
the unsigned package without securing that the signing will happen ASAP,
with such tight dependencies. Users of unstable should expect that their
system breaks once in a while, but that's not by design but because bugs
happen. Being able to not update because of transitions is to be
expected and we don't have an alternative. But that's different from
what I read in this bug, where something else got updated and then the
fwupd set breaks without warning.

If unstable doesn't work for you, how about using experimental? You can
upload there much more freely and once stuff is ready (including making
sure the signing can happen ASAP) you upload to unstable.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983013: [Pkg-openssl-devel] Bug#983013: m2crypto: autopkgtest needs update for new version of openssl: M2Crypto.RSA.RSAError: sslv3 rollback attack

[Kurt Roeckx]

forwarded 983013 https://gitlab.com/m2crypto/m2crypto/-/issues/293
thanks

I've created an upstream issue for it.

Bug#983012: plasma-desktop: installing plasma-desktop does not pull kmix

[Johannes Ranke]

> Maybe it has to do with desktop-file-utils? 

kmix from bullseye/sid installs, among others:

/etc/xdg/autostart/kmix_autostart.desktop
/etc/xdg/autostart/restore_kmix_volumes.desktop

On my system, I have

me@box:/etc/xdg/autostart$ ls -lh

..

lrwxrwxrwx 1 root root   43 18. Okt 2016  kmix_autostart.desktop -> /usr/
share/autostart/kmix_autostart.desktop
-rw-r--r-- 1 root root 3,0K 11. Nov 10:35 kmix_autostart.desktop.dpkg-new

...

lrwxrwxrwx 1 root root   49 18. Okt 2016  restore_kmix_volumes.desktop -> /
usr/share/autostart/restore_kmix_volumes.desktop
-rw-r--r-- 1 root root 2,6K 11. Nov 10:35 restore_kmix_volumes.desktop.dpkg-
new

...

The links to /usr/share/autostart are missing their targets.

They were originally installed with stretch:

https://packages.debian.org/stretch/amd64/kmix/filelist

Cheers,

Johannes

Bug#979326: ITP: crust -- SCP firmware for sunxi SoCs

[Nicolas Boulenguez]

> It seems crust-firmware is missing upstream and pristine-tar
> branches.

Fixed for 'upstream/master'.
Feel free to add pristine-tar, but I am avoiding its complexity now
that other tools are converging towards reproducibility by default.

Bug#982423: reprepro: Does not write to pipe if --endhook is set

[Uwe Kleine-König]

Control: forcemerge -1 928133

On Wed, Feb 17, 2021 at 12:55:45PM +0100, Hilko Bengen wrote:
> control: merge -1 928133

I repeated that with a bit of force as the severities of the two don't
match.

> * Uwe Kleine-König:
> 
> > This seems to be the same issue as https://bugs.debian.org/928133
> 
> Yes, indeed.
> 
> > @brlink: Do you consider fixing this problem for bullseye? Would you
> > welcome an NMU?
> 
> If you do so, be sure to also add code to flush stderr, though. :-)

Yeah, I noticed this flaw in my patch.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Bug#981597: plasma-desktop: Same problem on a system set up with stretch

[Johannes Ranke]

Am Donnerstag, 18. Februar 2021, 08:41:48 CET schrieb Norbert Preining:

> Did you do dist-upgrade? I simple upgrade might not find a proper
> solution because several packages need to be removed.

I do remember that I tried apt full-upgrade and aptitude full-upgrade without 
success.
 
> It is really hard to debug this, and in general it seems to be an apt
> problem not being able to find a solution, while there definitely is
> one, as you have shown yourself by installing it afterwards ;-)
> 
> So, without more debugging - and that is not possible since you have
> already upgraded your system, it is really hard to say why all this
> happened.

I agree. I thought it was only my system, but now when I see this bug report, 
I got the impression that it may be a general problem of stretch -> buster 
installations upgrading to bullseye.

I have a stretch chroot hanging around that I could upgrade to buster to see 
if I can reproduce it.

Cheers,

Johannes

Bug#983017: 9base: flaky autopkgtest on i386: stack smashing detected

[Paul Gevers]

Hi,

On Thu, 18 Feb 2021 08:28:06 +0100 Paul Gevers  wrote:
> shoogle has an autopkgtest, great. However, on i386 it fails more often
  ^^^ oops, that's what you get for reusing an old mail.

> I copied the output at the bottom of this report. Can you please look
> into it and make the test more robust (against network issues). If you
> keep the test that requires internet, you should add the needs-internet
> restriction too.

This paragraph also doesn't apply. Sorry for the sub-optimal report.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983014: manpages-de: Fails to upgrade from 4.2.0-1 to 4.9.1-5: This installation run will require temporarily removing the essential package manpages-de:amd64 due to a Conflicts/Pre-Depends loop.

[David Kalnischkies]

On Thu, Feb 18, 2021 at 08:12:06AM +0100, Axel Beckert wrote:
> I though have no idea why apt regards manpages-de as
> essential. X-Debbugs-Cc'ing the APT developers at

Does the output of
$ apt rdepends manpages-de --important
include more than task-german and parl-desktop-eu?

In particular, does it include a local metapackage which is tagged
Essential/Important:yes?

(Important packages are considered like Essential which here is probably
 wrong as we shouldn't make ordering guarantees for it… but then,
 I guess that is part of why libgcc ↔ libgcc_s works now. And btw: The
 commandline flag stands for "important dependencies", which in this
 case is Depends and Pre-Depends, it has nothing to do with the
 Important flag or the other billion things also called important)


If not have a look into /var/backups for a dpkg.status file from before
your (failed) upgrade, so that we might be able to reproduce this.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#983012: plasma-desktop: installing plasma-desktop does not pull kmix

[Johannes Ranke]

> Hmmm, I don't have kmix installed either ... but I do have a sound
> applet in my systray.

Oh, I see... 

> > Please add a dependency on kmix to plasma-desktop or to one of the
> > packages it depends on, if this is more suitable.
> 
> kmix doesn't help here, it must be something else that is missing, since
> I don't have kmix and I have a sound applet ;-)

The applet came back after installing kmix and calling it from the command 
line. Also, after logging out and logging in again, I did not have to manually 
start it any more to have it.

I just removed kmix, logged out and logged back in, and the applet is gone 
again...

Maybe it has to do with desktop-file-utils? I noticed when installing kmix it 
processes a trigger for it:

...

Setting up kmix (4:20.12.0-1) ... 
Processing triggers for desktop-file-utils (0.26-1) ... 

...

Best, Johannes

Bug#980856: bridge-utils: ignores bridge_hw

[Martin-Éric Racine]

to 18. helmik. 2021 klo 1.41 Santiago Garcia Mantinan
(ma...@debian.org) kirjoitti:
>
> > > > Btw, the discrepancy in behavior explained in Bug#980752 remains. With
> > > The problem is with neither, I believe.
> > Oh? What would cause this then?
>
> Like I have explained to you in other bugs, I could replicate the problem
> and found that it was a problem with bridge-utils, I have assigned #980752
> to bridge-utils and added a patch to fix that on the bug report.
>
> > Yes, they all have bridge=br0 in their config.
>
> Ok, I've been looking at your interfaces and I have some sugestions to make,
> removal of hwaddress statements, leave just the bridge_hw ones, remove all
> the ipv6 statements if they don't provide real meaning and I would extend
> this to any other stuff you have written. I would leave it like this:
>
> allow-hotplug wlxdongle1mac wlxdongle2mac wlxdongle3mac wlxdongle4mac 
> wlxdongle5mac
> auto br0
>
> iface br0 inet dhcp
> hwaddress enp4s0mac
> bridge_hw enp4s0mac
> bridge_ports regex (en|wl).*
>
> iface wlxdongle1mac inet manual
> hostapd /etc/hostapd/hostapd-wlxdongle1mac.conf
>
> iface wlxdongle2mac inet manual
> hostapd /etc/hostapd/hostapd-wlxdongle2mac.conf
>
> iface wlxdongle3mac inet manual
> hostapd /etc/hostapd/hostapd-wlxdongle3mac.conf
>
> iface wlxdongle4mac inet manual
> hostapd /etc/hostapd/hostapd-wlxdongle4mac.conf
>
> iface wlxdongle5mac inet manual
> hostapd /etc/hostapd/hostapd-wlxdongle5mac.conf
>
> I have tested this after applying the patch I sent to bug #980752 with a new
> dongle I have just bought and seems to work ok with a similar configuration.
>
> Can you please apply the patch on #980752 to your system and modify the
> configuration like I suggest and let me know how things go?

That would fail to raise enp4s0, and it also still has hwaddress. I
also still need this:

iface br0 inet6 auto
privext 2

Martin-Éric

Bug#979432: ruby-rack FTBFS on IPV6-only buildds

[Paul Gevers]

Hi,

On Sun, 7 Feb 2021 19:22:30 +0100 Chris Hofstaedtler 
wrote:
> I guess one can change all the tests to use ::1 instead of
> 127.0.0.1, but that will just introduce other failure modes.

If no proper solution can be found shortly, can this package please be
uploaded with these specific tests disabled?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure

[intrigeri]

Hi,

intrigeri (2021-02-06):
> I understand the LXC container is stopped and restarted between each
> test, so what Paul wrote above suggests the container is successfully
> stopped between the 1st and 2nd test, same between the 2nd and 3rd
> test, but then it occasionally fails to stop after the last
> (3rd) test. Correct?
>
> If this analysis is correct, then the culprit has to be in the 3rd
> test i.e.:
>
>   # Dummy test so that changes to linux-image-amd64 trigger our other 
> autopkgtests
>   # on ci.debian.net
>   Test-Command: /bin/true
>   Depends: linux-image-amd64 [amd64] | linux-image-generic [ amd64 ]
>   Restrictions: superficial, skip-not-installable
>
> … and this is the one I should mark it as isolation-machine,
> so we can resume running the other 2 tests on ci.d.n,
> which I would very much like.
>
> Makes sense?

Actually, apparmor-profiles-extra has the exact same test, and AFAICT
it seems to run pretty reliably there, so I now have doubts about the
hypothesis I quoted above.

Still, perhaps it's worth trying to add isolation-machine to that
test, remove src:apparmor from the blocklist, and see what happens?

Cheers!

Bug#980752: Patch for testing

[Martin-Éric Racine]

ti 16. helmik. 2021 klo 22.35 Santiago Garcia Mantinan
(ma...@debian.org) kirjoitti:
> I have now assigned this bug to bridge-utils and I've got this patch that
> should solve it, can you test it on your machine and let me know if it fixes
> the problem?
>
> --- /lib/udev/bridge-network-interface~ 2021-02-16 20:59:36.397579972 +0100
> +++ /lib/udev/bridge-network-interface  2021-02-16 20:59:45.777222821 +0100
> @@ -30,6 +30,7 @@
> create_vlan_port
> if [ -d /sys/class/net/$port ]; then
> ifup --allow auto $i
> +   if [ -f 
> /proc/sys/net/ipv6/conf/$port/disable_ipv6 ]; then echo 1 > 
> /proc/sys/net/ipv6/conf/$port/disable_ipv6;fi
> brctl addif $i $port && ip link set 
> dev $port up &&
> if [ "$(ifquery "$i"|sed -n 
> -e's/^bridge[_-]hw: //p')" = "$port" ]; then
> ip link set dev "$i" address 
> "$(ip link show dev "$port" 2>/dev/null|sed -n "s|.*link/ether \([^ ]*\) 
> brd.*|\1|p")"

This indeed prevents the superfluous fe80 address from appearing when
the dongle is plugged in after the bridge is already up. It doesn't
seem to affect traffic connecting via the dongle either.

Martin-Éric

Bug#979865: m2crypto FTBFS on IPV6-only buildds

[Paul Gevers]

Hi,

On Fri, 29 Jan 2021 20:50:07 +0100 Sebastian Andrzej Siewior
 wrote:
> > The release team considers these bugs release critical.
> 
> it would be easier to enforce to have all buildds configured equally so
> the package does not fail on a random buildd.

I *guess* that's not trivial as I think it depends on the network their in.

m2crypto needs another upload anyways. Without a proper IPv6 solution
for the tests, can the failing network tests please be disabled in the
next upload?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure

[Paul Gevers]

Hi intrigeri,

On 18-02-2021 10:34, intrigeri wrote:
>>   # Dummy test so that changes to linux-image-amd64 trigger our other 
>> autopkgtests
>>   # on ci.debian.net

By the way, we have the "hint-testsuite-triggers" for this.

> Actually, apparmor-profiles-extra has the exact same test, and AFAICT
> it seems to run pretty reliably there, so I now have doubts about the
> hypothesis I quoted above.
> 
> Still, perhaps it's worth trying to add isolation-machine to that
> test, remove src:apparmor from the blocklist, and see what happens?

If you add that restriction (instead of the current ones), the test
isn't run anywhere (and can't cause any issues).

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982671: Supporting unbound in stretch by upgrading to 1.9

[Andrei POPESCU]

On Mi, 17 feb 21, 22:47:32, Markus Koschany wrote:
> Am Mittwoch, den 17.02.2021, 15:21 -0500 schrieb Robert Edmonds:
> > Markus Koschany wrote:
> [...]
> > > Please feel free to reassign and/or adjust the bug report as necessary.
> > 
> > I get the following error message from the BTS. Do I need to do
> > "reassign 982671 unbound1.9" instead?
> 
> I also got some error messages but it seems the bug reports are now reassigned
> to src:unbound1.9. The errors are probably related to the fact that the source
> package only and ever existed in Stretch 

Hello,

This appears to be the case. A side effect of this is that unless dealt 
with manually these bugs will just linger in the BTS.

https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=

Please either close or reassign them to a package known to the BTS.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure

[Paul Gevers]

Ooo,

On 18-02-2021 10:34, intrigeri wrote:
>>   # Dummy test so that changes to linux-image-amd64 trigger our other 
>> autopkgtests
>>   # on ci.debian.net
>>   Test-Command: /bin/true
>>   Depends: linux-image-amd64 [amd64] | linux-image-generic [ amd64 ]
>>   Restrictions: superficial, skip-not-installable
>>
>> … and this is the one I should mark it as isolation-machine,
>> so we can resume running the other 2 tests on ci.d.n,
>> which I would very much like.
>>
>> Makes sense?
> 
> Actually, apparmor-profiles-extra has the exact same test, and AFAICT
> it seems to run pretty reliably there, so I now have doubts about the
> hypothesis I quoted above.
> 
> Still, perhaps it's worth trying to add isolation-machine to that
> test, remove src:apparmor from the blocklist, and see what happens?

I think this test only makes sense by the way in isolation-machine case,
as our workers are nearly all running stable, and you get the host
kernel in your lxc, don't you?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983020: mirror submission for debian.fastserv.co.il

[HQserv Networks]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: debian.fastserv.co.il
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: HQserv Networks 
Country: IL Israel
Sponsor: HQserv Networks https://www.fastserv.co.il/




Trace Url: http://debian.fastserv.co.il/debian/project/trace/
Trace Url: 
http://debian.fastserv.co.il/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://debian.fastserv.co.il/debian/project/trace/debian.fastserv.co.il

Bug#983021: mirror submission for debian.fastserv.co.il

[HQserv Networks]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: debian.fastserv.co.il
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: HQserv Networks 
Country: IL Israel
Sponsor: FastServ Networks https://www.fastserv.co.il/




Trace Url: http://debian.fastserv.co.il/debian/project/trace/
Trace Url: 
http://debian.fastserv.co.il/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://debian.fastserv.co.il/debian/project/trace/debian.fastserv.co.il

Bug#983022: RFP: bio-vcf -- DSL for parsing of bioinformatics VCF format (DebianMed)

[wrk]

Package: wnpp
Severity: wishlist

* Package name: bio-vcf
  Version : 0.9.5
  Upstream Author : Pjotr Prins 
* URL : https://github.com/vcflib/bio-vcf
* License : MIT
  Programming Lang: Ruby
  Description : binary tool offers DSL for VCF parsing - used in 
bioinformatics pipelines (DebianMed)

bio-vcf is used in existing workflows and we think it would be a valuable 
addition to Debian Med.
It is a CLI tool packaged as a Ruby gem and has no runtime dependencies other 
than Ruby. It
is also packaged in GNU Guix as 
https://guix.gnu.org/en/packages/bio-vcf-0.9.5/. As the author
I am happy to support upstream issues, though I expect few.

Bug#983023: mirror submission for debian.fastserv.co.il

[HQserv Networks]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: debian.fastserv.co.il
Type: leaf
Archive-architecture: amd64 i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: HQserv Networks 
Country: IL Israel
Sponsor: FastServ Networks https://www.fastserv.co.il/




Trace Url: http://debian.fastserv.co.il/debian/project/trace/
Trace Url: 
http://debian.fastserv.co.il/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://debian.fastserv.co.il/debian/project/trace/debian.fastserv.co.il

Bug#982879: Acknowledgement (Artifacts in x2go rendering connecting to testing from a buster client)

[Francesco P. Lovergine]

Update: I tested also with a vagrant installation of a testing64 vm (from 
scratch), under a virtualbox provider. It gives exactly the same result. IMHO 
this bug should be raised to important or grave because could render unusable 
the x2goserver in bullseye for many (if not most) use cases :-( I still did 
not check the use of bullseye from a bullseye client or other platforms.


--
Francesco P. Lovergine

Bug#983024: RFP: bio-vcf -- DSL for parsing of bioinformatics VCF format (DebianMed)

[wrk]

Package: wnpp
Severity: wishlist

* Package name: bio-vcf
  Version : x.y.z
  Upstream Author : Name 
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : DSL for parsing of bioinformatics VCF format (DebianMed)

(Include the long description here.)

Please also include as much relevant information as possible.
For example, consider answering the following questions:
 - why is this package useful/relevant? is it a dependency for
   another package? do you use it? if there are other packages
   providing similar functionality, how does it compare?
 - how do you plan to maintain it? inside a packaging team
   (check list at https://wiki.debian.org/Teams)? are you
   looking for co-maintainers? do you need a sponsor?

Bug#981597: plasma-desktop: Same problem on a system set up with stretch

[Johannes Ranke]

Am Donnerstag, 18. Februar 2021, 09:58:59 CET schrieb Johannes Ranke:

> I have a stretch chroot hanging around that I could upgrade to buster to see
> if I can reproduce the problem.

I just installed plasma-desktop on stretch and upgraded stretch -> buster -> 
bullseye without problems in a pbuilder chroot. So it seems there was 
something more specific on my system preventing the smooth upgrade.

Thanks,

Johannes

Bug#983014: manpages-de: Fails to upgrade from 4.2.0-1 to 4.9.1-5: This installation run will require temporarily removing the essential package manpages-de:amd64 due to a Conflicts/Pre-Depends loop.

[Axel Beckert]

Control: severity -1 important
Control: reassign -1 apt 2.1.20

Hi David,

thanks for having a look at this.

David Kalnischkies wrote:
> On Thu, Feb 18, 2021 at 08:12:06AM +0100, Axel Beckert wrote:
> > I though have no idea why apt regards manpages-de as
> > essential. X-Debbugs-Cc'ing the APT developers at
> 
> Does the output of
> $ apt rdepends manpages-de --important
> include more than task-german and parl-desktop-eu?

Correct:

$ apt rdepends manpages-de --important
manpages-de
Reverse Depends:
  Depends: kiva-users
  Depends: task-german
  Depends: task-german
  Depends: parl-desktop-eu

> In particular, does it include a local metapackage which is tagged
> Essential/Important:yes?

Correct:

Package: kiva-users
Source: abe-metapackages
[…]
Depends: […], manpages-de, […]
Important: yes

Full control file stanza at
https://github.com/xtaran/abe-metapackages/blob/master/debian/control#L1243-L1333

Binary package at
https://noone.org/apt/pool/main/a/abe-metapackages/kiva-users_19_all.deb

> (Important packages are considered like Essential which here is probably
>  wrong as we shouldn't make ordering guarantees for it… but then,
>  I guess that is part of why libgcc ↔ libgcc_s works now. And btw: The
>  commandline flag stands for "important dependencies", which in this
>  case is Depends and Pre-Depends,

What I don't understand is, that apt claims that manpages-de is
Essential (or Important, whatever) just because an Essential (or
Important…) package depends on it.

I do see that it might want to apply similar rules for dependencies of
Essential packages, but the phrase "the essential package
manpages-de:amd64" is nevertheless extremly misleading and not
helpful.

>  it has nothing to do with the
>  Important flag or the other billion things also called important)

Downgrading to important (sic!) as a first measure and reassigning
then to apt.

P.S. to Toddy and Helge: Sorry for the noise. You already had enough
trouble with manpages-de in the last few weeks.

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

Bug#982423: reprepro: diff for NMU version 5.3.0-1.2

[Uwe Kleine-König]

Control: tags 982423 + pending

Hey Bernhard,

I've prepared an NMU for reprepro (versioned as 5.3.0-1.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards from Freiburg
Uwe

diff -Nru reprepro-5.3.0/debian/changelog reprepro-5.3.0/debian/changelog
--- reprepro-5.3.0/debian/changelog	2020-01-17 03:03:27.0 +0100
+++ reprepro-5.3.0/debian/changelog	2021-02-18 10:25:24.0 +0100
@@ -1,3 +1,10 @@
+reprepro (5.3.0-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Flush stdout and stderr before execv of an end hook (Closes: #982423)
+
+ -- Uwe Kleine-König   Thu, 18 Feb 2021 10:25:24 +0100
+
 reprepro (5.3.0-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru reprepro-5.3.0/debian/patches/flush-streams-before-exec-hook.patch reprepro-5.3.0/debian/patches/flush-streams-before-exec-hook.patch
--- reprepro-5.3.0/debian/patches/flush-streams-before-exec-hook.patch	1970-01-01 01:00:00.0 +0100
+++ reprepro-5.3.0/debian/patches/flush-streams-before-exec-hook.patch	2021-02-18 10:25:24.0 +0100
@@ -0,0 +1,18 @@
+From: Hilko Bengen 
+Date: Wed, 10 Feb 2021 01:47:23 +0100
+Subject: Flush stdout, stderr before calling endhook
+Bug-Debian: https://bugs.debian.org/982423
+
+Flush stdout and stderr, otherwise output might be discarded.
+
+--- a/main.c
 b/main.c
+@@ -4906,6 +4906,8 @@
+ 	if (snprintf(exitcode, 4, "%u", ((unsigned int)status)&255U) > 3)
+ 		memcpy(exitcode, "255", 4);
+ 	sethookenvironment(causingfile, NULL, NULL, exitcode);
++	fflush(stdout);
++	fflush(stderr);
+ 	argv[0] = endhook,
+ 	(void)execv(endhook, argv);
+ 	fprintf(stderr, "Error executing '%s': %s\n", endhook,
diff -Nru reprepro-5.3.0/debian/patches/series reprepro-5.3.0/debian/patches/series
--- reprepro-5.3.0/debian/patches/series	2020-01-17 02:57:30.0 +0100
+++ reprepro-5.3.0/debian/patches/series	2021-02-18 10:25:24.0 +0100
@@ -1 +1,2 @@
 bump-buffer-size
+flush-streams-before-exec-hook.patch


signature.asc
Description: PGP signature

Bug#951988: libplacebo: FTBFS: (.text+0x8ee): undefined reference to `spvContextCreate'

[Simon McVittie]

On Mon, 18 Jan 2021 at 11:27:35 +, Simon McVittie wrote:
> On Mon, 18 Jan 2021 at 10:54:30 +, Simon McVittie wrote:
> > Unfortunately, unlike #980369, I was not able to find a combination of
> > libraries that I could add to spirv.pc to fix this bug.
> 
> I think the attached might do it? As before, I don't know this library,
> so please review carefully.
> 
> I have deliberately not used SPIRV-Tools-Shared here to avoid being
> affected by #980370.

https://salsa.debian.org/xorg-team/vulkan/glslang/-/merge_requests/4

(Updated patches attached, if you prefer the BTS.)

smcv
>From af942e4bc20bdb9fab9f187f497e7fe6c80cf12d Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 18 Jan 2021 11:24:30 +
Subject: [PATCH 1/2] Add missing dependencies to spirv.pc

Some code accessed via spirv.pc requires SPIRV-Tools and/or glslang.

Signed-off-by: Simon McVittie 
Closes: #951988
---
 debian/control|  3 +-
 debian/patches/series |  1 +
 ...endencies-on-SPIRV-Tools-and-glslang.patch | 38 +++
 3 files changed, 41 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/spirv.pc-Add-dependencies-on-SPIRV-Tools-and-glslang.patch

diff --git a/debian/control b/debian/control
index 594ac5a8..6eacf228 100644
--- a/debian/control
+++ b/debian/control
@@ -28,7 +28,8 @@ Description: OpenGL and OpenGL ES shader front end and validator -- tools
 
 Package: glslang-dev
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends},
+ spirv-tools,
 Suggests: glslang-tools
 Multi-Arch: same
 Description: OpenGL and OpenGL ES shader front end and validator -- development files
diff --git a/debian/patches/series b/debian/patches/series
index 7d0b1f9a..e66d681a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 glslang-default-resource-limits_staticlib.patch
 0001-pkg-config-compatibility.patch
 glslang.pc-Add-missing-libraries.patch
+spirv.pc-Add-dependencies-on-SPIRV-Tools-and-glslang.patch
diff --git a/debian/patches/spirv.pc-Add-dependencies-on-SPIRV-Tools-and-glslang.patch b/debian/patches/spirv.pc-Add-dependencies-on-SPIRV-Tools-and-glslang.patch
new file mode 100644
index ..160832d6
--- /dev/null
+++ b/debian/patches/spirv.pc-Add-dependencies-on-SPIRV-Tools-and-glslang.patch
@@ -0,0 +1,38 @@
+From: Simon McVittie 
+Date: Mon, 18 Jan 2021 11:22:34 +
+Subject: spirv.pc: Add dependencies on SPIRV-Tools and glslang
+
+Otherwise, a simple program like this will fail to link:
+
+#include 
+int main (void)
+{
+  std::string s;
+  glslang::GetSpirvVersion(s);
+  return 0;
+}
+
+when compiled with the obvious parameters from pkg-config:
+
+g++ -ospirv spirv.cpp $(pkg-config --cflags --libs spirv)
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951988
+Signed-off-by: Simon McVittie 
+---
+ SPIRV/spirv.pc.cmake.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/SPIRV/spirv.pc.cmake.in b/SPIRV/spirv.pc.cmake.in
+index dfcad94..d47d427 100644
+--- a/SPIRV/spirv.pc.cmake.in
 b/SPIRV/spirv.pc.cmake.in
+@@ -5,7 +5,7 @@
+ 
+ Name: @SPIRV_NAME@
+ Description: SPIR-V is a binary intermediate language for representing graphical-shader stages and compute kernels for multiple Khronos APIs, including OpenCL, OpenGL, and Vulkan
+-Requires:
++Requires: SPIRV-Tools, glslang
+ Version: @SPIRV_VERSION@
+ Libs: -L${libdir} -lSPIRV
+ Cflags: -I${includedir}
+\ No newline at end of file
-- 
2.30.1

>From ff5bf4e4301419d16f68a5ca673dc1c88c3f3c1f Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 18 Jan 2021 10:16:45 +
Subject: [PATCH 2/2] d/tests/glslang-dev: Add a test for spirv.pc

Signed-off-by: Simon McVittie 
Reproduces: #951988
---
 .../glslang.pc-Add-missing-libraries.patch   |  2 +-
 debian/tests/glslang-dev | 16 
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/debian/patches/glslang.pc-Add-missing-libraries.patch b/debian/patches/glslang.pc-Add-missing-libraries.patch
index f8029af4..b3fa7b4f 100644
--- a/debian/patches/glslang.pc-Add-missing-libraries.patch
+++ b/debian/patches/glslang.pc-Add-missing-libraries.patch
@@ -11,7 +11,7 @@ Signed-off-by: Simon McVittie 
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/glslang/glslang.pc.cmake.in b/glslang/glslang.pc.cmake.in
-index 921497e..fd92606 100644
+index 921497e..8c49e0c 100644
 --- a/glslang/glslang.pc.cmake.in
 +++ b/glslang/glslang.pc.cmake.in
 @@ -7,5 +7,5 @@
diff --git a/debian/tests/glslang-dev b/debian/tests/glslang-dev
index 3f6af04a..bf103ca0 100755
--- a/debian/tests/glslang-dev
+++ b/debian/tests/glslang-dev
@@ -35,6 +35,17 @@ int main (void)
 }
 EOF
 
+cat > spirv.cpp <<'EOF'
+#include 
+
+int main (void)
+{
+  std::string s;
+  glslang::GetSpirvVersion(s);
+  return 0;
+}
+EOF
+
 # This is hard-coded because t

Bug#982519: [sprint] [RFS] libzstd 1.4.8+dfsg-2

[Étienne Mollier]

Control: tag -1 pending

Hi Sébastien, Hi Salvatore,

Salvatore Bonaccorso, on 2021-02-18 06:19:29 +0100:
> FTR, this has been fixed upstream.

Thanks the ping, I inlined upstream patch in the next iteration
of libzstd: 1.4.8+dfsg-2.  Upload will occur with urgency=high.
Changes are available on Salsa:

https://salsa.debian.org/med-team/libzstd

This package will need sponsored upload (unless Nilesh did grant
me upload permissions.  :)

Have a nice day,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/1, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#969907: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8

[Simon McVittie]

On Mon, 15 Feb 2021 at 12:07:13 +, Simon McVittie wrote:
> On Mon, 15 Feb 2021 at 12:03:35 +, Simon McVittie wrote:
> > I don't think this is actually about whether libpoppler-glib added new ABI
> > without bumping the shlibs version - it has a .symbols file that tracks
> > the version in which each public symbol was added.
> >
> > Instead, I think this is about private symbols and partial
> > upgrades. libpoppler102 and libpoppler-glib8 come from the same
> > source package, so libpoppler-glib8 is very likely to make assumptions
> > about private implementation details of the corresponding version of
> > libpoppler102; many of the source files glib/*.cc that get compiled into
> > libpoppler-glib8 have #include "poppler-private.h". This is fine if
> > everyone does an `apt upgrade` with no pinning, but breaks down if people
> > do arbitrary partial upgrades with pinning or interactively (leading to a
> > "Frankendebian" system).

Sorry, the proposed patch that I previously attached had the wrong bug
number in its Closes:. Please see attached for a corrected version.

Also available as a MR:
.

smcv
>From 215e53945323a7cee80e2bbc9a30ad209d7e77e1 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 15 Feb 2021 11:53:51 +
Subject: [PATCH] d/shlibs.local: Upgrade all binary packages in lockstep

Like many projects where one source package builds multiple binary
packages, poppler has private headers that share non-public interfaces
between its binary packages. Upgrading one binary package from this
source without upgrading the others is not something that its upstream
developers are ever going to test or support, and neither should we.

Closes: #969907
---
 debian/changelog| 12 
 debian/shlibs.local |  4 
 2 files changed, 16 insertions(+)
 create mode 100644 debian/shlibs.local

diff --git a/debian/changelog b/debian/changelog
index d65fa9f..54c96af 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+poppler (20.09.0-3.2) UNRELEASED; urgency=medium
+
+  * d/shlibs.local: Upgrade all binary packages in lockstep.
+Like many projects where one source package builds multiple binary
+packages, poppler has private headers that share non-public interfaces
+between its binary packages. Upgrading one binary package from this
+source without upgrading the others is not something that its upstream
+developers are ever going to test or support, and neither should we.
+(Closes: #969537)
+
+ -- Simon McVittie   Mon, 15 Feb 2021 11:44:22 +
+
 poppler (20.09.0-3.1) unstable; urgency=medium
 
   * debian/tests: make autopkgtests cross-test-friendly (Closes: #969726)
diff --git a/debian/shlibs.local b/debian/shlibs.local
new file mode 100644
index 000..af3275a
--- /dev/null
+++ b/debian/shlibs.local
@@ -0,0 +1,4 @@
+libpoppler 102 libpoppler102 (= ${binary:Version})
+libpoppler-cpp 0 libpoppler-cpp0v5 (= ${binary:Version})
+libpoppler-glib 8 libpoppler-glib8 (= ${binary:Version})
+libpoppler-qt5 1 libpoppler-qt5-1 (= ${binary:Version})
-- 
2.30.1

Bug#962788:

[Harald Dunkel]

Actually I cannot say. I haven't seen this problem in a while. And
/etc/init.d/nfs-common start does

PIPEFS_MOUNTPOINT=/run/rpc_pipefs
:
mkdir -p "$PIPEFS_MOUNTPOINT"
:
modprobe sunrpc nfs nfsd
mount -t rpc_pipefs rpc_pipefs $PIPEFS_MOUNTPOINT

providing the expected /run/rpc_pipefs/nfs, as it seems.

Regards
Harri

Bug#979326: ITP: crust -- SCP firmware for sunxi SoCs

[Jonas Smedegaard]

Quoting Nicolas Boulenguez (2021-02-18 09:56:51)
> > It seems crust-firmware is missing upstream and pristine-tar
> > branches.
> 
> Fixed for 'upstream/master'.
> Feel free to add pristine-tar, but I am avoiding its complexity now 
> that other tools are converging towards reproducibility by default.

Please consider document your workflow in debian/README.Source - 
preferably only a short sentence which referenced a URL to some shared 
place e.g. at https://wiki.debian.org/ more elaborately covering the 
chosen workflow, to encourage reuse.


 - 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#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8

[Pino Toscano]

Hi Simon,

In data lunedì 15 febbraio 2021 13:07:13 CET, Simon McVittie ha scritto:
> Control: retitle 969907 epdfinfo crashing with mismatched libpoppler102 and 
> libpoppler-glib8
> Control: tags 969907 + patch
> 
> Sorry, this reply should have gone to the clone in libpoppler-glib8,
> not to the archived original bug in epdfinfo (which I don't think was
> ever really an epdfinfo bug).
> 
> On Mon, 15 Feb 2021 at 12:03:35 +, Simon McVittie wrote:
> > I don't think this is actually about whether libpoppler-glib added new ABI
> > without bumping the shlibs version - it has a .symbols file that tracks
> > the version in which each public symbol was added.
> >
> > Instead, I think this is about private symbols and partial
> > upgrades. libpoppler102 and libpoppler-glib8 come from the same
> > source package, so libpoppler-glib8 is very likely to make assumptions
> > about private implementation details of the corresponding version of
> > libpoppler102; many of the source files glib/*.cc that get compiled into
> > libpoppler-glib8 have #include "poppler-private.h". This is fine if
> > everyone does an `apt upgrade` with no pinning, but breaks down if people
> > do arbitrary partial upgrades with pinning or interactively (leading to a
> > "Frankendebian" system).
> > 
> > If the upstream developers of poppler are asked to support a system where
> > libpoppler102 and libpoppler-glib8 are at different versions, I'm pretty
> > sure the first thing they will say is "don't". I think the same is
> > appropriate for downstreams.

Yes, this is correct.

> > In Cairo and Pango (which have a similar structure with multiple binary
> > packages making use of each other's implementation details), I added a
> > debian/shlibs.local to make sure the binary packages all get lockstep
> > dependencies. I think the same technique would be appropriate here. See
> > attached.

I honestly do not understand how this is even a problem, considering I
fixed this more than 5 years ago:
https://salsa.debian.org/freedesktop-team/poppler/-/commit/7929aa2d5ec9464fea755f622319d224787c4110
and indeed:

  $ apt-cache show libpoppler-glib8
  Package: libpoppler-glib8
  Source: poppler
  Version: 20.09.0-3.1
  [...]
  Depends: libpoppler102 (= 20.09.0-3.1), libc6 (>= 2.14), libcairo2 (>= 
1.12.0), libfreetype6 (>= 2.2.1), libglib2.0-0 (>= 2.41), libstdc++6 (>= 5.2)
  [...]

So the strict dependency is already in place. If I check the version
that was reported in the bug report, I see:

  $ debsnap -d . libpoppler-glib8 -a amd64 0.85.0-2
  $ dpkg -I libpoppler-glib8_0.85.0-2_amd64.deb
   Package: libpoppler-glib8
   Source: poppler
   Version: 0.85.0-2
   Depends: libpoppler95 (= 0.85.0-2), libc6 (>= 2.14), libcairo2 (>= 1.12.0), 
libfreetype6 (>= 2.2.1), libglib2.0-0 (>= 2.41), libstdc++6 (>= 5.2)

I'd rather think that the situation happened because
elpa-pdf-tools-server links both to libpoppler and libpoppler-glib:
the rebuild against poppler 20.09.0 (i.e. libpoppler102) make
elpa-pdf-tools-server link to libpoppler102 (forcing the newer
dependency to it), and setting an old dependency for libpoppler-glib
because there is no need for a newer version.

This was also a problem in case there was an incomplete dist-upgrade to
the newer poppler, so the newer libpoppler was pulled in but the newer
libpoppler-glib not. I remember having seen this in the past (when I
used to maintain poppler), but it happened once and indeed it was due
to an incomplete dist-upgrade. IMHO this will not happen in
oldstable->stable dist-upgrades, as everything will be build with the
newer libraries, and hopefully the dist-upgrade will be done fully.

Another contributing factor is that emacs-pdf-tools "abuses" the
libpoppler-glib internals, see server/poppler-hack.cc. I don't know
why it does that, and I'd rather see the actual issues fixed in
libpoppler-glib.

-- 
Pino Toscano

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

Bug#982987: tech-ctte: Call for votes for new CTTE member

[David Bremner]

Gunnar Wolf  writes:

> Package: tech-ctte
> Severity: normal
>
> Given that Philip Hands' term in the Technical Committee finished in
> December, I want first of all to thank him on behalf ot the rest of
> the Committee members for his good work during the term, and call for
> votes to accept a new TC member.
>
> So, voting will begin now, and end when the outcome is no longer in
> doubt, or one week from now.
>
> ===BEGIN
>
> The Technical Committee recommends that Christoph Berg  be
> appointed by the Debian Project Leader to the Technical Committee.
>
> A: Recommend to appoint Christoph Berg 
> B: Further Discussion
>
> ===END

I vote

  A > B



signature.asc
Description: PGP signature

Bug#982966: follow up info

[Richard Duivenvoorde]

See https://github.com/pygame/pygame/issues/2487

Pygame community/devs do not have resources to dive into older 1.9.6 issues, 
OR point to Wayland/Gnome.

Not sure what would be best for Debian: maybe remove it, with arguments:
- Python 3.9 and pygame 1.9.6 seems a strange combo
- it is pretty easy to install pygame 2.0.1 via pip
- you do not want to have packages in your distro which crash Wayland...

Bug#983012: plasma-desktop: installing plasma-desktop does not pull kmix

[Johannes Ranke]

 
> The links to /usr/share/autostart are missing their targets.
> 

OK, the problem with the links is a different bug

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

Regarding the Volume applet, there is a competition between plasma-pa and kmix

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

I had plasma-pm applet deactivated in order to avoid having two mixer applets 
in the systray. So the origin of the problem on my end was actually that kmix 
got lost in the upgrade to bullseye, because I had to reinstall KDE, as 
reported under #981597.

Thanks again for maintaining Qt/KDE in Debian!

Johannes

  

  

Bug#983026: libglib2.0-0: After update GDM3 does not longer start

[Michael Ott]

Package: libglib2.0-0
Version: 2.67.4-1
Severity: important

Dear Maintainer,

After update to 2.67.4 I cannot start GDM

Output in syslog:
Feb 18 05:14:25 k-c13 gnome-shell[2055]: invalid (NULL) pointer instance
Feb 18 05:14:25 k-c13 gnome-shell[2055]: g_signal_connect_data: assertion 
'G_TYPE_CHECK_INSTANCE (instance)' failed

with 2.67.3+git20210214-1 it works

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (710, 'unstable'), (670, 'testing'), (660, 'experimental'), (600, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64

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

Versions of packages libglib2.0-0 depends on:
ii  libc62.31-9
ii  libffi7  3.3-5
ii  libmount12.36.1-7
ii  libpcre3 2:8.39-13
ii  libselinux1  3.1-3
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages libglib2.0-0 recommends:
ii  libglib2.0-data   2.67.3+git20210214-1
ii  shared-mime-info  2.0-1
ii  xdg-user-dirs 0.17-2

libglib2.0-0 suggests no packages.

-- no debconf information

Bug#983026: libglib2.0-0: After update GDM3 does not longer start

[Philip Withnall]

This is https://gitlab.gnome.org/GNOME/glib/-/issues/2332

On Thu, 2021-02-18 at 10:57 +0100, Michael Ott wrote:
> Package: libglib2.0-0
> Version: 2.67.4-1
> Severity: important
> 
> Dear Maintainer,
> 
> After update to 2.67.4 I cannot start GDM
> 
> Output in syslog:
> Feb 18 05:14:25 k-c13 gnome-shell[2055]: invalid (NULL) pointer
> instance
> Feb 18 05:14:25 k-c13 gnome-shell[2055]: g_signal_connect_data:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> 
> with 2.67.3+git20210214-1 it works
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (710, 'unstable'), (670, 'testing'), (660,
> 'experimental'), (600, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, armhf, arm64
> 
> Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages libglib2.0-0 depends on:
> ii  libc6    2.31-9
> ii  libffi7  3.3-5
> ii  libmount1    2.36.1-7
> ii  libpcre3 2:8.39-13
> ii  libselinux1  3.1-3
> ii  zlib1g   1:1.2.11.dfsg-2
> 
> Versions of packages libglib2.0-0 recommends:
> ii  libglib2.0-data   2.67.3+git20210214-1
> ii  shared-mime-info  2.0-1
> ii  xdg-user-dirs 0.17-2
> 
> libglib2.0-0 suggests no packages.
> 
> -- no debconf information
> 

Bug#983027: r-bioc-mutationalpatterns: autopkgtest regression in testing: no package called ‘BSgenome.Hsapiens.UCSC.hg19’

[Paul Gevers]

Source: r-bioc-mutationalpatterns
Version: 2.0.0-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent (October 2020) change somewhere outside of your package
the autopkgtest of your package started to fail. I copied some of the
output at the bottom of this report. Can you please investigate the
situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-bioc-mutationalpatterns/10546520/log.gz

══ Failed tests

── Error (test-bin_mutation_density.R:11:1): (code run outside of
`test_that()`) ──
Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
Backtrace:
█
 1. └─base::library(ref_genome, character.only = TRUE)
test-bin_mutation_density.R:11:0
── Error (test-calculate_lesion_segretation.R:5:1): (code run outside of
`test_that()`) ──
Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
Backtrace:
█
 1. └─base::library(ref_genome, character.only = TRUE)
test-calculate_lesion_segretation.R:5:0
── Error (test-context_potential_damage_analysis.R:13:1): (code run
outside of `test_that()`) ──
Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
Backtrace:
█
 1. └─base::library(ref_genome, character.only = TRUE)
test-context_potential_damage_analysis.R:13:0
── Error (test-extract_signatures.R:19:1): (code run outside of
`test_that()`) ──
Error: Package 'ccfindR' is needed for variational_bayes to work. Please
either install it or use the regular NMF.
Backtrace:
█
 1. └─MutationalPatterns::extract_signatures(...)
test-extract_signatures.R:19:0
── Error (test-get_indel_context.R:10:1): (code run outside of
`test_that()`) ──
Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
Backtrace:
█
 1. └─base::library(ref_genome, character.only = TRUE)
test-get_indel_context.R:10:0
── Error (test-mut_context.R:10:1): (code run outside of `test_that()`)

Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
Backtrace:
█
 1. └─base::library(ref_genome, character.only = TRUE)
test-mut_context.R:10:0
── Error (test-mut_matrix_stranded.R:6:1): (code run outside of
`test_that()`) ──
Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
Backtrace:
█
 1. └─base::library(ref_genome, character.only = TRUE)
test-mut_matrix_stranded.R:6:0
── Error (test-mut_matrix.R:5:1): (code run outside of `test_that()`)
──
Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
Backtrace:
█
 1. └─base::library(ref_genome, character.only = TRUE) test-mut_matrix.R:5:0
── Error (test-mut_type_occurrences.R:10:1): (code run outside of
`test_that()`) ──
Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
Backtrace:
█
 1. └─base::library(ref_genome, character.only = TRUE)
test-mut_type_occurrences.R:10:0
── Error (test-plot_spectrum_region.R:10:1): (code run outside of
`test_that()`) ──
Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
Backtrace:
█
 1. └─base::library(ref_genome, character.only = TRUE)
test-plot_spectrum_region.R:10:0
── Error (test-plot_spectrum.R:11:1): (code run outside of
`test_that()`) ──
Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
Backtrace:
█
 1. └─base::library(ref_genome, character.only = TRUE)
test-plot_spectrum.R:11:0
── Error (test-plot_strand.R:10:1): (code run outside of `test_that()`)

Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
Backtrace:
█
 1. └─base::library(ref_genome, character.only = TRUE)
test-plot_strand.R:10:0
── Error (test-read_vcfs_as_granges.R:5:1): (code run outside of
`test_that()`) ──
Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
Backtrace:
█
 1. └─base::library(ref_genome, character.only = TRUE)
test-read_vcfs_as_granges.R:5:0
── Error (test-strand_occurrences.R:10:1): (code run outside of
`test_that()`) ──
Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
Backtrace:
█
 1. └─base::library(ref_genome, character.only = TRUE)
test-strand_occurrences.R:10:0
── Error (test-type_context.R:10:1): (code run outside of `test_that()`)
───
Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
Backtrace:
█
 1. └─base::library(ref_genome, character.only = TRUE)
test-type_context.R:10:0

[ FAIL 15 | WARN 0 | SKIP 0 | PASS 264 ]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983028: splint-data build failure: missing files

[Vincent Lefevre]

Source: splint
Version: 1:3.1.2+dfsg-4
Severity: serious
Tags: ftbfs
Justification: ftbfs

splint-data 1:3.1.2+dfsg-4 is missing, so that splint cannot be
installed.

https://buildd.debian.org/status/package.php?p=splint signals a
build failure for "all" (thus affecting splint-data):

make[1]: Entering directory '/<>'
dh_install -psplint-data -X.lcd -XMakefile
dh_install: warning: Cannot find (any matches for) "usr/share/splint/imports/" 
(tried in ., debian/tmp)

dh_install: warning: splint-data missing files: usr/share/splint/imports/
dh_install: warning: Cannot find (any matches for) "usr/share/splint/lib/" 
(tried in ., debian/tmp)

dh_install: warning: splint-data missing files: usr/share/splint/lib/
dh_install: error: missing files, aborting
make[1]: *** [debian/rules:52: override_dh_install] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:23: binary-indep] Error 2

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

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

-- no debconf information

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

Bug#983029: lava: flaky autopkgtest: lava-server-gunicorn service is not active

[Paul Gevers]

Source: lava
Version: 2020.12-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails often (since
around January on amd64 and arm64) [1].

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

I copied the output at the bottom of this report.

Paul

[1] https://ci.debian.net/packages/l/lava/testing/amd64/

https://ci.debian.net/data/autopkgtest/testing/amd64/l/lava/10400827/log.gz

+ cd /root
+ lava-server manage check
System check identified no issues (0 silenced).
+ lava-server manage check --deploy
SystemCheckError: System check identified some issues:

ERRORS:
lava services: lava-server-gunicorn service is not active.

INFOS:
debian pkg: 'lava-coordinator' not installed from a Debian package

System check identified 2 issues (2 silenced).
autopkgtest [12:35:59]: test management: ---]
autopkgtest [12:35:59]: test management:  - - - - - - - - - - results -
- - - - - - - - -
management   FAIL non-zero exit status 1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983030: googletest: please backport new version to buster-backports

[Luca Boccassi]

Source: googletest
Version: 1.10.0.20201025-1.1
Severity: wishlist

Dear Maintainer(s),

I would like to backport a new package to buster-backports (sdbus-cpp), 
but it requires a newer version of googletest to compile (it uses
GTEST_SKIP).

If you have time, I'd greatly appreciate if you could upload the
current version of googletest from testing to buster-backports. I just
did a quick test and it compiles without any changes.

I am more than happy to take care of it myself via an NMU if you lack
the time/interest.

Thank you!

-- 
Kind regards,
Luca Boccassi


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

Bug#983031: konqueror segfaults on starting

[Joe Rowan]

Package: konqueror
Version: 4:20.12.0-4
Severity: normal

Dear Maintainer,

I have not used konqueror for probably more than a year. I ran it from the Xfce
menu and it would not start, with a missing file.
I ran 'apt reinstall konqueror', and six additional new packages were
installed.
Konqueror now starts but immediately segfaults.



>From konqueror error box:

Executable: konqueror PID: 5083 Signal: Segmentation fault (11) Time:
18/02/2021 11:19:41 GMT

>From terminal:

~$ konqueror
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = konqueror path = /usr/bin pid = 5167
KCrash: Arguments: /usr/bin/konqueror
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi

[1]+  Stopped konqueror
~$ QSocketNotifier: Invalid socket 11 and type 'Read', disabling...

[1]+  Exit 253konqueror


The file /usr/lib/x86_64-linux-gnu/libexec/drkonqi exists, root:root 755

The same error occurs if run with sudo.

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages konqueror depends on:
ii  dolphin  4:20.12.2-1
ii  install-info 6.7.0.dfsg.2-6
ii  kio  5.78.0-4
ii  libc62.31-9
ii  libkf5archive5   5.78.0-2
ii  libkf5bookmarks5 5.78.0-2
ii  libkf5codecs55.78.0-2
ii  libkf5completion55.78.0-3
ii  libkf5configcore55.78.0-4
ii  libkf5configgui5 5.78.0-4
ii  libkf5configwidgets5 5.78.0-2
ii  libkf5coreaddons55.78.0-2
ii  libkf5crash5 5.78.0-3
ii  libkf5dbusaddons55.78.0-2
ii  libkf5i18n5  5.78.0-2
ii  libkf5iconthemes55.78.0-2
ii  libkf5itemviews5 5.78.0-2
ii  libkf5jobwidgets55.78.0-2
ii  libkf5kcmutils5  5.78.0-3
ii  libkf5kiocore5   5.78.0-4
ii  libkf5kiofilewidgets55.78.0-4
ii  libkf5kiogui55.78.0-4
ii  libkf5kiowidgets55.78.0-4
ii  libkf5konq6  4:20.12.0-4
ii  libkf5parts5 5.78.0-3
ii  libkf5service-bin5.78.0-2
ii  libkf5service5   5.78.0-2
ii  libkf5sonnetcore55.78.0-2
ii  libkf5sonnetui5  5.78.0-2
ii  libkf5textwidgets5   5.78.0-2
ii  libkf5wallet-bin 5.78.0-2
ii  libkf5wallet55.78.0-2
ii  libkf5widgetsaddons5 5.78.0-2
ii  libkf5windowsystem5  5.78.0-2
ii  libkf5xmlgui55.78.0-2
ii  libqt5core5a 5.15.2+dfsg-4
ii  libqt5dbus5  5.15.2+dfsg-4
ii  libqt5gui5   5.15.2+dfsg-4
ii  libqt5network5   5.15.2+dfsg-4
ii  libqt5printsupport5  5.15.2+dfsg-4
ii  libqt5webenginecore5 5.15.2+dfsg-3
ii  libqt5webenginewidgets5  5.15.2+dfsg-3
ii  libqt5widgets5   5.15.2+dfsg-4
ii  libqt5x11extras5 5.15.2-2
ii  libqt5xml5   5.15.2+dfsg-4
ii  libstdc++6   10.2.1-6

Versions of packages konqueror recommends:
ii  kfind  4:20.12.0-1

Versions of packages konqueror suggests:
pn  konq-plugins  

Bug#983012: plasma-desktop: installing plasma-desktop does not pull kmix

[Norbert Preining]

On Thu, 18 Feb 2021, Johannes Ranke wrote:
> I had plasma-pm applet deactivated in order to avoid having two mixer applets 
> in the systray. So the origin of the problem on my end was actually that kmix 
> got lost in the upgrade to bullseye, because I had to reinstall KDE, as 
> reported under #981597.

Good that this is solved, too. So again, can we close this bug, or do
you think there is anything necessary to be done?

Best regards

Norbert

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

Bug#981597: plasma-desktop: Same problem on a system set up with stretch

[Norbert Preining]

> something more specific on my system preventing the smooth upgrade.

Good to hear, thanks for reporting back.

I tend to close this bug ... any objections from other participants
here?

Best

Norbert

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

Bug#982950: ssh.service starts sshd before network is online: please switch to After=network-online.target instead of just After=network.target

[Timo Weingärtner]

Hallo,

17.02.21 21:42 Chris Hofstaedtler:
> * Thomas Goirand  [210217 20:38]:
> > # cat /etc/systemd/system/ssh.service.d/override.conf
> > [Unit]
> > After=network-online.target auditd.service
> > 
> > But IMO, this is very wrong to mandate doing this, and not having ssh
> > connectivity after a reboot, is kind of a grave problem.
> > 
> > So, could you hard-wire this in the openssh-server package directly, so
> > Debian users can avoid such an override? Indeed After=network.target
> > doesn't tell you that network is ready. After=network-online.target does,
> > and that's IMO what the ssh daemon should be using.
> 
> But if you do this, you'll end up delaying start of sshd for up to
> 120seconds in error cases. And even then, you might not get what you
> want (if you read systemd-networkd-wait-online.service(8)
> carefully).
> 
> Services that use After=network-online.target are generally broken,
> please do not introduce that.

Seconded. Just consider a node where one link is down on boot and you would 
have to wait such a long time until you can examine the problem via ssh.

> As discussed already, IP_FREEBIND is a thing. The system-wide sysctl
> is a common workaround, especially for "bgp-on-the-host" setups, for
> all sorts of servers/daemons.

That should work; systemd-sysctl.service is ordered before ssh.

Another option is in #965132 (ssh@.socket), but then the fix for #946180 and 
#934663 (RuntimeDirectoryPreserve=yes for ssh*.service) is also needed.


Grüße
Timo

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965132
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946180
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934663

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

Bug#981597: plasma-desktop: Same problem on a system set up with stretch

[Johannes Ranke]

> I tend to close this bug ... any objections from other participants
> here?

I'd keep it open, as it is not clear where the problem comes from and it was 
observed on two independent systems. Maybe someone can figure it out before the 
official release.

Johannes

Bug#964275: flowblade: the package is missing the helpfiles

[Gürkan Myczko]

Where do you have your version from?

Can't find it at:
https://packages.debian.org/search?keywords=flowblade

apt-cache policy flowblade says what?

Best,

Bug#983032: xkeyboard-config: please consider including rules for "custom" layout in bullseye

[Andrej Shadura]

Package: src:xkeyboard-config
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

The upstream has accepted an MR from Peter Hutterer to add "custom"
layout to the XML rules file. This allows users to easily install their
own keyboard layouts without having to patch the package or use other
less reliable methods (e.g. xkbcomp is incompatible with GNOME and DEs
using its gnome-settings-daemon).

[1]: 
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/merge_requests/189
[2]: 
https://discourse.gnome.org/t/how-to-stop-gnome-messing-with-the-keyboard-layout/5271

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSD3NF/RLIsyDZW7aHoRGtKyMdyYQUCYC5gTgAKCRDoRGtKyMdy
YXo0AP9TOqqNfZ1L0USgeF5hpBE7K1hZYSNyRMb6S/e+aFG7IQEA/7JOhISC+jM7
iZHjq+urbXsnIAItKe6Tg+a2v9zNnw8=
=VBrx
-END PGP SIGNATURE-

Bug#982879: Acknowledgement (Artifacts in x2go rendering connecting to testing from a buster client)

[Francesco P. Lovergine]

On Thu, Feb 18, 2021 at 11:22:27AM +0100, Francesco P. Lovergine wrote:

On Thu, Feb 18, 2021 at 10:56:04AM +0100, Francesco P. Lovergine wrote:
Update: I tested also with a vagrant installation of a testing64 vm 
(from scratch), under a virtualbox provider. It gives exactly the 
same result. IMHO this bug should be raised to important or grave 
because could render unusable the x2goserver in bullseye for many 
(if not most) use cases :-( I still did not check the use of 
bullseye from a bullseye client or other platforms.




... and it gives the same artifacts using a bullseye client (which 
works perfectly while connecting a buster x2go server). So this is 
definitively an issue of the x2goserver in bullseye.




Ok, workaround: disable composite rendering, which could be done in both xfce 
and mate settings, for instance. 


--
Francesco P. Lovergine

Bug#983033: golang-github-revel-revel: please make the build reproducible

[Chris Lamb]

Source: golang-github-revel-revel
Version: 1.0.0-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
golang-github-revel-revel could not be built reproducibly.

This is because during the test phase it appends various bits of
logging info to a file called "none" which is then installed under 
/usr/share/gocode/src/github.com/revel/revel.

Patch attached that removes this (presumably unnecessary) file prior
to the binary package being created.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2021-02-18 12:54:25.624261668 +
--- b/debian/rules  2021-02-18 12:59:08.292110927 +
@@ -7,3 +7,6 @@
 
 execute_after_dh_auto_configure:
cp -av $(CURDIR)/debian/go/src _build/src/github.com/revel/revel/vendor
+
+execute_after_dh_auto_test:
+   find _build -name "none" -delete

Bug#983034: plasma-workspace-wayland: hanging in ksplashqml

[Heinrich Schuchardt]

Package: plasma-workspace-wayland
Version: 4:5.20.5-3
Severity: grave

Dear Maintainer,

from SDDM I try to start a Wayland KDE session.

The whole GUI freezes.
CTRL-ALT-FN2 cannot be used to open a terminal session.
SSH login is still possible.

Top reports 100 % CPU load for ksplashqml.

Mainboard is MacchiatoBIN with 16 GiB RAM.
Video card is GeForce GT 710 with nouveau driver.

Kernel command line:
BOOT_IMAGE=/vmlinuz-5.10.0-3-arm64 root=UUID= ro quiet

The problem only occurs in Wayland sessions. X11 KDE is working fine.

Best regards

Heinrich Schuchardt

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

Kernel: Linux 5.10.0-3-arm64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-workspace-wayland depends on:
ii  kwayland-integration  5.20.5-1
ii  kwin-wayland  4:5.20.5-1
ii  libc6 2.31-9
ii  libkf5configcore5 5.78.0-4
ii  libkf5coreaddons5 5.78.0-2
ii  libkworkspace5-5  4:5.20.5-3
ii  libqt5core5a  5.15.2+dfsg-4
ii  libqt5dbus5   5.15.2+dfsg-4
ii  libstdc++610.2.1-6
ii  plasma-workspace  4:5.20.5-3
ii  qtwayland55.15.2-2

plasma-workspace-wayland recommends no packages.

plasma-workspace-wayland suggests no packages.

-- no debconf information

Bug#983035: Missing dependency on dbus-x11

[Francesco P. Lovergine]

Package: xfce4
Version: 4.16
Severity: normal

I found a missing dependency on /usr/bin/dbus-launch (dbus-x11) in bullseye, somewhere. 
Not sure this is an xfce4 issue specifically, feel free to reassign to another proper package.


In order to replicate the problem: I just installed from scratch a bullseye current image 
(debian/testing64) in vagrant, with virtualbox provider, an upgraded it.  Then 
installed xfce4i (the metapackage) and started lightdm. After that, the user 
cannot login and start a session due to missing dbus-launch, with appropriate 
message at screen. Installing dbus-x11 solves the problem.


-cheers

--
Francesco P. Lovergine

Bug#983036: RFS: sasm/3.12.1-1 -- simple IDE for NASM, GAS and FASM assembly languages

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: sasm
   Version : 3.12.1-1
   Upstream Author : Dmitriy Manushin 
 * URL : https://github.com/Dman95/SASM
 * License : GPL-3+, BSD-3-clause
 * Vcs : https://salsa.debian.org/myczko-guest/sasm
   Section : devel

It builds those binary packages:

  sasm - simple IDE for NASM, GAS and FASM assembly languages

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/s/sasm/sasm_3.12.1-1.dsc


Changes since the last upload:

 sasm (3.12.1-1) experimental; urgency=medium
 .
   * New upstream version.
   * d/copyright: bump year.

Regards,
--
  Gürkan Myczko

Bug#983037: RFS: logswan/2.1.10-1 -- fast Web log analyzer using probabilistic data structures

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: logswan
   Version : 2.1.10-1
   Upstream Author : Frederic Cambus 
 * URL : https://github.com/fcambus/logswan
 * License : BSD-2-clause
 * Vcs : https://salsa.debian.org/myczko-guest/logswan
   Section : web

It builds those binary packages:

  logswan - fast Web log analyzer using probabilistic data structures

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/l/logswan/logswan_2.1.10-1.dsc


Changes since the last upload:

 logswan (2.1.10-1) experimental; urgency=medium
 .
   * New upstream version.
   * d/copyright: bump years.

Regards,
--
  Gürkan Myczko

Bug#983038: RFS: ansilove/4.1.5-1 -- ANSI and ASCII art to PNG converter

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: ansilove
   Version : 4.1.5-1
   Upstream Author : Frederic Cambus 
 * URL : https://www.ansilove.org
 * License : BSD-2-clause, BSD-2-Clause, ISC
 * Vcs : https://salsa.debian.org/myczko-guest/ansilove
   Section : graphics

It builds those binary packages:

  ansilove - ANSI and ASCII art to PNG converter

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/a/ansilove/ansilove_4.1.5-1.dsc


Changes since the last upload:

 ansilove (4.1.5-1) experimental; urgency=medium
 .
   * New upstream version.
   * d/copyright: bump years.

Regards,
--
  Gürkan Myczko

Bug#983039: RFS: flowblade/2.8.0.2-1 [RC] -- non-linear video editor

[Gürkan Myczko]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: flowblade
   Version : 2.8.0.2-1
   Upstream Author : https://github.com/jliljebl/flowblade/issues
 * URL : https://github.com/jliljebl/flowblade
 * License : GPL-3+, GPL-2+, CC-BY-3.0
 * Vcs : https://salsa.debian.org/multimedia-team/flowblade
   Section : video

It builds those binary packages:

  flowblade - non-linear video editor

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/f/flowblade/flowblade_2.8.0.2-1.dsc


Changes since the last upload:

 flowblade (2.8.0.2-1) experimental; urgency=medium
 .
   * Merge debian/*. (Closes: #980219)
   * New upstream version.
   * Unquote %s mailcap entry. (Closes: #982952)
   * d/copyright: drop unused paragraph.

Regards,
--
  Gürkan Myczko

Bug#983040: rdkit: doesn't ship with inchi support enabled

[Michael Banck]

Package: rdkit
Severity: wishlist

Hi Francois,

On Thu, Feb 18, 2021 at 02:48:49PM +0900, Francois Berenger wrote:
> ---
> python3
> import rdkit
> from rdkit import Chem
> rdkit.Chem.INCHI_AVAILABLE
> # False
> ---
> 
> It would be nice if INCHI support is enabled
> when building rdkit for Debian.
> 
> If you point me to the bugtracker where I should report
> this (not found after 10min of searching...), I might report it there.

What you can do is email sub...@bugs.debian.org (in BCC on this mail)
and use the above pseudo-headers, or use the reportbug tool available in
Debian.
 
> inchi is a pretty standard and common format for people dealing with
> chemical data.

Thanks, I'll look into it. However, the next Debian release is
feature-frozen already so not clear whether it will/can make it in.


Michael

Bug#983040: [Debichem-devel] Bug#983040: rdkit: doesn't ship with inchi support enabled

[Andrius Merkys]

Hello,

On 2021-02-18 15:27, Michael Banck wrote:
> On Thu, Feb 18, 2021 at 02:48:49PM +0900, Francois Berenger wrote:
>> ---
>> python3
>> import rdkit
>> from rdkit import Chem
>> rdkit.Chem.INCHI_AVAILABLE
>> # False
>> ---
>>
>> It would be nice if INCHI support is enabled
>> when building rdkit for Debian.
>>
>> If you point me to the bugtracker where I should report
>> this (not found after 10min of searching...), I might report it there.

This has already been reported as [#964773]. In short, rdkit cannot be
built with INCHI support in Debian due to DFSG reasons (please see the
original bug report for explanation).

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

Best,
Andrius

Bug#983027: r-bioc-mutationalpatterns: autopkgtest regression in testing: no package called ‘BSgenome.Hsapiens.UCSC.hg19’

[Andreas Tille]

Hi folks,

I think this is a consequence of running autopkgtest-pkg-r blindly for all
bioc packages since we are adding

   Testsuite: autopkgtest-pkg-r

automatically to all packages.  The "manual" test is prevented by simply
renaming the debian/tests/control file to

   
https://salsa.debian.org/r-pkg-team/r-bioc-mutationalpatterns/-/blob/master/debian/tests/control_needs_large_data

and thus documenting the issue.

The easiest cure would be to simply remove the Testsuite field
from debian/control.  However, routine-update would re-add this
(which I think is a sensible thing to do) and if we use a comment
to prevent routine-update to add this field this in turn is
removed again by dh-update-R (called by run-unit-test).  This
is all not so elegant.

I'm currently thinking about some file

   debian/tests/autopkgtest-pkg-r.hook

which will be executed after

   
https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/scripts/pkg-r-autopkgtest#L28

This could exclude or tweak some test files and in the case below simply
remove those tests that are trying to load not yet packaged stuff (which
is for a reason since these are just big data files).

What do you think?

Kind regards

 Andreas.

On Thu, Feb 18, 2021 at 12:33:47PM +0100, Paul Gevers wrote:
> Source: r-bioc-mutationalpatterns
> Version: 2.0.0-2
> X-Debbugs-CC: debian...@lists.debian.org
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: regression
> 
> Dear maintainer(s),
> 
> With a recent (October 2020) change somewhere outside of your package
> the autopkgtest of your package started to fail. I copied some of the
> output at the bottom of this report. Can you please investigate the
> situation and fix it?
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-bioc-mutationalpatterns/10546520/log.gz
> 
> ══ Failed tests
> 
> ── Error (test-bin_mutation_density.R:11:1): (code run outside of
> `test_that()`) ──
> Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
> Backtrace:
> █
>  1. └─base::library(ref_genome, character.only = TRUE)
> test-bin_mutation_density.R:11:0
> ── Error (test-calculate_lesion_segretation.R:5:1): (code run outside of
> `test_that()`) ──
> Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
> Backtrace:
> █
>  1. └─base::library(ref_genome, character.only = TRUE)
> test-calculate_lesion_segretation.R:5:0
> ── Error (test-context_potential_damage_analysis.R:13:1): (code run
> outside of `test_that()`) ──
> Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
> Backtrace:
> █
>  1. └─base::library(ref_genome, character.only = TRUE)
> test-context_potential_damage_analysis.R:13:0
> ── Error (test-extract_signatures.R:19:1): (code run outside of
> `test_that()`) ──
> Error: Package 'ccfindR' is needed for variational_bayes to work. Please
> either install it or use the regular NMF.
> Backtrace:
> █
>  1. └─MutationalPatterns::extract_signatures(...)
> test-extract_signatures.R:19:0
> ── Error (test-get_indel_context.R:10:1): (code run outside of
> `test_that()`) ──
> Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
> Backtrace:
> █
>  1. └─base::library(ref_genome, character.only = TRUE)
> test-get_indel_context.R:10:0
> ── Error (test-mut_context.R:10:1): (code run outside of `test_that()`)
> 
> Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
> Backtrace:
> █
>  1. └─base::library(ref_genome, character.only = TRUE)
> test-mut_context.R:10:0
> ── Error (test-mut_matrix_stranded.R:6:1): (code run outside of
> `test_that()`) ──
> Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
> Backtrace:
> █
>  1. └─base::library(ref_genome, character.only = TRUE)
> test-mut_matrix_stranded.R:6:0
> ── Error (test-mut_matrix.R:5:1): (code run outside of `test_that()`)
> ──
> Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
> Backtrace:
> █
>  1. └─base::library(ref_genome, character.only = TRUE) test-mut_matrix.R:5:0
> ── Error (test-mut_type_occurrences.R:10:1): (code run outside of
> `test_that()`) ──
> Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
> Backtrace:
> █
>  1. └─base::library(ref_genome, character.only = TRUE)
> test-mut_type_occurrences.R:10:0
> ── Error (test-plot_spectrum_region.R:10:1): (code run outside of
> `test_that()`) ──
> Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
> Backtrace:
> █
>  1. └─base::library(ref_genome, character.only = TRUE)
> test-plot_spectrum_region.R:10:0
> ── Error (test-plot_spectrum.R:11:1): (code run outside of
> `test_that()`) ──
> Error: there is no package called ‘BSgenome.Hsapiens.UCSC.hg19’
> Backtrace:
> █
>  1. └─base::library(ref_genome, charac

Bug#983041: php-imagick: autopkgtest regression: cd: too many arguments

[Paul Gevers]

Source: php-imagick
Version: 3.4.4+php8.0+3.4.4-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of php-imagick the autopkgtest of php-imagick fails
in testing when that autopkgtest is run with the binary packages of
php-imagick from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
php-imagickfrom testing3.4.4+php8.0+3.4.4-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=php-imagick

https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-imagick/10526591/log.gz

autopkgtest [13:11:38]: test command1: cd imagick-*/tests && phpunit
--verbose .
autopkgtest [13:11:38]: test command1: [---
bash: line 1: cd: too many arguments
autopkgtest [13:11:38]: test command1: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983042: kdeconnect: Please redesign the sc-apps-kdeconnectindicatordark icon

[Bohdan Horbeshko]

Package: kdeconnect
Version: 20.04.3-1
Severity: wishlist

Dear Maintainer,

the current icon looks very similar to a broken image icon. I thought it
was broken for several months, until I squinted and found out that × is
actually K. Though when I glance over it, I still subconciously percieve
it as a broken image icon. Please redesign it to something more contrast
and distinct; the light version of the icon does not have this issue.


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

Kernel: Linux 5.8.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_CRAP, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kdeconnect depends on:
ii  kde-cli-tools 4:5.17.5-2
ii  kio   5.70.1-1
ii  libc6 2.31-3
ii  libfakekey0   0.3+git20170516-2
ii  libkf5configcore5 5.70.0-1
ii  libkf5configwidgets5  5.70.0-2
ii  libkf5coreaddons5 5.70.0-2
ii  libkf5dbusaddons5 5.70.0-1
ii  libkf5i18n5   5.70.0-1
ii  libkf5iconthemes5 5.70.0-1
ii  libkf5kcmutils5   5.70.0-1
ii  libkf5kiocore55.70.1-1
ii  libkf5kiofilewidgets5 5.70.1-1
ii  libkf5kiowidgets5 5.70.1-1
ii  libkf5notifications5  5.70.0-1
ii  libkf5people5 5.70.0-1
ii  libkf5pulseaudioqt2   1.2-2
ii  libkf5service-bin 5.70.0-1
ii  libkf5service55.70.0-1
ii  libkf5waylandclient5  4:5.70.0-1
ii  libkf5widgetsaddons5  5.70.0-1
ii  libqca-qt5-2  2.3.1-1
ii  libqca-qt5-2-plugins  2.3.1-1
ii  libqt5core5a  5.14.2+dfsg-6
ii  libqt5dbus5   5.14.2+dfsg-6
ii  libqt5gui55.14.2+dfsg-6
ii  libqt5multimedia5 5.14.2-3
ii  libqt5network55.14.2+dfsg-6
ii  libqt5qml55.14.2+dfsg-3
ii  libqt5quick5  5.14.2+dfsg-3
ii  libqt5widgets55.14.2+dfsg-6
ii  libqt5x11extras5  5.14.2-2
ii  libstdc++610.2.0-9
ii  libx11-6  2:1.6.12-1
ii  libxtst6  2:1.2.3-1
ii  plasma-framework  5.70.1-1
ii  qml-module-org-kde-kirigami2  5.70.0-1
ii  qml-module-org-kde-people 5.70.0-1
ii  qml-module-qtquick-controls   5.14.2-2
ii  qml-module-qtquick-controls2  5.14.2+dfsg-2
ii  qml-module-qtquick-layouts5.14.2+dfsg-3
ii  qml-module-qtquick2   5.14.2+dfsg-3
ii  sshfs 3.7.0+repack-1

kdeconnect recommends no packages.

Versions of packages kdeconnect suggests:
pn  python3-nautilus  

-- no debconf information

Bug#983041: php-imagick: autopkgtest regression: cd: too many arguments

[Ondřej Surý]

> 
> On 18. 2. 2021, at 14:39, Paul Gevers  wrote:
> 
> autopkgtest [13:11:38]: test command1: cd imagick-*/tests && phpunit

Gah, whoever did this (well, and I definitely have merged it, so it’s my fault 
anyway),
it’s wrong, it needs to iterate through the directories.

Thanks for the poke.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org



signature.asc
Description: Message signed with OpenPGP

Bug#32877: Hey girl you

[Danielle]

Sent from my iPhone

Bug#979326: ITP: crust -- SCP firmware for sunxi SoCs

[Nicolas Boulenguez]

> > Feel free to add pristine-tar, but I am avoiding its complexity now
> > that other tools are converging towards reproducibility by default.

> Please consider document your workflow in debian/README.Source -
> preferably only a short sentence which referenced a URL to some shared
> place e.g. at https://wiki.debian.org/ more elaborately covering the
> chosen workflow, to encourage reuse.

People that *do* expose preferences for non-standard tools like
pristine-tar should document their choice.  I try to avoid unneeded
steps for new contributors.

Bug#983042: kdeconnect: Please redesign the sc-apps-kdeconnectindicatordark icon

[Pino Toscano]

Hi Bohdan,

In data giovedì 18 febbraio 2021 14:40:52 CET, Bohdan Horbeshko ha scritto:
> Package: kdeconnect
> Version: 20.04.3-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> the current icon looks very similar to a broken image icon. I thought it
> was broken for several months, until I squinted and found out that × is
> actually K. Though when I glance over it, I still subconciously percieve
> it as a broken image icon. Please redesign it to something more contrast
> and distinct; the light version of the icon does not have this issue.

Please note that we do not do upstream development, and this kind of
change (i.e. artwork) ought to be done by upstream, either in kdeconnect
itself or in the breeze icon theme.

Please note also:

> Kernel: Linux 5.8.0-3-amd64 (SMP w/2 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_CRAP, 
> TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
> LANGUAGE=ru_UA:ru
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages kdeconnect depends on:
> ii  kde-cli-tools 4:5.17.5-2
> ii  kio   5.70.1-1
> ii  libc6 2.31-3
> ii  libfakekey0   0.3+git20170516-2
> ii  libkf5configcore5 5.70.0-1

kernel 5.8.0, Frameworks 5.70, Plasma 5.17, and kdeconnect 20.04:
your system is ~6 month behind of the current Debian testing.
Please fully dist-update your system when reporting bugs for
unstable or testing, as otherwise there is the risk of reporting
stale issues.

-- 
Pino Toscano

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

Bug#983040: [Debichem-devel] Bug#983040: rdkit: doesn't ship with inchi support enabled

[Michael Banck]

tags 983040 +wontfix
merge 983040 964773
thanks

On Thu, Feb 18, 2021 at 03:35:21PM +0200, Andrius Merkys wrote:
> On 2021-02-18 15:27, Michael Banck wrote:
> > On Thu, Feb 18, 2021 at 02:48:49PM +0900, Francois Berenger wrote:
> >> ---
> >> python3
> >> import rdkit
> >> from rdkit import Chem
> >> rdkit.Chem.INCHI_AVAILABLE
> >> # False
> >> ---
> >>
> >> It would be nice if INCHI support is enabled
> >> when building rdkit for Debian.
> >>
> >> If you point me to the bugtracker where I should report
> >> this (not found after 10min of searching...), I might report it there.
> 
> This has already been reported as [#964773]. In short, rdkit cannot be
> built with INCHI support in Debian due to DFSG reasons (please see the
> original bug report for explanation).
> 
> [#964773] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964773

Thanks Andrius for the pointer. By the way, I've looked at the INCHI
licenes again, and clause 3 allows to use the INCHI code under the GPL,
was it considered to just go that route in Debian or is there some other
loophole I don't see?

Maybe RDKit could be changed in some way to build against both INCHI
versions, but if that is possible at all, it sounds like a major
project.

Francois, what might help here is opening an issue with RDKit's GitHub
issue tracker and asking them about supporting both versions.


Michael

Bug#981976: in version 2.1.0-2

[David Kunz]

found 981976 2.1.0-2
thanks

Hi,

this bug has been found in above version.

Regards,
David

Bug#983043: Failed to initialize GENET properly on RPI4 (arm64)

[Jeff Forsyth]

Package: installation-reports

Boot method: netboot
Image version: 
https://d-i.debian.org/daily-images/arm64/daily/netboot/debian-installer/arm64/linux
 2021-02-18 02:07 26M
Date: 2021-02-18 14:05:00

Machine: RPi4
Processor:
Memory: 4GiB
Partitions:

Output of lspci -knn (or lspci -nn):

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [E]
Detect media:   [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[E]

Comments/Problems:

RPi 4 with 4GiB Ram.  System is netbooted using DNSMASQ, RPI-UEFI and iPXE.
Netboot Debian Installer for arm64 starts and fails at configuring the
genet ethernet card.
I have attempted to remove and reinstall the genet driver.  No effect.
ip link show has the card identified as enabcm6e4ei0.
I can put an address on the card using ip addr add.
ip link set dev down works
ip link set dev up fails with SIOCSIFFLAGS: No such device




-- 
"Non sibi, sed patriae"

Bug#982164: RFS: geda-gaf/1.10.2-2 [ITA] -- GPL EDA -- Electronics design software

[Kai-Martin Knaak]

Following the the suggestion by Roland, I moved the xorn executable to
gedalib-common. In addition I removed the closes clause for #936593 and
closed #966736 in the changelog. Lintian complained about inconsistent
licenses. So I made debian/copyright aware that certain files are GFDL
licensed (with no invariant parts).
 
I just uploaded a new version of the source package to debian-mentors
and made sure, the sponsor search flag is still set:
https://mentors.debian.net/package/geda-gaf/

---<)kaimartin(>---


pgpZGetl0LOUg.pgp
Description: OpenPGP digital signature

Bug#983044: Please update to ssh-import-id 5.11

[Robie Basak]

Source: ssh-import-id
Version: 5.10-1
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi,

I just uploaded ssh-import-id 5.11 to Ubuntu. I think it's suitable for
upload to Debian also. You can grab it from:

dget 
https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/ssh-import-id/5.11-0ubuntu1/ssh-import-id_5.11-0ubuntu1.dsc

I expect this will need to wait until bookworm though.

Robie


signature.asc
Description: PGP signature

Bug#981597: plasma-desktop: Same problem on a system set up with stretch

[Johannes Ranke]

I dug up my upgrade transcript, and it shows, after the first apt-upgrade

$ apt full-upgrade

Some packages could not be installed...
...

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 libc6-dev : Beschädigt: libgcc-8-dev (< 8.4.0-2~) aber 8.3.0-6 soll 
installiert werden

...

i.e. the installation candidate for libc6-dev had a "Breaks" on libgcc-8-dev 
(< 8.4.0-2~) but 8.3.0-6 was to be installed.

I just checked and libgcc-8-dev is only present in buster (8.3.0-6), but not 
in bullseye.

I then "solved" it by removing libgcc8-dev which removed almost all of KDE 
which I then reinstalled without problems.

Normally (in my pbuilder chroot with less packages installed) apt full-upgrade 
will remove libgcc-8-dev.

It seems some package on my system still wanted libgcc-8-dev. I assume it was 
just a temporary problem, maybe caused by an incomplete migration of packages 
to testing. From my part, the bug can be closed.

Johannes

Bug#983042: kdeconnect: Please redesign the sc-apps-kdeconnectindicatordark icon

[Горбешко Богдан]

On 18.02.2021 15:53, Pino Toscano wrote:

Hi Bohdan,

In data giovedì 18 febbraio 2021 14:40:52 CET, Bohdan Horbeshko ha scritto:

Package: kdeconnect
Version: 20.04.3-1
Severity: wishlist

Dear Maintainer,

the current icon looks very similar to a broken image icon. I thought it
was broken for several months, until I squinted and found out that × is
actually K. Though when I glance over it, I still subconciously percieve
it as a broken image icon. Please redesign it to something more contrast
and distinct; the light version of the icon does not have this issue.

Please note that we do not do upstream development, and this kind of
change (i.e. artwork) ought to be done by upstream, either in kdeconnect
itself or in the breeze icon theme.

Please note also:


Kernel: Linux 5.8.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_CRAP, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kdeconnect depends on:
ii  kde-cli-tools 4:5.17.5-2
ii  kio   5.70.1-1
ii  libc6 2.31-3
ii  libfakekey0   0.3+git20170516-2
ii  libkf5configcore5 5.70.0-1

kernel 5.8.0, Frameworks 5.70, Plasma 5.17, and kdeconnect 20.04:
your system is ~6 month behind of the current Debian testing.
Please fully dist-update your system when reporting bugs for
unstable or testing, as otherwise there is the risk of reporting
stale issues.

I had checked the upstream repository before reporting this issue 
(that's where I got the filename), it still contains this version of the 
icon. Reporting here, because I couldn't find an issue tracker on KDE 
GitLab.

Bug#983040: [Debichem-devel] Bug#983040: Bug#983040: rdkit: doesn't ship with inchi support enabled

[Alex Mestiashvili]

On 2/18/21 2:58 PM, Michael Banck wrote:

tags 983040 +wontfix
merge 983040 964773
thanks

On Thu, Feb 18, 2021 at 03:35:21PM +0200, Andrius Merkys wrote:

On 2021-02-18 15:27, Michael Banck wrote:

On Thu, Feb 18, 2021 at 02:48:49PM +0900, Francois Berenger wrote:

---
python3
import rdkit
from rdkit import Chem
rdkit.Chem.INCHI_AVAILABLE
# False
---

It would be nice if INCHI support is enabled
when building rdkit for Debian.

If you point me to the bugtracker where I should report
this (not found after 10min of searching...), I might report it there.


This has already been reported as [#964773]. In short, rdkit cannot be
built with INCHI support in Debian due to DFSG reasons (please see the
original bug report for explanation).

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


Thanks Andrius for the pointer. By the way, I've looked at the INCHI
licenes again, and clause 3 allows to use the INCHI code under the GPL,
was it considered to just go that route in Debian or is there some other
loophole I don't see?

Maybe RDKit could be changed in some way to build against both INCHI
versions, but if that is possible at all, it sounds like a major
project.

Francois, what might help here is opening an issue with RDKit's GitHub
issue tracker and asking them about supporting both versions.


Michael

___
Debichem-devel mailing list
debichem-de...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debichem-devel



An ideal case would be to convince the inchi upstream to change the 
license to a more permissive one (may be it is enough to change the 
wording only).
Just for reference, here is the thread about inchi licensing, but no 
consensus so far:


 https://lists.debian.org/debian-legal/2018/02/msg00026.html

Alex

Bug#982833: man2html,man2html-base,manpages-it: manpage conflicts: man2html.1, hman.1

[Andreas Beckmann]

Followup-For: Bug #982833
Control: found -1 4.9.1-5

Hi,

the conflicting manpages are still present in manpages-it 4.9.1-5:

/usr/share/man/it/man1/hman.1.gz
/usr/share/man/it/man1/man2html.1.gz


Andreas

Bug#982381: AttributeError: lowlevel due to trio usage in s3ql/block_cache.py

[Francesco P. Lovergine]

On Sun, Feb 14, 2021 at 01:38:58PM +1100, Lorentz Kim wrote:

Hi,

I don't know if it'll help much, but I've also gotten this bug and
have resolved it by manually upgrading python3-trio with pip to its
latest version, overriding system's installed version (which is 0.13
last I checked).

pip install trio==0.18.0

Pretty sure the s3ql release notes for 3.7 suggests anything after
trio 0.9 is supported, but perhaps there's a bug in there somewhere?

Regards,
Lorentz


I'm pretty sure this release should depend on >= 0.15,
even due to #981906. Unfortunately, it is not expressed in the package, so yes
it is an upstream issue apparently.

--
Francesco P. Lovergine

Bug#983042: kdeconnect: Please redesign the sc-apps-kdeconnectindicatordark icon

[Pino Toscano]

In data giovedì 18 febbraio 2021 15:20:53 CET, Горбешко Богдан ha scritto:
> I had checked the upstream repository before reporting this issue 
> (that's where I got the filename), it still contains this version of the 
> icon. Reporting here, because I couldn't find an issue tracker on KDE 
> GitLab.

https://bugs.kde.org is the KDE upstream bug tracking system. Please
report it there, rather than on a downstream bug tracking system.

-- 
Pino Toscano

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

Bug#885195: [Pkg-electronics-devel] Bug#885195: guile-2.0 removed

[Kai-Martin Knaak]

Joerg Jaspert  schrieb am 13. February 2021:

> i just removed guile-2.0 from unstable.
> While your package already won't be part of the next release, it will 
> now also be unusable in unstable.
> 
> Please either upload a fixed version

A fixed version sits at debian mentors looking for a sponsor.
https://mentors.debian.net/package/geda-gaf/

First upload to debian mentors was last week (Tuesday 9th). I reploaded
to amend changes that make lintian complain less and respond to remarks
by reviewers.

All the best,

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
https://keyserver.ubuntu.com/pks/lookup?op=index&search=0x7B0F9882


pgp5DT0e2autd.pgp
Description: OpenPGP digital signature

Bug#983045: swupdate: cross build deps

[Bastian Germann]

Source: swupdate
Severity: wishlist
Tags: patch

Some build dependencies that are not bound to the target architecture 
and do not specify Multi-Arch "foreign" cannot be resolved automatically 
for cross builds: https://bootstrap.debian.net/cross_all/swupdate.html.


A patch is enclosed that marks them :native or replaces them with their 
virtual counterpart.
From: Bastian Germann 
Date: Thu, 18 Feb 2021 15:39:43 +0100
Subject: arch-independent build deps: Use virtual or :native

Some packages that are not bound to the target architecture and do not
specify Multi-Arch "foreign" cannot be automatically resolved for cross
builds. Mark them :native or replace them with their virtual counterpart.

Signed-off-by: Bastian Germann 
---
 debian/control | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index f373aaf..a6f4e48 100644
--- a/debian/control
+++ b/debian/control
@@ -5,10 +5,10 @@ Maintainer: Stefano Babic 
 Uploaders: SZ Lin (林上智) ,
Nobuhiro Iwamatsu 
 Build-Depends: debhelper-compat (= 13),
-   dh-lua ,
+   dh-lua:native ,
liblua5.2-dev ,
libfdisk-dev,
-   latexmk ,
+   latexmk:native ,
libconfig-dev,
libcurl4-openssl-dev,
libarchive-dev,
@@ -28,7 +28,7 @@ Build-Depends: debhelper-compat (= 13),
libcmocka-dev,
pkg-config,
gawk,
-   python3-sphinx ,
+   sphinx ,
texlive-latex-recommended ,
texlive-fonts-recommended ,
texlive-formats-extra 

Bug#983046: kjs: please make the opcodes.h file reproducible

[Chris Lamb]

Source: kjs
Version: 5.78.0-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
kjs could not be built reproducibly.

This is, in part, because it generates an opcodes.h file that embeds the
full path to its original filename which naturally varies on the original
build directory.

Patch attached that applies the equivalent of basename(3) to these values;
kjs doesn't use boost so I cannot use boost::filesystem, nor does it use
c++17 (?) so I cannot use std::filesystem::path either, alas.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible_build 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/reproducible_build 2021-02-18 14:52:49.165246604 +
@@ -0,0 +1,49 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2021-02-18
+
+--- kjs-5.78.0.orig/src/kjs/bytecode/generator/filetemplate.h
 kjs-5.78.0/src/kjs/bytecode/generator/filetemplate.h
+@@ -46,6 +46,7 @@ struct FileTemplate {
+ {
+ isOK  = true;
+ lines = 0;
++  inFileBaseName = inFileName.substr(inFileName.find_last_of("/") + 1);
+ 
+ in.open(inFileName.c_str());
+ if (in.fail()) {
+@@ -60,7 +61,7 @@ struct FileTemplate {
+ }
+ 
+ if (isOK) {
+-out << "// WARNING: Portions of this file are autogenerated from 
codes.def and " << inFileName << ".\n";
++out << "// WARNING: Portions of this file are autogenerated from 
codes.def and " << inFileBaseName << ".\n";
+ out << "// (which is what the licensing terms apply to)\n";
+ out << "// Any changes you make here may be lost!\n";
+ handleUntilGenerate();
+@@ -77,7 +78,7 @@ struct FileTemplate {
+ // Goes until @generate..
+ void handleUntilGenerate()
+ {
+-out << "#line " << (lines + 1) << " \"" << inFileName << "\"\n";
++out << "#line " << (lines + 1) << " \"" << inFileBaseName << "\"\n";
+ while (!in.eof()) {
+ string line;
+ getline(in, line);
+@@ -92,7 +93,7 @@ struct FileTemplate {
+ 
+ void handleSuffix()
+ {
+-out << "#line " << (lines + 1) << " \"" << inFileName << "\"\n";
++out << "#line " << (lines + 1) << " \"" << inFileBaseName << "\"\n";
+ while (!in.eof()) {
+ string line;
+ getline(in, line);
+@@ -101,6 +102,7 @@ struct FileTemplate {
+ }
+ 
+ string   inFileName;
++string   inFileBaseName;
+ string   outFileName;
+ ifstream in;
+ ofstream out;
--- a/debian/patches/series 2021-02-18 12:56:03.551163060 +
--- b/debian/patches/series 2021-02-18 13:00:06.669560158 +
@@ -1 +1,2 @@
 install_missing_headers
+reproducible_build

Bug#982671: Supporting unbound in stretch by upgrading to 1.9

[Markus Koschany]

Am Donnerstag, den 18.02.2021, 11:40 +0200 schrieb Andrei POPESCU:
[...]
> Hello,
> 
> This appears to be the case. A side effect of this is that unless dealt 
> with manually these bugs will just linger in the BTS.
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=
> 
> Please either close or reassign them to a package known to the BTS.
> 
> Kind regards,
> Andrei

Hello,

the bug report is correctly assigned now, see

https://tracker.debian.org/pkg/unbound1.9

but the BTS is unable to fetch the maintainer address automatically. Minor
issue in my opinion.

Regards,

Markus


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

Bug#981009: Charybdis abandoned upstream, do not ship in bullseye

[Antoine Beaupré]

On 2021-02-18 02:32:10, Sadie Powell wrote:
> Charybdis' development was terminated due to (among other reasons) threats by 
> a former maintainer. It probably won't be revived.
>
> It's successor is probably Solanum (https://github.com/solanum-ircd/solanum) 
> which is a fork that is led by freenode and OFTC people some of whom were 
> contributors to Charybdis. It might be a good idea to package that instead 
> when it gets a release?

I believe my co-maintainer here is working on this, actually. No WNPP
bug, as far as I know, but as you say, without an upstream release it
might not be worth it just yet.

But yes, it's pretty much the replacement for charybdis, but do note
that it's not a drop-in replacement.

A.

-- 
We will create a civilization of the Mind in Cyberspace. May it be more
humane and fair than the world your governments have made before.
- John Perry Barlow, 1996
A Declaration of Independence of Cyberspace

Bug#983025: libqt5widgets5: Segfault with QGLWidget class. Fixed Upstream

[Alejandro Lorenzo]

Package: libqt5widgets5
Version: 5.15.2+dfsg-4
Severity: critical
Tags: upstream newcomer
Justification: breaks unrelated software

Dear Maintainer,

Recently i found a bug in QGLWidget (one of the widgets included in
libqt5widgets5) that
creates a segfault. This bug was accepted as upstream bug 86582

(https://bugreports.qt.io/browse/QTBUG-86582)

It was confirmed and fixed by the Qt people, unfortunately, it has been
committed to the
5.15 LTS branch of their development which is no longer accessible to the
OpenSource licensees

QGLWidget has been a deprecated Widget for some time now, and many software
changed to
QOpenGLWidget alternative, which does not exhibit this problem, but other
pieces of the debian
system (e.g. libqtgstreamer; also deprecated but still in debian repos)  uses
it.

In the issue tracker of the Qt project the likely cause of the bug is
commented, but the actual
fix is not detailed (or i do not know how to access it)

Anyways, i want to put this here to kee everyone informed about this.



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

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

Versions of packages libqt5widgets5 depends on:
ii  libc6 2.31-9
ii  libgcc-s1 10.2.1-6
ii  libqt5core5a [qtbase-abi-5-15-2]  5.15.2+dfsg-4
ii  libqt5gui55.15.2+dfsg-4
ii  libstdc++610.2.1-6

libqt5widgets5 recommends no packages.

libqt5widgets5 suggests no packages.

Bug#979326: ITP: crust -- SCP firmware for sunxi SoCs

[Jonas Smedegaard]

Quoting Nicolas Boulenguez (2021-02-18 14:48:20)
> > > Feel free to add pristine-tar, but I am avoiding its complexity 
> > > now that other tools are converging towards reproducibility by 
> > > default.
> 
> > Please consider document your workflow in debian/README.Source - 
> > preferably only a short sentence which referenced a URL to some 
> > shared place e.g. at https://wiki.debian.org/ more elaborately 
> > covering the chosen workflow, to encourage reuse.
> 
> People that *do* expose preferences for non-standard tools like 
> pristine-tar should document their choice.  I try to avoid unneeded 
> steps for new contributors.

Thanks for considering.


 - 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#982974: FTBFS: fails to compile translation files

[tony mancill]

On Wed, Feb 17, 2021 at 09:38:16PM +0530, Ritesh Raj Sarraf wrote:
> Source: swt4-gtk
> Version: 4.17.0-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)

Hi Ritesh,

It seems that a local sbuild in a clean chroot doesn't set the
environment the same way that reproducible-builds.org does, as 4.17.0-1
builds correctly in that environment.  But that's a separate concern.

I just wanted to comment that the reproducible-builds.org build for
4.18.0-2 is successful, and that is the version we would like to get
into bullseye.  It is currently blocked by #979609 [1].

Cheers,
tony

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

Bug#983047: linux-image-5.10.0-3-amd64: Virtualbox Shared Folder vboxsf in 5.10 is racy / unusable with git clone

[Ludovic Pouzenc]

Package: src:linux
Version: 5.10.13-1
Severity: normal

Dear Maintainer,

The current kernel in testing has vboxsf properly integrated and signed.
With Buster, we should use VirtualBoxGuestAdditions.iso to dkms it.
It implies linux-headers, dkms, toolchain... 300 or 400 Mio of stuff.

The integrated vboxsf is way easy to use but it currently fails for "git
clone" like work loads. Steps to reproduce :
 * install debian testing in a virtualbox VM, everything as default
 * configure a shared folder in virtualbox
 * mount in from debian VM somewhere
 * from VM, go into this folder, then :
 * git clone https://a-random-non-empty-public-git-repo.git
 * it fails at unpacking stage.

If host is Windows, there is 2 problems (spurious EINTR, and "File Already 
exists").
If host is Linux, there is 1 problem (a third one : spurious EPERM)

It's reported, patches are written by one of the person who a have took
the initiative about mainline it, I use it since some weeks locally.

https://bugzilla.kernel.org/show_bug.cgi?id=211171
Hans de Goede has submited patches to fs and char-misc teams.

On 2021-02-18 only 1/5 patches are on linux-next. Kernel fs team seems
not have pickup the 4 remaining patches yet.

I don't know if it doable to get them for buster, but it should help
everyone who tries to use this feature.

Here we use it as a way to give local development env to web developers.

Please found the patches has Hans mailed me, they should appears in
linux-next soon.


-- Package-specific info:
** Version:
Linux version 5.10.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP 
Debian 5.10.13-1 (2021-02-06)

** Not tainted
>From 684a3a9a4570991863398e65840d94ec454eb6ad Mon Sep 17 00:00:00 2001
From: Hans de Goede 
Date: Thu, 21 Jan 2021 10:08:59 +0100
Subject: [PATCH v4 1/4] vboxsf: Honor excl flag to the dir-inode create op

Honor the excl flag to the dir-inode create op, instead of behaving
as if it is always set.

Note the old behavior still worked most of the time since a non-exclusive
open only calls the create op, if there is a race and the file is created
between the dentry lookup and the calling of the create call.

While at it change the type of the is_dir parameter to the
vboxsf_dir_create() helper from an int to a bool, to be consistent with
the use of bool for the excl parameter.

Fixes: 0fd169576648 ("fs: Add VirtualBox guest shared folder (vboxsf) support")
Signed-off-by: Hans de Goede 
---
 fs/vboxsf/dir.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/fs/vboxsf/dir.c b/fs/vboxsf/dir.c
index 4d569f14a8d8..c3e68ad6c0f4 100644
--- a/fs/vboxsf/dir.c
+++ b/fs/vboxsf/dir.c
@@ -253,7 +253,7 @@ static int vboxsf_dir_instantiate(struct inode *parent, 
struct dentry *dentry,
 }
 
 static int vboxsf_dir_create(struct inode *parent, struct dentry *dentry,
-umode_t mode, int is_dir)
+umode_t mode, bool is_dir, bool excl)
 {
struct vboxsf_inode *sf_parent_i = VBOXSF_I(parent);
struct vboxsf_sbi *sbi = VBOXSF_SBI(parent->i_sb);
@@ -261,10 +261,12 @@ static int vboxsf_dir_create(struct inode *parent, struct 
dentry *dentry,
int err;
 
params.handle = SHFL_HANDLE_NIL;
-   params.create_flags = SHFL_CF_ACT_CREATE_IF_NEW |
- SHFL_CF_ACT_FAIL_IF_EXISTS |
- SHFL_CF_ACCESS_READWRITE |
- (is_dir ? SHFL_CF_DIRECTORY : 0);
+   params.create_flags = SHFL_CF_ACT_CREATE_IF_NEW | 
SHFL_CF_ACCESS_READWRITE;
+   if (is_dir)
+   params.create_flags |= SHFL_CF_DIRECTORY;
+   if (excl)
+   params.create_flags |= SHFL_CF_ACT_FAIL_IF_EXISTS;
+
params.info.attr.mode = (mode & 0777) |
(is_dir ? SHFL_TYPE_DIRECTORY : SHFL_TYPE_FILE);
params.info.attr.additional = SHFLFSOBJATTRADD_NOTHING;
@@ -291,13 +293,13 @@ static int vboxsf_dir_create(struct inode *parent, struct 
dentry *dentry,
 static int vboxsf_dir_mkfile(struct inode *parent, struct dentry *dentry,
 umode_t mode, bool excl)
 {
-   return vboxsf_dir_create(parent, dentry, mode, 0);
+   return vboxsf_dir_create(parent, dentry, mode, false, excl);
 }
 
 static int vboxsf_dir_mkdir(struct inode *parent, struct dentry *dentry,
umode_t mode)
 {
-   return vboxsf_dir_create(parent, dentry, mode, 1);
+   return vboxsf_dir_create(parent, dentry, mode, true, true);
 }
 
 static int vboxsf_dir_unlink(struct inode *parent, struct dentry *dentry)
-- 
2.28.0

>From 315010a5a43a468ea2d5a5d1fdec48c01ecffadd Mon Sep 17 00:00:00 2001
From: Hans de Goede 
Date: Thu, 21 Jan 2021 10:22:27 +0100
Subject: [PATCH v4 2/4] vboxsf: Make vboxsf_dir_create() return the handle for
 the created file

Make vboxsf_dir_create() optionally return the vboxsf-handle for
th

Bug#982970: offlineimap3: broken folderincludes config option

[Santiago Ruano Rincón]

El 17/02/21 a las 18:51, Sudip Mukherjee escribió:
> Hi Santiago,
> 
> On Wed, Feb 17, 2021 at 2:30 PM Santiago Ruano Rincón
>  wrote:
> >
> > Package: offlineimap3
> > Version: 0.0~git20210105.00d395b+dfsg-3
> > Severity: normal
> > Tags: upstream
> >
> > Dear Sudip,
> >
> > offlineimap3 is not able to handle the folderincludes config, that
> > worked with offlineimap. I got this when trying to sync (tested with two
> > different accounts):
> >
> >   'str' object has no attribute 'decode'
> 
> Can you please test with the PR at
> https://github.com/OfflineIMAP/offlineimap3/pull/47/ and check if it
> fixes your issue..
> I could reproduce the problem in my setup and the above PR fixes the
> problem for me. I have not tested enough to know if it breaks
> something else.

It seems to work, thanks!

 -- Santiago


signature.asc
Description: PGP signature

Bug#983048: please provide mke2fs to let fastboot format work

[Dmitry Baryshkov]

Package: fastboot
Version: 1:10.0.0+r36-7
Severity: normal

Currently fastboot format fails because it can not find the mke2fs tool:

$ /usr/bin/fastboot format userdata
/usr/lib/android-sdk/platform-tools/mke2fs failed with status 1
fastboot: error: Cannot generate image for userdata

$ ls -l /usr/lib/android-sdk/platform-tools/
total 604
-rwxr-xr-x 1 root root 202944 Jan 19 23:09 adb
-rwxr-xr-x 1 root root 401512 Jan 19 23:09 fastboot
-rw-r--r-- 1 root root979 Jan 22 12:23 package.xml
-rw-r--r-- 1 root root 50 Jan 22 12:23 source.properties

Please provide mke2fs tool so that we can fastboot format partitions.


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

Kernel: Linux 5.10.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fastboot depends on:
ii  android-libadb 1:10.0.0+r36-7
ii  android-libbase1:10.0.0+r36-7
ii  android-libboringssl   10.0.0+r36-1
ii  android-libcutils  1:10.0.0+r36-7
ii  android-libext4-utils  10.0.0+r36+ds-2
ii  android-libsparse  1:10.0.0+r36-7
ii  android-libunwind  10.0.0+r36-4
ii  android-libziparchive  1:10.0.0+r36-7
ii  android-sdk-platform-tools-common  28.0.2+3
ii  libc6  2.31-9
ii  libgcc-s1  10.2.1-6
ii  libstdc++6 10.2.1-6

fastboot recommends no packages.

Versions of packages fastboot suggests:
pn  android-sdk-platform-tools  

-- no debconf information

Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8

[Simon McVittie]

On Thu, 18 Feb 2021 at 12:06:58 +0100, Pino Toscano wrote:
> In data lunedì 15 febbraio 2021 13:07:13 CET, Simon McVittie ha scritto:
> > > In Cairo and Pango (which have a similar structure with multiple binary
> > > packages making use of each other's implementation details), I added a
> > > debian/shlibs.local to make sure the binary packages all get lockstep
> > > dependencies. I think the same technique would be appropriate here. See
> > > attached.
> 
> I honestly do not understand how this is even a problem, considering I
> fixed this more than 5 years ago:
> https://salsa.debian.org/freedesktop-team/poppler/-/commit/7929aa2d5ec9464fea755f622319d224787c4110

Sorry, I didn't spot that the interdependencies were already strict. I'll
close the MR.

> I'd rather think that the situation happened because
> elpa-pdf-tools-server links both to libpoppler and libpoppler-glib:
> the rebuild against poppler 20.09.0 (i.e. libpoppler102) make
> elpa-pdf-tools-server link to libpoppler102 (forcing the newer
> dependency to it), and setting an old dependency for libpoppler-glib
> because there is no need for a newer version.

So elpa-pdf-tools-server is linked to libpoppler-glib, and because the
(parts of the) libpoppler-glib API that it uses has not changed for a
while, it is happy with an old version; but then during a partial
upgrade, it can get this

elpa-pdf-tools-server
\- old libpoppler-glib
|   \- libpoppler95
\- libpoppler102

and the two copies of libpoppler fight?

That seems entirely plausible, and I don't immediately see a way to
fix it without adding Breaks (which would force a lockstep upgrade,
somewhat defeating the purpose of SONAMEs).

GNOME had similar issues during the libffi transition, where gjs' direct
use of libffi conflicted with its indirect use via GLib, and I think we
ended up adding Breaks to force the broken combinations not to happen.

> Another contributing factor is that emacs-pdf-tools "abuses" the
> libpoppler-glib internals, see server/poppler-hack.cc. I don't know
> why it does that, and I'd rather see the actual issues fixed in
> libpoppler-glib.

That does look like emacs-pdf-tools is doing things that aren't guaranteed
to work, yes, and the solution is indeed to improve libpoppler-glib to do
what emacs-pdf-tools needs (and then make emacs-pdf-tools depend on the
newer version instead of working around older versions).

smcv

Bug#900374: updated knot.service file available since knot-3.0.1-1

[Jakub Ružička]

I've updated debian/knot.service file from upstream which already
addressed described issues.

It's been synced in knot-3.0.1-1 debian package release and it remains
in sync as of 3.0.4.

You can look at commit cc65f515c1:
https://salsa.debian.org/dns-team/knot-dns/-/commit/cc65f515c1

I believe this issue is solved and can be closed.


Cheers,
Jakub Ružička

Bug#983047: Erratum

[Ludovic Pouzenc]

Erratum : I've written :


I don't know if it doable to get them for*buster*, but it should help

It wanted to say :


I don't know if it doable to get them for*bulleye*, but it should help

Sorry,

--
Ludovic Pouzenc
Ingénieur Informatique de Gestion
Direction du Numérique, DN : Applications
04 79 75 83 54

Bug#982970: offlineimap3: broken folderincludes config option

[Sudip Mukherjee]

On Thu, Feb 18, 2021 at 3:28 PM Santiago Ruano Rincón
 wrote:
>
> El 17/02/21 a las 18:51, Sudip Mukherjee escribió:
> > Hi Santiago,
> >
> > On Wed, Feb 17, 2021 at 2:30 PM Santiago Ruano Rincón
> >  wrote:
> > >
> > > Package: offlineimap3
> > > Version: 0.0~git20210105.00d395b+dfsg-3
> > > Severity: normal
> > > Tags: upstream
> > >
> > > Dear Sudip,
> > >
> > > offlineimap3 is not able to handle the folderincludes config, that
> > > worked with offlineimap. I got this when trying to sync (tested with two
> > > different accounts):
> > >
> > >   'str' object has no attribute 'decode'
> >
> > Can you please test with the PR at
> > https://github.com/OfflineIMAP/offlineimap3/pull/47/ and check if it
> > fixes your issue..
> > I could reproduce the problem in my setup and the above PR fixes the
> > problem for me. I have not tested enough to know if it breaks
> > something else.
>
> It seems to work, thanks!

Thanks for confirming.


-- 
Regards
Sudip