Bug#947907: uno-libs-private: Unmet dependencies

[rene . engelhard]

Am 2. Januar 2020 04:46:11 MEZ schrieb William Panlener :
>ure=6.4.0~rc1-5 ships files provided by other packages in addition to
>the reported conflict. I have discovered the following conflicting
>files and packages:
>
>'/usr/share/java/juh.jar', which is also in package libjuh-java
>1:6.4.0~rc1-5
>'/usr/share/java/jurt.jar', which is also in package libjurt-java
>1:6.4.0~rc1-5
>'/usr/share/java/ridl.jar', which is also in package libridl-java
>1:6.4.0~rc1-5
>'/usr/share/java/unoloader.jar', which is also in package
>libunoloader-java 1:6.4.0~rc1-5

I know.

Already fixed locally, needs a test build ...

Regards

Rene

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#947924: ITP: haskell-bytestring -- Fast, compact, strict and lazy byte strings with a list interface

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: haskell-bytestring
  Version : 0.10.10.0
  Upstream Author : Duncan Coutts 
* URL : https://hackage.haskell.org/package/bytestring
* License : BSD-3
  Programming Lang: Haskell
  Description : Fast, compact, strict and lazy byte strings with a list 
interface

 An efficient compact, immutable byte string type (both strict and lazy)
 suitable for binary or 8-bit character data.
 .
 The 'ByteString' type represents sequences of bytes or 8-bit characters.
 It is suitable for high performance use, both in terms of large data
 quantities, or high speed requirements. The 'ByteString' functions follow
 the same style as Haskell\'s ordinary lists, so it is easy to convert code
 from using 'String' to 'ByteString'.
 .
 Two 'ByteString' variants are provided:
 .
   * Strict 'ByteString's keep the string as a single large array. This
 makes them convenient for passing data between C and Haskell.
 .
   * Lazy 'ByteString's use a lazy list of strict chunks which makes it
 suitable for I\/O streaming tasks.
 .
 The @Char8@ modules provide a character-based view of the same
 underlying 'ByteString' types. This makes it convenient to handle mixed
 binary and 8-bit character content (which is common in many file formats
 and network protocols).
 .
 The 'Builder' module provides an efficient way to build up 'ByteString's
 in an ad-hoc way by repeated concatenation. This is ideal for fast
 serialisation or pretty printing.
 .
 There is also a 'ShortByteString' type which has a lower memory overhead
 and can be converted to or from a 'ByteString', but supports very few
 other operations. It is suitable for keeping many short strings in memory.
 .
 'ByteString's are not designed for Unicode. For Unicode strings you should
 use the 'Text' type from the @text@ package.
 .
 These modules are intended to be imported qualified, to avoid name clashes
 with "Prelude" functions, e.g.
 .
 > import qualified Data.ByteString as BS
 .
 This package will be maintained by the Curry Maintainers under the umbrella
 of the Debian Haskell Group.

Bug#947923: RFS: opendkim/2.11.0~beta2-1 -- Milter implementation of DomainKeys Identified Mail

[David Bürgin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: opendkim
   Version : 2.11.0~beta2-1
   Upstream Author : The Trusted Domain Project
 * URL : http://www.opendkim.org/
 * License : BSD-3-clause and SOSL
 * Vcs : https://salsa.debian.org/debian/opendkim
   Section : mail

It builds those binary packages:

  opendkim - Milter implementation of DomainKeys Identified Mail
  opendkim-tools - Set of command line tools for OpenDKIM
  libopendkim11 - Library for signing and verifying DomainKeys Identified Mail 
signatures
  libopendkim-dev - Headers and development libraries for the OpenDKIM library
  libvbr2 - Library for RFC 5518 Vouch By Reference (VBR)
  libvbr-dev - Headers and development libraries for the OpenDKIM VBR library
  librbl1 - Library to support a DKIM based RBL system
  librbl-dev - Headers/development libraries for the OpenDKIM RBL library

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opendkim/opendkim_2.11.0~beta2-1.dsc

Changes since the last upload:

   * New upstream release.
 - Refresh patches, delete patch "openssl_1.1.0_compat.patch" incorporated
   upstream
 - Update symbols files, add Build-Depends-Package metadata
 - Drop outdated --enable-poll and --with-test-socket configure options
   * debian/rules: Build with hardening flags (patch by Christian Göttsche
 ; closes: #878058)
   * opendkim.service.generate script: Fix permissions of generated override
 files (patch by Christophe Siraut ; closes: #859797)
   * miltertest: Add patch fixing undefined behaviour in mt.eom_check()
 (Closes: #946397)
   * libopendkim-dev: Install only HTML files as documentation, and do so
 directly in /usr/share/doc/ (no subdirectory) as does upstream
   * Install convert_keylist.sh script in its documented location at
 /usr/bin/opendkim-convert-keylist, but keep old name around as a symlink
   * Replace all uses of /var/run with /run (Closes: #859706)
   * Add VCS repository coordinates
   * Bump standards version to 4.4.1 without further change

Thank you!


-- 
David

Bug#941657: RFS: python-lark

[merkys]

Hi Peter,

On 2020-01-01 22:56, Peter Wienemann wrote:
> It would be great if someone could review the code, provide feedback and
> - once everything looks fine - upload it.

The package looks fine to me - uploaded. Thanks for your contribution!

Best,
Andrius

Bug#947422: node-babel depends on itself for build, then updating core-js is blocked

[Xavier]

Hi,

I tried to embed core-js@2.6.x in node-babel-runtime. I pushed my work
into a new "unstable" branch.

@praveen, could you review ?

Cheers,
Xavier

Bug#904215: civicrm: CIVI-SA-2018-07: Remote Code Execution in Quickform

[Salvatore Bonaccorso]

Hi Dmitry!

On Thu, Jan 02, 2020 at 10:38:09AM +1100, Dmitry Smirnov wrote:
> Closing obsolete bug...
> 
> On Sunday, 22 July 2018 5:11:39 AM AEDT Salvatore Bonaccorso wrote:
> > https://civicrm.org/advisory/civi-sa-2018-07-remote-code-execution-in-quick
> > form
> > 
> > This is already fixed, so this bug is to track the issue in the BTS.
> > No CVEs seem to be assigned for the CIVI advisories.
> 
> Maybe CVE was assigned later? The URL above refers to CVE-2018-1999022.

Yes I guess so, from the bug log I see I did retitle it on 24th of
july, I guess it appeared then in the MITRE CVE feed, and someone of
the people working on CVE triage then noticed that association and
updated the security-tracker.

> > Speaking of that, might you convince upstream to request CVE
> > identifiers when they plan to release a CiviCRM security advisory?
> 
> I can try but I'm not sure how to make a convincing case... Do you have a 
> good reasons to recommend or maybe a best practice document I could refer to?

The good thing on having a CVE id for the vulnerabilities is helping
other vendors to track the issues properly 'cross-vendor' in an unique
way. If every upstream would use individual identifiers to track their
vulnerabilities, this makes the work of downsteams security teams much
harder. Nowdays MITRE has improved a lot on their processes on
assigning CVEs, and good filled reports at https://cveform.mitre.org/
get fastly assigned a CVE respectively (this somehow depends though on
how good the report is done). I know some upstreams did in past make
frustrating experiations, and do not want to try that out again.

Does this helps or are you targetting the question to something else
which I just missed now?

Many thanks for your work!

Regards,
Salvatore

Bug#947922: ITP: Bubblemail -- An unread mail notification dbus service

[Razer raz]

Package: wnpp
Severity: wishlist
Owner: "Razer" 

* Package name: Bubblemail
  Version : 0.4
  Upstream Author : "Razer" 
* URL : https://framagit.org/razer/bubblemail
* License : LGPL-2.0-or-later
  Programming Lang: Python
  Description : An unread mail notification dbus service

Bubblemail is a DBus service providing a list of the new and unread user mail
from local mailboxes, pop, imap, and gnome online accounts. It include a
libnotify frontend to create notifications and can be used by other frontends as
well.

Bug#940570: gtk-layer-shell status

[Mike Gabriel]

Hi Birger,

thanks for your interest in joining in with packaging gtk-layer-shell.

On  Di 31 Dez 2019 22:07:00 CET, Birger Schacht wrote:


hi,

I'm interested in helping to get this package into Debian. I'm
maintaining the waybar [0] package, which is a Wayland status bar.
In its newest release, one functionality of Waybar also depends on
gtk-layer-shell. I started to work on the gtk-layer-shell package in
https://salsa.debian.org/bisco-guest/gtk-layer-shell, because I only
afterwards saw this ITP.


Nice!


Maybe we can work together on this package or you can use the stuff I
already implemented (I haven't found a packaging repo in the mate team
for gtk-layer-shell so I figured you might not have started yet).


Yes, let's bundle resources. If you are not a DD yourself, I'll be  
happy to move your Git repo over to salsa/debian/gtk-layer-shell and  
we continue the packaging there. I haven't started anything, so far,  
regarding putting together a DEB package. (Sometimes, it is just good  
to wait... ;-) ).



cheers,
Birger (bisco)


If you are not a DD, are you interested in a packaging review? Or  
shall I just go over your packaging and add my 2¢ here and there and  
then upload?


Maintainer-wise, I'd say we put a package tracker email address into  
the Maintainer:-field and add the package to more than one team on  
tracker.debian.org. So all teams get informed on updates.  
Uploader-wise, we should put all persons' names into the field that  
are interested in its maintenance.


light+love
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpIoMhbaaDnM.pgp
Description: Digitale PGP-Signatur

Bug#947921: iputils-ping: glibc ipv4/v6 route check causes ping to fail with certain ip routing policies

[Benjamin Poirier]

Package: iputils-ping
Version: 3:20180629-2
Severity: important
Tags: ipv6 patch

Using `ping -I` on hosts that have routing rules matching on the outgoing
interface may fail when specifying the destination by name because ping tries
to connect via ipv6 while there are only ipv4 routes or vice-versa:

root@vdebian:~# ping -c1 -I eth0 google.com
connect: Network is unreachable
root@vdebian:~# ping -c1 -I eth0 -4 google.com
PING google.com (172.217.174.110) from 192.168.15.102 eth0: 56(84) 
bytes of
data.
64 bytes from nrt12s28-in-f14.1e100.net (172.217.174.110): icmp_seq=1 
ttl=53
time=16.2 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 16.223/16.223/16.223/0.000 ms
root@vdebian:~# host google.com
google.com has address 172.217.174.110
google.com has IPv6 address 2404:6800:4004:80d::200e
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
root@vdebian:~# ping -c1 -I eth0 172.217.174.110
PING 172.217.174.110 (172.217.174.110) from 192.168.15.102 eth0: 56(84) 
bytes
of data.
64 bytes from 172.217.174.110: icmp_seq=1 ttl=53 time=11.4 ms

--- 172.217.174.110 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 11.435/11.435/11.435/0.000 ms

Patches (that I submitted) have been merged in upstream iputils to address
this issue:
c249e48 ping: fix main loop over multiple addrinfo results
2705c82 ping: try next addrinfo on connect failure

The exact conditions that lead to this problem are detailed in the log of
commit 2705c82.

I've attached a backport of those patches for Debian Buster. I've built a test
package with those packages and confirmed that they fix the issue. Please
consider applying them.

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

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

Versions of packages iputils-ping depends on:
ii  libc6   2.28-10
ii  libcap2 1:2.25-2
ii  libidn2-0   2.0.5-1
ii  libnettle6  3.4.1-1

Versions of packages iputils-ping recommends:
ii  libcap2-bin  1:2.25-2

iputils-ping suggests no packages.

-- no debconf information
>From 769a6790437e883d72eebbabd06d33a05a0340ca Mon Sep 17 00:00:00 2001
From: Benjamin Poirier 
Date: Thu, 26 Dec 2019 10:44:03 +0900
Subject: [PATCH 1/2] ping: fix main loop over multiple addrinfo results

Despite what the log of commit f68eec0eafad ("ping: perform dual-stack ping
by default") says, main() was not designed to loop over multiple addresses
returned by getaddrinfo().  This is apparent because until commit
db11bc96a68c ("ping: make command to return from main()"), ping{4,6}_run()
never returned (they always exited).  After commit db11bc96a68c, we
encounter unexpected situations if getaddrinfo returns multiple results and
ping{4,6}_run() return != 0.

For example (notice echo reply is not received):

root@vsid:/src/iputils# ./builddir/ping/ping -w1 google.com
PING google.com(nrt12s22-in-x0e.1e100.net (2404:6800:4004:80c::200e)) 56 
data bytes

--- google.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

PING  (216.58.197.142) 56(84) bytes of data.

---  ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time -1002ms

root@vsid:/src/iputils#

Establish the following convention:

* return value >= 0 -> exit with this code (same behavior as before commit
  db11bc96a68c)

* return value < 0 -> go on to next addrinfo result

The second case will be used in the following patch.

Fixes: db11bc96a68c ("ping: make command to return from main()")
Signed-off-by: Benjamin Poirier 
---
 ping.c | 6 +-
 ping6_common.c | 1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/ping.c b/ping.c
index 733477f..4d2de0f 100644
--- a/ping.c
+++ b/ping.c
@@ -528,8 +528,11 @@ main(int argc, char **argv)
exit(2);
}
 
-   if (status == 0)
+   if (status >= 0)
break;
+   /* status < 0 means to go on to next addrinfo result, there
+* better be one. */
+   assert(ai->ai_next);
}
 
freeaddrinfo(result);
@@ -537,6 +540,7 @@ main(int argc, char **argv)
r

Bug#947920: RFS: pdf2djvu/0.9.15-1 [NMU] -- PDF to DjVu converter

[Paul Wise]

On Thu, Jan 2, 2020 at 6:09 AM Hsieh-Tseng Shen wrote:

> Moreover, I'd like to take over this package but I'm not sure if I have
> to solve some bugs or just by changing debian/control. Btw, I already
> asked maintainer for this from https://bugs.debian.org/945185.

The O in the title of this bug means the package is orphaned. If you
would like to be the new maintainer, you can follow this procedure to
adopt the package:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#adopting-a-package

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#947920: RFS: pdf2djvu/0.9.15-1 [NMU] -- PDF to DjVu converter

[Hsieh-Tseng Shen]

Package: sponsorship-requests
Severity: normal
Tags: upstream

Dear mentors,

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

 * Package name: pdf2djvu
   Version : 0.9.15-1
   Upstream Author : Jakub Wilk 
 * URL : http://jwilk.net/software/pdf2djvu
 * License : GPL-2
 * Vcs : https://salsa.debian.org/debian/pdf2djvu
   Section : text

It builds those binary packages:

  pdf2djvu - PDF to DjVu converter

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pdf2djvu/pdf2djvu_0.9.15-1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * New upstream release.

Moreover, I'd like to take over this package but I'm not sure if I have
to solve some bugs or just by changing debian/control. Btw, I already
asked maintainer for this from https://bugs.debian.org/945185.

Regards,

-- 
Woodrow Shen (Hsieh-Tseng Shen)
4FA0 D159 803F F8B6 34E9  5A38 3970 FE24 7CB6 9685
woodrow.s...@gmail.com


signature.asc
Description: PGP signature

Bug#946193: workaround

[Ted Anderson]

I encountered the same problem upgrading from (jessie to) stretch to 
buster today.  I was successful using the simpler workaround of deleting 
compatibility.ini from my profile.  Once Firefox started, it recreated a 
new compatibility.ini file automatically.  Here is a comparison of the 
old and new files:


ota@alfriston:~$ diff 
~/.mozilla/firefox/bhojq6pr.default/compatibility.ini 
~/firefox-pre-buster-profile/compatibility.ini

2c2
< LastVersion=68.3.0_20191203235607/20191203235607
---
> LastVersion=68.3.0_20191204133900/20191204133900
ota@alfriston:~$ firefox --version
Mozilla Firefox 68.3.0esr
ota@alfriston:~$ cat /etc/debian_version
10.2
ota@alfriston:~$ dpkg -l | grep firefox
ii  firefox-esr   68.3.0esr-1~deb10u1 
 amd64Mozilla Firefox web browser - Extended Support 
Release (ESR)

ota@alfriston:~$ cat /etc/debian_version
10.2

So this minor versioning glitch appears to explain the problem as 
described above.  I also found the Mozilla bug(s) from July that 
addresses a similar problem, but which apparently doesn't handle this case.


https://bugzilla.mozilla.org/show_bug.cgi?id=1554029
https://bugzilla.mozilla.org/show_bug.cgi?id=1568252

HtH,
Ted

Bug#947915: release-notes: Suggest cleaning up leftover *.dpkg-old etc. config files

[Karl O. Pinc]

On Thu, 2 Jan 2020 01:45:16 +
Justin B Rye  wrote:

> Karl O. Pinc wrote:
> > Attached is a patch which suggests cleaning up unused config files
> > leftover from prior upgrades, the foo.dpkg-old and similar files,
> > before starting the new upgrade.  
> 
> > --- a/en/upgrading.dbk
> > +++ b/en/upgrading.dbk
> > @@ -301,6 +301,17 @@ $ apt-forktracer | sort
> >  It is a good idea to remove obsolete
> >  packages from your system before upgrading.
> >
> > +  
> > +A previous upgrade can have left unused copies of
> > configuration  
> 
> I'd recommend may have

Agreed.

> > +files; old
> > versions
> > +of configuration files, versions supplied by the package
> > +maintainers, etc.  Removing leftover files from previous
> > upgrades,
> > +before performing another upgrade, can avoid confusion.  
> 
> The commas in this sentence seem subtly wrong.

I think the commas are right, as a parenthetical-ish without
parenthesis, but the sentence structure is strange.  But
I want the forgettable stuff in the middle and the important
stuff on the ends of the sentence where the reader pays attention.

> > + Find
> > such
> > +leftover files with:
> > +  
> > +  
> > +# find /etc -name '*.dpkg-*'
> > +
> 
> But in fact if you're going to do this sweep (and haven't previously
> been in the habit of doing it), doesn't it make more sense to learn it
> as something to do *after* every (dist- or package-)upgrade?  What
> kinds of confusion does it risk if you do it then?
> 
> It might fit best in 4.7. "Preparing for the next release".

I like to leave the leftover files laying around for a while after
upgrade just in case they shed light on some problem that I don't
notice until later.  So I clean them up (or not, usually) before
doing the next upgrade because I forget they exist.

It is also theoretically possible a dist-upgrade will be required
for some installed package in the middle of the release cycle.
That could create another *.dist-* file.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#947915: release-notes: Suggest cleaning up leftover *.dpkg-old etc. config files

[Karl O. Pinc]

On Thu, 2 Jan 2020 01:45:16 +
Justin B Rye  wrote:

> (Personally I have a cronjob that nags me if it sees any *.dpkg-new,
> *.dpkg-old, *.dpkg-save, *.pam-old or *ucf-old files lying about.)

I noticed with the Buster upgrade that there are some packages
that want to do a "three way merge", which, when it fails,
uses some other long suffix for the files it leaves laying
around.  But I forget the name.

Using locate I also notice a few *.dpkg-bak files.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

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

[Utkarsh Gupta]

On Fri, 27 Dec 2019 22:06:40 -0500 Tong Sun
 wrote:
> Package: wnpp
> Severity: normal
> 
> I've created/updated the salsa repo at:
> 
>https://salsa.debian.org/debian/dbab
> 
> For the package of
> 
>   https://tracker.debian.org/pkg/dbab
> 
> The reason that I’m asking for reviewing is that,
> 
> - this is the first time that I created a salsa project all by myself
> - also, this is the first time that I am doing the packaging and
> uploading all by myself
> 
> The package was tested on both gbp and sbuild
> (http://paste.debian.net/1122767/). It's also lintian-clean.
> And I’ve done my best to fix anything I can.
> 
> However, a second pair of eyes, i.e., any kind of reviews and
> suggestions are appreciated.

A couple of pointers from my end..

1. As a general rule, always check your package by running "cme fix
dpkg". Once you do that, please commit the result.
Let me know if you don't understand the result.

2. assets/dbab.service points to a 404 link. Please always run "duck".
Please fix the same :)

3. testsuite-autopkgtest-missing: not a necessity per se, but always
good to have them :)

4. Whilst closing a bug which wants a new upstream release, you should
rather have something like, "New upstream release 1.3.3 (Closes: #946977).

5. I am not sure if you're using that already, but use "gbp dch -a" to
generate a d/ch entry. It's neater that way.

6. I am not particularly sure of "License-Grant" thingy, so I'll leave
it as is.

7. Re: your last commit: 987bf1cff4cfe443ff6d04fd68df5cbac19ce7d2:
You shouldn't really override it. Mostly because it's not false.
You should leave it as is, almost all the packages have it :)
Also, it's not a "warning" or an "error", it's just a "O".
I'd recommend to revert it.

