Bug#970580: licenseutils: Memory access error

2020-09-22 Thread Mattia Rizzolo
Control: forwarded -1 https://savannah.nongnu.org/bugs/?59157

On Sat, Sep 19, 2020 at 10:24:38AM +0200, Mechtilde Stehmann wrote:
> At the first start I got
> 
> licensing gpl: got unexpected response code 302 from
> www.gnu.org/licenses/gpl.txt
> 
> I also tested more options and get "Memory access error"
> 
> No option gives a result


thank you, forwarded upstream at the above URL.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#969529: (no subject)

2020-09-17 Thread Mattia Rizzolo
A note, that ubuntu links to a different commit (the same that is
recorded at mitre).

https://bugs.launchpad.net/debian/+source/libxml2/+bug/1895839

-- 
regards,
Mattia Rizzolo

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



Bug#970441: libnuspell-dev: typo in long description: germand

2020-09-16 Thread Mattia Rizzolo
On Wed, Sep 16, 2020 at 06:03:11PM +0300, Andrei POPESCU wrote:
> On Mi, 16 sep 20, 16:47:19, Mattia Rizzolo wrote:
> > 
> > you filed this against libnuspell-dev, something that doesn't exists.  I
> > thought it was a typo for libhunspell-dev, but I can't find that
> > sentence nor the typo in it… so I ask you to double check your report :)
> 
> https://tracker.debian.org/news/1176360/accepted-nuspell-300-1-source-amd64-into-unstable-unstable/

oh, sorry.  that's too new and in these cases:
 * the BTS considers it an unknown package (and sends the report to the
   dedicated address…)
 * tracker didn't know of the new binary package yet

Thank you for digging deeper than me!

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#970441: libnuspell-dev: typo in long description: germand

2020-09-16 Thread Mattia Rizzolo
Control: tag -1 moreinfo

On Wed, Sep 16, 2020 at 02:23:24PM +0200, Jonas Smedegaard wrote:
> Package: libnuspell-dev
> Version: 3.0.0-1
> Severity: minor
> 
> Long description contains this:
> 
> > Support complex compounds (for example, Hungarian, Germand and Dutch)
> 
> There is no "d" in german.

Hi,

you filed this against libnuspell-dev, something that doesn't exists.  I
thought it was a typo for libhunspell-dev, but I can't find that
sentence nor the typo in it… so I ask you to double check your report :)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#970321: tracker should display related ITS bugs

2020-09-14 Thread Mattia Rizzolo
On Mon, Sep 14, 2020 at 12:19:57PM -0400, Antoine Beaupre wrote:
> But, critically, it does not show ITS (Intent To Salvage) bugs, which
> are (arguably) even more important.
> 
> This should be fixed, and, in general, I think that any WNPP bug
> related to a package should be displayed in the dashboard.

Techinically, ITS are not WNPP bugs (in the sense, they are not filed
against the WNPP pseudo-package).

> So it might
> be worth going over the different categories to make sure we cover
> them all (and not forget one in the future).

I haven't checked right now, but I'm positive tracker already deals with
all WNPP bugs (at the very least, O/ITA/RFA).  It also includes RFS,
which is another thing that is not a WNPP bug.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#969084: buildd.d.o: please don't use a tainted buildenv

2020-09-10 Thread Mattia Rizzolo
On Thu, Sep 10, 2020 at 02:14:57PM +0200, Aurelien Jarno wrote:
> On 2020-09-10 11:58, Holger Levsen wrote:
> > Hi,
> > 
> > On Thu, Sep 10, 2020 at 01:45:31PM +0200, Mattia Rizzolo wrote:
> > > On Wed, Sep 09, 2020 at 11:01:01AM +0200, Aurelien Jarno wrote:
> > > > Well I would say that we have a solution but not yet the patch, but
> > > > anyway I'll plan to work on writing a patch in the next days.
> > > Oh, great!
> > > thank you for being so quick!
> > 
> > indeed, thank you very much Aurelien!
> > 
> > fwiw, I also think it's fine to only have this for new
> > unstable/bullseye/bookworm/... builds.
> 
> policy-rcd-declarative is used for bullseye and sid chroots. We do not
> have bookworm chroots yet ;-)

do buildds use the sid chroots for experimental builds?

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#969084: buildd.d.o: please don't use a tainted buildenv

2020-09-10 Thread Mattia Rizzolo
On Wed, Sep 09, 2020 at 11:01:01AM +0200, Aurelien Jarno wrote:
> Well I would say that we have a solution but not yet the patch, but
> anyway I'll plan to work on writing a patch in the next days.

Oh, great!
thank you for being so quick!

> > > Improvement would be to ship
> > > that single conffile in a separate package (which, IMHO,
> > > src:policy-rcd-declarative could do, i.e. provide a
> > > "policy-rcd-declarative-deny-all" binary; or do fancy things with a
> > > debconf option sbuild-createchroot could inject but that would be too
> > > dirty for me).
> > 
> > I'm tempted to clone this bug and make the clone a wishlist bug for such
> > a "policy-rcd-declarative-deny-all" binary. What do you think?
> 
> Indeed, that would be awesome.

I opened a new bug instead, to give the policy-rcd-declarative
maintainer some context without being shoved a bugload of comments ^^

https://bugs.debian.org/970027

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#970027: policy-rcd-declarative: please provide a package with a deny-all rule

2020-09-10 Thread Mattia Rizzolo
Source: policy-rcd-declarative
Version: 0.3
Severity: wishlist
X-Debbugs-Cc: Debian Buildd Team 


Dear maintainer,

The buildd.d.o team took up on your experiment and started using this
package in place of dropping a file in the chroots' /usr/local/sbin.

See:

https://salsa.debian.org/dsa-team/mirror/dsa-puppet/-/commit/abacce72bdc2417961cab2704ef3881f6d15d654
https://bugs.debian.org/969084

In that bug I propose a further improvement, that is to provide the
deny-all configuration from a package instead of having the
configuration file manually managed.

Could you please add a binary package (that I tentatively named
policy-rcd-declarative-deny-all) providing a conffile
/etc/service-policy.d/99-buildd-deny-all
with the content
.* .* deny
?
(I named the file 99 so that the users can place their overrides first.)


Thank you for your input!

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#970016: pkg-js-tools: please add Provides: dh-sequence-nodejs

2020-09-10 Thread Mattia Rizzolo
Package: pkg-js-tools
Version: 0.9.40
Severity: wishlist

Hi Xavier,

would you please consider adding
Provides: dh-sequence-nodejs
to bin:pkg-js-tools?  That should allow nodejs packages to drop the
`--with nodejs` option in the dh call, replacing it with
`dh-sequence-nodejs` in d/control (which might mean the build-dep on
pkg-js-tools would become useless if that option was the only reason it
was addded).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#949100: clamav: loses link against libxml2 with 2.9.10 (uses xml2-config)

2020-09-05 Thread Mattia Rizzolo
On Sat, Jul 11, 2020 at 12:35:58PM +0200, Sebastian Andrzej Siewior wrote:
> I didn't do anything here because I've been told that this is Debian
> only and not blessed by XML2 upstream. Did anything change here in the
> meantime?

No, and it is indeed something that I'm pushing by myself.  Though I had
to break this "project" for a while…

> I don't like to cary that patch myself and I prefer not to
> drag ClamAV upstream into this unless there is an official statement
> from XML2 upstream.

I totally plan on writing up patches and pushing them to the several
upstreams by myself at some point, bringing my reaons to them myself.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#969084: buildd.d.o: please don't use a tainted buildenv

2020-09-05 Thread Mattia Rizzolo
On Mon, Aug 31, 2020 at 02:44:12PM +, Holger Levsen wrote:
> On Thu, Aug 27, 2020 at 04:25:56PM +0200, Guillem Jover wrote:
> > I think ideally
> > this would be using a system pathname and be part of a package that gets
> > then listed in the .buildinfo files.
> 
> I cannot comment on this except to say that I'd wish for some more pragmatism 
> :(

It's not something that I run myself, but I believe
https://tracker.debian.org/pkg/policy-rcd-declarative
is a good solution to this: install that package, then instead of
dropping that file into /usr/local/sbin/policy-rc.d, do
echo ".* .* deny" > /etc/service-policy.d/00-buildd-deny-all

That turns a non-dpkg tracked binary into a non-dpkg tracked conffile,
which I suppose it's a good compromise.  Improvement would be to ship
that single conffile in a separate package (which, IMHO,
src:policy-rcd-declarative could do, i.e. provide a
"policy-rcd-declarative-deny-all" binary; or do fancy things with a
debconf option sbuild-craetechroot could inject but that would be too
dirty for me).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#905866: uscan: prefers watch files from a random dir over debian/watch

2020-09-04 Thread Mattia Rizzolo
Hi Matthijs!

On Tue, May 12, 2020 at 03:22:01PM +0200, Matthijs Kooijman wrote:
> Turns out there was a bug with the directory checking. I submitted a fix
> here:
> 
> https://salsa.debian.org/debian/devscripts/-/merge_requests/193
> 
> That MR also has a small change to the manpage that makes it a bit more
> explicit that uscan works recursively by default.

Thank you for this, I've now merged it.

> I still think that the current default might not be ideal. However, I do
> see the usecase of running uscan over a collection of debian package at
> the same time.

Also, I personally hate changing long-standing defaults.

> Maybe the default could be changed to only scan the current directory
> *if* it is a debian source tree, and default to recursive scanning if
> not? That would support both the "Run on a single package" and "Run on a
> collection of packages" usecases neatly?

That's too surprising.  Changing behaviour that way just due to the
surrounding files is too unexpected for me.

Regardless, I'd accept an MR that would implement:

> More specifically, I would suggest:
>  - Adding a `--no-recursive` option, which will always check only the
>current dir (and probably produce an error if no valid package and
>watchfile can be found). This might be implemented as an alias for
>`--watchfile debian/watch` maybe.

this, and

>  - Adding a `--recursive` option, which ensures that recursive operation
>happens, even when the current directory is a valid source tree. This
>is what is the current default operation.

this, and

>  - Specifying more than one of `--recursive`, `--no-recursive` and
>`--watchfile` is an error.

this.

>  - When none of `--recursive`, `--no-recursive` and `--watchfile` is
>specified, the default is to use `--no-recursive` when the current
>directory is a source tree, and `--recursive` otherwise.

Don't do this, instead leave the default --recursive on.

Also perhaps add a relevant config item that would switch the default
locally, so that one can set, e.g., USCAN_RECURSIVE=no in their
~/.devscripts and have it re-enabled with --recursive as needed.

> One open question is what constitutes a "source tree" exactly for the
> purpose of the default operation. The simplest (and most conservative)
> is "Whenever a debian/ subdirectory exists", the most extensive is
> probably "When a debian/changelog exists and can be parsed and
> debian/watch exists".

[ -f debian/changelog -a -f debian/watch ] should do IMHO.  Without
parsing, it would just fail a few moments later anyway.


Thank you again for your contribution! :)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#969520: Should hunspell-se recommend or suggest giella-sme?

2020-09-04 Thread Mattia Rizzolo
On Fri, Sep 04, 2020 at 09:21:42AM +0200, Petter Reinholdtsen wrote:
> There is another North Sami package in the Archive, 
> https://tracker.debian.org/pkg/giella-sme >.  Perhaps the
> hunspell-se package should recommend or suggest this package?

I'd rather have their maintainers (aka Kartik Mistry) pop up and ask it
than a random 3rd party.
Also not when it has a RC bug pending testing removal in a couple of
weeks.

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#966825: transition: libcdio

2020-09-03 Thread Mattia Rizzolo
On Thu, Sep 03, 2020 at 06:49:54AM +, Vasyl Gello wrote:
> Hi Gabriel!
> 
> If I understand the info from tracker.d.o correctly, libcdio 2.1.0-2 migrated 
> to testing and transition is complete, isn't it?
> If that's true, can you please push buster backport?

That has nothing to do with the release team (i.e. this bug report), so
please ask in a different forum.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#969170: lintian: fpos for override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS

2020-08-28 Thread Mattia Rizzolo
Package: lintian
Version: 2.91.0

Hi,

When using debhelper compat 13 there is no need to explicitly check
DEB_BUILD_OPTIONS=nocheck, so this tag
override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS
should not be emitted in dh compat 13.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#968756: inkscape: Inkscape crash on multiple undo-redo actions

2020-08-22 Thread Mattia Rizzolo
On Fri, Aug 21, 2020 at 01:53:32AM +0200, Anon1336 wrote:
> At first, I thought it was a one-time bug so I tried using the bpo.
> Once again, under the same conditions, Inkscape crashed. Finally, I
> tried using the 1.0 AppImage (to test "sterile"  and see if this was
> Debian-specific or Inkscape in general). The result is the same. Since
> it wasn't a "world-ender" bug, I went back to using the native Debian
> bpo and decided to just save a lot (side-note: auto-save and recovery
> still occasionally fails).

Since you tried the AppImage and reproduced with that as well, could you
consider filing a bug report upstream directly at
https://gitlab.com/inkscape/inbox ?


Also, I'm uploading now 1.0-5 to backports, if you could see whether
that also triggers this crash it would be useful (1.0-2 disable a bunch
of asserts that might or might not be relevant).

> The errors (see below) point to the problem being Inkscape-specific (the core 
> lib), so it's very concerning that there's this "domino effect".
> 
> Here's the relevant dmesg outputs:
> inkscape[18142]: segfault at 148 ip 7efbfefec5db sp 7ffb9620 
> error 4 in libinkscape_base.so[7efbfe58a000+bb]
> traps: inkscape[28062] general protection fault ip:7efbfeed39a1 
> sp:7ffb8520 error:0 in libinkscape_base.so[7efbfe58a000+bb]
> 
> If I have time, I'll try running Inkscape and Thunar from two consoles and 
> try to reproduce the error. Hopefully it'll shed some light on it. Hopefully 
> still, I won't need to.

Likewise, if you can get a stacktrace it usually helps nailing down where
the bug is.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#968561: O: ibus-unikey -- Vietnamese Input Method Engine for IBus using Unikey Engine

