Bug#925782: mp3check: diff for NMU version 0.8.7-3.1

[David da Silva Polverari]

Control: tags 925782 + pending

Dear maintainer,

I've prepared an NMU for mp3check (versioned as 0.8.7-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer or cancel the NMU.

Regards,

David Polverari.
diff -Nru mp3check-0.8.7/debian/changelog mp3check-0.8.7/debian/changelog
--- mp3check-0.8.7/debian/changelog	2018-12-22 18:33:01.0 -0500
+++ mp3check-0.8.7/debian/changelog	2020-06-11 00:33:53.0 -0500
@@ -1,3 +1,12 @@
+mp3check (0.8.7-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/60_bts925782_ftbfs_with_gcc_9.patch: added to fix FTBFS
+with GCC-9. Thanks to Joachim Reichel . (Closes:
+#925782)
+
+ -- David da Silva Polverari   Thu, 11 Jun 2020 00:33:53 -0500
+
 mp3check (0.8.7-3) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff -Nru mp3check-0.8.7/debian/patches/60_bts925782_ftbfs_with_gcc_9.patch mp3check-0.8.7/debian/patches/60_bts925782_ftbfs_with_gcc_9.patch
--- mp3check-0.8.7/debian/patches/60_bts925782_ftbfs_with_gcc_9.patch	1969-12-31 19:00:00.0 -0500
+++ mp3check-0.8.7/debian/patches/60_bts925782_ftbfs_with_gcc_9.patch	2020-06-11 00:33:53.0 -0500
@@ -0,0 +1,50 @@
+Description: fix FTBFS with GCC-9
+Author: Joachim Reichel 
+Bug-Debian: https://bugs.debian.org/925782
+Last-Update: 2019-09-01
+
+--- a/texception.h
 b/texception.h
+@@ -38,10 +38,10 @@
+ 
+ #define TExceptionN(n) public: virtual const char *name()  const { return #n; }
+ #define TExceptionM(m) public: virtual const char *message() const { return m; }
+-#define TExceptionM1(m,a) public: virtual const char *message() const { char *buf; asprintf(, m, a); return buf; }
+-#define TExceptionM2(m,a,b) public: virtual const char *message() const { char *buf; asprintf(, m, a,b); return buf; }
+-#define TExceptionM3(m,a,b,c) public: virtual const char *message() const { char *buf; asprintf(, m, a,b,c); return buf; }
+-#define TExceptionM4(m,a,b,c,d) public: virtual const char *message() const { char *buf; asprintf(, m, a,b,c,d); return buf; }
++#define TExceptionM1(m,a) public: virtual const char *message() const { char *buf; int result = asprintf(, m, a); return result != -1 ? buf : "asprintf failure"; }
++#define TExceptionM2(m,a,b) public: virtual const char *message() const { char *buf; int result = asprintf(, m, a,b); return result != -1 ? buf : "asprintf failure"; }
++#define TExceptionM3(m,a,b,c) public: virtual const char *message() const { char *buf; int result = asprintf(, m, a,b,c); return result != -1 ? buf : "asprintf failure"; }
++#define TExceptionM4(m,a,b,c,d) public: virtual const char *message() const { char *buf; int result = asprintf(, m, a,b,c,d); return result != -1 ? buf : "asprintf failure"; }
+ 
+ // base class of all exceptions 
+ class TException {
+--- a/tstring.cc
 b/tstring.cc
+@@ -111,7 +111,7 @@
+ tstring::Rep *tstring::Rep::create(size_t tmem) {
+size_t m = sizeof(Rep) << 1;
+while((m - 1 - sizeof(Rep)) < tmem) m <<= 1;
+-   Rep *p = new (m - 1 - sizeof(Rep)) Rep;
++   Rep *p = new (/*tag*/ true, m - 1 - sizeof(Rep)) Rep;
+p->mem = m - 1 - sizeof(Rep); p->ref = 1; p->vulnerable = false;
+return p;
+ }
+--- a/tstring.h
 b/tstring.h
+@@ -71,9 +71,12 @@
+   
+   // static methods
+   // operator new for this class
+-  static void * operator new (size_t size, size_t tmem) {
++  // add a tag parameter to ensure that the signature of the delete operator does not collide with the (void*,size_t) overload
++  static void * operator new (size_t size, bool /*tag*/, size_t tmem) {
+ 	 return ::operator new (size + tmem + 1);}
+-  static void operator delete (void *p, size_t) {
++  static void operator delete (void *p, bool /*tag*/, size_t) {
++	 ::operator delete (p); }
++  static void operator delete (void *p) {
+ 	 ::operator delete (p); }
+   
+   // create a new representation
diff -Nru mp3check-0.8.7/debian/patches/series mp3check-0.8.7/debian/patches/series
--- mp3check-0.8.7/debian/patches/series	2018-12-22 18:33:01.0 -0500
+++ mp3check-0.8.7/debian/patches/series	2020-06-11 00:12:11.0 -0500
@@ -4,3 +4,4 @@
 30_hardening.patch
 40_bts726068_remove_truncated_last_frame.patch
 nostrip.patch
+60_bts925782_ftbfs_with_gcc_9.patch

Bug#962692: puppet: Crashes due to "missing" facts.d directories

[Wilmer van der Gaast]

Package: puppet
Version: 5.5.19-1
Severity: grave
Justification: renders package unusable


Since the recent Ruby upgrade, Puppet invocations have been very noisy for a
while already.

But by now it's not even starting. Even after a dpkg -P including most
dependencies (including apt-get remove ruby.*) then reinstalling, all I
get is:

wilmer@veer:~/adsb$ sudo puppet agent --waitforcert 60 -t
/usr/lib/ruby/vendor_ruby/puppet/util.rb:461: warning: URI.escape is
obsolete
/usr/lib/ruby/vendor_ruby/puppet/file_system/file_impl.rb:80: warning: Using
the last argument as keyword parameters is deprecated
free(): invalid pointer
Aborted

Some gdb'ing and strace'ing suggests it gets stuck in facter, which indeed
fails individually with the ~same error.

Some stracing uncovered that it was trying to read the following
directories:

/opt/puppetlabs/facter/facts.d
/etc/facter/facts.d
/etc/puppetlabs/facter/facts.d

through trial and Aborted errors I've created those and now it works again.

Really wondering what's special about my system, or are more folks
seeing this?



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

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.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 puppet depends on:
ii  adduser  3.118
ii  facter   3.11.0-4.1
ii  hiera    3.2.0-2
ii  init-system-helpers  1.57
ii  lsb-base 11.1.0
ii  ruby 1:2.7+1
ii  ruby-augeas  1:0.5.0-3+b8
ii  ruby-deep-merge  1.1.1-1
ii  ruby-shadow  2.5.0-1+b3

Versions of packages puppet recommends:
ii  debconf-utils  1.5.74
ii  lsb-release    11.1.0
ii  ruby-selinux   3.0-1+b3

Versions of packages puppet suggests:
pn  ruby-hocon  
pn  ruby-rrd    

-- no debconf information

Bug#962693: mariadb-server-core-10.3: Recovery failure : loop of Read redo log up to LSN (MDEV-21826)

[Moritz Schlarb]

Package: mariadb-server-core-10.3
Version: 10.3.22-0+deb10u1
Severity: important
Tags: upstream
Forwarded: https://jira.mariadb.org/browse/MDEV-21826
Control: forwarded -1 https://jira.mariadb.org/browse/MDEV-21826

Dear Maintainers,

we are continuously plagued from upstream bug
[MDEV-21826](https://jira.mariadb.org/browse/MDEV-21826).

The workaround is to set `innodb_buffer_pool_instances=1`, but for
performance
reasons this is not so nice.

Would you mind releasing another stable update with just this patch
(https://github.com/MariaDB/server/commit/09e8707d90a8a73887fd4f22b64df43ff4669556.patch)
or the whole 10.3.23 version?

Best regards,
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF



-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (60, 'testing'),
(50, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 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 mariadb-server-core-10.3 depends on:
ii  libaio1 0.3.112-3
ii  libc6   2.30-4
ii  libcrypt1   1:4.4.10-10
ii  libgnutls30 3.6.7-4+deb10u4
ii  liblz4-11.8.3-1
ii  libpcre32:8.39-12
ii  libsnappy1v51.1.7-1
ii  libstdc++6  10.1.0-3
ii  libsystemd0 241-7~deb10u4
ii  mariadb-common  1:10.3.22-0+deb10u1
ii  zlib1g  1:1.2.11.dfsg-1

mariadb-server-core-10.3 recommends no packages.

mariadb-server-core-10.3 suggests no packages.



signature.asc
Description: OpenPGP digital signature

Bug#946412: janus-gateway: upstream does not support stable releases

[Jonas Smedegaard]

Quoting Moritz Muehlenhoff (2020-06-12 10:20:31)
> On Fri, Jun 12, 2020 at 08:53:35AM +0200, Jonas Smedegaard wrote:
> > Quoting Salvatore Bonaccorso (2020-06-11 22:54:43)
> > > On Sun, Dec 08, 2019 at 02:09:10PM +0100, Jonas Smedegaard wrote:
> > > > Upstream releases are to be considered draft snapshots,
> > > > and this package is therefore unsuitable for inclusion
> > > > in long-term distributions like Debian stable.
> > > > 
> > > > This bug should be bumped to release-critical state
> > > > close to or after entering freeze -
> > > > but not before so as to ease use for users tracking testing
> > > > including derivatives based on Debian testing.
> > > 
> > > Reading the above, so janus should not have been in buster, right?
> > 
> > While in good faith, I am not sure what you are implying with the 
> > above: In an ideal World (where crystal balls or time machines 
> > exist), yes.
> > 
> > Both filing this bugreport and the upstream statement triggering it 
> > occured _after_ the release of Buster, indicating lack of knowledge 
> > on the matter at the time of release of Buster (or, in bad faith, 
> > that it was known but kept secret - sure you cannot mean that).
> 
> Don't read things into this which don't exist :-)
> 
> The only question here was whether janus should continue to be in stable
> or not, noone is accusing you of anything.

Thanks for confirmation :-)


> > Sorry, I am not familiar with the procedures to do that, and 
> > appreciate your suggestion: Do I simply file a bugreport against 
> > ftp.debian.org as with removals from unstable/experimental, or which 
> > different runes should I throw?
> 
> For this simply do "reportbug release.debian.org" and pick the "rm" 
> option. The removal (if agreeds by stable release managers), then 
> happens by the next point release.

Yes, I figured that out (and tried communicate that shortly after I 
posted the above - sorry if that update didn't reach you), and should 
now have initiated the procedure with bug#962694.


Thanks,

 - Jonas

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

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

signature.asc
Description: signature

Bug#962665: python3: System site-packages directory not in sys.path breaking mechanism for pip3 install from source

[Piotr Ozarowski]

[Matthias, 2020-06-11]
> after installing a python package (radiotray) from source with pip3 (sudo pip3
> install .) The package is not listed by pip3 (pip3 list), nor can it be
> imported.

did you use pip3 from Debian or upstream?

> When checking manually the files a located under: /usr/lib/python3.6/site-
> packages/radiotray
> But this path is missing in the sys.path of python3:
[...] 
> So please add the site-packages directory under /usr to the sys.path of
> python3.

this will never happen, we removed site-packages for a good reason¹

[¹] https://wiki.debian.org/Python#Deviations_from_upstream

so… if you're using our pip3, then there's a bug (it should install into
dist-packages even if user used the
--I-know-it-s-stupid-but-please-use-sudo-and-break-my-system option)
If not (i.e. you used pip3 from outside Debian) then there's nothing we
can do.

Bug#962696: please consider renaming package

[Ivo De Decker]

package: vrms

Hi,

Please consider changing the name of this package and removing the reference
to RMS. As the description says, the package isn't based on the opinions of
RMS, but on the DFSG. 

Thanks,

Ivo

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Ian Jackson]

Jonathan Nieder writes ("Re: debian-policy: Please permit Debian revisions with 
1.0 native packages"):
> Hi,
> 
> Sam Hartman wrote:
> 
> > I think there are at least two cases where this issue comes up and is
> > important, and where using a debian revision without separate upstream
> > tarballs is the right approach:
> >
> > 1) small packages currently maintained by the upstream maintainer where
> > debian revision is incremented for packaging only changes and upstream
> > revision is incremented for upstream versions
> >
> > and
> >
> > 2) Cases typically outside the Debian archive where a git tree is being
> > built as a Debian package especially as part of a CI system and where
> > the effort of tracking upstream tarballs is undesired.
> >
> > 2) is more of an issue for lintian than it is for debian-policy.
> 
> I don't have any strong opinions about this, but I got the impression
> that Ian's motivation is a different case 3):

I agree with both of Sam's motivating scenarios.  But I also agree
with you that I presented a different scenario:

> | Most packages are maintained in git nowadays.  It is usual to have a
> | separate git branch for Debian and upstream work.  In such a situation
> | it makes perfect sense to have an upstream version number which
> | corresponds to an upstream tag.  For packages with a very small (or
> | zero) Debian delta to the upstream files, it makes sense to maintain
> | these git branches using `git merge' rather than as a stack of
> | patches.
> |
> | However, there are serious inherent problems with all of the
> | non-native source formats.  There are many that can occur in git
> | repositories which are not representable in non-native packages.  For
> | example, changes to symlinks.  Worse, one must either choose
> | `3.0 (quilt)' *which involves patch files within the git tree
> | and a great deal of complexity to manage those*; or 1.0-with-diff which
> | has an even more restricted set of things it can represent.

[emphasis added]

> Regardless of what happens to the 1.0 format, shouldn't the non-native
> package formats be improved to handle this?  The "git diff" format,
> which GNU patch has reasonable support for, is able to represent all
> of these kinds of changes, including changes to symlinks.  Tooling for
> handling 3.0 (quilt) packages is reasonably good at generating an
> appropriate single-diff quilt at build time.  To the extent that this
> doesn't work, it seems worth fixing.

Well, maybe.  I agree that some improvement here is warranted, but it
would need a transition plan to avoid uncontrolled adoption of source
package features meaning that source packages unexpectedly cannot be
unpacked on older releases of Debian.

But that does not solve the problem for my scenario.  I wrote:

|  *which involves patch files within the git tree
|   and a great deal of complexity to manage those*

I do not agree with the thrust of your comment that "Tooling for
handling 3.0 (quilt) packages is reasonably good at generating an
appropriate single-diff quilt at build time".  It's true as far as it
goes but doesn't address the key problems, namely that the single
patch ends up inside the tree.

This could be solved by a new `3.0 (diff)' format perhaps.  If and
when that is provided then this one scenario would perhaps be better
handled that way.  But we are not there yet.

The other two scenarios presented by Sam would still remain as reasons
to have a native package with a hyphen in the version number.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#962441: RFS: siconos/4.3.0+dfsg-1 [RC] -- modeling and simulation of nonsmooth dynamical systems (simulation runner tool)

[Stephen Sinclair]

The problem turned out to be a real bug (null dereference) that only
occurred occasionally due to poor testing procedures (test includes
some randomization in the code path).

The bug has been patched and a separate RFS for fclib has been filed, #962684.


regards,
Steve



On Mon, Jun 8, 2020 at 6:09 PM Stephen Sinclair  wrote:
>
> Hi Adam,
>
> Thanks for taking a look.
>
> On Mon, Jun 8, 2020 at 5:29 PM Adam Borowski  wrote:
> >
> > On Mon, Jun 08, 2020 at 07:37:26AM +0200, Stephen Sinclair wrote:
> > >  * Package name: siconos
> > >Version : 4.3.0+dfsg-1
> >
> > But
> >
> > > Testing this package requires fclib 3.1.0+dfsg-1, which also needs
> > > sponsorship.  It can be found here:
> > >
> > >   https://mentors.debian.net/package/fclib
> >
> > so thats actually two RFSes in one.  And there are problems with fclib.
>
> I'm not sure what the right protocol is in this case, to be honest.
> Should I have issued two RFSes or done this one differently?
>
> > > Changes since the last upload:
> > >
> > >* New upstream version. (Closes: #962219) (Closes: #961735)
> > >* Add dependencies libboost-timer-dev, libboost-chrono-dev.
> > >* Depend on openblas and lapacke instead of atlas.
> > >* Require fclib 3.1.0
> > >* Update location of install paths.
> > >* Enable WITH_GENERATION, now required for serialization.
> > >* Install new siconos_export_raw_data tool.
> > >* Fix cmake import targets to allow independent packages.
> > >* Update patches for new upstream version.
> > >* Add a flag for gfortran to avoid a regression in GCC-10.
> > >  (Closes: #957794)
> > >* Remove unused build rule for swig3.0 symlink.
> > >* Remove non-existent files from debian/copyright.
> > >* Rewrite patch descriptions using gbp pq.
> > >* Fix a Python warning about using 'is' with a literal.
> >
> > It looked ok on my box, and passed both all automated and manual review I've
> > done.  But, it fails on some of official buildds: at least on amd64 arm64
> > x32.
> >
> > I seem unable to reproduce the FTBFS locally -- in 15 tries on amd64, 1 on
> > arm64, all passed.
> >
> > Thus, you'd need to investigate and fix that one in fclib first.
>
> I'm very confused about the error on buildd because I have indeed
> built the package many times with a fresh debootstrap without such a
> segfault.  I will investigate and try to reproduce.
>
> I did my best to avoid problems but it seems I have missed something,
> I'd like to understand the difference between buildd and my own
> configuration to avoid this happening in the future.
>
> By the way Siconos due to its nature has been quite hard to get
> working on any architecture other than amd64 unfortunately.  Is there
> a way to mark the package as amd64-only?
> In the meantime I try to find solutions for other architectures but it
> is slow going.
>
> > It'd be good if you filed a separate RFS for that.  Let's leave this one
> > for siconos 4.3.0+dfsg-1
>
> Okay that sounds like a reasonable approach given this problem.
>
> regards,
> Steve

Bug#953554: Please permit Debian revisions with 1.0 native packages

[Guillem Jover]

On Thu, 2020-06-11 at 18:32:04 -0700, Felix Lechner wrote:
> On Wed, Mar 11, 2020 at 5:37 AM Ian Jackson wrote:
> >
> > I hope that whatever occurs more widely, this particular message can
> > be downgraded appropriately so that by default it is an warning rather
> > than an error.  That's all I'm asking for in this bug.
> >
> > Can we perhaps go back to
> >hyphen-in-native-debian-changelog-version
> 
> It never felt so wrong to merge two bugs, but they are now the same. I
> supported your request in the cloned policy bug #953629 and got you
> another +1. For now, I will reduce the tag's severity to a warning
> like you asked.
> 
> Lintian is not a good vehicle for policy changes, and you were unaware
> when filing that policy stood in the way. Please contact us again when
> the policy changes (or if you require additional support in the
> matter). I cannot wait to implement your request.

Oh! Given the timing of this reaction, I think it would not be
unreasonable to consider it originating out of spite? :)

Regards,
Guillem

Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1

[Adam D. Barratt]

On Fri, 2020-06-12 at 00:50 +0300, Adrian Bunk wrote:
> Control: tags 962669 moreinfo
> 
> On Thu, Jun 11, 2020 at 08:18:38PM +0100, Adam D. Barratt wrote:
> > On Thu, 2020-06-11 at 13:48 -0500, Michael Shuler wrote:
> > > On 6/11/20 1:33 PM, Adam D. Barratt wrote:
> > > > Just to confirm - will the certificates be automatically re-
> > > > added (assuming that users have either the automatically trust
> > > > or prompt options enabled)?
> > > 
> > > (stretch-pu report cc'ed, since same applies)
> > > 
> > > Excellent question. I believe we're going to hit #743339
> > > "Previously removed certificates not added again". I had not
> > > found a reasonable fix for that case in general, to preserve a
> > > user's selections.
> > > Maybe a "good enough" fix will have to do for the specific ones
> > > added back.
> > 
> > OK.
> > 
> > In that case, how does this seem as an SUA text?
[...]
> > use the affected certificates, you may need to manually enable them
> > by running "dpkg-reconfigure ca-certificates" as root.
> > 
> 
> This does not work in various embedded scenarios.

Wouldn't embedded setups be more likely to have a hard-coded
configuration?

> Would it work to force-enable them in /etc/ca-certificates.conf
> from the preinst when upgrading from old-version matching 20200601* ?

I'll leave the technical answer to Michael.

Practically, it's then not great for users who had intentionally
removed the certificates - or simply decided not to trust them in the
first place - prior to the upgrade. I'm not sure how we could
distinguish the cases automatically.

> Unrelated to that, please keep the Python 2 -> 3 build dependency
> change out of this emergency update.

ACK.

Regards,

Adam

Bug#946412: janus-gateway: upstream does not support stable releases

[Moritz Muehlenhoff]

On Fri, Jun 12, 2020 at 08:53:35AM +0200, Jonas Smedegaard wrote:
> Quoting Salvatore Bonaccorso (2020-06-11 22:54:43)
> > On Sun, Dec 08, 2019 at 02:09:10PM +0100, Jonas Smedegaard wrote:
> > > Upstream releases are to be considered draft snapshots,
> > > and this package is therefore unsuitable for inclusion
> > > in long-term distributions like Debian stable.
> > > 
> > > This bug should be bumped to release-critical state
> > > close to or after entering freeze -
> > > but not before so as to ease use for users tracking testing
> > > including derivatives based on Debian testing.
> > 
> > Reading the above, so janus should not have been in buster, right?
> 
> While in good faith, I am not sure what you are implying with the above: 
> In an ideal World (where crystal balls or time machines exist), yes.
> 
> Both filing this bugreport and the upstream statement triggering it 
> occured _after_ the release of Buster, indicating lack of knowledge on 
> the matter at the time of release of Buster (or, in bad faith, that it 
> was known but kept secret - sure you cannot mean that).

Don't read things into this which don't exist :-)

The only question here was whether janus should continue to be in stable
or not, noone is accusing you of anything.

> Sorry, I am not familiar with the procedures to do that, and appreciate 
> your suggestion: Do I simply file a bugreport against ftp.debian.org as 
> with removals from unstable/experimental, or which different runes 
> should I throw?

For this simply do "reportbug release.debian.org" and pick the "rm"
option. The removal (if agreeds by stable release managers), then happens
by the next point release.

Cheers,
Moritz

Bug#960495: transition: gdal

[Sebastian Ramacher]

On 2020-06-12 06:51:57 +0200, Sebastiaan Couwenberg wrote:
> On 6/11/20 10:07 PM, Sebastian Ramacher wrote:
> > On 2020-06-11 20:37:58 +0200, Sebastiaan Couwenberg wrote:
> >> On 6/11/20 6:46 AM, Sebastiaan Couwenberg wrote:
> >>> On 6/10/20 9:46 PM, Sebastian Ramacher wrote:
>  Please go ahead with the upload to unstable.
> >>>
> >>> Thanks, gdal (3.1.0+dfsg-1) was just uploaded to unstable.
> >>
> >> The rebuild are looking good so far
> >>
> >> Please also binNMU postgis in experimental.
> > 
> > Scheduled.
> 
> Thanks.
> 
> Some packages were (re)built with the old gdal:
> 
>  * octave-mapping on mips64el

Rescheduled. I forgot to set dw for octave-mapping.

>  * libgdal-grass  on armel, mips64el & mipsel

They weren't built with the old version of gdal, but with libgdal-dev
3.1.0+dfsg-1 installed. How did they end up with a dependency on
libgdal26 (>= 3.1.0)?

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Ian Jackson]

Felix Lechner writes ("debian-policy: Please permit Debian revisions with 1.0 
native packages"):
> As a Lintian maintainer, I would like to express support for Ian's
> effort to remove restrictions on Debian version strings.
> 
> Unlike Ian, however, I also believe all packages should be converted
> to format 3.0. A package's 'nativeness' is then declared explicitly,
> and does not have to be inferred from the version string.

On 1.0 vs 3.0:

I agree that the nativeness should be declared explicitly.  If there
were a 3.0 format which was strictly superior to 1.0-with-diff then I
would have no objection to deprecating 1.0-with-diff.  But sadly there
isn't.

The problem is that `3.0 (quilt)' has both advantages (eg that
`nativeness' is declared explicitly) and disadvantages (patches stored
in the tree, complex interactions with dpkg-source, cannot handle
packages whose upstream contains a .pc directory, very confusing to
those new to Debian, ...).  Many of these disadvantages are inherent
in the design of `3.0 (quilt)'.  A peruse of the dpkg-source bug list
shows that it's not just me who sees problems with `3.0 (quilt)'.[1]

Whether to choose one set of disadvantages, or another set, should be
a workflow choice for the maintainer.

Obviously it would be possible for there to be a new format of some
kind (maybe something like a `3.0 (diff)') which would address these
issues.  But the dpkg maintainers haven't evidently haven't felt such
a thing to be an appropriate part of their programme to abolish 1.0,
since they haven't provided it in all these years.

As for `3.0 (native)', it has one serious disadvantage: dpkg-source
has been programmed to reject version numbers with a Debian revision.
If that restriction were relaxed, `3.0 (native)' would be a strictly
superior drop-in replacement for 1.0-native and I doubt anyone would
have any objection to phasingt 1.0-native out completely.

Thanks,
Ian.

[1] I do feel I need to say that `3.0 (quilt)' is a massive
improvement over what was being done before its introduction.  I can
quite see why it was designed the way it was.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#962158: lintian: New very problematic --fail-on default value

[Guillem Jover]

Control: tags -1 patch

*Sigh*

On Wed, 2020-06-10 at 08:38:05 -0700, Felix Lechner wrote:
> On Tue, Jun 9, 2020 at 11:15 PM Chris Lamb  wrote:
> >
> > Felix, can you help out? I am not in a position to contribute to this
> > discussion itself.
> 
> Well, I wish I could. Guillem makes many alarmist statements,

This is a funny way to put it I guess. :)

> but fails to explain why the change is an undue burden.

I've done that multiple times now.

> I also do not know
> how to engage productively with visceral and absolute responses such
> as:

Obviously biased, but I don't see anything visceral in any of the
"selected" (out of context) quotes below. They reflect IMO either
astonishment or a reasoned view on the matter. If you disagree you
could have as well rebutted them, which you still have not done…

(Should really not be going over these, because this is yet again
another diversion from the matter at hand but…)

> > Err…

This was in reply to:

  ,---
  As I explained on IRC this statement is probably untrue (and you did
  not have the courtesy to mention that objection here).
  `---

So pretty much astonishment at this, first because I'm not in the
habit of leaking conversations from IRC w/o permission, and second
because of the unsubstantiated truthiness claim veiled in as a
"possibility".

> > it does not make any sense whatsoever
> > does not match reality
> > it does not even make sense within a Debian-centric view

Supported in the context conveniently trimmed out.

> > I'll have to very much disagree
> > you have still not explained what this default change really accomplishes
> > besides inducing tons of work and breakage
> > No, they did not.

These are either substantiated opinion (also conveniently trimmed
out), or facts. If the facts are wrong, you can always challenge them.

> It's amazing how much time and energy Guillem expended on this issue
> here, on IRC, and in #962157 while dpkg has more open bugs than
> Lintian.

Wow, just wow, I'm not sure where to begin here TBH. First, I'm not
even sure how this is in the least relevant to this report, how it
is relevant to you how anyone else spends their time in a volunteer
project, and how that compares to anything else.

But this just feels like a pattern to me, when there are no more
technical arguments to make, you start either the unrelated diversion
and distraction, the personal comments, etc.

And, really, the bug reports have actually been 4 shortish emails. The
"bulk" of the time was on IRC, but that has not been the only and first
instance of endless and repetitive discussions going in circles, with
unrelated tangents all over the place…

> As you know from my past behavior with 'md5sums -z' or the odd
> contributor on Salsa, I am not opposed to compromise when it brings
> peace. In the present case, such a compromise could be a value 'none'
> to disable the default Guillem likes (and which I would like to
> remove).

Again with the personification, this is not something _I_ personally
like. I could personally adapt. This is something I do consider to
be a global bad default for the program and Debian, derivatives, etc
at large.

It's clear you want this behavior change, it's not clear why though.
The reasons I've seen from you are:

  - it has been advertised.
  - ftp-masters have requested it (and they are the only ones that
matter, at which moment I guess I wonder that's the point of any
non-fatal tags in lintian that ftp-masters do not use)
  - a very vague and unsubstantiated "the current solution is simple,
elegant, straightforward and explicit".
  - unrelated claims about the exit status being unreliable.
  - other unrelated stuff from IRC.

The attached (untested, just «perl -cw» checked) patch, applied after
reverting commit 30ae7cab479e64bf58618e17854794112f8cc791 does not
really look complex to me TBH, in addition of fixing a small bug.

> At the same time, the change was widely released two weeks ago. Simon
> Quigley from Ubuntu announced it on debian-devel on May 25 [1], while
> I advertised the change repeatedly on IRC and added a note to DevNews.
> Some users may have already adapted their systems.
> 
> [1] https://lists.debian.org/debian-devel/2020/05/msg00239.html

Yet again, advertising a change does not imply there's a justification
for it, that's not a technical nor even a good social reason. (Not to
mention that not everyone has apt-listchanges installed, so not even a
NEWS might be seen, and as mentioned the problem with that is that it
would go unnoticed given that it is a silent breaking change.)

> It would also give me more time to understand the possibly
> unreasonable burden on Lintian users across Debian and the derivative
> ecosystem. Simon may receive feedback from Ubuntu, a significant
> derivative. If there are real problems, I am happy to discuss a
> solution that reverts the default to Lintian's old setting.

This again shows that all the reasons exposed on IRC and on the reports
are 

Bug#962681: battery drain during system shutdown

[Gopal Sharma]

I am still facing the issue.

Bug#946412: janus-gateway: upstream does not support stable releases

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2020-06-12 08:53:35)
> Quoting Salvatore Bonaccorso (2020-06-11 22:54:43)
> > As such it might be a good option to ask for removal of src:janus in 
> > buster. If you agree on that, can you fill a bug for the 
> > release-team/SRM to ask for removal of the package in the next buster 
> > point release?
> 
> Yes, removal from Buster should be done.
> 
> Sorry, I am not familiar with the procedures to do that, and appreciate 
> your suggestion: Do I simply file a bugreport against ftp.debian.org as 
> with removals from unstable/experimental, or which different runes 
> should I throw?

Ah, ignore that last part, I found it now (silly me):
  reportbug release.debian.org


 - Jonas

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

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

signature.asc
Description: signature

Bug#960953: deepin-qt5dxcb-plugin: FTBFS with Qt 5.14: Project ERROR: Not support Qt Version: 5.14.2

[Dmitry Shachnev]

Dear Maintainer,

On Mon, May 18, 2020 at 08:46:07PM +0300, Dmitry Shachnev wrote:
> deepin-qt5dxcb-plugin fails to build with Qt 5.14, currently available in
> experimental:
>
>   make[1]: Entering directory '/<>'
>   [...]
>   sh: 1: git: not found
>   Project ERROR: Not support Qt Version: 5.14.2
>   make[1]: *** [Makefile:47: 
> sub-platformplugin-qt5platform-plugin-pro-make_first] Error 3
>
> You need to add Qt 5.14 headers to platformplugin/libqt5xcbqpa-dev/5.14.2.

I have just uploaded NMU to DELAYED/5-day.

The diff is available here:

https://salsa.debian.org/pkg-deepin-team/deepin-qt5dxcb-plugin/-/merge_requests/1

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Bill Allombert]

On Fri, Jun 12, 2020 at 09:09:22AM +, Holger Levsen wrote:
> hi,
> 
> I'm not fully sure if people really intend to change the 1.0 format, but if 
> so,
> I'm against it. If you do it, please call it 1.1 or whatever, but please don't
> change 1.0, too many tools rely on it's decade old behavior.
  
For what it is worth, Debian revisions with 1.0 native package were
allowed for a long time. so this is not a change to the 1.0 format.

> Besides that it's also my opinion that we should get rid off native packages
> completly, though that's yet another discussion. Native packages made sense
> when Debian had little or no downstreams, but...

I believe there are exceptions.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#962518: cegui-mk2 FTBFS on mipsel/mips64el: symbol differences

[Stephen Kitt]

On Wed, 10 Jun 2020 13:53:58 +0200, Stephen Kitt  wrote:
> On Tue, 9 Jun 2020 21:08:25 +0100, Simon McVittie  wrote:
> > On Tue, 09 Jun 2020 at 15:21:37 -0400, Olek Wojnar wrote:  
> > > On Tue, Jun 9, 2020 at 6:12 AM Adrian Bunk <[1]b...@debian.org>
> > > wrote:
> > > > I wonder if the real fix shouldn't be for cegui-mk2 to stop
> > > > exporting a
> > > pile
> > > > of Boost symbols...
> > > 
> > > 
> > > I would love that. Any advice on a reasonably easy/straightforward way
> > > of doing that?
> > 
> > *If* your upstream is on board with this, my understanding is that
> > the main way to do this is to build with -fvisibility=hidden,
> > and decorate each intentionally-public class/function/thing
> > with a macro that (when building with gcc or clang) expands to
> > __attribute__((__visibility__("hidden"))).
> > 
> > Some upstreams will be doing something similar already, because they are
> > portable to Windows and need to decorate public symbols with
> > __declspec(dllexport) on Windows.  
> 
> See
> https://salsa.debian.org/debian/fcml/-/blob/master/debian/patches/visibility.patch
> for a quick-and-dirty example of both of these approaches (and
> https://salsa.debian.org/debian/fcml/-/commit/22d753b1c820ea339b6b52cbc1cdf6e05229fbf9#34a4bacbb5ecf973fa5f481819228c77da389f43
> for the resulting symbols file simplification).

I’ve looked into the cegui-mk2 situation a bit more. It turns out that the
project itself does define its exported symbols, and that can be used to
built a library with no extraneous symbols:

* add -fvisibility=hidden to the CXXFLAGS (or use the CMake hidden symbol
  support, which I think is available);
* patch the headers define the various export macros, e.g. CEGUIEXPORT in
  cegui/include/CEGUI/Base.h (taking care to match the EXPORTS handling, same
  as the Windows code).

This greatly reduces the number of exported symbols:

 debian/libcegui-mk2-0.8.7.symbols | 7477
 
+++--
 1 file changed, 577 insertions(+), 6900 deletions(-)

However it also breaks dh_dwz.

This still leaves all the bitness variation (armel/armhf/i386 etc. v.
amd64/arm64 etc., which could be better handled with arch-bits), and the
changes from GCC 9 to 10. Those are annoying enough that I suspect it’s
simply not worth dealing with a symbols file, as others have said.

However I do think that controlling the symbols’ visibility would be a good
thing, but that should be dealt with upstream.

Regards,

Stephen


pgpYiz05ydFjM.pgp
Description: OpenPGP digital signature

Bug#962667: Fix FTBFS

[Frédéric Bonnard]

Control: tags -1 patch

--

Dear maintainer,
upstream has a commit for that : which I imported and improved as well.
Here is a merge request for ardour packaging :
https://salsa.debian.org/multimedia-team/ardour/-/merge_requests/2

Regards,


F.


signature.asc
Description: PGP signature

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Holger Levsen]

hi,

I'm not fully sure if people really intend to change the 1.0 format, but if so,
I'm against it. If you do it, please call it 1.1 or whatever, but please don't
change 1.0, too many tools rely on it's decade old behavior.

Besides that it's also my opinion that we should get rid off native packages
completly, though that's yet another discussion. Native packages made sense
when Debian had little or no downstreams, but...


-- 
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#962695: iftop resolves all IPv6 addresse to the same hostname

[Harald Hannelius]

Package: iftop
Version: 1.0~pre4-4
Severity: minor

Dear Maintainer,

When running iftop on a server with serveral IPv6-connections ongoing,
iftop seems to resolve the ip-addresses to the same hostname. This is a
bit confusing. By pressing 'n' to get numerical output everything looks 
correct.

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

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

Versions of packages iftop depends on:
ii  libc62.24-11+deb9u4
ii  libncurses5  6.0+20161126-1+deb9u2
ii  libpcap0.8   1.8.1-3
ii  libtinfo56.0+20161126-1+deb9u2

iftop recommends no packages.

iftop suggests no packages.

-- no debconf information

Bug#960495: transition: gdal

[Sebastiaan Couwenberg]

On 6/12/20 10:21 AM, Sebastian Ramacher wrote:
> On 2020-06-12 06:51:57 +0200, Sebastiaan Couwenberg wrote:
>> On 6/11/20 10:07 PM, Sebastian Ramacher wrote:
>>> On 2020-06-11 20:37:58 +0200, Sebastiaan Couwenberg wrote:
 On 6/11/20 6:46 AM, Sebastiaan Couwenberg wrote:
> On 6/10/20 9:46 PM, Sebastian Ramacher wrote:
>> Please go ahead with the upload to unstable.
>
> Thanks, gdal (3.1.0+dfsg-1) was just uploaded to unstable.

 The rebuild are looking good so far

 Please also binNMU postgis in experimental.
>>>
>>> Scheduled.
>>
>> Thanks.
>>
>> Some packages were (re)built with the old gdal:
>>
>>  * octave-mapping on mips64el
> 
> Rescheduled. I forgot to set dw for octave-mapping.
> 
>>  * libgdal-grass  on armel, mips64el & mipsel
> 
> They weren't built with the old version of gdal, but with libgdal-dev
> 3.1.0+dfsg-1 installed. How did they end up with a dependency on
> libgdal26 (>= 3.1.0)?

Most likely because grass hadn't been rebuilt with the new gdal yet.

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#962692: puppet: Crashes due to "missing" facts.d directories

[intrigeri]

Hi,

Wilmer van der Gaast (2020-06-12):
> wilmer@veer:~/adsb$ sudo puppet agent --waitforcert 60 -t
> /usr/lib/ruby/vendor_ruby/puppet/util.rb:461: warning: URI.escape is
> obsolete
> /usr/lib/ruby/vendor_ruby/puppet/file_system/file_impl.rb:80: warning: Using
> the last argument as keyword parameters is deprecated
> free(): invalid pointer
> Aborted

On a sid system, I see puppet-master.service failing to start with
the same "free(): invalid pointer" error.

> Some stracing uncovered that it was trying to read the following
> directories:
>
> /opt/puppetlabs/facter/facts.d
> /etc/facter/facts.d
> /etc/puppetlabs/facter/facts.d
>
> through trial and Aborted errors I've created those and now it works again.

I confirm this workaround fixes the problem for me as well.
Thanks for figuring it out and sharing this workaround :)

Cheers!

Bug#962692: puppet: Crashes due to "missing" facts.d directories

[Wilmer van der Gaast]

Huh https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962320 may in fact be a 
duplicate.

Bug#962692: puppet: Crashes due to "missing" facts.d directories

[Wilmer van der Gaast]

On Fri, 12 Jun 2020, at 09:38, intrigeri wrote:
> > Some stracing uncovered that it was trying to read the following
> > directories:
> >
> > /opt/puppetlabs/facter/facts.d
> > /etc/facter/facts.d
> > /etc/puppetlabs/facter/facts.d
> >
> > through trial and Aborted errors I've created those and now it works again.
> 
> I confirm this workaround fixes the problem for me as well.
> Thanks for figuring it out and sharing this workaround :)
> 
Ha, no worries, glad you discovered this so quickly then!

For others who run into this, let's reduce the above into a oneliner:

mkdir -p /opt/puppetlabs/facter/facts.d /etc/facter/facts.d 
/etc/puppetlabs/facter/facts.d

I just realised that indeed my other testing box had this problem and again it 
was resolved by creating these directories.

Logs show that puppet on this box disappeared on the 7th. (I separately have a 
cronjob that restarts puppet daily due to memory leaks (maybe long gone, the 
cronjob is years old), helping early discovery of this issue) dpkg.log doesn't 
show any ruby or puppet packages being touched then but I do see some libboost 
libraries, I believe at least some of these are (indirect) puppet dependencies?


`//

Bug#960073: Re: Bug#960073: Package:python-pyqt5 Run the example code with Trace and crash (SIGABRT)【请注意，邮件由mity...@gmail.com代发】

[pengzon...@uniontech.com]

Hi!

I tried to verify the local opengl/glx, they are normal. It is no problem to 
write QT code directly to call qtwebengine. So I suspect that the problem is 
caused by pyqt.
Looking forward to hearing from you soon.
Thanks.

BRs
//Zongli


testwebengine.cpp
Description: Binary data

Bug#918358: libsane:amd64: Missing permissions for scanner group on usb device

[Jörg Frings-Fürst]

Hello Chris,

the version 1.0.30-1~experimental2 is almost ready to start the upcoming
transition. At the moment only the build on 2 architectures[1] is missing.

As soon as they are finished I will talk to my mentor and apply for the start of
the transition.

Since the fix to fix the bug is quite simple[2] there is no bugfix release.

CU
Jörg

[1] 
https://buildd.debian.org/status/package.php?p=sane-backends=experimental
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918358#12

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#962669: Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1

[Michael Shuler]

On 6/12/20 7:36 AM, Adrian Bunk wrote:

On Fri, Jun 12, 2020 at 08:40:29AM +0100, Adam D. Barratt wrote:

On Fri, 2020-06-12 at 00:50 +0300, Adrian Bunk wrote:

Control: tags 962669 moreinfo

On Thu, Jun 11, 2020 at 08:18:38PM +0100, Adam D. Barratt wrote:

On Thu, 2020-06-11 at 13:48 -0500, Michael Shuler wrote:

On 6/11/20 1:33 PM, Adam D. Barratt wrote:

Just to confirm - will the certificates be automatically re-
added (assuming that users have either the automatically trust
or prompt options enabled)?


(stretch-pu report cc'ed, since same applies)

Excellent question. I believe we're going to hit #743339
"Previously removed certificates not added again". I had not
found a reasonable fix for that case in general, to preserve a
user's selections.
Maybe a "good enough" fix will have to do for the specific ones
added back.


OK.

In that case, how does this seem as an SUA text?

[...]

use the affected certificates, you may need to manually enable them
by running "dpkg-reconfigure ca-certificates" as root.



This does not work in various embedded scenarios.


Wouldn't embedded setups be more likely to have a hard-coded
configuration?


The official way to hardcode CA configuration would be through debconf
or /etc/ca-certificates.conf, which runs into #743339.

If you are really security-focussed you might pin the actual certificate
instead of trusing a CA.

For the average embedded device the only thing that matters about
ca-certificates is something like "https works".


Would it work to force-enable them in /etc/ca-certificates.conf
from the preinst when upgrading from old-version matching 20200601* ?


This could actually be done in the postinst before the debconf
configuration, something like
   sed -i "s|^\!mozilla/GeoTrust_Global_CA.crt|mozilla/GeoTrust_Global_CA.crt|" 
/etc/ca-certificates.conf
for all affected certificates when $2 matches 20200601*


This is what I was working on last night, there is an old dpkg 
--compare-versions example in postinst, and that is similar to the 
action I had in mind. I intend to sed all in the list we blacklisted, 
since they remain in the bundle, so we're not here next week with 
another of the date or intermediate exceptions in NSS. If there is 
objection to this, please let me know.



I'll leave the technical answer to Michael.

Practically, it's then not great for users who had intentionally
removed the certificates - or simply decided not to trust them in the
first place - prior to the upgrade. I'm not sure how we could
distinguish the cases automatically.


The default is to trust all new certificates, so this is what the vast
majority of users are using.

#743339 is primarily about this kind of remove+readd in the package
being the only way how any installed certificate could end up being
deactivated in the default situation.

This is permanent damage that can lead to nasty problems months or
years later.

There are likely some users somewhere who have manually activated or
deactivated these specific certificates, but this is nothing we can
handle correctly in both directions now.


This is exactly the kind of behavior I think we'd like to preserve, so 
we don't stomp on a previous intentional trust setting and blindly 
enable, but I think this specific list of blacklisted certs being 
re-enabled, if specifically 20200601* is installed should work. The 
default "yes" trust and re-enable of these may be the "good enough" fix, 
while #743339 is still an issue. That should hit way over 80% use case, 
if we consider an 80/20 split.


For what it's worth, with additional testing after this, I believe I may 
have found one of the "save but disable' causes of #743339, after 
staring at ca-certificates.conf creation, upgrades, etc in postinst and 
the debconf ca-certificates.config contents. It won't fix existing trust 
^!'s, but would help on future root removals - later on that bug..



Unrelated to that, please keep the Python 2 -> 3 build dependency
change out of this emergency update.


ACK.


Will do, thank you both.

Kind regards,
Michael

Bug#962711: RM: python-tornado4 -- ROM; Not needed anymore

[Ondřej Nový]

Package: ftp.debian.org
Severity: normal

Hi,

this package is an old fork of the tornado binary package, which
have been created for src:salt.

There are no longer any rdepends (salt ceased to depend upon it after
3000+dfsg1-1).

Thanks,
Ondrej Novy

Bug#962713: please add support for x13as

[Sébastien Villemot]

Package: gretl
Version: 2020b-1
Severity: wishlist

Hi Dirk,

gretl is able to take advantage of X-13ARIMA-SEATS (a.k.a. x13as) for
performing seasonal adjustment of time series.

x13as is now packaged in Debian (though in the non-free archive area), so it
would be nice if gretl could take advantage of it.

At least, a Suggests relationship should be added (note that a Recommends or a
Depends is not possible, since x13as is non-free; see Policy §2.2.1).

Quickly looking at the source code of gretl, I am under the impression that it
may need to be slightly patched in order to find the x13as executable (it seems
to hardcode a Windows .exe path). But I did not really investigate, so I leave
that up to you.

Best,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org

Bug#962714: RFS: ddupdate/0.6.5-1 -- Tool updating DNS data for dynamic IP addresses

[Alec Leamas]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: ddupdate
   Version : 0.6.5-1
   Upstream Author : https://github.com/leamas/ddupdate/issues
 * URL : https://github.com/leamas/ddupdate
 * License : Expat
 * Vcs : https://github.com/leamas/ddupdate/tree/debian
   Section : net

It builds the single, standard python package:

  ddupdate - Tool updating DNS data for dynamic IP addresses

This is a bugfix upstream release. More info is available at

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

Alternatively, one can download the package with dget using:

  dget -x
https://mentors.debian.net/debian/pool/main/d/ddupdate/ddupdate_0.6.5-1.dsc

Changes since the last upload:

   * New upstream release.
   * Bump debhelper from old 11 to 12.
   * Set debhelper-compat version in Build-Depends.
   * Set field Upstream-Contact in debian/copyright.
   * Set upstream metadata fields: Bug-Submit, Repository.
   * Remove obsolete fields Contact, Name from debian/upstream/metadata
 (already present in machine-readable debian/copyright).
   * Update standards version to 4.5.0, no changes needed.
   * Fix error running ddupdate-config (#41)
   * New plugin domains.google.com
   * Multiple python 3.9 fixes.

Regards,

--
  Alec Leamas

Bug#852196: lintian: check of license-problem-convert-utf-code is too strict

[Felix Lechner]

Control: retitle -1 lintian: check of license-problem-convert-utf-code
is too strict

Hi,

Message #18 went to #900598 and this bug, but the retitle operation
should not have applied here. Reverting.

Kind regards,
Felix Lechner

Bug#962713: please add support for x13as

[Dirk Eddelbuettel]

Hi Seb,

On 12 June 2020 at 15:59, Sébastien Villemot wrote:
| Package: gretl
| Version: 2020b-1
| Severity: wishlist
| 
| Hi Dirk,
| 
| gretl is able to take advantage of X-13ARIMA-SEATS (a.k.a. x13as) for
| performing seasonal adjustment of time series.

I know. There was some back and forth about that between Allin and myself. I
think I even supported it in the past.
 
| x13as is now packaged in Debian (though in the non-free archive area), so it
| would be nice if gretl could take advantage of it.
| 
| At least, a Suggests relationship should be added (note that a Recommends or a
| Depends is not possible, since x13as is non-free; see Policy §2.2.1).
| 
| Quickly looking at the source code of gretl, I am under the impression that it
| may need to be slightly patched in order to find the x13as executable (it 
seems
| to hardcode a Windows .exe path). But I did not really investigate, so I leave
| that up to you.

I may not have time for that. I can add the Suggests, but the rest is a
little out of reach.  It probably just needs it in the PATH, eveything else
would be a litle anti-unixish.

Also, in case you had not seen it, Christoph Sax and I extended his (CRAN)
package seasonal to automagically download x13as and use it behind the
scenes. If R scripting is of interest / use to you that is another option.
(Same non-freenees for x13as of course though commerce ships Fortran which
Christoph and I turn into x13binary (on GitHub) eg for Windows.

Dirk
 
| Best,
| 
| --
| ⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
| ⣾⠁⢠⠒⠀⣿⡁  Debian Developer
| ⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
| ⠈⠳⣄  http://www.debian.org

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#962701: installation-report: No problem in everyday use.

[veb]

Package: installation-reports
Version: 2.74
Severity: minor

Dear Maintainer,



-- Package-specific info:

Boot method: DVD
Image version: Debian GNU/Linux 10.4.0 "Buster" - Unofficial amd64 Binary-1
with firmware 20200509-10:26 netinst
Date: 2020-06-06 14:24 BST

Machine: AMD A10-5800K ASUS F2A85-VPro NVIDIA GeForce GTX970
Partition:Disk: /dev/sdb
   Size: 931.53 GiB, 1000204886016 bytes, 1953525168 sectors
   Label: dos, identifier: 0xcf981e75

Device  Boot  StartEndSectors   Size Id Type
>>  /dev/sdb1   *  2048 1936850943 1936848896 923.6G 83 Linux
/dev/sdb21936852990 1953523711   16670722 8G  5 Extended
└─/dev/sdb5  1936852992 1953523711   16670720 8G 82 Linux swap /
Sol





 ┌┐
 │ Partition type: Linux (83) │
 │ Attributes: 80 │
 │Filesystem UUID: f897dbc2-969f-4b20-a7e5-307352441d15   │
 │ Filesystem: ext4   │
 │ Mountpoint: / (mounted)


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

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

Comments/Problems:

package nvidia-driver installed after failed attempt to install proprietary
driver 440.82




--

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20190702+deb10u4"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux gdebian 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29)
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD]
Family 15h (Models 10h-1fh) Processor Root Complex [1022:1410]
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8526]
lspci -knn: 00:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD]
Family 15h (Models 10h-1fh) Processor Root Port [1022:1412]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
FCH USB XHCI Controller [1022:7812] (rev 03)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8527]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:10.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
FCH USB XHCI Controller [1022:7812] (rev 03)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8527]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD]
FCH SATA Controller [AHCI mode] [1022:7801] (rev 40)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8527]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
FCH USB OHCI Controller [1022:7807] (rev 11)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8527]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: Kernel modules: ohci_pci
lspci -knn: 00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
FCH USB EHCI Controller [1022:7808] (rev 11)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8527]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
FCH USB OHCI Controller [1022:7807] (rev 11)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8527]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: Kernel modules: ohci_pci
lspci -knn: 00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
FCH USB EHCI Controller [1022:7808] (rev 11)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8527]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH 