8. There are a couple of bugs open (#876815, #876824). I hope you'd
eventually get there? If it's fixed, please close them as well.

9. Whilst you suggested it was uploaded on 27th December, I can't really
find so on the tracker?

10. Lastly, I can't see any "tags" that you should've pushed.
Ideally, each upstream release warrants an "upstream" tag and each
upload should be tagged as a "debian/" tag. I can just see 1
upstream tag. Can you perhaps push the other ones as well? :)



Best,
Utkarsh



signature.asc
Description: OpenPGP digital signature

Bug#947919: schroot: Support for ZFS snapshotting

[Steve Langasek]

Package: schroot
Version: 1.6.10-6.1
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

schroot currently supports using LVM and btrfs volumes as a source for
snapshot-based chroots, to good effect.  It is also possible to use ZFS as a
filesystem on Linux, via the zfs-linux package; it would be useful to users
of ZFS for schroot to support ZFS snapshots in addition to the other two
snapshot-based backends.

Attached is a preliminary patch which adds support for a zfs-snapshot type. 
It currently has a bug I've only just detected which prevents it from
working correctly for source chroots, so I'll revise it shortly.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru schroot-1.6.10/debian/control schroot-1.6.10/debian/control
--- schroot-1.6.10/debian/control   2018-09-01 02:25:59.0 -0500
+++ schroot-1.6.10/debian/control   2019-12-30 23:59:11.0 -0600
@@ -54,7 +54,7 @@
  sbuild (<< 0.62.6),
 # We need the --find option of update-binfmts
  binfmt-support (<< 2.0.1)
-Suggests: debootstrap, lvm2, btrfs-tools, aufs-tools | unionfs-fuse, 
qemu-user-static
+Suggests: debootstrap, lvm2, btrfs-tools, zfsutils-linux, aufs-tools | 
unionfs-fuse, qemu-user-static
 Description: Execute commands in a chroot environment
  schroot allows users to execute commands or interactive shells in
  different chroots.  Any number of named chroots may be created, and
@@ -67,7 +67,7 @@
  Several different types of chroot are supported, including normal
  directories in the filesystem, and also block devices.  Sessions,
  persistent chroots created on the fly from files (tar with optional
- compression) and Btrfs and LVM snapshots are also supported.
+ compression) and Btrfs, ZFS, and LVM snapshots are also supported.
  .
  schroot supports kernel personalities, allowing the programs run
  inside the chroot to have a different personality.  For example,
@@ -76,7 +76,7 @@
  .
  schroot also integrates with sbuild, to allow building packages with
  all supported chroot types, including session-managed chroot types
- such as Btrfs and LVM snapshots.
+ such as Btrfs, ZFS, and LVM snapshots.
  .
  schroot shares most of its options with dchroot, but offers vastly
  more functionality.
diff -Nru schroot-1.6.10/debian/patches/series 
schroot-1.6.10/debian/patches/series
--- schroot-1.6.10/debian/patches/series2018-09-01 02:25:59.0 
-0500
+++ schroot-1.6.10/debian/patches/series2019-12-30 19:40:44.0 
-0600
@@ -13,3 +13,4 @@
 update_czech_schroot_translation.patch
 update_french_schroot_manpage_translation_2018.patch
 update_german_schroot_manpage_translation_2018.patch
+zfs-snapshot-support.patch
diff -Nru schroot-1.6.10/debian/patches/zfs-snapshot-support.patch 
schroot-1.6.10/debian/patches/zfs-snapshot-support.patch
--- schroot-1.6.10/debian/patches/zfs-snapshot-support.patch1969-12-31 
18:00:00.0 -0600
+++ schroot-1.6.10/debian/patches/zfs-snapshot-support.patch2019-12-30 
23:59:11.0 -0600
@@ -0,0 +1,1186 @@
+Description: add support for a zfs-snapshot backend.
+Author: Steve Langasek 
+Last-Update: 2020-01-01
+
+Index: schroot-1.6.10/sbuild/sbuild-chroot-zfs-snapshot.cc
+===
+--- /dev/null
 schroot-1.6.10/sbuild/sbuild-chroot-zfs-snapshot.cc
+@@ -0,0 +1,259 @@
++/* Copyright © 2005-2009  Roger Leigh 
++ * Copyright © 2019   Steve Langasek 
++ *
++ * schroot is free software: you can redistribute it and/or modify it
++ * under the terms of the GNU General Public License as published by
++ * the Free Software Foundation, either version 3 of the License, or
++ * (at your option) any later version.
++ *
++ * schroot is distributed in the hope that it will be useful, but
++ * WITHOUT ANY WARRANTY; without even the implied warranty of
++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
++ * General Public License for more details.
++ *
++ * You should have received a copy of the GNU General Public License
++ * along with this program.  If not, see
++ * .
++ *
++ */
++
++#include 
++
++#include "sbuild-chroot-zfs-snapshot.h"
++#include "sbuild-chroot-block-device.h"
++#include "sbuild-chroot-facet-session.h"
++#include "sbuild-chroot-facet-session-clonable.h"
++#include "sbuild-chroot-facet-source-clonable.h"
++#include "sbuild-chroot-facet-mountable.h"
++#include "sbuild-format-detail.h"
++
++#include 
++#include 
++
++#include 
++
++using std::endl;
++using boost::format;
++using namespace sbuild;
++
++chroot_zfs_snapshot::chroot_zfs_snapshot ():
++  chroot_bloc

Bug#947918: RFP: soundtracker -- Fasttracker II compatible music sequencer and sampler

[Thomas Uwe Grüttmüller]

Package: wnpp
Severity: wishlist

* Package name: soundtracker
  Version : 1.0.0
  Upstream Author : Michael Krause , Yury Alyaev

* URL : http://www.soundtracker.org/
* License : GPL 2
  Programming Lang: C
  Description : Fasttracker II compatible music sequencer and sampler

SoundTracker is a music sequencer and sampler (aka tracker), that allows to
play and edit Fasttracker II modules in the .xm file format and to import
Protracker modules in the .mod format. A module is a music file that contains
notes and samples.


Why is this package useful?

  The package is useful for people who work with this music format.

Is it a dependency for another package?

  No.

Do you use it?

  Yes.

How does it compare to other packages?

  * xmp can play .xm files, but not edit them

  * milkytracker provides similar functionality but with a different GUI.

  * milkytracker’s timing is less accurate than that of soundtracker, so
modules with sung parts might play out of sync. It is therefor not an
alternative for .xm files containing sung parts or other long samples.


Up to version 0.6.8, soundtracker was already in Debian, and has been removed
in 2009. It was propably dropped due to its dependency on GTK1.

The current version 1.0.0 depends on

  libgtk2.0-dev
  libasound2-dev
  libsdl1.2-dev
  libaudiofile-dev
  libgoocanvas-dev


Cordially,
Thomas

Bug#946951:

[Tony Liu]

On 2019-12-29 01:16:01 -0500, Joe Nahmias wrote:
> On 12/27/2019 6:23 PM, Vincent Lefevre wrote:
> > On 2019-12-27 19:49:46 +, Joseph Nahmias wrote:
> > > On Fri, Dec 27, 2019 at 07:27:42PM +, Joseph Nahmias wrote:
> > > > The attached patch works around the issue until that is fixed.
> > >
> > > Of course, I forgot this patch... Take 2.
> >
> > Wouldn't the use of wildcards be a security issue?
> >
> > +   ln -s /tmp/.wine-`id -u`/server* /tmp/wine-*/
> >
> > i.e. could you end up creating wrong symbolic links?
>
> Attached is an updated patch that does the extra work to avoid the
> wildcards.
>
> > In any case, this seems rather ugly to me.
>
> Not sure precisely what you are referring to as ugly here;




Encountered the same problem, I solved it this way
# rm -fr /tmp/.wine
$ wine exe

$ ll /run/user/1000/wine
lrwxrwxrwx 1 ... ... /run/user/1000/wine -> /tmp/.wine-1000

>From this point of view, in essence, the runtime is also implemented based
on the soft chain.
so in fact this method should be no problem. The way I deleted above is
equivalent to ~clear cache & rerun~

Bug#947917: python3-plotly: FigureWidget doesn't work inside jupyter because files are missing

[Alexandre Detiste]

Package: python3-plotly
Version: 4.4.1+dfsg-1
Severity: normal

Hi,

At least .../site-packages/plotlywidget/static/index.js
and .../site-packages/plotlywidget/static/extension.js
are missing from the package.

I had to overide the Debian package with
"pip3 install plotly --force" to make it work.

Now Jupyter display the widgets.



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

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

Versions of packages python3-plotly depends on:
ii  python33.7.5-1
ii  python3-decorator  4.3.0-1.1
ii  python3-nbformat   4.4.0-3
ii  python3-requests   2.22.0-2
ii  python3-retrying   1.3.3-4
ii  python3-six1.13.0-1
ii  python3-tz 2019.3-1

python3-plotly recommends no packages.

Versions of packages python3-plotly suggests:
pn  ipython3
ii  python3-ipykernel   4.10.1-1
ii  python3-matplotlib  3.1.2-1
ii  python3-pandas  0.25.3+dfsg-4
pn  python3-scipy   

-- no debconf information

Bug#947907: uno-libs-private: Unmet dependencies

[William Panlener]

ure=6.4.0~rc1-5 ships files provided by other packages in addition to
the reported conflict. I have discovered the following conflicting
files and packages:

'/usr/share/java/juh.jar', which is also in package libjuh-java 1:6.4.0~rc1-5
'/usr/share/java/jurt.jar', which is also in package libjurt-java 1:6.4.0~rc1-5
'/usr/share/java/ridl.jar', which is also in package libridl-java 1:6.4.0~rc1-5
'/usr/share/java/unoloader.jar', which is also in package
libunoloader-java 1:6.4.0~rc1-5

Bug#947916: FTBFS: 5.0.2-1 fails to build from source, not transitioning to testing

[Sunil Mohan Adapa]

Source: pcp
Version: 5.0.2-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Debian build servers are unable to build the latest Debian package of pcp
uploaded to repositories: 5.0.2-1 [1]. As a consequence, pcp and it's
dependencies cockpit and freedombox are at threat of being removed from Debian
testing on January 10, 2020 [2].

This is due to incorrect invocation of dh_python2 which is no longer available
on these build machines. This can be fixed by

 * Conditionally invoking dh_python2 such as by if test -x /usr/bin/dh_python2;
then dh_python2 -a --package $(pcp_python2); fi in debian/rules. This may have
unintended effects on machines with dh_python2 installed but configured not to
build python2.

 * Completely dropping support for Python2 in control.master, control.python2,
rules, and fixcontrol.master

1)
https://buildd.debian.org/status/fetch.php?pkg=pcp&arch=amd64&ver=5.0.2-1&stamp=1576047957&raw=0
2) http://udd.debian.org/cgi-bin/autoremovals.yaml.cgi



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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAl4NY5YRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfKgkBAAprf7QlJNBDDWWzzI/5R1BbPI/zlr4NNV
jnKnj5F0NKWdCJjuJRcb53ukL/2g+u45K8l+YkpB9wJ0VLBhYJTMShNS5UhoQGyp
UdOzSwfBRCfqQCaJPT5YTqN4n+DsM8WOXjoxVzXkYa+GrKhle69MCppSVt6RgTXd
/ZSd+3AeUYgnFeCQKER30ge7kLvfZqPzjS0BkVYWkbWK78oWHmzlZ9FdJ3oUwyY6
r0lx+yVvveCC7FWEHXgRwnWy/3hX6nKM7c4VQ3TBOo0PywBSDd3G3RmBf90ggmy6
VIhqIK4+3UdKP94IvF96PpO+2ACCsIIH+tW7EYjQP2F2ANfg2NVHjsL+eMDdqwyJ
m9k4H8ZQMEWK35XCmi7FgBBRfEgJcsIVyebn2kzf4GNdM3I0ndUoO4ffg5Ac4Cui
uqIENJpPGZJpinXutcULVnYbJ4vpC7Q54D/mFjJV5YEvJj4JQ4dKL4sylMrffMqc
agKlAM5YsyjzLjLE/sYYcu4b0IOldvcqMZFxJaWcJFl5FUSRSlhi8IB1IJ1BmSKN
bH1GadpUYk/l4iyixW/bjj08IRg9ym1CFIAhLVOEO29+526Ilro2KKj4ZVbM3fTm
8jDa3mIdMLQLkWlUK/EqNpDg+s7TGhO3MqzLPVoXf+MCniSeIegDvdzirbFxdQtt
yi2vkee+7SU=
=LiUu
-END PGP SIGNATURE-

Bug#947915: release-notes: Suggest cleaning up leftover *.dpkg-old etc. config files

[Justin B Rye]

Karl O. Pinc wrote:
> Attached is a patch which suggests cleaning up unused config files
> leftover from prior upgrades, the foo.dpkg-old and similar files,
> before starting the new upgrade.

> --- a/en/upgrading.dbk
> +++ b/en/upgrading.dbk
> @@ -301,6 +301,17 @@ $ apt-forktracer | sort
>  It is a good idea to remove obsolete
>  packages from your system before upgrading.
>
> +  
> +A previous upgrade can have left unused copies of configuration

I'd recommend may have

> +files; old versions
> +of configuration files, versions supplied by the package
> +maintainers, etc.  Removing leftover files from previous upgrades,
> +before performing another upgrade, can avoid confusion.

The commas in this sentence seem subtly wrong.

> + Find such
> +leftover files with:
> +  
> +  
> +# find /etc -name '*.dpkg-*'
> +  

But in fact if you're going to do this sweep (and haven't previously
been in the habit of doing it), doesn't it make more sense to learn it
as something to do *after* every (dist- or package-)upgrade?  What
kinds of confusion does it risk if you do it then?

It might fit best in 4.7. "Preparing for the next release".

(Personally I have a cronjob that nags me if it sees any *.dpkg-new,
*.dpkg-old, *.dpkg-save, *.pam-old or *ucf-old files lying about.)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#946569: Request for CONFIG_EROFS_FS=m on 5.4+

[Gao Xiang]

Hi Salvatore,

On Wed, Jan 01, 2020 at 08:42:51PM +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 + pending
> 
> Hi,
> 
> On Wed, Dec 11, 2019 at 10:12:23AM +0800, Gao Xiang wrote:
> > Source: linux
> > Version: 5.4.2-1~exp1
> > Severity: normal
> > 
> > Hi Debian kernel maintainers,
> > 
> > Could you consider enabling EROFS filesystem support as a module
> > from 5.4 for end users now? It has been out of staging.
> > 
> > It has much better dynamic performance than squashfs for such
> > like LIVECD use. I'd suggest the following configuration:
> > 
> > CONFIG_EROFS_FS=m
> > # CONFIG_EROFS_FS_DEBUG is not set
> > CONFIG_EROFS_FS_XATTR=y
> > CONFIG_EROFS_FS_POSIX_ACL=y
> > CONFIG_EROFS_FS_SECURITY=y
> > CONFIG_EROFS_FS_ZIP=y
> > CONFIG_EROFS_FS_CLUSTER_PAGE_LIMIT=1
> > 
> > erofs-utils package has been available in testing branch as well,
> > https://packages.debian.org/source/bullseye/erofs-utils
> 
> Done in
> https://salsa.debian.org/kernel-team/linux/commit/33639568475c399acc9cd9d45e9b06a3a2df6e75
> with the suggested configuration.