2020-08-17 Thread Mattia Rizzolo
Package: wnpp

The current maintainer of ibus-unikey, Lê Quốc Tuấn ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: ibus-unikey
Binary: ibus-unikey
Version: 0.7.0~beta1-0.1
Maintainer: Lê Quốc Tuấn 
Build-Depends: cmake, debhelper-compat (= 12), libgtk-3-dev, libibus-1.0-dev 
(>= 1.5.22-2)
Architecture: any
Standards-Version: 4.5.0
Format: 3.0 (quilt)
Files:
 a79acf7c89668ff67c38348a1024e75b 1855 ibus-unikey_0.7.0~beta1-0.1.dsc
 a07a4f4e8368a69b6336902f278f9b92 92243 ibus-unikey_0.7.0~beta1.orig.tar.gz
 aa824a26b2b13cb1ec78060509ed380f 5168 ibus-unikey_0.7.0~beta1-0.1.debian.tar.xz
Checksums-Sha256:
 51a476b4f1fe1476f21016af0b767d8e7f7ee378dd9ebd1569722c1518785669 1855 
ibus-unikey_0.7.0~beta1-0.1.dsc
 962cb0b1e76b46ae6e6b4b694da005d13344bcfae1a65b33b5908223c04620a7 92243 
ibus-unikey_0.7.0~beta1.orig.tar.gz
 5a11dff73ff0751e9645ee9f45e556747c9e61d990465bef6de531e2ccdf01a0 5168 
ibus-unikey_0.7.0~beta1-0.1.debian.tar.xz
Homepage: https://github.com/vn-input/ibus-unikey
Package-List: 
 ibus-unikey deb utils optional arch=any
Directory: pool/main/i/ibus-unikey
Priority: source
Section: utils

Package: ibus-unikey
Version: 0.7.0~beta1-0.1
Installed-Size: 310
Maintainer: Lê Quốc Tuấn 
Architecture: amd64
Depends: libc6 (>= 2.14), libgcc-s1 (>= 3.0), libglib2.0-0 (>= 2.26.0), 
libgtk-3-0 (>= 3.0.0), libibus-1.0-5 (>= 1.5.22-2), libstdc++6 (>= 5.2), 
dconf-gsettings-backend | gsettings-backend, ibus (>= 1.5.22-2), ibus-gtk, 
ibus-gtk3
Description: Vietnamese Input Method Engine for IBus using Unikey Engine
Description-md5: 985e023e854ac292f0b39058569a0321
Homepage: https://github.com/vn-input/ibus-unikey
Tag: uitoolkit::gtk
Section: utils
Priority: optional
Filename: pool/main/i/ibus-unikey/ibus-unikey_0.7.0~beta1-0.1_amd64.deb
Size: 70968
MD5sum: 8be7187e7302f050d3657440d244b9e7
SHA256: e47e2e880c38e1dac626daf33a5d58c0fdc5dfb63069460436f2f6b61d4afa24


-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#968562: O: scim-unikey -- Vietnamese Input Method Engine for SCIM using Unikey Engine

2020-08-17 Thread Mattia Rizzolo
Package: wnpp

The current maintainer of scim-unikey, Lê Quốc Tuấn ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: scim-unikey
Binary: scim-unikey
Version: 0.3.1+debian-3.2
Maintainer: Lê Quốc Tuấn 
Build-Depends: debhelper (>= 7), autotools-dev, pkg-config, libscim-dev, 
autoconf, automake, autopoint, gettext, libtool, libltdl-dev
Architecture: any
Standards-Version: 3.9.1
Format: 3.0 (quilt)
Files:
 dc00ac2ae481dc9ffa725b7012fe42fb 1929 scim-unikey_0.3.1+debian-3.2.dsc
 e44fc9962c002124e137dcfc9028b0f7 484006 scim-unikey_0.3.1+debian.orig.tar.gz
 17d43b84c12414be17da52b89099142d 6540 
scim-unikey_0.3.1+debian-3.2.debian.tar.xz
Checksums-Sha256:
 697ef0d3a331120f5d4efe384675660726c095d4304904b86ad901715e008141 1929 
scim-unikey_0.3.1+debian-3.2.dsc
 ddc170308ade5e4239c8c2ab961ea7b24d8e5fa237bd28a3800914e45b9036bb 484006 
scim-unikey_0.3.1+debian.orig.tar.gz
 9a79e0f4dd96a7f1b3c79372bd81485063d52635b0c10fa3bb5c2563ec02 6540 
scim-unikey_0.3.1+debian-3.2.debian.tar.xz
Homepage: http://scim-unikey.googlecode.com/
Package-List: 
 scim-unikey deb utils extra arch=any
Directory: pool/main/s/scim-unikey
Priority: source
Section: utils

Package: scim-unikey
Version: 0.3.1+debian-3.2
Installed-Size: 313
Maintainer: Lê Quốc Tuấn 
Architecture: amd64
Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libglib2.0-0 (>= 2.16.0), 
libgtk-3-0 (>= 3.0.0), libscim8v5 (>= 1.4), libstdc++6 (>= 5.2), scim | skim
Description: Vietnamese Input Method Engine for SCIM using Unikey Engine
Description-md5: d1a972ca8eda60015b97b22cba4dcbd6
Homepage: http://scim-unikey.googlecode.com/
Tag: uitoolkit::gtk
Section: utils
Priority: optional
Filename: pool/main/s/scim-unikey/scim-unikey_0.3.1+debian-3.2_amd64.deb
Size: 82392
MD5sum: 291e996aac6982f154d365f2460b8047
SHA256: a39d6c38ef7dfc8b657f0f6d44262695780a94224905695879f652dfdf514ddb


-- 
regards,
            Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#968508: blender-data: Please only recommend blender instead of python3

2020-08-16 Thread Mattia Rizzolo
On Sun, Aug 16, 2020 at 05:47:17PM +0200, Elrond wrote:
> On Sun, Aug 16, 2020 at 17:35:32 +0200, Jonas Smedegaard wrote:
> > Quoting Elrond (2020-08-16 17:16:26)
> > > On the other hand, blender-data does not need to depend on python3. 
> > > Yes, there are some python scripts in there, but they do only make 
> > > sense together with blender.
> > 
> > If blender-data contains scripts which require Python3 to run, then it 
> > must declare either Depends or Recommends on python3.
> > 
> > 
> > > If you want to keep the python3 dep, please turn it into
> > > python3:any, and also into a Recommends. Recommends means
> > > "You really should install this. If you don't, expect
> > > missing functionality", which seems right then.
> > 
> > If those python3 scripts are not always used, then it makes sense to 
> > relax to only recommend python3.
> 
> TBH I am not 100% sure, if they're not always used. I might
> try sometime soon.

Either way, here is the problem:
the source control file has
Package: blender-data
Architecture: all
Depends: python3,
 ${misc:Depends},
 ${python3:Depends}
Note how it also has ${python3:Depends}.  That substvar should be
expanded to "python3:any" (with an appropriate version restriction if
deemed needed by the tooling), and the helper that is supposed to fill
in that substvar is dh_python3.
dh_python3 is already called by the rules file, but the scripts are all
in private locations; dh_python3 doesn't look into private directories
that are not named after the binary package name, so it needs to be
instructed as such, by adding an override and pass the private dirs
(looking at the file list, I guess `/usr/share/blender/scripts/` is
enough, but should be tested) as arguments of dh_python3, and then
python3:any will be added to the python3:Depends substvar.  After that,
the explicit python3 dep can go away.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#968508: blender-data: Please only recommend blender instead of python3

2020-08-16 Thread Mattia Rizzolo
On Sun, Aug 16, 2020 at 06:07:11PM +0200, Jonas Smedegaard wrote:
> Quoting Elrond (2020-08-16 17:47:17)
> > On Sun, Aug 16, 2020 at 17:35:32 +0200, Jonas Smedegaard wrote:
> > > Quoting Elrond (2020-08-16 17:16:26)
> > [...]
> > > > Installing blender-data alone doesn't make much sense. It
> > > > is most useful with the blender package.
> > > > So, please:
> > > > Recommends: blender (= ${source:Version})
> > > > Don't use "Depends", because that would introduce a
> > > > circular dependency. Which is not good.
> > > 
> > > Package relations are directional.  Since blender-data cannot use 
> > > blender for anything (data does not use apps - apps uses their data), it 
> > > is correct for blender-data to not depend on or recommend blender.
> > 
> > Well, would a Suggests make sense then?
> > So that you know, which "app" is best to use, when looking
> > at that package?
> 
> No: blends-data is data for blends to use (not data that uses blends).
> 
> It's a directional relationship: blends need its data - blends data does 
> not "need" blends, ever - not always (depends) and not mostly 
> (recommends) but also not occationally (suggests).  Instead, blends data 
> is _consumed_ by blends, i.e. gets processed by blends.

Despite not really used by any frontend that I'm aware of, IMHO the
correct relationship would be "Enhances".  But, really, it's useless.
My reading and understanding of "Enhances" is that it's the same kind of
relationship but in the opposite verse of "Suggests".


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#968344: pencil2d: please make the build reproducible

2020-08-16 Thread Mattia Rizzolo
On Thu, Aug 13, 2020 at 12:02:43PM +0100, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0] we noticed that
> pencil2d could not be built reproducibly.
> 
> While you do use SOURCE_DATE_EPOCH to populate GIT_TIMESTAMP, you omit
> the --utc flag to date(1) so the generated date will depend on the
> build system's current timezone.

Ahah, of course!

I wonder how this haven't come up earlier on but only in the last
upload, but well, thank you for saving me from invastigating this myself
:)

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#881719: libcdio 2.1.0 and lubcdio++

2020-07-10 Thread Mattia Rizzolo
On Fri, Jul 10, 2020 at 06:53:33AM +, Vasyl Gello wrote:
> Hi Gabriel!
> 
> I investigated the reprotest failure on libcdio and it seems a reborn 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795690
> Is it possible to exclude GMT-14 from reprotest or is it better to try fixing 
> upstream instead?

No, even if it was possible I'd disagree to it: why should something
knowingly fail in a known timezone?  (TBH, even exporting TZ=UTC in
d/rules is IMHO just a workaround)

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#964539: qa.debian.org: man-pages.wml uses lintian.log that went away

2020-07-08 Thread Mattia Rizzolo
Package: qa.debian.org
X-Debbugs-Cc: lint...@packages.debian.org

This seems to be the only service under qa.d.o that used
lintian.log.

lintian.log hasn't existed for several months, and now I went and
removed our copy on quantz.

We should move this service to the replacement facility the lintian
maintainers will provide in the future (the voices mention some json
file…).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#962221: Fixes for CVE-2020-13696 (#962221)

2020-07-08 Thread Mattia Rizzolo
On Wed, Jul 08, 2020 at 09:07:25AM +0100, Jeremy Sowden wrote:
...
> The new upstream release added extra checks to ensure that the object at
> the end of the path is a device file of the right sort before opening
> it:
...
> However, the error messages still leak information, allowing the user to
> test for the existence of arbitrary files:
...
> The patch changes the error messages to prevent this:
...

Oh, I think I understand now.  So I reckon with the extra patch this CVE
is fixed.

I'm going to upload this soon :)

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#962221: Fixes for CVE-2020-13696 (#962221)

2020-07-07 Thread Mattia Rizzolo
On Mon, Jul 06, 2020 at 09:07:31PM +, Vasyl Gello wrote:
> I pushed the modernized package however

..however it fails to build :)

   dh_auto_install