Bug#962707: transition: qhull

[Timo Röhling]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: jspri...@debian.org

Dear release team,

I would like to transition qhull 2020.1, which has a properly bumped upstream 
SONAME now.

The ben tracker is good:
https://release.debian.org/transitions/html/auto-qhull.html

The API has had a few additions but no incompatible changes or removals since 
2019.1, and all
reverse dependencies build fine on amd64, so I don't expect any trouble.

Cheers
Timo

Bug#962712: please add support for x13as

[Sébastien Villemot]

Package: python3-statsmodels
Version: 0.11.1-2
Severity: wishlist

Dear Maintainers,

statsmodels is able to take advantage of X-13ARIMA-SEATS (a.k.a. x13as) for
performing seasonal adjustment of time series.

x13as is now packaged in Debian (though in the non-free archive area), so it
would be nice if statsmodels could take advantage of it.

At least, a Suggests relationship should be added (note that a Recommends or a
Depends is not possible, since x13as is non-free, see Policy §2.2.1).

I did not investigate whether installing the x13as package is enough to get
support from statsmodels (since x13as will be in the $PATH), or whether
additional modifications are needed.

Best,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org

Bug#962713: please add support for x13as

[Dirk Eddelbuettel]

On 12 June 2020 at 16:38, Riccardo (Jack) Lucchetti wrote:
| On Fri, 12 Jun 2020, Dirk Eddelbuettel wrote:
| 
| > | Quickly looking at the source code of gretl, I am under the impression 
that it
| > | may need to be slightly patched in order to find the x13as executable (it 
seems
| > | to hardcode a Windows .exe path). But I did not really investigate, so I 
leave
| > | that up to you.
| 
| I believe that no adjustment is needed. The .exe path you're referring to 
| is buried within an #if directive, and is only used when cross-compiling 
| for windows. In fact, I just installed the debian x13as package and tried 
| using that from within gretl instead of my home-baked x13as, and it works 
| just fine.