Got it. Thanks for considering this.

Thanks,
Gao Xiang


> 
> Regards,
> Salvatore

Bug#947907: uno-libs-private: Unmet dependencies

[Rene Engelhard]

reassign 947907 ure
severity 947907 serious
retitle 947907 trying to overwrite '/usr/share/java/juh.jar', which is also in
package libjuh-java
forcemerge 947909 947907
thanks

Hi,

On Thu, Jan 02, 2020 at 12:32:24AM +0100, Domenico Cufalo wrote:
> Upgrading to v. 1:6.4.0~rc1-5, I had this output:

*After* a failed upgrade.

> Preparing to unpack .../ure_6.4.0~rc1-5_amd64.deb ...
> Unpacking ure (6.4.0~rc1-5) over (6.4.0~rc1-4) ...
> dpkg: error processing archive
> /var/cache/apt/archives/ure_6.4.0~rc1-5_amd64.deb
>  (--unpack):
>  trying to overwrite '/usr/share/java/juh.jar', which is also in package
> libjuh-
> java 1:6.4.0~rc1-5
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> Errors were encountered while processing:
>  /var/cache/apt/archives/ure_6.4.0~rc1-5_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)

Yes, that is the real issue.

Regards,

Rene

Bug#947915: release-notes: Suggest cleaning up leftover *.dpkg-old etc. config files

[Karl O. Pinc]

Package: release-notes
Severity: normal
Tags: patch

Hello,

Attached is a patch which suggests cleaning up unused config files
leftover from prior upgrades, the foo.dpkg-old and similar files,
before starting the new upgrade.

Regards,
Karl

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/en/upgrading.dbk b/en/upgrading.dbk
index b04a58e2..77f275fd 100644
--- a/en/upgrading.dbk
+++ b/en/upgrading.dbk
@@ -301,6 +301,17 @@ $ apt-forktracer | sort
 It is a good idea to remove obsolete
 packages from your system before upgrading.
   
+  
+A previous upgrade can have left unused copies of configuration
+files; old versions
+of configuration files, versions supplied by the package
+maintainers, etc.  Removing leftover files from previous upgrades,
+before performing another upgrade, can avoid confusion.  Find such
+leftover files with:
+  
+  
+# find /etc -name '*.dpkg-*'
+  
 
   
 The proposed-updates section

Bug#945188: xpdf: memory leak when changing page

[Vincent Lefevre]

On 2019-11-21 20:15:24 +0100, Bernhard Übelacker wrote:
> This patch makes some changes how containers get accessed.

Thanks. I confirm that it solves the problem on my side.

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

Bug#947913: telegram-desktop: alttab application fails to show telegram-desktop icon

[B Stack]

Package: telegram-desktop
Version: 1.8.15-2
Severity: minor

Please provide a symlink like so for each telegram.png in hicolor theme:
ln -s telegram.png telegram-desktop.png

The alttab program uses `xprop WM_CLASS` which for telegram-desktop is
"telegram-desktop" and "TelegramDesktop."

-- System Information:
Debian Release: 10.0
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages telegram-desktop depends on:
ii  libavcodec58  7:4.2.1-2+b1
ii  libavformat58 7:4.2.1-2+b1
ii  libavutil56   7:4.2.1-2+b1
ii  libc6 2.29-7
ii  libgcc1   1:9.2.1-21
ii  libglib2.0-0  2.62.4-1
ii  liblz4-1  1.9.2-2
ii  liblzma5  5.2.4-1+b1
ii  libminizip1   1.1-8+b1
ii  libopenal11:1.19.1-1+b1
ii  libopus0  1.3-1+b1
ii  libqt5core5a [qtbase-abi-5-12-5]  5.12.5+dfsg-5
ii  libqt5dbus5   5.12.5+dfsg-5
ii  libqt5gui55.12.5+dfsg-5
ii  libqt5network55.12.5+dfsg-5
ii  libqt5widgets55.12.5+dfsg-5
ii  librlottie0-1 0~git20190721.24346d0+dfsg-2+b1
ii  libssl1.1 1.1.1d-2
ii  libswresample37:4.2.1-2+b1
ii  libswscale5   7:4.2.1-2+b1
ii  libx11-6  2:1.6.8-1
ii  libxxhash00.7.2-1
ii  qt5-image-formats-plugins 5.12.5-1
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages telegram-desktop recommends:
ii  fonts-open-sans  1.11-1

telegram-desktop suggests no packages.

-- no debconf information

Bug#947914: libxslt: make distclean deletes doc/xsltproc.1 which is not regenerated

[Andreas Beckmann]

Source: libxslt
Version: 1.1.34-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

hi,

libxslt/experimental FTBFS twice in a row. debian/rules clean after the
first build removes doc/xsltproc.1 via 'make distclean', but that file
is not regenerated during the second build causing the install target to
fail. I did not check whether the package in sid has the same problem.