install -d /build/xawtv-3.107/debian/tmp
make -j4 install DESTDIR=/build/xawtv-3.107/debian/tmp 
AM_UPDATE_INFO_DIR=no
make[1]: Entering directory '/build/xawtv-3.107'
/usr/bin/install -c -d -m 755 /build/xawtv-3.107/debian/tmp/usr/bin
/usr/bin/install -c  console/dump-mixers console/record console/showriff 
console/showqt console/streamer console/webcam console/scantv console/ttv 
console/radio console/fbtv console/v4l-info 
/build/xawtv-3.107/debian/tmp/usr/bin
/usr/bin/install -c  -m4755 -o root console/v4l-conf 
/build/xawtv-3.107/debian/tmp/usr/bin
/usr/bin/install: cannot change ownership of 
'/build/xawtv-3.107/debian/tmp/usr/bin/v4l-conf': Operation not permitted
make[1]: *** [console/Subdir.mk:100: install] Error 1
make[1]: Leaving directory '/build/xawtv-3.107'
dh_auto_install: error: make -j4 install DESTDIR=/build/xawtv-3.107/debian/tmp 
AM_UPDATE_INFO_DIR=no returned exit code 2
make: *** [debian/rules:6: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


this is related to the addition of Rules-Requires-Root.  When run
without fakeroot it's not possible to run such `chmod` commands.  In
fact, they are most likely always wrong to run them anyway…

> there are two errors claiming two libs are not compiled against libc and 
> several
> others missing requured prerequisites. I have not figured yet how to fix 
> these,
> maybe you know?

I'll see them when I can fully build the package ;)


In d/copyright, that boilerplate-y thing you copied into the Comment
field, IMHO you should just get rid of it.  Also, it's missing many of
the years in the copyright claims: a copyright claim without a year is
at most an legal headache and at worst invalid.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#962221: Fixes for CVE-2020-13696 (#962221)

2020-07-06 Thread Mattia Rizzolo
On Mon, Jul 06, 2020 at 05:10:30AM +, Vasyl Gello wrote:
> Thanks for contributing the security release! I checked your changes and 
> pushed them to the team repo.
> I do not have an upload rights, so CCing Sebastian and Mattia.

Sure,

but could either of you do a bunch of housekeeping work as well, like:
 * bumping dh compat
 * drop --dbgsym-migration
 * drop the .menu files
 * would be awesome to have the copyright file rewrote using dep-5
 * 

Also, the commit adding the CVE patch mentions "partial fix", as does
the sec-tracker page.  Can anybody explain shortly what's with that,
where is the full fix (if there is), and how come the LTS upload claims
this to be fully fixed instead (CCing the LTS team and the uploader for
this).

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#964390: inkscape: Inkscape does not start: symbol lookup error

2020-07-06 Thread Mattia Rizzolo
On Mon, Jul 06, 2020 at 06:23:39PM +0200, jesusda wrote:
> Inkscape 1.0-2 does not start.
> 
> inkscape: symbol lookup error: /usr/bin/../lib/x86_64-linux-
> gnu/inkscape/libinkscape_base.so: undefined symbol:
> _ZN3Gio11Application35set_option_context_parameter_stringERKN4Glib7ustringE

This is the same of https://bugs.debian.org/961216

>   APT policy: (500, 'testing'), (500, 'stable'), (500, 'oldstable')

please beware of mixing up releases.

> ii  libglib2.0-0   2.64.3-1
> ii  libglibmm-2.4-1v5  2.54.1-3

I really wonder how you mange to mix up these.  Obviously there is a
missing versioned dependency, but your system is not fully up-to-date,
so please run apt upgrade.

Now that glibmm2.4 is fixed to generate the proper versioned dependency,
I'm going to rebuild inkscape to pick up the new dependency, fixing
this… but really, your system can be considered broken.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#936805: kodi: Python2 removal in sid/bullseye

2020-07-05 Thread Mattia Rizzolo
A few people are already working on kodi 19, and packages will start to
appear in a few days in experimental.

Actually there are related packages in NEW: dav1d was accepted a couple
days ago, shairplay and libudfread.  They are not compulsory dependencies,
so not strictly blocking, but they were uploaded for kodi to link against
them.

On Sun, 5 Jul 2020, 5:51 pm Nicholas D Steeves,  wrote:

> Hi,
>
> On Fri, Aug 30, 2019 at 07:22:18AM +, Matthias Klose wrote:
> > Package: src:kodi
> > Version: 2:17.6+dfsg1-4
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal
> >
> > Python2 becomes end-of-live upstream, and Debian aims to remove
> > Python2 from the distribution, as discussed in
> > https://lists.debian.org/debian-python/2019/07/msg00080.html
> >
> > Your package either build-depends, depends on Python2, or uses Python2
> > in the autopkg tests.  Please stop using Python2, and fix this issue
> > by one of the following actions.
> >
>
> [snip]
>
> This bug will be solved when updating to Kodi ≥ 19, which prominently
> declares it migrated to Python 3.  Of course some plugins might not be
> py3 ready, so it's probably time to stage the kodi-without-py2
> packages in experimental and report bugs upstream.
>
> The Python Team is moving ahead with making at py2 dep RC for low
> popcon leaf packages this week, and while there isn't a roadmap
> (afaik), I suspect this bug will become serious this fall (2020).
>
> Thanks,
> Nicholas
>


Bug#908814: origtargz: handle .asc upstream signatures

2020-07-01 Thread Mattia Rizzolo
On Wed, Jul 01, 2020 at 04:34:32PM +0200, Xavier wrote:
> --- a/scripts/origtargz.pl
> +++ b/scripts/origtargz.pl
> @@ -343,6 +343,7 @@ sub unpack_tarball (@) {
> 
>  for my $origtar (@origtar) {
>  my $tmpdir = File::Temp->newdir(DIR => ".", CLEANUP => 1);
> +next if $origtar =~ /\.(?:asc|sig)$/;
>  print "Unpacking $origtar\n";
>  my $cmp = ($origtar =~ /orig(?:-([\w\-]+))?\.tar/)[0] || '';
>  if ($cmp) {


Mh, but I doubt it does what this bug is about: it should *extract* the
.asc files from pristine-tar if they matches the version.  I suppose it
needs to somehow check whether the .asc is present and if it pass it via
the -s option of `pristine-tar checkout` (at line 255).

Perhaps indeed we also need this bit you proposed, though I admit I
never used --unpack :D
-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#963887: UDD: 'duck' importer broken since 2020-05-25

2020-06-30 Thread Mattia Rizzolo
On Tue, Jun 30, 2020 at 09:19:31AM +0200, Baptiste BEAUPLAT wrote:
> On 6/29/20 11:34 PM, Raphael Hertzog wrote:
> >> The duck worker has to process around 46 urls (only counting
> >> Homepage) in less than 24h.
> > 
> > How do you get to that figure? We don't have that many source package
> > and even if you consider multiple URL for each source package due to
> > changes over time (in multiple releases), that makes way too many URLs
> > per source package.
> 
> Err, sorry about that. That figure is the result of:
> 
> $ curl -s
> http://deb.debian.org/debian/dists/unstable/main/source/Sources.gz |
> zgrep -v Homepage: | sort -u | wc -l
> 458804
> 
> Which is obviously wrong. Here is the real number:
> 
> $ curl -s
> http://deb.debian.org/debian/dists/unstable/main/source/Sources.gz |
> zgrep Homepage: | sort -u | wc -l
> 26250

Just a note before you head toward implementing that: the Homepage field
is similar to Section, in the way that it can also be specified in the
binary paragraphs, not just the source paragraphs.
You can see that as the Homepage field is present in the DEBIAN binary
control field of the .debs, and clearly that value might be different
than the one in Homepage of the .dsc.

So please, look harder for Homepage, not just in the first paragraph of
d/control ;)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#963887: UDD: 'duck' importer broken since 2020-05-25

2020-06-28 Thread Mattia Rizzolo
On Sun, Jun 28, 2020 at 05:32:05PM +0200, Lucas Nussbaum wrote:
> The importer uses http://duck.debian.net/ which doesn't resolve anymore.

Some context:
 * the previous maintainer of duck.d.n retired, and as such the .d.n
   domain was removed
 * the previous maintainer was contacted to have at least access to the
   previously running code
 * it turns out said code was not freely license and as such easily
   usable by a new maintainer in a new deployment

Baptiste (CCed) volunteered to write it over again, but for now there is
no clear timeline as for when the new project will be started.

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#963765: lintian: please flag this typo of override

2020-06-28 Thread Mattia Rizzolo
On Fri, Jun 26, 2020 at 10:55:03PM -, Chris Lamb wrote:
> > Please also flag [oeverride_dh_missing].
> 
> Hm, are we sure we are likely to see this typo again soon? The "e" key
> is not near the "o" or "v" keys in QWERTY, only in Dvorak.

I assure you I'm not using Dvorak here!!
In fact I have no idea how that typo happened!  
I can only try a guess that I pressed the "e" key twice in a row
accidentally, while also pressing the "v" key…

If you think this is too improbable or anything, clearly feel free to
drop this bug away.
In fact, if one were to try to list all possible typos it would be a
never-ending effort, I acknowledge that.  I reckon the one and true way
forward would be to do pattern-matching, but then it would perhaps
starts to go a tad outside the scope of lintian.


:)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#963864: debhelper: circular dependency with dh-autoreconf/dh-stripdeterminism

2020-06-28 Thread Mattia Rizzolo
On Sun, Jun 28, 2020 at 02:50:20PM +0200, Bill Allombert wrote:
> Do you mean you plan to remove the '| debhelper' branch in the future ?
> If so when ?

In fact, I couldn't see any good reason to not just use
libdebhelper-perl only, so I went ahead and committed the change to git.

I don't thin we have any requirements to allow backporting to plain
stable without backports anyway.

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#963864: debhelper: circular dependency with dh-autoreconf/dh-stripdeterminism

2020-06-28 Thread Mattia Rizzolo
On Sun, Jun 28, 2020 at 02:34:01PM +0200, Bill Allombert wrote:
> There is a circular dependency between debhelper, dh-autoreconf and 
> dh-strip-nondeterminism:

Haven't looked at dh-autoreconf, but regarding dh-strip-nondeterminism:

> dh-strip-nondeterminism   :Depends: debhelper (>= 9.20151004), debhelper 
> (<< 12.6~)

This is just incomplete:
Depends: libdebhelper-perl | debhelper (>= 9.20151004), libdebhelper-perl | 
debhelper (<< 12.6~)

I.e., what it *really* depends on nowadays is libdebhelper-perl, not
debhelper.  That was done exactly to prevent a circular dependency.

> Circular dependencies are known to cause problems during upgrade, so we
> should try to avoid them.

Citation needed™.  There are plenty of circular dependencies in the
archive, and very few actually cause problems.
What causes problems are circular build-dependencies, that often require
some work to break every time they need to be bootstrapped.  For that
very reason, debhelper itself doesn't build-depend on neithre debhelper,
nor dh-strip-nondeterminism nor dh-autoreconf.


Can you please describe what you are really seeing and what problem you
are facing?  Else this is just an xyproblem.

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961655: debhelper: compat 13 HOME and XDG_RUNTIME_DIR are long enough to break AF_UNIX sockets

2020-06-28 Thread Mattia Rizzolo
On Sun, Jun 28, 2020 at 11:08:36AM +0200, Niels Thykier wrote:
> The relevant question here being whether /tmp is cleaned automatically
> by sbuild, pbuilder (etc.) on errors.  If it is, then this approach
> might be a non-issue.

I think nothing should start relying on chroot-controllers to clean up.
Currently the Debian build process is not defined to be contained in
such setup, and as such builds are supposed to clean after themselves.


FTR, in pbuilder /tmp by default is a random directory (i.e., there is
no tmpfs or anything else mounted on it) and as such is discarded on
exit.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#963765: lintian: please flag this typo of override

2020-06-26 Thread Mattia Rizzolo
Package: lintian
Version: 2.80.0

This MR was sent to me 
https://salsa.debian.org/multimedia-team/inkscape/-/merge_requests/2
it's doing this:

-oeverride_dh_missing:
+override_dh_missing:

ISTR there is already a tag flagging possibly wrong rules target that
are likely a typo of a dh override.  Please also flag these.


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961216: inkscape: symbol resolution problem

2020-06-24 Thread Mattia Rizzolo
Control: reassign -1 libglibmm-2.4-dev 2.56.0-1

So, talking with people over at the Gnome team, this came out:

On Fri, May 22, 2020 at 10:30:20AM +1000, Peter Eckersley wrote:
> However this somehow fixed the problem?
> 
> $ sudo apt-get build-dep inkscape
...
> The following packages will be upgraded:
...
>   libenchant-2-2 libglibmm-2.4-1v5 libgtkspell3-3-0 liblcms2-2
  ↑↑


> > _ZN3Gio11Application35set_option_context_parameter_stringERKN4Glib7ustringE

So, that set_option_context_parameter_string thing comes from Glib 2.56,
but you have this piece of glibmm at 2.54 according to your initial
post.
Indeed it seems that your system had a broken update in the past, with
way too many old packages still laying around.  I think you shold take
your time to fix it up and properly fully upgrade your system to
whatever distribution you are targetting.  Whilst this bug can be fixed,
there is not that much support around for such half-upgraded systems.

The bug actually lies in libglibmm-2.4-1v5 which is not propagating the
proper versioned dependency, so I'm reassigning this bug to them.  After
that inkscape will need a rebuild to pick it up, whever it will be.

-- 
regards,
            Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#936941: found 936941 in 2.9.10+dfsg-2

2020-06-24 Thread Mattia Rizzolo
On Tue, Jun 23, 2020 at 10:58:17PM +0200, Moritz Mühlenhoff wrote:
> With the removal of gnome-doc-utils the only remaining rdep of python-libxml2
> is gone (apart from src:chirp, but it's already uninstallable for various 
> other
> packages which have dropped Py2 support, so can be safely ignored).

There is also gimp-help still there, with a B-D-I on pyhon-libxml2.
What about that?

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#950052: please warn for files installed into /

2020-06-22 Thread Mattia Rizzolo
Noted. Let's see what it'll yield.

However, please do try to judge the proposals, instead of very blindly
implement them.  Arguing might be unproductive but, as I mentioned in the
past, generally annoying and likely inactionable tags are likewise very
unproductive for us! :)

On Mon, 22 Jun 2020, 6:24 pm Felix Lechner, 
wrote:

> Hi Mattia,
>
> On Mon, Jun 22, 2020 at 8:58 AM Mattia Rizzolo  wrote:
> >
> > I don't think I have much voice here, but tbh I feel like this is
> totally artificially adding
> > restraints that have no real reason to exist.
>
> That sweeping statement does not cover either (1) the accidental
> installation errors that can occur when people use cp(1) instead of
> install(1) to copy files, or (2) the degradation of style and
> placement logic that happens with repetitive paths.
>
> > It's alright to think that at times this might be hiding a packaging
> error, but honestly most of
> > those case are usually self-evident and IME very rarely are a real
> problem.
>
> Please remember I am closing bugs for requested features. I do not
> argue much because I find it unproductive. Instead, I implement
> everything that is remotely reasonable.
>
> I, too, have found repetitive paths annoying in the past, and have
> seen installation errors in which a destination folder was
> accidentally duplicated.
>
> Let's reserve judgment until we see how the check performs in the
> wild. In the end, you may well be right. But we don't know that yet.
>
> Kind regards
> Felix Lechner
>


Bug#950052: please warn for files installed into /

2020-06-22 Thread Mattia Rizzolo
I don't think I have much voice here, but tbh I feel like this is totally
artificially adding restraints that have no real reason to exist.

It's alright to think that at times this might be hiding a packaging error,
but honestly most of those case are usually self-evident and IME very
rarely are a real problem.

On Mon, 22 Jun 2020, 5:39 pm Felix Lechner, 
wrote:

> Hi Chris,
>
> On Mon, Jun 22, 2020 at 7:57 AM Chris Lamb  wrote:
> >
> >   P: lintian: repeated-path-segment usr usr/share/lintian/checks/usr/
> lib.pm
>
> Also solved by renaming, in commit 68b72cd0.
>
> Kind regards
> Felix Lechner
>
>


Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library

2020-06-21 Thread Mattia Rizzolo
On Mon, Jun 01, 2020 at 01:39:10PM +, Vasyl Gello wrote:
> >* d/control:
> > + Vcs-* have to point to the packaging repository, not the upstream
> >   one.  Since this is something maintained by the multimedia team
> >   (according to Maintainer) it should have a repo within the multimedia
> >   team space.
> 
> Fixed by setting Maintainer to me until I get into the team. I have not even 
> raised
> the application intent yet.

Mhh, would you please instead consider joining it now, rather than move
stuff around later?  I don't think I saw your joining mail in the last
20 days (sorry for ghosting - I had some personal matters going on).

> >* libudfread-dev.install
> > + you are installing the .a file: do you really need it?  As a personal
> >   policy I try to remove static libraries rather than adding them…
> 
> I often link software statically, especially targeting Android.
> So I guess keeping static library won't hurt as part of -dev
> package.

I see that you removed it following pabs' suggestion.  Well, just know
that whilst I generally agree with him that static libraries are usually
just an old renmant and they should be avoided, I also consider them
alright if somebody really need them (as long as they are not used to
statically link stuff within the archive).


Then, I notice that you are bumping the version while uploading to
mentors.  In the end we shall only upload a -1 with only one changelog
entry to the archive, so feel free to just remove and re-upload the -1
version to mentors (IIRC you can also just re-upload the same version
and it would overwrite it).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#962934: inkscape package contains a Debug build

2020-06-17 Thread Mattia Rizzolo
Control: found -1 1.0-1
Control: severity -1 normal

On Tue, Jun 16, 2020 at 08:01:20AM +0200, Benjamin Sygnat wrote:
> According to the Debian build logs for inkscape 1.0-1 (amd64), inkscape is
> built with the cmake option CMAKE_BUILD_TYPE=None. Effectively, this turns the
> build into a Debug build with asserts being in place, etc.

Right, but what problem is this causing to you?
I'm aware of only this related bug:
https://gitlab.com/inkscape/inkscape/-/issues/1472

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#948074: din FTBFS: cannot find X11/X.h

2020-06-13 Thread Mattia Rizzolo
I know that at the start of the year some reorganization within the X11
packages caused down FTBFS while files where being moving around.

I recommend you just close this bug.  FTR, it also builds in
reproducible-builds testing.

On Sun, 14 Jun 2020, 12:33 am Sudip Mukherjee, 
wrote:

> Hi Helmut,
>
> On Fri, Jan 03, 2020 at 06:48:06PM +0100, Helmut Grohne wrote:
> > Source: din
> > Version: 5.2.1-6
> > Severity: serious
> > Tags: ftbfs
> >
> > din fails to build from source in unstable on amd64. A build log ends
> > with:
>
> I tried building it today and there was no build failure.
>
>
> +--+
> | Summary
> |
>
> +--+
>
> Build Architecture: amd64
> Build Type: full
> Build-Space: 79072
> Build-Time: 30
> Distribution: unstable
> Host Architecture: amd64
> Install-Time: 65
> Job: din
> Machine Architecture: amd64
> Package: din
> Package-Time: 97
> Source-Version: 5.2.1-6
> Space: 79072
> Status: successful
> Version: 5.2.1-6
>
> 
>
> Can you please retry the build and confirm.
>
> --
> Regards
> Sudip
>
>


Bug#948791: xmlstarlet: diff for NMU version 1.6.1-2.1

2020-06-10 Thread Mattia Rizzolo
Control: tags 948791 + patch
Control: tags 948791 + pending
Control: tags 949513 + patch
Control: tags 949513 + pending


Dear maintainer,

I'm sponsoring the above NMU for xmlstarlet (versioned as 1.6.1-2.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
regards,
Mattia Rizzolo

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

 changelog|   77 +-
 compat   |1 
 control  |   17 +--
 copyright|2 
 patches/pkg-config.patch |  105 +++
 patches/series   |1 
 rules|7 ++-
 7 files changed, 174 insertions(+), 36 deletions(-)

diff -Nru xmlstarlet-1.6.1/debian/changelog xmlstarlet-1.6.1/debian/changelog
--- xmlstarlet-1.6.1/debian/changelog	2017-01-24 13:14:14.0 +0100
+++ xmlstarlet-1.6.1/debian/changelog	2020-05-30 15:34:58.0 +0200
@@ -1,3 +1,25 @@
+xmlstarlet (1.6.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use pkg-config to find the libxml2, libxslt and libexslt libraries
+(Closes: #948791, #949513).
+  * debian/changelog: Remove trailing whitespace.
+  * debian/control:
+- Sort Build-Depends list.
+- Drop build-dependencies on autotools-dev and dh-autoreconf.
+  The autoreconf sequence is enabled by default in debhelper >= 10.
+- Build-Depend on pkg-config.
+- Use debhelper-compat v13 instead of legacy debian/compat.
+- Raise Standards-Version to 4.5.0 from 3.9.8 (no changes needed).
+- Add Rules-Requires-Root: no.
+  * debian/copyright: Use secure HTTP protocol in the Format field.
+  * debian/rules:
+- Drop '--with autoreconf' with change to debhelper >= 10.
+- Set 0644 permissions on xmlstarlet-pad.xml and xmlstarlet-xsa.xml.
+- Do not install upstream ChangeLog. The file is empty.
+
+ -- Hugh McMaster   Sat, 30 May 2020 23:34:58 +1000
+
 xmlstarlet (1.6.1-2) unstable; urgency=medium
 
   * Bump to Standards-Version 3.9.8. No changes required.
@@ -54,7 +76,7 @@
   * Remove patch 10-add-xmlstar-fodoc-style.xsl.patch: it is not needed any
 more, xmlstar-fodoc-style.xsl is now included in upstream tarball.
   * Remove patch 20-automake-needs-pkg-tarname.patch: fixed in new release.
-  * debian/rules: exclude test log files generated during build time from 
+  * debian/rules: exclude test log files generated during build time from
 examples directory.
 
  -- Mònica Ramírez Arceda   Mon, 11 Feb 2013 17:08:46 +0100
@@ -65,18 +87,18 @@
   * Remove patch fix_inconsistency_man_page.patch: it's not needed anymore.
   * debian/docs: remove doc/callouts. This dir doesn't exist anymore.
   * Generate documentation. (Closes: #621755)
-- debian/rules: add --enable-build-docs option to configure to generate 
+- debian/rules: add --enable-build-docs option to configure to generate
   documentation.
-- debian/clean: remove upstream documentation to generate documentation 
+- debian/clean: remove upstream documentation to generate documentation
   again.
-- debian/patches/10-add-xmlstar-fodoc-style.xsl.patch: add 
+- debian/patches/10-add-xmlstar-fodoc-style.xsl.patch: add
   xmlstar-fodoc-style.xsl to be able to generate documentation.
-  * debian/patches/20-automake-needs-pkg-tarname.patch: Install 
+  * debian/patches/20-automake-needs-pkg-tarname.patch: Install
 documentation in /usr/share/doc/xmlstarlet, instead of /usr/share/doc/.
   * Update debian/xmlstarlet.doc-base.
-  * Add xsltproc, gawk, docbook-xsl-ns, fop and ghostscript as build 
+  * Add xsltproc, gawk, docbook-xsl-ns, fop and ghostscript as build
 dependencies.
-  * debian/patches/30-fix-stray-in-program.patch: Force usage2c.awk to use 
+  * debian/patches/30-fix-stray-in-program.patch: Force usage2c.awk to use
 gawk.
   * debian/patches/40-use-debian-docbook-xsl.patch: use docbook stylesheets
 from docbook-xsl-ns package.
@@ -86,7 +108,7 @@
 
 xmlstarlet (1.3.1-3) unstable; urgency=low
 
-  * Remove debian/menu file: xmlstarlet does not do anything useful if invoked 
+  * Remove debian/menu file: xmlstarlet does not do anything useful if invoked
 without arguments. (Closes: #673716)
 
  -- Mònica Ramírez Arceda   Sat, 23 Jun 2012 17:58:15 +0200
@@ -111,7 +133,7 @@
 xmlstarlet (1.3.0-1) unstable; urgency=low
 
   * New upstream release.
-- Work around libxml bug that passes bogus data 
+- Work around libxml bug that passes bogus data
   to error handler (Closes: #642523)
 
  -- Mònica Ramírez Arceda   Thu, 06 Oct 2011 11:22:27 +0200
@@ -126,7 

Bug#926409: lintian: autopkgtest takes very long to finish

2020-06-02 Thread Mattia Rizzolo
On Wed, 3 Jun 2020, 1:09 am Felix Lechner, 
wrote:

> Hi Chris,
>
> On Fri, Apr 5, 2019 at 4:33 AM Iain Lane  wrote:
> >
> > We do similar in some pkg-gnome packages, for example glib2.0 ships a
> > -tests package that contains "installed tests" which are compiled as
> > part of the package build and then executed during the autopkgtests.
>
> Should we ship all built test packages as part of our releases? I
> can't think of a better way to close this bug.


Now lintian autopkgtests take approximately 1 hour everywhere I checked.
Honestly, I believe 1 hour to be acceptable.


>


Bug#961919: RFS: shairplay/1.0-1 [ITP] -- AirPort Express server emulator.

2020-06-01 Thread Mattia Rizzolo
Control: owner -1 !
Control: tag -1 moreinfo

On Sun, May 31, 2020 at 02:33:33PM +, Vasyl Gello wrote:
>   dget -x 
> https://mentors.debian.net/debian/pool/main/s/shairplay/shairplay_0.9.0+git20180824-1.dsc

* d/control:
 + vcs is set to your private space, but the package is team maintained
 + why did you decide to use "shairplay-bin" instead of just
   "shairplay"?
 + drop the full stops from the synopsis (lintian flags this, didn't you
   see it?)
* d/changelog:
 + it's not closing an ITP
* d/libshairplay-dev.install:
 + same as the other pacakge regarding the .a file.
* d/shairplay-bin.install:
 + imho, you could just reduce the line length with "usr/bin" and
   "usr/share/man" without specifying the single files, since there is
   no risk here to pick up stuff from other binary packages accidentally
* d/rules:
 + beware of what that dh_installdocs call you did actually do.  I
   believe you don't want that.  hint: check the package contents.
 + you are -X'ing the .la file in dh_install?  is that really needed?
 + same as the other package regarding dh_missing.
* d/patches:
 + did you forward them?  if you did please add some headers following
   DEP-3.
* d/watch:
 + since now uscan supports scanning bare git repositories, I think you
   should add a watchfile novertheless


Incidentally, the git repository and what you uploaded to mentors are
slightly different:

|--- shairplay-0.9.0+git20180824/debian/control  2020-05-31 02:00:00.0 
+0200
|+++ shairplay-0.9.0+git20180824/debian/control  2020-05-31 02:00:00.0 
+0200
|@@ -34,7 +34,7 @@
|  .
|  Currently only AirPort Express emulation is supported.
|  .
|- This package installs the shairplay server executable
|+ This package installs the shairplay server executable.
|
| Package: libshairplay-dev
| Architecture: any

:P


NOTE: I haven't reviewd the copyright yet.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library

2020-06-01 Thread Mattia Rizzolo
Control: owner -1 !
Control: tag -1 moreinfo

On Sun, May 24, 2020 at 12:11:42PM +, Vasyl Gello wrote:
>   dget -x 
> https://mentors.debian.net/debian/pool/main/libu/libudfread/libudfread_1.0.0-1.dsc

* d/control:
 + Vcs-* have to point to the packaging repository, not the upstream
   one.  Since this is something maintained by the multimedia team
   (according to Maintainer) it should have a repo within the multimedia
   team space.
 + Homepage points to the upstream VCS: doesn't this project have a real
   homepage?
 + Both descriptions are way way too short (1 line). please strive to
   find at least 3 lines...
* d/*.dirs
 + those two files are totally useless, get rid of them
* libudfread-dev.install
 + you are installing the .a file: do you really need it?  As a personal
   policy I try to remove static libraries rather than adding them…
* d/changelog:
 + Please add the "Initial upload" words in there :)
* d/rules:
 + since you are using dh compat 13, you can go and use
   "execute_before_dh_installexamples" instead of the current override
 + you may prefer to add that .la file in d/not-installed instead of
   overriding dh_missing that way (also relevant if you stop installing
   the .a file).
* d/copyright:
 + I see that debian/* has a different license than the rest of the
   package.  Theoretically that might cause issue if for example sombody
   writes a patch for debian, place it under the debian/* license (GPL2+
   in this case).  That patch then it would taint the upstream license,
   as combining code with LGPL2.1 and GPL2+ leads to something that is
   only GPL2+, likely something that upstream wouldn't want.
 + furthermore, the project is not released under LGPL-2.1, but
   LGPL-2.1+ ... please pay attention to these details
 + in the copyright you wrote "2014-2020 VLC authors and VideoLAN", but
   I can't find any year later than 2017.  Lastly, I see all files have
   only one "Author:" listead in them, I'd find nice if you added at
   least a Comment: line in that "Files: *" paragraph mentioning that
   single author.
 + you missed m4/attributes.m4 - please take note that that GPL-2+ file
   has a special exception
* you uploaded a .asc file, but you have not provided either public
  signing key in d/upstream/signing-key.asc nor set an appropriate pgp
  option in d/watch.  Nor I can find any signature on the upstream
  repository (note that I haven't tried to check the signature).  Where
  is it coming from?


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961429: Subject: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.

2020-05-31 Thread Mattia Rizzolo
On Sun, May 31, 2020 at 02:54:34PM +, Vasyl Gello wrote:
> I do still appreciate additional reviews on packaging and security of
> cryptopass, because I thought it could be a great example of "making a
> small pavkage to learn Debian packaging".

From my side, the only thing that I would have to say about the new
release, is that since there is now an upstream testsuite, it would be
good to have an autopkgtest.
Apart from that, I notice that some of my previous comments have not
been applied, but those are not new by definition :)

I reckon that asking for review of a small package is indeed a great way
to learn; nevertheless, thank you for thinking more deeply about the
package and retract the RFS.

I would have also wanted to ask you to close this RFS, but I see bartm's
script is too quick these days, removing the package as soon as you
removed it from mentors u.U

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#938451: scribus: Python2 removal in sid/bullseye

2020-05-31 Thread Mattia Rizzolo
Indeed there is the option for me to package a SVN checkout, but I really
don't quite like that option if I can save it, since there are quite a few
changes since 1.5.5 and I'm sure upstream won't be keen on supporting that.

Note that it's possible that the next release will be 1.6.0, not 1.5.6
(i.e. fully considered production ready, the 1.5.5 I was forced to upload
due to the Qt4 deprecstion is not officially considered "production ready").


On Sun, 31 May 2020, 1:00 pm Philip Rinn,  wrote:

> Control: usertag -1 + py3available
>
>
> Hi,
>
> just to keep the bug report up to date: the upcoming version of Scribus
> (1.5.6)
> will be ready for Python3, see
>
> http://lists.scribus.net/pipermail/scribus/2019-October/055776.html
>
> No idea when it will be released though.
>
> Best,
> Philip
>


Bug#961868: release.debian.org: RM: broccoli, broccoli-python, broccoli-ruby

2020-05-30 Thread Mattia Rizzolo
Control: reassign -1 ftp.debian.org
Control: clone -1 -2 -3
Control: retitle -1 RM: broccoli -- ROM; deprecated
Control: retitle -2 RM: broccoli-python -- ROM; deprecated
Control: retitle -3 RM: broccoli-ruby -- ROM; deprecated
Control: block -1 by -2 -3

On Sat, May 30, 2020 at 06:00:34PM +0200, Hilko Bengen wrote:
> Package: release.debian.org
> 
> Please remove broccoli, broccoli-python, broccoli-ruby from unstable.
> These packages have been deprecated upstream.

removals from unstable are handled by the ftp masters, reassigning (and
retitling correctly, they like one bug per source package).

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961029: Request for new mailing list: debian-ai

2020-05-27 Thread Mattia Rizzolo
On Wed, May 27, 2020 at 07:58:37PM +0900, Norbert Preining wrote:
> let me support this request.

I likewise want to support this request.

> Hitherto there is no dedicated ML for AI/ML, one of the most active
> areas. In Debian we should strive for better support of AI/ML tools!

I have several acquaintances studying or working on ML/AI stuff, and I'm
always flustered that nothing of what they need is already in Debian (or
if it is it's in a way that's useless to them).  I totally support any
kind of movement towards improving this area!

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.

2020-05-27 Thread Mattia Rizzolo
On Wed, May 27, 2020 at 06:46:42AM +, Vasyl Gello wrote:
> BTW I fixed all the stuff GCC 8.3.0 reported me with FORTIFY_SOURCE=2 before 
> pushing code to GitHub.
> Did you use GCC 10?

I just used the current default in Debian sid, which is GCC 9.

You should be building your packages in a chroot (possibly using wrapper
tools such as pbuilder or sbuild) to, as from what you said you aren't
building them in sid.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.

2020-05-26 Thread Mattia Rizzolo
Control: owner -1 !
Control: tag -1 moreinfo

On Sun, May 24, 2020 at 02:22:42PM +, Vasyl Gello wrote:
> I am looking for a sponsor for my package "cryptopass"

o/

>  * Vcs : https://salsa.debian.org/basilgello-guest/cryptopass

I'm mostly looking at the VCS, but I'm not ignoring the regular source
package either.


Things:

 * you are not using git-buildpackage, instead everything is just thrown
   into the master branch.  Please look into gbp.  Since this is a
   totally new package, I'm actually recommending you just destroy this
   repository and create it anew, starting with a blank
   `gbp import-orig`.
   Please also enable pristine-tar in your local configuration unless
   you have a reason not to, and I also recommend you put
   "sign-tags = True" in the DEFAULT section as well.
 * d/control:
   + any reason not to go to compat 13?
   + just to please my OCD, could you please move the Section field up
 next to Priority?  (this is just me, I just can't look at that! :|)
   + on that note, you should review the Section, since this is not a
 library from what I can see
   + the synopsis is not a sentence, as such it shouldn't end with a
 full stop
   + also in the synopsis, grammar improvement: s/for generating/to
 generate/
   + in contrast, the long description is made up of whole sentences,
 but it's not really flowing: "This program can be used to generate
 passwords from a seed composed by:  " is more welcoming to read
 than your initial line
  * d/changelog:
+ Make that only "Initial upload.  Closes: #xxx", no need for 3
  lines and "initial upload" is kind of standard.
  * d/copyright:
+ place the full local URI for the Apache-2.0 License
+ likewise for the CC0, you only wrote the remote URL
+ you assert that lib/base64/* is BSD-3-clause, but I can't really
  say it by looking at the source.  Since you are upstream, I urge
  you to include an extra file (like the referenced README?)
  explaining the origin of those bundled files
  * d/rules:
+ you have clearly copied this file from somewhere without
  understanding it… didn't you?
+ that DH_OPTIONS export to make "some magic below work", do you
  know what?  AFAIK it's pretty useless as it is, so please drop
  that
+ also go read the section "COMPATIBILITY LEVELS" of debhelper(7),
  to discover that starting with compat 10 "--with autoreconf" is
  implied
+ can you please explain what's so special of this package that you
  don't want to call ldconfig?  Since it's something so odd there
  ought to be a comment.
  * d/upstream/metadata:
+ Contact is obsoleted by Upstream-Contact in d/copyright (avoids
  duplication)
  * building the package shows this "scary" GCC warning:
|In file included from /usr/include/string.h:495,
| from cryptopass.c:19:
|In function 'strncpy',
|inlined from 'main' at cryptopass.c:200:9:
|/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: 
'__builtin___strncpy_chk' specified bound depends on the length of the source 
argument [-Wstringop-overflow=]
|  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos 
(__dest));
|  |  ^~
|cryptopass.c: In function 'main':
|cryptopass.c:191:25: note: length computed here
|  191 | passlenbuflen = strlen(argv[3]);
|  | ^~~



Overall all of the above are indeed trivial matters, but this is
likewise a very trivial project to package.

One thing I have to think about is if this is something that debian
would benefit to have.  I'm not really security-minded, so I tend to be
wary about anything that tried to do crypto or handling passwords.  I
hope some random 3rd party will tell me that this is fine ^^

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961609: Updating the xsunpinyin Uploaders list

2020-05-26 Thread Mattia Rizzolo
Source: xsunpinyin
Version: 2.0.3-6
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Liang Guo  has retired, so can't work on
the xsunpinyin package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961613: Updating the ocserv Uploaders list

2020-05-26 Thread Mattia Rizzolo
Source: ocserv
Version: 0.12.6-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Liang Guo  has retired, so can't work on
the ocserv package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961612: Updating the spice-html5 Uploaders list

2020-05-26 Thread Mattia Rizzolo
Source: spice-html5
Version: 0.1.7-4
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Liang Guo  has retired, so can't work on
the spice-html5 package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961616: Updating the fcoe-utils Uploaders list

2020-05-26 Thread Mattia Rizzolo
Source: fcoe-utils
Version: 1.0.32+git20190507.9834b34-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Liang Guo  has retired, so can't work on
the fcoe-utils package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961615: Updating the ibus-sunpinyin Uploaders list

2020-05-26 Thread Mattia Rizzolo
Source: ibus-sunpinyin
Version: 2.0.3+git20181120-5
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Liang Guo  has retired, so can't work on
the ibus-sunpinyin package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961610: Updating the tigervnc Uploaders list

2020-05-26 Thread Mattia Rizzolo
Source: tigervnc
Version: 1.10.1+dfsg-3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Liang Guo  has retired, so can't work on
the tigervnc package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961611: Updating the sunpinyin Uploaders list

2020-05-26 Thread Mattia Rizzolo
Source: sunpinyin
Version: 3.0.0~rc1+ds1-3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Liang Guo  has retired, so can't work on
the sunpinyin package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961614: Updating the lldpad Uploaders list

2020-05-26 Thread Mattia Rizzolo
Source: lldpad
Version: 1.0.1+git20200210.2022b0c-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Liang Guo  has retired, so can't work on
the lldpad package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961608: O: herculesstudio -- Hercules GUI front-end

2020-05-26 Thread Mattia Rizzolo
Package: wnpp

The current maintainer of herculesstudio, Liang Guo ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: herculesstudio
Binary: herculesstudio
Version: 1.5.0-2
Maintainer: Liang Guo 
Build-Depends: debhelper (>= 7.0.50~), qt5-qmake, quilt (>= 0.48-7~), 
qtbase5-dev
Architecture: any
Standards-Version: 3.9.5
Format: 3.0 (quilt)
Files:
 ffc12fc3d131261b4a6821cbaae9bace 1953 herculesstudio_1.5.0-2.dsc
 0f44bbba6c9ea0217a14d2f6560213ba 368486 herculesstudio_1.5.0.orig.tar.gz
 8ea6e78f6e9e94b558b6ffd7d2345fb6 6616 herculesstudio_1.5.0-2.debian.tar.xz
Vcs-Browser: 
http://anonscm.debian.org/gitweb/?p=collab-maint/herculesstudio.git;a=summary
Vcs-Git: git://anonscm.debian.org/collab-maint/herculesstudio.git
Checksums-Sha256:
 5be5e46b98d71d8ab24f2141a040c54c46491fa2e42fccde7b5feaf6a32033d9 1953 
herculesstudio_1.5.0-2.dsc
 8cb57cd64bde1881f8896560381e8c40d9b75cd97b8cb4e5d6efdfadb65f8698 368486 
herculesstudio_1.5.0.orig.tar.gz
 d08359db52487a7e5131abe179613fc8880b7ed75d42a525024763cb98b5463c 6616 
herculesstudio_1.5.0-2.debian.tar.xz
Homepage: http://www.mvsdasd.org/hercstudio/
Package-List: 
 herculesstudio deb otherosfs extra arch=any
Directory: pool/main/h/herculesstudio
Priority: source
Section: otherosfs

Package: herculesstudio
Source: herculesstudio (1.5.0-2)
Version: 1.5.0-2+b3
Installed-Size: 1886
Maintainer: Liang Guo 
Architecture: amd64
Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libqt5core5a (>= 5.12.2), 
libqt5gui5 (>= 5.2.0) | libqt5gui5-gles (>= 5.2.0), libqt5network5 (>= 5.0.2), 
libqt5widgets5 (>= 5.11.0~rc1), libstdc++6 (>= 5.2), hercules (>= 3.07-2.1)
Description: Hercules GUI front-end
Description-md5: b0643232eedc59a37d975820c4239154
Homepage: http://www.mvsdasd.org/hercstudio/
Tag: admin::virtualization, implemented-in::python, interface::graphical,
 interface::x11, role::program, suite::openstack, system::cloud,
 system::virtual, uitoolkit::qt, x11::application
Section: otherosfs
Priority: optional
Filename: pool/main/h/herculesstudio/herculesstudio_1.5.0-2+b3_amd64.deb
Size: 507824
MD5sum: 9374d1fdbd1b0671c78bc8300433ede6
SHA256: 90a52b1c3c2e9670c01c4c24293e83e0f6c423c2a0d419359f0f243747f11239


-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961568: O: httpry -- HTTP logging and information retrieval tool

2020-05-26 Thread Mattia Rizzolo
Package: wnpp

The current maintainer of httpry, Janos Guljas ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: httpry
Binary: httpry, httpry-dbg, httpry-daemon, httpry-tools
Version: 0.1.8-1
Maintainer: Janos Guljas 
Build-Depends: debhelper (>= 9), libpcap0.8-dev
Architecture: any all
Standards-Version: 4.0.0
Format: 3.0 (quilt)
Files:
 1a617ff2ebbdffcc92b482dbb149a7fd 2020 httpry_0.1.8-1.dsc
 a759a1e89dbfe475c4db33bd136e0b93 49815 httpry_0.1.8.orig.tar.gz
 a5b776b45e11710ca299fe120d151d62 8160 httpry_0.1.8-1.debian.tar.xz
Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/httpry.git
Vcs-Git: git://anonscm.debian.org/collab-maint/httpry.git
Checksums-Sha256:
 4c74a1f2583443a19c0095e70b0d1918ea032d2de3474fcf6042748347c9fe1c 2020 
httpry_0.1.8-1.dsc
 b3bcbec3fc6b72342022e940de184729d9cdecb30aa754a2c994073447468cf0 49815 
httpry_0.1.8.orig.tar.gz
 f98befbac327e33201c36439b7a9423c987882120d442faee71ae0a926464414 8160 
httpry_0.1.8-1.debian.tar.xz
Homepage: http://dumpsterventures.com/jason/httpry/
Package-List: 
 httpry deb net optional arch=any
 httpry-daemon deb net optional arch=all
 httpry-dbg deb debug extra arch=any
 httpry-tools deb net optional arch=all
Directory: pool/main/h/httpry
Priority: source
Section: misc

Package: httpry
Source: httpry (0.1.8-1)
Version: 0.1.8-1+b1
Installed-Size: 86
Maintainer: Janos Guljas 
Architecture: amd64
Depends: libc6 (>= 2.4), libpcap0.8 (>= 0.9.8)
Suggests: httpry-daemon, httpry-tools
Description: HTTP logging and information retrieval tool
Description-md5: 33636b7f430c389ab37a3866f20e2fb6
Homepage: http://dumpsterventures.com/jason/httpry/
Section: net
Priority: optional
Filename: pool/main/h/httpry/httpry_0.1.8-1+b1_amd64.deb
Size: 32164
MD5sum: f90a71e8102651cc94520bb56c0c79cd
SHA256: 440abf9da843c81b58bfc4611f5512bc4049f5b145fec3e692081935ad2a91b4

Package: httpry-dbg
Source: httpry (0.1.8-1)
Version: 0.1.8-1+b1
Installed-Size: 76
Maintainer: Janos Guljas 
Architecture: amd64
Depends: httpry (= 0.1.8-1+b1)
Description: HTTP logging and information retrieval tool - debug symbols
Description-md5: bb5f3438557ad5d8523c1ac3c7d4f04f
Homepage: http://dumpsterventures.com/jason/httpry/
Build-Ids: b207a3d972bbab6700f435e2f361a1b9bf3e01e3
Tag: role::debug-symbols
Section: debug
Priority: optional
Filename: pool/main/h/httpry/httpry-dbg_0.1.8-1+b1_amd64.deb
Size: 52668
MD5sum: 4f29b05648134aa8f3606a27bb4f1b94
SHA256: 5367a320bebc5f60b67ef67fa22f6289adb235544239846d591be1621993a67a

Package: httpry-daemon
Source: httpry
Version: 0.1.8-1
Installed-Size: 30
Maintainer: Janos Guljas 
Architecture: all
Depends: httpry (>= 0.1.8-1), lsb-base (>= 3.0-6)
Breaks: httpry (<= 0.1.7-2)
Description: HTTP logging and information retrieval tool - daemon
Description-md5: c758e141aa5ce9332447ede6604262f6
Homepage: http://dumpsterventures.com/jason/httpry/
Section: net
Priority: optional
Filename: pool/main/h/httpry/httpry-daemon_0.1.8-1_all.deb
Size: 8700
MD5sum: b743d95cda88f04f6626e7e4ef845a85
SHA256: 1ddb2929dfbc1186fc046829928652b7de7b1fc46d6238cd5879ce16823f698d

Package: httpry-tools
Source: httpry
Version: 0.1.8-1
Installed-Size: 109
Maintainer: Janos Guljas 
Architecture: all
Depends: perl:any
Description: HTTP logging and information retrieval tool - log parsing scripts
Description-md5: fcf4061091cfe79e33d31f3e05391607
Homepage: http://dumpsterventures.com/jason/httpry/
Section: net
Priority: optional
Filename: pool/main/h/httpry/httpry-tools_0.1.8-1_all.deb
Size: 21612
MD5sum: e043d7528f2912a0be617eada84b3891
SHA256: 40ef4ca086c8ba6f711eb4b57415b05c1cafe1a7c6506ff40a6db3ec310321a3


-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961532: devscripts: Missing package relation with pristine-tar (used by origtargz)

2020-05-25 Thread Mattia Rizzolo
Control: severity -1 minor

On Mon, May 25, 2020 at 08:02:59PM +0200, Axel Beckert wrote:
> to my surprise the devscripts has no package relation with pristine-tar
> nor is it mentioned in devscripts' long package description despite
> origtargz uses it unconditionally. pristine-tar is though mentioned in
> the origtargz(1) man page and changelog.Debian.gz.
> 
> origtargz though ignores any errors from the pristine-tar (not sure if
> feature or bug ;-), so a missing pristine-tar binary is not noticed
> during usage as origtargz just falls back to other acquisition methods.

It's a documented feature.
origtargz tries to obtain the tarball, and just falls back through
several retrival methods.  As such, the pristine-tar is entirely
optional.

> I hence suggest as fix for this bug to add pristine-tar to either
> Suggests or Recommends and mention it in the long package description as
> optional (but IMHO for origtargz recommended) dependency of origtargz.

Done, as recommends. See the README file for a description of the whole
thing (which is then partially mirrored in the long description)

> So while the RC severity is theoretically correct due to a missing
> package relation, I have no issue if someone prefers to downgrade this
> bug to e.g. important as it IMHO is not needed to prepare a devscripts
> upload now just because of this bug report.

Indeed, RC is way too overblown for such optional feature :3


Thank you for your report!

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961258: [ubuntu-dev] Bug#961258: gdebi: -V is ignored in pypy3compile on install

2020-05-24 Thread Mattia Rizzolo
Control: reassign -1 dh-python
Control: forcemerge 961261 -1
Control: affects 961261 obs-studio gdebi

On Fri, May 22, 2020 at 07:50:23AM +, Witold Baryluk wrote:
> Package: gdebi
> Version: 0.9.5.7+nmu3
> Severity: minor
> 
> Dear Maintainer,
> 
> Setting up gdebi (0.9.5.7+nmu3) ...
> -V is ignored in pypy3compile

You seem to have filed many similar bugs, please reassign and merge them
all with 961261 (and set appropriate "affects").

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#961216: inkscape: symbol resolution problem

2020-05-21 Thread Mattia Rizzolo
Control: tag -1 moreinfo unreproducible

On Thu, May 21, 2020 at 11:34:49PM +1000, Peter Eckersley wrote:
> Package: inkscape
> Version: 1.0-1
> Severity: grave
> Justification: renders package unusable
> 
> $ inkscape
> inkscape: symbol lookup error:
> /usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so:
> undefined symbol:
> _ZN3Gio11Application35set_option_context_parameter_stringERKN4Glib7ustringE

I can't reproduce this.

That symbol is
Gio::Application::set_option_context_parameter_string(Glib::ustring const&)
which obviously comes from this library you are also listing:

> libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
> (0x7f7eda043000)

Which seems to be installed:

> ii  libglib2.0-0   2.64.2-1


Regardless it's odd, obviously it works for me and many other people,
such bug would have drawn many others to complain.
Please double check your Glib installation…

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#960955: inkscape: crash when resizing canvas on a system running wayland

2020-05-20 Thread Mattia Rizzolo
On Tue, May 19, 2020 at 10:19:40AM -0700, Diane Trout wrote:
> I mentioned this in the upstream report but the flatpak version from
> flathub does seem to work.

That's because the Debian toolchain by default passes
-DCMAKE_BUILD_TYPE=None
to cmake while building, which in the case of inkscape is pretty much
the same as passing -DCMAKE_BUILD_TYPE=Debug.
The flatpak is built with -DCMAKE_BUILD_TYPE=Release, which disables the
asserts therefore it doesn't crash.

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#960987: RFS: inkscape/1.0-1~bpo10+1 -- vector-based drawing program

2020-05-19 Thread Mattia Rizzolo
Control: close -1

Hi here,

On Tue, May 19, 2020 at 05:27:34AM +0100, Phil Wyett wrote:
>   dget -x 
> https://mentors.debian.net/debian/pool/main/i/inkscape/inkscape_1.0-1~bpo10+1.dsc
> 
> Changes since the last upload:
> 
>* Rebuild for buster-backports.
>* d/control: Use build dep 'debhelper-compat (=12)'.
>* d/rules: Use 'override_dh_dwz' to disable debug symbol compression.

Thanks for this, but I went ahead and did it myself.
Mostly because I see no reason to revert the debhelper compat bump, and
I wanted to look for myself at dwz failing (I will add it to d/rules
directly on the next unstable upload, conditionally disabling dwz on
buster-backports builds).  So overall it was just quicker for me to do
the work.


Since this is a new backport it will have to go through NEW, expect to
find it availalbe within a week.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#960955: inkscape: crash when resizing canvas on a system running wayland

2020-05-19 Thread Mattia Rizzolo
Control: forwarded -1 https://gitlab.com/inkscape/inkscape/-/issues/1472
Control: tags -1 upstream

On Mon, May 18, 2020 at 11:22:23AM -0700, Diane Trout wrote:
> On a system running wayland with dual monitors, when I open an inkscape
> document and press 5 to resize to my screen inkscape crashes.
> 
> Originally I thought it was my document that was causing problems but I could
> reproduce it with the default blank document you get when running inkscape 
> with
> no arguments.

Thank you.
I believe this report is the same of the one I linked above, so I added
a comment there.

I recommend you follow up directly with upstream to seek a solution to
this.

>   APT policy: (500, 'testing-debug'), (500, 'oldstable-debug'), (500, 
> 'testing'), (500, 'stable'), (110, 'unstable'), (100, 'experimental')

BTW, I recommned you get rid of at least oldsable here ^^
(and I trust you know what you are doing mixing several release
repositories…)

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#960105: [Pkg-javascript-devel] Bug#960105: node-redis: autopkgtest regressions against Redis 6.x

2020-05-12 Thread Mattia Rizzolo
Control: severity -1 serious
Control: affects -1 src:redis

On Tue, May 12, 2020 at 09:18:01AM +0100, Chris Lamb wrote:
> severity 960105 important

By virtue that this bug prevents a package from migrating to testing,
autopkgtest failures are RC :)

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#959885: inkscape: crashes when called without X server

2020-05-10 Thread Mattia Rizzolo
Control: tag -1 moreinfo unreproducible
Control: forwarded -1 https://gitlab.com/inkscape/inbox/-/issues/2755

On Wed, May 06, 2020 at 05:05:03PM +0200, Ole Streicher wrote:
> I use inkscape when building the debian-astro package to convert our
> logo from svg into several end user formats (pdf, png).
> 
> This doesn't work any longer, since inkscape crashes when called without
> an X server, even when the gui is not used (and not displayed) at all:
> 
> When trying with a running X server, the program works, but the X server
> does not display anything from inkscape.
> 
> This significantly complicates the usability of inkscape for batch
> processing.

Whilst indeed I see the same errors, I don't see a crash: the program
exists with 0, and the pdf is correctly produced.

Is it actually crashing in your case?  How's the pdf?

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#960154: UDD table no longer populated

2020-05-09 Thread Mattia Rizzolo
clone 960154 -1
retitle 960154 lintian: please provide a stable, parsable output
reassign -1 qa.debian.org
user qa.debian@packages.debian.org
usertags -1 udd
block -1 by 960154
retitle -1 udd.debian.org: change the lintian importer to use the new export 
file
thanks

On Sat, May 09, 2020 at 11:37:52PM +, Jelmer Vernooij wrote:
> Not sure whether to file this against UDD or lintian or detagtive; filing it
> against lintian since it changed more recently and I suspect that's related.

It was caused by a change in lintian, but it will have to be fixed in
both lintian and udd.

> For a while now, the UDD tables for lintian have been empty. They were
> previously populated with lintian data.

This was discussed recently in #-qa.
The frontend rewrite lechner did, completely removed the logs.gz that
was used by udd (and not only udd, I fear…)

I believe the first step is going to have lintian decide on a nice
machine-parsable (text!) format and publish that; then udd will adopt
its importer.


(PS, lechner: I went looking in lindsay to see if there was already a
replacement for the logs.gz file, and I noticed that the files under
/srv/lintian.debian.org/ are all with mixed ownership lintian:lintian
and lechner:lintian that might not be a issue right now since you
are the only one working on that part of lintian, but it's not quite
nice to any other team member in the future, even if the umask seems to
allow all team members to edit those files; I recommend you take on the
habit to deploy that stuff entirely under the role account.)


-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#960118: ifupdown: ifup doesn't check if /etc/network/if-%s.d exists before running run-parts

2020-05-09 Thread Mattia Rizzolo
Package: ifupdown
Version: 0.8.35
Severity: important

I've just hardly bit by a system in which for some reason yet to
discover the otherwise empty directory /etc/network/if-pre-up.d/ was
removed.
At the next boot, the network didn't come up because of
May  9 14:15:55  ifup[310]: run-parts: failed to open directory 
/etc/network/if-pre-up.d: No such file or directory

Looking at the code,
https://sources.debian.org/src/ifupdown/0.8.35/execute.c/?hl=181#L181
|static int execute_scripts(interface_defn *ifd, execfn *exec, char *opt) {
|...
|char *command;
|if(asprintf(, "/bin/run-parts %s%s/etc/network/if-%s.d", 
ignore_failures ? "" : "--exit-on-error ", verbose ? "--verbose " : "", opt) == 
-1)
|err(1, "asprintf");
|int result = (*exec) (command);
|...
|return ignore_failures ? 1 : result;
|}

Now, `run-parts` just fails if you pass a non-existing directory.

I believe you should check for the directory existence before trying to
run run-parts on it.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#960058: vim: wrong highlight for some d/rules targets

2020-05-09 Thread Mattia Rizzolo
On Sat, May 09, 2020 at 09:32:04AM -0400, James McCoy wrote:
> May Mattia, I'd like you to meet April Mattia.  He had the same problem.
> :)

uhuh
Clearly my memory is falling behind :3

> This should be fixed by my pending Vim upload.

Thank you! :)

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#960036: inkscape takes 100% CPU when opening font combobox

2020-05-08 Thread Mattia Rizzolo
On Fri, May 08, 2020 at 09:25:13PM +0200, Antonio wrote:
> After several tests I realized that the problem depends on these fonts:
> "fonts-noto, fonts-noto-cjk, fonts-noto-cjk-extra, fonts-noto-color-emoji,
> fonts-noto-core, fonts-noto-extra, known-fonts-hinted, known-fonts-mono,
> known-fonts-ui-core, known-fonts-ui-extra, known-fonts-unhinted ".
> Once removed, everything works fine.

Ohh, this is very interesting.
Could you please share this in the upstream bug I linked before, or
would you prefer me to proxy the message?

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#960036: inkscape takes 100% CPU when opening font combobox

2020-05-08 Thread Mattia Rizzolo
Control: tag -1 -moreinfo
Control: forwarded -1 https://gitlab.com/inkscape/inkscape/-/issues/841
Control: severity -1 normal

On Fri, May 08, 2020 at 07:55:19PM +0200, Antonio wrote:
> >Could you please provide us:
> >fc-list | wc -l
> 4083

Indeed, that's considered a lot.  For comparison, I have 481 :)

In theory, if you leave the program at it long enough (which effectively
means you won't be able to use the system during that time...) it should
finish and be able to generate all the previous.  Also, that would be a
one-time thing the first time you open the font selector.
Also, if you manage to close the drop-down it should likewise
"unfreeze".  Another workaround is to disable the generation of the font
previews.

See the above upstream bug about this.

I recommend you follow up directly in the upstream bug I posted above if
you have any other information. :)

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#960036: inkscape takes 100% CPU when opening font combobox

2020-05-08 Thread Mattia Rizzolo


Bug#960036: inkscape takes 100% CPU when opening font combobox

2020-05-08 Thread Mattia Rizzolo
Control: severity -1 important
Control: tag -1 moreinfo upstream

Hi Antonio, thank you for the report.

On Fri, May 08, 2020 at 04:10:32PM +0200, Antonio wrote:
> after updating inkscape to version 1.0, when I open the combobox to select a
> font, the program consumes 100% of the cpu and the desktop freezes

Could you please give me more details?  Here I tried to:
 * open a blank new file
 * create a "text object" and typed in some random words
 * selected the text
 * tried to change the font using the menu that appears on the top left
   side of the tool bar
and I'm not experiencing any issue.

> Same thing if I recompile it from source (downloaded from their site).
> No effect if I remove configuration files.
> Note that previous version works well.

What's the "previous version"? 1.0~rc1 or 0.92.4?
Also, since you managed to reproduce this with a plain upstream build,
did you also file this bug directly with them?

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#959696: debian-rules-uses-as-needed-linker-flag and backports

2020-05-05 Thread Mattia Rizzolo
Experimental and lowering to pedantic are orthogonal flags.  I think both
should be done, as removing --as-needed has very marginal relevance so it
can't possibly be labeled as "warning".  But due to what Christian said
(which matches my thoughts) I likewise believe the tag should be hidden for
the time being. I
 agree that marking the tag as experimental should be enough. I reckon not
many display experimental tags, since those are hidden behind a flag that
kind of discourage its usage.

Perhaps also consider adding a note in the description that suitability of
the change needs to be considerated if the package will be subject of
backporting (whilst it's true that there is a risk of overlinking, many of
those are not that severe: think of a Qt application that links a a bunch
of Qt library just because upstream cargo-culted a list in a qmake file,
even when not using all of it.  An extra link to a QtSvg that is not used
won't bother anybody.  But there are more severe cases.). Such note should
clearly mention that this is safe only if the package won't target anything
lower than bullseye, so that it can stay also during the bookwork cycle for
people considering oldstable-bpo uploads.

Lastly, I am not sure if this works for your development workflow, place a
code comment todo to drop the experimental flag once bullseye is out.

Thank you for your tireless work on lintian!

On Tue, 5 May 2020, 2:50 pm Christian Kastner,  wrote:

> On 2020-05-05 13:58, Chris Lamb wrote:
> > I would like to do a Lintian release today, so given that a) I was led
> > to believe skipping the tag for backports uploads would be sufficient
> > and b) that I would not like to leave the resolution of this bug for
> > another release, I would like to make the concrete proposal that we
> > remove this tag (or possibly, mark it as pedantic, experimental, and
> > add a suitable note to the long description). Would you concur?
>
> By my gut, either marking it as experimental, or removing it and
> re-adding it once bullseye becomes stable, are superior approaches to
> marking it pedantic. Pedantic might still motivate, well, a pedant, to
> change something.
>
> Generally speaking, I found the tag informative, because I wasn't aware
> of this new default setting in bullseye until lintian pointed this out
> to me. It's just that a warning is a strong call to action.
>
> Christian
>


Bug#959696: debian-rules-uses-as-needed-linker-flag and backports

2020-05-04 Thread Mattia Rizzolo
On Mon, May 04, 2020 at 10:58:03PM -, Chris Lamb wrote:
> It was sad to read that you do not consider that Lintian itself could
> be updated to prevent all of these wasted brain cycles on a question
> that you have seen raised multiple times.

I consider that, and I think I tried to contribute in a bunch of similar
discussions in the past, as well as filing reports whenever I thought
there were possible improvements around.

I'm just somewhat bothered because it feels that recent times (...
1/2/3 years maybe?) it started to be much more common for me to find
unactionable or inapplicable tags, even if they could later be "tuned
down" in a subsequent update.

> Once a tag has been added we can always refine, replace or remove it
> and the maintainers of Lintian have done so on a number of occasions
> once they were made aware of it.

What I'm getting at, is that as soon as a tag is added, it will
immediately affects at least dozens but most likely hundreds of people
in likely a single day, and if it stays around more than a day it'll
soon touch the thousands.
I'm convinced that tag additions should be pondered much more before
adding them, rather than considering that they will be improved further
on.  By the time somebody is annoyed enough to file a bug (because,
after all, a person will ponder if it's easier to just ignore something
rather than writing a report about it) it will have already caused
enough lost brain cycles.

> This is even more of an unfortunate stance to take given that a simple
> one-line improvement (such as to not emit this new tag in the case of
> backporting) would appear to be sufficient.

That is simply not true for this particular case: the problem of this
tag is that it is emitted *for unstable* builds.  It doesn't make sense
for it to be hidden during backports, as by then its "harm" will be
already done when the developer removed the --as-needed flag during the
unstable upload.  You'd have to know if that particular package *will
be* *in the future* backported, to understand whether it's appropriate
or not to drop that flag.

> It is regrettable that so many Debian Developers hold such pessimistic
> and fatalistic views regarding change in our project. Our collective
> sense of fulfilment and enjoyment would no doubt improve if we were to
> take small steps in reframing how we view these matters of this nature.

I'm sure you know that I hold anything but fatalistic views when
thinking of changes within the Project :)  Just know that I'm regularly
amongst the first to bump the debhelper compat level, and I've been
asked by multiple parties multiple time to wait before doing so!

But, however fast you want to change something, I agree proper and
careful steps always need to be taken.
In this particular case, there is not improvement whatsoever in removing
that flag, except removing possible cruft from d/rules.  Surely that
cruft can stay there another year or two, when opposed to the risk of
overlinking binaries and accidentally creating possibly heavy
dependencies in stable systems (because that's where backports are).
In other cases, there is a need to balance the view of thousands of
maintainers and their needs.
In this, my personal thought is that you, not you lamby but the Lintian
maintainers as a whole, need to take more care about what you are
including within the lintian checks, because whilst it's true that
anything can be better tuned later after the release, as the end user of
the tool being repeatedly irked by overzealous tags that need to be
first ignored for a while, then reported, discussed and finally
days/weeks later see in production can easily turn tiresome.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#959725: RM: svgtune -- RoQA; Inactive Upstream; Unmaintained; Affected by Python2 Removal

2020-05-04 Thread Mattia Rizzolo
Control: tag -1 moreinfo

On Mon, May 04, 2020 at 12:48:04PM -0400, Yaroslav Halchenko wrote:
> Please hold off on removal... I will update the package for python3

Tagging this bug as +moreinfo to hold back on the removal; please close
this bug once you've done the porting work and uploaded a fixed package.

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#947758: buster-pu: package node-handlebars/3:4.1.0-1+deb10u1

2020-05-04 Thread Mattia Rizzolo
Hi,

let me reply before adsb has a chance ;)

On Mon, May 04, 2020 at 02:24:20PM +0200, Xavier wrote:
> Finally I found a way to fix CVE and keep autopkgtest OK
> (node-markdown-it-html5-embed). Here is a debdiff for a future point release

This is good, however,

> diff --git a/debian/changelog b/debian/changelog
> index b985661..64df8db 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,11 @@
> +node-handlebars (3:4.1.0-1+deb10u1) buster; urgency=medium
> +
> +  * Team upload
> +  * Disallow calling "helperMissing" and "blockHelperMissing" directly
> +(Closes: CVE-2019-19919)
> +
> + -- Xavier Guimard   Mon, 04 May 2020 14:21:11 +0200

By now 3:4.1.0-1+deb10u1 is already accepted in p-u, built and all, and
it can't really be removed from there and replaced by a same-versined
pacakge.

Please prepare a +deb10u2 version, and post here a debdiff against the
already uploaded +deb10u1 one.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#959665: git-buildpackage: please put a full stop after "New upstrem version X."

2020-05-04 Thread Mattia Rizzolo
On Sun, May 03, 2020 at 07:38:11PM +0200, Guido Günther wrote:
> > my OCD is telling me that a changelog should be properly formatted, with
> > full stops and all.
> 
> But it's not a full sentence so why should it stop with a full stop?

Hmm, indeed it's not a full sentence.  It's what I think is called a
"verbless clause", but that doesn't really make it any less "complete"
than a full sentence :)

Not to mention that changelog lines are usually concise anyway, so I
really consider "New upstream version 1.2.3." complete and done by
itself.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#958841: Bug#959505: release.debian.org: Is erlang autoremoval is necessary?

2020-05-04 Thread Mattia Rizzolo
On Sun, May 03, 2020 at 09:02:11PM +0200, Paul Gevers wrote:
> > Alright, then I recommend this:
> > reassign 958841 src:erlang 1:22.3.2+dfsg-1
> > clone 958841 -1
> > reassign -1 src:elixir-lang 1.9.1.dfsg-1.3
> > retitle -1 elixir-lang: incompatible with erlang 22
> > # consider also leaving a longer message somewhere…?
> > close 958841 1:22.3.3+dfsg-1
> > 
> > Doing that should live a RC bug in elixir-lang, and cause its autorm in
> > a while, and leave erlang where it is, letting it migrate to testing as
> > soon as elixir-lang is out.  The rm from testing of elixir-lang could be
> > expedited if nothing happens.
> 
> I agree with this approach. It leaves the maintainers of elixir-lang
> some time to fix the situation. If they don't fix it, it will be removed
> and erlang can migrate. Unless there is some issue that I am not aware
> of that warrants a faster migration (and hence removal of elixir-lang).

Very well, I've now send that to command@, and added a `summary` to the
cloned bug to explain a bit what's happening.
The new bug against elixir-lang is #959701.

> Given the issue as I understand it, I don't want to binNMU it. I think
> the binNMU'd package can migrate before erlang and then the package in
> testing is broken (until erlang migrates) which isn't cool

I don't think that would happen.  bin:elixir depends on
erlang-pcre-8.43, which is provided by bin:erlang-core in testing, but
erlang-core in unstable only provides erlang-pcre-8.43-1 instead.
(I believe that's the original cause of the breakage, an ABI break in
that thing.)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#959696: debian-rules-uses-as-needed-linker-flag and backports

2020-05-04 Thread Mattia Rizzolo
[ not a lintian maintainer ]

On Mon, May 04, 2020 at 09:53:45AM +0200, Christian Kastner wrote:
> lintian understandably reports about a no longer required
> -Wl,--as-needed in bullseye. However, unless I'm mistaken, it's still
> needed for building for buster-backports, so removing it has a side effect.

IMHO, this is typical example of a tag that shouldn't have existed until
bullseye was stable.  Having -Wl,--as-needed specified in d/rules AND as
internal default from ld brings no downsides whatsoever, bearing one
"extra" line in d/rules.
Instead, I can see how many man-minutes and precious brain cycles were
lost in bugs like this, since you are not the first person to raise this
question.

> The cleanest solution would probably be to remove it, and to simply
> re-add this flag during backporting, at the cost of manual intervention
> (beyond dch --bpo, that is).
> 
> The pragmatic solution would be to just override the tag for packages
> where a backport might be expected.

I recommend you just either simply ignore the tag for those packages, or
please an override if it bothers you.
No need to overcomplicate a simple matter by removing and-readding flags
when they can simply just stay there.

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#959665: git-buildpackage: please put a full stop after "New upstrem version X."

2020-05-03 Thread Mattia Rizzolo
Package: git-buildpackage
Version: 0.9.19
Severity: wishlist

Hi,

my OCD is telling me that a changelog should be properly formatted, with
full stops and all.

Please consider changing the default from "New upstream version X" to
"New upstream version X.".
Attached an untested patch to do so.

TIA!

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
diff -Nru git-buildpackage-0.9.19/gbp/config.py 
git-buildpackage-0.9.19+nmu1/gbp/config.py
--- git-buildpackage-0.9.19/gbp/config.py   2020-02-28 09:48:01.0 
+0100
+++ git-buildpackage-0.9.19+nmu1/gbp/config.py  2020-05-03 16:48:56.0 
+0200
@@ -137,7 +137,7 @@
 'ignore-branch': 'False',
 'ignore-new': 'False',
 'ignore-regex': '',
-'import-msg': 'New upstream version %(version)s',
+'import-msg': 'New upstream version %(version)s.',
 'interactive': 'True',
 'keyid': '',
 'merge': 'True',
diff -Nru git-buildpackage-0.9.19/gbp.conf git-buildpackage-0.9.19+nmu1/gbp.conf
--- git-buildpackage-0.9.19/gbp.conf2019-10-26 10:24:20.0 +0200
+++ git-buildpackage-0.9.19+nmu1/gbp.conf   2020-05-03 16:49:07.0 
+0200
@@ -71,7 +71,7 @@
 # emulate old behaviour of calling dch:
 #postimport = dch -v%(version)s New Upstream Version
 # commit message:
-#import-msg = New upstream version %(version)s
+#import-msg = New upstream version %(version)s.
 
 # Options only affecting gbp import-dsc
 [import-dsc]
diff -Nru git-buildpackage-0.9.19/nosetests.xml 
git-buildpackage-0.9.19+nmu1/nosetests.xml
--- git-buildpackage-0.9.19/nosetests.xml   2020-02-28 09:06:02.0 
+0100
+++ git-buildpackage-0.9.19+nmu1/nosetests.xml  2020-05-03 16:49:25.0 
+0200
@@ -1526,7 +1526,7 @@
 --import-msg=IMPORT_MSG
 Format string for commit message used to commit the
 upstream tarball, default is 'New upstream version
-%(version)s'
+%(version)s.'
 --symlink-orig  Whether to create a symlink from the upstream tarball
 to the orig.tar.gz if needed, default is 'True'
 --no-symlink-orig   negates '--symlink-orig'
@@ -1594,7 +1594,7 @@
 --import-msg=IMPORT_MSG
 Format string for commit message used to commit the
 upstream tarball, default is 'New upstream version
-%(version)s'
+%(version)s.'
 
   version and branch naming options:
 version number and branch layout options


signature.asc
Description: PGP signature


Bug#959505: release.debian.org: Is erlang autoremoval is necessary?

2020-05-03 Thread Mattia Rizzolo
On Sun, May 03, 2020 at 12:58:19PM +0300, Sergei Golovan wrote:
> > Well, that bug is assigned to *both* erlang and erlang-elixir, and in
> > fact, the fix was done in erlang, so it really much looks like an erlang
> > bug?
> 
> It wasn't really a fix, I just bumped the erlang-pcre virtual package version
> exactly to make elixir-lang uninstallable because it's broken.

ACK.
Though it still means that indeed you had to do something in erlang as
well ;)

> > Now, it seems that wasn't enough, since erlang-elixir still doesn't pass
> > its autopkgtest with the new erlang; worse, it makes elixir-lang
> > uninstallable.
> 
> Elixir-lang (at least its current version in Debian) uses some
> unstable interface
> in Erlang, so it's sometimes requires to be rebuilt with the new erlang.
> As far as I can see now, elixir-lang is basically unmaintained, so nobody
> will ask for binNMU (it should be sufficient, but I havent't checked this).

I see.

> It's not a desirable output here. This means that without some changes
> in elixir-lang
> new erlang packages will never reach testing. I'm not sure that an 
> unmaintained
> package should stall development of its reverse dependencies like that.

Alright, then I recommend this:
reassign 958841 src:erlang 1:22.3.2+dfsg-1
clone 958841 -1
reassign -1 src:elixir-lang 1.9.1.dfsg-1.3
retitle -1 elixir-lang: incompatible with erlang 22
# consider also leaving a longer message somewhere…?
close 958841 1:22.3.3+dfsg-1

Doing that should live a RC bug in elixir-lang, and cause its autorm in
a while, and leave erlang where it is, letting it migrate to testing as
soon as elixir-lang is out.  The rm from testing of elixir-lang could be
expedited if nothing happens.

> > Lastly, I recommend you just don't spend too much time on understanding
> > the autorm situation, rather just fix whatever is broken and make
> > elixir-lang pass the autopkgtest again; the autorm date is more than a
> > month away after all.
> 
> I would say that binNMU would be sufficient for now, but I wouldn't like to
> constantly monitor this elixir-lang situation.

ACK, if really that package is unmaintained it's probably best to not do
anything even if a simple binNMU was enough.  Or we could just try it
and wait till the next breakage before removing elixir-lang from
testing.

I'm not sure I'd call a package "unmaintained" when the last maintainer
upload was last September, so perhaps I'd still try to give it another
chance by binNMUing it.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#959505: release.debian.org: Is erlang autoremoval is necessary?

2020-05-03 Thread Mattia Rizzolo
On Sun, May 03, 2020 at 09:39:51AM +0300, Sergei Golovan wrote:
> Today, I've got an autoremoval mails for erlang and a whole bunch of related
> packages because of #958841 (see [1] for details).
> 
> Is it really necessary to remove erlang and all its reverse dependencies,
> while it's elixir-lang which is the culprit?

Well, that bug is assigned to *both* erlang and erlang-elixir, and in
fact, the fix was done in erlang, so it really much looks like an erlang
bug?

Now, it seems that wasn't enough, since erlang-elixir still doesn't pass
its autopkgtest with the new erlang; worse, it makes elixir-lang
uninstallable.

> As far as I can see, removal
> of all erlang related packages (which includes elixir-lang) should lead to
> moving them back except for elixir-lang which is now uninstallable.

What do you mean with "moving back"?

> On the other hand, just removing elixir-lang from testing achieves the same
> outcome without removing/moving back many packages.

The autoremoval is quite confusing (perhaps actually buggy?) when bugs
are assigned against multiple packages.  In fact, only erlang is being
autoremoved, elixir-lang is being removed only due to being a rdep of
erlang.

Please read with more attention the text of the bug:
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958841
| Due to the nature of this issue, I filed this bug report against
| both packages. Can you please investigate the situation and reassign the
| bug to the right package?
I'm confident that if you reassign this bug to erlang only (and properly
changing the 'found', 'fixed' and 'done' values), nothing
would be autoremoved, simply because that bug won't affect erlang in
testing anymore.

Lastly, I recommend you just don't spend too much time on understanding
the autorm situation, rather just fix whatever is broken and make
elixir-lang pass the autopkgtest again; the autorm date is more than a
month away after all.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#958104: system-config-printer-udev: ABRT: free(): invalid pointer

2020-04-29 Thread Mattia Rizzolo
Hello there!

On Tue, Apr 28, 2020 at 12:35:52AM +0200, Bernhard Übelacker wrote:
> Dear Maintainer,
> looking at the backtrace from message 13 and at the changes
> done by upstream, following commit sounds related:
> 
> https://github.com/OpenPrinting/system-config-printer/commit/b9289dfe105bdb502f183f0afe7a115ecae5f2af#diff-d3f2f90b6e176486d4b8dfe3222577f7

Indeed!

I opened a MR at
https://salsa.debian.org/gnome-team/system-config-printer/-/merge_requests/1
picking that and the previous, related, commit.

After trying, the thing doesn't crash anymore, though it does still
fail:
Apr 29 18:58:45 warren systemd[1]: Started Configure Plugged-In Printer.
Apr 29 18:58:45 warren udev-configure-printer[3076204]: add usb-001-008
Apr 29 18:58:45 warren udev-configure-printer[3076204]: device devpath is 
/devices/pci:00/:00:14.0/usb1/1-1
Apr 29 18:58:45 warren udev-configure-printer[3076204]: Device already handled
Apr 29 18:58:45 warren systemd[1]: configure-printer@usb-001-008.service: Main 
process exited, code=exited, status=1/FAILURE
Apr 29 18:58:45 warren systemd[1]: configure-printer@usb-001-008.service: 
Failed with result 'exit-code'.


I didn't debug further, and I know nothing about udev so maybe it just
needs some poking?

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#959037: lintian: FPOS? for executable-in-usr-lib

2020-04-29 Thread Mattia Rizzolo
On Tue, Apr 28, 2020 at 11:38:44PM +0100, Steve McIntyre wrote:
> ACK. d-i won't be looking in /usr/libexec. Please leave things where
> they are...

Good, then @lintian-maint: please exclude udebs from this check :)
(as I think used to be in the past, since I don't think I saw this tag
years ago in this package, but I know it has been there for a while…)

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#959037: lintian: FPOS? for executable-in-usr-lib

2020-04-28 Thread Mattia Rizzolo
On Tue, Apr 28, 2020 at 02:39:49PM -0700, Felix Lechner wrote:
> On Tue, Apr 28, 2020 at 4:27 AM Mattia Rizzolo  wrote:
> > I'm CCing d-boot@ for confirmation, since I'm not sure if maybe I'm
> > doing something wrong.
> >
> > Today I notices these tags:
> >
> > P: eatmydata-udeb udeb: executable-in-usr-lib 
> > usr/lib/finish-install.d/13eatmydata-udeb
> > N:
> 
> I expanded that odd tag description with some text from the original
> bug report. I also adjusted the references. Perhaps the remark
> regarding /usr/libexec is helpful:
> 
> The package ships an executable file in /usr/lib.
> 
> Please move the file to /usr/libexec.

Not quite, as I'm positive those directories is where d-i go look for
hooks, and I doubt just moving them to libexec is useful.

I'm re-instating the CC on d-boot@ to see if it sparks some comment...

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#959037: lintian: FPOS? for executable-in-usr-lib

2020-04-28 Thread Mattia Rizzolo
Package: lintian
Version: 2.68.0
X-Debbugs-Cc: debian-b...@lists.debian.org

Hi,

I'm CCing d-boot@ for confirmation, since I'm not sure if maybe I'm
doing something wrong.

Today I notices these tags:

P: eatmydata-udeb udeb: executable-in-usr-lib 
usr/lib/finish-install.d/13eatmydata-udeb
N:
N:policy, 9.1.1,
N:https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
N:
N:Severity: pedantic
N:
N:Check: usr/lib
N:
P: eatmydata-udeb udeb: executable-in-usr-lib 
usr/lib/post-base-installer.d/01eatmydata-udeb
P: eatmydata-udeb udeb: executable-in-usr-lib 
usr/lib/pre-pkgsel.d/10eatmydata-udeb


That being an udeb I know many things don't apply to it, but I'm not
sure if maybe I hsould place those d-i hooks elsewhere.

If, as I think, they are in the right place, please teach lintian to
ignore that in udebs.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#800878: inkscape: non-free file "gallardo.svgz"

2020-04-27 Thread Mattia Rizzolo
On Sun, Oct 04, 2015 at 07:00:06PM +0200, Jonas Smedegaard wrote:
> >> According to its metadata, image 
> >> "/usr/share/inkscape/examples/gallardo.svgz" 
> >> appears to be non-free:
> > It's funny because according to that wikipedia page the image under a
> > double license GFDL-1.2 / CC-BY-SA-3.0.
> 
> Indeed, that's interesting.
> 
> We could try locate and get in touch with the copyright holder of the 
> SVG, and ask kindly if he agrees to relicense, also making him aware 
> that arguably¹ he has no choice.
> 
> According to metadata of the file, his name is Michael Grosberg and he 
> used Windows² at the time.  A Michael Grosberg have been active on the 
> Inkscape developers' list, so maybe his email is in some commit message 
> or his list posts hare unscrambled somewhere...
> 
> Anyone who wants to try contact Michael?

Today it felt the right time to bring up this bug with upstream (I
talked with Mc over #inkscape-devel).  They found an address for
Michael, but it needs to be mentioned that there haven't been a trace of
that address for 15 years, even if the mail didn't bounce.


Regarding animated-clock.svg, the copyright holder of that is an active
Inkscape contributor, so we just pinged him over IRC.


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#958986: celery: FTBFS with Sphinx 2.0.0

2020-04-27 Thread Mattia Rizzolo
Source: celery
Version: 4.4.2-1
Severity: serious
Control: block -1 by 958983
Control: 958983 !
Owner: !

SSIA.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#958985: sphinx: please add Breaks: python3-sphinx-celery (<< 2.0.0-1)

2020-04-27 Thread Mattia Rizzolo
Package: python3-sphinx
Version: 2.4.3-2
Severity: important

sphinx-celery doesn't autopkgtest or somesuch so this wasn't really
caught, nor debugged untile today.

I'm updating the package now for #958983 - so please add this Breaks on
your next upload of sphinx.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#958983: sphinx-celery: incompatible with sphinx 2+

2020-04-27 Thread Mattia Rizzolo
Source: sphinx-celery
Version: 1.3.1-2
Severity: serious

This theme is not compatible with sphinx 2.

There seems to be a new upstream available in
https://github.com/celery/sphinx_celery that at least has relevant
commits.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#958932: lintian: debhelper compat level 13 is no longer experimental

2020-04-27 Thread Mattia Rizzolo
On Sun, Apr 26, 2020 at 04:17:34PM -0700, Felix Lechner wrote:
> > I do not follow how
> > making this minor change would affect the rest of Lintian in the
> > dramatic way you describe.
> 
> Following a conversation on IRC with mapreri last week I made the
> changes below. They caused build failures in almost all test artifacts
> on stable. The debian-compat (= 13) facility is not available.

debhelper/13 just migrated to bullseye, I reckon a buster-bpo will
follow soon.
I'm sure we can all wait a few more days...

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#958410: lintian: please warn about about duplicated debhelper build-deps

2020-04-26 Thread Mattia Rizzolo
On Tue, Apr 21, 2020 at 11:49:09PM +0100, Chris Lamb wrote:
> >  Build-Depends: autoconf-archive,
> > -   debhelper (>= 11),
> > +   debhelper (>= 12),
> > +   debhelper-compat (= 12),
> > libbz2-dev,
> > libtar-dev,
> 
> Interesting, I would have thought debhelper would FTBFS this with:
> 
> dh: warning: Please specify the debhelper compat level exactly once.
> dh: warning:  * debian/compat requests compat 12.
> dh: warning:  * debian/control requests compat 12 via "debhelper-compat 
> (= 12)"
> dh: warning: 
> dh: warning: Hint: If you just added a build-dependency on 
> debhelper-compat, then please remember to remove debian/compat
> dh: warning: 
> dh: error: debhelper compat level specified both in debian/compat and via 
> build-dependency on debhelper-compat

That only happens if you ship d/compat AND have debhelper-compat in the
build-deps.  It is not related to having debhelper in the build-deps.

If fact, there are documented use cases where you *need* have have both
debhelper and debhelper-compat (an example, if you rely on the udeb
auto-detection from dh_makeshlibs 12.3, you need "debhelper-compat (=
12)" AND "debhelper (>= 12.3)" (or just d-copat=13 now…)).

> Alternatively, if the build-profile means that the *debhelper-compat*
> dependency is ignored and there is no debian/compat, would it not mean
> that it would FTBFS with a "no debian/compat file"?

The "extra restrictions (build profiles, etc)" I was referring to is
related to the "debhelper" build-dep, not "debhelper-compat", sorry for
not being precise.
However now, thinking again, I can't think of a good reason to have a
version of debhelper <= of that of debhelper-compat even with a build
profile, I'm not sure what I was thinking about. :3

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#958192: stretch-pu: package xdg-utils/1.1.1-1+deb9u1

2020-04-25 Thread Mattia Rizzolo
On Sat, Apr 25, 2020 at 07:15:41PM +0100, Adam D. Barratt wrote:
> On Sun, 2020-04-19 at 17:16 +0300, Nicholas Guriev wrote:
> > Along with 1.1.3-1+deb10u1 for buster I propose an update for stretch
> > with the same fixes that applicable for 1.1.1 version.
> > 
> 
> Please go ahead.

Uploaded.

(Nicholas: I know you didn't ask me to, hope I didn't just in too soon)

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#883155: fixed in inkscape 1.0~beta1+ds-1

2020-04-25 Thread Mattia Rizzolo
On Sat, Apr 25, 2020 at 04:09:15AM +0200, Vincent Lefevre wrote:
> On 2020-04-13 15:40:01 +0200, Mattia Rizzolo wrote:
> > On Sun, Apr 12, 2020 at 07:21:37PM -0400, Sandro Tosi wrote:
> > > Can you give us your take on this? tbh i'd like to proceed with the 4
> > > packages removal mentioned above rather quickly, as they are blocking
> > > several other packages from removal.
> > 
> > Go and remove those 4 packages!
> 
> This is not nice for the end user, as this prevents upgrades without
> manual intervention.

How so?  They are recommends, so their removal doesn't break any
dependency by definition.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


  1   2   3   4   5   6   7   8   9   10   >