Re: How to ask efficiently for removal of 32 bit architectures of about 40 packages (Was: reverse dependenc)
On Mon, Mar 11, 2024 at 09:12:30PM +0100, Andreas Tille wrote:
> I hope there is some better solution than sending single bug reports
> for those packages. If ftpmaster tooling really needs single bug
> reports I wonder how I can automatically create such bug reports with
> always the same text, just targeting at different binary packages.
>
> This also should include some means to work around the less than 5
> bug reports per hour SPAM protection means of BTS.
clone the bug however many time you need and retitle the clones? What
matters for the ftp tooling is just the bug title, pretty much.
That's one single email...
--
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
Re: Question regarding uscan check on UDD
On Tue, Jan 02, 2024 at 10:22:29PM -0800, Xiyue Deng wrote:
> I noticed a discrepancy of the uscan @ANY_VERSION@ substitute string on
> UDD and locally on my bookworm system.
That's because UDD is running on bullseye, not on bookworm, with
bullseye-backports' version of devscripts (which really really I should
go back to work on and update…)
--
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
Re: debian/copyright format and SPDX
On Fri, Sep 08, 2023 at 07:34:43AM -0700, Russ Allbery wrote:
> I don't think the file format is the most interesting part of SPDX. They
> don't really have a competing format equivalent to the functionality of
> our copyright files (at least that I've seen; I vaguely follow their
> lists). Last time I looked, they were doing a lot with XML, which I don't
> think anyone would adopt for new formats these days. (YAML or TOML or
> something like that is now a lot more popular.)
Formally, SPDX is only a data model, which supports several
serializations formats. The XML one is I believe the most common one
for some technically good reasons, but it does support YAML
serialization, as well as some lossy ones as well (like CSV, plaintext,
etc...).
--
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
Re: -ffile-prefix-map option and reproducibility
On Tue, Feb 07, 2023 at 04:41:47PM +0100, Stéphane Glondu wrote:
> When building packages, a -ffile-prefix-map option is automatically injected
> into CFLAGS. Where does it come from? Since when?
>
> I suspect this was added to improve reproducibility. Ironically, it makes
> packages that capture this variable non reproducible, since the build path
> seems to be randomized (has it always been the case? since when?).
The build path has always been randomized since, or at least it has been
for as long as I've been involved in Debian.
> It is the
> case of OCaml (see #1030785), and seemingly of R as well (found by grepping
> in my /etc). I wouldn't be surprised other packages are affected as well.
>
> Is there a way to not get this option? More elegant than explicitly
> filtering it out of CFLAGS in debian/rules...
Besides doing
DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath
I actually propose to you to filter out the whole option from being
saved. I've seen a similar pattern in other packages in the past, and
all of those packages already had a filtering function in place to
remove other gcc flags that make no sense being saved (just looking at:
- 8: const("camlConfig__8"="-O2 -fno-strict-aliasing -fwrapv -pthread
-fPIC -g -O2 -ffile-prefix-map=/build/ocaml-Vq2uKK/ocaml-4.13.1=.
-fstack-protector-strong -Wformat -Werror=format-security");
+ 8: const("camlConfig__8"="-O2 -fno-strict-aliasing -fwrapv -pthread
-fPIC -g -O2 -ffile-prefix-map=/build/ocaml-xz3WL7/ocaml-4.13.1=.
-fstack-protector-strong -Wformat -Werror=format-security");
makes me believe that many options have been stripped out…)
--
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
Re: Firmware GR result - what happens next?
On Mon, Oct 03, 2022 at 01:18:55AM +0300, Dmitry Baryshkov wrote: > вс, 2 окт. 2022 г. в 22:36, Steve Langasek : > > > So this is the one bit that I don't think we currently have a good > > > answer for. We've never had a specific script to run on upgrades (like > > > Ubuntu do), so this kind of potentially breaking change doesn't really > > > have an obvious place to be fixed. > > > > > Obviously we'll need to mention this in the release notes for > > > bookworm. Should we maybe talk about adding an upgrade helper tool? > > > > I heartily endorse ubuntu-release-upgrader, it has been useful in addressing > > uncounted upgrade issues over the years and I think something like this > > would be a nice addition to Debian as well. Two caveats: > > I'd kindly ask against additional upgrade scripts. It is too easy to > miss them, especially if one has been using Debian for ages with bare > apt-get update && apt-get dist-upgrade. > Moreover such a script will not help people that are already using testing. > > For the past few decades, updating the setup was always a job of the > package scripts. This is getting OT in this thread, but I agree with the many that are against such upgrading script. I consider even the need for such thing a bug, as each package should take care of its own quirks. Besides, if something wants to mess with my system configuration, that's an even greater bug for me (something that IME ubuntu has been doing more and more over the last years). I can live with an APT hook warning me if I have non-free but not non-free-firmware, but I would prefer to even do without that. For stable→stable updates there are the release notes for this tiny change. For testing/unstable users, they should really read d-d-a, and this change be announced there (if it hasn't already). -- 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
Re: FTBS bugs -- MBF?
On Sun, Oct 02, 2022 at 10:57:11AM +0100, Simon McVittie wrote:
> > Packages that only build Architecture: all binary packages tend to use
> > Build-Depends-Indep.
>
> Policy is quite clear about that being a bug. I think a better rule of
> thumb for maintainers in a hurry would be: if you don't have time to think
> about which dependency list is the right one, and preferably test the
> result (with a source-only build like Adam has been doing, a --build=all
> build, and a --build=any build), then the safe option is to put everything
> in B-D.
I totally agree, and I consider that a RC bug in my mind.
I would support filing all the bugs as sev:important, and bump them
right after the bookworm release (so we don't add all these RC bugs so
near the freeze, even if they are trivial to fix).
--
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
Re: 'The' timestamp of a snapshot of deb.debian.org
On Sun, Sep 18, 2022 at 10:58:37AM +0200, Roland Clobus wrote:
> All of these timestamps (for sid) are close to each other, but not
> identical. I would guess that the earliest timestamp is the 'real'
> timestamp, but it is accessible (on snapshot.d.o) only with a later
> timestamp.
Consider that the archive "freezes" when it starts working on an update.
Once it finishes its job it generates the Release files, and puts the
current timestamp *inside* the file. But then that file gets copied
around, signed, etc and that will change the timestamp.
Also, for example, I just spotted a line on IRC saying that this time
around copying the archive from the live one to archive.debian.org also
reset the mtimes...
So I really wouldn't trust mtimes in any way, only what's inside the
Release file.
What's in the trace file is IIRC the time when the archive kicks the
mirrors off, which also happens after the generation of the indexes, and
really has no business in this discussion as it's only a tool mirrors
use to coordinate and see if they are too much out of sync.
As you noticed snapshots indexes by time of the archive run, which is…
honestly I don't particularly consider it a good idea myself but that's
how the design decision went I guess.
(does it make sense to archive twice if there were two mirror pushes for
the same identical set of index files?)
--
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
Re: Proposed MBF: wxwidgets3.2 transition
On Mon, Sep 12, 2022 at 10:32:23PM -0400, Scott Talbert wrote:
> wxWidgets 3.2 (a new API/ABI stable release) has been released a few months
> ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped
> supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx
> package users to wxwidgets3.2 for bullseye, with the plan to remove
> wxwidgets3.0 before release.
>
> For most packages, the transition should be as simple as changing
> Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. Some packages
> may require small patches; I'm happy to help with those (and I have some
> already from working on this transition in Fedora already).
Question from somebody who doesn't know wxWidgets: if the update from
one release to the other is so simple (at least, you make it sound very
simple, and #1019416 has no blocking bugs, so I reckon everything
works?) then why is this not packaged like pretty much any other library
with an unversionde source package and an unversioned -dev binary
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
Re: fontconfig RC bugs (was: Re: key packages RC bugs of the month September)
On Thu, Sep 01, 2022 at 04:08:20PM +0200, Johannes Schauer Marin Rodrigues wrote: > > #960679 src:fontconfig > > strict dependency of arch:any libfontconfig1 on arch:all > > fontconfig-config going wrong > > https://bugs.debian.org/960679 > > fontconfig also has a second RC bug: #909750 > > The last maintainer upload of fontconfig was more than two years ago. Since > then it has been NMU-ed by me and Julien Cristau. > > Since there is no maintainer action on #960679 I wanted to ask the d-devel > crowd if you see any problem with making fontconfig-config arch:any to fix it? > > There is a patch for #909750 which I can apply in my next fontconfig NMU as > well. I don't see any reason why you wouldn't do this change following the usual NMU procedure. Just go ahead? :) -- 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
Re: A mail relay server for Debian Members is live
On Sat, Jul 16, 2022 at 11:49:31PM +0200, Pierre-Elliott Bécue wrote:
> This service is now operational behind mail-submit.debian.org (AKA
> stravinsky.debian.org). Documentation about how to use this service can
> be accessed via [1].
That's great!
> If you have any question or issue, please don't hesitate to reach out.
Question:
At this point, what about SPF? Ignoring potential whitelists on mail
receivers, I think using this service doesn't provide extra advantages
than signing on our own servers.
Since there is now this system in place, I think it's fair that after a
transition period we kind of force DDs to relay their email through
Debian infrastracture to properly authenticate outgoing emails.
Do you have any sort of plan in mind? I'd epxect to at least place a
"ip4:82.195.75.108 ~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
Re: UDD upstream importer seems to fail randomly for sf.net
On Tue, Jan 25, 2022 at 10:36:52AM +0100, Andreas Tille wrote: > Hi, > > when checking UDD dashboard for the Debian Med team[1] I see lots of > >debian/watch: uscan returned an error: In debian/watch no matching files > for watch line http://sf.net/ > > expressions. I suspect that this affects all packages hosted at > SourceForge. When running uscan manually on my local machine uscan > works nicely for at least five examples I've checked. It seems there > are circumstances when the UDD importer just fails while the watch file > is perfectly OK? > > I checked UDD (mirror) for success and failure when scanning > http://sf.net/ watch files: > > udd=> SELECT sf_success, count(*) from (select source, case when warnings > like 'In debian/watch no matching files for watch line%' THEN 'Fail' ELSE > 'Success' END as sf_success from upstream where watch_file like > '%http://sf.net/%') as tmp group by sf_success ; > sf_success | count > +--- > Success| 731 > Fail | 544 … > I admit I can not see any pattern inside the watch files - may be its > just a "bad timing" effect. Any ideas are welcome. I blame the network, most likely just a temporary glitch *shrugs*. With so many moving pieces it happens every so often... -- 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
Re: Dropping dpatch for bookworm
On Fri, Jan 07, 2022 at 12:35:12AM +0100, Moritz Mühlenhoff wrote: > There are only 24 packages left using dpatch and the vast majority of > remaining > uses are packages which haven't seen a maintainer upload for a decade or > longer. > > Some of these have existing "please migrate to source format 3(quilt)" bugs > already > and in the interest of more streamlined packaging workflows and eliminating > technical > debt I think it's time to remove dpatch for bookworm. > > So unless there's objections, I'd bump existing bugs to RC and file bugs where > they don't exist. And anything that doesn't get fixed/NMUd/removed can then > be removed along with dpatch before the bookworm freeze. ACK, thank you very much for taking charge of 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
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
On Mon, Jan 10, 2022 at 02:21:48PM -0500, Andres Salomon wrote: > On 1/10/22 05:01, Mattia Rizzolo wrote: > > On Sun, Jan 09, 2022 at 11:23:20PM -0500, Andres Salomon wrote: > > > Btw, https://salsa.debian.org/dilinger/chromium/-/tree/stable is my branch > > > with cleaned-up commits. That's what I'll use for the NMU, which I'm > > > preparing now. > > If you all agree, you could finalize the tree, then I'll build again, > > after which I could sponsor this after a couple days of testing. > > > > I see that you changed debian/copyright compared to the one I used in my > > build here, so I'll export the orig tarball again. (normally with > > Michel we'd share the sha256 of one's produced tarball to check we are > > building with the same thing, so please share yours?) > > > Thank you so much for testing! The sha256 that I have is > cca093107bf6991b4777889012646455f8e520b446c9f27250653f98ed4bb7e0 Cool, this matches with the new tarball I produced. Guess I'll restart a build with the stable branch now then. BTW, my current build (from the v97 branch), just crashed on me. Not sure where, and I couldn't quickly reproduce it either; I was just clicking ont he "extension bar", but I'm not even sure what I was doing.. just saying :) > I don't need a sponsor (I'm a developer), but thank you for the offer. Ah! Apologies! I didn't look your name up, and I just assumed so from the n...@debian.org address. Well, happy then, less "work" for me :D > Btw, hopefully Michael is just currently busy and is still interested in > working on chromium? I ralized that riku retaired formally last month (indeed, please drop him from Uploaders, I also opened a bug (as MIA team) against chromium last month). About Micheal, that's unclear to me: he stated less than one year ago that he would keep working on chromium, but he really is not answering to anybody... so well, even if he is still interested, in a case as big as chromium I think you really needs to show consideration and be at least reachable. Though it might just be my own opinion. -- 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
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sun, Jan 09, 2022 at 11:23:20PM -0500, Andres Salomon wrote:
> Btw, https://salsa.debian.org/dilinger/chromium/-/tree/stable is my branch
> with cleaned-up commits. That's what I'll use for the NMU, which I'm
> preparing now.
If you all agree, you could finalize the tree, then I'll build again,
after which I could sponsor this after a couple days of testing.
I see that you changed debian/copyright compared to the one I used in my
build here, so I'll export the orig tarball again. (normally with
Michel we'd share the sha256 of one's produced tarball to check we are
building with the same thing, so please share yours?)
Regarding the git repository/team on salsa. What would you all think
about asking the salsa admins to bypass the team admins (gilbert and
riku) that have been silent all this time?
When Micheal started taking over, I didn't want to be too involved so I
didn't ask to be added to team together with him, but I suppose I got
sucked in by this matter a bit too much.
Otherwise I wonder about simply creating a new repository under debian/.
--
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
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sun, Jan 09, 2022 at 12:56:28AM -0500, Andres Salomon wrote: > > On 1/8/22 15:57, Mattia Rizzolo wrote: > > On Thu, Jan 06, 2022 at 02:55:20AM -0500, Andres Salomon wrote: > > > If you want to try with chromium 97; it now builds as an official build, > > > so > > > those DCHECKs shouldn't even be compiled in. It also supports wayland > > > automatically, in case that's related to your slowdowns. > > > > > > https://salsa.debian.org/dilinger/chromium/-/tree/v97 > > I wanted to do this, but could it be that this version is for some > > reason taking much more space than the previous one? Here I have ~40 GB > > free, and v96 built just fine (though I wasn't looking when it was > > running), but now this failed already twice due to ENSPC. > > > > I'll try looking for someplace more spacy but it's odd :) > > > > Yeah, I think it's the debugging info; it's also breaking lld. It's a result > of enabling official build, I'm working on it. I see. Well, it took me longer than I would have liked, but I finally got a build out of that v97 branch (commit 2c2685aee67a677c85dd752aea08a7e571312116). This one looks fully functional, gmail is as reactive as it used to be (u.U after a few days with v96 and that slowness, now it feels so much better lol) in the past, and after ~15 minutes of random usage it hasn't crashed on me yet! \o/ It also fixed a problem I had with v93 where document google sheets would look totally blank... so double happy now! -- 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
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
On Thu, Jan 06, 2022 at 02:55:20AM -0500, Andres Salomon wrote:
> If you want to try with chromium 97; it now builds as an official build, so
> those DCHECKs shouldn't even be compiled in. It also supports wayland
> automatically, in case that's related to your slowdowns.
>
> https://salsa.debian.org/dilinger/chromium/-/tree/v97
I wanted to do this, but could it be that this version is for some
reason taking much more space than the previous one? Here I have ~40 GB
free, and v96 built just fine (though I wasn't looking when it was
running), but now this failed already twice due to ENSPC.
I'll try looking for someplace more spacy but it's odd :)
--
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
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
On Thu, Jan 06, 2022 at 02:55:20AM -0500, Andres Salomon wrote:
> If you want to try with chromium 97; it now builds as an official build, so
> those DCHECKs shouldn't even be compiled in. It also supports wayland
> automatically, in case that's related to your slowdowns.
>
> https://salsa.debian.org/dilinger/chromium/-/tree/v97
Thank you, let's try with this.
I've just started the build! :)
Also thanks for handling the py2 thing, however you should be aware that
build-depending on python-is-python3 is also not allowed :3
(however I personally prefer that than to have to inject an old binary..)
--
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
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
On Wed, Jan 05, 2022 at 01:52:33PM +0100, Mattia Rizzolo wrote:
> I suppose I'll see how it goes in the coming few days.
So it's not crashing but it's being unbearably slow in gmail, to the
point that I just wasn't able to type a mail there, while throwing one
CPU core to 100%.
Also it was kind go generally slow in several other sites, compared to
v93. Always compared to v93, it takes far longer (and by far much much
more CPU) to reopen the whole session (I keep ~50 tabs in 3 windows open
all the time, trusting the browser to reopen them where I left when I
close it).
I didn't mesure anything and I don't have any numbers to share, but
that's what I see.
At least, it looks like it has not been leaking as much memory as v93
was (that in this regard was buggier than v90).
--
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
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
On Tue, Jan 04, 2022 at 06:46:46PM -0500, Andres Salomon wrote: > On 1/4/22 15:15, Mattia Rizzolo wrote: > > On Tue, Jan 04, 2022 at 02:50:20PM -0500, Andres Salomon wrote: > > > I pushed a commit to the skip-a11y-checks branch, please give that a try. > > > I > > > need to take a look at other distributions that are shipping chromium to > > > see > > > if they're just disabling DCHECKs outright, or what. > > Just took a look at fedora, arch, and ungoogle-chromium debian packaging. > They're all setting is_official_build=true, which completely disables those > DCHECKs. We should probably set it like that as well, although the > dcheck_is_configurable=true thing that I added to the skip-a11y-checks > branch should at least allow the DCHECKs to not be fatal - so there's no > need to restart your build. So, this one at least didn't crash on me as soon as I started. Also, it looks like the saved passwords that went away came back, so I reckon perhaps the local storage format changed in the upgrade, so v93 wasn't able to see them anymore, or something similar. I suppose I'll see how it goes in the coming few days. Thank you for your work! -- 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
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
On Tue, Jan 04, 2022 at 02:50:20PM -0500, Andres Salomon wrote:
> Okay, that's funny - appears to be a fatal error due to being run under gdb.
Well, it was also crashing outside of gdb ^^
> I pushed a commit to the skip-a11y-checks branch, please give that a try. I
> need to take a look at other distributions that are shipping chromium to see
> if they're just disabling DCHECKs outright, or what.
build 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
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
)] Cannot use V8 Proxy resolver in single process mode. [413:413:0104/174404.300230:FATAL:render_process_host_impl.cc(4227)] Check failed: host->GetBrowserContext() == browser_context (0x645f47d0 vs. 0x658dcb30) Single-process mode does not support multiple browser contexts. Thread 1 "chromium" received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49 49 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49 #1 0x74653536 in __GI_abort () at abort.c:79 #2 0x5d79e9e5 in base::debug::BreakDebuggerAsyncSafe() () #3 0x5d6ea9f4 in logging::LogMessage::~LogMessage() () #4 0x5d6eaffe in logging::LogMessage::~LogMessage() () #5 0x5aba348a in content::RenderProcessHostImpl::IsSuitableHost(content::RenderProcessHost*, content::IsolationContext const&, content::SiteInfo const&) () #6 0x5aba4733 in content::RenderProcessHostImpl::GetExistingProcessHost(content::SiteInstanceImpl*) () #7 0x5aba5b71 in content::RenderProcessHostImpl::GetProcessHostForSiteInstance(content::SiteInstanceImpl*) () #8 0x5acb37dc in content::SiteInstanceImpl::GetProcess() () #9 0x5ab7b3c4 in content::RenderFrameHostManager::CreateRenderFrameHost(content::RenderFrameHostManager::CreateFrameCase, content::SiteInstance*, int, mojo::PendingAssociatedRemote, base::TokenType const&, bool) () #10 0x5ab7b235 in content::RenderFrameHostManager::InitRoot(content::SiteInstance*, bool) () #11 0x5aa4d59e in content::FrameTree::Init(content::SiteInstance*, bool, std::__cxx11::basic_string, std::allocator > const&) () #12 0x5ad1a896 in content::WebContentsImpl::Init(content::WebContents::CreateParams const&) () #13 0x5ad0cbb1 in content::WebContentsImpl::CreateWithOpener(content::WebContents::CreateParams const&, content::RenderFrameHostImpl*) () #14 0x5ad0c8b1 in content::WebContents::Create(content::WebContents::CreateParams const&) () #15 0x608c633b in ProfilePickerView::Init(Profile*) () #16 0x608c61f0 in ProfilePickerView::OnSystemProfileCreated(Profile*, Profile::CreateStatus) () #17 0x5a62fec0 in base::internal::Invoker, std::allocator > const&, web_app::InstallResultCode), base::WeakPtr >, void (std::__cxx11::basic_string, std::allocator > const&, web_app::InstallResultCode)>::RunOnce(base::internal::BindStateBase*, std::__cxx11::basic_string, std::allocator > const&, web_app::InstallResultCode) () #18 0x5d399bcb in ProfileManager::CreateProfileAsync(base::FilePath const&, base::RepeatingCallback const&) () #19 0x608c4442 in ProfilePickerView::Display(ProfilePicker::EntryPoint) () #20 0x6076c476 in StartupBrowserCreator::LaunchBrowserForLastProfiles(base::CommandLine const&, base::FilePath const&, bool, Profile*, std::vector > const&) () #21 0x6076df14 in StartupBrowserCreator::ContinueProcessingCommandLineAfterEarlyWebAppCheck(base::CommandLine const&, base::FilePath const&, Profile*, bool, Profile*, std::vector > const&) () #22 0x6076bcd8 in StartupBrowserCreator::ProcessCmdLineImpl(base::CommandLine const&, base::FilePath const&, bool, Profile*, std::vector > const&) () #23 0x6076ae30 in StartupBrowserCreator::Start(base::CommandLine const&, base::FilePath const&, Profile*, std::vector > const&) () #24 0x5d1b86ef in ChromeBrowserMainParts::PreMainMessageLoopRunImpl() () #25 0x5d1b7ea8 in ChromeBrowserMainParts::PreMainMessageLoopRun() () #26 0x5a6b6ddc in content::BrowserMainLoop::PreMainMessageLoopRun() () #27 0x5acd2c36 in content::StartupTaskRunner::RunAllTasksNow() () #28 0x5a6b69ca in content::BrowserMainLoop::CreateStartupTasks() () #29 0x5a6b9598 in content::BrowserMainRunnerImpl::Initialize(content::MainFunctionParams const&) () #30 0x5a6b4e22 in content::BrowserMain(content::MainFunctionParams const&) () #31 0x5d176f7d in content::ContentMainRunnerImpl::RunBrowser(content::MainFunctionParams&, bool) () #32 0x5d1768df in content::ContentMainRunnerImpl::Run(bool) () #33 0x5d17419a in content::RunContentProcess(content::ContentMainParams const&, content::ContentMainRunner*) () #34 0x5d174a8b in content::ContentMain(content::ContentMainParams const&) () #35 0x555558e0d721 in ChromeMain () #36 0x746547ed in __libc_start_main (main=0x58e0d5f0 , argc=11, argv=0x7fffdd38, init=, fini=, rtld_fini=, stack_end=0x7fffdd28) at ../csu/libc-start.c:332 #37 0x58e0d52a in _start () -- 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
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
On Mon, Jan 03, 2022 at 01:39:21PM +0100, Mattia Rizzolo wrote:
> On Sun, Jan 02, 2022 at 06:53:52PM +0100, Mattia Rizzolo wrote:
> > > > the v96 branch of https://salsa.debian.org/dilinger/chromium
> >
> > FWIW, I'm trying to build it myself as well
>
> Here it started chrashing as soon as I tried to open a new tab, and
> after that it refuses to load my main profile (but it loads others).
After rolling back, it seems to have nuked all of the saved passwords
and login information I had (I don't know if this is only an effect of
the rollback and they are actually there somewhere), as well as all
cookies.
--
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
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sun, Jan 02, 2022 at 06:53:52PM +0100, Mattia Rizzolo wrote: > > > the v96 branch of https://salsa.debian.org/dilinger/chromium > > FWIW, I'm trying to build it myself as well Here it started chrashing as soon as I tried to open a new tab, and after that it refuses to load my main profile (but it loads others). Here is what it prints on the console: mattia@warren /tmp % chromium [3249439:3249439:0103/133254.120313:ERROR:power_monitor_device_source_stub.cc(11)] Not implemented reached in virtual bool base::PowerMonitorDeviceSource::IsOnBatteryPower() [3249485:3249485:0103/133254.419923:ERROR:gpu_init.cc(457)] Passthrough is not supported, GL is desktop, ANGLE is [3249485:3249485:0103/133254.445016:ERROR:sandbox_linux.cc(376)] InitializeSandbox() called with multiple threads in process gpu-process. [3249439:3249468:0103/133258.019370:ERROR:chrome_browser_main_extra_parts_metrics.cc(226)] crbug.com/1216328: Checking Bluetooth availability started. Please report if there is no report that this ends. [3249439:3249468:0103/133258.020176:ERROR:chrome_browser_main_extra_parts_metrics.cc(229)] crbug.com/1216328: Checking Bluetooth availability ended. [3249439:3249468:0103/133258.020199:ERROR:chrome_browser_main_extra_parts_metrics.cc(232)] crbug.com/1216328: Checking default browser status started. Please report if there is no report that this ends. [3249439:3249468:0103/133258.284415:ERROR:chrome_browser_main_extra_parts_metrics.cc(236)] crbug.com/1216328: Checking default browser status ended. [3249439:3249439:0103/133259.591406:FATAL:accessibility_paint_checks.cc(60)] Check failed: node_data.GetNameFrom() == ax::mojom::NameFrom::kAttributeExplicitlyEmpty (kAttribute vs. kAttributeExplicitlyEmpty) 0x55c6fb7c92d0: BookmarkButton is focusable but has no accessible name or placeholder, and is not explicitly marked as empty. BrowserRootView -> NonClientView -> OpaqueBrowserFrameView -> BrowserView -> TopContainerView -> BookmarkBarView -> BookmarkButton #0 0x55c6ef3a2d79 (/usr/lib/chromium/chromium+0x824bd78) #1 0x55c6ef2d2353 (/usr/lib/chromium/chromium+0x817b352) #2 0x55c6ef2ed596 (/usr/lib/chromium/chromium+0x8196595) #3 0x55c6ef2edffe (/usr/lib/chromium/chromium+0x8196ffd) #4 0x55c6f1fd483a (/usr/lib/chromium/chromium+0xae7d839) #5 0x55c6f1fc7e92 (/usr/lib/chromium/chromium+0xae70e91) #6 0x55c6f1fcb985 (/usr/lib/chromium/chromium+0xae74984) #7 0x55c6f1fcb7a8 (/usr/lib/chromium/chromium+0xae747a7) #8 0x55c6f25a21bc (/usr/lib/chromium/chromium+0xb44b1bb) #9 0x55c6f1fc86ec (/usr/lib/chromium/chromium+0xae716eb) #10 0x55c6f1fcc72c (/usr/lib/chromium/chromium+0xae7572b) #11 0x55c6f0a59f58 (/usr/lib/chromium/chromium+0x9902f57) #12 0x55c6f05f0b71 (/usr/lib/chromium/chromium+0x9499b70) #13 0x55c6f063ef56 (/usr/lib/chromium/chromium+0x94e7f55) #14 0x55c6f063e891 (/usr/lib/chromium/chromium+0x94e7890) #15 0x55c6f0704e02 (/usr/lib/chromium/chromium+0x95ade01) #16 0x55c6f0705928 (/usr/lib/chromium/chromium+0x95ae927) #17 0x55c6eeead34a (/usr/lib/chromium/chromium+0x7d56349) #18 0x55c6ef3421cd (/usr/lib/chromium/chromium+0x81eb1cc) #19 0x55c6ef3632d6 (/usr/lib/chromium/chromium+0x820c2d5) #20 0x55c6ef362a88 (/usr/lib/chromium/chromium+0x820ba87) #21 0x55c6ef363892 (/usr/lib/chromium/chromium+0x820c891) #22 0x55c6ef2f655f (/usr/lib/chromium/chromium+0x819f55e) #23 0x55c6ef363e28 (/usr/lib/chromium/chromium+0x820ce27) #24 0x55c6ef322a15 (/usr/lib/chromium/chromium+0x81cba14) #25 0x55c6ec2baa33 (/usr/lib/chromium/chromium+0x5163a32) #26 0x55c6ec2bc9de (/usr/lib/chromium/chromium+0x51659dd) #27 0x55c6ec2b7e32 (/usr/lib/chromium/chromium+0x5160e31) #28 0x55c6eed79f7d (/usr/lib/chromium/chromium+0x7c22f7c) #29 0x55c6eed798df (/usr/lib/chromium/chromium+0x7c228de) #30 0x55c6eed7719a (/usr/lib/chromium/chromium+0x7c20199) #31 0x55c6eed77a8b (/usr/lib/chromium/chromium+0x7c20a8a) #32 0x55c6eaa10721 ChromeMain #33 0x7f7cbdfd17ed __libc_start_main #34 0x55c6eaa1052a _start Task trace: #0 0x55c6f0705676 (/usr/lib/chromium/chromium+0x95ae675) #1 0x55c6ef58b1c0 (/usr/lib/chromium/chromium+0x84341bf) #2 0x55c6ef5b62dc (/usr/lib/chromium/chromium+0x845f2db) IPC message handler context: 0xB99CF134 Crash keys: "total-discardable-memory-allocated" = "8388608" "gpu-gl-renderer" = "Mesa Intel(R) HD Graphics 520 (SKL GT2)" "gpu-gl-vendor" = "Intel" "gpu-generation-intel" = "9" "gpu-vsver" = "4.60" "gpu-psver" = "4.60" "gpu-driver" = "21.2.6" "gpu-devid" = "0x1916" "gpu-venid" = "0x8086" "ui_scheduler_async_stack" = "0x55C6F0705676 0x55C6EF58B1C0" "extension-1" = "oboonakemofpalcgghocfoadofidjkkk" "num-extensions" = "1" "switch-12" = "--origin-trial-disabled-features=CaptureHandle" "switch-11" = &qu
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote: > > I've got 96.0.4664.110 building on both bullseye and sid Trying it, I see it still build-depends on python-jinja2. That package is now gone, so it's not actually buildable in sid anymore. Correlated, do you know how long do they plan on keeping using python2? That's plainly unsuitable, it really is not going to last much longer in debian. > > the v96 branch of https://salsa.debian.org/dilinger/chromium FWIW, I'm trying to build it myself as well (after injecting an old python-jinja2 and an old python-markupsafe). > Alright, crashes are solved and the packages are now usable. After some > cleanups (listing CVEs in changelogs, This doesn't seem to be done as of the current tip of you v96 branch. > merging/pushing a bunch of > commits in my branch, possibly dropping strong stack protection from > builds to silence warnings from older clang versions, and going through > lintian errors/warnings), it should be ready to upload. TBH, I don't think I am able to judge the appropriateness of most of those changes... Though I suspect I could close most of my eyes and upload it to unstable: can't be much worse than what we have... > How should I handle this? NMU to sid, let people try it out, and then > deal with buster/bullseye? Upload everything all at once? Procedure would be NMU to unstable first, IMHO. > I also haven't heard from anyone on the chromium team yet - should I > add myself as an uploader and do a normal (non-NMU) upload? Do any of > them care? Without hearing from them, adding yourself to Uploaders would be inappropriate. -- 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
Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Tue, Dec 07, 2021 at 07:31:09PM +0100, Tomas Pospisek wrote: > > Obviously I cannot promise anything here; I'm currently even more in the > > dark > > than you. :-) But if there's a list of relevant bugs somewhere, I at least > > have a place to try to understand the issues at hand. The one bug I had in mind when I wrote my email was this: https://bugs.chromium.org/p/chromium/issues/detail?id=1250231 However I saw in the past also some cases of a bug reported, few versions later bug fixed, but actually the bug wasn't even touched, so most likely somebody else noticed "internally" but never saw the bug report. Besides that, look at the stupidly long list of patches. I consider it fair to say that for most of them chromium upstream could just trivially incorporate build flags or support our needs: none of those patches change foundamental behaviour or so. > PS: I have included Mattia Rizzolo, Michael Gilbert and the Debian Chromium > Team directly in the recipients, to be sure they see this email. I do hope > you all do not mind. That's all fine with me (also, I'm subscribed to d-d@ (and d-release@), but I'm not actually involved in the maintenance. Rather, I'm adding here Michel Le Bihan who actually maintained chromium in the past 8+ months, and I can only say that he did a great job, despite the short time. -- 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
Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Mon, Dec 06, 2021 at 08:53:37PM +0100, Paul Gevers wrote:
> I have good experience with some of my upstreams where they supported me by
> adapting their build system to enable building without the bundled/vendored
> dependencies. Has this been tried? Would it be worth pursuing?
It has been, yes.
I was looking when Micheal reported a few bugs (after my prodding) to
get a few build issues solved (actual FTBFS when building with specific
build flags). Even those bug reports were completely ignored with no
answer whatsoever; the patches also ignored.
I'm led to believe the chromium team is not really playing with the
community at all, rather they are just following their internal bug
tracker instead.
Likewise, they are obviously not interested in supporting anything that
is not the official Google Chrome build (if it can even said they are
"supoprting" 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
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
> Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
> > The problem really is lack of maintenance. In my opinion, chromium deserves
> > an active *team* to support it in Debian.
[..]
> > We'll not ship it in bookworm unless we see steady uploads
> > in unstable and we see security uploads in stable.
FWIW, as the person currently sponsoring the (few) uploads thatt happen,
I also approve of this.
I had some hopes for the current "team" (m)ilbert and Michel), but
gilbert's mail even started bouncing, and Micheal became less and less
responsive :( - I understand it's a complicated package so yes, there
needs to be a real team: I also recommend you require an active (as
gilbert is not) DD in the team that actually maintains chromium (so not
me who just sponsor the uploads).
--
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
Re: uscan roadmap
On Wed, Dec 01, 2021 at 12:39:41PM +0100, Geert Stappers wrote: > Summary: unhide redirectors And not only. > On Wed, Dec 01, 2021 at 09:11:17AM +0100, Yadd wrote: > > after few discussions with some devscripts maintainers, we decided to build > > a new "version=5" format for debian/watch. To be clear, this is a *very* non-ready proposal that we are getting through the wider community. Nothing of this is implemented anywhere. > >* URL and regex are separated > >* Some default values change. For example, `dversionmangle` default > > value will be "auto" (drop +dfsg, ~ds,...), uversionmangle=s/-/~/g, > > filenamemangle=s/.*?(\d[\d\.]*@ARCHIVE_EXT@)/@PACKAGE@-$1/... I honestly would like to add website-aware functionalities to uscan, such as exactly this. > I think the move from v4 to v5 is an excellent opportunity > to express in the watch file that there is a dependency on a redirector. [..] > Version: 5 > Source: https://qa.debian.org/watch/sourceforge/ > -(.+)\.tar\.gz debian uupdate I would like something like: Source: qa-redirector Source-Options: name: sourceforge project: Likewise, I would love if uscan could just learn how github, gitlab, launchpad, etc are made so prople won't have to bother with sticking urls into watchfiles, such as: Source: GitHub Source-Options: namespace: trendmicro project: tlsh match-on: tags|releases To go either matching on https://github.com/trendmicro/tlsh/tags or https://github.com/trendmicro/tlsh/releases. using then Scheme (a name that, tbh, I don't particularly like right now) for the tags or releases regex. > And I think such change will allow removal of > >bare >Disable all site specific special case code such as URL >redirector uses and page content alterations. > > from the uscan code and uscan manual page (they are in /usr/bin/uscan ) > > > The goal is to have documented that there are extra components being used. > Avoiding nasty surprises. this feels like the opposite direction I'm proposing above :D > Awareness of redirectors will get us more redirectors. > Those redirectors will help us to prevent that `uscan` > must get a javascript interpreter. Possibly, I'm indeed kind of unimpressed that we grew a parse for nodejs' package.json and perl's META.json. Though I accepted it because I saw some value, I'm totally in awe of universes where that is actually needed.. -- 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
Re: Require packages to build without any configured DNS
On Tue, Sep 14, 2021 at 10:05:01AM +0200, Johannes Schauer Marin Rodrigues wrote: > Hi, > > Quoting Mattia Rizzolo (2021-09-06 16:39:39) > > As the pbuilder maintainer, I've been asked to make it serve a non-working > > /etc/resolv.conf just to make that bug above moot, so I'm quite biased on > > the > > matter myself :) > > sbuild already disables network access for all chroot backends that support > it. As several people already stated, this is *not* about network access. > Schroot, the default chroot backend, currently doesn't allow this. See > #802849. Likewise pbuilder, yes. > The only chroot backend that allows disabling the network is the unshare > backend. It does so, by unsharing the network namespace, only bringing up the > loopback interface and writing an empty /etc/resolv.conf. So you ship an *empty* /etc/resolv.conf? Then I suppose you also can't build packages using dnspython in their tests with your configuration? -- 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
Require packages to build without any configured DNS
Hi,
during the year, a src:dnspython change made it so that any software
importing that library now requires a valid /etc/resolv.conf with at
least one nameserver configured.
This also made it so that something between 50-100 packages now fail to
build if the build system doesn't have any working /etc/resolv.conf. I
venture to say that this is a very reasonable configuration to have in a
build system that tries to be network-disabled.
It must be noted that no actual network operation happen, so this
doesn't fall into the "no network activity" bucket.
This is the bug that was filed against dnspython: https://bugs.debian.org/989171
Do anybody on the list have any opinion on where is the bug, on
dnspython, or on the build environment?
As the pbuilder maintainer, I've been asked to make it serve a
non-working /etc/resolv.conf just to make that bug above moot, so I'm
quite biased on the matter 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
Re: src:developers-reference - pt_BR translation initiative
On Wed, Aug 25, 2021 at 12:11:17PM +, Thiago Pezzo (tico) wrote:
> Hi, Sean,
>
> > Please consider Debian Policy too! We've got po4a infra set up.
> That would be great too. Today we'll have our team's BoF at DebConf, I'll
> talk about translating the Debian Policy.
That's all nice and dandy, however please make sure to keep up with
those translations...
/me - who is kind of not amused at how the German (and clearly also the
newly added Portuguese) are not keeping up at all with devscripts
--
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
Re: Have the watch file checks stopped?
On Mon, Aug 23, 2021 at 12:59:39PM +0200, Gard Spreemann wrote:
> Have the uscan watch file checks that feed qa.debian.org stopped? Is it
> on purpose? Perhaps a consequence of the recent release?
That's one part that's included in the UDD downtime reported here:
https://lists.debian.org/debian-qa/2021/08/msg0.html
--
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
Re: inconsistent mailgraph settings
On Sat, Aug 21, 2021 at 10:36:04AM +0200, Tomas Pospisek wrote: > Hi Vincent, > > On 20.08.21 16:50, Vincent Lefevre wrote: > > My bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734 > > has been closed again, with no explanations. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734;msg=12 claims that > the bug was closed via > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734;msg=10 . However I > can't see why the latter mentioned message would close the bugreport. Can > anybody shed some light on this? Likely Jörg Frings-Fürst BCCed the -close@ address. There are some people who do 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
Re: Adding an epoch to the 'steam' package
On Mon, Aug 16, 2021 at 03:08:24PM +0100, Simon McVittie wrote:
> I would like to add the same 1: epoch to the steam package in Debian
> and all of its binary packages, so that all of our version numbers
> (Valve's, Debian's and Ubuntu's) are directly comparable again.
ACK, I'm also fine with adding this epoch.
--
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
Re: Slower/no acceptance from dak?
On Tue, Aug 03, 2021 at 03:11:09AM +0530, Utkarsh Gupta wrote:
> I've been facing issues with the acceptance emails for a while and was
> wondering if it's known or something, so asking here.
AFAIK, nothing is known.
> I've uploaded a couple of packages to unstable a while ago but that
> didn't make it through (at least that's what it looks like). Neither
> did I get the acceptance mail nor the rejection.
Please give package names as examples.
dak's log all use package names, it's too hard to grep by uploader
names.
Trying, the last packages processed with you as uploader is:
Jun 11 00:12:51 micro_2.0.9-1_source.changes processed successfully
(uploader utka...@debian.org)
which was a while ago.
--
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
Re: What are desired semantics for /etc/shells?
Hello,
I have no personal stake either, the same as the others who already
replied, but I guess I'll chime in as well.
On Mon, Jun 14, 2021 at 02:39:30PM +0200, Helmut Grohne wrote:
> > I think using triggers has an obvious benefit here, but depending in the
> > intended semantics of `/etc/shells`, implementing the part about preserving
> > user changes may be difficult. A possible solution could be moving
> > `/etc/shells` to `/var` and replacing it with a symbolic link when its
> > contents
> > match with the generated one one.
>
> At this time, my personal preference would be turning /etc/shells into a
> symbolic link to an autogenerated file. Replacing that link with a
> manually maintained file would keep the original flexibility at the
> slightly increased cost of having to manually update it for added or
> removed shells while providing significant improvements for the vast
> majority of users.
I have an enhancement proposal to your suggestion.
Add an /etc/shells.add and /etc/shell.remove or somesuch, that are
parsed while generating the proposed /var/ file, that are to
be used by the system administrator to instruct the debianutils trigger
to either remove a shell from the list even if it's installed, or to add
a shell to the list even if it's not installed. It probably means that
the code handling the /var/ file should probably be callable
by other means than just a dpkg trigger, so that the system
administrator can force update the shell list when they update
add/remove files.
This way you'd entirely remove another case where you'd need to remove
the symlink and as such lose the ability to auto-update the file when
you add/remove shells (that are not otherwise already listed in the .add
and .remove files), and, in fact, make it possible for those systems to
be even more declarative since the administrators wouldn't be messing
with files that are already managed by other tools.
(this is somewhat inspired by /etc/hosts.{allow,deny})
--
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#989607: ITP: 2geom -- robust computational geometry framework
Package: wnpp Severity: wishlist Owner: Mattia Rizzolo X-Debbugs-Cc: debian-devel@lists.debian.org, debian-multime...@lists.debian.org Control: block 989606 by -1 * Package name: 2geom Version : 1.1 Upstream Author : Inkscape developers * URL : https://gitlab.com/inkscape/lib2geom * License : LGPLG-2.1 or MPL-1.1 Programming Lang: C++ Description : robust computational geometry framework The library is descended from a set of geometric routines present in Inkscape, a vector graphics editor based around the Scalable Vector Graphics format, the most widespread vector graphics interchange format on the Web and a W3C Recommendation. Due to this legacy, not all parts of the API form a coherent whole (yet). Rendering is outside the scope of this library, and it is assumed something like libcairo or similar is employed for this. 2geom concentrates on higher level algorithms and geometric computations. This library was developed mainly to be used by Inkscape, but it's released separately in the hope to be useful to others. I plan to maintain it within the Debian Multimedia team (like I do for inkscape), and welcome others to join 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
Re: Epoch bump for kernelshark
On Sun, May 23, 2021 at 03:17:10PM -0500, Richard Laager wrote: > On 5/23/21 8:34 AM, Sudip Mukherjee wrote: > > And, as a result, upstream kernelshark is now at v2.0 but the Debian > > packaged version is at v2.9.1 and I will need to add an epoch to the > > version to package it directly from its new upstream repo. > > > > Current version: 2.9.1-1 > > Proposed version: 1:2.0-1 > > How close is upstream to 3.0? If not close, are they willing to bump to 3.0 > anyway to avoid this versioning issue? And in the meantime, I recommend you use 2.0-1 as source version, and make the binary 2.9.1+really$(DEB_VERSION) (DEB_VERSION coming from /usr/share/dpkg/pkg-info.mk) -- 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
Re: Missing samba DSA-4513 changelog in https://metadata.ftp-master.debian.org/changelogs/
On Sat, May 01, 2021 at 02:26:31PM +0900, Hideki Yamane wrote:
> On Wed, 7 Apr 2021 18:20:09 +0200
> Julien Cristau wrote:
> > The samba package is held in stable-new by bug#939419, see
> > https://release.debian.org/proposed-updates/stable.html
>
> Thanks, Julien.
>
> Can we fix it with cherry-picking
> https://salsa.debian.org/samba-team/samba/commit/bedd051122980c31dd1c1431ce9e40ba01dc5990
> as 2:4.9.5+dfsg-5+deb10u2 then?
Rather, I think
https://debdiffs.raspbian.org/main/s/samba/samba_4.9.5+dfsg-5+deb10u1+rpi1.debdiff
would be more appropriate, as it is, for me, more appropriate than
dropping a binary.
--
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
Re: Proposed mass-bug filing: missing support for build-arch or build-indep
On Mon, Apr 19, 2021 at 03:11:21PM +0200, Lucas Nussbaum wrote:
> I would like to propose a mass bug filing on source packages that miss
> support for build-arch or build-indep targets in debian/rules.
+1
> There are currently 411 packages in testing that do not include those
> targets, according to lintian's debian-rules-missing-recommended-target
> tag. (I will also file a bug against lintian to reflect that those
> targets are now required).
That's way more than I'd expected, but as you mentions it's a good
indicator of not-greatly-maintained packages, so I'm cool 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
Re: debtags.debian.org tag vocabulary now editable by all DDs
Hi,
On Mon, Apr 05, 2021 at 06:26:19PM +0200, Enrico Zini wrote:
> * I need help with routine dput-ting of tag data
>
> I could still use help from one or more DDs, doing regular uploads of
> tags from the site to the archive.
>
> It means running a script that generates a source package, GPG-signing
> it, and uploading it with dput. It needs to be done once a month or so,
> and I regularly miss doing that. If you're interested, get in touch and
> we can go through the script to make it work on your system.
I don't remember if this happened, but did you try to get dak to pull
automatically (or the other way around: debtags pushing automatically)
during dinstall, like it's done by i18n?
--
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#982562: general: Storing upstream signatures next to upstream tarballs is problematic
On Fri, 12 Feb 2021, 10:25 am Rene Engelhard, wrote: > Hi, > > Am 11.02.21 um 21:59 schrieb Raphaël Hertzog: > > > [1] For details it happened in dbus-glib: > > https://snapshot.debian.org/package/dbus-glib/0.110-2/ -> it has .asc > file > > https://snapshot.debian.org/package/dbus-glib/0.110-3/ -> no .asc > > https://snapshot.debian.org/package/dbus-glib/0.110-4/ -> no .asc > > https://snapshot.debian.org/package/dbus-glib/0.110-5/ -> it has a > > different .asc file > > > Why should anything else than -1 have a .asc file anyways in the upload? > > That's .orig.tar.xz (or whatever compression) and the accompanying > .orig.tar.xz.asc. > > Since -2 etc don't upload the .orig again there's no need to upload the > signature of the .orig again. You are likely confusing the .dsc and the .changes. The .dsc *always* refer to all the source files, even if not uploaded. That clearly also includes the .asc. >
Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic
On Fri, 12 Feb 2021, 12:52 am Guillem Jover, wrote: > Then there's the problem with changing contents for already seen > files, which seems like a dak bug. It does not allow to change a > tarball once it has been seen, so I don't see why it should allow a > changed .asc either? > That's not true. Call it a dak bug or a feature, depending on where you stand. Dak forgets everything concerning a file as soon as it's not present in any suite it manages. This usually appears in the way of people uploading a package with the same name and version of something that was removed long long ago and since then archived and forgotten by dak. It's totally possible to overwrite a tarball with the same filename too that way, you just need to wait the appropriate amount of time and upload things in a way that you replace the upstream tarball. (Honestly I haven't tried this myself, but I have a package where if you'd like I can actually go and try to prove my point). Back to the original bug report: I personally believe that the signatures there are fine, and I don't believe in the "upstream the re-sign an already released tarball" story. But I consider the current forgetfulness of dak as a bug.
Re: Possible DEP proposal - contribution preferences
On Tue, Feb 09, 2021 at 10:40:39AM -0800, Russ Allbery wrote: > Jonas Smedegaard writes: > > > Let's see if Debian can agree on a single normalization of 822-ish > > files. For starters, I disagree that "wrap-and-sort -a" is a suitable > > normalization, as that will involve re-indentation when keys change. > > Instead, I propose this as starting point: > > > wrap-and-sort -ast > > I've been using wrap-and-sort -ast on all of my packages for a while, with > much the same justification. Indeed, same here :) > My recollection is that the relevant Config::Model model has a slightly > different preferred normalization form? Those are the two most common > tools used for this, I think, so if the two of them could agree, that > would go a long way towards having a common format (and this may have > already happened without me knowing). That's exactly what I'm saying in the above bug. That bug asks to change wrap-and-sort's defaults, and my answer is saying that if the default change, we should do the same to cme. -- 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
Re: Possible DEP proposal - contribution preferences
On Tue, Feb 02, 2021 at 01:55:19PM +, Jelmer Vernooij wrote:
> * Whether or not contributors can feel free to reformat
>files (e.g. wrap-and-sort -a -v).
>("allow-reformatting" in lintian-brush.conf)
On this, please also read https://bugs.debian.org/895570#13
tl;dr: I honestly believe we should just decide on a format, and
converge towards it.
It apparently works quite well for python as a whole ecosystem, where
now pretty much nobody is "against" pep8 (or even black!). There is no
reason we can't manage to decide on a wrapping format and stick with 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
Re: Bug#981113: ITP: root -- open-source data analysis framework
On Tue, Jan 26, 2021 at 04:59:48PM +0100, Christoph Biedl wrote: > Julien Cristau wrote... > > > On Tue, Jan 26, 2021 at 04:34:14PM +0100, Stephan Lachnit wrote: > > > * Package name: root > > [...] > > > > > > I want to maintain ROOT in the science team. ROOT was already in Debian as > > > `root-system` [1], but hasn't been updated since 2015. > > > > > > [1] https://tracker.debian.org/pkg/root-system > > > > > Please re-use the old name. "root" is a terrible choice of package name. > > At least. Even "root-system" is not very distict, I'd rather choose > something like "root-analysis-framework", assuming that name is a good > description for what the package does. tbh I'd just keep root-system only for consistency with the past. However I have another concern, rather than the name: > > > I will probably go with a more easy maintainable route like I did with > > > Geant4 > > > for the start and do package splitting later. I don't understand this statement. It's not like it's the package split that makes it more or less maintenable IMHO. Actually, IME it's often a more split package that might be somewhat easier to maintain. The problem really is about somebody who can dedicate a long time to it, not just one or two years. For reference, just looking at tracker: * added in 2007, but the maintainer was immediately unavailable next year, so there were NMUs starting in 2009 not even 21 months after the first upload. Removed in 2011 since nobody seriously picked it up * re-added in 2012, the maintainer looked motivated and clearly did quite a few uploads to maintain it, but that winded down in 2014, and after a bunch of NMUs was removed in 2016 (18 months after the last upload and 11 months after being removed from testing, so you can really just think of it as removed in 2015) So history of this package shows that the interest wanes after ~2 years, which meakes me wonder wether this is only driven by some external factor, like some phd-driven work or similar. I'm *not* in favor of adding such big piece of software to the archive, if it's interest is something that is assured to disappear in a couple of years. So please make sure of your motivation and state it. You've been a DM for less than a year and you are already doing the NM to become a DD, so I really hope the above history of src:root-system doesn't happen again, at least not that quickly :) -- 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
Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default
On Sat, Jan 09, 2021 at 08:37:48PM +0100, Samuel Thibault wrote: > Lisandro Damián Nicanor Pérez Meyer, le sam. 09 janv. 2021 15:53:41 -0300, a > ecrit: > > # __FILE__ is a public, well defined API > > ? My copy of C11 says > > “ > __FILE__ The presumed name of the current source file (a character string > literal) > ” > > that's not so well-defined. I would not expect it to necessarily > contain the path to it. In fact, empirically I've seen that __FILE__ is expanded to whatever path gets passed to the compiler. You can easily see how stuff build with cmake get a full path in there, whereas stuff built with make gets a path relative to the Makefile. -- 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
Re: Bugs "fails to migrate to testing for too long" (Was: cluster3 dropped out of testing)
On Wed, Dec 09, 2020 at 09:44:25AM -0800, Diane Trout wrote: > Could we add a note to tracker or excuses for non-free packages on what > the developer needs to do to get it to migrate? IMHO, that's inappropriate. That would mean artificially adding into britney something that is really a nuance of how the archive and buildd system is currently set up. Alright that's definitely doable, but I consider this something that the maintainer of a non-free package ought to know (it's clearly written in the devref, for starters). There are quite a few more details of how non-free is different from any other suite, starting from how little testing of it there is. Though I guess in the past years the britney report on tracker changed enough to be more and more friendly to developers, so I guess the release team (which is the team that would be in charge on the content of the "testing migrations" box) would do it if talked to appropriately… Even then, the message says that "cluster3 has no binaries on any arch" - from there why can't one try to figure why there are no binaries? I'm positive that dumping the tracker link and that message in debian-mentors@ would yield the reason why it's stuck quite quickly. (note that the thread Andreas started on -devel@ is about the how people seems to notice first the "failed to migrate to testing" bugs, not about why cluster3 is not migrating). > My understanding of your explanation is that we need to do a binary > upload for non-free because it's not auto-built. Rather, I encourage you to read the devref part on how to enable auto-building. The package seems to have XS-Autobuild: yes in d/control even in oldoldstable, so I guess it means nobody sent the request to the buildd admins. > It's a difference from how main is handled and and it seems like > putting documentation for the difference would help prevent confusion > in the future. I insist that such doc belongs to devref. If that is lacking, devref should be improved. The current devref maintainer is very open to patches :) -- 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
Re: Bugs "fails to migrate to testing for too long" (Was: cluster3 dropped out of testing)
On Wed, Dec 09, 2020 at 10:17:56AM +0100, Andreas Tille wrote: > I'd like to point to a discussion on the Debian Med mailing list which > was caused by a "fails to migrate to testing for too long" bug. I > fully agree that these bugs should be filed. However, the bugs are > immediately set to "Done" later by the issuer of the bug. I discussed > this with Paul before and he said reasons for this - but I think its > wrong since the issue vanishes from BTS and becomes invisible for the > maintainers which is not helpful IMHO. > > My suggestion is to not set those bugs to Done to keep the red flag > for the package raised. I'm instead convinced that closing those bugs directly is right. The reason the packages are not migrating has nothing to do with the bug, and keeping it open adds to the confusion as then it's reported as a "regression" when really it isn't. > On Tue, Dec 08, 2020 at 08:46:04PM -0800, tony mancill wrote: > > Hi Diane, > > > > On Tue, Dec 08, 2020 at 10:14:24AM -0800, Diane Trout wrote: > > > My coworker noticed cluster3 dropped out of testing and I'm confused > > > why. > > > > > > https://tracker.debian.org/pkg/cluster3 > > > says that "cluster3 has no binaries on any arch", and there are no logs > > > at buildd https://buildd.debian.org/status/package.php?p=cluster3 for > > > it > > > > > > However if I grab either the source package for 1.59+ds-2 or the > > > current main branch from salsa and try building, I get a package with > > > binaries. > > > > > > The only mildly annoying thing is when I build in unstable, it ends up > > > with a dependency on python3 (<< 3.10), python3 (>= 3.9~) which doesn't > > > install on testing. > > > > > > But the package seems to be fine, so any thoughts why it was held back? > > > > Sometimes you can find this information in the PTS [1] in the News > > section [2]. In this case cluster3 failed to migrate from unstable to > > testing before a fixed deadline [3]. (Although I don't know exactly why > > *that* happened.) Because you seem to not be aware of how non-free works. Non-free is not autobuilt, so when Andreas uploaded 1.59+ds-2 without any binaries then "cluster3 has no binaries on any arch". Since there are no binaries associated with the source, britney refuses to migrate it. Indeed, one could just do a binary-only build of it, upload it, and it would migrate stright the next day. Or one could ask for an exception to the non-free buildds as docuemnted on https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#marking-non-free-packages-as-auto-buildable As you can see, nothing relating to that 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
Re: How to cleanup Ubuntu bugs for my Debian packages?
Hello all, For the sake of disclosure, I'm also an Ubuntu Developer. On Sun, Nov 29, 2020 at 12:58:53PM +0100, Iustin Pop wrote: > I have a Launchpad account, and the project itself lists my Launchpad > account as "maintainer", but on the bug itself I can't mark it as "Won't > fix", only as "Invalid". Which tells me that I'm missing _some_ rights > in Ubuntu itself… Indeed, there are some status that are restricted to the so called "bug supervisor", which a team defined in the project settings in launchpad. In the case of Ubuntu itself, that is the ~ubuntu-bugcontrol team https://launchpad.net/~ubuntu-bugcontrol . Users who are part of that team have access to all the features of the bug tracker. Another common limitation imposed on users that are not bug supervisors, is that they cannot re-open an already closed bug. Or, targeting a series. > I also have > https://bugs.launchpad.net/ubuntu/+source/python-mox/+bug/852095, where > again I can't mark "Won't fix" (it refers to distributions 8 years old)… I've marked that as wontfix. However, in the case of https://bugs.launchpad.net/ubuntu/+source/python-pylibacl/+bug/1876350 "invalid" is the correct status, not "wontfix". BTW, in case you missed it, if you are going to fix bugs reported on launchpad, you can use "LP: #x" in the (debian) changelog and close them, similarly to what you do to close bugs against the BTS. -- 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
Re: Epoch version for golang-github-gomodule-redigo-dev?
On Thu, 26 Nov 2020, 11:30 am Holger Levsen, wrote: > > The technical problems I'm are aware of are that a.) version numbers > (with and without epoch) need to be unique, so if you had 0:2.0.0-1 > you are not allowed to ever have 1:2.0.0-1 again. That's enforced > by dak however. > That's not enforced by dak. The only case it would be enforced is when once try to upload the 1: version while the 0: is still published, which is rare in the cases of epochs. The other technical problem is that .deb filenames don't contain > the epoch, which is a problem the archive Which is the same problem as above, from my understanding. There is that risk in having two filenames with different content across history. IIRC, there *used to* be an actual problem way back in some program that couldn't handle the : in filenames, and that's why they are not present to this day. I argue that we could just put that : (or the %-encoded version, to avoid accidentally ssh-ing somewhere...) and be done with whatever problem. The other problem, is that maintainers regularly forge to put the epoch when writing version restrictions in d/control, but those are just bugs that people should be aware of... (Explicitly not drawing any conclusion here...)
Re: Bug#973637: flag debian/watch files that use older versions of the format
On Mon, Nov 02, 2020 at 10:54:11PM +0100, Xavier wrote: > But version 2 is really deprecated and it's > not easy to maintain uscan with 4 versions (It took me a lot of hours to > rewrite old uscan to modern Perl-OO). > That's why I'd like to see a "error" tag for version ≤ 2. Right, but currently version=2 is not explicitly marked as "deprecated" anywhere. Could you please send a MR updating the docs doing so? I also think ds_warn() its usage would be good (then tracker.d.o and others would rely the warning, etc). > 3. After bullseye release, I'd like to propose to remove version=2 > support from uscan. +1 For context of d-devel@, version=2 is currently used by a total of 350 packages in the whole archive, I reckon dropping support for it is totally doable. I think we can easily: 1) mark the thing as deprecated in the manpage and warning at runtime 2) add a note for the next DevNews 3) wait a few months after the bullseye release 4) MBF the remaining version=2 packages 5) wait a few more months 6) drop the support ~1/~1.5 years from now -- 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
Re: DAM Key and identity requirements
On Thu, 24 Sep 2020, 10:51 am Bastian Blank, wrote: > Hi Enrico > > On Sun, Sep 13, 2020 at 09:11:04AM +0200, Enrico Zini (DAM) wrote: > > * Minimum key size and acceptable algorithms are actually the domain of > >keyring-maint, and we just check those for them. > >At the time of writing this, a new key must be larger than 1024bits, > >ideally at least 4096bits, and capable of hashes stronger than SHA1. > >Please check [KDO] for more recent information. > > Hmm, this page do not really read like some sort of policy. > > It talks about key size in bits, which only applies to RSA. What about > X25519? > You should bring that to the keyring-maints. However I can tell you that EC keys are pretty much always considered good. > * An encryption subkey must be present, since various parts of our > >infrastructure require it. > > Which parts? While encryption subkeys are useful, I can't see anything > _requiring_ this. > Besides NM sending encrypted tokens, also DSA: the db.d.o password is sent encrypted during account creation, and ISTR also other things. > * A signature subkey must be there, since various parts of our > >infrastructure require it. Also, it is needed to build up trust (see > >below). > > Signing subkeys are pretty rare. What is their use-case? > I believe the *sub*key bit was wrong, it most likely was talking about signing capabilities (like above for encryption, it's all about capabilities, not subkeys) Also trust is built using certification, not signing (the C bit, not the > S bit). I don't think subkeys can hold a certification setting. > You clearly haven't read the rest of the mail that is talking how certifications are no longer considered mandatory for the formation of trust.
Re: Mass bugs filing: autopkgtest should be marked superficial (new list)
On Sat, Sep 19, 2020 at 08:39:44PM +0100, Sudip Mukherjee wrote:
> After discussing with few people, I now intend to file them with
> "severity: important" and I will also reduce the severity of the
> previously open similar bugs to 'important'.
That's good.
But please also share your proposed text with this list (as the MBF
rules asks for). Your past filings where IMHO written with a tone that
could be improved. Also I would like to make sure that you include
stuff like your plans with the severity, references to the release team
decisions, etc.
--
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
Re: debian/rules and DEB_BUILD_PROFILES vs _OPTIONS
On Mon, Sep 07, 2020 at 08:03:20AM +0200, Niels Thykier wrote: > Mattia Rizzolo: > >> Or do dpkg or debhelper apply some kind of mapping logic from _OPTIONS > >> to _PROFILES for the popular options nocheck, nodoc, noopt? > > > > debhelper does. various helpers do things differently with such > > options. You should read the manpages for more details. > > > > It does not in the general case. It does for nodoc because > $HISTORICAL_REASONS. Oh, sorry. I misunderstood the question, I read is as "does debhelper apply some logic for _OPTIONS or _PROFILES", nothing relating to mapping from one to the other. -- 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
Re: debian/rules and DEB_BUILD_PROFILES vs _OPTIONS
On Sun, Sep 06, 2020 at 10:53:05PM +0200, Christian Kastner wrote: > It seems that "nocheck" and "nodoc" can be used with both variables. > > However, which one is to be used in debian/rules recipes? Or both, as > suggested here [1]? The thing is, according to the build profile spec, if you specify nodoc or nocheck in _PROFILES you *MUST* also specify it on _OPTIONS (talking about when you do the build), so… > Looking at random packages, newer packages seem to favor just checking > DEB_BUILD_PROFILES to conditionally build documentation, but that would > mean that DEB_BUILD_OPTIONS as recommended by policy is not honored. Yeah, that might cause chances of failing builds if built with nodoc I guess… > Or do dpkg or debhelper apply some kind of mapping logic from _OPTIONS > to _PROFILES for the popular options nocheck, nodoc, noopt? debhelper does. various helpers do things differently with such options. You should read the manpages for more details. > Or are we supposed to transition to just _PROFILES in the long term? There were talks around that with the people involved in writing up the _PROFILES spec, not sure where that go (nowhere I think). -- 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
Re: we do recommend workflows (Re: Why Vcs-* fields are not at least recommended ?)
On Wed, Aug 19, 2020 at 09:56:49AM +, Holger Levsen wrote: > On Wed, Aug 19, 2020 at 02:18:08AM +0500, Andrey Rahmatullin wrote: > > And we cannot recommend using a VCS because we don't usually recommend > > workflows. > [...] > > I don't think anything is "supposed" here. We don't recommend workflows > > yes, we do. workflows and tools. i'm not sure why you think we don't? And, specifically: https://lists.debian.org/debian-devel-announce/2020/04/msg9.html It felt to me 2019 was one of the years of endless debates, kind of surprised by that sentence indeed! -- 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
Re: epoch bump for babl and gegl libraries
On Mon, Aug 17, 2020 at 10:21:37AM +0100, Simon McVittie wrote: > The GNOME team intend to add an epoch to the babl and gegl libraries, … > Historically, versions of these packages were shipped by the third-party > deb-multimedia.org apt repository. That would have been fine, except that > the maintainer(s) of deb-multimedia.org added an epoch to their versions. > It is not clear to me why this was done, and it breaks the versioned > dependency system, manifesting as frequent bug reports for gimp crashing > on startup. Question: what about changing the package name instead, and doing a transition to a new library package name? It would be perfect to catch the occasion of a soname bump, but even then, we are only talking about less than 10 packages to rebuild for a changed library package name. > In principle we could add the epoch to only the binary packages, > but it'll be a lot simpler and less confusing to add it to the source > package's version. Some of the binary package names (particularly > libbabl-dev and libgegl-dev) are going to be long-lived, so restricting > the epoch bump to binary packages would not help us to eliminate the > epoch in a future Debian release. This wouldn't solve the problem of the -dev packages having the epoch in the 3rd party repository, but since you mention that they already removed the package altogether, I think this is fine: your average user wouldn't have installed these binaries but only the shared library binaries, and anybody dealing with building debian packages ought to keep their system usable enough for that porpuse. Over time, people who even had those packages installed would notice somehow… or just disappear by system reinstallation and whatnot. > please do not interpret this as precedent for > having Debian packages reflect epochs added in third-party repositories > in general. It's still not so nice though... -- 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
Re: Festeggiamo DebianDay 2020?
On Mon, Aug 10, 2020 at 11:02:24AM +0200, Giuseppe Sacco wrote:
> qualcuno si è già mosso per fare qualcosa questo fine settimana, o
> sarebbe comunque interessato a partecipare, sia come «visitatore» che
> come organizzatore?
In passato è successo qualcosa a Varese mi pare?
In effetti se si facesse una cena lì sarei felice di venire (come
visitatore, voglia di organizzare qualsiasi cosa meno di zero in questo
momento).
--
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
Re: NMU for Imagemagick?
On Sat, Jun 27, 2020 at 02:51:32PM +0200, Jonathan Carter wrote:
> so any objection if I look into making an NMU upload for this
> package?
You are asking here, but you didn't report on whether you tried to
contact:
1) the maintainer (and here I'm referring to Bastien Roucariès)
2) the security team
before trying to write to d-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
Re: Mass bug filing: dependencies on GTK 2
On Wed, 29 Apr 2020, 9:29 pm Michael Biebl, wrote: > Am 29.04.20 um 19:37 schrieb Simon McVittie: > > On Wed, 29 Apr 2020 at 18:04:41 +0200, Mattia Rizzolo wrote: > > >> I think you should > >> file the bugs at severity:minor, given the amount of involved packages, > >> and the fact that you state we might not be able to remove gtk2 in many > >> many years. > > > > If you say so. I was going to use normal, like I did for the analogous > > dbus-glib MBF; the practical difference between minor and normal doesn't > > seem significant. > > > > fwiw, I think normal seems about right. > I'm not fussy either way, that was mostly my 2¢ given you didn't specify in the OP. As you mention, the practical differences are next to non-existent. >
Re: Mass bug filing: dependencies on GTK 2
On Wed, Apr 29, 2020 at 10:38:27AM +0100, Simon McVittie wrote:
> Quite a lot of source packages (see attached list and dd-list) have
> Build-Depends on GTK 2 (libgtk2.0-dev), or produce binary packages with
> a Depends on it.
>
> Mass-filed bugs for this will be usertagged to appear in
> https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-gnome-maintainers%40lists.alioth.debian.org=gtk2
> and will be marked as blocking #947713.
It is a huge list, but I think it's fine and you should start filing the
bugs.
You haven't included a copy of the proposed text, but I think you should
file the bugs at severity:minor, given the amount of involved packages,
and the fact that you state we might not be able to remove gtk2 in many
many years.
--
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
Re: Salsa update: no more "-guest" and more
On Sun, Apr 26, 2020 at 10:12:41AM -0700, Sean Whitton wrote: > On Sun 26 Apr 2020 at 02:36PM +02, Mattia Rizzolo wrote: > > On Sun, Apr 26, 2020 at 02:07:54PM +0200, Bernd Zeimetz wrote: > >> There are even cli tools that do the same stuff. I'd guess there is at > >> least one on Debian. > > Indeed, after I first lost a phone, and a second one broke, leaving me > > with a quite huge pain to recover my accounts, I started using > > `oathtool` to manage the TOTP and HOTP codes, which is in Debian, and I > > store the secret hash needed to generate the codes with `pass`. > > > > That said, for the only website where I need HOTP (Ubuntu SSO), I stored > > that thing in the HOTP spot of my yubikey, and for everything else they > > also support U2F so I likewise use my yubikey for those as well. > > In such a case, though, haven't you essentially turned it back into one > factor authentication (the single factor being your laptop)? It's still two factor: something I know (password) and something I have (my yubikey). Since I sometimes I don't really know my passwords, I suppose at that point the "something I know" instead of being the actual password is the GPG passphrase used to decrypt the file that actually contains the password, but it's still 2fa. Still I wouldn't consider that to be tied to my laptop (the password storage does live in my laptop, but it's encrypted AND duplicated elsewhere). -- 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
Re: Salsa update: no more "-guest" and more
On Sun, Apr 26, 2020 at 02:07:54PM +0200, Bernd Zeimetz wrote:
> There are even cli tools that do the same stuff. I'd guess there is at least
> one on Debian.
Indeed, after I first lost a phone, and a second one broke, leaving me
with a quite huge pain to recover my accounts, I started using
`oathtool` to manage the TOTP and HOTP codes, which is in Debian, and I
store the secret hash needed to generate the codes with `pass`.
That said, for the only website where I need HOTP (Ubuntu SSO), I stored
that thing in the HOTP spot of my yubikey, and for everything else they
also support U2F so I likewise use my yubikey for those as well.
> No need for a mobile phone.
mobile phones are overrated :P
--
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
Re: Third-party forks of packaged projects
On Fri, Apr 24, 2020 at 05:28:51PM -0400, Kyle Edwards wrote: > In that case, the depending > project "vendors" the third-party dependency with the modifications > that it needs. Which is always horrible for us. If you have any power, please don't do it. Rather find a way to monkey-patch whatever dependency function you are using or whatever is possible in your case. If the upstream maintainer of that library is not available anymore and the project is clearly dormient, perhaps you can take over officially? Or if that patch is "acceptable" just leave it on the bug tracker, and within debian that patch could be applied, so that at least downstram we can strip off that vendored library. That's cleraly possible only if that patch doesn't break stuff, etc. > Obviously, "vendored" dependencies are a no-go in Debian, but how do > situations like this get resolved? vendored dependencies are not really a strict no-go. cases like what you describe are one reason to keep them vendored within a package, and the security team tries keep a list of such vendored libraries, but since few maintainers reports back changes in this area, that list is not really that good (reason not to vendor libraries!!). > I'm imagining the modified project > could be packaged on its own the way any fork would - in that manner, > it would not be much different from packaging MariaDB even though a > package for MySQL already exists. Is my intuition correct here? pacakaging that as a fork it's clearly possible, but it's much more work, and usually doesn't make sense since that vendorerd patches libraries likely won't be used by anything else, and would be updated only together with the "main" software, so separating them is not really useful. -- 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
Re: trends.debian.net updated
On Sat, Apr 11, 2020 at 11:10:48AM +0200, Wouter Verhelst wrote: > On Fri, Apr 03, 2020 at 10:41:55PM +0200, Lucas Nussbaum wrote: > > https://trends.debian.net/ was just updated (with data until April 1st). > > There is a significant bump in the number of co-maintained packages > during the buster release cycle. It is not at all clear to me what > happened there. > > Do you have any idea? My assumption is that the deprecation of alioth lead many "team" formed by 1 or 2 people to be replaced by simply comaintained packages. That, together with the the @packages.d.o maintainer address, I reckon those might also be considered "comaintained" instead of "team maintained". -- 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
Re: Announcing Debian Social
On Thu, Mar 19, 2020 at 11:59:48PM +0100, Rhonda D'Vine wrote:
> Long-term, we plan to authenticate these services against the salsa.debian.org
> service. Some services are part of the way there, others may take some more
> time and collaboration with upstream.
I want to highlight this bit.
In the past formorer said no to this, as he doesn't want salsa to end up
like alioth and be used for too many things. In particular, he said he
wouldn't want anybody to rely on salsa as a user database. sso.d.o. is
the thing that should be used instead (but it's still lacking a proper
guest account backend).
That said, recently somebody else also rised this issue in #alioth, and
it turns out that the salsa admins team is not really on the same page
on 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
Re: Standardized way of extracting additional build-time artefacts (was: Re: RFC: Standardizing source package artifacts build paths)
(note, this is a barely structured brain dump)
On Tue, Mar 10, 2020 at 08:10:55AM +0100, Niels Thykier wrote:
> >> Though, can you elaborate a bit on why the above approach would be
> >> better than a standard ENV variable a la AUTOPKGTEST_ARTIFACTS and some
> >> easy way to declare additional artifacts to be extracted?
> >
> > Mainly, I'd prefer something declarative with glob patterns (a bit like
> > debian/clean or Gitlab-CI's artifacts:paths) rather than having to write
> > logic like these pseudo-patches:
Same.
Having such directory be hidden inside
/build/foo-1.2.3/debian/.build/artefacts/ is kind of a mouthful, but if
that gets to be standardized I think it would be awesome (builders
(sbuild, pbuilder, …) decide on the first '/build/foo-1.2.3/' part of
the path and they know of it; package building happens with CWD in that
place, so build tools should just try to stick to relative paths
'./debian/.build/artefacts/'; everything should Just Work that way).
One thing that strikes me of this proposal, is that you were trying to
"hide" that .build directory from the maintainer; doing this would be
going against that design decision. This is the only "concern" I have
with the proposal. Probably this can be avoided by providing a dh_
helper.
> Ack, I get the part of having a declarative mechanism for selecting files.
And then builder could just take out the whole directory. If that gets
to be (g|x|)zipped or not would be an implementation detail of the
builders (sbuild, pbuilder, …) and of whatever frontend (launchpad,
buildd + wanna-build, …) is used.
> Just to clarify something related. Should debhelper and other tools by
> default archive "certain files of possible interest" (e.g. config.log)?
> Or should we limit it to "on request only"?
That would be some nice automatism indeed, but I think it's something
for "later". If you do, please consider these bits:
* naming the files: you risk clashing with maintainer-set file names
* deciding on whether to put those files there only on failure or all
the time
> The former makes it simpler for people that are interested in the
> "default" parts but also bloats the archive for people that are
> interested in just one file.
"bloating" is indeed important. If we start doing this, frontends need
to decide on a retaining policy. Do we want maintainers to have a say
on this? Like, adding a metadata file to the artifacts to indicate any
interest on those files (this is a successful build: keep for x
days/keep until next successful build + y days, etc etc).
> > I don't have any particular opinion on whether artifacts should be
> > collected into debian/.build/artifacts/, into $DPKG_ARTIFACTS/, or
> > directly into some sort of archive (Gitlab and Jenkins seem to use zip
> > files, which have the advantage of being seekable, so web frontends
> > can presumably read individual logs directly out of the zip file if
> > that's desirable).
>
> Thanks for clarifying. This answered the question I was trying to write. :)
I think I took care of those thoughts above, but to reiterate:
* IMHO ./debian/.build/artefacts/ (or artifacts? :P) is a cool and
accessible place for all interested software
* perhaps, you could consider using
${DPKG_ARTEFACTS:-$PWD/debian/.build/artefacts} so that some builders
can override the directory if they find it more convenient for some
reason, but otherwise I'd rather stick to a stable, non-changable
path.
* I think eventual tarball/compression should be left as a matter for
the build driver (sbuild, pbuilder, …).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Standardized way of extracting additional build-time artefacts (was: Re: RFC: Standardizing source package artifacts build paths)
On Tue, Mar 10, 2020 at 09:07:57AM +, Simon McVittie wrote: > On Tue, 10 Mar 2020 at 07:19:59 +, Paul Wise wrote: > > On Tue, Mar 10, 2020 at 7:12 AM Niels Thykier wrote: > > > Standardized way of extracting additional build-time artefacts > > > > This reminds me of the BYHAND stuff, I forget how that works though. […] > Similarly, we probably don't want to publish the build products to users > if the build(-time tests) failed (because we can't be confident that any > products that were already produced are good), although we might well > want to make them available through a contributor-oriented interface to > help to debug the failures; but we do want to publish build and test logs > to contributors, regardless of success or failure. And this highlights one important aspect of such interface: such artifacts would be collected even after a build failure. That's not possible at all now. > The .buildinfo file is arguably already in the same category as build > and test logs. We currently capture it in the .changes file and upload > it to ftp-master, but it isn't reproducible, and ftp-master doesn't > republish it through our user-facing interface (the archive). Ideally, > failed builds would capture their .buildinfo as well as their log for > subsequent analysis, although I don't know whether they actually do. That's somewhat of a tough argument, that I'd try to keep separate (it has to do with the semantic meaning of a .buildinfo (i.e., it tries to attach a *built artifacts* to the way it was build, a .buildinfo without any hashes would be quite meaningless when tied to its original meaning. Also, we do want it to be published, but we are still waiting for the ftp-masters to tell us their distribution requirements...). -- 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
Re: Salsa "Emails on push" send only mails for tags
Fyi: https://salsa.debian.org/salsa/support/issues/195 On Mon, 24 Feb 2020, 4:05 pm Andreas Tille, wrote: > Hi, > > (hopefully) all repositories of the Debian Med team have set >Emails on push > trigger in the integration settings. It is configured for both > > > Triggers >Push > Event will be triggered by a push to the repository) >Tag push > Event will be triggered when a new tag is pushed to the repository > > > This worked since we moved to Salsa but since some weeks only > "Tag push" is triggering any mails. Did I missed something > that the behavious on push events had changed or is this a bug > on Salsa which I should report? > > Kind regards > > Andreas. > > -- > http://fam-tille.de > >
Re: Bug email to Maintainer, not Uploader?
On Sat, Feb 22, 2020 at 12:35:14PM -0600, Steven Robbins wrote: > 1. Subscribe to the Maintainer ML would produce an enormous amount of spam. > The maintainer is Debian-Science, which is listed in 790 packages, of which I > care about maybe 10. You could do that coupled with some mail filtering locally, checking for X-Debian-Package: foobar X-Debian-PR-Package: foobar but you'd still need to maintain that thing. > I would prefer, instead, to suggest a mechanism to email uploaders. Would > that be best suggested to the bts software or the pts software? the bts is really "dumb" in this regards. For sure it's not saving the content of the Uploader fields anywhere. IMHO, if anything, this would need to be a pts extension of sorts. Or you could script that: the pts also has a mail interface to handle package subscription: you can do something that automatically send the proper control mails whenever you start/stop co-maintaining a package. Honestly though, I don't think going and clicking "subscribe" in a "few dozens" package pages is too much. On that note: remember that you should also remember to subscribe to the salsa repositories to receive MR notifications... (this is a totally unsolved problem still). Fortunately Myon extended the DDPO to show pending MRs... -- 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
Re: Bug email to Maintainer, not Uploader?
On Sat, Feb 22, 2020 at 10:15:28AM -0600, Steven Robbins wrote:
> Most of my packages are team-maintained, so my email appears only
> as the Uploader, not the Maintainer. I am beginning to suspect this is the
> cause of missing emails. Is it?
Yes, nothing mails Uploaders.
> Is there a global method to inform bts to
> send me email even when only an uploader?
Either you subscribe to the ML that is used as Maintainer, or you
subscribed through the PTS.
--
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
Accepted scribus 1.5.5+dfsg-5 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 25 Jan 2020 15:58:46 +0100 Source: scribus Architecture: source Version: 1.5.5+dfsg-5 Distribution: unstable Urgency: low Maintainer: Mattia Rizzolo Changed-By: Mattia Rizzolo Changes: scribus (1.5.5+dfsg-5) unstable; urgency=low . * Upload to unstable. * d/control: Bump Standards-Version to 4.5.0, no changes needed. Checksums-Sha1: e2a6d52ec5f73e5df8189b74b39516aef0f2d363 2513 scribus_1.5.5+dfsg-5.dsc 28039c9776d9786033953778b110e828fabc989a 48400 scribus_1.5.5+dfsg-5.debian.tar.xz bea38deaf487a797694e43eedefe4b8f7b65d8ce 21241 scribus_1.5.5+dfsg-5_amd64.buildinfo Checksums-Sha256: 39f1b3ce2ea09cdcf06111bf2eeaa2935ed988558c6beeb6d8276b8fa0bd8f64 2513 scribus_1.5.5+dfsg-5.dsc 04dbb17a630740ddeeef0024233eb80b0a719c1c970ac692bb71e3e7d657372f 48400 scribus_1.5.5+dfsg-5.debian.tar.xz 899383e0efe71911c467eff2b2f5946b73de61940e6d7b90ba7b8c05b9c79dc9 21241 scribus_1.5.5+dfsg-5_amd64.buildinfo Files: 63b9bd0ed8221072eacb0edef8b286bc 2513 graphics optional scribus_1.5.5+dfsg-5.dsc 2579a7fce27f8f733acfbe51e4acaa4d 48400 graphics optional scribus_1.5.5+dfsg-5.debian.tar.xz 644d45af8d39e0d110e051c60f9c017f 21241 graphics optional scribus_1.5.5+dfsg-5_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl4sWfAACgkQCBa54Yx2 K60VORAAiqEaG9Z7FBFfSDdy3xvdrl0f0U/6ocWvOn0Gv9BVU0cbbj/ntXoVEAmI R9duaSygFgNhD5QijHc2xdJ2Qnsp3Gzs+sICT5pHh7XZBP06H+W/rdnpfSqc6x4w p7Q2Nai3nW45gs6aNda0cfm+W84SvcOtjbr+x4HZV90Nge5m/KPeiLu4SBA73d1W k7g39pQKcNr86T3NH+IHtgjseHn2KYBacCgx8mJnZOj10yAnXedNlEQ6HiO1Z8Ic 2SLmzuVnsY/huACzzEaSlZnXADP37lZ2zsNPIxZcoLteubBnp0I2J8qsdVZLnG9+ 3YIft3VwU8sbZA4LCvdIXgpqqR1vMBIWvOwRgfX5rVkhWVffAbs62PUTrBYcfnKq aGAv5Cyw8fFNwgz4D5xbpj2pMaXcI8D5HnNXQvFzzZlrBz0qGwgxX3tHAC2ksmux 4ADHZg3UQ7yzVA8oDrImg+oiZ/9VQ/WAl05tOTcV5GOuccR7okrz7srBqg1CABcx +33YM2bWnKxX/IdZ7tgMMP9lfLaXpEyXXfOC3suS6J4PhP+jAt4j/KKbWzBGV8Fx ueRAq4TPrDAf/UZ/gk31d+LJsDrep5XuS/2eK2YQO+z5/Bv2beP8Yov5jTRQGija 4Q1GcmpKjG3N7XeSHxtHfyYkQLGx2tL6slgIDjBr3UWpWeDIM8I= =W/Fh -END PGP SIGNATURE-
Accepted libreoffice-dictionaries 1:6.4.0~rc2-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 19 Jan 2020 10:27:15 +0100 Source: libreoffice-dictionaries Architecture: source Version: 1:6.4.0~rc2-1 Distribution: unstable Urgency: medium Maintainer: Debian LibreOffice Maintainers Changed-By: Mattia Rizzolo Closes: 943096 Changes: libreoffice-dictionaries (1:6.4.0~rc2-1) unstable; urgency=medium . [ Mattia Rizzolo ] * New upstream version 6.4.0~rc2. * Drop obsolete alternative dependency on python-uno. Closes: #943096 * Update copyright. . [ Rene Engelhard ] * Remove obsolete python3.patch. Checksums-Sha1: c23526a9a9750d47408caba21ba902881bc7646a 8019 libreoffice-dictionaries_6.4.0~rc2-1.dsc 5bac12965b2a89f828832c8332e39356226d9d55 45900320 libreoffice-dictionaries_6.4.0~rc2.orig.tar.xz 00081e7efa43c954f1af1b8f998f11d3ae3a347a 833 libreoffice-dictionaries_6.4.0~rc2.orig.tar.xz.asc 0c76a19d63202888fe55ee49ada2ce8dc41ee820 64500 libreoffice-dictionaries_6.4.0~rc2-1.debian.tar.xz 6189c7551df8dc8f24231f9c0d78f19cef0025bc 34011 libreoffice-dictionaries_6.4.0~rc2-1_amd64.buildinfo Checksums-Sha256: f64294b847a2f752b0d9a9deb0b9cc8c3e4ec6519d3f3ddad17a4bdb53c4f983 8019 libreoffice-dictionaries_6.4.0~rc2-1.dsc 7b0f62308438d28b82cb56518d83f1e34d98641517c3167a9f34783a605b3f8f 45900320 libreoffice-dictionaries_6.4.0~rc2.orig.tar.xz 2d0e1ae1dd8ae32e04ee93ad34b0dd36f76b887cd5cb419f464e34417336c631 833 libreoffice-dictionaries_6.4.0~rc2.orig.tar.xz.asc 6c0856e4a7afb707d2e0d09f7587d8b1fac1496f601105a0bd52965deababbec 64500 libreoffice-dictionaries_6.4.0~rc2-1.debian.tar.xz 999c62602d6e78c09d869d719cdd0bbc6b5a8d62f9073b40f174a1c1d508f9b0 34011 libreoffice-dictionaries_6.4.0~rc2-1_amd64.buildinfo Files: 0193c0955ee543022b0ca945f8cd2945 8019 text optional libreoffice-dictionaries_6.4.0~rc2-1.dsc d0680f7e4215917b6d402eaccb069f60 45900320 text optional libreoffice-dictionaries_6.4.0~rc2.orig.tar.xz 60faa865a04e0ea3b8859ce1a7d6a3b3 833 text optional libreoffice-dictionaries_6.4.0~rc2.orig.tar.xz.asc aca909409f57c3863d2b5385b2fbf460 64500 text optional libreoffice-dictionaries_6.4.0~rc2-1.debian.tar.xz 0560634d64da023cc1afeb3b31276cba 34011 text optional libreoffice-dictionaries_6.4.0~rc2-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl4kJmkACgkQCBa54Yx2 K61x/g//QrDBEa9Mkvv2/u6evF0ldYxUIMLqbBNEphQdYNTnDJNQfjfQR/Y826Jt VxNef7d6XmFybivmRmwVI/gaSNQUKbWRCHBUreH2g1f4ZKeQ+hHk9EXdB4ckvlJ5 AF5GuWcY3PvNO1vLZR8MiFmCy24CH3uC8AGFw9ZBSzqMU2Pg88yHHs59UnIZ2kXW GFqWf1YpuIpNV2kyYGFh8jD43wO+1rjTOrVlf1FmYxLJR/XM9xlWfQaPTEiLNlgu bUgwnb36LyZFebAXcdjMpOFUhEYbrEHZI5O1D3DMZ4aPLXnol647Vbc3GAXqywPg fQB1OX7h2TA2J4K0UfAtj4XzGA8R49xp3lbuMOkoGaHKR7quOIWhtmQRIoLNPy2K illq8ZqwTl4I/DxES0hPmE9C7Wf2rZv5m8SSFh4x5MaWrrEyVClEVVSk8xFsshkg 7U+h29/k+HtR+/XMCFAQuRIlmHSNNz9PzIgUcH3XgJNH6B7FOZTlPPs78DZG65Pc 8AkU85p1Hk1Sy0XV3X/DUZhMHEaVi8lEAd7zf/+k7Hv7SRymEpPi+p+feAYIDar+ 5MfRyUFIG2C2HEwi5sn0UpH+6a1ObXQLm5nxuxqMYeNtfBGLbuowrVJlmkkiQMWp KyKQZ50baP6RHMFwP3Hfv20Ozr92antIYT+MtFKZKonFUk5NIoM= =1JU2 -END PGP SIGNATURE-
Accepted s3fs-fuse 1.85-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 17 Jan 2020 19:32:06 +0100 Source: s3fs-fuse Architecture: source Version: 1.85-1 Distribution: unstable Urgency: medium Maintainer: Andrii Senkovych Changed-By: Mattia Rizzolo Closes: 923581 949032 Changes: s3fs-fuse (1.85-1) unstable; urgency=medium . [ Mattia Rizzolo ] * New upstream release 1.85. Closes: #949032; LP: #1828849 + Plug many memory leaks. LP: #1802912 * Add patch from upstream to fix cross-compiling. Closes: #923581 . [ Andrii Senkovych ] * d/gbp.conf: revert to default upstream tag name format. . [ Ondřej Nový ] * d/copyright: Change Format URL to correct one . [ Debian Janitor ] * Bump debhelper from old 11 to 12. * Set debhelper-compat version in Build-Depends. * Set upstream metadata fields: Repository, Repository-Browse. Checksums-Sha1: a5e800400b58815e5d9e53b45c4b78f17d974529 2013 s3fs-fuse_1.85-1.dsc 18f00ca33fb22d50a4366a53c3671df93aeb49f4 170209 s3fs-fuse_1.85.orig.tar.gz 1cac90911a9b27bcd9878ab719368ae785b4a130 3628 s3fs-fuse_1.85-1.debian.tar.xz ac3bb5571e1f13d12da97415ce6e06df0e450fdd 7314 s3fs-fuse_1.85-1_amd64.buildinfo Checksums-Sha256: 18b27fdf4e020669ae3787e9643f4cd8ce23adff116c4f283eba68146337 2013 s3fs-fuse_1.85-1.dsc c4b48c0aba6565b9531c251d42a6a475a7e845909a3017b61d9c945b15cc008f 170209 s3fs-fuse_1.85.orig.tar.gz 279c9492ffd9ad47746ffe66591a1cf17e860ddcc87203d18713ddb5cb11cf11 3628 s3fs-fuse_1.85-1.debian.tar.xz d81ba8caa030015e3887ab3ccf5ef5044f6701efef58f815f76a3748ff8e6889 7314 s3fs-fuse_1.85-1_amd64.buildinfo Files: 06250b6ec2d8fce9a321f7b850cfe491 2013 utils optional s3fs-fuse_1.85-1.dsc 0dd35ea749933468788f933c5d8b3e06 170209 utils optional s3fs-fuse_1.85.orig.tar.gz eb7e9990451276e13e637357b6b7789a 3628 utils optional s3fs-fuse_1.85-1.debian.tar.xz b7f9e524e7b983cfd41e66fea0d819b0 7314 utils optional s3fs-fuse_1.85-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl4h/l8ACgkQCBa54Yx2 K62ycg//Ya9+rXyxxHiAN/blpl4hCV+EyrOivfIe7QJHoXGFd5D/kQiuBWLS4SH2 ev5OnQAvVbAfXpsTgVN1VRzUfEGWX8A/nBKfXioxQAR7cF2XcwmnErC/hLOW6Ntd T1ApdB4p1HCurj3Ef+X0rrltDbIPsaG0aMXW8z8bPd+CgYXrZ+X4/0ajIEaal5G3 rSHhMN9WtqGSqdPMHgMiLKybMbqj4xlGwjP05aDJIZfyYpGmfi/lzPCcXBLgX5NZ 7t+CUL7UgUw4Ll7fZuCGWa29IM9S3cyKvxdhhXFV83L4zfw8GT5/LHIOee4ciM+R qc8XSjbXyKkFYG6y7leYvLZE/OeQP6Ye+evzCpYrN/yBNihLv0nTt6ye3owpi183 1r/pgvgFz9eNmA+LHQBkpttXDNpZetqTjGGkPNac4AqijTq69R0ZUozRpXERcKGN fM61kSU3ZERXEvvlk/VcGa+ZBlNUibzu/jnHuVPexnW+M6BPa9+LrOzhjxjlvqPX SgnOdKjs/KIjMsRJe5T7fNfSDxkQnc4XVOwPQAoexcKxayFIKlVhiz/aZRaYWQGg T8vTcGoiYwIQ2xE9ir+xSdS88PqIoApHCaV7s0DT0XU9n3Ui5lv7WL4rIg4hd9pr lX3ZtQz2U6s5CwhmHB7HU1IYcrvrL6mjQxYgncnxCiQe5BNF4ko= =o3sa -END PGP SIGNATURE-
Accepted scribus 1.5.5+dfsg-4 (source) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 15 Jan 2020 21:13:07 +0100 Source: scribus Architecture: source Version: 1.5.5+dfsg-4 Distribution: experimental Urgency: low Maintainer: Mattia Rizzolo Changed-By: Mattia Rizzolo Closes: 737983 875180 948430 Changes: scribus (1.5.5+dfsg-4) experimental; urgency=low . * Merge scribus-ng and its whole history into scribus, releasing as stable. + NEW MAJOR VERSION 1.5.5. - Completely rewritten text layout engine. Closes: #737983 - Move to Qt5. Closes: #875180; LP: #1757865 * Add a NEWS item regarding the version bump. * d/control: Drop hard-coded dependency on python. Closes: #948430 Checksums-Sha1: 55e46184801fa4f462953ddd82c6ffc2a09efa0d 2513 scribus_1.5.5+dfsg-4.dsc 0565201a70251410416be075b272439d984d86b2 23387352 scribus_1.5.5+dfsg.orig.tar.xz a738780b6b6c8823868f91de13c130ad025fee36 48292 scribus_1.5.5+dfsg-4.debian.tar.xz 344e3cc7f3058866b4955870c995f3d87af9fcd8 21155 scribus_1.5.5+dfsg-4_amd64.buildinfo Checksums-Sha256: 1d2f3c94091ec38a36310f9a52e94d7986d9dc6cdab3ae123f0a679573e0dedb 2513 scribus_1.5.5+dfsg-4.dsc 963ac8ac13d743bfb8dcdb92143ac5e03e2b71805ce295696a4f8d752398ef18 23387352 scribus_1.5.5+dfsg.orig.tar.xz 86213ec91d9d02c91799ae2418dd18b3fefa4f2485f5fdabebcde53b04aeb9a5 48292 scribus_1.5.5+dfsg-4.debian.tar.xz 46d192862f68d55709d6cae553f8bc9e7a94f7b5b635525bb2d1d276d8c73dfa 21155 scribus_1.5.5+dfsg-4_amd64.buildinfo Files: 2f98543b93aaafd6771b9057249f5cb8 2513 graphics optional scribus_1.5.5+dfsg-4.dsc 2df7f95f905d8d50c5c30020a2f81129 23387352 graphics optional scribus_1.5.5+dfsg.orig.tar.xz 5eb0e88db4701725c037d3511c6818e2 48292 graphics optional scribus_1.5.5+dfsg-4.debian.tar.xz 9c1a62adfb9e23234c299605317dad52 21155 graphics optional scribus_1.5.5+dfsg-4_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl4gec8ACgkQCBa54Yx2 K61Kmw/5Ac9VTDyIy+BP2VCCVJezzArpo8uYnKx1epNPGKSV7qms3Bf9AdMIneOI F9AY445iwlE++vLvo/kEKqasj2SGHVEXD0KWWI48FvGH+pTreaFYHbq8D0h0T1ON 7sv3G0X5ZAoIYk/cYz4RyXf2NoYbxg/ND8M6CmApFT0YrqNYINrIgft5NjjGiZZ6 CUvc5AJNPpXXYU3dG6+0vLrWMInQaBjVXF2Lc2Ac9z/nL5SeIEgifhsQvQbzThsB zt0xmfX1mu7CnYza8+je55hHtvVZcPfyDeaHdx8Ucxma5ruMdtttn6OdvHNKF8Hg Njbz3Zb5/ujEAAHJSyQBICxhJHH1RkNiv+K15kTcjOJF/Xt5n883DGk28zQNqVvJ 2VyNrkmLq255ouWsda3EfJkH6Ps98qX54uqlUWpBPcc/pNl7+rgMqPlKUFiy4jen iBLrAV40781oFrTGaYqBtnOsaw5RXJPZM0+wYEN6OOD+GGpscvXJrMmK6obKGmST gKUlMjZ5NKccsfuCBUU07D2Mp1v8VK8XjmG5046AO0RW9fZcd3F0XO9RYfy6o83N WFOkp9L4UyAUnAYPlAo/jyFwr+vBxSAmytGy92ETIcJya+lgV6uIhgLYSBgszY7s wM5ZrU7xTwCGvzcp0nTnwLSY2Fn+/P6DvXZRdEum1kQvWotrrrY= =2EfF -END PGP SIGNATURE-
Accepted dput-ng 1.29 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 13 Jan 2020 10:58:47 +0100 Source: dput-ng Architecture: source Version: 1.29 Distribution: unstable Urgency: medium Maintainer: dput-ng Maintainers Changed-By: Mattia Rizzolo Changes: dput-ng (1.29) unstable; urgency=medium . * Team upload . [ Joao Eriberto Mota Filho ] * Added an example of 'dcut cancel' command to the manpage. MR: !8 . [ Mattia Rizzolo ] * Use the mtime instead of the ctime to decide on the latest .changes file. * Properly error out if running without any argument but no .changes is found in the current directory. * Covert an internal script to Python3 as well. * Bump Standards-Version to 4.4.1, no changes needed. . [ Philippe Pepiot ] * Fix a TypeError in http upload exception handling. MR: !9 Checksums-Sha1: 938bdb6f8685ca8aeec2bd6eeafbf9216740fe1d 2192 dput-ng_1.29.dsc 00fe0094c90f35b9aca27005a6037ae1199d4e88 85588 dput-ng_1.29.tar.xz f184bdaa4a4f2d3196f26de2392ec930895c3822 8380 dput-ng_1.29_amd64.buildinfo Checksums-Sha256: 954c7ead40947787c70bdd3e4a815b69371f3652f2d4efc4746afdd69022d19e 2192 dput-ng_1.29.dsc 2966afbbf60a15700926c232e5c368f35294b141a95f3e8b180e081369408b4c 85588 dput-ng_1.29.tar.xz 023c0e50d84cfd2156fd479a5c80fd24fa86999ad85c2e6f003efc4f120f919c 8380 dput-ng_1.29_amd64.buildinfo Files: 20c4cbe35487b038dd9ebc51e51895a5 2192 devel optional dput-ng_1.29.dsc e687e311fd12671d1ca024197c246fb9 85588 devel optional dput-ng_1.29.tar.xz 473c3a0f25175ee8fa1c439eb640268d 8380 devel optional dput-ng_1.29_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl4cP7QACgkQCBa54Yx2 K627aRAAhsxMzfWqxR39D5HfZVX1mrF2uh65FJrK18qiwXiX7bzSOdo+oVMuRwxr mGSYkblrkmYeZWboFUEnKehYB8EfEh7mdFG4j+jzkMc3qB/51uW4cQp+zDbHHI8m JwzsbpvcqrwgZIGNxat3BnFFgoMwlHCMC4+90gVpdnNP9LIQn+4QeeajVmwmK1kX g7oZ6z3GUv+DGtlX5jjqyvtP4pThYnsO6W46qsmqlGwy6YBeylx0jRpgvzguLLSb PTde37HpG1p6q7lHwb7MBbX4blok/Rlg0qphWHCNuI/YQO8+jxL363DSiTnsEMUU sGK1nFSeVWILAsL2oPyxEdJqmIFrkrEVWfQdSP7kd6W/BgplzsTPNWap5U7o5mDA lB2kCE6zEjI6Hl6yBMEq6hzDKUfyqS+KuODGGdkXN1+6+NpOzoWDMhQyZ4rAVDK8 SICyNdxz07x7C30EjGP/f6xJrsjGsE6lRiK9IewDbh5W/xFA1Ozys/0Hnv3OTSbQ iI5bhhUIMYQwo4FPLAph1GLlGRhfr8+mBU2VzhibcDnWg+EKXsWniuN+F+IqH53f I5MqrO+jVV8OQpYI2BmrIXOOfzp3/LH72z9ixMH01e1L5YijMFQCjQ/gnYdUUTf9 c6fECmG1lnqyYANv0hgtZAthdjOzBBzC25xGxP5SWFwc6AplH8Y= =IgAr -END PGP SIGNATURE-
Accepted sinntp 1.6-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 12 Jan 2020 13:45:54 +0100 Source: sinntp Architecture: source Version: 1.6-1 Distribution: unstable Urgency: medium Maintainer: Python Applications Packaging Team Changed-By: Mattia Rizzolo Changes: sinntp (1.6-1) unstable; urgency=medium . * Team upload. . [ Jakub Wilk ] * Use canonical URIs for Vcs-* fields. . [ Ondřej Nový ] * d/copyright: Use https protocol in Format field. * d/rules: Remove trailing whitespaces. . [ Mattia Rizzolo ] * d/clean: drop now unneeded rules, dh_clean already does that by itself. * Bump debhelper compat level to 12, and use debhelper-compat instead of the debian/compat file * Drop long obsolete debian/pyversions file. * d/tests/control: Drop unknown Features: no-build-needed. * d/control: + Drop Piotr Lewandowski from uploaders at his request to mia@. + Bump Standards-Version to 4.4.1: - Set Rules-Requires-Root: no. Checksums-Sha1: 9d4971d55723389e9917381f85af091af392dd55 1913 sinntp_1.6-1.dsc b856e6f69836aa2e46fb024a78a3c69a72d29127 2916 sinntp_1.6-1.debian.tar.xz da23564b840f183505a43bcdc14a8c520a138fff 5998 sinntp_1.6-1_amd64.buildinfo Checksums-Sha256: 80a53d43ccf0a6adc2102486912e760a9236758e6350393d6863b67e24910209 1913 sinntp_1.6-1.dsc 808c1bc9dcdd17d286cc2ef0962ef179100684144d8859208f6590677ae48a39 2916 sinntp_1.6-1.debian.tar.xz 53ba2ca4ef52c766b21e39a497703d2aa62b191ba836990dd43fd56585acc21d 5998 sinntp_1.6-1_amd64.buildinfo Files: 79ffeb65d470cc809613371bc099e634 1913 news optional sinntp_1.6-1.dsc 14c5b649eac44a104db257e6b1566cb5 2916 news optional sinntp_1.6-1.debian.tar.xz c2fa33cf4c73364f3b8277914421b237 5998 news optional sinntp_1.6-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl4bFewACgkQCBa54Yx2 K61Sew/+Mq++KmpVs0OKmJhCD9Y2JTHn9WLjRqGWIX5e+npqI8O6IiHqhu6CeIjM 0NZD6pXe1YVCLIiC33LzAcwSnV/IZ/81/iZrWtiA74hTDfsu2aWBM79tX9ncHtKN dJN8bH3sfSvI3w2d71PnKtrD9cQbpbnuvitHR/gjEq1b3n1ooOFFUAxQxmOzZF0t 08TkXdDcaujxN/agD/DLXZihoNWjHEZZe08N+kCMilyWXrZkTEFF4LWACgAIcm3b kIOnoagYbctt2XrEs3AyyDoru/WoVToyU6I96l4a1p1pv7dn73DGercD6L36EaZH KPSmO4WAbhN7Q22RNldm8aQ7y8nN5XoCxYweyz5BQUGFkXG5F1KXZH/ITKiF/gUT /6uQkfPHZXvbjNRdEhz7igCjeJDV452qaoI6wyTwn/fOQwaNlmoKO4/djvuEG+2p xWKqTQxYtQAds6kdncb+ZeejrRBkZuKhrWsxwHFO5dx7u+XndyZnrtXGw7SOw6kE kUORfSsAf8DWTJVWuCBBW5ljLnN37AJCMnIOtuhDOpk+eMNzNMkEvD/WiuUVanSy Fo+odK29QNMpGsCok6Of3wh/ebA6zoTSVT6XkfE5JD3oJW1q4YDpwWqZ8shbMwtM Yt78ByvQm14lsSkP9ljrWKRdGLpj8tKbco4qkk/ZFm+kDWFmjyQ= =+OrE -END PGP SIGNATURE-
Accepted limnoria 2020.01.09-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 11 Jan 2020 15:09:04 +0100 Source: limnoria Architecture: source Version: 2020.01.09-2 Distribution: unstable Urgency: medium Maintainer: Mattia Rizzolo Changed-By: Mattia Rizzolo Changes: limnoria (2020.01.09-2) unstable; urgency=medium . * d/copyright: add missing attribution for a new plugin. * Drop --disable-multiprocessing from the autopkgtest command as well, not needed anymore and causing a test failure now. Checksums-Sha1: cb4dc57154e99d64577b9ee596a2600ba8811b46 2377 limnoria_2020.01.09-2.dsc cc0ffb844c40affa3f022cc64c558c8438cde19b 9496 limnoria_2020.01.09-2.debian.tar.xz 6a0ecb4b30adc3a519571aaf5b4cbdc40ad3e4ce 6580 limnoria_2020.01.09-2_amd64.buildinfo Checksums-Sha256: ba0e3b78d83dda71189b85ebf052968d1401eef2f0d16b0b19b9dfeb57c51048 2377 limnoria_2020.01.09-2.dsc 0d3b1385d8672c0c38e2b77a71d569de32e9398f97f092166747de811927afa2 9496 limnoria_2020.01.09-2.debian.tar.xz 6f7f85e37f3dfc5c21dc811776fcd6c017062fddb2f6d3783aa37dacfd4004a5 6580 limnoria_2020.01.09-2_amd64.buildinfo Files: 85301fb30fc9c0e073d6d08523996ea7 2377 net optional limnoria_2020.01.09-2.dsc 5bf2b8cb75e52add14ce166a3f23dc6e 9496 net optional limnoria_2020.01.09-2.debian.tar.xz a1481fa5a8f8ede6a9f8a2556b74b4bf 6580 net optional limnoria_2020.01.09-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl4Z2fUACgkQCBa54Yx2 K61nqhAAtVtdBuTrM2WJvAO2qL0yIabJR3dMpro4nGL0MPF4VTW6eG7vHJNddFBu 0Hobq7CMrCj92rmCC+a9A70b/b1iW31pArCUdm5ojIYgNVwYatVhDKWvcqsBKYwQ dGBcvd8O1n++lyiuPfcCIQ1sRXrU9ce99LZa55ozOmrBu6M4jrAN3XFrlV7OZfPM FYuO/bkFuVFeKSs98StFGeJn8diFfliyqjS0dtZFdMQRw5IVapcOaf8F68e7dHtJ iLiDo2yvUByCGADicHIfAmfwg7qcm3YUUpuieELczKn3aoCg2cvp5vyJtjmGYCTO e/+GywEREQ97RrH4wiqkzY4VYEDELx0yC+l6jSV6EjyRBwILdUArAFciaaZcL0eL XMPRkxzvYYsjfrSmk/U8I3V8H9ORILn68U0ebsYfQEUINPlKjaOj4RQuU2DAWE+i gxH8/PxTRGAe8byr0FF/DoUnszVM4mv5jyYp6Bu7wW5/b4eM7XibCSEYM3bxiWzS wBSqT0eKq/UAZe3D4sSBRtyFR/5WPD+5hAbVtJmN83g7U/gOqdEqkZ2nwZMs+ueR H1b6KYpkYgpOieAOvxXHfr1hOlHCqGvPo/hSy2kaVjJsUgS8LHgpg9pMnCoNRwTm CuB4OtMdwB37iSgfs4lh3f1COT9CiWuo7teUr1F/2hOabj2TgIU= =jWTF -END PGP SIGNATURE-
Accepted zfs-fuse 0.7.0-20 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 04 Jan 2020 16:38:32 +0100 Source: zfs-fuse Architecture: source Version: 0.7.0-20 Distribution: unstable Urgency: medium Maintainer: Debian QA Group Changed-By: Mattia Rizzolo Closes: 947588 Changes: zfs-fuse (0.7.0-20) unstable; urgency=medium . * QA upload. * Add patch from Phil Wyett to fix build with Python3 scons. Closes: #947588 Checksums-Sha1: 23c2138f91eb32a0de1d9685461e119aea68aa85 2048 zfs-fuse_0.7.0-20.dsc 459556f66bc59b34310fc8da600668f44a5de1ed 26936 zfs-fuse_0.7.0-20.debian.tar.xz fc465806373a83fd2f553edc9edde12dd83cc12a 6493 zfs-fuse_0.7.0-20_amd64.buildinfo Checksums-Sha256: c351dfb7d6097b86940f58785f1e513aee5940194fc98c35b66f9b420ec22f0d 2048 zfs-fuse_0.7.0-20.dsc f70a6d3af6504c22e9b5083ef9bdb5a2b551a75154116533f7153b300aa9c3e8 26936 zfs-fuse_0.7.0-20.debian.tar.xz 6d190ff95a874f0a73c538e252ac990e8c5b6bc1f5c27c077e7231c7ebb652bb 6493 zfs-fuse_0.7.0-20_amd64.buildinfo Files: 5ed3b5e66bd2e9e7d7161821b3d044be 2048 otherosfs optional zfs-fuse_0.7.0-20.dsc 35bc492e87367ced7b2331db85f901c2 26936 otherosfs optional zfs-fuse_0.7.0-20.debian.tar.xz ab0ba402caa2bb0b3fcd52cfe6afa5e3 6493 otherosfs optional zfs-fuse_0.7.0-20_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl4Qsm8ACgkQCBa54Yx2 K61UQg//V99gLv/giPhvxYsR8K1ApXDh7kEh6N8KAwoAflGZwM+PX6mQv8Lp/OEL Z29TbVazelxAsRaTOefRXWAE3XL2jyW7wKNJCH1Pbt46SIpISRLAAwh+RjMSvNjc Jyt4X0iuHfwV9QqP8pSt0PQjfalqJbZ5XuHTCpLnvOih/F6QqyU/JzehuYaGGWio sb6jTXP773phw4U+gIsTGlND5T6spuIJJoL39yPwbkrxLhMsuOtHbNb3oIkgCvpm RLiDWSEJLAHVWoXlBGRhOWBW6C8ClISfi0YRsLxXZ7+wUvsOg5eK3OJGT5XQiQN1 UuJcW8uFxUDUQMHmyiOKQV7z/yWKfDWMRf3SsBhvWIQeAG+yaLODf+VHPN8+fPoj ZOFTsx7/VLtWEW5/MN0az7+Euun0ZWmebxgo+qrzgLX0Ex0K2HHNdrXYKk1/rQZ3 flBdTKzx8Kj67NGUnzhuIOj9UgBoeAUm1t2HZl14naxLwbsbDvWuct9rEcoyDZuy 4p2O82zBFi8a9H7viw7DZKZJhrwZJtibzuqaAvb0xnrfsQJ+ZsOP3y2P9TipQRnT Z39ADK9Ot3w9ouhMNiuAeGySJemNFQN7EhizWyFWfQ7tFDvsWtrXf8GrioBn68cS 3YchZkb4RE9kFDz3dbrKUO/AGPkRfMCmRI7O+84tztUs68JsQwI= =PSbY -END PGP SIGNATURE-
Accepted hexchat 2.14.3-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 02 Jan 2020 09:46:24 +0100 Source: hexchat Architecture: source Version: 2.14.3-2 Distribution: unstable Urgency: medium Maintainer: Mattia Rizzolo Changed-By: Mattia Rizzolo Changes: hexchat (2.14.3-2) unstable; urgency=medium . [ Gianfranco Costamagna ] * Refresh the Ubuntu servlist patch. . [ Mattia Rizzolo ] * Import patch from upstream (from James Clarke) to properly prioritize MODE commands, that were delaying PINGs in some cases. . [ Debian Janitor ] * Set upstream metadata fields: Bug-Database, Repository, Repository-Browse. Checksums-Sha1: bca3170986f2d220996f63c5a004fe3667c1c6f9 2600 hexchat_2.14.3-2.dsc 27d74dfb424625b4e3614ce96e4b7c6030aeb7bd 34924 hexchat_2.14.3-2.debian.tar.xz 9059db5fa7767ebde786f5d3a144cc77cb7057ac 14616 hexchat_2.14.3-2_amd64.buildinfo Checksums-Sha256: 72610dc8826a04ff4f0bc718994b3dedc8376afcfe10017e6c04ef00db54 2600 hexchat_2.14.3-2.dsc 389d663e80d2f42a5e188f294a7f434c9cb88b17dbc003a6b2a024c69b3b371d 34924 hexchat_2.14.3-2.debian.tar.xz 8b0950d11f4946a154d71944b75883941bd12007760a268c890768d1ed42da1b 14616 hexchat_2.14.3-2_amd64.buildinfo Files: 587d5e5971b97d898ad41b2357140b21 2600 net optional hexchat_2.14.3-2.dsc a7097b945547b1e256e3da1343438456 34924 net optional hexchat_2.14.3-2.debian.tar.xz bda3e7c41cae2bb1e27b69964b38b4e9 14616 net optional hexchat_2.14.3-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl4NsuYACgkQCBa54Yx2 K60KNA//TSjt+QSD8eI9fOzcx2wHbxEJ4KQOkU9uwjEWPBDW+uBEtHtz18qmp55t r4BXuh/6HKYHa5MqbCCXVTKBAxJkrRVuyjpF6glKp/OrZPmRKa4Fzt29+U0bXglB 3NcFiHi7i0a2Q5PktlbBz4TXc3DEboMW9VdfrtRtCSsWeVhWHqSn6pAU27QBLH6m M1Xjqh8D7Gao2DGqeir6QUvT00j2rfBb0Is8dL4j5T0M03EE/8C8ibpq9lbLe1bL OQJ/XiQqilPjqflcE+fBwGJtsvfeJqyJ85HDhjqwR/g3U15PhUQOABsQw+q8Mcx7 rkOEmTCCLtLTnq7CkBg8jFZviVIqK9/ISyGd8Id/Y/RwfBo09FBULaeVjqlWD2Mx xnH+mu5QLvt0r/+ot4tbmq13+/+u4kRWLYnguspy5dy2X/021nfnwWC9jwAwmLLR kZNZh2Ymmw/cSJMkJC2bgAcrFXaJhzGQZqmP+6qspdIQ6K3H+c8gDhGSwciIId0B 4/i74SMt+qsHLubPEhus2qnXhj99rfkdWfvC4hWu2utIfzCuZ8eWWKcFnYCUy8f7 MBSebY/iIMSDUgYvUuhXQMPf2RDZi5la1OcXN8oTJ44AGPhOl0waSrD4313uP4mL Z1/l9PCFFPceKIIOKf3tK82yTyw+s1e7KsOZ1F4C7PU9pdi0vzU= =pEHs -END PGP SIGNATURE-
Re: Appstream + Gnome
On Wed, Jan 01, 2020 at 01:17:34PM +0100, Jeff wrote:
> One of my packages is an application and ships a .desktop file and
> appstream xml. The tracker.debian.org page for the package complained
> that the ID for package didn't follow the {tld}.{vendor}.{product}
> scheme[1], so I modified so that it did.
>
> Now I have a report from a Gnome 3 user that since the above change, it
> is no longer possible to add the application as a "favorite".
>
> It seems that adding an application is only possible in Gnome 3 if the
> ID is exactly the same as the executable name.
>
> Given there seem to be plenty of gnome-* applications that use the
> {tld}.{vendor}.{product} scheme, I seem to be missing something.
I was likewise hit by a similar issue. It seems to be a Wayland bug,
rather than a Gnome bug though.
Also, none of the Gnome application are affected due to their heavy use
of Glib stuff that do enough magic to keep everythign working.
See https://bugs.debian.org/942600
https://gitlab.com/inkscape/inkscape/issues/539
If anybody could also help with my bug above, that would be awesome.
--
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
Accepted hexchat 2.14.3-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 31 Dec 2019 15:24:45 +0100 Source: hexchat Architecture: source Version: 2.14.3-1 Distribution: unstable Urgency: medium Maintainer: Mattia Rizzolo Changed-By: Mattia Rizzolo Changes: hexchat (2.14.3-1) unstable; urgency=medium . * New upstream version 2.14.3. + Drop patches applied upstream. * d/control: + Bump build-dependency on meson to >= 0.40. + Bump Standards-Version to 4.4.1, no changes needed. * Update the boundled upstream docs. Checksums-Sha1: b6f54996e6b5d7e2143be985cee12943f3ecbc79 2600 hexchat_2.14.3-1.dsc a219796d70023b675e5ea24af9f22beb9e855abb 1292072 hexchat_2.14.3.orig.tar.xz 033e231bcf8469f9e29d663854472acdc7798fb3 833 hexchat_2.14.3.orig.tar.xz.asc 4132d44ad26a8865cbf7dfb9d02c41fc0a0996f1 33992 hexchat_2.14.3-1.debian.tar.xz d4167b5aa19ff363f683a2bc72d10991c8cc6bb0 14655 hexchat_2.14.3-1_amd64.buildinfo Checksums-Sha256: 170cc57dc47db3a10c4904a685c24b0025b0f42e61a1520486efaea87f4c4e73 2600 hexchat_2.14.3-1.dsc 901a9d13db5a4da69b827f6093306bbd16863dc49016f7668bd3e4506512e882 1292072 hexchat_2.14.3.orig.tar.xz 0cda3f6f41dec8c5f326b3f75aa293683d08053e425742c640d1d6d29af7b6b3 833 hexchat_2.14.3.orig.tar.xz.asc 66ede4d0338899792bf1c1cf1c89c822b77d2fbfa4c5026c1f11740088298b53 33992 hexchat_2.14.3-1.debian.tar.xz 43d7fecd7fcbc785afdfec628583d47968d6e47ee403ebab363a873ccb34cbee 14655 hexchat_2.14.3-1_amd64.buildinfo Files: 801fbcea51e7429f0d58d1ed555f0498 2600 net optional hexchat_2.14.3-1.dsc 9f04c48f011b646b91d03c5776fce776 1292072 net optional hexchat_2.14.3.orig.tar.xz ec0455f8670406384d9805a83371b912 833 net optional hexchat_2.14.3.orig.tar.xz.asc 4c50aa62894d2675245aa16b20051a95 33992 net optional hexchat_2.14.3-1.debian.tar.xz 0313f657329648090d1cd8eb4ee50ea1 14655 net optional hexchat_2.14.3-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl4LWrEACgkQCBa54Yx2 K60jjw//TXYGKADSKXGMeJNdsstVZWWJ12t/ZOfkqAGQnEvfEP4qrh5Ha12vHZpS kH+10+k1voqMEBS1WgnoVhxAiG/aLZnTzGVNzpLeWvAdAQxc1HW7QicewI09Pp3n sfzAu2ACZmiXkrO/iNDUQFGB8d/x19BpDeB8OIdWDk8pyhW5aePfiAerD2NQ2ldJ TLab5mfwu6p1PAu1G3lnnwXIGBzUectkVEPCmNbAaGaJlevuifbmbZGDnBhxYXw2 hMmvGmLJcQ+tldYndpqpEHlvvj5wt3Ew9IVTJt1YwVBpgR2uXDwmv9eD6uMXnqC6 BAIjQiLhLYasjTfwde9LI2gu7Uwst+Z73LQd+iJpcgDxFhT7w/LTPwgz2PGtO2mV ltOPZr2q2U0cLG+HD2JXLU0XeSlwlHwI+c+TS4Ehfuv8R2h0iZvYXJeBfha6XTeI VyUdrl8gc5WaxNDz++dCi5JMZeQd8tCTTTh0Ab7bjEOrdIkX8mTc0wCBOoySaq6u skU+211Dx9x6rKZ8y+KxCX/hCBBSDBypCzercljiiP3svuGXOYSe36uPUspjf4ri NW1HxgoUyXiRe9OBtz0JZ3qRg8DBMmOfTPrDxFf74Qs/TBG7Ba7BZA5z3ApBtLln 72r2mrcC1rd1e68rwNG6Bc3v0BJWv/SDZeFG5jZjGg1zMVTIOUE= =0Spr -END PGP SIGNATURE-
Re: https://tracker.debian.org/pkg/dballe
On Mon, Dec 30, 2019 at 11:29:52AM +0100, Kurt Roeckx wrote:
> Note that the name of the .changes file by the maintainer and the
> buildd will be the same, and dak will reject it if that .changes
> file already exists.
That's true only in case of policy queues nowadays.
--
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
Accepted scribus-ng 1.5.5+dfsg-3 (source) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 28 Dec 2019 21:04:57 +0100 Source: scribus-ng Architecture: source Version: 1.5.5+dfsg-3 Distribution: experimental Urgency: medium Maintainer: Mattia Rizzolo Changed-By: Mattia Rizzolo Changes: scribus-ng (1.5.5+dfsg-3) experimental; urgency=medium . * d/control: + Build-Depend on python2-dev instead of python-all, since what we are interested in are the header files. Checksums-Sha1: 367943ab086e538db5d344924af6dfb13a196a85 2552 scribus-ng_1.5.5+dfsg-3.dsc 081ff93099b0b165d1ed727af9ddb497684b05f8 40760 scribus-ng_1.5.5+dfsg-3.debian.tar.xz d1f1e48beb8be2a8d92efd5b4afa767380a2ab8d 20861 scribus-ng_1.5.5+dfsg-3_amd64.buildinfo Checksums-Sha256: 969155da206cc20a9d884b77210574bc51126ee46e911f7b34045fe6c7447119 2552 scribus-ng_1.5.5+dfsg-3.dsc caea8de03a32cf4c62814ed16efa7d608da736b5c8abaaf97d97a006218a4450 40760 scribus-ng_1.5.5+dfsg-3.debian.tar.xz 9062013ad1a2e47b1f9c071e1c2a052ae5c7e2254800dfa1c34b85630d9369a6 20861 scribus-ng_1.5.5+dfsg-3_amd64.buildinfo Files: f81721bdc4d58fa669ac08e95b29627b 2552 graphics optional scribus-ng_1.5.5+dfsg-3.dsc 99ca5eb2183d7b63ab00b0e88c4aab4e 40760 graphics optional scribus-ng_1.5.5+dfsg-3.debian.tar.xz 00b64e2fe48efd396f2af37413c3ba81 20861 graphics optional scribus-ng_1.5.5+dfsg-3_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl4HvU4ACgkQCBa54Yx2 K63dGg/+NYziZu/T6wvol0tySE4TKuFa1xOq7vHft6T3XtNo3JSUGQ3iA+Q5XqG4 GVHVDeywIRZp8YL0Yxcbrt3+f/9FIS5IXnCiTwbzSjCCKQlmu9W36Zz6LoDmdQJj 2UKSL0LI861xY44vr29U3YHkGXbDAga+n5IwJv0M8vK+iJW+kNJEcZwu+omsm4PG 5ciieRMz/68j1VZvOfLo0VPBkVnMKDLwz6vy4ad2L5offY6CZcErIEYlAaCPUV8y 1uXBniDchqfL2SZFdSRXseXLKAZxDF9sQbB4hWhjkF0oNrAGBm3drxlNg4xA7wtT 2kHLz9a+t3doy8XEGy/UMHxE5e79rRLwjA3dmWcZDAtsC+QXEGSlCt8iQpVP8i2p WSkwkO1q3Q7yW4HxdXSyaE1kxfaDZIzLQCP2c5OYcRpO4eRSi/F56TYWCXjvdPMs 1D6byORuXfBxqs2/ZqpQW2Y1V3cnyqZ6QHJ/6XQnmP3dqr/Oi6qY+hzyim1O6ItF acgzA4xjrMZQSETf1P2QaLu0LZIqb84Sv+nLixW2z/XZiduvUpkhGFSgwCcZXTEi GaZZbyTxAqdALgUgGjET0pO3DZhmKSx5it1FG1NXc5wTHHPYf3ozXQ2MfZ6xKdX8 qzibooxg1EE3yiCcHBOGvyNPlLuKp+W+zQfyWYvA09/VhdqIbYA= =exyZ -END PGP SIGNATURE-
Re: requirements and regulations concerning upgrade checks/statistics callback on program start
On Thu, Dec 26, 2019 at 11:26:26AM +0100, Tomas Pospisek wrote: > > are there any requirements or restriction what a program packaged in > > Debian is allowed to do when starting up? Calibre is normally doing the > > following checks: > > - check for updates of itself > > - check for updates of plugins > > - send UID, OS, program version, and the icon theme selected in the > > program to the statistic site [1] > > > > Which of the above actions are acceptable for Debian/main? > > > > [1] https://calibre-ebook.com/dynamic/calibre-usage > > The last point seems inacceptable to me if the user hasn't explicitly > consented to it. Checking for updates might be annoying but is "OK" to me. Considering this is debian, I'd probably say that none of those are acceptable without a proper consent for the user. Opt-in flags in the preference windows about "automatically checks for (plugins|program) updates at startup" would do it…. Silently sending out details like UID, OS, etc is a no-go in my mind though. See also the history of chromium that had to patch away similar features. -- 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
Accepted limnoria 2019.12.15-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 25 Dec 2019 22:47:52 +0100 Source: limnoria Architecture: source Version: 2019.12.15-1 Distribution: unstable Urgency: medium Maintainer: Mattia Rizzolo Changed-By: Mattia Rizzolo Closes: 945569 Changes: limnoria (2019.12.15-1) unstable; urgency=medium . * New upstream version 2019.12.15. + Fix SyntaxWarning. Closes: #945569 Checksums-Sha1: 22d5850daf12f1ee2fe80ff0fad96079220f7db6 2377 limnoria_2019.12.15-1.dsc aaa699b3bf24f1a110eb86a40076e6f4ba7ed49d 900064 limnoria_2019.12.15.orig.tar.gz c128b5782965eb0fcd7de911877506925e90cf5c 833 limnoria_2019.12.15.orig.tar.gz.asc 36d8472be5fab37ba45feb09a239d276ad15b35b 9300 limnoria_2019.12.15-1.debian.tar.xz ae44a6741ffb434b0fc3b0fd27429aec115fefee 6458 limnoria_2019.12.15-1_amd64.buildinfo Checksums-Sha256: 7eff24a77ae36d1a27776c6997492887ea23946fe30488b6dd088b4cccbd4bea 2377 limnoria_2019.12.15-1.dsc c6d86480c400317214d3b97b722621920f7298da1baf88475d3d34f3873283bd 900064 limnoria_2019.12.15.orig.tar.gz 7387fad57c73d578f4a7de3d56e2065da8a044300e2c93e783b530bd75f0c32f 833 limnoria_2019.12.15.orig.tar.gz.asc c0470e90c1ce101418ceb1f604168a8a218312d4029ecb80848d4e7230c1539a 9300 limnoria_2019.12.15-1.debian.tar.xz 0ba910694d3547271345e55ae6be383b199bbcbaec604a6362969366a299d953 6458 limnoria_2019.12.15-1_amd64.buildinfo Files: a8b5c2f5114749ce84e47af2e6b250c5 2377 net optional limnoria_2019.12.15-1.dsc 8ba38c54fd6e71a5911f1fa2ebb89f2d 900064 net optional limnoria_2019.12.15.orig.tar.gz 4b17c165be48b4b2d0ffad0b432e957a 833 net optional limnoria_2019.12.15.orig.tar.gz.asc f97aa8d21794b519262e613d8e7a1dda 9300 net optional limnoria_2019.12.15-1.debian.tar.xz e3f1f323bc534f81ecccb830bcb8b902 6458 net optional limnoria_2019.12.15-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl4D22oACgkQCBa54Yx2 K61rmhAAle3rPObizbYvqOc9+YmF1jpCG71pmCuMBtExT1hsY3Jxn0EGgBz+fXWv MezYwepH3dgmPDSi39hLncH5tHx8L+LVbC6gQmyyLAEK0N0syS/LN/dAzytSBNu5 KRwIr0wEolz+C8mpP3uzX/8Gwpa/yieXiZMOm9VJYepcr0NGpVPjG9WpYE0qLrJs myR3cGs9e+vus9j3R8+Uc2Pqj+Y5EKdH/JLcKOs/s0/WO+I1SHsW2xvXW6FqM22R g7+ywubL7RUAbtd3aHZGtzuv7QymaB9rIFaZWcvhcQsgNnynned12l6GRF/s2hgb NhUZNV2+OW6p4cmOUsHCYMJdbmTxGRFhcw3wYzaD+5j4XZy5/ZDIH2GbzlNG0cc6 STDREZdav3g08grfLoOPo0iWYkVolqG/BND+Jj8UdmaYv8zM0AXQgE+pTKc4eGya H1GjelzJ2NKnus3cRqL7I98kdswIS+weyYYpWTk2U6Y/2lh7tREdsUEex6Z+dvEi qoJ2QAan7EpuJ1EdssKnSAGHtN6gTdrjhFWp7aYJcSQ0keRMzLSBTRu8bCwwC/16 9Ha1QK6nBjdo30tFZQGOF2UjfCoH4YUzG2R0KqByc+vLXpQ5f7UizcE1kD9IpMIC /OswVNg0MXpkpco76g1cTV4MzQArQUQ3wJ8sbu/q9ecv5OS3jnM= =VyfQ -END PGP SIGNATURE-
Re: epoch bump request for protracker
On Mon, Dec 23, 2019 at 09:41:57AM +0100, Andreas Henriksson wrote:
> Upstream renaming is a very rare (and AFAIK *only*) chance for you to
> actually get rid of epochs cleanly! I'd very much suggest you take this
> chance!
>
> Basically what you do is rename everything and use the new version
> number, then you add transitional packages and for those you override
> version number generation in debian/rules and add an epoch *only* to the
> transitional packages.
I agree, please take the occasion of this rename and get rid of the
epoch!
However I have to be in disaccord with this example:
> override_dh_gencontrol:
> dh_gencontrol -pmy-transitional-package -- -v1:$(DEB_VERSION)
> dh_gencontrol --remaining-packages
I'd avoid using -v1:$(DEB_VERSION) and instead do something like
-v2.b37+really$(DEB_VERSION), so just to aovid an epoch also there. You
may also build those transitional packages from the old source, and then
ask for RM once the +really version went into a stable release.
--
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
Accepted sigil 1.0.0+dfsg-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 21 Dec 2019 15:50:17 +0100 Source: sigil Architecture: source Version: 1.0.0+dfsg-1 Distribution: unstable Urgency: medium Maintainer: Mattia Rizzolo Changed-By: Mattia Rizzolo Closes: 947056 Changes: sigil (1.0.0+dfsg-1) unstable; urgency=medium . * New upstream version 1.0.0+dfsg. Closes: #947056 https://github.com/Sigil-Ebook/Sigil/releases/tag/1.0.0 * Upload to unstable. Checksums-Sha1: e0454f9cf5d7a90f75d9b023a2e60b50d2f29aa6 2217 sigil_1.0.0+dfsg-1.dsc ffb3640657b36baea89f105ee0fdf2f13b58261b 13238304 sigil_1.0.0+dfsg.orig.tar.xz ade431f1a07dead7911a0d2aaecee5dc8a3a 15236 sigil_1.0.0+dfsg-1.debian.tar.xz 570efddb72932ac3f3f7c5ead52bb75b1e2eb41a 14670 sigil_1.0.0+dfsg-1_amd64.buildinfo Checksums-Sha256: 6a5f3780d98ac29e51d29ccfce6157a8185f078d247b29be65872af9be37154b 2217 sigil_1.0.0+dfsg-1.dsc c534d8af90a36b896a51b69a33350a103d5a50ec29768750cdec1afd35f7a1b0 13238304 sigil_1.0.0+dfsg.orig.tar.xz 31c9a870e2a8c4ca4353c946433476143066bd62b59b3373e1e3d5e28f2e45aa 15236 sigil_1.0.0+dfsg-1.debian.tar.xz 0993e103f403743e6e5eaa5957b7c58fde458f3e0c37a425c397e45f323ce148 14670 sigil_1.0.0+dfsg-1_amd64.buildinfo Files: 5a5767d0ce8599cdf8fcada861d7d335 2217 editors optional sigil_1.0.0+dfsg-1.dsc 226e8b3f24a1509bf2ac7bcca42c6c23 13238304 editors optional sigil_1.0.0+dfsg.orig.tar.xz 56c8c27e0208906d3039165f92f8a317 15236 editors optional sigil_1.0.0+dfsg-1.debian.tar.xz 0a6debf18821b63baa3ae96e3fa0ad7e 14670 editors optional sigil_1.0.0+dfsg-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl3/jOAACgkQCBa54Yx2 K61agBAAt1IXRYMLzrcowMC3rhtX+SG0nUlAN6B0oNmBV+lFOsbuNvBaldwTzXyt zF7hw6dHia1j0ZvTxM509elf9p0iYnGCZhh4IKejH14c/Bt95RL/qHwD5+N0UqwL Q3ka2SgQ2CaAjRIdx+4tPcbbqniNvwgX8+06Uj8GsMbqt/T74B9C2DnZmYpg9vl4 t/hKY+WcNu/TxbJSnlwI1WJjR0zQpcpygyAkJBDvCDPX4J7IgQfHzhgkZg4rrsnT ZNby/MFLLLHEQ5kbNloLCirOlB9xHofvRmlYcs0Bbxe+OXOdtH1o7jCokk5gKR2K 3RPqxVo/qVsj2lz13cTGHg4QXM86zATLVDx728HlJeoYaH/CS2Axp0lHd+1uW+0c alClJiMnDOgzp8gufxs6xlys0ZT0p3GW6/Z5ghj1ePvAmRulPlJDhIjlNdYQ4P7f jxYrU2kYputNg1UjE00cpP2PTQzUlP6sr5vGpU12VFN2R24BFFy++UL/t/fyohLo wXQvU33sbfgxytMW6jCO+2T/Q8rX9EY7DMmHLZjg3hJpkeyEtWQoczCuAuceZVSI YmgR1UL8tDkHrRpLXaKyd8I2OAobAIhLDdjwPOCTDJhESpEtW5gMzCPsoTMpgBPz Adypjxku3QryzdOdwW8ukZf7vXHjeipi3h6QZGsnBHnBJi4jkYw= =7SpW -END PGP SIGNATURE-
Accepted inkscape 1.0~beta2-1 (source) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 06 Dec 2019 13:07:44 +0100 Source: inkscape Architecture: source Version: 1.0~beta2-1 Distribution: experimental Urgency: medium Maintainer: Debian Multimedia Maintainers Changed-By: Mattia Rizzolo Changes: inkscape (1.0~beta2-1) experimental; urgency=medium . * New upstream version 1.0~beta2. http://wiki.inkscape.org/wiki/index.php/Release_notes/1.0 https://inkscape.org/release/inkscape-1.0beta2/ * Refresh patches * d/rules: now the extensions are properly present in the tarball, drop multitarball hack. Checksums-Sha1: 3508f8fecbe7611a6595869cf6ae357c3fc2e886 2943 inkscape_1.0~beta2-1.dsc c29ae066df55e7c0c87270d67f12c6b0424a7edc 39508392 inkscape_1.0~beta2.orig.tar.xz 37568afbe5a83c7eb31c8291aec763016dbc48a2 95 inkscape_1.0~beta2.orig.tar.xz.asc 09c92154e24bbbe07b6635d892feda531fb29650 25992 inkscape_1.0~beta2-1.debian.tar.xz ba766b58e7cf8a57eb01808423fd30ca9664ded7 19661 inkscape_1.0~beta2-1_amd64.buildinfo Checksums-Sha256: 041a4f871630568428d74db9341669fb643f345855dc07a10c6706c8503f004b 2943 inkscape_1.0~beta2-1.dsc c375945fb8c71a9911db68b6e090f149e31a89f89fbfbb42447b87bd626dc328 39508392 inkscape_1.0~beta2.orig.tar.xz a57dca69bb7a632bd8bdaa03e62a4578bd7de55ddf47cebea02f208bcf4e0df6 95 inkscape_1.0~beta2.orig.tar.xz.asc e6b1988364ee6e1857cbd13048f7069cd07faf305f7d1360acccea6fde69ff85 25992 inkscape_1.0~beta2-1.debian.tar.xz 44e0c7c072bdf61f7c3c7f7b22da7dd9285f58da72957a41de8ea31b7c4472c4 19661 inkscape_1.0~beta2-1_amd64.buildinfo Files: 624acac277e113f73cc111bc666c5803 2943 graphics optional inkscape_1.0~beta2-1.dsc 8f14777858d18823bff3885d63caa3ae 39508392 graphics optional inkscape_1.0~beta2.orig.tar.xz 1dd1fc1e72dc8dacc65d4cb8962525df 95 graphics optional inkscape_1.0~beta2.orig.tar.xz.asc 2031902739a8cc307c1ec44d3baebfc6 25992 graphics optional inkscape_1.0~beta2-1.debian.tar.xz b356dee850eea0f4727022e412f343e4 19661 graphics optional inkscape_1.0~beta2-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl3qRqoACgkQCBa54Yx2 K60dRA//Z4LcCelVMwC65YVBdb089yhVV7QjjnMbNpBsuJ+cDDMhucPtLpP1Qkql /S+2w5WERQvlxWP1pijfFWsVL6ipY803BGoc77EbJjiuzq0D5x0rNb806B7tUv6N 1cz1EUWwDtDMPxwzIi651uvf4fn1mlmfIkL2IWdW2lf5CjeH5D3QiYBL6FGo/CSw bAkKKnYRf+i4CEF6vSzG1R5BroOnV4ZJVdD3IrezWzvwCE+4ioWpGwTLneCM0hcS KibQbqJVFqefcsIAHlvajm6BYWg5vWZsYGElI54GSwWabKwL1MGskx3RO/3uCRFp xXBdFxWtAX5oEci4dq20wieA/yLtyG8L+kGpY7ca9O4iuGqllAvrn1vVhvuoW5Zb mq6K7l9HKE8cCpBxJzFbVVRdSYjxK6ppz0DwzBaVifxi7xkMnVVnXpdo7/V4OthU ApzIkTxoZIuodoMbVyzemtTrYHczVsA8FfLV5BLGUTRpF+RN1JSSzviNrhkG9zUz AESYIyO4zvhcg0VsUD322srt27FGYO7/006XHqsAXfwmVoWRT1Hrc857IAUXBVHY exY+WNk0PMWv0bEPZb+ofIhb7hNWkcicD1USCiUNq5KRoZ1ksyOVq8xQ63l8YP/o VnN6d6b+vo7tS5/VsuG86jzdbm2+DMdRZwF85R8msk8Wd/O1BEE= =Kb1f -END PGP SIGNATURE-
Accepted inkscape 1.0~beta1+ds-2 (source) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 03 Dec 2019 18:21:19 +0100 Source: inkscape Architecture: source Version: 1.0~beta1+ds-2 Distribution: experimental Urgency: medium Maintainer: Debian Multimedia Maintainers Changed-By: Mattia Rizzolo Closes: 942600 Changes: inkscape (1.0~beta1+ds-2) experimental; urgency=medium . * Add a patch to make the program icon appear also under Gnome with Wayland. Closes: #942600 Checksums-Sha1: d038c1dcf200236045c65db19e6d6ebf6bd39677 3286 inkscape_1.0~beta1+ds-2.dsc 09d02b0195b1e916df7d1cb6c6e5d61ec45cef5e 26360 inkscape_1.0~beta1+ds-2.debian.tar.xz 2c6cab878cc3c8bb878e837fdba19f7d4454438a 19686 inkscape_1.0~beta1+ds-2_amd64.buildinfo Checksums-Sha256: 0029fd570934c506361ff5f44076bf1f0e1f1d03cc09badf99cd8a072e7aa61b 3286 inkscape_1.0~beta1+ds-2.dsc f71601788983bc88aac7c7357d8bdd61d323d38b79ef1d88dd20eb86fb479246 26360 inkscape_1.0~beta1+ds-2.debian.tar.xz a7730c890e136f3efd2abca25d9c427a75706ba3024e5422ceabc45cd6840390 19686 inkscape_1.0~beta1+ds-2_amd64.buildinfo Files: 8ff7f115deba5c6b68a7d9df0a039a98 3286 graphics optional inkscape_1.0~beta1+ds-2.dsc d382f0c9dab49d3b72f2aa7faf275e9c 26360 graphics optional inkscape_1.0~beta1+ds-2.debian.tar.xz 303c4e68f2f48959f3a96db50fa21d28 19686 graphics optional inkscape_1.0~beta1+ds-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl3msh0ACgkQCBa54Yx2 K63JmRAAiYg4Z3QMMRvC42KEffHNUEPw713FiAyuSWMvHkh9MdthUI8EJB8mAG3d Tq5ah711sxgz4Px17s5xOW4McG3hgX80CvayvtdMX4VW1MxmFbgMdLKojYnvdPFu /oJBylclqqMTIG2U9U+qy53/vcYZec+GKbqQ4JkB6lchcvRSfoHBweiT4fRtIQWq bKbpo7z2Xjk/FFXOhmz7G7wCp8nHL3X85gAFsn8zzg+B4SUCvR7HzLS/oD29G4Iv Gn8/CXf0FMHY27aePBMr35pDCueKcIlboL32UIC5cKA9m/k9TNxt4/pNEltLQJbW 3JtFFd35QulNvOvR9BpztzenDD9Zfu6jBT4SnWK3MI8uvoEuSDK63znIN8DV7mRe lNmLGnaJe7o57evq7upExjpQFQ45LfqVUVz8Clfa8097iSatW+WaVCn2DzNaIMig gaMaCGYh/zLL0HAEBD7Pd8E4ZtBZDni7/U/PlczDD+YNiksv5c/IK8ILFFTI596b 8I1kf5gl1uHNizfX8pxN34xguwAoTFSNNjm37oeGpHu9QwnkJtTLRwFVzyo9VciQ V+Zz49JoR6llG+TdW2ZDPDvtLBB35C7xXbtx22xI18CMkJqO1i7xR/h6NxwOrMdO SJx9wL+wr1V2Ees4Ji+cXuIYNvTJxUh+Kd66ifmlpcOX8A3feb8= =yl6M -END PGP SIGNATURE-
Accepted ubuntu-dev-tools 0.175 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 01 Dec 2019 19:36:23 +0100 Source: ubuntu-dev-tools Architecture: source Version: 0.175 Distribution: unstable Urgency: medium Maintainer: Ubuntu Developers Changed-By: Mattia Rizzolo Changes: ubuntu-dev-tools (0.175) unstable; urgency=medium . [ Mattia Rizzolo ] * Trust the installed debian-keyring when checking validity of dsc signatures. * requestbackport: + Error out nicely when a tracking project doesn't exist. LP: #1852901 * d/control: Bump Standards-Version to 4.4.1, no changes needed. . [ Stefano Rivera ] * merge-changelog: rewrite the changelog handling to use python3-debian. . [ Dan Streetman ] * tests/pylint.conf: use jobs=0 to speed up tests. * submittodebian: use a context manager while opening a file. * d/control: add dependency on python3-lazr.restfulclient. * Big refactor/rewrite of the whole archive.py module, together with a restracturing of all the pull-pkg-* commands. * Unify the logging using the standard python logging module, and remove the local ubuntutools.logger module. Checksums-Sha1: 6a4cd33cc33917a8e8c181e7ac632e6c66af7f35 2248 ubuntu-dev-tools_0.175.dsc f08f0006ce51169eec1bd735ebfb2780c732f566 169592 ubuntu-dev-tools_0.175.tar.xz 2adf06450b5381a4216c572855687291b5af1f81 10671 ubuntu-dev-tools_0.175_amd64.buildinfo Checksums-Sha256: 23fa72b2b2bb4f7c3eb2abc46b601e956609f5f6d48c455e7213c509573b895d 2248 ubuntu-dev-tools_0.175.dsc 394c59cda9de00c83634e9dd6bccc524658eaf22aa24ab7dcc4bacb8fbc0e50a 169592 ubuntu-dev-tools_0.175.tar.xz 21af1254e3a3383a0fd6873810d6834ad97c2648ea6b62d063176a34f9a01dad 10671 ubuntu-dev-tools_0.175_amd64.buildinfo Files: b45e2ceb54b0a7235c7c58b8d7536a7c 2248 devel optional ubuntu-dev-tools_0.175.dsc f2296ddb5b2aeb8d130dbadd9d037efd 169592 devel optional ubuntu-dev-tools_0.175.tar.xz 2bd0b5522af8f2228d0cd39687b2949c 10671 devel optional ubuntu-dev-tools_0.175_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl3kCeMACgkQCBa54Yx2 K62dwRAAl09xzXkP+319fHffHNX+e4SjiZ71Ffhz5FRWi0foAaZVcT3s2z7ksfdT iyf7aCuD3efZSlJSe2giKyvyxqJ7Sa6x3OkCmhIUlvM+vKAHESsVPl1Psm3qHYjh fgjTA07srnRxh2JrS4qHyHoU7zWJb55LH5ckAJqL/E/V3eHIRNZu0B/Z5T2VBG7g 5C0pqIgXDXbKgsYKvlXEbFUci8PsPRE1haX9icd+jrs7IKVDsvRHooh2o+rcZAu5 wg4hconshImEKDkCkExUEbVZ8DNYrLL3m7p+a7S081WYsfcWgtFD7+xnyG4do+vC DL2Z36WsV1RVyMl67X0lVZXSC5QPgLDYOaaQ6Ez3GIx8d673glSn1tvyrktbnqSt +9iFChOuaixChCEfZgQ1pei43q5t8ZKW7WXHeg6tBkzcomasZ13KoM4junnzwMHR fwiV39towF3h9VL9qBhe45AzUMNPAxD7a+tldZaGnr8Omky/tSqCktgQkqXBaMth 9Hwf5B+WSpG9v3kRJ7AXhGx5Pg9S6YSA5eKagxpvdkBvbAVhyyJzgyeH/YTYSuGN KmktSUQp8wpmBnewvITkHkzpLBUMxxVBktOkIO+nB0OK4NCo6e5hNC1+yqac7OUx di5m2rPOa0HZoEJZr9PvwcV/V1qju43O5DNRyQgR8W+jvRW9BWs= =BSNE -END PGP SIGNATURE-
Accepted libxslt 1.1.34-1 (source) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 25 Nov 2019 19:22:08 +0100 Source: libxslt Architecture: source Version: 1.1.34-1 Distribution: experimental Urgency: medium Maintainer: Debian XML/SGML Group Changed-By: Mattia Rizzolo Closes: 936942 Changes: libxslt (1.1.34-1) experimental; urgency=medium . * Team upload. * New upstream version 1.1.34. * Refresh patches * d/libxslt1.1.symbols: Add new symbols. * d/control: + Bump debhelper compat level to 12. + Bump Standards-Version to 4.4.1, no changes needed. * Stop building and installing the static library. * Stop installing xslt-config, please use pkg-config. * Drop Python2 packages. (Closes: #936942) * Make use of dh_missing --fail-missing: + Leave the docs files where the upstream build system put them, and just move them into the right package. All the documentation was this way moved into an extra html/ directory. + Installs files in a way that lets dh_missing detect them as installed. + d/not-installed: list xslt-config. Checksums-Sha1: 4067917a32c534214519167395afa2c4ccd2b53a 2362 libxslt_1.1.34-1.dsc 5b42a1166a1688207028e4a5e72090828dd2a61e 3552258 libxslt_1.1.34.orig.tar.gz 2c03db476a27bfbaa6194c877925945b7ed8 488 libxslt_1.1.34.orig.tar.gz.asc 4f38c482729a4123b290a136a8296c65d095ddd8 19980 libxslt_1.1.34-1.debian.tar.xz 26d885b58fb1ce5371991a15ed04cdd493900413 6621 libxslt_1.1.34-1_amd64.buildinfo Checksums-Sha256: 49e9e59377f866627f219133d581faa671ead56dcf5c7e19b396ddd0a6efe4f7 2362 libxslt_1.1.34-1.dsc 98b1bd46d6792925ad2dfe9a87452ea2adebf69dcb9919ffd55bf926a7f93f7f 3552258 libxslt_1.1.34.orig.tar.gz 673d1477552bdd5b0cc665704e77ca70e6be5d2f257e6a5a341c846719d747cf 488 libxslt_1.1.34.orig.tar.gz.asc cb4c0d81f86ae915302c602c9285926da8faf6720b04f8df2c87968bea412a96 19980 libxslt_1.1.34-1.debian.tar.xz 08b9e3e0cf90fd9416a5d2af778134a8a91af48f14c6ebd7c476b45b2a407e3f 6621 libxslt_1.1.34-1_amd64.buildinfo Files: ddb1e0a18c263b706e361584c3c6591e 2362 text optional libxslt_1.1.34-1.dsc db8765c8d076f1b6caafd9f2542a304a 3552258 text optional libxslt_1.1.34.orig.tar.gz 0b982649f3a726af7f54312a2dba1e1d 488 text optional libxslt_1.1.34.orig.tar.gz.asc 2bbf3c85db07e4c396f8f0165c62a926 19980 text optional libxslt_1.1.34-1.debian.tar.xz 2c5a725b448fb19558b23fb0e5d5 6621 text optional libxslt_1.1.34-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl3cHJAACgkQCBa54Yx2 K612Wg//fvL3Pn2DUjRgYMO8+XejtvYPxlnj9iehLLDXja2iZ6IYON6IODKC524d RJdJhsEtSNsWLBcnU7fz+b/wieqrvqtISxvIZofiaDBTLMUiWvbSY9IhM1keAe5+ pplPbNKmKTFMrmkN9EeJI0bYBZTI0kY5KI0zKrr7FcPL8DI4+oBXuRwJa2phepqW yhrYdt7GfLZofRBRhCphewuY2kgOZSHX7lY5kH7WpTNw3kUHHFnYNBJXO4fJbl5K 7k54lGKcijeX0bce1EisuKLmtXpnKxFGaHDgyT9CxPvsYVW7hlL7HY6VwuTOnzMw CCz8xDTXSFYEXt6BOwchK7Mt77ShRaZXVDUrYlLmWSEJT4Z5H+owrb8CZ34hfmn3 PKR1gK+qbHhhaX+s/SufhVo8rRxdsyjhIlNyYHufLeZzjO/rZ/D9SQCATBxnZ/Vr K0txme965uts+Z/ahF/upYhzUoSlc/YAwcT8S7PDGUU4dgZ4kxu914CpCGdu5zhi +x/PKJCBYZAs3UeXwJLPrmZh53TJzeLiaDm9OTYPjwuTFXg2UwTGIaMa5VBzyojV VigZRl1o7N2p78hCi56adjbT+unoaxiG/X5HJi0sQqKiv7uxRh/PSwOKcDmLIjo2 o88NKb235bqLi1gdA1qrIwSbTQTQjpLifTJvFfUoXDire5qCit0= =MCw3 -END PGP SIGNATURE-
Accepted libxml2 2.9.10+dfsg-1 (source) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 25 Nov 2019 16:48:13 +0100 Source: libxml2 Architecture: source Version: 2.9.10+dfsg-1 Distribution: experimental Urgency: medium Maintainer: Debian XML/SGML Group Changed-By: Mattia Rizzolo Changes: libxml2 (2.9.10+dfsg-1) experimental; urgency=medium . * Team upload. * New upstream version 2.9.10+dfsg. * Drop all patches. * d/control: + Bump debhelper compat level to 12. + Bump Standards-Version to 4.4.1, no changes needed. * d/libxml2.symbols: add Build-Depends-Package field, by lintian. Checksums-Sha1: 4dbd4bf0813011b7f6475468bab894541fcb6975 2619 libxml2_2.9.10+dfsg-1.dsc 2578c0817feae47d78c4f987c7a2a32f87d89517 2503560 libxml2_2.9.10+dfsg.orig.tar.xz 1915e28e400cea71d1270835a7c4c74ca6869f67 24628 libxml2_2.9.10+dfsg-1.debian.tar.xz 8d37925c78205e9bf09ec571379dc20790f5bbc4 8783 libxml2_2.9.10+dfsg-1_amd64.buildinfo Checksums-Sha256: 8da5eb87764724e90842a24cb891061a0da48a5caf0d16365417e7aa61cb49a1 2619 libxml2_2.9.10+dfsg-1.dsc 65ee7a2f5e100c64ddf7beb92297c9b2a30b994a76cd1fab67470cf22db6b7d0 2503560 libxml2_2.9.10+dfsg.orig.tar.xz b3f1065a018275fac3402c2f7fe4465dc10007251149f9cd3d86fcf4ece32002 24628 libxml2_2.9.10+dfsg-1.debian.tar.xz ee6520273bbb32d900412b5234811223077962e0c09c8979b4063f74b5c6dec9 8783 libxml2_2.9.10+dfsg-1_amd64.buildinfo Files: 8a0f50bde09cd39d881498ad86cb10a3 2619 libs optional libxml2_2.9.10+dfsg-1.dsc 4fb60521425df67f453b3c1ff0efbc1c 2503560 libs optional libxml2_2.9.10+dfsg.orig.tar.xz 2b4e2c7f344fa7aacad5aa50cabca69d 24628 libs optional libxml2_2.9.10+dfsg-1.debian.tar.xz f1d5ab005303cb7284466e3d2eca597b 8783 libs optional libxml2_2.9.10+dfsg-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl3b+58ACgkQCBa54Yx2 K63BDRAAgbajxSmdB6TajnUeFzEqa3mv6cePVyYR6QMVTAFByFLpeNuIaBYqurWd DQOHfs7b0wAMStZDyKdLx5KqH+HPWw6eI9R2Zmsh1CLkbNL2VfHqk5EVKBjUPIiQ GNcFM7d24B0cWbc5Bxgef4+9XE9HQ731pFPWsetlRgZbCme7p6ToBEs6XJHcUQnC qAFf1pX3V6y55KNkhyP3RwxHizLtpvukT3C1JRuxhhjzeI4hkoQ8TBkPQUbFZpOM +3LY1XgzTp8s5TyuyXcttkI0sEW8yQb/tPAAh9twdCvaZYMPERgc1wjS3+M5jN8/ WoriUvoWQvUqRB7qptl4/OsA7F7i74IIRGqY2KIUepLSBXe0gSfpDI1L6W/Wk+Zp Z/UwZs1QGtVhY8hmUFnod8ho9Xry/giZVSvpZ11dy9keiNoaFA4gI6RnBlNPWYgh S0d/u5ZjeQJlQVZNV2SjbwO/6yAXaU/ZX1i6u974p9XEahJJMOcJ9wax2VlgnYWj zAYETwBQtY4za9vPNO/iJCg8Un41/zzDbPANLvRTK9GPCrQSuBFRGyX9IqQQnELb +jr6yxjJE/kNHGK7+Y6v3uxpcRyD/7mGIkse7Ra8E7QgE9doJppd2a+kBnvn7k6a QmGOkqN7aTLuyblCJiRCGtwoW/FCnFMTHCDmj+xmoUhsEix9dQ0= =oIsM -END PGP SIGNATURE-
Accepted scribus-ng 1.5.5+dfsg-2 (source) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 23 Nov 2019 16:49:26 +0100 Source: scribus-ng Architecture: source Version: 1.5.5+dfsg-2 Distribution: experimental Urgency: medium Maintainer: Mattia Rizzolo Changed-By: Mattia Rizzolo Changes: scribus-ng (1.5.5+dfsg-2) experimental; urgency=medium . * d/rules: Stop compressing the TRANSLATION file. Bug: https://bugs.scribus.net/view.php?id=14098 * d/control: + Replace build-dependency with unversioned openscenegraph, now that it has been updated and it points to a Qt5 version. + Bump Standards-Version to 4.4.1, no changes needed. + Drop direct dependency on python-tk from the main binary. Checksums-Sha1: f0ef45f2c5f9efe5beab976043db502312faa715 2551 scribus-ng_1.5.5+dfsg-2.dsc 6460d862c4a4c73d2357d07a1cb7604e85a5a1ca 40688 scribus-ng_1.5.5+dfsg-2.debian.tar.xz c8b077931d6f6273d9d820c4e4ba327a5cd61fee 21744 scribus-ng_1.5.5+dfsg-2_amd64.buildinfo Checksums-Sha256: 08306b97f30b67cd9bc1b6575ad10e4a245d47d981d7f7f8b60ce11063047e2c 2551 scribus-ng_1.5.5+dfsg-2.dsc 296e1ec2066297cf7588a4bf89cf9ea282530833a2f3eb3734b3c42a641e34ed 40688 scribus-ng_1.5.5+dfsg-2.debian.tar.xz 05cb083fc88a59fde189a4ab3490a255c71b90ec7985f311a0255fd3e246128a 21744 scribus-ng_1.5.5+dfsg-2_amd64.buildinfo Files: 67c0d0c51cfd80343d30816a7ecf8473 2551 graphics optional scribus-ng_1.5.5+dfsg-2.dsc dafcb3f03ef33854feb89ec4af490417 40688 graphics optional scribus-ng_1.5.5+dfsg-2.debian.tar.xz d412564e92f154e277366a9b40fd28a8 21744 graphics optional scribus-ng_1.5.5+dfsg-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl3ZbWsACgkQCBa54Yx2 K61ZuA/+NIh0u/YJ9r/zzHppR2PSAMajvcvRvKHHLuKo8dJLJlc3cFTTSPDk1P1b 7AHbXfcGVVTerAkf28p4Zz/ZrJp4ac5tFCzbhhLtaN02vqlXh9uuzOeQpL2LEa/l cagfhrh1QOwDXCHCXGPWYOCT1b1kPQvFu+Sjo5tWVjiRlhrwSzip/CuPYj9eH5JG 6kJMnkZhiGMEoXy9bJHnhL6xd/+wGcRCVJtufik33mTP0xj3bSLkDs2n+Gl9T7b4 mhsFRDuJxdWIshkdtZAt2cg7VszzvZtK6gtfVLDWglq3kp6p8LINdZxR23aJnSPD iGNcXOdm0cPOr3vzkcQEGRF/P/mlK1v7eshIyTxFRuWsSO5PGWAu02qdSTTw5gjX iauPsobW37dgKcbAL4flkbniJkxySyNlt/5iJmxdJ8urvfTPUaOtfdsWRsCzMeCk LDst7rRzgVG/nf/wnobgY+KBLAbTk/aIotkq5PnAJeIbIzDE5/yv5mOjQt+4g8Ve iK9up6PkwmFRVOm+KKZ3TOu3sxEAVMLEJ0X1cSgWvoNKrh5S8TFPA99JRjA/XZF8 PiwvyOGQLe7A7tTYVbozxHEEFFo+rw7HsUeIQa0reebmow4CT9gArVOmioNqsnA4 soFJ9W0O8Wcl/oFm/197pEUqpwdoF3LstXVTGPCuvSYxb5ipmco= =rE2U -END PGP SIGNATURE-
Accepted libxml2 2.9.9+dfsg1-1~exp2 (source) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 19 Nov 2019 14:53:11 +0100 Source: libxml2 Architecture: source Version: 2.9.9+dfsg1-1~exp2 Distribution: experimental Urgency: medium Maintainer: Debian XML/SGML Group Changed-By: Mattia Rizzolo Changes: libxml2 (2.9.9+dfsg1-1~exp2) experimental; urgency=medium . * Team upload. * Merge the lost uploads 2.9.7+dfsg-1 and 2.9.8+dfsg-1. Checksums-Sha1: 0972fc1bedf35e152243f34eadf1cf93433c74a4 2633 libxml2_2.9.9+dfsg1-1~exp2.dsc 25c8e636d84d9f6b4fc94cdc73a0ebee48fe7748 25980 libxml2_2.9.9+dfsg1-1~exp2.debian.tar.xz 0329237ad293ac6e26e5c60f2a4aa64adef66dc5 8953 libxml2_2.9.9+dfsg1-1~exp2_amd64.buildinfo Checksums-Sha256: d27676dab50f86c75caa87447cea4e5fd389b3aea4b9810a72b83c3c0198acd6 2633 libxml2_2.9.9+dfsg1-1~exp2.dsc 784e58554c19099624d25e9fd77220add4afdbd54b474950fe89316873a31782 25980 libxml2_2.9.9+dfsg1-1~exp2.debian.tar.xz cade15b3ddcf14bd14ab6efdb20a4441fc3f15a04b7a8e2ce6ae3fb7eca0ec22 8953 libxml2_2.9.9+dfsg1-1~exp2_amd64.buildinfo Files: 6405b25dd32e7dd9f6c68e34a810874a 2633 libs optional libxml2_2.9.9+dfsg1-1~exp2.dsc 105bcc0d06c21c063214d5806b40b920 25980 libs optional libxml2_2.9.9+dfsg1-1~exp2.debian.tar.xz d4da49c5f75f945a9c71ddcfdc53e48c 8953 libs optional libxml2_2.9.9+dfsg1-1~exp2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl3T9UUACgkQCBa54Yx2 K61PGA/+IhOc1dMItajPN+5x7UK5FvyUBPi0Mn5hu7GUR7pVflzoDfP0SDnrynDl ry2WEJT3cRASuFLb813LvyQfT0MfT1zvH73KRsumdKFNju+TSI54yFTiEnjON3iA qCrwkUaZCpLtiuVLw5+NHhN/3sqH9wTV/7N5S2mHFWk6G5p+nwh8TfyAvY0sSxSI c2/UgJ0qsQx2ZaafRZyMrCWlBpQJcbZ8wBUtXddYKMypFIxVQ6Y53JrNlaICfe0c 2G0uj9o4xf6bog9G1avuzZymcjMgDVsRoQKM9+CD8HxTi5zycidOKxtBH/sFGWq8 h4CA/hrirgWlD8jA3EipOXKv4Mmc6i8wKNbLxm8akdU+R+hO7+LdJEsCuiIc9/xJ OS3hC7edfBMAqinZf7ISlRcGga79m+kwKjCWjOHKmWKg4obsuLg9K6RehnhyoS6e knGWeAa24pqPyXzMxtDXQkT3ji+B+GZso+HyCVpr74CA1hWUfO4LMqTYU+i9rRzL cJO4J1Sf6u5qwSlsjWJHMYgiPxunMDHxJTmuexQw02kz8ad2JZo6HuulNdv0SFBl RYkmPA1EgY4lnFQ5R+W0+DEaCuqESzc3N+dPQulDzHvzuxKnmawjyqhU0WZATu4o dY/m5d+wm7BRa8woDcVYrOpCPJJSecC3sVcbPb9QOulbNFerBts= =4Qnk -END PGP SIGNATURE-
Accepted libxml2 2.9.4+dfsg1-8 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 19 Nov 2019 12:05:14 +0100 Source: libxml2 Architecture: source Version: 2.9.4+dfsg1-8 Distribution: unstable Urgency: medium Maintainer: Debian XML/SGML Group Changed-By: Mattia Rizzolo Closes: 943386 Changes: libxml2 (2.9.4+dfsg1-8) unstable; urgency=medium . * Team upload. * Fix autopkgtest: use `python2` instead of `python` and actually run the `python3` test. Closes: #943386 Checksums-Sha1: 1ee60c9fcbdc71455cea7bba267a05357d407d1d 2968 libxml2_2.9.4+dfsg1-8.dsc 6ef9a80cc0b8db7320f216de44f1b1355e5d3b73 36228 libxml2_2.9.4+dfsg1-8.debian.tar.xz 432731ed7d457486a5841c1c36716a4b032d6a34 10248 libxml2_2.9.4+dfsg1-8_amd64.buildinfo Checksums-Sha256: 837e98c7eb0846be1b5c8c60ec6bf6db2d25dc830efaeec6eb2461046e751455 2968 libxml2_2.9.4+dfsg1-8.dsc aa0dec45f29ab6eeb67e71d47bf736f0f8cef9caacb7833d83c7deb31625 36228 libxml2_2.9.4+dfsg1-8.debian.tar.xz a831f4f2bd4c2aa7da479f986e365bb8be4708a10dcbce6b6d91d55a2b9c5a0a 10248 libxml2_2.9.4+dfsg1-8_amd64.buildinfo Files: 87a0d15085c70c9ae70b356504244e9c 2968 libs optional libxml2_2.9.4+dfsg1-8.dsc 8fcb9d35292338a2f69a895108937525 36228 libs optional libxml2_2.9.4+dfsg1-8.debian.tar.xz f66ec96afa72e9569b66d26493a1755d 10248 libs optional libxml2_2.9.4+dfsg1-8_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl3Tz8cACgkQCBa54Yx2 K61XMRAAiOsZGM767zRtsmFeNCIo4t2gjH/xGkcAOxvDUuLC+Pj0tz0DygAPwO0m X0QofK2NNgLyiAAaNOrDt8TCZDM3mWleDRriWpUzS4WHayORGH9Ubrnw0JS94nhI nxRpq7ds2UP9yAB+HqE1USSPbzgyi4BQEmbr24mej61l6+ZAaiOn/vxwclP5c/bz d9YIXVe2mgebLkIRe2U9cw+rvrxL37xDhOmSceMT265bdUMrGLE7ySFHYay479mf hY7WRLIAC4egBwFvqTnb2SKzNoRMJt1AIpNnzpAcjJ5IIMprLBBf3IB4NPJKEvGx ZlbuVQKoMDQVG8/IxJQyqcyRWILUNVR/VoGsOtkRD0yJa1pkhHTKZkFvToibdmI0 r4DLM4xT3UDmsE9/zObAKp+QLV0tHO7ZttWLPpBG/3P4SXriCp9m6Xkw3rvu47cg UkCq4WRhE7iDlQNOnt5ol4wj4f1MI55F+DBV76rHOhtYmV7Gr+CWW2x3Fp95vXwC ACvm4xf4OQRrW4qawYM/EkBu8rfbm1K7Osng53zw8wc2ymhO9djGgg/KMiQB54aD MYzQE9eifGSVzufJYr5hfdjzvIMdS+sCCChVpz8Rnuj2Kl7fv4HS27jzQyspV7S4 us7uEkSKMsMqysucC7wiHlDjsUDdXOizx+nlBZM43LDOlAK20K4= =zhIO -END PGP SIGNATURE-
Accepted diffoscope 130 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 14 Nov 2019 11:22:20 +0100 Source: diffoscope Architecture: source Version: 130 Distribution: unstable Urgency: medium Maintainer: Reproducible builds folks Changed-By: Mattia Rizzolo Closes: 944709 Changes: diffoscope (130) unstable; urgency=medium . [ Chris Lamb ] * debian/tests/basic-command-line: Move from deprecated ADTTMP to AUTOPKGTEST_TMP. * Correct the matching of R .rds files by also detecting newer versions of this file format. * Drop unused BASE_DIR global in the tests. * Try and ensure that new test data files are generated dynamically, ie. at least no new ones are added without "good" reasons. * Truncate the tcpdump expected diff to 8KB (from ~600KB). * Refresh OCaml test fixtures to support OCaml >= 4.08.1. Closes: #944709 * Correct reference to the ".rdx" extension in a comment. * Update XML test for Python 3.8+. * Don't use line-base dbuffering when communucating with subprocesses in binary mode. (Closes: reproducible-builds/diffoscope#75) . [ Jelle van der Waa ] * Add support for comparing .zst files are created by zstd. (Closes: reproducible-builds/diffoscope!34) Checksums-Sha1: deabf9b7fdacff9b784df1fe6067e756ef5e8ccf 4704 diffoscope_130.dsc 73a38ec08c3601a962fada3179817c9556f7f54a 974520 diffoscope_130.tar.xz 559d86e96ef16f5361b9a4ed120d728158caf018 26134 diffoscope_130_amd64.buildinfo Checksums-Sha256: 618fcd5c2cd1476b7535301ed66f93eb582c768c77de480d743bc782f3a4b7c5 4704 diffoscope_130.dsc bbaaeedc02eead27ece817914a5f47a73125c939f52b143d01fc406149ffd9e5 974520 diffoscope_130.tar.xz 051b51384619e8583c5f0e62031bf0798f07a93675af30a169cf32243aab12ee 26134 diffoscope_130_amd64.buildinfo Files: 60a6535df0989caca1402091cb5b844b 4704 devel optional diffoscope_130.dsc 727938b0620d1743f1a306fc6c1fd23e 974520 devel optional diffoscope_130.tar.xz e5a733760cdcafe72bc9b87ff65ff946 26134 devel optional diffoscope_130_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl3NLacACgkQCBa54Yx2 K63cwA/+Mt4NCbZdEU8h7RL6a7Ac2/lvWJN7GVK8oD4s8tY8tN7jgJcBF/1iKWoz XnBt4/kQn2EWgjakP5IJEmmCCmyH3dV264AWDzuX5zBqNdXYoI4z06jh3Qletas2 dRP++OtHAQi+DAGxAngnyIfxf+n7JTU0M0LoHSXVLJ09Rlhzwm+KzL5DSB1jmTmZ 61+uaJYVCeNjD3MM2usKpfLG7LfgclbtBxQxFElKqz6UU5HL+YoYbvUzfL2xMU5m 058gU/OMMlgXnlTprSE2t2xkvRkNgss9uOOlTbv1mRcooCdsje0WVhbVYYA/jcyp Gf1EE6zz/kvjeWikJ9DojvbxYFiyJ8kdCuC5nNLdFrtSJPmnM9enkpSYK1qBXciJ GR7kgtMcUgwi4WQJOWrb50EU7ZhDs+YgVFqzij2IO93vQ48Q7Dto6J6Vo1cek+/J N/O3OItsKZMLlyTe9qrRp8ArwDHnMpFkID+ILXx0QjVX2hIeX4cOSXbyuYkqroNC jszwodnGyHWvnRHVyZEw5Hf6/ZKzLujwS7UZdBnHC+oyvL3tceNhtywWjHpXbUnO GF+rapcaVBEmCh324yFrNiYhNCe75u3F7eBZ1BWx1LJO6b12U5lmFltXpGi2rraE clqOF4BUA3ZHvc0SD8OdKGJ23Nu+5/0T0wQ4k0mBkaCbru4wrPw= =/6Z/ -END PGP SIGNATURE-
Accepted tlsh 3.4.4+20151206-1.3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 13 Nov 2019 16:07:32 +0100 Source: tlsh Architecture: source Version: 3.4.4+20151206-1.3 Distribution: unstable Urgency: medium Maintainer: Jérémy Bobbio Changed-By: Mattia Rizzolo Closes: 944072 Changes: tlsh (3.4.4+20151206-1.3) unstable; urgency=medium . * Non-maintainer upload. * d/control: + Move the git repository to salsa.debian.org. + Drop now unused X-Python-Version field. * Run wrap-and-sort. * Reinstate the actual python autopkgtests, accidentally removed in the previous upload. Closes: #944072 Checksums-Sha1: b45e05389ead4ca70c51cab7e3636cfcaec17cb0 2175 tlsh_3.4.4+20151206-1.3.dsc 86a65e17be84e108c396197cb00d7742dd500219 9372 tlsh_3.4.4+20151206-1.3.debian.tar.xz 315b754eef41c72dd27744b74c045447808167ab 9116 tlsh_3.4.4+20151206-1.3_amd64.buildinfo Checksums-Sha256: a8f736d1014a4a7e9615b0b91207ba0ad244b3d755754e35b46557e076eba8de 2175 tlsh_3.4.4+20151206-1.3.dsc cbdc711cd550825d47de78da493c3199e8283a5d31e66cb4c7a675a2b2132f58 9372 tlsh_3.4.4+20151206-1.3.debian.tar.xz 734e6d3bec0dd399272917b67cc17750116f0ab163dd983c99df3609542622af 9116 tlsh_3.4.4+20151206-1.3_amd64.buildinfo Files: 330b0bbb3d52bf93880c3827f42f2fbf 2175 admin optional tlsh_3.4.4+20151206-1.3.dsc 8a8ca97de06a95a82fa270291d0b9fd4 9372 admin optional tlsh_3.4.4+20151206-1.3.debian.tar.xz 5893e7b6bb34c8db8f05b54da76e8440 9116 admin optional tlsh_3.4.4+20151206-1.3_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl3MHNQACgkQCBa54Yx2 K63KuxAAhy7nrSrB0FmXOf/A+cw2uDRf2dpa9LtEpIQX9XSZtpdks9QcYVUFCpMb Sg8ljn2wPa6KfXUrCZcYSsOzx9hTEQrZpiZ8jvwK+JoaztYEfxSSUT7YZrDaQbvD NvVDXx/rQjFjEBy+fsEwjWsaDFkgLACPWjeLmN9GHThChLiSBK8R0pp4HkeAzTts dVInt6bS3H7ROPPt+q/ukdDEUPbDGGcCyuzU8HRgB81G7oQ7M17DrV5jDYj8enRU QgbL0DE3DOLO8sBp7qiW6ltA6m3vmQ+cQIHLk0dSzVLX5D6qehV1m1eiZDSXa2k9 JN9AvzaZLEZ1N+gLnwQ4TYZvpESyGnKVBG1OldreKc3D/G6CDttJAoi6BWv2ouA6 uwWXwUraqJKBMNQQ2V85BgTofaNR7f1PX3H0I63DzG7wwaTRJ7+yUKf235ZJBDqe 0tYXVinrDXrG4G/1sXIkjK3aqHg/15YR3uGuYAn38oiTWLYq1KVRUFxnQlzx0bWa EwYCiKRZg06uS6qUgWVA/dCFUXdxU280GeDDHHU0eRAs3zoDCpHgZSaXRZQArS4S NpQURdnKLl4I2E/jnCRw6dyjG1b6bZh9KZ1ciJgNFMQzZZUZeAKVis4eDKCIxheK Bc4cqgJl+XOxexoZOPWw+t6UnnNliOfe9v1+cdEC3jszS01TeCM= =nqB3 -END PGP SIGNATURE-
Accepted limnoria 2019.11.09-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 11 Nov 2019 18:44:23 +0100 Source: limnoria Architecture: source Version: 2019.11.09-2 Distribution: unstable Urgency: medium Maintainer: Mattia Rizzolo Changed-By: Mattia Rizzolo Changes: limnoria (2019.11.09-2) unstable; urgency=medium . * Add a patch from upstream to fix timeout errors during tests. Checksums-Sha1: 241f29ea24356b6cb3a1f07a042aa7944983b4a8 2380 limnoria_2019.11.09-2.dsc 9a827518fb2ff77bb51a42562727e8babff2710c 10148 limnoria_2019.11.09-2.debian.tar.xz 1c3bba14badfe419319307f2460a6904551a6b04 6267 limnoria_2019.11.09-2_amd64.buildinfo Checksums-Sha256: a92f06037104388edb98918dd5354804f2e6718be02da9095eda2a808ff912f8 2380 limnoria_2019.11.09-2.dsc e82d8758bda54bc6084924c2909123ab41deef61f82a7b1c1bbaceb5a424657c 10148 limnoria_2019.11.09-2.debian.tar.xz cee1e5d97fe8a0e3c9dd2ddaea8c221a6bb4ac90caacc96ce386ad1ec0d5107c 6267 limnoria_2019.11.09-2_amd64.buildinfo Files: 36d5aaa79ec431e47f7888156a0b25f4 2380 net optional limnoria_2019.11.09-2.dsc b8c53e875d3f2b414b55cba62bb32b45 10148 net optional limnoria_2019.11.09-2.debian.tar.xz bf03d9252cef44ed494e20da59a4ec41 6267 net optional limnoria_2019.11.09-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl3Jn8MACgkQCBa54Yx2 K61TGw/7BqazajkHtirMi190Fq0Qq5dG6tlPjxpgLBz/QoAKS87IZbsoDwu8p+pG Z6lVIXpRxxaYvnLg89B0JfB8e//e4b9hkevYqOGAn12JHh1gWkmTDE1FzgUDH8MH +a7MwIMfkM2riTcPpQaPi9mg15CkCCCS/kg0eKAyFTe+vm7RuHWA6IjbKYB1ED+Q c7laB/nxhU2p6U5mFJSMK1YncQoQtxf9mmWGDrQWKnNTxqII88qki8PD0RMl8py2 lxScIgrcrq6smm8JkqBdDC6PCii9KZcq8llJ/xrLGJIRZAOd3ZNoId3G1WEuMpfq j1qSIPbY4fq/yw2tzcaODUfyjHhRKl7Nl95+JK1CruRCVpIyoX5iPatS2fd7mjDl SpWRkP8uliZ7swN7z9ENtEDHIwZrhyCujkhDqrJ1afBXFG1JyuuS2kysm4RS0DBC aCXSq0mjBUM78C0y3ewdD5/lkVcHP7e5b2UMt90VVUn9+DxET4FQ/NzSpNFForQz L9ow4COGzkLSuoU0BAJQBI2mVp+Dw77SaQ6GAedPyHFESroVpu4JV9VA3yjaZoh8 BmLthXw+FYjZfzAiBpbAerZJCYU1kUvnzvtD64FdnUwy7e3Cx2MSZmq9VAmJpvaN lAStX/O8VI9dM3iwynOK1/kxqssaiakHVYWVZSOci/jaJaERWpA= =EXtO -END PGP SIGNATURE-