[...]
Making distclean in doc
make[3]: Entering directory '/build/libxslt-1.1.34/doc'
rm -rf .libs _libs
rm -f *~ *.1 *.bak *.hierarchy *.signals *-unused.txt
rm -f *.lo
test -z "" || rm -f 
if test ! -r Makefile.am ; then \
rm -f *.html *.templ *.xsa ; \
rm -rf EXSLT html ; \
fi
test . = "." || test -z "" || rm -f 
rm -f Makefile
make[3]: Leaving directory '/build/libxslt-1.1.34/doc'
[...]
dpkg-source: warning: ignoring deletion of file doc/xsltproc.1, use 
--include-removal to override
[...]
Making install in doc
make[3]: Entering directory '/build/libxslt-1.1.34/doc'
make[4]: Entering directory '/build/libxslt-1.1.34/doc'
make[4]: Nothing to be done for 'install-exec-am'.
/bin/mkdir -p /build/libxslt-1.1.34/debian/tmp/usr/share/doc/libxslt-1.1.34/html
/usr/bin/install -c -m 0644 ./*.html 
/build/libxslt-1.1.34/debian/tmp/usr/share/doc/libxslt-1.1.34/html
/usr/bin/install -c -m 0644 ./*.gif 
/build/libxslt-1.1.34/debian/tmp/usr/share/doc/libxslt-1.1.34/html
/bin/mkdir -p 
/build/libxslt-1.1.34/debian/tmp/usr/share/doc/libxslt-1.1.34/html/html
/usr/bin/install -c -m 0644 ./html/*.html 
/build/libxslt-1.1.34/debian/tmp/usr/share/doc/libxslt-1.1.34/html/html
/usr/bin/install -c -m 0644 ./html/*.png 
/build/libxslt-1.1.34/debian/tmp/usr/share/doc/libxslt-1.1.34/html/html
/bin/mkdir -p 
/build/libxslt-1.1.34/debian/tmp/usr/share/doc/libxslt-1.1.34/html/EXSLT
/usr/bin/install -c -m 0644 ./EXSLT/*.html 
/build/libxslt-1.1.34/debian/tmp/usr/share/doc/libxslt-1.1.34/html/EXSLT
/bin/mkdir -p 
/build/libxslt-1.1.34/debian/tmp/usr/share/doc/libxslt-1.1.34/html/tutorial
/usr/bin/install -c -m 0644 ./tutorial/* 
/build/libxslt-1.1.34/debian/tmp/usr/share/doc/libxslt-1.1.34/html/tutorial
/bin/mkdir -p 
/build/libxslt-1.1.34/debian/tmp/usr/share/doc/libxslt-1.1.34/html/tutorial2
/usr/bin/install -c -m 0644 ./tutorial2/* 
/build/libxslt-1.1.34/debian/tmp/usr/share/doc/libxslt-1.1.34/html/tutorial2
 /bin/mkdir -p '/build/libxslt-1.1.34/debian/tmp/usr/share/man/man1'
 /usr/bin/install -c -m 644 ./xsltproc.1 
'/build/libxslt-1.1.34/debian/tmp/usr/share/man/man1'
/usr/bin/install: cannot stat './xsltproc.1': No such file or directory
make[4]: *** [Makefile:521: install-man1] Error 1
make[4]: Leaving directory '/build/libxslt-1.1.34/doc'
make[3]: *** [Makefile:615: install-am] Error 2
make[3]: Leaving directory '/build/libxslt-1.1.34/doc'
[...]

Andreas


libxslt_1.1.34-1_twice.log.gz
Description: application/gzip

Bug#947912: hwloc: lstopo default scale is too small with graphical window on HiDPI screens

[Samuel Thibault]

Hello,

Vincent Lefevre, le jeu. 02 janv. 2020 01:48:43 +0100, a ecrit:
> It is possible to change the font size with --fontsize, but this
> does not work well as the space between the elements is not large
> enough.

You can use --gridsize to fix that part.

But yes, ideally lstopo would automatically use the dpi of the display,
to scale the font & grid sizes.

Samuel

Bug#947912: hwloc: lstopo default scale is too small with graphical window on HiDPI screens

[Vincent Lefevre]

Package: hwloc
Version: 2.1.0+dfsg-3
Severity: minor

The lstopo default scale is too small on HiDPI screens, with default
output (to a graphical window).

It is possible to change the font size with --fontsize, but this
does not work well as the space between the elements is not large
enough.

As a workaround, increasing the window manually works. But a good
window size should be used by default.

-- 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.4.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages hwloc depends on:
ii  libc6   2.29-7
ii  libcairo2   1.16.0-4
ii  libhwloc15  2.1.0+dfsg-3
ii  libtinfo6   6.1+20191019-1
ii  libx11-62:1.6.8-1

hwloc recommends no packages.

hwloc suggests no packages.

-- no debconf information

Bug#926242: [rb-general] Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images

[Chris Lamb]

[trimming CCs to just the mailing lists and #926242]

Hey all,

> > So, I heard a vague rumour that this "buster" thing was released? I
> > was thus wondering whether we could apply my patch from:
> > 
> >   https://bugs.debian.org/926242#127
> >   
> > :)
> 
> My current plan is (1) breathing a little, (2) getting the needed
> bugfixes into 10.1.

Whoops, I'm afraid I totally neglected to followup on this so I
apologise this got stalled. Anyway, anything I can do to help?


Best wishes,

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

Bug#947911: sqlgrey daemon does not stop when requested

[Karl O. Pinc]

Package: sqlgrey
Version: 1:1.8.0-1
Severity: serious
Tags: patch
Justification: Policy 9.3.2

Hello,

/etc/init.d/sqlgrey does not stop the sqlgrey daemon.  (Policy
seems to say that being able to stop is required, so I've marked
the bug serious.)

The problem is that start-stop-daemon --pidfile is no longer
sufficient to stop a daemon when the pidfile is written as
a non-priviliged user.  So the daemon is not stopped.
(As of start-stop-daemon version 1.19.3.)

The attached patch adds "--user sqlgrey" to the start-stop-daemon
command, which is enough that the command stops the daemon.

Regards,
Karl

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

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

Versions of packages sqlgrey depends on:
ii  adduser   3.118
pn  libdate-calc-perl 
pn  libdbd-pg-perl | libdbd-mysql-perl | libdbd-sqlite3-perl  
pn  libnet-server-perl
ii  perl  5.28.1-6

Versions of packages sqlgrey recommends:
pn  libdbd-pg-perl  
ii  postfix 3.4.7-0+deb10u1

sqlgrey suggests no packages.
--- sqlgrey 2020-01-01 17:23:16.952002224 -0600
+++ sqlgrey.new 2020-01-01 17:35:18.719746141 -0600
@@ -48,7 +48,8 @@
;;
   stop)
echo -n "Stopping $DESC: $NAME"
-   start-stop-daemon --stop --quiet --pidfile $PIDFILE --oknodo
+   start-stop-daemon --stop --quiet \
+ --user sqlgrey --pidfile $PIDFILE --oknodo
 rm -f $PIDFILE
echo "."
;;

Bug#947910: ure uninstallable because of file conflict with libjuh-java

[Ben Caradoc-Davies]

Package: ure
Version: 6.4.0~rc1-4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

upgrading:

   libjuh-java (1:6.4.0~rc1-2 => 1:6.4.0~rc1-5)
[...]
   ure (6.4.0~rc1-4 => 6.4.0~rc1-5)

results in:

Unpacking ure (6.4.0~rc1-5) over (6.4.0~rc1-4) ...
dpkg: error processing archive /tmp/apt-dpkg-
install-8kglun/11-ure_6.4.0~rc1-5_amd64.deb (--unpack):
 trying to overwrite '/usr/share/java/juh.jar', which is also in package
libjuh-java 1:6.4.0~rc1-5
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

[...]

Errors were encountered while processing:
 /tmp/apt-dpkg-install-8kglun/11-ure_6.4.0~rc1-5_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)



-- Package-specific info:

Java:
/usr/lib/jvm/java-11-openjdk-amd64/lib/amd64/client:/usr/lib/jvm/java-11-openjdk-amd64/lib/amd64/server:/usr/lib/jvm/java-11-openjdk-amd64/lib/amd64/native_threads:/usr/lib/jvm/java-11-openjdk-amd64/lib/amd64

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

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

Versions of packages ure depends on:
ii  libc6   2.29-7
ii  libgcc1 1:9.2.1-21
ii  libicu6363.2-2
ii  liblangtag1 0.6.3-1
ii  libstdc++6  9.2.1-21
iu  libuno-cppu36.4.0~rc1-5
iu  libuno-cppuhelpergcc3-3 6.4.0~rc1-5
iu  libuno-purpenvhelpergcc3-3  6.4.0~rc1-5
iu  libuno-sal3 6.4.0~rc1-5
iu  libuno-salhelpergcc3-3  6.4.0~rc1-5
ii  libxml2 2.9.4+dfsg1-8
iu  uno-libs-private6.4.0~rc1-5

Versions of packages ure recommends:
iu  libjuh-java1:6.4.0~rc1-5
iu  libjurt-java   1:6.4.0~rc1-5
iu  libridl-java   1:6.4.0~rc1-5
iu  libunoloader-java  1:6.4.0~rc1-5

Versions of packages ure suggests:
ii  default-jre [java5-runtime] 2:1.11-72
ii  openjdk-11-jre [java5-runtime]  11.0.6+7-1

-- no debconf information

Bug#947909: ure is trying to overwrite '/usr/share/java/juh.jar', which is also in package libjuh-java 1:6.4.0~rc1-5

[Laurent Bigonville]

Package: ure
Version: 6.4.0~rc1-5
Severity: serious

Hello,

The installation of the ure package fails with the following error:


Preparing to unpack .../ure_6.4.0~rc1-5_amd64.deb ...
Unpacking ure (6.4.0~rc1-5) over (6.4.0~rc1-4) ...
dpkg: error processing archive 
/var/cache/apt/archives/ure_6.4.0~rc1-5_amd64.deb (--unpack):
 trying to overwrite '/usr/share/java/juh.jar', which is also in package 
libjuh-java 1:6.4.0~rc1-5
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/ure_6.4.0~rc1-5_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Apparently both ure and libjuh-java packages are shipping the same file

Kind regards,

Laurent Bigonville

-- Package-specific info:

Java:
/usr/lib/jvm/java-11-openjdk-amd64/lib/amd64/client:/usr/lib/jvm/java-11-openjdk-amd64/lib/amd64/server:/usr/lib/jvm/java-11-openjdk-amd64/lib/amd64/native_threads:/usr/lib/jvm/java-11-openjdk-amd64/lib/amd64

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

Kernel: Linux 5.4.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages ure depends on:
ii  libc6   2.29-7
ii  libgcc1 1:9.2.1-21
ii  libicu6363.2-2
ii  liblangtag1 0.6.3-1
ii  libstdc++6  9.2.1-21
iu  libuno-cppu36.4.0~rc1-5
iu  libuno-cppuhelpergcc3-3 6.4.0~rc1-5
iu  libuno-purpenvhelpergcc3-3  6.4.0~rc1-5
iu  libuno-sal3 6.4.0~rc1-5
iu  libuno-salhelpergcc3-3  6.4.0~rc1-5
ii  libxml2 2.9.4+dfsg1-8
iu  uno-libs-private6.4.0~rc1-5

Versions of packages ure recommends:
iu  libjuh-java1:6.4.0~rc1-5
iu  libjurt-java   1:6.4.0~rc1-5
iu  libridl-java   1:6.4.0~rc1-5
iu  libunoloader-java  1:6.4.0~rc1-5

Versions of packages ure suggests:
ii  default-jre [java5-runtime] 2:1.11-72
ii  openjdk-11-jre [java5-runtime]  11.0.6+7-1

-- no debconf information

Bug#947908: pulseaudio: sound doesn't play on first launch of pulseaudio at login; restarting it always results in working sound but will reoccur on next boot

[Joshua]

Package: pulseaudio
Version: 12.2-4+deb10u1
Severity: normal

After installing systemd, the following problem appeared in pulseaudio:

The first login after boot launches a non-working pulseaudio. Killing and 
restarting pulseaudio results in
a working pulseaudio. It's not a wait for device to initialize problem. It 
doesn't matter how long I stare
at the login screen before logging in.

The normal debug steps are useless as the problem won't recur when pulseaudio 
is not restarted.

-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE=en_US 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  libasound2   1.1.8-1
ii  libasound2-plugins   1:1.1.8-dmo1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libdbus-1-3  1.12.16-1
ii  libgcc1  1:8.3.0-6
ii  libice6  2:1.0.9-2
ii  libltdl7 2.4.6-9
ii  liborc-0.4-0 1:0.4.28-3.1
ii  libpulse012.2-4+deb10u1
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.28-6
ii  libsoxr0 0.1.2-3
ii  libspeexdsp1 1.2~rc1.2-1+b2
ii  libstdc++6   8.3.0-6
ii  libsystemd0  241-7~deb10u2
ii  libtdb1  1.3.16-2+b1
ii  libudev1 241-7~deb10u2
ii  libwebrtc-audio-processing1  0.3-1
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-2
ii  libxtst6 2:1.2.3-1
ii  lsb-base 10.2019051400
ii  pulseaudio-utils 12.2-4+deb10u1

Versions of packages pulseaudio recommends:
pn  dbus-user-session  
ii  libpam-systemd 241-7~deb10u2
pn  rtkit  

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
ii  pavucontrol  3.0-4
pn  pavumeter
ii  udev 241-7~deb10u2

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (d

Bug#947907: uno-libs-private: Unmet dependencies

[Domenico Cufalo]

Package: uno-libs-private
Version: 6.4.0~rc1-5
Severity: normal

Dear Maintainer,

Upgrading to v. 1:6.4.0~rc1-5, I had this output:

$ sudo apt upgrade
[...]
The following packages have unmet dependencies:
 ure : Depends: uno-libs-private (= 6.4.0~rc1-4) but 6.4.0~rc1-5 is installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or
specify a solution).

Then

$ sudo apt --fix-broken install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  ure
The following packages will be upgraded:
  ure
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
41 not fully installed or removed.
Need to get 0 B/1742 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Reading changelogs... Done
(Reading database ... 286277 files and directories currently installed.)
Preparing to unpack .../ure_6.4.0~rc1-5_amd64.deb ...
Unpacking ure (6.4.0~rc1-5) over (6.4.0~rc1-4) ...
dpkg: error processing archive
/var/cache/apt/archives/ure_6.4.0~rc1-5_amd64.deb
 (--unpack):
 trying to overwrite '/usr/share/java/juh.jar', which is also in package
libjuh-
java 1:6.4.0~rc1-5
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/ure_6.4.0~rc1-5_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


Despite the bug, Libreoffice seems to be working fine.

Thank you so much in advance and Happy new Year,
Domenico



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

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

Versions of packages uno-libs-private depends on:
ii  libc6   2.29-7
ii  libgcc1 1:9.2.1-21
ii  libstdc++6  9.2.1-21
iu  libuno-cppu36.4.0~rc1-5
iu  libuno-sal3 6.4.0~rc1-5
iu  libuno-salhelpergcc3-3  6.4.0~rc1-5
ii  ure 6.4.0~rc1-4

uno-libs-private recommends no packages.

uno-libs-private suggests no packages.

-- no debconf information

Bug#930088: mpg123 plays back gibberish instead of music from mp3 files

[Thomas Orgis]

Am Mon, 24 Jun 2019 22:54:23 + (UTC)
schrieb Thorsten Glaser : 

> >I suspect the link from alsa to pulse is faulty, as mpg123's alsa output 
> >module
> >has been working fine for a long time now using proper alsa.  

I just had some reproducable playback trouble on a Ubuntu 18.04 box and
mpg123 -o alsa as opposed to mpg123 -o pulse: A brief period of static
noise and reported ALSA underruns on loading a new track. This hints at
some performance/timing issue that at least triggers this. I fixed it
in current mpg123 trunk by delaying device activation based on the
ringbuffer fill.

We used to have this in src/libout123/modules/alsa.c for a long time
(so, also in current Debian):

snd_pcm_sw_params_set_start_threshold(pcm, sw, 1)

This starts the audio device as soon as the first block of audio is
there. Strangely, this seems to work fine for real hardware or ALSA's
dmix stuff (where I'd expect the real trouble), but fails when being
decoupled via pulse. I changed that now to

snd_pcm_sw_params_set_start_threshold(pcm, sw, buffer_size/2)

and this seems to work fine in my tests. Maybe someone can confirm with
a build from the current https://mpg123.org/snapshot, or just this
little change applied to the debian package?

Interestingly enough, just not setting this value (relying on a
sensible default) does not help. The default doesn't seem to be
sensible.

A current workaround is to simply activate mpg123's background buffer
using mpg123 -b 512 (or any other number that feels good), it contains
logic probaby rather similar to ALSA's to start playback only after a
certain amount of PCM data is ready.


Alrithty then,

Thomas

PS: This may be a good time to be prepared for a general update of the
Debian package, as I really, really intend to finish mpg123 1.26.0
soon, with a rather disturbingly big amount of fixes and additions. I
have hope to really get it done this time (month, year, decade).

Bug#947904: ledger2beancount autopkgtest failure with new ledger

[Jelmer Vernooij]

On Wed, Jan 01, 2020 at 09:53:31PM +, plugwash wrote:
> package: ledger2beancount
> version: 1.8-1
> severity: serious
> 
> ledger recently migrated to python 3 (forced by boost dropping python 2
> support), this has broken the ledger2beancount autopkgtest and this is
> blocking ledger from migrating to testing.

It looks like the last upload (in unstable) doesn't actually migrate Python 3,
but just disables Python support altogether. :-(

I'll see if I can do an upload that just disables the Python tests for now.

Cheers,

Jelmer

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#947906: RM: api-hour -- ROM; abandoned upstream

[Piotr Ożarowski]

Package: ftp.debian.org
Severity: normal

Upstream replaced it with Pillars (which seems abandoned as well)


signature.asc
Description: PGP signature

Bug#947905: RM: emma -- ROM; abandoned upstream, uses unmaintained pygtk and deprecated Python2

[Piotr Ożarowski]

Package: ftp.debian.org
Severity: normal


signature.asc
Description: PGP signature

Bug#947904: ledger2beancount autopkgtest failure with new ledger

[plugwash]

package: ledger2beancount
version: 1.8-1
severity: serious

ledger recently migrated to python 3 (forced by boost dropping python 2 
support), this has broken the ledger2beancount autopkgtest and this is 
blocking ledger from migrating to testing.



autopkgtest [19:31:06]: test testsuite:  - - - - - - - - - - stderr - - - - - - 
- - - -
While parsing file 
"/tmp/autopkgtest-lxc.52s9eaxl/downtmp/build.oQM/src/tests/directives.ledger", 
line 209:
Error: 'python' directive seen, but Python support is missing
While parsing file 
"/tmp/autopkgtest-lxc.52s9eaxl/downtmp/build.oQM/src/tests/directives.ledger", 
line 213:
While evaluating value expression:
   print_type(true)
   
Error: Unknown identifier 'print_type'
While parsing file 
"/tmp/autopkgtest-lxc.52s9eaxl/downtmp/build.oQM/src/tests/directives.ledger", 
line 215:
Error: 'python' directive seen, but Python support is missing
make: *** [Makefile:8: test-stamp] Error 1

Bug#947397: transition: cppunit

[Rene Engelhard]

On Wed, Jan 01, 2020 at 10:34:07PM +0100, Paul Gevers wrote:
> Control: tags -1 - moreinfo
> Control: tags -1 confirmed
> 
> On 28-12-2019 11:21, Paul Gevers wrote:
> > PS: @Rene, as gatb-core is a transition by itself, we'll proceed with
> > cppunit after gatb-core migrates.
> 
> Rene, please go ahead. It looks like gatb-core is now the only
> reverse-dependency left. We'll handle it.

OK, done.

Regards,

Rene

Bug#947903: rust-cbindgen: autopkgtest failure: can't create /usr/share/cargo/registry/cbindgen-0.12.1/tests/expectations/alias.compat.o: Permission denied

[Paul Gevers]

Source: rust-cbindgen
Version: 0.9.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: important
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

Since version 0.9.0-1 rust-cbindgen has an autopkgtest, great. However,
it fails since its introduction. I copied some of the output at the
bottom of this report.

Normally these failures are blocking the migration to testing [1],
however, I want thunderbird to finally migrate to testing, so I have
ignored this failure, but can you please investigate the situation and
fix it? In principle this bug should be "serious", but then it would
block migration again, hence I filed it as important.

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-cbindgen/3824078/log.gz


running 69 tests
test test_alias ... FAILED
test test_annotation ... FAILED
test test_array ... FAILED
test test_asserted_cast ... FAILED
test test_assoc_const_conflict ... FAILED
test test_assoc_constant ... FAILED
test test_associated_in_body ... FAILED
test test_bitflags ... FAILED
test test_body ... FAILED
test test_cdecl ... FAILED
test test_cfg ... FAILED
test test_cfg_2 ... FAILED
test test_cfg_field ... FAILED
test test_char ... FAILED
test test_const_conflict ... FAILED
test test_const_transparent ... FAILED
test test_custom_header ... FAILED
test test_constant ... FAILED
test test_display_list ... FAILED
test test_destructor_and_copy_ctor ... FAILED
test test_docstyle_auto ... FAILED
test test_docstyle_c99 ... FAILED
test test_docstyle_doxy ... FAILED
test test_documentation ... FAILED
test test_enum ... FAILED
test test_euclid ... FAILED
test test_extern ... FAILED
test test_extern_2 ... FAILED
test test_fns ... FAILED
test test_global_attr ... FAILED
test test_include_guard ... FAILED
test test_include ... FAILED
test test_include_item ... FAILED
test test_include_specific ... FAILED
test test_inner_mod ... FAILED
test test_item_types ... FAILED
test test_item_types_renamed ... FAILED
test test_layout ... FAILED
test test_layout_aligned_opaque ... FAILED
test test_lifetime_arg ... FAILED
test test_layout_packed_opaque ... FAILED
test test_monomorph_2 ... FAILED
test test_monomorph_1 ... FAILED
test test_must_use ... FAILED
test test_monomorph_3 ... FAILED
test test_namespace_constant ... FAILED
test test_namespaces_constant ... FAILED
test test_no_includes ... FAILED
test test_nested_import ... FAILED
test test_nonnull ... FAILED
test test_prefix ... FAILED
test test_prefixed_struct_literal ... FAILED
test test_prefixed_struct_literal_deep ... FAILED
test test_renaming_overrides_prefixing ... FAILED
test test_rename ... FAILED
test test_reserved ... FAILED
test test_simplify_option_ptr ... FAILED
test test_static ... FAILED
test test_std_lib ... FAILED
test test_struct ... FAILED
test test_struct_literal ... FAILED
test test_style_crash ... FAILED
test test_struct_literal_order ... FAILED
test test_transform_op ... FAILED
test test_transparent ... FAILED
test test_typedef ... FAILED
test test_union ... FAILED
test test_using_namespaces ... FAILED
test test_va_list ... FAILED

failures:

 test_alias stdout 
Running:
"/tmp/tmp.eBeK8VQvKg/target/x86_64-unknown-linux-gnu/debug/cbindgen"
"--lang" "c" "--cpp-compat" "--style" "type" "-o"
"/usr/share/cargo/registry/cbindgen-0.12.1/tests/expectations/alias.compat.c"
"/usr/share/cargo/registry/cbindgen-0.12.1/tests/rust/alias.rs"
Running: "gcc" "-D" "DEFINED" "-c"
"/usr/share/cargo/registry/cbindgen-0.12.1/tests/expectations/alias.compat.c"
"-o"
"/usr/share/cargo/registry/cbindgen-0.12.1/tests/expectations/alias.compat.o"
thread 'test_alias' panicked at 'Output failed to compile: Output {
status: ExitStatus(ExitStatus(256)), stdout: "", stderr: "Assembler
messages:\nFatal error: can\'t create
/usr/share/cargo/registry/cbindgen-0.12.1/tests/expectations/alias.compat.o:
Permission denied\n" }', tests/tests.rs:82:5
stack backtrace:
   0: ::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::io::impls::>::write_fmt
   4: std::panicking::default_hook::{{closure}}
   5: std::panicking::default_hook
   6: std::panicking::rust_panic_with_hook
   7: std::panicking::continue_panic_fmt
   8: std::panicking::begin_panic_fmt
   9: tests::compile
 at tests/tests.rs:82
  10: tests::run_compile_test
 at tests/tests.rs:125
  11: tests::test_file
 at tests/tests.rs:136
  12: tests::test_alias
 at tests/tests.rs:160
  13: tests::test_alias::{{closure}}
 at tests/tests.rs:159
  14: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.40.0/src/libcore/ops/function.rs:227
  15:  as core::ops::function::FnOnce>::call_once
  16: __rust_maybe_catch_panic
  17: test::run_test_in_process
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a
verbose backtrace.




signature.asc
Description: OpenPGP digital signature

Bug#947881: [Pkg-opencl-devel] Bug#947881: pocl: fix build on hurd-i386

[Samuel Thibault]

Andreas Beckmann, le mer. 01 janv. 2020 22:10:57 +0100, a ecrit:
> On 01/01/2020 15.19, Samuel Thibault wrote:
> > pocl currently FTBFS on hurd-i386 only due to a header inclusion
> > condition bug, could you apply the attached patch?
> 
> Nice. Thanks.
> Does the buildlog show any symbols changes?

This is the diff I am getting

Samuel
dpkg-gensymbols: warning: debian/libpocl2/DEBIAN/symbols doesn't match 
completely debian/libpocl2.symbols
--- debian/libpocl2.symbols (libpocl2_1.3-10+hurd.1_hurd-i386)
+++ dpkg-gensymbols5QYPpU   2020-01-01 21:44:24.0 +
@@ -95,7 +95,7 @@
  
(optional=templinst)_ZN4llvm15callDefaultCtorIN4pocl14AllocasToEntryEEEPNS_4PassEv@Base
 0.10
  
(optional=templinst)_ZN4llvm15callDefaultCtorIN4pocl14IsolateRegionsEEEPNS_4PassEv@Base
 0.10
  
(optional=templinst)_ZN4llvm15callDefaultCtorIN4pocl18RemoveBarrierCallsEEEPNS_4PassEv@Base
 0.14
-#MISSING: 0.14-4~llvm3.9# 
(optional=templinst)_ZN4llvm15callDefaultCtorIN4pocl19TargetAddressSpacesEEEPNS_4PassEv@Base
 0.10
+#MISSING: 1.3-10+hurd.1# 
(optional=templinst)_ZN4llvm15callDefaultCtorIN4pocl19TargetAddressSpacesEEEPNS_4PassEv@Base
 0.10
  
(optional=templinst)_ZN4llvm15callDefaultCtorIN4pocl19WorkitemReplicationEEEPNS_4PassEv@Base
 0.10
  
(optional=templinst)_ZN4llvm15callDefaultCtorIN4pocl20CanonicalizeBarriersEEEPNS_4PassEv@Base
 0.10
  
(optional=templinst)_ZN4llvm15callDefaultCtorIN4pocl20ImplicitLoopBarriersEEEPNS_4PassEv@Base
 0.10
@@ -391,9 +391,9 @@
  
_ZNK4pocl27ImplicitConditionalBarriers16getAnalysisUsageERN4llvm13AnalysisUsageE@Base
 0.10
  (arch=!x32)_ZNK4pocl9Workgroup16getAnalysisUsageERN4llvm13AnalysisUsageE@Base 
1.3-5~llvm7
  (optional=templinst|arch=!x32)_ZNKSt5ctypeIcE8do_widenEc@Base 1.3-5~llvm7
-#MISSING: 1.3-3~gcc9# 
(optional=templinst)_ZNKSt8_Rb_treeIPN4llvm10BasicBlockES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE4findERKS2_@Base
 1.1-6~llvm6.0+gcc8
-#MISSING: 1.3-3~gcc9# 
(optional=templinst)_ZNSt11_Deque_baseIPN4llvm6RegionESaIS2_EED1Ev@Base 
1.1-6~llvm6.0+gcc8
-#MISSING: 1.3-3~gcc9# 
(optional=templinst)_ZNSt11_Deque_baseIPN4llvm6RegionESaIS2_EED2Ev@Base 
1.1-6~llvm6.0+gcc8
+#MISSING: 1.3-10+hurd.1# 
(optional=templinst)_ZNKSt8_Rb_treeIPN4llvm10BasicBlockES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE4findERKS2_@Base
 1.1-6~llvm6.0+gcc8
+#MISSING: 1.3-10+hurd.1# 
(optional=templinst)_ZNSt11_Deque_baseIPN4llvm6RegionESaIS2_EED1Ev@Base 
1.1-6~llvm6.0+gcc8
+#MISSING: 1.3-10+hurd.1# 
(optional=templinst)_ZNSt11_Deque_baseIPN4llvm6RegionESaIS2_EED2Ev@Base 
1.1-6~llvm6.0+gcc8
 #MISSING: 1.3-5~llvm7# 
(optional=templinst|arch=armel)_ZNSt23_Sp_counted_ptr_inplaceIN4llvm3sys2fs6detail12DirIterStateESaIS4_ELN9__gnu_cxx12_Lock_policyE1EE10_M_destroyEv@Base
 0.14-7~llvm4.0
 #MISSING: 1.3-5~llvm7# 
(optional=templinst|arch=armel)_ZNSt23_Sp_counted_ptr_inplaceIN4llvm3sys2fs6detail12DirIterStateESaIS4_ELN9__gnu_cxx12_Lock_policyE1EE10_M_disposeEv@Base
 0.14-7~llvm4.0
 #MISSING: 1.3-5~llvm7# 
(optional=templinst|arch=armel)_ZNSt23_Sp_counted_ptr_inplaceIN4llvm3sys2fs6detail12DirIterStateESaIS4_ELN9__gnu_cxx12_Lock_policyE1EE14_M_get_deleterERKSt9type_info@Base
 0.14-7~llvm4.0
@@ -458,7 +458,7 @@
  
(optional=templinst)_ZNSt6vectorIPN4llvm10BasicBlockESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 0.13-9~llvm3.8+gcc7
  
(optional=templinst)_ZNSt6vectorIPN4llvm10BasicBlockESaIS2_EE6insertEN9__gnu_cxx17__normal_iteratorIPKS2_S4_EERS7_@Base
 0.10
  
(optional=templinst)_ZNSt6vectorIPN4llvm11InstructionESaIS2_EE17_M_realloc_insertIJRKS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 0.13-9~llvm3.8+gcc7
-#MISSING: 0.14-4~llvm3.9# 
(optional=templinst)_ZNSt6vectorIPN4llvm12MemIntrinsicESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 0.13-9~llvm3.8+gcc7
+#MISSING: 1.3-10+hurd.1# 
(optional=templinst)_ZNSt6vectorIPN4llvm12MemIntrinsicESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 0.13-9~llvm3.8+gcc7
  
(optional=templinst)_ZNSt6vectorIPN4llvm4TypeESaIS2_EE12emplace_backIJS2_EEEvDpOT_@Base
 1.0
  
(optional=templinst)_ZNSt6vectorIPN4llvm4TypeESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 0.13-9~llvm3.8+gcc7
  
(optional=templinst)_ZNSt6vectorIPN4llvm5ValueESaIS2_EE12emplace_backIJS2_EEEvDpOT_@Base
 0.10
@@ -471,12 +471,12 @@
  
(optional=templinst)_ZNSt6vectorIPN4llvm8FunctionESaIS2_EE17_M_realloc_insertIJRKS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 0.14
  
(optional=templinst)_ZNSt6vectorIPN4llvm8FunctionESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 1.3
  
(optional=templinst)_ZNSt7__cxx1110_List_baseINS_12basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE8_M_clearEv@Base
 1.3
-#MISSING: 0.14-7~llvm4.0# 
(optional=templinst)_ZNSt7__cxx1110_List_baseISt4pairIPvSt10unique_ptrIN4llvm6detail21AnalysisResultConceptINS4_8FunctionEEESt14default_deleteIS8_EEESaISC_EE8_M_clearEv@Base
 0.13-3~llvm3.8
+#MISSI

Bug#947397: transition: cppunit

[Rene Engelhard]

On Wed, Jan 01, 2020 at 10:34:07PM +0100, Paul Gevers wrote:
> Control: tags -1 - moreinfo
> Control: tags -1 confirmed
> 
> On 28-12-2019 11:21, Paul Gevers wrote:
> > PS: @Rene, as gatb-core is a transition by itself, we'll proceed with
> > cppunit after gatb-core migrates.
> 
> Rene, please go ahead. It looks like gatb-core is now the only
> reverse-dependency left. We'll handle it.

But gab-core itself is blocked by the piuparts regression?

$ grep-excuses gatb-core
gatb-core (1.4.1+git20190813.a73b6dd+dfsg-1 to 1.4.1+git20191209.9398f28+dfsg-1)
Maintainer: Debian Med Packaging Team
5 days old (needed 5 days)
Migration status for gatb-core (1.4.1+git20190813.a73b6dd+dfsg-1 to 
1.4.1+git20191209.9398f28+dfsg-1): BLOCKED: Rejected/violates migration 
policy/introduces a regression
Issues preventing migration:
Rejected due to piuparts regression - 
https://piuparts.debian.org/sid/source/g/gatb-core.html
Additional info:
5 days old (needed 5 days)

Regards,

Rene

Bug#947902: midori: Crash upon clearing URL

[Peter]

Package: midori
Version: 7.0-2
Severity: normal

Dear Maintainer,

midori 7 crashes when I type a word in an address bar, press Ctrl-A and then
Del.



-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (1001, 'stable'), (500, 'stable-updates')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-6-686-pae (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages midori depends on:
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libgck-1-0   3.28.1-1
ii  libgcr-base-3-1  3.28.1-1
ii  libgcr-ui-3-13.28.1-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgirepository-1.0-11.58.3-2
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk-3-0   3.24.5-1
ii  libjavascriptcoregtk-4.0-18  2.24.2-dmo1
ii  libp11-kit0  0.23.15-2
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpeas-1.0-01.22.0-4
ii  libsoup2.4-1 2.64.2-2
ii  libsqlite3-0 3.27.2-3
ii  libwebkit2gtk-4.0-37 2.24.2-dmo1

Versions of packages midori recommends:
ii  gnome-icon-theme  3.12.0-3
ii  gnome-keyring 3.28.2-5

midori suggests no packages.

-- no debconf information

Bug#947397: transition: cppunit

[Paul Gevers]

Control: tags -1 - moreinfo
Control: tags -1 confirmed

On 28-12-2019 11:21, Paul Gevers wrote:
> PS: @Rene, as gatb-core is a transition by itself, we'll proceed with
> cppunit after gatb-core migrates.

Rene, please go ahead. It looks like gatb-core is now the only
reverse-dependency left. We'll handle it.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[Paul Gevers]

Hi all,

On 31-12-2019 22:50, Chris Lamb wrote:
> Hi László,
> 
>>   File "/<>/tests/admin_inlines/tests.py", line 1, in 
>> from selenium.common.exceptions import NoSuchElementException
>> ModuleNotFoundError: No module named 'selenium'
>>
>> Are you going to upload it fixed to Sid?
> 
> Thanks for uploading sqlite. This exception was already fixed in
> #947549…
> 
>> Happy New Year!
> 
> … you too. :)

I have given-back python-django, and it built now. Thanks.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#947901: gnome-js-common: unmaintained upstream since around 2010

[Simon McVittie]

Source: gnome-js-common
Version: 0.1.2-2
Severity: serious
Tags: upstream wontfix
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs unmaintained-upstream

gnome-js-common doesn't appear to be depended on by any other package, and
its upstream git repository has been archived, with no significant commits
since 2010: https://gitlab.gnome.org/Archive/gnome-js-common

It probably shouldn't be in future Debian stable releases without someone
taking over upstream maintenance.

Does anyone object to me opening a RM: RoM bug?

Thanks,
smcv

Bug#947881: [Pkg-opencl-devel] Bug#947881: pocl: fix build on hurd-i386

[Andreas Beckmann]

On 01/01/2020 15.19, Samuel Thibault wrote:
> pocl currently FTBFS on hurd-i386 only due to a header inclusion
> condition bug, could you apply the attached patch?

Nice. Thanks.
Does the buildlog show any symbols changes?

Andreas

Bug#947247: libcln-dev: move cln.pc to a multiarch location

[Richard B. Kreckel]

On 23.12.19 15:18, Helmut Grohne wrote:
> ginac fails to cross build from source, because it cannot find cln.pc
> using pkg-config. During cross compilation, pkg-config does not search
> /usr/lib/pkgconfig. It only searches /usr/share/pkgconfig and
> /usr/lib//pkgconfig. To be usable for cross compilation, cln.pc
> must be moved to a multiarch location. Please consider applying the
> attached patch.

Thank you for reporting this!

Hmmm, I have a question: Wouldn't it be more consistent to set $(libdir)
to /usr/lib//, so the library files are installed there, too,
not in /usr/lib/?

  -richy.
-- 
Richard B. Kreckel

Bug#930248: RM: gnome-xcf-thumbnailer -- RC buggy, dead-upstream, unmaintained, obsolete

[Simon McVittie]

Control: reassign -1 ftp.debian.org
Control: severity -1 normal
Control: retitle -1 RM: gnome-xcf-thumbnailer -- RoQA; RC buggy, dead upstream, 
appears obsolete

On Sun, 09 Jun 2019 at 11:30:57 +0200, Tobias Frost wrote:
> gnome-xcf-thumbnailer is currently RC buggy with 2 bugs:
> #655465 [S|  |  ] [gnome-xcf-thumbnailer] No thumbnails created in Gnome 3.2.1
> #886072 [S|  |  ] [src:gnome-xcf-thumbnailer] gnome-xcf-thumbnailer: Depends 
> on gconf
> 
> However, at least on my system, xcf thumbnails are still generated in
> Gnome so it seems that this package is obsolete anyway.  It is for sure
> dead-upstream (last release 10 years ago) and it seems to be
> unmaintained in Debian.
> 
> Thus I suggest to RM this package.

Nobody objected within 6 months, and I'm trying to tidy up some of the
unmaintained GNOME-2-era GNOME stuff (or at least make sure it has bug
reports about being unmaintained upstream), so let's do this.

smcv

Bug#941657: RFS: python-lark

[Peter Wienemann]

Dear DDs,

I prepared packaging for the parsing library python-lark (ITP bug
#941657). It is needed to bump the versions of prewikka [0] and
charliecloud [1]. The git repository is available on

https://salsa.debian.org/python-team/modules/python-lark

It would be great if someone could review the code, provide feedback and
- once everything looks fine - upload it.

Thanks, Peter

[0] https://tracker.debian.org/pkg/prewikka
[1] https://tracker.debian.org/pkg/charliecloud

Bug#947900: chemical-mime-data: build-depends on unmaintained gnome-mime-data

[Simon McVittie]

Package: chemical-mime-data
Version: 0.1.94-7
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gnome-mime-data
Control: block 947878 by -1

chemical-mime-data build-depends on the unmaintained gnome-mime-data
package, which appears to have been used by the GNOME 2 gnome-vfs
libraries, which became obsolete with the release of GNOME 3 in 2011 and
were finally removed from Debian last year. This is the only dependency
in Debian unstable that would be broken by removing gnome-mime-data.

All vaguely modern versions of GNOME (and all other major desktop
environments, as far as I know) use the freedesktop.org shared-mime-info
database for MIME types. chemical-mime-data appears to contain data to
extend both the newer shared-mime-info and the old gnome-mime-data.

Please either extend shared-mime-info only (and stop extending,
build-depending on or suggesting gnome-mime-data), or get these MIME
types incorporated into the upstream shared-mime-info package so that
chemical-mime-data can turn into a transitional package.

Thanks,
smcv

Bug#945314: freecad: FTBFS on several architectures

[Gianfranco Costamagna]

control: fixed -1 0.18.4+dfsg1-2
control: close -1

On Mon, 30 Dec 2019 15:08:50 +0100 Gianfranco Costamagna 
 wrote:
> control: tags -1 patch pending
> 
> in deferred/1 there is a version that should now build with the new pyside.
> 
> I'm pushing on git my changes
> 
> cheers, and thanks for the help
> 
> Gianfranco
> 
> On Wed, 18 Dec 2019 11:45:06 +0100 Tommaso Colombo  
> wrote:
> > Package: freecad
> > Version: 0.18.4+dfsg1-1
> > Followup-For: Bug #945314
> > Control: block -1 by 946082
> > 
> > I believe this is caused by a change in the pyside2 upstream source: since
> > PySide 5.13, the CMake files shipped in libshiboken2-dev have a dependency 
> > on
> > the /usr/bin/shiboken2 executable. However libshiboken2-dev does not depend 
> > on
> > shiboken2, which causes freecad to FTBFS. I've reported the missing 
> > dependency
> > as bug #946082.
> > 
> > 
> 
> 

Bug#947754: [omv.dynamicpuzzle.ro] gitlab mattermost integration error

[Pirate Praveen]

On തി, Dec 30, 2019 at 02:25, Dragos Jarca 
 wrote:

Package: gitlab
Version: 12.4.6-1
Severity: normal

Dear Maintainer,

I try to integrate mattermost Version: 5.18.0 with gitlab using 
bundled plugins.

Followed instructions from mattermost and gitlab.

When I try to /gitlab connect and Click here to link your GitLab 
account I have:

- no errors in mattermost console with debuug activated.
- have 500 Whoops, something went wrong on our end in gitlab windows 
opened by mattermost

and gitlab in log says:

NoMethodError (undefined method `mapping' for 
Doorkeeper::Rails::Routes:Class):


lib/gitlab/request_profiler/middleware.rb:17:in call'
lib/gitlab/middleware/go.rb:20:incall'
lib/gitlab/etag_caching/middleware.rb:13:in call'
lib/gitlab/middleware/correlation_id.rb:16:inblock in call'
lib/gitlab/middleware/correlation_id.rb:15:in call'
lib/gitlab/middleware/multipart.rb:117:incall'
lib/gitlab/middleware/read_only/controller.rb:48:in call'
lib/gitlab/middleware/read_only.rb:18:incall'
lib/gitlab/middleware/basic_health_check.rb:25:in call'
lib/gitlab/request_context.rb:32:incall'
lib/gitlab/metrics/requests_rack_middleware.rb:49:in call'
lib/gitlab/middleware/release_env.rb:12:incall'

I think that ruby-doorkeeper and/or ruby-doorkeeper-openid-connect 
can be the problem.


We have a newer version of doorkeeper in debian (4.4.2 in debian where 
as upstream still uses 4.3.2). May be 
https://salsa.debian.org/ruby-team/gitlab/blob/debian/12.6.1-1/debian/patches/0670-allow-doorkeepr-4_3.patch 
needs more changes.

Bug#944742: fixed in assimp 5.0.0~ds2-4

[Gianfranco Costamagna]

Hello,
On Sun, 22 Dec 2019 12:29:49 +0100 Gianfranco Costamagna 
 wrote:
> control: unarchive -1
> control: reopen -1
> 
> Hello, looks like we still have segfaults/failures on:
> armhf: http://autopkgtest.ubuntu.com/packages/a/assimp/focal/armhf
> ppc64el: http://autopkgtest.ubuntu.com/packages/a/assimp/focal/ppc64el
> s390x: http://autopkgtest.ubuntu.com/packages/a/assimp/focal/s390x
> 
> they previously passed, so this is why they should be considered probably RC 
> (and why I'm reopening this bug)...
> 
> Can you please have another look?
> 
> Note, those pages update in ~12h after sid has been updated, so you might 
> want to use them as a testbed in case you can't have a porterbox access...
> 

ping please? I fixed pyside2 and freecad, but autoremoval is still kicking...

G.

Bug#947899: xerces-c: FTBFS on ports without java support

[Samuel Thibault]

Source: xerces-c
Version: 3.2.2+debian-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

xerces-c is currently not getting built on ports without java support
only because there are java build-dependencies which are actually only
used for generating the arch:all documentation. The attached patch fixes
this by moving the java dependencies to Build-Depends-Indep. I could
check that the generated packages still contain the same set of files.

Samuel

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

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

-- 
Samuel
 can you guys see what I type?
 no, raize
 How do I set it up so you can see it?
--- debian/control.original 2020-01-01 19:47:04.0 +
+++ debian/control  2020-01-01 19:54:00.0 +
@@ -2,14 +2,14 @@
 Section: libs
 Priority: optional
 Build-Depends: debhelper (>> 11),
-   default-jre-headless | default-jre,
-   libatk-wrapper-java,
libcurl4-gnutls-dev,
-   libicu-dev,
-   libstylebook-java,
-   libxalan2-java,
-   libxerces2-java
-Build-Depends-Indep: doxygen
+   libicu-dev
+Build-Depends-Indep: doxygen,
+ default-jre-headless | default-jre,
+ libatk-wrapper-java,
+ libstylebook-java,
+ libxalan2-java,
+ libxerces2-java
 Maintainer: William Blough 
 Standards-Version: 4.2.1
 Vcs-Browser: https://salsa.debian.org/bblough/xerces-c

Bug#947898: RFS: zope.schema/4.9.3-1 [QA] -- zope.interface extension for defining data schemas

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "zope.schema"

 * Package name: zope.schema
   Version : 4.9.3-1
   Upstream Author : Zope Foundation and Contributors 


 * URL : https://pypi.python.org/pypi/zope.schema
 * License : Zope-2.1
 * Vcs : None
   Section : zope

It builds those binary packages:

  python3-zope.schema - zope.interface extension for defining data schemas

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


  https://mentors.debian.net/package/zope.schema

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

  dget -x 
https://mentors.debian.net/debian/pool/main/z/zope.schema/zope.schema_4.9.3-1.dsc


Changes since the last upload:

   * QA upload
   * New upstream release
   * d/watch
 - Use secure URI
   * d/control
 - Change to debhelper-compat
 - Bump debhelper to 12
 - Update Standards-Version to 4.4.1
 - Priority: change from extra to optional
 - Add Rules-Requires-Root
 - Secure URI on homepage
   * d/copyright
 - Use secure URI
 - Remove Files-Excluded, not included upstream.
   * d/rules
 - Enable testsuite

Regards,
Håvard

Bug#864242: Review of propsed fix for /etc/cron.monthly/acct failure on recent installs

[Sergio Gelato]

This bug is still present in buster.

I'm not sure that the proposed fix will do the right thing if logrotate is not 
installed (which I think can happen, as logrotate is not a dependency of acct 
and only has priority important, not required). How about moving the "exit 0" 
to an else clause in the existing "if [-f /var/log/wtmp.1 ]" block?

Bug#947897: doxygen: does not build on ports without java support

[Samuel Thibault]

Package: doxygen
Version: 1.8.8-5
Severity: important
Tags: patch

Hello,

doxygen currently doesn't build on ports without java support only
because it still depends on yui-compressor, but that is not actually
used any more, as done by patch avoid-compass.diff. Could you apply the
attached patch to drop that unused dependency?

Thanks,
Samuel

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

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

Versions of packages doxygen depends on:
ii  libc62.29-3
ii  libclang1-3.51:3.5.2-3~bpo8+2
ii  libgcc-s1 [libgcc1]  10-20191205-1
ii  libgcc1  1:9.2.1-21
ii  libsqlite3-0 3.30.1-1
ii  libstdc++6   10-20191205-1
ii  libxapian22  1.2.19-1+deb8u1

doxygen recommends no packages.

Versions of packages doxygen suggests:
pn  doxygen-doc
pn  doxygen-gui
ii  doxygen-latex  1.8.8-5
ii  graphviz   2.42.2-3

-- no debconf information

-- 
Samuel
 can you guys see what I type?
 no, raize
 How do I set it up so you can see it?
--- debian/control.original 2020-01-01 21:18:52.371433428 +0100
+++ debian/control  2020-01-01 21:18:54.571434058 +0100
@@ -10,7 +10,6 @@
   zlib1g-dev,
   libxapian-dev (>= 1.2.21-1.2),
   cmake,
-  yui-compressor,
   llvm-9-dev [amd64 armel armhf arm64 i386 mips mipsel mips64el ppc64 
ppc64el s390x sparc64],
   libclang-9-dev [amd64 armel armhf arm64 i386 mips mipsel mips64el ppc64 
ppc64el s390x sparc64],
   clang-9[amd64 armel armhf arm64 i386 mips mipsel mips64el ppc64 
ppc64el s390x sparc64],

Bug#944012: freetds: diff for NMU version 1.1.6-1.1

[Salvatore Bonaccorso]

Control: tags 944012 + patch
Control: tags 944012 + pending


Dear maintainer,

I've prepared an NMU for freetds (versioned as 1.1.6-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -u freetds-1.1.6/debian/changelog freetds-1.1.6/debian/changelog
--- freetds-1.1.6/debian/changelog
+++ freetds-1.1.6/debian/changelog
@@ -1,3 +1,10 @@
+freetds (1.1.6-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * tds: Make sure UDT has varint set to 8 (CVE-2019-13508) (Closes: #944012)
+
+ -- Salvatore Bonaccorso   Wed, 01 Jan 2020 21:09:16 +0100
+
 freetds (1.1.6-1) unstable; urgency=medium
 
   * New upstream release.
diff -u freetds-1.1.6/src/tds/data.c freetds-1.1.6/src/tds/data.c
--- freetds-1.1.6/src/tds/data.c
+++ freetds-1.1.6/src/tds/data.c
@@ -1428,6 +1428,7 @@
 	tds_get_string(tds, tds_get_usmallint(tds), NULL, 0);
 
 	col->column_size = 0x7ffflu;
+	col->column_varint_size = 8;
 
 	return TDS_SUCCESS;
 }
@@ -1435,6 +1436,7 @@
 TDS_INT
 tds_clrudt_row_len(TDSCOLUMN *col)
 {
+	col->column_varint_size = 8;
 	/* TODO save other fields */
 	return sizeof(TDSBLOB);
 }