Nice one. That's also what I recall from way back when. I'll add the Suggests.
 
Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#962697: RFS: ace/6.5.8+dfsg-1 [RC] -- makefile, project, and workspace creator

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: important
X-Debbugs-CC: t...@debian.org

Dear mentors,

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

 * Package name: ace
   Version : 6.5.8+dfsg-1
   Upstream Author : Douglas C. Schmidt 
 * URL : https://www.dre.vanderbilt.edu/~schmidt/ACE.html
 * License :
 * Vcs : https://salsa.debian.org/debian/ace
   Section : devel

It builds those binary packages:

  mpc-ace - makefile, project, and workspace creator
  libace-6.5.8 - C++ network programming framework
  libace-dev - C++ network programming framework - development files
  libace-doc - C++ network programming framework - documentation
  libace-ssl-6.5.8 - ACE secure socket layer library
  libace-ssl-dev - ACE secure socket layer library - development files
  libace-rmcast-6.5.8 - ACE reliable multicast library
  libace-rmcast-dev - ACE reliable multicast library - development files
  libace-tmcast-6.5.8 - ACE transactional multicast library
  libace-tmcast-dev - ACE transactional multicast library - development files
  libace-htbp-6.5.8 - ACE protocol over HTTP tunneling library
  libace-htbp-dev - ACE protocol over HTTP tunneling library - development files
  libace-inet-6.5.8 - ACE Inet protocol library
  libace-inet-dev - ACE Inet protocol library - development files
  libace-inet-ssl-6.5.8 - ACE SSL-enabled Inet protocol library
  libace-inet-ssl-dev - ACE SSL-enabled Inet protocol library - development 