Bug#947895: postgresql-common: pg_upgradecluster fails when old cluster has no SSL but SSL is broken

[Karl O. Pinc]

Package: postgresql-common
Version: 200+deb10u3
Severity: normal

Hello,

When the old cluster has SSL turned off, but when SSL is broken
enough to prevent PG from starting, pg_upgradecluster fails.

This is because pg_upgradecluster is started before the data
copy with SSL turned on.  And with SSL broken won't start.

It is not entirely unusual that SSL is broken.  See, e.g.,
bug #924881.  I am not sure how easy it is to break
SSL in a way that prevents PG from starting but #924881
shows that it is possible.  SSL is complicated enough
that it has many ways to break.  :-)

The initial cluster startup for data copy is with pg_hba.conf in
"trust" mode, so SSL is not needed for the copy step.

Regards,
Karl

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

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

Versions of packages postgresql-common depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.71
ii  lsb-base  10.2019051400
ii  postgresql-client-common  200+deb10u3
ii  procps2:3.3.15-2
ii  ssl-cert  1.0.39
ii  ucf   3.0038+nmu1

Versions of packages postgresql-common recommends:
ii  e2fsprogs  1.44.5-1+deb10u2
ii  logrotate  3.14.0-4

Versions of packages postgresql-common suggests:
ii  libjson-perl  4.02000-1

-- debconf information:
  postgresql-common/catversion-bump:
* postgresql-common/ssl: true
* postgresql-common/obsolete-major:

Bug#947896: wal2json: autopkgtest regression: output different

[Paul Gevers]

Source: wal2json
Version: 1.0-6
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of wal2json the autopkgtest of wal2json fails in
testing when that autopkgtest is run with the binary packages of
wal2json from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
wal2json   from testing1.0-6
all others from testingfrom testing

Please have a look at the log linked below, copying the output here
doesn't make a lot of sense.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? I'm filing this bug
already because it interferes with the glibc upload and I am going to
ignore the failure of this version for that purpose, but don't want this
version to migrate without this issue fixed.

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=wal2json

https://ci.debian.net/data/autopkgtest/testing/amd64/w/wal2json/3833450/log.gz

test toast... FAILED   40 ms
test bytea... FAILED   27 ms



signature.asc
Description: OpenPGP digital signature

Bug#947894: mkl-dnn: autopkgtest regression: 'CL/cl.h' file not found

[Paul Gevers]

Source: mkl-dnn
Version: 2.0~beta3-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of mkl-dnn the autopkgtest of mkl-dnn fails in
testing when that autopkgtest is run with the binary packages of mkl-dnn
from unstable. It passes when run with only packages from testing. In
tabular form:
   passfail
mkl-dnnfrom testing2.0~beta3-1
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? I'm filing this bug
already because it interferes with the glibc upload and I am going to
ignore the failure of this version for that purpose, but don't want this
version to migrate without this issue fixed.

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

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
mkl-dnn/2.0~beta3-1. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=mkl-dnn

https://ci.debian.net/data/autopkgtest/testing/amd64/m/mkl-dnn/3830710/log.gz

autopkgtest [11:11:27]: test command24: [---
In file included from examples/rnn_training_f32.cpp:29:
In file included from examples/example_utils.hpp:26:
In file included from /usr/include/dnnl.hpp:33:
/usr/include/dnnl.h:29:10: fatal error: 'CL/cl.h' file not found
#include 
 ^
1 error generated.
autopkgtest [11:11:28]: test command24: ---]
autopkgtest [11:11:28]: test command24:  - - - - - - - - - - results - -
- - - - - - - -
command24FAIL non-zero exit status 1
autopkgtest [11:11:29]:  summary
command1 FAIL non-zero exit status 1o
command2 FAIL non-zero exit status 1
command3 FAIL non-zero exit status 1
command4 FAIL non-zero exit status 1
command5 FAIL non-zero exit status 1
command6 FAIL non-zero exit status 1
command7 FAIL non-zero exit status 1
command8 FAIL non-zero exit status 1
command9 FAIL non-zero exit status 1
command10FAIL non-zero exit status 1
command11FAIL non-zero exit status 1
command12FAIL non-zero exit status 1
command13FAIL non-zero exit status 1
command14FAIL non-zero exit status 1
command15FAIL non-zero exit status 1
command16FAIL non-zero exit status 1
command17FAIL non-zero exit status 1
command18FAIL non-zero exit status 1
command19FAIL non-zero exit status 1
command20FAIL non-zero exit status 1
command21FAIL non-zero exit status 1
command22FAIL non-zero exit status 1
command23FAIL non-zero exit status 1
command24FAIL non-zero exit status 1



signature.asc
Description: OpenPGP digital signature

Bug#922533: Review of proposed move of /var/log/account to /var/account

[Sergio Gelato]

I'm looking at the proposed fix for this bug and have a few concerns. I hope 
they can be addressed before the next upload.

1. What about the possibility that /var/log and /var are different filesystems? 
The preinst may need some error checking to handle out-of-space conditions from 
mv, and the administrator needs to be warned in advance about the move (I think 
this calls at least for a mention in the release notes). Moreover, I'm not 
convinced that the currently proposed preinst script is idempotent (policy 
§6.2). How about adding a symbolic link from /var/account to /var/log/account 
on upgrade instead?

2. What happens if both /var/account and /var/log/account already exist? Is it 
really appropriate to try and clobber an existing /var/account without 
consulting the administrator? Again, consider the idempotency requirement.

3. I'm not sure offhand whether process accounting will be turned off while the 
preinst script is running. (The old prerm in buster only stops the acct service 
on remove, not on upgrade.) If not, there is a risk that accounting records 
will be written to the old location during the move. (At the same time, I'd 
like to keep any gap in process accounting coverage at a minimum; but this is a 
wish, not a requirement.)

Bug#945969: tinyeartrainer: Intent to remove from Debian

[Moritz Mühlenhoff]

On Sun, Dec 01, 2019 at 04:19:26PM -0500, Jeremy Bicha wrote:
> Source: tinyeartrainer
> Version: 0.1.0-4
> Severity: serious
> Tags: bullseye sid
> 
> tinyeartrainer was recently removed from Testing as part of the
> Python2 removals.
> 
> It looks to me like tinyeartrainer's last release was a decade ago and
> that it is unlikely to be ported away from pygtk and Python 2.
> 
> Therefore, I or someone else will file a bug soon to request that
> tinyeartrainer be removed from Debian Unstable.
> 
> This package can easily be added back to Debian if someone does port
> it to use supported libraries.

Given there were no objections for a month, I've filed a removal bug now.

Cheers,
Moritz

> 
> Thanks,
> Jeremy Bicha
> 

Bug#947893: RM: tinyeartrainer -- RoQA; dead upstream, depends on pygtk2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove tinyeartrainer. It depends on pygtk, which is going away
and is dead upstream. Noone objected to the proposed removal in #945969
for a month.

Cheers,
Moritz

Bug#947891: avahi-daemon: segfaults after upgrade to buster with airprint service

[Ian Chard]

Package: avahi-daemon
Version: 0.7-4+b1
Severity: important

Hi,

After upgrading to buster avahi-daemon segfaults immediately on startup.
If I run with --debug I see:

Found user 'avahi' (UID 113) and group 'avahi' (GID 118).
Successfully dropped root privileges.
avahi-daemon 0.7 starting up.
Loading service file /etc/avahi/services/AirPrint-printer.service.
Segmentation fault

I have one file in /etc/avahi/services (filename above) the contents of
which are:




   AirPrint printer @ %h
   
  _ipp._tcp
  _universal._sub._ipp._tcp
  631
  txtvers=1
  qtotal=1
  Transparent=T
  URF=none
  rp=printers/printer
  note=
  product=(GPL Ghostscript)
  printer-state=3
  printer-type=0x1014
  
pdl=application/octet-stream,application/pdf,application/postscript,application/vnd.cups-raster,image/gif,image/jpeg,image/png,image/tiff,image/urf,text/html,text/plain,application/vnd.adobe-reader-postscript,application/vnd.cups-pdf
   


For info the file was generated by
https://github.com/tjfontaine/airprint-generate.  I've added line breaks
for clarity (the daemon still fails with the line breaks present).

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armel (armv5tel)

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

Versions of packages avahi-daemon depends on:
ii  adduser3.118
ii  bind9-host [host]  1:9.11.5.P4+dfsg-5.1
ii  dbus   1.12.16-1
ii  host   1:9.10.3.dfsg.P4-12.3+deb9u5
ii  libavahi-common3   0.7-4+b1
ii  libavahi-core7 0.7-4+b1
ii  libc6  2.28-10
ii  libcap21:2.25-2
ii  libdaemon0 0.14-7
ii  libdbus-1-31.12.16-1
ii  libexpat1  2.2.6-2+deb10u1
ii  lsb-base   10.2019051400

Versions of packages avahi-daemon recommends:
ii  libnss-mdns  0.14.1-1

Versions of packages avahi-daemon suggests:
pn  avahi-autoipd  

-- no debconf information

Bug#947892: dma: postinst maintainer script fails

[Tom Ellis]

Package: dma
Version: 0.11-1+deb10u1
Severity: normal

I cannot get dma to configure successfully after installation:

% sudo dpkg --configure dma
Setting up dma (0.11-1+deb10u1) ...
dpkg: error processing package dma (--configure):
 installed dma package post-installation script subprocess returned error exit 
status 128
Errors were encountered while processing:
 dma

This is a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847659 but I didn't find
any way of reopening that bug.

I've just come across this bug, with exactly the same symptoms seen by Uli
in 2016.  In my case I am trying to install version 0.11-1+deb10u1 (i.e.
from buster) via a full-upgrade from stretch.  The version I am upgrading
from is 0.11-1+b1.

Any help trying to fix this would be welcome.

Tom

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

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

Versions of packages dma depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libssl1.1  1.1.1d-0+deb10u2
ii  ucf3.0038+nmu1

dma recommends no packages.

dma suggests no packages.

-- debconf information excluded

Bug#946183: Should fusionforge be removed?

[Moritz Mühlenhoff]

On Wed, Dec 04, 2019 at 10:27:04PM +0100, Moritz Muehlenhoff wrote:
> Source: fusionforge
> Severity: serious
> 
> There hasn't been an upload since two years and fusionforge missed the last 
> two
> stable releases and has gathered five RC bugs at this point. Should it be 
> removed?

No objections for a month, filed a removal bug.
 
Cheers,
Moritz
 

Bug#947890: RM: fusionforge -- RoQA; unmainained, many RC bugs, missed last two stable releases

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove fusionforge. There's a number of RC bugs which haven't seen any 
update, it
missed the last two stable releases and there wasn't an upload in the last two 
years.
Noone objected to my proposed removal in #946183 for a month.

Cheers,
Moritz

Bug#946569: Request for CONFIG_EROFS_FS=m on 5.4+

[Salvatore Bonaccorso]

Control: tags -1 + pending

Hi,

On Wed, Dec 11, 2019 at 10:12:23AM +0800, Gao Xiang wrote:
> Source: linux
> Version: 5.4.2-1~exp1
> Severity: normal
> 
> Hi Debian kernel maintainers,
> 
> Could you consider enabling EROFS filesystem support as a module
> from 5.4 for end users now? It has been out of staging.
> 
> It has much better dynamic performance than squashfs for such
> like LIVECD use. I'd suggest the following configuration:
> 
> CONFIG_EROFS_FS=m
> # CONFIG_EROFS_FS_DEBUG is not set
> CONFIG_EROFS_FS_XATTR=y
> CONFIG_EROFS_FS_POSIX_ACL=y
> CONFIG_EROFS_FS_SECURITY=y
> CONFIG_EROFS_FS_ZIP=y
> CONFIG_EROFS_FS_CLUSTER_PAGE_LIMIT=1
> 
> erofs-utils package has been available in testing branch as well,
> https://packages.debian.org/source/bullseye/erofs-utils

Done in
https://salsa.debian.org/kernel-team/linux/commit/33639568475c399acc9cd9d45e9b06a3a2df6e75
with the suggested configuration.

Regards,
Salvatore

Bug#947237: gnome-software: Crashes on click over any software icon

[definetti]

Package: gnome-software-plugin-snap
Version: 3.34.2-1
Followup-For: Bug #947237

I can confirm that removing the snap plugin package gnome-software works as
intended. Installing the dbgsym packages and running gdb this is what I obtain

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x727e8700 (LWP 338376)]
[New Thread 0x71fe7700 (LWP 338377)]
[New Thread 0x71410700 (LWP 338378)]
[New Thread 0x7fffe3fff700 (LWP 338379)]
19:22:43:0603 Gs  enabled plugins: desktop-categories, fwupd, os-release,
packagekit, packagekit-local, packagekit-offline, packagekit-proxy, packagekit-
refine-repos, packagekit-refresh, packagekit-upgrade, packagekit-url-to-app,
shell-extensions, appstream, snap, desktop-menu-path, epiphany, flatpak,
hardcoded-blacklist, hardcoded-featured, hardcoded-popular, modalias,
packagekit-refine, rewrite-resource, odrs, packagekit-history, provenance,
systemd-updates, generic-updates, provenance-license, icons, key-colors, key-
colors-metadata
19:22:43:0603 Gs  disabled plugins: dpkg, dummy, repos
[New Thread 0x7fffe2d02700 (LWP 338380)]
19:22:43:0884 Gs  not handling error failed for action get-updates-historical:
failed to build result for 2da31270d317b076424992de14a0f08ae373c137
[New Thread 0x7fffe2460700 (LWP 338386)]
19:22:44:0638 Gs  not handling error failed for action refresh: E: Failed to
fetch http://ftp.it.debian.org/debian/dists/sid/InRelease
E: Failed to fetch http://deb.debian.org/debian-debug/dists/unstable-
debug/InRelease
E: Failed to fetch
http://httpredir.debian.org/debian/dists/experimental/InRelease
E: Failed to fetch http://linux.dropbox.com/debian/dists/sid/InRelease
E: Failed to fetch http://dl.google.com/linux/chrome/deb/dists/stable/InRelease
E: Failed to fetch http://apt.insynchq.com/debian/dists/buster/InRelease
E: Failed to fetch http://apt.insync.io/debian/dists/buster/InRelease
E: Failed to fetch https://mega.nz/linux/MEGAsync/Debian_10.0/./InRelease
E: Failed to fetch https://repo.skype.com/deb/dists/stable/InRelease
E: Failed to fetch http://repository.spotify.com/dists/stable/InRelease
E: Failed to fetch http://repo.steampowered.com/steam/dists/precise/InRelease
E: Some index files failed to download. They have been ignored, or old ones
used instead.

[New Thread 0x7fffe12e1700 (LWP 338403)]
[New Thread 0x7fffe0ae0700 (LWP 338404)]
[New Thread 0x7fffcbfff700 (LWP 338405)]
[New Thread 0x7fffcb7fe700 (LWP 338406)]
19:22:46:0478 GsPluginSnap Failed to load snap icon: local snap has no icon
[Thread 0x7fffe2460700 (LWP 338386) exited]
[Thread 0x7fffe3fff700 (LWP 338379) exited]
[Thread 0x7fffe0ae0700 (LWP 338404) exited]
19:22:48:0168 GsPluginSnap Failed to load snap icon: local snap has no icon
[Thread 0x7fffcbfff700 (LWP 338405) exited]
19:22:48:0625 GsPluginSnap Failed to load snap icon: local snap has no icon
[New Thread 0x7fffcbfff700 (LWP 338473)]
[Thread 0x7fffcbfff700 (LWP 338473) exited]
[Detaching after fork from child process 338477]
[Detaching after fork from child process 338479]
[Detaching after fork from child process 338481]
[Detaching after fork from child process 338483]
[Detaching after fork from child process 338485]
[Detaching after fork from child process 338487]
[Detaching after fork from child process 338489]
[New Thread 0x7fffcbfff700 (LWP 338491)]
[Thread 0x7fffcbfff700 (LWP 338491) exited]
[New Thread 0x7fffcbfff700 (LWP 338492)]
[Thread 0x7fffcbfff700 (LWP 338492) exited]
[Detaching after fork from child process 338557]
[Detaching after fork from child process 338559]
[New Thread 0x7fffcbfff700 (LWP 338561)]
[Thread 0x7fffcbfff700 (LWP 338561) exited]
19:22:58:0238 GsPluginSnap Failed to load snap icon: local snap has no icon
19:22:58:0244 GsPluginSnap Failed to load snap icon: local snap has no icon
[Thread 0x7fffe2d02700 (LWP 338380) exited]
[New Thread 0x7fffe2d02700 (LWP 338698)]
[New Thread 0x7fffcbfff700 (LWP 338699)]
19:23:00:0604 Gs  can't reliably fixup error from domain as-icon-error-quark
19:23:00:0604 Gs  can't reliably fixup error from domain as-icon-error-quark
19:23:00:0604 Gs  can't reliably fixup error from domain as-icon-error-quark
19:23:00:0608 Gs  can't reliably fixup error from domain as-icon-error-quark
19:23:00:0612 Gs  can't reliably fixup error from domain as-icon-error-quark
19:23:00:0629 Gs  can't reliably fixup error from domain as-icon-error-quark
19:23:00:0631 Gs  can't reliably fixup error from domain as-icon-error-quark
19:23:00:0631 Gs  can't reliably fixup error from domain as-icon-error-quark
19:23:00:0639 Gs  can't reliably fixup error from domain as-icon-error-quark
19:23:00:0641 Gs  can't reliably fixup error from domain as-icon-error-quark
19:23:00:0652 Gs  can't reliably fixup error from domain as-icon-error-quark
19:23:00:0654 Gs  can't reliably fixup error from domain as-icon-error-quark
19:23:00:0698 Gs  can't reliably fixup error from domain as-icon-error-quark
19:23:00:0708 Gs  can't reliably fixup e