files
  ace-gperf - ACE perfect hash function generator
  libacexml-6.5.8 - ACE SAX based XML parsing library
  libacexml-dev - ACE SAX based XML parsing library - development files
  libace-xml-utils-6.5.8 - ACE XML utility classes and methods
  libace-xml-utils-dev - ACE XML utility classes and methods - development files
  libkokyu-6.5.8 - ACE scheduling and dispatching library
  libkokyu-dev - ACE scheduling and dispatching library - development files
  libace-xtreactor-6.5.8 - ACE-GUI reactor integration for Xt
  libace-xtreactor-dev - ACE-GUI reactor integration for Xt - development files
  libace-tkreactor-6.5.8 - ACE-GUI reactor integration for Tk
  libace-tkreactor-dev - ACE-GUI reactor integration for Tk - development files
  libace-flreactor-6.5.8 - ACE-GUI reactor integration for FLTK
  libace-flreactor-dev - ACE-GUI reactor integration for FLTK - development 
files
  libace-foxreactor-6.5.8 - ACE-GUI reactor integration for FOX
  libace-foxreactor-dev - ACE-GUI reactor integration for FOX - development 
files
  ace-netsvcs - ACE network service implementations
  libnetsvcs-6.5.8 - ACE network service implementations - libraries
  libnetsvcs-dev - ACE network service implementations - development files

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/a/ace/ace_6.5.8+dfsg-1.dsc

Changes since the last upload:

   * Team upload.
   * Update to upstream v6.5.8
 - Remove old patches applied upstream.
 - Use debian/* from upstream.
 - Update get-orig-source.sh and repack source.
 - Remove WebSTONE from copyright.
   * Update Standards-Version to 4.5.0
   * Use debhelper-compat.
 - Update compat level to 12.
   * Update debian/rules.
 - Remove --list-missing.
 - Add -g for debug symbols.
 - Stop modifying flags directly.
 - Install shared library in multiarch location.
 - Remove LD_LIBRARY_PATH.
   * Update doc-base location.
   * Remove lintian overrides.
 - for symbols.
 - for debhelper.
   * Update maintainer to valid team email. (Closes: #899440)
   * Update Vcs link to salsa.
   * Update copyright year.
   * Drop transitional package gperf-ace. (Closes: #878198)
   * Fix whitespace in changelog.

Note: The previous RFS was #956907 and ftp-master rejected and noted
missing copyright in:
* apps/JAWS/clients/WebSTONE/src/nsapi_includes/*
* apps/JAWS/clients/WebSTONE/src/rexec.c
* contrib/FaCE/*

Assuming the copyright for "apps/JAWS/clients/WebSTONE/src/nsapi_includes"
meant the one at https://en.wikipedia.org/wiki/Netscape_Public_License
I preferred to remove those files from the repacked source as none of
the files pointed out by ftp-masters are being used.

No other change has been done from the previous upload which ftp-masters
have reviewed.

As before it has been tested with ratt.


-- 
Regards
Sudip

Bug#962700: dnsmasq: Please make another source-only upload to allow testing migration

[Boyuan Yang]

Source: dnsmasq
Version: 2.81-3
Tags: sid  bullseye
Severity: important

Dear Debian dnsmasq maintainer,

The last upload of package dnsmasq in Sid was not a source-only upload. As a
result, this new release will not migrate to Debian Testing.

This also indicates the out-of-sync condition between package in Testing and
package in Sid. According to 
https://lists.debian.org/debian-devel-announce/2020/02/msg5.html , this
bug will be considered as release-critical if the out-of-sync condition lasts
for more than 60 days. Your package has been out-of-sync for 53 days.

Please make another source-only upload to allow testing migration. For details
about source-only upload, please see https://wiki.debian.org/SourceOnlyUpload
. Let me know if you have any questions.

-- 
Regards,
Boyuan Yang


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

Bug#962703: mailplate: Should we remove this package from Debian?

[Boyuan Yang]

Source: mailplate
Version: 0.2-1
Tags: sid  bullseye
Severity: serious
X-Debbugs-CC: madd...@debian.org

Dear Debian mailplate maintainer,

Thank your for maintaining package mailplate in Debian in the past decades.
However as you can see in https://tracker.debian.org/pkg/mailplate , this
package saw no upload in Debian in the last 12 years. Besides, the registered
homepage is now unavailable (403 Forbidden). Now mailplate is affected by
Debian's ongoing effort in removing all python2-related packages [1].

I'm wondering if you are going to work on this package to have it migrated to
Python3 so that it no longer depends on the now-EOL python2. If that cannot be
achieved in the near future, the best choice of dealing this package might be
having it removed for now and re-introduce it later when the migration is
properly done.

For now I will be preparing for the package removal and submit the removal
request 28 days later (on July 10, 2020). Meanwhile if you have any other
thoughts, please let me know asap so that this package can be properly handled
and maintained.

-- 
Best Regards,
Boyuan Yang


[1] https://wiki.debian.org/Python/2Removal


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

Bug#668538: RFP: vdsm -- Virtual Desktop and Server Manager

[Sam Morris]

Followup-For: Bug #668538

Updated URL about building VDSM on Debian:
https://www.ovirt.org/develop/developer-guide/vdsm/on-debian.html

The changeset for debian packaging is here:
https://gerrit.ovirt.org/#/c/49257/

This was merged, but the debian packaging was removed from vdsm Git in
April 2016.

Bug#962708: Please build dummy_hcd and g_mass_storage modules

[Laurent GUERBY]

Package: linux-image-amd64
Severity: wishlist

Hi,

When using the spice protocol one can via usbredir give
the remote guest VM access to a local USB device, all
with a nice UI in spicy or remote-viewer which
allows you to select the local USB device to share.

It would be nice when you have downloaded an ISO file (eg debian ISO)
not to have to dd it to a real USB device in order
to then make it available to the VM via spice.

It should be doable virtually without a real device 
using dummy_hcd and g_mass_storage kernel modules according to:

https://unix.stackexchange.com/questions/373569/emulating-usb-device-with-a-file-using-g-mass-storage-udc-core-couldnt-find

However those two modules are not packaged in stable 4.19 kernel:

# modprobe dummy_hcd
modprobe: FATAL: Module dummy_hcd not found in directory
/lib/modules/4.19.0-8-amd64
# modprobe g_mass_storage
modprobe: FATAL: Module g_mass_storage not found in directory
/lib/modules/4.19.0-8-amd64

Note: this was requested a while ago but with another
use in mind which had a better solution for the user:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678731

Thanks in advance for your help,

Sincerely,

Laurent GUERBY

Bug#962710: libedit2: undocumented change to upstream's SONAME

[Simon McVittie]

Package: libedit2
Version: 3.1-20191231-1
Severity: normal

While working with the Steam Runtime, a partial library stack for
third-party binary software, I noticed that ldconfig considers modern
Debian's libedit2 3.x to be older than libedit2 2.x. If both are in the
library search path, this results in 2.x being selected in preference
to 3.x, breaking binaries that expect the full ABI of 3.x.

Investigating this led me to
https://salsa.debian.org/debian/libedit/-/blob/master/debian/patches/update-soname.diff
which changes the SONAME from upstream's libedit.so.0 to a Debian-specific
libedit.so.2, without documenting why. The reason also doesn't seem to
be documented in d/changelog.

Looking back through the git history, it seems that the reason is: back in
2013, at the transition from 2.x to 3.x, upstream switched from a
pmake-based build system to Autotools, and the SONAME moved from
libedit.so.2 to libedit.so.0 at this point. To avoid needing to rebuild
existing libedit-dependent projects, the Debian package started patching
the build system.

The version comparison order problem that I noticed is because the Steam
Runtime (Ubuntu 12.04-derived) libedit.so.2 version 2.11 is implemented
by libedit.so.2.11, whereas modern Debian's libedit.so.2 version 3.x
is implemented by libedit.so.2.0.63, which compares less than 2.11 in
strverscmp() order.

Debian-specific SONAMEs are a problematic pattern: we used to have
more tolerance for them than we do now, but these days I believe it
is considered best-practice for SONAME changes (and ABI management
in general) to happen "upstream first". For example, libcurl diverged
from its upstream in 2007 and only reconverged in 2018, with a lot of
confusion in between (see #858398 for some history), while libpcre 3.x
is still diverged and periodically causing confusion.

Whatever else happens or doesn't happen, if the libedit.so.0 SONAME is
not used, it would be very helpful for the packaging to document why
this happened, perhaps in https://dep-team.pages.debian.net/deps/dep3/
format.

Ideally, I think libedit should transition to its upstream SONAME,
libedit.so.0 (which is how it is shipped in non-Debian-derived
distributions), in a new libedit0 binary package. This would be a
transition which would need to be coordinated with the release team,
but would make future Debian releases more compatible with the rest
of the GNU/Linux world. Because the actual symbols exported are the
same as upstream's, this could be made a "soft" transition by having a
transitional libedit2 package containing a symbolic link
libedit.so.2 -> libedit.so.0, if desired: that way, newly-compiled
packages would depend on libedit0, but existing binary packages that have
DT_NEEDED: libedit.so.2 and Depends: libedit2 would continue to work.

The next best thing, if the libedit.so.0 name is unsuitable for some
reason that I'm not seeing, would be to use an obviously-Debian-specific
SONAME, for example libedit.so.2d. Again, that would be a transition
that would need to be coordinated, but could have a transitional package
to make it a "soft" transition.

The best option that I can see to reinstate the "newer-than" property
(from ldconfig's perspective) *without* a transition would be to
increase the minor (second) version in the name of the library, for
example by bumping both the libtool "current" and "age" fields. Setting
the libtool current:revision:age to, for example, 102:63:100 would
result in libedit.so.2 -> libedit.so.2.100.63, which compares newer
than libedit.so.2.11. The choice of 100 here is entirely arbitrary, and
something like 31 or 3001000 that suggests the version number would be
equally valid.

Thanks,
smcv

Bug#962715: Incompatible API versions: encoded with [1,17,5,4] but attempted to decode with [1,20]

[Eric Marsden]

Package: pandoc-sidenote
Version: 0.20.0-1

When invoking pandoc-sidenote as a pandoc filter, it generates an error 
related to "incompatible API versions".


   % pandoc --filter pandoc-sidenote -o /tmp/foo.html foo.md
   pandoc-sidenote: Error in $: Incompatible API versions: encoded with 
[1,17,5,4] but attempted to decode with [1,20].

   CallStack (from HasCallStack):
    error, called at ./Text/Pandoc/JSON.hs:107:64 in 
pandoc-types-1.20-Ip2ZGM2tgGt4TDYVgvP7zF:Text.Pandoc.JSON

   Error running filter pandoc-sidenote:
   Filter returned error status 1


Architecture is amd64. Pandoc version is 2.5-3+b1. Reverting to the 
previous version 0.19.0.0-2+b4 works fine.

Bug#959613: range-v3: FTBFS: unique.cpp:58:10: internal compiler error: in dependent_type_p, at cp/pt.c:25610

[Nicholas Guriev]

reassign 959613 g++-9
fixed 959613 9.3.0-10
found 959613 9.3.0-11
found 959613 9.3.0-13
severity 959613 important
affects 959613 src:range-v3
stop

Dear GCC maintainer, could you please take a little look at this
compiler crash? The regression is appearing since GCC 9.3.0-11 uploaded
on April 24 through 9.3.0-13, while with 9.3.0-10 the ragne-v3 package
is built with no trouble.

Bug#962698: python-pauvre: FTBFS if the "DISPLAY" environment variable is exported

[Chris Lamb]

Package: python-pauvre
Version: 0.2.2-1
Severity: important

Hi,

python-pauvre FTBFS if the "DISPLAY" environment variable is exported:

 Traceback (most recent call last):
   File 
"/home/lamby/temp/cdt.20200612115324.KT7RjF0aGh.repro.python-pauvre/build-a/python-pauvre-0.2.2/.pybuild/cpython3_3.8_pauvre/build/pauvre/pauvre_main.py",
 line 636, in 
 main()
   File 
"/home/lamby/temp/cdt.20200612115324.KT7RjF0aGh.repro.python-pauvre/build-a/python-pauvre-0.2.2/.pybuild/cpython3_3.8_pauvre/build/pauvre/pauvre_main.py",
 line 630, in main
 args.func(parser, args)
   File 
"/home/lamby/temp/cdt.20200612115324.KT7RjF0aGh.repro.python-pauvre/build-a/python-pauvre-0.2.2/.pybuild/cpython3_3.8_pauvre/build/pauvre/pauvre_main.py",
 line 62, in run_subtool
 import pauvre.synplot as submodule
   File 
"/home/lamby/temp/cdt.20200612115324.KT7RjF0aGh.repro.python-pauvre/build-a/python-pauvre-0.2.2/.pybuild/cpython3_3.8_pauvre/build/pauvre/synplot.py",
 line 32, in 
 from pauvre.functions import GFFParse, print_images, timestamp
   File 
"/home/lamby/temp/cdt.20200612115324.KT7RjF0aGh.repro.python-pauvre/build-a/python-pauvre-0.2.2/.pybuild/cpython3_3.8_pauvre/build/pauvre/functions.py",
 line 25, in 
 import matplotlib.pyplot as plt
   File "/usr/lib/python3/dist-packages/matplotlib/pyplot.py", line 2282, in 

 switch_backend(rcParams["backend"])
   File "/usr/lib/python3/dist-packages/matplotlib/pyplot.py", line 221, in 
switch_backend
 backend_mod = importlib.import_module(backend_name)
   File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
 return _bootstrap._gcd_import(name[level:], package, level)
   File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_tkagg.py", 
line 1, in 
 from . import _backend_tk
   File "/usr/lib/python3/dist-packages/matplotlib/backends/_backend_tk.py", 
line 6, in 
 import tkinter as tk
 ModuleNotFoundError: No module named 'tkinter'
 FAIL

 ==
 FAIL: test_normal_plotting_scenario 
(pauvre.tests.test_synplot.libSeq_test_case)
 This verifies that the LibSeq class is constructed with all of the
 --
 Traceback (most recent call last):
   File 
"/home/lamby/temp/cdt.20200612115324.KT7RjF0aGh.repro.python-pauvre/build-a/python-pauvre-0.2.2/.pybuild/cpython3_3.8_pauvre/build/pauvre/tests/test_synplot.py",
 line 66, in test_normal_plotting_scenario
 self.assertEqual(0, int(data.returncode))
 AssertionError: 0 != 1

 --
 Ran 1 test in 0.777


I assume it is trying to run optional GUI tests and failing.


Regards,

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

Bug#962697: RFS: ace/6.5.8+dfsg-1 [RC] -- makefile, project, and workspace creator

[Tobias Frost]

Hi Sudip,

thanks for the update. Looks good, but before uploading:
Is there a reason not to package 6.5.9?

For future uploads there are a few modernization possiblities,
like please check whether get-orig.sh be replaced by using
Files-Excluded; please check if you decide to package 6.5.9.

Maybe d/rules could be refactored as some of
the bits are probably standard in newer debhelper now, like
the hardening and the manual configure target. Did not check
if it makes sense, but would be cool if you could take a look
or at least put it on your To-Do list.

Cheers,
-- 
tobi


On Fri, Jun 12, 2020 at 11:35:35AM +0100, Sudip Mukherjee wrote:
> Package: sponsorship-requests
> Severity: important
> X-Debbugs-CC: t...@debian.org
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "ace"
> 
>  * Package name: ace
>Version : 6.5.8+dfsg-1
>Upstream Author : Douglas C. Schmidt 
>  * URL : https://www.dre.vanderbilt.edu/~schmidt/ACE.html
>  * License :
>  * Vcs : https://salsa.debian.org/debian/ace
>Section : devel
> 
> It builds those binary packages:
> 
>   mpc-ace - makefile, project, and workspace creator
>   libace-6.5.8 - C++ network programming framework
>   libace-dev - C++ network programming framework - development files
>   libace-doc - C++ network programming framework - documentation
>   libace-ssl-6.5.8 - ACE secure socket layer library
>   libace-ssl-dev - ACE secure socket layer library - development files
>   libace-rmcast-6.5.8 - ACE reliable multicast library
>   libace-rmcast-dev - ACE reliable multicast library - development files
>   libace-tmcast-6.5.8 - ACE transactional multicast library
>   libace-tmcast-dev - ACE transactional multicast library - development files
>   libace-htbp-6.5.8 - ACE protocol over HTTP tunneling library
>   libace-htbp-dev - ACE protocol over HTTP tunneling library - development 
> files
>   libace-inet-6.5.8 - ACE Inet protocol library
>   libace-inet-dev - ACE Inet protocol library - development files
>   libace-inet-ssl-6.5.8 - ACE SSL-enabled Inet protocol library
>   libace-inet-ssl-dev - ACE SSL-enabled Inet protocol library - development 
> files
>   ace-gperf - ACE perfect hash function generator
>   libacexml-6.5.8 - ACE SAX based XML parsing library
>   libacexml-dev - ACE SAX based XML parsing library - development files
>   libace-xml-utils-6.5.8 - ACE XML utility classes and methods
>   libace-xml-utils-dev - ACE XML utility classes and methods - development 
> files
>   libkokyu-6.5.8 - ACE scheduling and dispatching library
>   libkokyu-dev - ACE scheduling and dispatching library - development files
>   libace-xtreactor-6.5.8 - ACE-GUI reactor integration for Xt
>   libace-xtreactor-dev - ACE-GUI reactor integration for Xt - development 
> files
>   libace-tkreactor-6.5.8 - ACE-GUI reactor integration for Tk
>   libace-tkreactor-dev - ACE-GUI reactor integration for Tk - development 
> files
>   libace-flreactor-6.5.8 - ACE-GUI reactor integration for FLTK
  >   libace-flreactor-dev - ACE-GUI reactor integration for FLTK - development 
files
>   libace-foxreactor-6.5.8 - ACE-GUI reactor integration for FOX
>   libace-foxreactor-dev - ACE-GUI reactor integration for FOX - development 
> files
>   ace-netsvcs - ACE network service implementations
>   libnetsvcs-6.5.8 - ACE network service implementations - libraries
>   libnetsvcs-dev - ACE network service implementations - development files
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/ace
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/a/ace/ace_6.5.8+dfsg-1.dsc
> 
> Changes since the last upload:
> 
>* Team upload.
>* Update to upstream v6.5.8
>  - Remove old patches applied upstream.
>  - Use debian/* from upstream.
>  - Update get-orig-source.sh and repack source.
>  - Remove WebSTONE from copyright.
>* Update Standards-Version to 4.5.0
>* Use debhelper-compat.
>  - Update compat level to 12.
>* Update debian/rules.
>  - Remove --list-missing.
>  - Add -g for debug symbols.
>  - Stop modifying flags directly.
>  - Install shared library in multiarch location.
>  - Remove LD_LIBRARY_PATH.
>* Update doc-base location.
>* Remove lintian overrides.
>  - for symbols.
>  - for debhelper.
>* Update maintainer to valid team email. (Closes: #899440)
>* Update Vcs link to salsa.
>* Update copyright year.
>* Drop transitional package gperf-ace. (Closes: #878198)
>* Fix whitespace in changelog.
> 
> Note: The previous RFS was #956907 and ftp-master rejected and noted
> missing copyright in:
> * apps/JAWS/clients/WebSTONE/src/nsapi_includes/*
> * apps/JAWS/clients/WebSTONE/src/rexec.c
> * contrib/FaCE/*
> 
> Assuming the copyright for 

Bug#953908: sinntp: diff for NMU version 1.6-1.1

[Marcelo Mota]

Control: tags 953908 + patch
Control: tags 953908 + pending

Dear maintainer,

I've prepared an NMU for sinntp (versioned as 1.6-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer or cancel the NMU.

Regards,

Marcelo S Mota

diff -Nru sinntp-1.6/debian/changelog sinntp-1.6/debian/changelog
--- sinntp-1.6/debian/changelog 2020-01-12 09:45:54.0 -0300
+++ sinntp-1.6/debian/changelog 2020-06-11 14:29:16.0 -0300
@@ -1,3 +1,11 @@
+sinntp (1.6-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/tests/control: added restriction to fix CI test. Thanks to
+Paul Gevers . (Closes: #953908)
+
+ -- Marcelo Soares Mota   Thu, 11 Jun 2020 14:29:16 
-0300
+
 sinntp (1.6-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru sinntp-1.6/debian/tests/control sinntp-1.6/debian/tests/control
--- sinntp-1.6/debian/tests/control 2020-01-12 09:42:05.0 -0300
+++ sinntp-1.6/debian/tests/control 2020-06-11 14:29:16.0 -0300
@@ -1 +1,2 @@
 Tests: tests
+Restrictions: allow-stderr

Bug#962697: RFS: ace/6.5.8+dfsg-1 [RC] -- makefile, project, and workspace creator

[Sudip Mukherjee]

Hi Tobi,

On Fri, Jun 12, 2020 at 12:25 PM Tobias Frost  wrote:
>
> Hi Sudip,
>
> thanks for the update. Looks good, but before uploading:
> Is there a reason not to package 6.5.9?

Only reason is that ftp-masters have already reviewed 6.5.8 and so I
think it becomes easier for them if we upload the same version again
with only the changes they have pointed out. Atleast, thats what I
realized from the past uploads.

>
> For future uploads there are a few modernization possiblities,
> like please check whether get-orig.sh be replaced by using
> Files-Excluded; please check if you decide to package 6.5.9.

I thought about that, but didn't wanted to change it now. Will do it
definitely for the next upload.

>
> Maybe d/rules could be refactored as some of
> the bits are probably standard in newer debhelper now, like
> the hardening and the manual configure target. Did not check
> if it makes sense, but would be cool if you could take a look
> or at least put it on your To-Do list.

Yes. I will also move to compat level 13 and at the same time rework on d/rules.


-- 
Regards
Sudip

Bug#962705: shanty: Consider rebuilding the package for reproducibility-builds project goal

[Boyuan Yang]

Package: shanty
Version: 3-4
Severity: minor
Tags: sid

Dear Debian shanty maintainer,

As part of the goal in the reproducible-builds project [1], it is recommended
that all packages built before 2014 to be rebuilt against current toolchain to
gain necessary changes for it to be analyzed by the reproducible-builds
project.

Your binary package is of Architecture:all and was built on 2008. Could you
please consider revising the packaging and rebuild the package via another
upload (ideally source-only upload [2])?

[1] https://wiki.debian.org/ReproducibleBuilds 
[2] https://wiki.debian.org/SourceOnlyUpload

-- 
Regards,
Boyuan Yang


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

Bug#960073: Package:python-pyqt5 Run the example code with Trace and crash (SIGABRT)

[Dmitry Shachnev]

Hi!

On Thu, Jun 11, 2020 at 02:57:22PM +0800, pengzon...@uniontech.com wrote:
> Hi!
>
> Sorry for my late reply.
> I tried to exporting QT_XCB_GL_INTEGRATION=xcb_egl  and it still reported
> an error. libglvnd-dev  package was originally installed.

I have never seen this issue, so it's hard to tell anything about it.

I may suggest you to try debugging further and try to find out why Python
and C++ programs behave differently.

Also, you may try to contact upstream PyQt [1] or Qt [2].

[1]: https://www.riverbankcomputing.com/mailman/listinfo/pyqt
[2]: https://bugreports.qt.io/

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#931785: GoodMorning, I have been looking for a way to reach you, hope its the right email?

[Jason Donnelly]

Bug#962709: chromium: + arrow does not stop on period characters

[Eyal Zekaria]

Package: chromium
Version: 81.0.4044.92-1
Severity: normal

Dear Maintainer,

Anywhere within the chromium browser, whether it's the address bar or any text 
input area within, holding down CTRL while pressing the left/right directional 
arrows does not stop on a period character.
For example, enter the following in the address bar: `foo.bar.baz` and then 
attempt to skip words using CTRL+left/right. The cursor will skip from the 
beginning of the address to the end without stopping before/after any of the 
period separated words. The expected behavior is the cursor stopping 
before/after each of the words, the same way it does when they are separated by 
`/` characters.
Upstream chromium browser is not affected 
(https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Linux_x64/737173/),
 so I suppose the problem is with the debian package.

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

Kernel: Linux 5.6.0-2-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 chromium depends on:
ii  chromium-common  81.0.4044.92-1
ii  libasound2   1.2.2-2.1
ii  libatk-bridge2.0-0   2.34.1-3
ii  libatk1.0-0  2.36.0-2
ii  libatspi2.0-02.36.0-2
ii  libavcodec58 7:4.2.2-1+b1
ii  libavformat587:4.2.2-1+b1
ii  libavutil56  7:4.2.2-1+b1
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libcups2 2.3.3-1
ii  libdbus-1-3  1.12.18-1
ii  libdrm2  2.4.101-2
ii  libevent-2.1-7   2.1.11-stable-1
ii  libexpat12.2.9-1
ii  libflac8 1.3.3-1
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.1-2
ii  libgbm1  20.0.7-1
ii  libgcc-s110.1.0-3
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.64.3-1
ii  libgtk-3-0   3.24.20-1
ii  libharfbuzz0b2.6.4-1+b1
ii  libicu63 63.2-3
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3.1
ii  liblcms2-2   2.9-4+b1
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.25-1
ii  libnss3  2:3.53-1
ii  libopenjp2-7 2.3.1-1
ii  libopus0 1.3-1+b1
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libpng16-16  1.6.37-2
ii  libpulse013.0-5
ii  libre2-6 20200401+dfsg-1
ii  libsnappy1v5 1.1.8-1
ii  libstdc++6   10.1.0-3
ii  libvpx6  1.8.2-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.6.9-2+b1
ii  libx11-xcb1  2:1.6.9-2+b1
ii  libxcb-dri3-01.14-2
ii  libxcb1  1.14-2
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-2
ii  libxi6   2:1.7.10-1
ii  libxml2  2.9.10+dfsg-5+b1
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.34-4
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages chromium recommends:
ii  chromium-sandbox  81.0.4044.92-1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+5
ii  xdg-utils  1.1.3-2

Versions of packages chromium-common recommends:
ii  chromium-sandbox   81.0.4044.92-1
ii  fonts-liberation   1:1.07.4-11
ii  gnome-shell [notification-daemon]  3.36.3-1
ii  libgl1-mesa-dri20.0.7-1
ii  libu2f-udev1.1.10-1
ii  notification-daemon3.20.0-4
ii  system-config-printer  1.5.12-1
ii  upower 0.99.11-2

Versions of packages chromium-sandbox depends on:
ii  libc6  2.30-8

-- no debconf information

Bug#962713: please add support for x13as

[Riccardo (Jack) Lucchetti]

On Fri, 12 Jun 2020, Dirk Eddelbuettel wrote:


| Quickly looking at the source code of gretl, I am under the impression that it
| may need to be slightly patched in order to find the x13as executable (it 
seems
| to hardcode a Windows .exe path). But I did not really investigate, so I leave
| that up to you.


I believe that no adjustment is needed. The .exe path you're referring to 
is buried within an #if directive, and is only used when cross-compiling 
for windows. In fact, I just installed the debian x13as package and tried 
using that from within gretl instead of my home-baked x13as, and it works 
just fine.


 ---
  Riccardo (Jack) Lucchetti
  Dipartimento di Scienze Economiche e Sociali (DiSES)

  Università Politecnica delle Marche
  (formerly known as Università di Ancona)

  r.lucche...@univpm.it
  http://www2.econ.univpm.it/servizi/hpp/lucchetti
---

Bug#962693: [debian-mysql] Bug#962693: mariadb-server-core-10.3: Recovery failure : loop of Read redo log up to LSN (MDEV-21826)

[Otto Kekäläinen]

Hello!

There are currently no stable point updates planned
(https://release.debian.org/) but once there is one, it will have the
latest MariaDB point release available at that time.

Thanks for reporting this issue, so we can track it.

Bug#961228: the b1 build does not resolve the problem

[Eric Valette]

Try launching experimental digikam on a console and see the unresolved 
that comme when loading libopencv-imgcodecs4.2 ...


--eric

Bug#962274: libcamera-dev: cannot compile a trivial program against libcamera

[Simon McVittie]

Control: tags -1 - patch

On Thu, 11 Jun 2020 at 10:29:36 +0100, Simon McVittie wrote:
> On Fri, 05 Jun 2020 at 14:01:47 +0100, Simon McVittie wrote:
> > I would expect that either libcamera headers should be installed in
> > /usr/include/libcamera/*.h, or `pkg-config --cflags camera` should print
> > "-I/usr/include/libcamera".
> 
> This appears to be fixed in:
> https://git.linuxtv.org/libcamera.git/commit/?id=56ff904915ed264c3b9625a38cbdddb77411c431

This part is indeed fixed in 0~git20200513+924778e-1.1.

On Thu, 11 Jun 2020 at 10:38:39 +0100, Simon McVittie wrote:
> On Fri, 05 Jun 2020 at 16:15:03 +0100, Simon McVittie wrote:
> > I tried to do the equivalent of this, and in addition to the missing
> > -I/usr/include/libcamera, there seems to be a missing dependency on
> > something (I don't know what) that provides 
> 
> This seems to be to do with differences in how Debian and other
> distributions package libdrm - in Ubuntu and Gentoo it includes
> , but in Debian and Arch it doesn't.
> 
> A fix appears to be in progress in this thread:
> https://lists.libcamera.org/pipermail/libcamera-devel/2020-June/009338.html

This is not yet fixed in current unstable.

If there is no workaround for this, then this bug should probably be RC.

smcv

Bug#962699: sec: Please make another source-only upload to allow testing migration

[Boyuan Yang]

Source: sec
Version: 2.8.3-1
Severity: important
Tags: sid  bullseye

Dear Debian sec maintainer,

The last upload of package sec in Debian was not a source-only upload. As a
result, the new version 2.8.3-1 will not migrate to Testing.

Please make another source-only upload to allow testing migration. For details
about source-only upload, please see https://wiki.debian.org/SourceOnlyUpload
.

-- 
Regards,
Boyuan Yang


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

Bug#962702: python-pauvre: please make the build reproducible

[Chris Lamb]

Source: python-pauvre
Version: 0.2.2-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

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

This is because it included a generated PDF in the tests which, as it
happens, had a filename based on the current timestamp.

Patch attached that simply doesn't ship this PDF in the binary package
as it's likely not very useful at runtime (and if it is useful it will
be missing if the tests are not run as part of the build).


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


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   ` a/debian/rules  2020-06-12 11:53:25.309309926 +0100
--- b/debian/rules  2020-06-12 12:06:42.779552457 +0100
@@ -7,6 +7,9 @@
 %:
dh $@ --with python3 --buildsystem=pybuild
 
+execute_after_dh_auto_install:
+   find debian/ -type d -name 'testresults' -print0 | xargs -0r rm -rf
+
 override_dh_auto_test:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
PYBUILDDIR="$$(echo "$(CURDIR)"/.pybuild/cpython3_3.*/build)" \

Bug#949664: libassuan: diff for NMU version 2.5.3-7.1

[Filipi Souza]

Control: tags 949664 + pending

Dear maintainer,

I've prepared an NMU for libassuan (versioned as 2.5.3-7.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Filipi Souza


diff -Nru libassuan-2.5.3/debian/changelog libassuan-
2.5.3/debian/changelog
--- libassuan-2.5.3/debian/changelog2019-07-17 12:09:10.0
-0300
+++ libassuan-2.5.3/debian/changelog2020-06-10 06:57:10.0
-0300
@@ -1,3 +1,12 @@
+libassuan (2.5.3-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/tests/build-windows: updated to fix testsuite flags being
+  incorrectly passed and to skip a test fail on arch arm64. Thanks
+  Gianfranco Costamagna. (Closes: #949664)
+
+ -- Filipi Souza   Wed, 10 Jun 2020 06:57:10
-0300
+
 libassuan (2.5.3-7) unstable; urgency=medium
 
   * export CPPFLAGS_FOR_BUILD as well
diff -Nru libassuan-2.5.3/debian/tests/build-windows libassuan-
2.5.3/debian/tests/build-windows
--- libassuan-2.5.3/debian/tests/build-windows  2019-07-16
14:49:54.0 -0300
+++ libassuan-2.5.3/debian/tests/build-windows  2020-06-10
06:57:10.0 -0300
@@ -2,35 +2,35 @@
 
 set -e
 
-ARCH=$1
+ARCH="$1"
 
 if [ "$ARCH" = x86_64 ]; then
-GCC=x86_64-w64-mingw32-gcc
 WINE=/usr/lib/wine/wine64
 export WINESERVER=/usr/lib/wine/wineserver64
 elif [ "$ARCH" = i686 ]; then
-GCC=i686-w64-mingw32-gcc
 WINE=/usr/lib/wine/wine
 export WINESERVER=/usr/lib/wine/wineserver32
 else
 printf >&2 'Unknown Architecture: %s\n' "$ARCH"
 exit 1
 fi
+GCC="${ARCH}-w64-mingw32-gcc"
 
 # get wine initialized, which normally spews logs to stderr
 # (autopkgtest doesn't want stderr)
 "$WINE" hostname 2>&1
 
-export PKG_CONFIG_PATH=/usr/x86_64-w64-mingw32/lib/pkgconfig
+if [ `dpkg --print-architecture` = 'arm64' ] ; then
+  echo "Don't fail testsuite on arm64, this test always failed there"
+  exit 0
+fi
 
-# see https://dev.gnupg.org/T4624 for why this is needed
-extralibs=(-lws2_32)
+export PKG_CONFIG_PATH="/usr/${ARCH}-w64-mingw32/lib/pkgconfig"
 
-"$GCC" -pedantic -Wall -Werror -o test-run.exe \
-   -static \
-   -Wl,--no-as-needed \
-   debian/tests/simple-build.c \
-   $(pkg-config --static --cflags --libs libassuan)
"${extralibs[@]}"
+# see https://dev.gnupg.org/T4624 for why this is needed
+extra_libs=(-lws2_32)
 
+# build a static windows binary around libassuan and run it:
+"$GCC" -pedantic -Wall -Werror -static -o test-run.exe
debian/tests/simple-build.c $(pkg-config --cflags --static --libs
libassuan) "${extra_libs[@]}"
 "$WINE" ./test-run.exe
-rm -f test-run.exe
+rm -f ./test-run.exe

Bug#962669: Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1

[Adrian Bunk]

On Fri, Jun 12, 2020 at 08:40:29AM +0100, Adam D. Barratt wrote:
> On Fri, 2020-06-12 at 00:50 +0300, Adrian Bunk wrote:
> > Control: tags 962669 moreinfo
> > 
> > On Thu, Jun 11, 2020 at 08:18:38PM +0100, Adam D. Barratt wrote:
> > > On Thu, 2020-06-11 at 13:48 -0500, Michael Shuler wrote:
> > > > On 6/11/20 1:33 PM, Adam D. Barratt wrote:
> > > > > Just to confirm - will the certificates be automatically re-
> > > > > added (assuming that users have either the automatically trust
> > > > > or prompt options enabled)?
> > > > 
> > > > (stretch-pu report cc'ed, since same applies)
> > > > 
> > > > Excellent question. I believe we're going to hit #743339
> > > > "Previously removed certificates not added again". I had not
> > > > found a reasonable fix for that case in general, to preserve a
> > > > user's selections.
> > > > Maybe a "good enough" fix will have to do for the specific ones
> > > > added back.
> > > 
> > > OK.
> > > 
> > > In that case, how does this seem as an SUA text?
> [...]
> > > use the affected certificates, you may need to manually enable them
> > > by running "dpkg-reconfigure ca-certificates" as root.
> > > 
> > 
> > This does not work in various embedded scenarios.
> 
> Wouldn't embedded setups be more likely to have a hard-coded
> configuration?

The official way to hardcode CA configuration would be through debconf 
or /etc/ca-certificates.conf, which runs into #743339.

If you are really security-focussed you might pin the actual certificate 
instead of trusing a CA.

For the average embedded device the only thing that matters about 
ca-certificates is something like "https works".

> > Would it work to force-enable them in /etc/ca-certificates.conf
> > from the preinst when upgrading from old-version matching 20200601* ?

This could actually be done in the postinst before the debconf 
configuration, something like
  sed -i "s|^\!mozilla/GeoTrust_Global_CA.crt|mozilla/GeoTrust_Global_CA.crt|" 
/etc/ca-certificates.conf
for all affected certificates when $2 matches 20200601*

> I'll leave the technical answer to Michael.
> 
> Practically, it's then not great for users who had intentionally
> removed the certificates - or simply decided not to trust them in the
> first place - prior to the upgrade. I'm not sure how we could
> distinguish the cases automatically.

The default is to trust all new certificates, so this is what the vast
majority of users are using.

#743339 is primarily about this kind of remove+readd in the package 
being the only way how any installed certificate could end up being 
deactivated in the default situation.

This is permanent damage that can lead to nasty problems months or
years later.

There are likely some users somewhere who have manually activated or 
deactivated these specific certificates, but this is nothing we can 
handle correctly in both directions now.

> > Unrelated to that, please keep the Python 2 -> 3 build dependency
> > change out of this emergency update.
> 
> ACK.
> 
> Regards,
> 
> Adam

cu
Adrian

Bug#953554: Please permit Debian revisions with 1.0 native packages

[Ian Jackson]

Felix Lechner writes ("Re: Bug#953554: Please permit Debian revisions with 1.0 
native packages"):
> For now, I will reduce the tag's severity to a warning
> like you asked.

Thank you.  I think for 1.0 packages that warning should remain,
because the lack of explicitness means that it is easy to do this by
mistake.  The maintainer can override it if it's deliberate.

For non-1.0 packages I think the warning should be removed but from
lintian's pov I can see that that would be blocked by the policy
debate.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#949664: libassuan: diff for NMU version 2.5.3-7.1

[Filipi Souza]

Dear maintainer,

I've prepared an NMU for libassuan (versioned as 2.5.3-7.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.


Regards,
Filipi Souza
diff -Nru libassuan-2.5.3/debian/changelog libassuan-2.5.3/debian/changelog
--- libassuan-2.5.3/debian/changelog	2019-07-17 12:09:10.0 -0300
+++ libassuan-2.5.3/debian/changelog	2020-06-10 06:57:10.0 -0300
@@ -1,3 +1,12 @@
+libassuan (2.5.3-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/tests/build-windows: updated to fix testsuite flags being
+  incorrectly passed and to skip a test fail on arch arm64. Thanks
+  Gianfranco Costamagna. (Closes: #949664)
+
+ -- Filipi Souza   Wed, 10 Jun 2020 06:57:10 -0300
+
 libassuan (2.5.3-7) unstable; urgency=medium
 
   * export CPPFLAGS_FOR_BUILD as well
diff -Nru libassuan-2.5.3/debian/tests/build-windows libassuan-2.5.3/debian/tests/build-windows
--- libassuan-2.5.3/debian/tests/build-windows	2019-07-16 14:49:54.0 -0300
+++ libassuan-2.5.3/debian/tests/build-windows	2020-06-10 06:57:10.0 -0300
@@ -2,35 +2,35 @@
 
 set -e
 
-ARCH=$1
+ARCH="$1"
 
 if [ "$ARCH" = x86_64 ]; then
-GCC=x86_64-w64-mingw32-gcc
 WINE=/usr/lib/wine/wine64
 export WINESERVER=/usr/lib/wine/wineserver64
 elif [ "$ARCH" = i686 ]; then
-GCC=i686-w64-mingw32-gcc
 WINE=/usr/lib/wine/wine
 export WINESERVER=/usr/lib/wine/wineserver32
 else
 printf >&2 'Unknown Architecture: %s\n' "$ARCH"
 exit 1
 fi
+GCC="${ARCH}-w64-mingw32-gcc"
 
 # get wine initialized, which normally spews logs to stderr
 # (autopkgtest doesn't want stderr)
 "$WINE" hostname 2>&1
 
-export PKG_CONFIG_PATH=/usr/x86_64-w64-mingw32/lib/pkgconfig
+if [ `dpkg --print-architecture` = 'arm64' ] ; then
+  echo "Don't fail testsuite on arm64, this test always failed there"
+  exit 0
+fi
 
-# see https://dev.gnupg.org/T4624 for why this is needed
-extralibs=(-lws2_32)
+export PKG_CONFIG_PATH="/usr/${ARCH}-w64-mingw32/lib/pkgconfig"
 
-"$GCC" -pedantic -Wall -Werror -o test-run.exe \
-   -static \
-   -Wl,--no-as-needed \
-   debian/tests/simple-build.c \
-   $(pkg-config --static --cflags --libs libassuan) "${extralibs[@]}"
+# see https://dev.gnupg.org/T4624 for why this is needed
+extra_libs=(-lws2_32)
 
+# build a static windows binary around libassuan and run it:
+"$GCC" -pedantic -Wall -Werror -static -o test-run.exe debian/tests/simple-build.c $(pkg-config --cflags --static --libs libassuan) "${extra_libs[@]}"
 "$WINE" ./test-run.exe
-rm -f test-run.exe
+rm -f ./test-run.exe

Bug#962704: shanty: Upstream homepage is now defunct

[Boyuan Yang]

Source: shanty
Version: 3-4
Severity: normal

Dear Debian shanty maintainer,

The homepage of package shanty (
http://www.codebunny.org/coding/shanty/index.html) now returns a 404 not found
result. Could you please review the upstream status and see whether there is
another valid upstream location?

Thanks,
Boyuan Yang


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

Bug#962624: libsrt1-openssl: missing Breaks+Replaces

[Gianfranco Costamagna]

control: tags -1 patch
(patch uploaded in Ubuntu)

--- srt-1.4.1/debian/changelog  2020-06-10 21:33:17.0 +0200
+++ srt-1.4.1/debian/changelog  2020-06-12 13:10:33.0 +0200
@@ -1,3 +1,9 @@
+srt (1.4.1-3.1) unstable; urgency=medium
+
+  * Add breaks/replaces to ease upgrades (Closes: #962624)
+
+ -- Gianfranco Costamagna   Fri, 12 Jun 2020 
13:10:33 +0200
+
 srt (1.4.1-3) unstable; urgency=medium
 
   [ Jonas Smedegaard ]
diff -Nru srt-1.4.1/debian/control srt-1.4.1/debian/control
--- srt-1.4.1/debian/control2020-06-10 21:33:17.0 +0200
+++ srt-1.4.1/debian/control2020-06-12 13:10:33.0 +0200
@@ -18,9 +18,11 @@
 
 Package: libsrt1-openssl
 Architecture: any
+Breaks: libsrt1 (<< 1.4.1-3)
+Replaces: libsrt1 (<< 1.4.1-3)
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Conflicts: libsrt1-gnutls
+Conflicts: libsrt1-gnutls, libsrt1
 Description: Secure Reliable Transport UDP streaming library (OpenSSL flavour)
  SRT is a latency-aware UDP transport mechanism optimized for video streams.
  It detects and compensates for jitter and bandwidth fluctuations due to
@@ -32,7 +34,7 @@
 Architecture: any
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Conflicts: libsrt1-openssl
+Conflicts: libsrt1-openssl, libsrt1
 Description: Secure Reliable Transport UDP streaming library (GnuTLS flavour)
  SRT is a latency-aware UDP transport mechanism optimized for video streams.
  It detects and compensates for jitter and bandwidth fluctuations due to
@@ -42,9 +44,11 @@
 
 Package: libsrt-openssl-dev
 Section: libdevel
+Breaks: libsrt-dev (<< 1.4.1-2)
+Replaces: libsrt-dev (<< 1.4.1-2)
 Architecture: any
 Multi-Arch: same
-Conflicts: libsrt-gnutls-dev
+Conflicts: libsrt-gnutls-dev, libsrt-dev
 Depends: libsrt1-openssl (= ${binary:Version}), ${misc:Depends}
 Suggests: libsrt-doc (= ${binary:Version}), libssl-dev (>= 1.1)
 Description: Secure Reliable Transport UDP streaming library
@@ -57,9 +61,11 @@
 
 Package: libsrt-gnutls-dev
 Section: libdevel
+Breaks: libsrt-dev (<< 1.4.1-2)
+Replaces: libsrt-dev (<< 1.4.1-2)
 Architecture: any
 Multi-Arch: same
-Conflicts: libsrt-openssl-dev
+Conflicts: libsrt-openssl-dev, libsrt-dev
 Depends: libsrt1-gnutls (= ${binary:Version}), ${misc:Depends}
 Suggests: libsrt-doc (= ${binary:Version}), libgnutls28-dev
 Description: Secure Reliable Transport UDP streaming library


Hello, I'm not sure about the fix I did
(libsrt1 and libsrt-dev should have been transitional packages probably, but 
meh, they didn't live
that long to be needed probably).

Forcing their uninstallation, with breaks+replaces did the trick.


No need for the gnutls package to break/replaces the libsrt1 because files are 
called in a different way

G.
On Wed, 10 Jun 2020 22:42:41 +0200 Sebastian Ramacher  
wrote:
> Package: libsrt1-openssl
> Version: 1.4.1-2
> Severity: serious
> 
> When installing libsrt1-openssl if libsrt1 is already installed:
> 
> Preparing to unpack .../libsrt1-openssl_1.4.1-2_amd64.deb ...
> Unpacking libsrt1-openssl:amd64 (1.4.1-2) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/libsrt1-openssl_1.4.1-2_amd64.deb (--unpack):
>  trying to overwrite '/usr/lib/x86_64-linux-gnu/libsrt.so.1.4.1', which is 
> also in package libsrt1:amd64 1.4.1-1
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> Selecting previously unselected package libsrt-openssl-dev:amd64.
> Preparing to unpack .../libsrt-openssl-dev_1.4.1-2_amd64.deb ...
> 
> Same issue for libsrt-openssl-dev if libsrt-dev is already installed:
> 
> Unpacking libsrt-openssl-dev:amd64 (1.4.1-2) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/libsrt-openssl-dev_1.4.1-2_amd64.deb (--unpack):
>  trying to overwrite '/usr/include/srt/logging_api.h', which is also in 
> package libsrt-dev:amd64 1.4.1-1
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> Errors were encountered while processing:
>  /var/cache/apt/archives/libsrt1-openssl_1.4.1-2_amd64.deb
>  /var/cache/apt/archives/libsrt-openssl-dev_1.4.1-2_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> Cheers
> -- 
> Sebastian Ramacher

Bug#962645: qbittorrent-nox: Qbittorrent-nox is barely usable after the upgrade to 4.2.4-1+b1

[jim_p]

Package: qbittorrent-nox
Followup-For: Bug #962645

Downgrading to 4.2.4-1, the one from last week before the binary update, makes
qbittorrent work as it should, so I assume something went really wrong with
that boost 1.71 build.



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

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

Versions of packages qbittorrent-nox depends on:
ii  libboost-system1.67.0   1.67.0-18
ii  libc6   2.30-8
ii  libgcc-s1   10.1.0-3
ii  libqt5core5a5.12.5+dfsg-10+b1
ii  libqt5network5  5.12.5+dfsg-10+b1
ii  libqt5xml5  5.12.5+dfsg-10+b1
ii  libssl1.1   1.1.1g-1
ii  libstdc++6  10.1.0-3
ii  libtorrent-rasterbar10  1.2.5-1+b1
ii  zlib1g  1:1.2.11.dfsg-2

qbittorrent-nox recommends no packages.

Versions of packages qbittorrent-nox suggests:
pn  qbittorrent-dbg  

-- no debconf information

Bug#962318: libmojolicious-perl: build fails on IPv6-only buildds

[Niko Tyni]

On Tue, Jun 09, 2020 at 06:40:12PM +0200, gregor herrmann wrote:
> On Mon, 08 Jun 2020 10:18:09 +0300, Niko Tyni wrote:
> 
> > This seems to be a wider issue. Copying the debian-perl list for
> > discussion.
> 
> Thanks for the analysis!
>  
> > I'm left wondering if the IO::Socket::IP default behaviour is desirable,
> > or whether we should try to change it (maybe to special case localhost
> > and/or 0.0.0.0 ?)
> 
> Yes please. Patching all reverse dependencies sounds unattractive.

I've since test rebuilt the ~5000 packages that have a build or runtime
dependency on perl, on a system with IPv4 and IPv6 configured on the lo
device, and just a link-local IPv6 address on another device. I found
93 regressions, list below. My hunch is that more than half of them are
due to Net::EmptyPort (in libtest-tcp-perl) being broken.

I'm test rebuilding the whole archive now to see if other parts of the
archive have similar issues, but that's going to take quite a while.

I have not had the tuits yet for looking at IO::Socket::IP properly.
It seems to me that it could look at the address and pass AI_NUMERICHOST
to getaddrinfo(3) if it looks like an IPv4 address. I guess matching
against qr/^\d+\.\d+\.\d+\.\d+$/ would suffice.

I can try a rebuild with a patch like that next, but happy if somebody
else wants to pick this up. There's Perl 5.32 on my TODO list as well :)

IPv6-only regressions spotted:

alice_0.19-2
boxbackup_0.13~~git20200326.g8e8b63c-1
kgb-bot_1.56-1
libanyevent-connection-perl_0.06-5
libanyevent-connector-perl_0.03-2
libanyevent-memcached-perl_0.08-1
libanyevent-redis-perl_0.24-2
libapache-singleton-perl_0.17-1
libapache2-authcookie-perl_3.30-1
libapache2-reload-perl_0.13-3
libapp-termcast-perl_0.13-3
libaudio-mpd-perl_2.004-2
libcgi-application-plugin-captcha-perl_0.04-2
libcgi-application-server-perl_0.063-2
libcorona-perl_0.1004-4
libcpan-mini-inject-perl_0.35-1
libdancer-perl_1.3513+dfsg-1
libdanga-socket-perl_1.62-1
libfcgi-engine-perl_0.22-1
libfurl-perl_3.13-2
libgearman-client-perl_2.004.015-1
libhtml-html5-parser-perl_0.301-2
libhttp-async-perl_0.33-1
libhttp-daemon-ssl-perl_1.05-01-2
libhttp-server-simple-mason-perl_0.14-2
libio-socket-ssl-perl_2.067-1
libio-socket-timeout-perl_0.32-1
libjson-validator-perl_3.25+dfsg-1
liblwp-protocol-https-perl_6.07-2
libmime-tools-perl_5.509-1
libmojo-sqlite-perl_3.003-1
libmojolicious-perl_8.52+dfsg-2
libmojolicious-plugin-assetpack-perl_2.08-2
libmojolicious-plugin-authentication-perl_1.33-1
libmojolicious-plugin-authorization-perl_1.0302-2
libmojolicious-plugin-basicauth-perl_0.08-1
libmojolicious-plugin-bcrypt-perl_0.14-2
libmojolicious-plugin-cgi-perl_0.40-1
libmojolicious-plugin-i18n-perl_1.60-1
libmojolicious-plugin-mailexception-perl_0.20-1
libmojolicious-plugin-renderfile-perl_0.12-4
libmonitoring-livestatus-perl_0.80-1
libnet-facebook-oauth2-perl_0.12-1
libnet-http-perl_6.19-1
libnet-https-nb-perl_0.15-1
libnet-ldap-server-test-perl_0.22-1
libnet-server-mail-perl_0.28-1
libnet-server-perl_2.009-2
libnet-sip-perl_0.822-1
libperlio-via-timeout-perl_0.32-1
libplack-app-proxy-perl_0.29-1
libplack-handler-anyevent-fcgi-perl_0.01-1
libplack-handler-fcgi-ev-perl_0.01-1
libplack-middleware-deflater-perl_0.12-2
libplack-middleware-session-perl_0.33-1
libplack-perl_1.0047-2
libplack-test-agent-perl_1.4-2
libplack-test-externalserver-perl_0.02-1
libpod-webserver-perl_3.11-1
libproc-guard-perl_0.07-1
libprotocol-http2-perl_1.10-1
libredis-perl_1.9950-1
librest-client-perl_273-1
librpc-xml-perl_0.80-2
librt-client-rest-perl_0.60-1
libtest-fake-httpd-perl_0.08-1
libtest-http-server-simple-stashwarnings-perl_0.04-2
libtest-tcp-perl_2.22-1
libtest-www-declare-perl_0.02-4
libtest-www-mechanize-mojo-perl_0.0.20-1
libtest-www-mechanize-perl_1.52-1
libweb-id-perl_1.927-2
libweb-machine-perl_0.17-1
libwiki-toolkit-plugin-ping-perl_0.03-2
libwww-mechanize-perl_1.97-1
myproxy_6.2.6-1
perlbal_1.80-3
pinto_0.14000-1
request-tracker4_4.4.4-1
spamassassin_3.4.4-1
starman_0.4015-1
stunnel4_5.56+dfsg-3
twiggy_0.1025+dfsg-1
inn2_2.6.3+20200601-1
libcrypt-ssleay-perl_0.73.06-1
libnanomsg-raw-perl_0.10-1
libapache2-mod-perl2_2.0.11-2
feersum_1.407-2
libapache-authenhook-perl_2.00-04+pristine-7
libapache-ssllookup-perl_2.00-04-3
libredis-fast-perl_0.26+dfsg-2
remctl_3.16-4
nbdkit_1.20.2-1

-- 
Niko

Bug#948309: guice: Package the no_aop jar

[Thorsten Glaser]

Package: libguice-java
Version: 4.2.1-1
Followup-For: Bug #948309

Please address this issue. I can confirm that replacing
/usr/share/maven/lib/guice.jar with a copy of the stock
Maven Central guice-4.2.1-no_aop.jar fixes the Maven error.

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

Kernel: Linux 5.6.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libguice-java depends on:
ii  libaopalliance-java  20070526-6
ii  libatinject-jsr330-api-java  1.0+ds1-5
ii  libguava-java29.0-5
ii  libjsr305-java   0.1~+svn49-11

libguice-java recommends no packages.

Versions of packages libguice-java suggests:
ii  libasm-java7.3.1-1
ii  libcglib-java  3.2.12-1

-- no debconf information

Bug#962715: Incompatible API versions: encoded with [1,17,5,4] but attempted to decode with [1,20]

[Jonas Smedegaard]

Quoting Eric Marsden (2020-06-12 16:08:52)
> Package: pandoc-sidenote
> Version: 0.20.0-1
> 
> When invoking pandoc-sidenote as a pandoc filter, it generates an error 
> related to "incompatible API versions".
> 
>     % pandoc --filter pandoc-sidenote -o /tmp/foo.html foo.md
>     pandoc-sidenote: Error in $: Incompatible API versions: encoded with 
> [1,17,5,4] but attempted to decode with [1,20].
>     CallStack (from HasCallStack):
>      error, called at ./Text/Pandoc/JSON.hs:107:64 in 
> pandoc-types-1.20-Ip2ZGM2tgGt4TDYVgvP7zF:Text.Pandoc.JSON
>     Error running filter pandoc-sidenote:
>     Filter returned error status 1
> 
> 
> Architecture is amd64. Pandoc version is 2.5-3+b1. Reverting to the 
> previous version 0.19.0.0-2+b4 works fine.

Interesting!  Looks like pandoc and pandoc-sidenote was compiled with 
different versions of pandoc-types, and strongly depend on that being 
identical at runtime.

I will look into having pandoc provide a virtual package indicating its 
"ABI" of which pandoc-types it was compiled against, and then have 
pandoc-sidenote depend on that ABI.

Thanks for reporting!

 - Jonas

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

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

signature.asc
Description: signature

Bug#962532: Same bug in 20.1.1-1. Also calibre, vlc, stellarium segfault.

[ziegler]

Am Fr 12 Jun 2020 08:35:00 CET schrieb Timo Aaltonen:


don't use the intel X driver



Thanks! I removed /etc/X11/xorg.conf and everything is fine 
now.


Regards,
Martin

PS: Everything? No, xfce4 does not accept background 
pictures anymore, like the nice xfce-teal.jpg.

Bug#962716: qbittorrent: Qbittorrent 4.2.4-1+b1 crashes once a download is completed

[jim_p]

Package: qbittorrent
Version: 4.2.4-1+b1
Severity: normal

This is a followup of #962645.

As I mention on the other bug report, qbittorrent crashes when a download is
finished and this is the output at that time

https://paste.debian.net/1151639/

Downgrading it to 4.2.4-1, the version before last week's binary update, makes
it work as it should, so I assume that something went really wrong with that
build with boost 1.71.



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

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

Versions of packages qbittorrent depends on:
ii  geoip-database  20191224-2
ii  libc6   2.30-8
ii  libgcc-s1   10.1.0-3
ii  libqt5core5a5.12.5+dfsg-10+b1
ii  libqt5dbus5 5.12.5+dfsg-10+b1
ii  libqt5gui5  5.12.5+dfsg-10+b1
ii  libqt5network5  5.12.5+dfsg-10+b1
ii  libqt5widgets5  5.12.5+dfsg-10+b1
ii  libqt5xml5  5.12.5+dfsg-10+b1
ii  libssl1.1   1.1.1g-1
ii  libstdc++6  10.1.0-3
ii  libtorrent-rasterbar10  1.2.5-1+b1
ii  python3 3.8.2-3
ii  zlib1g  1:1.2.11.dfsg-2

qbittorrent recommends no packages.

Versions of packages qbittorrent suggests:
pn  qbittorrent-dbg  

-- no debconf information

Bug#962716: qbittorrent: Qbittorrent 4.2.4-1+b1 crashes once a download is completed

[jim_p]

Package: qbittorrent
Followup-For: Bug #962716

Can someone raise its importance from normal to grave because it does render
the package unusable?



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

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

Versions of packages qbittorrent depends on:
ii  geoip-database  20191224-2
ii  libboost-system1.67.0   1.67.0-18
ii  libc6   2.30-8
ii  libgcc-s1   10.1.0-3
ii  libqt5core5a5.12.5+dfsg-10+b1
ii  libqt5dbus5 5.12.5+dfsg-10+b1
ii  libqt5gui5  5.12.5+dfsg-10+b1
ii  libqt5network5  5.12.5+dfsg-10+b1
ii  libqt5widgets5  5.12.5+dfsg-10+b1
ii  libqt5xml5  5.12.5+dfsg-10+b1
ii  libssl1.1   1.1.1g-1
ii  libstdc++6  10.1.0-3
ii  libtorrent-rasterbar10  1.2.5-1+b1
ii  python3 3.8.2-3
ii  zlib1g  1:1.2.11.dfsg-2

qbittorrent recommends no packages.

Versions of packages qbittorrent suggests:
pn  qbittorrent-dbg  

-- no debconf information

Bug#962717: ITP: q2-quality-control -- QIIME 2 plugin for quality assurance of feature and sequence data

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: q2-quality-control
  Version : 2020.2.0
* URL : https://github.com/qiime2/q2-quality-control
* License : BSD-3-Clause
  Programming Lang: Python
  Description : QIIME 2 plugin for quality assurance of feature and 
sequence data

To be maintained at https://salsa.debian.org/med-team/q2-quality-control

Bug#962718: split renderdoc qt frontend from non-qt backend

[Eric Anholt]

Package: renderdoc
Version: 1.7+dfsg-2
Severity: wishlist

When I install renderdoc, it pulls in both the QT GUI for renderdoc
and the renderdoccmd and python renderdoc.so modules.

For resource-constrained systems, it would be nice to be able to avoid
the QT frontend for just replay.  Ustream Mesa CI wants to use
renderdoc traces for correctness testing of drivers, and we build from
source to avoid the QT frontend (some of the test systems bundle the
whole debian and test suites in an initramfs that we try to run on
1-2GB of RAM)  The build is painful to do and slow, and we're close to
our 1 hour build budget for the arm containers already, so a package
of just enough to replay (python backend is what we're using,
renderdoccmd could come with it or not) would be really nice to have.
I would imagine a set of packages like:

- librenderdoc
- renderdoccmd
- python renderdoc.so
- qrenderdoc
- renderdoc (meta package)

but we'd be happy with anything that split qrenderdoc and the qt deps out.

Thanks!

Bug#948188: New upstream release 1.4.0

[Andreas Henriksson]

Control: forwarded -1 https://salsa.debian.org/ah/pam/-/commits/master-1.4.0

Hello again,

I've now pushed my initial work on updating the packaging to 1.4.0 here:

https://salsa.debian.org/ah/pam/

See master-1.4.0 and upstream-1.4.0 branches.

Current status is that it builds. I'll continue working on making it
ready for upload when I find time.

Please also note that there's a bunch of things related to deprecations
that I expect maintainers to eventually step up and clean up, which I'm
just avoiding to touch as much as I can (eg. I'm reenabling deprecated
modules, also updating patches which likely doesn't make sense to keep
around anymore since /etc/securetty doesn't exist, etc).

Regards,
Andreas Henriksson

Bug#960144: srt: please package new upstream bugfix release 1.4.1

[Gianfranco Costamagna]

control: fixed -1 1.4.1-1
control: close -1

G.
On Sat, 09 May 2020 23:10:40 +0200 Jonas Smedegaard  wrote:
> Source: srt
> Severity: normal
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Upstream released a new bugfix release in December 2019.
> 
> It includes some improvements and also fixes for several crashing issues.
> 
> Please upgrade the package in Debian.
> 
> Raising severity due to the nature of the changes to that release.
> 
>  - Jonas
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl63HE8ACgkQLHwxRsGg
> ASGABQ//eNSAzImCrSYiJKRhj3683LtOGWTPHB07c6Q2/4ZGCCbD0PKCTxxU9NNS
> Qi8NwghnoMG3sxe8NI2R/jIqbOGhUHBghRQ27Pji3L6tXTN6Yb/XAJs9f3Uj9zd2
> M/60iyCNv+R7e4gNX2jLLMNnWdAE5J+VTgdKsrDvQvm10qac0IV509xaWSLe9RLT
> CBEvpiXOd0x49EiwVh96BcFCNkGevitLhTFcsS75gAdqaZU2yUdSt9A3B+QnbhJ9
> Z8PUS00x13+vzOZPoRL8Nhz0pZ+UWS65HsgPhth8KeQ6+2j1VjuF1h3LZyD99+md
> rJbEaeX1JMqTfhM/k7XT+2DMmutlIxlFhByF5qHQeP5OQ/grgXL6c8+9F/T97+VB
> /hInS6PUhEvqerYTjHvvLTQIQAnBJsOQXhGM43f7Gc3hhUCuMGcMOlHyqx6nz1Dj
> /q83xRLAuG6Oy9TUsJgVEZXt/imd51EkPlOCUNKIBD9NZ5HPr96gwhHXjVODIsm+
> b1VnqBVPq8Ayi2txREO/T8u4iBL1ordbO60Cp8WDov91CrjVr+ESUylNZpW5qyXZ
> gMcPahu2883FZPVIfCNdHmhxYy8SAZjZhAGQZy78QZ6SX/gGpQvm2jcwVlTjWU6G
> n4EDwE0Yvc7ZemEkBSIzC7YhiSDonaiMPAaKmsRKn19ljkcp54A=
> =HWAg
> -END PGP SIGNATURE-
> 
> 

Bug#962706: python3-uflash-doc: typo in dpendencies

[Laurent Bonnaud]

Package: python3-uflash-doc
Version: 1.2.4+dfsg-1
Severity: normal


Dear Maintainer,

here is the problem:

$ dpkg -s python3-uflash-doc
[...]
Suggests: -browser

---^ 
there is an extra w here.


-- 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)

Kernel: Linux 5.6.0-2-rt-amd64 (SMP w/2 CPU cores; PREEMPT)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-uflash-doc depends on:
ii  libjs-sphinxdoc  3.1.0-1

python3-uflash-doc recommends no packages.

Versions of packages python3-uflash-doc suggests:
pn  -browser  

-- no debconf information

-- 
Laurent.

Bug#962719: d-shlibs: fontforge FTBFS - There is no package matching [libharfbuzz0-dev] and noone provides it

[John Paul Adrian Glaubitz]

Source: d-shlibs
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

The package fontforge fails to build from source on some architectures again
due to d-shlibs [1]:

 --> libcairo-dev is provided by a package.
 --> libcairo2-dev package exists.
 --> libfontforge-dev package from same source package.
 --> libfreetype6-dev package exists.
 --> libgif-dev package exists.
 --> libglib2.0-dev package exists.
 --> libgtk-3-dev package exists.
 --> libgtk2.0-dev package exists.
devlibs error: There is no package matching [libharfbuzz0-dev] and noone 
provides it, please report bug to d-shlibs maintainer
 --> libjpeg-dev package exists.
 --> libpango1.0-dev package exists.
 --> libpng-dev package exists.
 --> libpython3.8-dev package exists.
 --> libreadline-dev package exists.
 --> libspiro-dev package exists.
 --> libtiff5-dev package exists.
 --> libuninameslist-dev package exists.
 --> libxml2-dev package exists.
 --> zlib1g-dev package exists.

Could this be fixed the same way as in [2]?

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=fontforge=m68k=1%3A20190801%7Edfsg-5=1590789689=0
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954167

--
.''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#962720: gst-plugins-bad1.0: FTBFS in sid

[Gianfranco Costamagna]

Also this patch
https://aur.archlinux.org/cgit/aur.git/tree/0001-vulkan-Drop-use-of-VK_RESULT_BEGIN_RANGE.patch?h=lib32-gst-plugins-bad

looks needed because of new mesa

G.

Bug#948310: maven: Depend on Guice no_aop

[Thorsten Glaser]

Package: maven
Version: 3.6.3-1
Followup-For: Bug #948310
Control: retitle -1 maven: An illegal reflective access operation has occurred 
(needs Guice no_aop)

You can already fix this in maven, the
/usr/share/maven-repo/com/google/inject/guice/debian/guice-debian-no_aop.jar
file/symlink already exists.

I’m retitling this so it can be more easily found.

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

Kernel: Linux 5.6.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages maven depends on:
ii  default-jre-headless [java7-runtime-headless] 2:1.11-72
ii  libjansi-java 1.18-1
ii  libmaven3-core-java   3.6.3-1
ii  libwagon-file-java3.3.4-1
ii  libwagon-http-shaded-java 3.3.4-1
ii  openjdk-11-jre-headless [java7-runtime-headless]  11.0.7+10-3

maven recommends no packages.

maven suggests no packages.

-- no debconf information

Bug#946412: janus-gateway: upstream does not support stable releases

[Salvatore Bonaccorso]

Hi Jonas,

On Fri, Jun 12, 2020 at 08:53:35AM +0200, Jonas Smedegaard wrote:
> Quoting Salvatore Bonaccorso (2020-06-11 22:54:43)
> > On Sun, Dec 08, 2019 at 02:09:10PM +0100, Jonas Smedegaard wrote:
> > > Upstream releases are to be considered draft snapshots,
> > > and this package is therefore unsuitable for inclusion
> > > in long-term distributions like Debian stable.
> > > 
> > > This bug should be bumped to release-critical state
> > > close to or after entering freeze -
> > > but not before so as to ease use for users tracking testing
> > > including derivatives based on Debian testing.
> > 
> > Reading the above, so janus should not have been in buster, right?
> 
> While in good faith, I am not sure what you are implying with the above: 
> In an ideal World (where crystal balls or time machines exist), yes.
> 
> Both filing this bugreport and the upstream statement triggering it 
> occured _after_ the release of Buster, indicating lack of knowledge on 
> the matter at the time of release of Buster (or, in bad faith, that it 
> was known but kept secret - sure you cannot mean that).

Sorry I think there was a missunderstanding here, I by no means
implied bad faith or that at the time of the buster release it was
known. I probably wrote the above too short to make it clear. Let me
expand a bit.

While I was filling bug for the new CVEs reported for janus I stumpled
over #946412 and that made me think to reply there and raise the
question on the removal of janus from buster. What I actually wanted
to ask with the above is "should janus be removed from buster as
ideally it would not have been released with it" but not implying the
situation was already clear at that time.

Sorry if that all was not clear in my wording.

Thanks for filling the removal, taken note of #962694.

Regards,
Salvatore

Bug#962723: libdogecoinconsensus-dev,libdogecoinconsensus0: missing Breaks+Replaces: dogecoin (<< 1.14)

[Andreas Beckmann]

Package: libdogecoinconsensus-dev,libdogecoinconsensus0
Version: 1.14.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Unpacking libdogecoinconsensus0:amd64 (1.14.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libdogecoinconsensus0_1.14.0-1_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/x86_64-linux-gnu/libdogecoinconsensus.so.0.0.0', which is also in 
package dogecoin 1.10.0-7.1+b2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Preparing to unpack .../libdogecoinconsensus-dev_1.14.0-1_amd64.deb ...
  Unpacking libdogecoinconsensus-dev:amd64 (1.14.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libdogecoinconsensus-dev_1.14.0-1_amd64.deb (--unpack):
   trying to overwrite '/usr/include/dogecoinconsensus.h', which is also in 
package dogecoin 1.10.0-7.1+b2
  Errors were encountered while processing:
   /var/cache/apt/archives/libdogecoinconsensus0_1.14.0-1_amd64.deb
   /var/cache/apt/archives/libdogecoinconsensus-dev_1.14.0-1_amd64.deb


cheers,

Andreas


dogecoin=1.10.0-7.1+b2_libdogecoinconsensus-dev=1.14.0-1.log.gz
Description: application/gzip

Bug#962721: ITP: commonmark -- Python parser for the CommonMark Markdown spec

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi 
Control: block 954301 by -1

* Package name: commonmark
  Version : 0.9.1
  Upstream Author : Bibek Kafle, Roland Shoemaker
* URL : https://github.com/readthedocs/commonmark.py
* License : BSD
  Programming Lang: Python
  Description : Python parser for the CommonMark Markdown spec

dependency of rich, #954301

Bug#953554: Please permit Debian revisions with 1.0 native packages

[Felix Lechner]

Hi Guillem,

On Thu, Jun 11, 2020 at 11:14 PM Guillem Jover  wrote:
>
> Given the timing of this reaction, I think it would not be
> unreasonable to consider it originating out of spite?

Actually, I did not think of you. I hoped to show Ian that I am not
"part of a campaign to abolish one of [his] workflows." The record in
this bug shows that my support for his position predates your current
efforts against me.

Kind regards
Felix Lechner

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Felix Lechner]

Hi,

On Fri, Jun 12, 2020 at 3:30 AM Ian Jackson
 wrote:
>
> As for `3.0 (native)', it has one serious disadvantage: dpkg-source
> has been programmed to reject version numbers with a Debian revision.
> If that restriction were relaxed, `3.0 (native)' would be a strictly
> superior drop-in replacement for 1.0-native and I doubt anyone would
> have any objection to phasingt 1.0-native out completely.

What a winning trade! The restriction should be lifted right away.

Kind regards
Felix Lechner

Bug#962640: RFS: zmat/0.9.8 [RFS] -- a portable C-library and Octave toolbox for data compression

[Qianqian Fang]

Just made another update to the test package on mentors, see

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

after consulting the debian-octave mailing list, the octave-zmat package 
is all good now (tested and working)


I also corrected an error (due to the removal of the bundled lz4 files) 
of the orig package prep script 
, and now 
the package is compiled properly against the external liblz4 library.


feel free to take a look and let me know if any additional change is 
needed. thanks


Qianqian

Bug#962722: nmu: md4c_0.4.4-1

[Patrick Franz]

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

Hi,

The last upload of md4c went through NEW and thus I'm requesting a binNMU to 
have the amd64 packages rebuilt on buildd, such that the package can transition 
to testing.

nmu md4c_0.4.4-1 . amd64 . unstable . -m "Rebuild amd64 package on the buildd 
so it can transition."


--
Med vänliga hälsningar

Patrick Franz

Bug#946412: janus-gateway: upstream does not support stable releases

[Salvatore Bonaccorso]

Hi

On Fri, Jun 12, 2020 at 10:29:06AM +0200, Jonas Smedegaard wrote:
> Quoting Moritz Muehlenhoff (2020-06-12 10:20:31)
> > On Fri, Jun 12, 2020 at 08:53:35AM +0200, Jonas Smedegaard wrote:
> > > Quoting Salvatore Bonaccorso (2020-06-11 22:54:43)
> > > > On Sun, Dec 08, 2019 at 02:09:10PM +0100, Jonas Smedegaard wrote:
> > > > > Upstream releases are to be considered draft snapshots,
> > > > > and this package is therefore unsuitable for inclusion
> > > > > in long-term distributions like Debian stable.
> > > > > 
> > > > > This bug should be bumped to release-critical state
> > > > > close to or after entering freeze -
> > > > > but not before so as to ease use for users tracking testing
> > > > > including derivatives based on Debian testing.
> > > > 
> > > > Reading the above, so janus should not have been in buster, right?
> > > 
> > > While in good faith, I am not sure what you are implying with the 
> > > above: In an ideal World (where crystal balls or time machines 
> > > exist), yes.
> > > 
> > > Both filing this bugreport and the upstream statement triggering it 
> > > occured _after_ the release of Buster, indicating lack of knowledge 
> > > on the matter at the time of release of Buster (or, in bad faith, 
> > > that it was known but kept secret - sure you cannot mean that).
> > 
> > Don't read things into this which don't exist :-)
> > 
> > The only question here was whether janus should continue to be in stable
> > or not, noone is accusing you of anything.
> 
> Thanks for confirmation :-)

yes excacltly, that was my intention. Thanks Moritz for wording that
in better way as I did.

Regards,
Salvatore

Bug#962685: wordpress 5.4.2 security release

[Salvatore Bonaccorso]

Hi Craig,

On Fri, Jun 12, 2020 at 06:33:14AM +0200, Salvatore Bonaccorso wrote:
> Hi Craig,
> 
> On Fri, Jun 12, 2020 at 09:40:34AM +1000, Craig Small wrote:
> > Source: wordpress
> > Version: 5.4.1+dfsg1-1
> > Severity: grave
> > Tags: security upstream
> > Justification: user security hole
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > WordPress 5.4.2 is out and fixes the following vulnerabilities:
> [...]
> 
> Thanks for filling the bugreport about those, added tracking in the
> security-tracker correspondigly.
> 
> Are you requesting CVEs for those?

Looks that for all (but not your first mentioned issue) they have CVEs
assigned now (was not when I checked). They are at

https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-4vpv-fgg2-gcqc
https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-87h4-phjv-rm6p
https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-q6pw-gvf4-5fj5
https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-8q2w-5m27-wm27
https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-rpwf-hrh2-39jf

Regards,
Salvatore

Bug#962727: libwww-mechanize-perl: build fails on IPv6-only buildds

[Adrian Bunk]

Source: libwww-mechanize-perl
Version: 2.00-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=libwww-mechanize-perl=all=2.00-1=1591965277=0

...
# Test server http://127.0.0.1:39495 as PID 1878

#   Failed test 'First fetch works'
#   at t/cookies.t line 74.
#  got: '500'
# expected: '200'

#   Failed test 'First cookie matches'
#   at t/cookies.t line 78.
#  got: undef
# expected: 'Cookie #1'

#   Failed test 'Right title'
#   at t/cookies.t line 79.
#  got: undef
# expected: 'Home of Cookie #1'

#   Failed test 'Second fetch works'
#   at t/cookies.t line 84.
#  got: '500'
# expected: '200'

#   Failed test 'Second cookie matches'
#   at t/cookies.t line 88.
#  got: undef
# expected: 'Cookie #2'

#   Failed test 'Right title'
#   at t/cookies.t line 89.
#  got: undef
# expected: 'Home of Cookie #2'

#   Failed test 'Cookie did not change...'
#   at t/cookies.t line 97.
#  got: undef
# expected: 'Cookie #2'

#   Failed test '... but back to the first page title'
#   at t/cookies.t line 98.
#  got: undef
# expected: 'Home of Cookie #1'

#   Failed test 'Cookie did not change...'
#   at t/cookies.t line 106.
#  got: undef
# expected: 'Cookie #2'

#   Failed test 'On the proper 3rd page'
#   at t/cookies.t line 107.
#  got: undef
# expected: 'No cookies sent'

#   Failed test 'Got the third cookie'
#   at t/cookies.t line 115.
#  got: undef
# expected: 'Cookie #3'

#   Failed test 'Title is correct'
#   at t/cookies.t line 116.
#  got: undef
# expected: 'Home of Cookie #3'
# Looks like you failed 12 tests of 14.
t/cookies.t ..
1..14
TestServer: You can connect to your server at http://localhost:39495/
ok 1 - An object of class 'WWW::Mechanize' isa 'WWW::Mechanize'
not ok 2 - First fetch works
not ok 3 - First cookie matches
not ok 4 - Right title
not ok 5 - Second fetch works
not ok 6 - Second cookie matches
not ok 7 - Right title
not ok 8 - Cookie did not change...
not ok 9 - ... but back to the first page title
not ok 10 - Cookie did not change...
not ok 11 - On the proper 3rd page
not ok 12 - Got the third cookie
not ok 13 - Title is correct
ok 14 - Signaled the child process
Dubious, test returned 12 (wstat 3072, 0xc00)
Failed 12/14 subtests
...
Test Summary Report
---
t/cookies.t(Wstat: 3072 Tests: 14 Failed: 12)
  Failed tests:  2-13
  Non-zero exit status: 12
Files=61, Tests=798, 83 wallclock secs ( 0.29 usr  0.10 sys + 15.79 cusr  2.28 
csys = 18.46 CPU)
Result: FAIL
Failed 1/61 test programs. 12/798 subtests failed.
make[2]: *** [Makefile:948: test_dynamic] Error 255


See #962019 for discussion of a similar problem in a different package.

Bug#959479: FTBFS with Boost 1.71

[Adrian Bunk]

On Sat, May 02, 2020 at 09:33:24PM +0200, Giovanni Mascellani wrote:
>...
> More specifically, your package fails building because it uses some
> retired API from Boost.Asio. It appears, though, that upstream dogecoin
> has since long stopped using Asio, switching to libevent2 as IO library
> since commit 40b556d3742a1f65d67e2d4c760d0b13fe8be5b7 (dated Fri Jan 23
> 07:53:17 2015 +0100). I believe it would be more advisable to package an
> updated version of dogecoin rather than patch it for Boost 1.71.
>...

This seems fixed in 1.14.0-1 in unstable now, except that the symbols 
file also needs updating:
  https://buildd.debian.org/status/package.php?p=dogecoin=sid

cu
Adrian

Bug#962682: nheko FTCBFS: multiple issues

[Hubert Chathi]

On Thu, 11 Jun 2020 22:53:36 +0200, Helmut Grohne  said:

> nheko fails to cross build from source. The immediate cause is its
> Build-Depends on g++. This dependency is unsatisfiable and needs cross
> translation. ...

Thanks for the patch.  I'll apply it to our git repo.  A new upstream
version is coming soon, so I'll rebuild some time after that happens.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#941866: gtrayicon: Intent to remove from Debian

[Boyuan Yang]

Dear gtrayicon maintainers,

On Tue, 21 Jan 2020 13:03:49 -0500 Boyuan Yang 
wrote:
> X-Debbugs-CC: ripps...@gmail.com
> 
> On Sun, 6 Oct 2019 16:29:28 -0400 Jeremy Bicha 
wrote:
> > Source: gtrayicon
> > Version: 1.1-1
> > Severity: serious
> > 
> > As part of a major effort to reduce the amount of GTK2 software in
> > Debian, I or someone else will be requesting the removal of
gtrayicon
> > from Debian.
> > 
> > It has very low popcorn and hasn't been updated upstream or in
Debian
> > in more than a decade.
> > 
> > If you object, please comment here before the package is removed
from
> > Debian. Or better yet, convert it to gtk3 if you can. See
> > https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html
> 
> Dear developer,
> 
> since there has been no response since October, I will consider
starting the
> removal soon. The removal bug will be filed after one week (after
Jan. 28,
> 2020). If you have any objections, please let me know ASAP.

Since there has been no reply for 6 months, I will be submitting the
removal request now.

-- 
Regards,
Boyuan Yang


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

Bug#962730: RM: gtrayicon -- RoQA; Unmaintained; Low Popcon; Gtk2 Deprecation

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: ripps...@gmail.com

Dear Debian FTP Masters,

As discussed in https://bugs.debian.org/941866 , please remove package
gtrayicon from Sid. It received no upload in the last 11 years and is
affected by the effort to reduce GTK2 software in Debian. The package
uploader did not respond to the removal request in 
https://bugs.debian.org/941866 for 6 months.

-- 
Regards,
Boyuan Yang


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

Bug#962703: mailplate: Should we remove this package from Debian?

[martin f krafft]

Thank you for your efforts! Removal of mailplate is definitely the 
best option.


--
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#828095: petitboot: diff for NMU version 13.05.29.14.00-g4dc604b-1.1

[Guilherme Xavier]

Dear maintainer,

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

Regards,

Guilherme

diff -Nru petitboot-13.05.29.14.00-g4dc604b/debian/changelog
petitboot-13.05.29.14.00-g4dc604b/debian/changelog
--- petitboot-13.05.29.14.00-g4dc604b/debian/changelog 2013-05-29
19:55:52.0 -0300
+++ petitboot-13.05.29.14.00-g4dc604b/debian/changelog 2020-06-11
08:48:35.0 -0300
@@ -1,3 +1,13 @@
+petitboot (13.05.29.14.00-g4dc604b-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload. (Closes: #828095)
+  * debian/control: added dh-autoreconf to Build-Depends field.
+  * debian/patches/fix-automake-warnings.patch: added upstream patch to fix
+dependency to build on ppc64el. Thanks to Logan Rosen >.
+  * debian/rules: added autoreconf parameters.
+
+ -- Guilherme de Paula Xavier Segundo   Thu, 11
Jun 2020 08:48:35 -0300
+
 petitboot (13.05.29.14.00-g4dc604b-1) unstable; urgency=low

   * debian/compat: Update 8 -> 9.
diff -Nru petitboot-13.05.29.14.00-g4dc604b/debian/control
petitboot-13.05.29.14.00-g4dc604b/debian/control
--- petitboot-13.05.29.14.00-g4dc604b/debian/control 2013-05-28
20:53:29.0 -0300
+++ petitboot-13.05.29.14.00-g4dc604b/debian/control 2020-06-11
08:48:35.0 -0300
@@ -9,7 +9,8 @@
  libtinfo-dev,
  libtwin-dev,
  libudev-dev,
- pkg-config
+ pkg-config,
+ dh-autoreconf
 Standards-Version: 3.9.4
 Homepage:
https://www.kernel.org/pub/linux/kernel/people/geoff/petitboot/petitboot.html
 Vcs-Git: git://git.kernel.org/pub/scm/linux/kernel/git/geoff/petitboot.git
diff -Nru
petitboot-13.05.29.14.00-g4dc604b/debian/patches/fix-automake-warnings.patch
petitboot-13.05.29.14.00-g4dc604b/debian/patches/fix-automake-warnings.patch
---
petitboot-13.05.29.14.00-g4dc604b/debian/patches/fix-automake-warnings.patch
1969-12-31 21:00:00.0 -0300
+++
petitboot-13.05.29.14.00-g4dc604b/debian/patches/fix-automake-warnings.patch
2020-06-11 08:48:35.0 -0300
@@ -0,0 +1,75 @@
+From 434a6c9c100bc8daca1e6c41137f993d88f20fe3 Mon Sep 17 00:00:00 2001
+From: Geoff Levand 
+Date: Sun, 30 Jun 2013 13:45:58 -0700
+Subject: discover: Fix automake warnings
+
+Change the Makfile.am relocatable output files from automake _LIBRARIES
+to automake _PROGRAMS.  Also, change the output file name extension
+from .o to .ro to better show these are relocatable files.
+
+Fixes automake warnings like these:
+
+  discover/Makefile.am: `libparser.o' is not a standard library name
+  discover/Makefile.am: did you mean `libparser.a'?
+
+Signed-off-by: Geoff Levand 
+---
+ discover/Makefile.am| 8 
+ test/parser/Makefile.am | 9 -
+ 2 files changed, 8 insertions(+), 9 deletions(-)
+
+--- a/discover/Makefile.am
 b/discover/Makefile.am
+@@ -19,9 +19,9 @@
+ -DPKG_SHARE_DIR='"$(pkgdatadir)"' \
+ -DLOCAL_STATE_DIR='"$(localstatedir)"'
+
+-noinst_LIBRARIES = libparser.o
++noinst_PROGRAMS = libparser.ro
+
+-libparser_o_SOURCES = \
++libparser_ro_SOURCES = \
+ parser.c \
+ parser.h \
+ parser-conf.c \
+@@ -35,7 +35,7 @@
+ yaboot-parser.c \
+ pxe-parser.c
+
+-libparser.o: $(libparser_o_OBJECTS)
++libparser.ro: $(libparser_ro_OBJECTS)
+ $(LD) -r -o $@ $^
+
+ EXTRA_DIST = native-parser.c
+@@ -63,7 +63,7 @@
+ user-event.c \
+ user-event.h
+
+-pb_discover_LDADD = libparser.o $(top_builddir)/lib/libpbcore.la
++pb_discover_LDADD = libparser.ro $(top_builddir)/lib/libpbcore.la
+
+ pb_discover_LDFLAGS = -ludev
+
+--- a/test/parser/Makefile.am
 b/test/parser/Makefile.am
+@@ -41,9 +41,9 @@
+ data/yaboot-rh8-ppc64.conf
+
+ common_libs = $(top_builddir)/lib/libpbcore.la
+-test_libs = libtest.o
++test_libs = libtest.ro
+
+-libtest.o: $(libtest_o_OBJECTS)
++libtest.ro: $(libtest_ro_OBJECTS)
+ $(LD) -o $@ -r $^
+
+ # objects under test
+@@ -58,7 +58,7 @@
+
+ LDADD = $(common_libs) $(test_libs)
+
+-libtest_o_SOURCES = utils.c parser-test.h handler.c main.c
$(parser_test_objs)
++libtest_ro_SOURCES = utils.c parser-test.h handler.c main.c
$(parser_test_objs)
+
+ $(check_PROGRAMS): %: %.embedded-config.o
+ $(check_PROGRAMS): LDADD += $@.embedded-config.o
diff -Nru petitboot-13.05.29.14.00-g4dc604b/debian/patches/series
petitboot-13.05.29.14.00-g4dc604b/debian/patches/series
--- petitboot-13.05.29.14.00-g4dc604b/debian/patches/series 1969-12-31
21:00:00.0 -0300
+++ petitboot-13.05.29.14.00-g4dc604b/debian/patches/series 2020-06-11
08:48:35.0 -0300
@@ -0,0 +1 @@
+fix-automake-warnings.patch
diff -Nru petitboot-13.05.29.14.00-g4dc604b/debian/rules
petitboot-13.05.29.14.00-g4dc604b/debian/rules
--- petitboot-13.05.29.14.00-g4dc604b/debian/rules 2012-02-15
21:16:23.0 -0200
+++ petitboot-13.05.29.14.00-g4dc604b/debian/rules 2020-06-11
08:48:35.0 -0300
@@ -18,7 +18,10 @@


 %:
- dh $@
+ dh $@ --with autoreconf

 override_dh_auto_configure:
  dh_auto_configure -- --with-twin-x11=yes --with-twin-fbdev=yes
+
+override_dh_autoreconf:
+ dh_autoreconf ./bootstrap


-- 

Bug#749891: [Pkg-haskell-maintainers] Bug#749891: pandoc: doesn't support some Unicode characters with PDF output

[Jonas Smedegaard]

Quoting Vincent Lefevre (2020-06-12 22:56:50)
> Well, I can see that the following issue has been fixed:
> 
> > > * if the character isn't present, it should output an error.
> 
> e.g. I get
> 
> $ pandoc file --pdf-engine=xelatex -o out.pdf
> [WARNING] Missing character: There is no ≤ in font 
> [lmroman10-regular]:mapping=tex-text;!
> 
> So, if something is wrong, at least I know that I need to change
> the font.

Ohhh, I totally missed that this was an ancient bugreport, so I didn't 
check if things had improved recently.

Yes, as also noted in related https://bugs.debian.org/639139 the error 
handling has improved over time. :-)

 - Jonas

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

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

signature.asc
Description: signature

Bug#962729: RM: mailplate -- RoM; Unmaintained; Affected by Python2 Removal

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: madd...@debian.org

Dear Debian FTP Masters,

Please remove package mailplate from Sid. As discussed in 
https://bugs.debian.org/962703 , this package is affected by Python2
removal and the current maintainer has agreed that package removal is
the best option now.

-- 
Regards,
Boyuan Yang


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

Bug#962402: haskell-text-icu built

[Frédéric Bonnard]

Hi,
I wanted to check that FTBFS but it actually built, on different setup.
After a give back on ppc64el and s390x, everything went fine. Very few
changes between the failing and succeeding build. Same ghc, kernel.
For the record, linux-libc-dev, libgmpxx4ldbl, libgmp-dev, libkrb5support0,
libk5crypto3, libkrb5-3, libgssapi-krb5-2, libnghttp2-14, hscolour were
not the same.

F.


signature.asc
Description: PGP signature