Bug#922240: ftp.debian.org: consider switching to merged pdiffs

[Niels Thykier]

Joerg Jaspert:
> On 15634 March 1977, Niels Thykier wrote:
> [...]
>> To avoid a combinational blow up, Julian and I propose that we limit the
>> number patch generations to a low constant.  This would limit the number
>> of patches to a factor 3x of the current number. We can further reduce
>> the number by reducing the number of pdiffs.
> 
> We currently seem to do up to 56 of them. And (for today) seem to cover
> a timeframe from last-run-on-17th-December to first run of todays, so
> about two weeks of pdiffs.
> 

Ack, 14 days assuming 4 dinstalls per day.

>> My understanding is that 3 generations will be sufficient to avoid
>> issues by giving "apt(-get) update" at least 6 hour window to complete
>> before there is an issue.
>>   As that pdiffs are only used during an "apt(-get) update", there is no
>> reason to be concerned about stale metadata in the Index after apt(-get)
>> has fetched all the files.
> 
> Does 3 generations mean we will have cover for less than a day, or do i
> misunderstand something here?
> 

The generation represents a different "time axis" than the one you are
thinking of.  On one axis, we have "how many dinstalls can you be behind
and still get patches?".  This is the "only axis" we have right now and
is currently set to 56 dinstalls (~14 days).  For reference, the code
refers to the this limit/time axis as "--maxdiffs"/"MaxDiffs".

When we start to do patch merging, we introduce the time axis "which
dinstall state will this patch forward you to?".  I referred to this as
"Generations" in my description in a lack of a better word (I am open to
suggestions for a better name).

As said, the primary purpose of using multiple generations is to avoid
removing pdiffs referenced by an Index file while an "apt-get update" is
fetching files (Time of fetch for Index vs. time of fetch for the actual
pdiff file).  As I understand it, we will ever need more than 3
generations, but that still implies that we will have 3*56 = 168 pdiff
files.

>> @FTP masters: Do you agree with the "fully-merged" approach with N
>> generations (with N=3 by default) as a solution to this request?
> 
> I'm happy with it, as long as we cover a long enough timeframe of diff
> generation with it, ie. multiple days.
> 
> And preferably if it works as a drop-in replacement and we can just
> start using it whenever it gets merged.
> 

Ok.  :)

I will try to have a look at it soonish.

Thanks,
~Niels

Bug#924881: Bugs #946938 and #924881 are duplicates

[Karl O. Pinc]

Hello,

Looks like Bug#946938 and Bug#924881 are the same bug.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#257096: Bug still current

[Steve Egbert]

> but do we really actually need the .so's in /var?

Linux Filesystem Standard v3.0 does not allow executable code under /var
directory.

Postfix is in non-compliance.

And this will become more problematic as containerization and
virtualization comes into play.

Citation: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s02.html

Bug#947886: clang (mipsel): LLVM error: out of memory

[Bernd Zeimetz]

On 1/1/20 7:49 PM, Sylvestre Ledru wrote:
> 
> Le 01/01/2020 à 19:05, Bernd Zeimetz a écrit :
>> If you are interested to debug this further, I can get the preprocessed
>> sources for a proper bug report. This will take some times as mipsel is
>> not really fast, so first I'd like to know if it makes sense to spend
>> the time on this...
> 
> No need. llvm is just very big and C++ uses a lot of memory at link time :/


Yeah, although clang was my rescue on arm* as g++ fails much earlier
there and clang works well... So my hope was that it would be the same
for mipsel.

I'll just remove ceph from mipsel then.

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

Bug#946480: lxc: non-root user cannot start a container under cgroupv2 / unified hierarchy

[Ryutaroh Matsumoto]

Control: unblock 943981 by -1
Control: tags -1 - upstream

Now I think this issue #946480 should be handled by updates to

https://wiki.debian.org/LXC
and/or
README.Debian

telling non-root users that they have to run lxc-start as
systemd-run --user --scope -p "Delegate=yes" lxc-start -F -n ...

There seems nothing required to change other than documents,
though addition of more sensible error handling and error messages
are helpful at the upstream.

Ryutaroh

Bug#947886: clang (mipsel): LLVM error: out of memory

[Sylvestre Ledru]

Le 01/01/2020 à 19:05, Bernd Zeimetz a écrit :

If you are interested to debug this further, I can get the preprocessed
sources for a proper bug report. This will take some times as mipsel is
not really fast, so first I'd like to know if it makes sense to spend
the time on this...


No need. llvm is just very big and C++ uses a lot of memory at link time :/

S

Bug#930846: New development of how to build the installation-guide for the website [ Re: Bug#930846: partman-auto-lvm: debconf show guided_size during auto install ]

[Holger Wansing]

Hi,

Laura Arjona Reina  wrote:
> Hi
> 
> The cron job will do the 'git pull' on wolkenstein the next time it runs.

yes, that worked, thanks.
So, the build was performed via the new script, and thanks to that we now have
the manual for buster on the webpage for buster :-)
(the last two days there was the manual for bullseye there.)

Thus, that part works fine so far.

However, the part with the example-preseed.txt file remains open:
in the past it was not updated, now I have added a "remove the old example file"
line into the script, and as a result we have no file at all now :-(

Because the rest is working fine, I suspect the problem is not in the build of
the manual ifself, but in the sync to the www mirrors (DSA provided, I think).
But this is only an assumption, I cannot say for sure, because I have no access
rights for wolkenstein.

@debian-www:
Maybe you want to grant me access to wolkenstein machine for similar jobs?


Holger



> El 1 de enero de 2020 14:45:21 CET, Holger Wansing  
> escribió:
> >Hi,
> >
> >Samuel Thibault  wrote:
> >> Samuel Thibault, le dim. 29 déc. 2019 22:15:59 +0100, a ecrit:
> >> > Holger Wansing, le dim. 29 déc. 2019 21:59:02 +0100, a ecrit:
> >> > > do you it would be possible for you to do another upload for the 
> >> > > installation-guide some day?
> >> > 
> >> > Ah, sure, I'm on it, then.
> >> 
> >> Done!
> >
> >Thanks for the quick upload!
> >
> >However, I noticed that this does not fix the problem in #930846.
> >And while looking at the details, I came (again) to the longstanding problem
> >with the built of installation-guide for the website.
> >
> >Therefore, I have changed the 1installation-guide script in cron's
> >lessoften part (see
> >https://salsa.debian.org/webmaster-team/cron/commit/eb181b214009878967197a673a3488821d1c2258
> > )
> >
> >It changes the way of building the installation-guide:
> >instead of hardcoding release codenames and always pulling the latest package
> >version from the archive, it now parses the release codenames from the webwml
> >repo, and package version is determined via rmadison.
> >
> >
> >@Laura: could you see, if there is something needed on wolkenstein, to make 
> >this
> >going live? (I assume a simply "git pull"?)



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#947751: Acknowledgement (gcc/g++: fails to build ceph on armel/armhf/mipsel)

[Bernd Zeimetz]

Hi,

just fyi: this also affects m68k, sh4.


Cheers,

Bernd

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

Bug#947887: RM: ceph [mipsel] -- ICE; clang and gcc run into OOM while compiling

[Bernd Zeimetz]

Package: ftp.debian.org
Severity: normal

Hi ftp-team,

neither gcc nor clang are able to compile ceph on mipsel (#947886
and #947751), both need more than the available virtual memory.

Also: compiling ceph on mipsel takes >>36h, I don't think that this
makes much sense to support at all.

So please remove ceph from unstable/mipsel.


Thanks,

Bernd

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

Bug#947888: RFS: transaction/3.0.0-1 [QA] -- Transaction management for Python

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: transaction
   Version : 3.0.0-1
   Upstream Author : Zope Foundation and Contributors 
 * URL : https://pypi.python.org/pypi/transaction
 * License : Zope-2.1
 * Vcs : None
   Section : zope

It builds those binary packages:

  python3-transaction - Transaction management for Python

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/transaction/transaction_3.0.0-1.dsc


Changes since the last upload:

   * QA upload
   * New upstream release
   * d/watch secure URI
   * d/control
 - Secure URI on homepage
 - Bump debhelper to 12
 - Update Standards-Version to 4.4.1
 - Add Rules-Requires-Root: no
   * Change to debhelper-compat
   * d/copyright
 - Update to correct format URI
 - Use secure URI's
   * d/rules add PYBUILD_NAME

Regards,
Håvard

Bug#947058: pygalmesh: autopkgtest failure on arm64 (and ppc64el, s390x)

[Nico Schlömer]

Just can just relax the relative tolerance to 2.0e-3 with a patch,
I'll include in the next release.

Cheers,
Nico

On Mon, Dec 30, 2019 at 3:27 PM Graham Inggs  wrote:
>
> Control: reopen -1
>
> Hi Drew
>
> The test gets a little further [1], and now fails at:
>
> ___ test_inr 
> ___
>
> def test_inr():
> this_dir = os.path.dirname(os.path.abspath(__file__))
> mesh = pygalmesh.generate_from_inr(
> os.path.join(this_dir, "meshes", "skull_2.9.inr"),
> cell_size=5.0, verbose=False
> )
>
> tol = 2.0e-3
> ref = [2.031053e02, 3.739508e01, 2.425594e02, 2.558910e01,
> 2.300883e02, 1.775010e00]
> assert abs(max(mesh.points[:, 0]) - ref[0]) < tol * ref[0]
> assert abs(min(mesh.points[:, 0]) - ref[1]) < tol * ref[1]
> assert abs(max(mesh.points[:, 1]) - ref[2]) < tol * ref[2]
> assert abs(min(mesh.points[:, 1]) - ref[3]) < tol * ref[3]
> assert abs(max(mesh.points[:, 2]) - ref[4]) < tol * ref[4]
> assert abs(min(mesh.points[:, 2]) - ref[5]) < tol * ref[5]
>
> vol = sum(helpers.compute_volumes(mesh.points, mesh.cells["tetra"]))
> ref = 2.725335e06
> >   assert abs(vol - ref) < ref * 1.0e-3
> E   assert 4425.526206357405 < (2725335.0 * 0.001)
> E+  where 4425.526206357405 = abs((2729760.5262063574 - 2725335.0))
>
> test/test_inr.py:24: AssertionError
>
> Regards
> Graham
>
>
> [1] 
> https://ci.debian.net/data/autopkgtest/testing/arm64/p/pygalmesh/3810331/log.gz
>

Bug#944389: lxc: Fails to work with cgroupv2 / unified hierarchy

[Ryutaroh Matsumoto]

Dear Michael and the Debian maintainers of LXC,

I suggest to close this issue #944389. The reason is that

Addition of

lxc.cgroup.devices.allow =
lxc.cgroup.devices.deny =
lxc.init.cmd = /lib/systemd/systemd systemd.unified_cgroup_hierarchy=1

to a container config allows normal start-up of an LXC container when
/sbin/init is a recent version of systemd, and only

lxc.cgroup.devices.deny =
lxc.cgroup.devices.allow =

are sufficient when /sbin/init is not systemd, for the latest Debian LXC package
3.1.0+really3.0.4-2 made on August 2019 running on a Debian Bullseye booted
with systemd.unified_cgroup_hierarchy=1

This #944389 seems a documentation issue that should be fixed at
https://wiki.debian.org/LXC
or
README.Debian
and does not seems an issue in the Debian package or the upstream
(except possible update to README.Debian).

Best regards, Ryutaroh Matsumoto

Bug#947886: clang (mipsel): LLVM error: out of memory

[Bernd Zeimetz]

Package: clang
Version: 1:8.0-48.3
Severity: normal

Hi,

clang runs into an out of memory error while compiling ceph on mipsel:

make[3]: Leaving directory '/<>/obj-mipsel-linux-gnu'
make -f src/tools/ceph-dencoder/CMakeFiles/ceph-dencoder.dir/build.make 
src/tools/ceph-dencoder/CMakeFiles/ceph-dencoder.dir/build
make[3]: Entering directory '/<>/obj-mipsel-linux-gnu'
[ 93%] Building CXX object 
src/tools/ceph-dencoder/CMakeFiles/ceph-dencoder.dir/ceph_dencoder.cc.o
cd /<>/obj-mipsel-linux-gnu/src/tools/ceph-dencoder && 
/usr/bin/clang++  -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D__linux__ 
-I/<>/obj-mipsel-linux-gnu/src/include -I/<>/src 
-I/usr/include/nss -I/usr/include/nspr -I/<>/src/dmclock/src 
-I/<>/src/dmclock/support/src -isystem 
/<>/obj-mipsel-linux-gnu/include -isystem 
/<>/src/xxHash -isystem /<>/src/rapidjson/include 
-isystem /<>/src/rocksdb/include -isystem 
/<>/src/rgw/../rapidjson/include  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wtype-limits 
-Wignored-qualifiers -Winit-self -Wpointer-arith -Werror=format-security 
-fno-strict-aliasing -fsigned-char -Wno-unknown-pragmas -Wno-unused-function 
-Wno-unused-local-typedef -Wno-varargs -Wno-gnu-designator -Wno-missing-braces 
-Wno-parentheses -Wno-deprecated-register -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -ftemplate-depth-1024 
-Wnon-virtual-dtor -Wno-unknown-pragmas -Wno-ignored-qualifiers 
-Wno-inconsistent-missing-override -Wno-mismatched-tags 
-Wno-unused-private-field -Wno-address-of-packed-member 
-fdiagnostics-color=auto -fPIE   -DHAVE_CONFIG_H -D__CEPH__ -D_REENTRANT 
-D_THREAD_SAFE -D__STDC_FORMAT_MACROS -std=c++17 -o 
CMakeFiles/ceph-dencoder.dir/ceph_dencoder.cc.o -c 
/<>/src/tools/ceph-dencoder/ceph_dencoder.cc
In file included from 
/<>/src/tools/ceph-dencoder/ceph_dencoder.cc:36:
In file included from /<>/src/tools/ceph-dencoder/types.h:270:
In file included from /<>/src/mds/events/EExport.h:21:
In file included from /<>/src/mds/events/../MDSRank.h:33:
/<>/src/mds/MDCache.h:1267:40: warning: null passed to a callee 
that requires a non-null argument [-Wnonnull]
  int dump_cache() { return dump_cache(NULL, NULL); }
   ^~~~
/usr/include/clang/8.0.1/include/stddef.h:100:18: note: expanded from macro 
'NULL'
#define NULL __null
 ^~
LLVM ERROR: out of memory
Stack dump:
0.  Program arguments: /usr/lib/llvm-8/bin/clang -cc1 -triple 
mipsel-unknown-linux-gnu -emit-obj -disable-free -disable-llvm-verifier 
-discard-value-names -main-file-name ceph_dencoder.cc -mrelocation-model pic 
-pic-level 1 -pic-is-pie -mthread-model posix -relaxed-aliasing -fmath-errno 
-masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu mips32r2 
-target-feature -noabicalls -target-feature +fpxx -target-feature +nooddspreg 
-target-abi o32 -mfloat-abi hard -dwarf-column-info -debug-info-kind=limited 
-dwarf-version=4 -debugger-tuning=gdb -momit-leaf-frame-pointer 
-coverage-notes-file 
/<>/obj-mipsel-linux-gnu/src/tools/ceph-dencoder/CMakeFiles/ceph-dencoder.dir/ceph_dencoder.cc.gcno
 -resource-dir /usr/lib/llvm-8/lib/clang/8.0.1 -isystem 
/<>/obj-mipsel-linux-gnu/include -isystem 
/<>/src/xxHash -isystem /<>/src/rapidjson/include 
-isystem /<>/src/rocksdb/include -isystem 
/<>/src/rgw/../rapidjson/include -D _FILE_OFFSET_BITS=64 -D 
_GNU_SOURCE -D __linux__ -I /<>/obj-mipsel-linux-gnu/src/include 
-I /<>/src -I /usr/include/nss -I /usr/include/nspr -I 
/<>/src/dmclock/src -I /<>/src/dmclock/support/src -D 
_FORTIFY_SOURCE=2 -D _FORTIFY_SOURCE=2 -D HAVE_CONFIG_H -D __CEPH__ -D 
_REENTRANT -D _THREAD_SAFE -D __STDC_FORMAT_MACROS -internal-isystem 
/usr/bin/../lib/gcc/mipsel-linux-gnu/9/../../../../include/c++/9 
-internal-isystem 
/usr/bin/../lib/gcc/mipsel-linux-gnu/9/../../../../include/mipsel-linux-gnu/c++/9
 -internal-isystem 
/usr/bin/../lib/gcc/mipsel-linux-gnu/9/../../../../include/mipsel-linux-gnu/c++/9
 -internal-isystem 
/usr/bin/../lib/gcc/mipsel-linux-gnu/9/../../../../include/c++/9/backward 
-internal-isystem /usr/include/clang/8.0.1/include/ -internal-isystem 
/usr/local/include -internal-isystem /usr/lib/llvm-8/lib/clang/8.0.1/include 
-internal-externc-isystem /usr/include/mipsel-linux-gnu 
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 
-Wformat -Werror=format-security -Wdate-time -Wall -Wtype-limits 
-Wignored-qualifiers -Winit-self -Wpointer-arith -Werror=format-security 
-Wno-unknown-pragmas -Wno-unused-function -Wno-unused-local-typedef 
-Wno-varargs -Wno-gnu-designator -Wno-missing-braces -Wno-parentheses 
-Wno-deprecated-register -Wformat -Werror=format-security -Wdate-time 
-Wnon-virtual-dtor -Wno-unknown-pragmas -Wno-ignored-qualifiers 
-Wno-inconsistent-missing-override -Wno-mismatched-tags 
-Wno-unused-private-field -Wno-address-of-packed-member -std=c++17 
-fdepr

Bug#947885: transition: gecode

[Kari Pahula]

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

I'm about to update gecode from 6.1.0 to 6.2.0 in unstable.  SONAME
changes from 48 to 49.

The only reverse dependency is minizinc which I also maintain.
Transitively minizinc-ide as well.  All of these have had new versions
uploaded to experimental.

Strictly speaking, the minizinc version in unstable doesn't depend on
the library itself but only on flatzinc which is also built from the
gecode source package.  But the version in experimental would add a
dependency on the library.

Ben file:

title = "gecode";
is_affected = .depends ~ "libgecode48" | .depends ~ "libgecodegist48" | 
.depends ~ "libgecodeflatzinc48" | .depends ~ "libgecode49" | .depends ~ 
"libgecodegist49" | .depends ~ "libgecodeflatzinc49";
is_good = .depends ~ "libgecode49" | .depends ~ "libgecodegist49" | .depends ~ 
"libgecodeflatzinc49";
is_bad = .depends ~ "libgecode48" | .depends ~ "libgecodegist48" | .depends ~ 
"libgecodeflatzinc48";


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

Kernel: Linux 4.9.0-9-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#947883: Enable reader name filter in pcscd

[Ludovic Rousseau]

Le 01/01/2020 à 17:51, Pawel Boguslawski a écrit :

Package: pcscd
Version: 1.8.25-3

Please add --enable-filter option to configure to allow one to use
reader name filter build in pcscd:

https://ludovicrousseau.blogspot.com/2015/12/remove-andor-customize-pcsc-reader-names.html

Useful for ignoring USB reader on host and passing it to guest.

See also: https://bugs.archlinux.org/task/51912


See also this Ubuntu bug https://bugs.launchpad.net/bugs/1857118

Since this request is now more frequent I plan, as the upstream maintainer of 
pcsc-lite, to change the configuration to have the filtering enabled by default.
So it will not be needed for each GNU/Linux distribution to change the 
packaging of pcsc-lite.

I should release a new upstream version and a new Debian package within a week.

Regards,

--
 Dr. Ludovic Rousseau

Bug#921904: Bug#946951: Bug#921904: win-iconv: FTBFS (wine: chdir to /tmp/wine-I6miLw/server-29-3583b06 : No such file or directory)

[Vincent Lefevre]

On 2019-12-29 01:16:01 -0500, Joe Nahmias wrote:
> On 12/27/2019 6:23 PM, Vincent Lefevre wrote:
> > On 2019-12-27 19:49:46 +, Joseph Nahmias wrote:
> > > On Fri, Dec 27, 2019 at 07:27:42PM +, Joseph Nahmias wrote:
> > > > The attached patch works around the issue until that is fixed.
> > > 
> > > Of course, I forgot this patch... Take 2.
> > 
> > Wouldn't the use of wildcards be a security issue?
> > 
> > +   ln -s /tmp/.wine-`id -u`/server* /tmp/wine-*/
> > 
> > i.e. could you end up creating wrong symbolic links?
> 
> Attached is an updated patch that does the extra work to avoid the
> wildcards.
> 
> > In any case, this seems rather ugly to me.
> 
> Not sure precisely what you are referring to as ugly here;

I meant the use of wildcards. Actually they were wrong, because they
would work only when they matched only one file or directory, while
in normal use (no attacks), some other old files or directories could
have been left in /tmp for various reasons (testing, crash, etc.).

In general, wildcards should be used only when the goal is to match a
set of files, not to replace something "unknown" (possibly unless one
has the full control of the directory, which is not the case here).

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

Bug#947167: Implementation

[Eduard Bloch]

Control: tags 947167 +patch

Patch attached, please apply and forward upstream.
Description: React to mouse button release event like to a press
 The callback for press also called on for the button release which allows for
 browsing the menu while keeping the button pressed and releasing it at the item
 which shall be activated.
 .
 Without this change, the menu is configuration on the release event (the radio
 button is switched) but without the callback, the effective configuration does
 not match the UI state anymore.
Author: Eduard Bloch 
Bug-Debian: https://bugs.debian.org/947167

--- pasystray-0.7.1.orig/src/menu_info.c
+++ pasystray-0.7.1/src/menu_info.c
@@ -369,6 +369,8 @@ void menu_info_item_add(menu_info_t* mi,
 break;
 }
 
+g_signal_connect(item->widget, "button-release-event",
+G_CALLBACK(menu_info_item_clicked), item);
 g_signal_connect(item->widget, "button-press-event",
 G_CALLBACK(menu_info_item_clicked), item);
 gtk_widget_add_events(item->widget, GDK_SCROLL_MASK);

Bug#947884: wine-development: patches for arm64 build failure

[Gianfranco Costamagna]

Source: wine-development
Version: 4.21-2
Severity: serious
control: affects -1 src:wine

Hello, I took some time to have a look on wine FTBFS, and I think I crafted 
some patches that are pending upstream review
https://bugs.winehq.org/show_bug.cgi?id=48398

+wine-development (4.21-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload (Closes: #-1)
+  * Fix new-gcc errors on arm64. 
+  * Do not check anymore for sysctl header file 
+
+ -- Gianfranco Costamagna   Tue, 31 Dec 2019 
17:27:10 +0100

the sysctl hack is needed for the new glibc

The very same patches are applying cleanly to wine too.

thanks

Gianfranco
diff -Nru wine-5.0~rc1/debian/patches/anysize-array.patch 
wine-5.0~rc1/debian/patches/anysize-array.patch
--- wine-5.0~rc1/debian/patches/anysize-array.patch 1970-01-01 
01:00:00.0 +0100
+++ wine-5.0~rc1/debian/patches/anysize-array.patch 2019-12-31 
18:29:19.0 +0100
@@ -0,0 +1,32 @@
+Description:
+clang -c -o file.o file.c -I. -I../../include -I../../include/msvcrt 
-D__WINESRC__ -D_REENTRANT -fPIC -fno-builtin -fshort-wchar -Wall -pipe 
-fcf-protection=none -fno-stack-protector -fno-strict-aliasing 
-Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers 
-Wno-pragma-pack -Wstrict-prototypes -Wtype-limits -Wvla -Wwrite-strings 
-Wpointer-arith -gdwarf-2 -gstrict-dwarf -Werror -Wdate-time -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wno-shift-overflow -Wno-unused-function 
-Wno-deprecated-declarations -Wno-enum-conversion -Wno-absolute-value
+file.c:1057:49: error: array index 1 is past the end of the array (which 
contains 1 element) [-Werror,-Warray-bounds]
+dir_info->FileName[0] == '.' && dir_info->FileName[1] == '.') 
continue;
+^  ~
+../../include/winternl.h:551:5: note: array 'FileName' declared here
+WCHAR   FileName[ANYSIZE_ARRAY];
+Author: Gianfranco Costamagna 
+Last-Update: 2019-12-31
+
+--- wine-development-4.21.orig/include/winnt.h
 wine-development-4.21/include/winnt.h
+@@ -4115,7 +4115,7 @@ typedef struct tagMESSAGE_RESOURCE_DATA
+  * First a constant for the following typedefs.
+  */
+ 
+-#define ANYSIZE_ARRAY   1
++#define ANYSIZE_ARRAY   2
+ 
+ /* FIXME:  Orphan.  What does it point to? */
+ typedef PVOID PACCESS_TOKEN;
+--- wine-development-4.21.orig/tools/winapi/winapi_test
 wine-development-4.21/tools/winapi/winapi_test
+@@ -140,7 +140,7 @@ my $progress_max = scalar(@files);
+ my %type_name2type;
+ 
+ my %defines = (
+-"ANYSIZE_ARRAY" => 1,
++"ANYSIZE_ARRAY" => 2,
+ "CCHDEVICENAME" => 32,
+ "CCHILDREN_TITLEBAR+1" => 6,
+ "ELF_VENDOR_SIZE" => 4,
diff -Nru wine-5.0~rc1/debian/patches/fix-bad-comparison.patch 
wine-5.0~rc1/debian/patches/fix-bad-comparison.patch
--- wine-5.0~rc1/debian/patches/fix-bad-comparison.patch1970-01-01 
01:00:00.0 +0100
+++ wine-5.0~rc1/debian/patches/fix-bad-comparison.patch2019-12-31 
18:29:19.0 +0100
@@ -0,0 +1,36 @@
+Description:
+../../tools/winegcc/winegcc -o d3dcompiler_47.dll.so --wine-objdir ../.. -fPIC 
-fasynchronous-unwind-tables -shared d3dcompiler_47.spec -mno-cygwin 
asmparser.o blob.o bytecodewriter.o compiler.o main.o preproc.o reflection.o 
utils.o asmshader.tab.o hlsl.tab.o ppy.tab.o asmshader.yy.o hlsl.yy.o ppl.yy.o 
version.res ../../dlls/dxguid/libdxguid.a ../../dlls/uuid/libuuid.a 
-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now 
-Wl,-rpath,/usr/lib/aarch64-linux-gnu/wine
+../d3dx9_36/effect.c:1472:12: error: result of comparison of unsigned enum 
expression < 0 is always false 
[-Werror,-Wtautological-unsigned-enum-zero-compare]
+if (op < 0 || op > SCT_PSINT)
+~~ ^ ~
+1 error generated.
+
+Author: Gianfranco Costamagna 
+
+Forwarded: pending
+Last-Update: 2019-12-31
+
+--- wine-5.0~rc1.orig/dlls/d3dx9_36/effect.c
 wine-5.0~rc1/dlls/d3dx9_36/effect.c
+@@ -1469,7 +1469,7 @@ static HRESULT d3dx_set_shader_const_sta
+ D3DXVECTOR4 value;
+ HRESULT ret;
+ 
+-if (op < 0 || op > SCT_PSINT)
++if (op > SCT_PSINT)
+ {
+ FIXME("Unknown op %u.\n", op);
+ return D3DERR_INVALIDCALL;
+--- wine-5.0~rc1.orig/dlls/gdiplus/graphics.c
 wine-5.0~rc1/dlls/gdiplus/graphics.c
+@@ -6836,8 +6836,8 @@ GpStatus WINGDIPAPI GdipTransformPoints(
+ GpCoordinateSpace src_space, GpPointF 
*points, INT count)
+ {
+ if(!graphics || !points || count <= 0 ||
+-   dst_space < 0 || dst_space > CoordinateSpaceDevice ||
+-   src_space < 0 || src_space > CoordinateSpaceDevice)
++   dst_space > CoordinateSpaceDevice ||
++   src_space > CoordinateSpaceDevice)
+ return InvalidParameter;
+ 
+ if(graphics->busy)
diff -Nru wine-5.0~rc1/debian/patches/for-loop.patch 
wine-5.0~rc1/debian/patches/for-loop.patch
--- wine-5.0~rc1/debian/patches/for-loop.patch  1970-01-01 01:00:00.0 
+0100
+++ wine-5.0~rc1/debia

Bug#922240: ftp.debian.org: consider switching to merged pdiffs

[Joerg Jaspert]

On 15634 March 1977, Niels Thykier wrote:


I am considering to look at this feature - I am looking for a review
before I invest a lot of time on an implementation in case the design is
going to be rejected.


Yay.


# Proposal
I have spoken with Julian about the APT side and we would end up doing
completely merged pdiffs for this to work (i.e. every patch must move
you from the current state to the newest state).  This means that every
dinstall will lead to a new generation of all existing patches.


Ok.


To avoid a combinational blow up, Julian and I propose that we limit the
number patch generations to a low constant.  This would limit the number
of patches to a factor 3x of the current number. We can further reduce
the number by reducing the number of pdiffs.


We currently seem to do up to 56 of them. And (for today) seem to cover
a timeframe from last-run-on-17th-December to first run of todays, so
about two weeks of pdiffs.


My understanding is that 3 generations will be sufficient to avoid
issues by giving "apt(-get) update" at least 6 hour window to complete
before there is an issue.
  As that pdiffs are only used during an "apt(-get) update", there is no
reason to be concerned about stale metadata in the Index after apt(-get)
has fetched all the files.


Does 3 generations mean we will have cover for less than a day, or do i
misunderstand something here?


@FTP masters: Do you agree with the "fully-merged" approach with N
generations (with N=3 by default) as a solution to this request?


I'm happy with it, as long as we cover a long enough timeframe of diff
generation with it, ie. multiple days.

And preferably if it works as a drop-in replacement and we can just
start using it whenever it gets merged.

--
bye, Joerg

Bug#947883: Enable reader name filter in pcscd

[Pawel Boguslawski]

Package: pcscd
Version: 1.8.25-3

Please add --enable-filter option to configure to allow one to use
reader name filter build in pcscd:

https://ludovicrousseau.blogspot.com/2015/12/remove-andor-customize-pcsc-reader-names.html

Useful for ignoring USB reader on host and passing it to guest.

See also: https://bugs.archlinux.org/task/51912

Regards,
Pawel

IB Development Team
https://dev.ib.pl/

Bug#947837: [Piuparts-devel] Bug#947837: Bug#947837: piuparts.debian.org: please upgrade python3-debianbts on pejacevic

[Holger Levsen]

On Wed, Jan 01, 2020 at 04:48:41PM +0100, Nis Martensen wrote:
> Aren't backports taken from testing? 

yes.

> python3-debianbts currently cannot
> migrate to testing because it would make the testing version of piuparts
> uninstallable (unsatisfiable dependencies). 

right.

(though testing migration rules can be relaxed and backports rules as
well.)

> loading a new version of
> piuparts may be required to let it migrate.

touche. I'll get around to do that in the next days.

so #947837 will stay open a bit longer.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#947863: lxc: apparmor denied mount with unprivileged lxc

[Johannes Schauer]

Hi,

Quoting Pierre-Elliott Bécue (2020-01-01 16:25:24)
> I'm sorry but lxc unprivileged containers can't run with any apparmor
> profile. You have to set this parameter to unconfined for your unprivileged
> containers. Setting a default profile for unconfined containers is a hard
> thing as only etc/default/lxc.conf is an option, but it'd also apply to
> privileged containers.

but I don't understand why this is a wontfix?

If lxc unprivileged containers cannot run with any apparmor profile, then why
do files like /usr/share/lxc/config/userns.conf not include a line like:

lxc.aa_profile=unconfined

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#879669: agetty: use full hardening flags

[Christian Göttsche]

It seems that even though only `export DEB_BUILD_MAINT_OPTIONS =
hardening=+bindnow` is used in d/rules, the build runs with all
hardening flags [1].

Also can not spot any missing parts via checksec on the binary/process.
$ checksec --file=/sbin/agetty
RELRO   STACK CANARY  NXPIE RPATH
RUNPATH  Symbols FORTIFY Fortified   Fortifiable
FILE
Full RELRO  Canary found  NX enabledPIE enabled No
RPATH   No RUNPATH   No Symbols  Yes 7   14
/sbin/agetty

[1]: see for example
https://buildd.debian.org/status/fetch.php?pkg=util-linux&arch=amd64&ver=2.34-0.1&stamp=1564330426&raw=0
  the configure script reports using
  cflags:-g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong
-Wformat -Werror=format-security
  suid cflags:
  ldflags:   -Wl,-z,relro -Wl,-z,now

Bug#928375: Announce - swig-4.0.0

[Alan Woodland]

On Mon, 2 Sep 2019 23:02:32 +0200 Torsten Landschoff <
tors...@landschoff.net> wrote:
> On 5/3/19 10:37 AM, Mathieu Malaterre wrote:
> > Would be super nice to have swig 4 in Debian.
> 
> absolutely. And I did not notice for months. I'll have a go - maybe
this
> weekend, but no guarantees!

How did it go? Is there anything you'd like some extra effort from
another person on? I'm pretty invested in SWIG these days, so it'd be
great to see this release in Debian.

Alan

Bug#946651: dispmua 1.8.4.6-1~deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: dispmua
Version: 1.8.4.6-1~deb10u1

Explanation: new upstream release compatible with Thunderbird 68

Bug#947165: transition: llvm-defaults to 9

[Adrian Bunk]

On Fri, Dec 27, 2019 at 10:43:11AM +0100, Paul Gevers wrote:
>...
> > Besides rustc, it should not have an impact on rust.
> 
> But rustc is having issues migrating, so this is something I am worried
> about.

rustc hardcodes the llvm version (and already uses 9),
so rustc is not part of this transition.

> Also, do you understand why rust-bindgen and rust-clang-sys are
> mentioned in the tracker? I looked *briefly* but didn't spot the
> connection yet.
>...

They build-depend on llvm/clang, not sure whether they are actually part 
of the transition.

According to dak they are leaf packages in bullseye,
so potential rust related issues with this transition
could be handled with removal hints.

> Paul

cu
Adrian