Re: Produce extra build artifacts during package builds
On Fri, Aug 02, 2024 at 11:01:24AM +0100, Simon McVittie wrote: > I also did some more concrete design and wrote a prototype - > <https://lists.debian.org/debian-devel/2022/02/msg00238.html> as revised > in <https://lists.debian.org/debian-devel/2022/02/msg00242.html>, and > <https://salsa.debian.org/debian/sbuild/-/merge_requests/14> - > although I never got as far as doing enough testing and polishing to get > it to a production-ready status. I'm sorry that this did not stay as my > top priority, but I can only have one top priority at a time. Right, I read most of the emails in that thread and I did look at the MR. Unfortunately, I did so _after_ the BOF :\ > The artifacts that I'm primarily interested in are the results of failed > testing Right, that's also what we thought. > But, when a test has failed, writing arbitrary imperative code to gather > up the package-specific results (for example the images that were generated > by the gtk4 test suite) is extra complexity for the package maintainer, > which can have bugs, and is rarely tested because hopefully the tests > usually pass. I dislike that as a pattern, and I'd strongly prefer a > declarative syntax of some sort. Consider that in my mind, most packages wouldn't have needed to write any imperative code. I was considering it for example within dh_auto_configure and dh_auto_test, etc, those tools would be responsible for copying the relevant test files into my proposed directory. > In the design that I prototyped, it's declarative, loosely inspired by > the equivalent Gitlab-CI feature: > > - the maintainer can write patterns into debian/build-artifacts for > package-specific quirks like GTK's reftests > (#-prefixed comments are allowed) > - tools like debhelper can append patterns to debian/extra-build-artifacts, > for example dh_auto_* in Meson mode should append "obj-*/meson-logs/*" Well, I don't use debputy nor really understand it, so I don't understand Niels' concerns. But I could accept a file debian/extra-artifacts (for maintainer-specified globs) and directory debian/extra-artifacts.d/ (for tools-provided globs). dh_auto_clean should (eventually) learn to clean this directory. And I suspect that packages that want to be dynamic in the content of this archive can simply `echo path/to/stuff >> debian/extra-artifacts.d/package` during the build instead of my proposed `cp`. Just, if we do we need to keep this as simple as possible as multiple tools will try to parse it. I'd be ok with a plan list, at most accept # at the start of a line for comments and empty lines. > - the patterns reuse machine-readable debian/copyright syntax > - as a result the -artifacts.tar.gz is always a subset of the build tree, > and inherits its layout, same as Gitlab's artifacts.zip This might not work as we want to be able to collect, for example, stuff from /tmp/. OTOH, this can be handled by doing proper subfolders in the tarball. > and sbuild (or pbuilder if you prefer) is responsible for enumerating files > matching the given patterns and packing them into a tarball. I was trying to have something else do the enumeration and have sbuild/pbuilder only do the packing, but I can be convinced in doing the enumeration sure. > >* place the tar'ed-up artifacts in the usual results directory, with > > a predictive name (`$srcpkg_$ver_$arch.artifacts.tar.xz`?) > > I prototyped this as the same name as the log file, except replacing the > .build extension with -artifacts.tar.gz (so the filename has a timestamp > in it). My rationale for this choice is that when tests fail, it's common > to retry the build to see whether the tests are reproducibly failing or > just flaky, so we want to collect one blob of artifacts per attempt, the > same way we collect one log per attempt. > > I don't know how the layers "above" sbuild such as buildd and wanna-build > operate, and I don't have a way to test them, so my prototype stops at > sbuild. This can be left as an implementation detail of the build runner (most likely, both sbuild and pbuilder will obtain a configuration knob for this filename). > > Matthias Klose would like to find a way to do something that at the end > > of a build will look for and collect all the relevant files that are > > produced during an ICE (for example all the pre-processor inputs, etc). > > I'm not sure how to best solve it, but he was imagining a hook somewhere > > (in dpkg?) that would look for them and copy them into the directory. > > Perhaps dpkg or dh_auto_build could append appropriate patterns to my > debian/extra-build-artifacts on build failure, so that this hook would > just be acting as an extension
Produce extra build artifacts during package builds
Hello people,
just now at DebConf we had a small BOF to discuss this problem, that has
several times come up.
Lastly I think https://lists.debian.org/debian-devel/2022/02/msg00216.html
to which Simon had a quite nice answer.
This is what we came up with:
https://wiki.debian.org/BuildArtifacts#Design_proposal
I'm copying it here for reference:
* decide on a directory name (`./debian/export_artifacts/`?)
* the build process will dump any files that could be interesting to
export in there (no decision if/how to define the structure within
this directory)
* potentially, all `dh_*` could copy there whatever is relevant to
them (i.e., `dh_auto_configure` could export configure logs,
`dh_auto_test` the various test logs, ..)
* the containering tool (sbuild, pbuilder, ...) at the end of the
build, regardless of the result of the build:
* check if the directory exists, and it's non-empty
* if true, tar it up
* place the tar'ed-up artifacts in the usual results directory, with
a predictive name (`$srcpkg_$ver_$arch.artifacts.tar.xz`?)
* tbd if this should happen always or opt-in by the build caller
* `buildd`/`pybuildd` will check if such file has been exported, if it
is, then it will be uploaded to some service
* something as simple as an authenticate HTTP POST somewhere will
do - no strong auth needed (right?)
* this new service will simply just accept whatever upload and store it
* possibly define an expiry rule for these artifacts to not hog all
space needlessly
Matthias Klose would like to find a way to do something that at the end
of a build will look for and collect all the relevant files that are
produced during an ICE (for example all the pre-processor inputs, etc).
I'm not sure how to best solve it, but he was imagining a hook somewhere
(in dpkg?) that would look for them and copy them into the directory.
Looking for inputs!
--
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 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)
ger.cc(681)] 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 0x58e0d721 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"
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: 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&tag=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
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
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
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
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
Re: Python 2 removal in sid/bullseye: Progress and next steps
Hi, I'm going to answer, even if I'm not Ondrej :) On Tue, Nov 12, 2019 at 12:10:32AM +0900, Norbert Preining wrote: > On Mon, 11 Nov 2019, Ondřej Nový wrote: > > We are going to raise the severity of the py2removal bugs to "serious" > > in several steps. In the > ... > > Could you please give a time line of how you are planning to proceed? > The next Debian release is still about 1.5 years away (extrapolating > from the last N releases), so I don't see any extreme urgency to purge > Debian from Py2 packages *now* at a time when it is even still > supported? > > Do you have any timeline? Plans beside "...we are going to raise > ...remove..."? > > I would strongly suggest to wait till january at least to start this process, > upstream authors might wait till the last moment ... I don't know about which particular timeline they were thinking about, but I honestly hope they start already. Sure, we are already at nearly half of the process, but now start the much more complex cases. Starting from leaf packages right now only makes sense, it will take weeks to just start crawling the tree anyway. > > We will also then file bug reports against ftp.debian.org to remove > > such packages from unstable. We are going to do this semi- > > I think requesting the removal of packages that you are **not** > maintaining is - to be polite - a bit unconventional (at least). > This remains at the discretion of the maintainer as far as I remember. That's not true. RoQA have been used for years, and from what I could see of the flow of RM bugs related to python2, quite a bit were already done like that. It might be unpolite at times, sure, but that's not really an excuse. Anyway, if you properly maintain your packages, and you maintain non-leaf packages you need not worry; if you maintain leaf packages, at least share in the py2removal bugs your plans. That ought to stop people from removing your packages, even if it won't stop them to raise the severity to RC when the time comes. > > All dependency fields in debian/control and debian/tests/control must > > also be updated to stop using the unversioned python > > Are all you "must" statements "policy decisions"? Or your personal wish > list items? They are "policy decisions" as in, "python policy" (even the package is not yet updated). Dependencies are already being automatically changed by dh-python. If there is one thing sure for bullseye, the /usr/bin/python symlink won't be shipped. -- 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: archive test rebuilds and reports for bullseye?
On Fri, Nov 08, 2019 at 06:37:29PM +0100, Lucas Nussbaum wrote: > UDD uses > https://tests.reproducible-builds.org/debian/reproducible-tracker.json, > but that only includes results for suite='bullseye'. Is that expected? Yes, it's expected. reproducible-tracker.json has only the data that is supposed to be "useful" for maintainers without being distracting. For example, it also doesn't show blacklisted packages, or in other weird states. If you want all the data, that would be in reproducible.json with a slight different structure; however in the past many times we received complaints about unnecessary noise, so if you change I at least urge you to limit what's displayed in DMD. -- 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: dput problem: Ancient sha256sum?
That said, the fact that your .orig.tar.gz changed is an indicator that you
are doing something fishy and you should double check your workflow. You
should not be able to accidentally end up with a different .orig.tar.gz.
On Thu, 29 Aug 2019, 3:18 pm Peter Pentchev, wrote:
> On Thu, Aug 29, 2019 at 03:49:57AM +0100, Ben Hutchings wrote:
> > On Thu, 2019-08-29 at 00:33 +0200, dettus wrote:
> > > So, I am trying to make a package out of my awesome project dMagnetic.
> > > I applied some patches, but unfortunately, now I am getting some
> errors.
> > > After each attempt to dput something, I get the following Email:
> > >
> > >
> > > What happened here? How can I fix it?
> >
> > I would guess that you previously uploaded dmagnetic version 0.17-1 and
> > now you are uploading (say) 0.17-2, with a repacked orig tarball.
> >
> > Since the upstream version is the same, the archive will use the same
> > orig tarball for them - you cannot replace it. So, you need to build
> > your source package using the same orig tarball as before.
> >
> > Ben
>
> ...or, since this is mentors.d.n, you (dettus) could try to log into
> your account there, go to "Your packages", find the upload there and
> remove it. After that, try the dput again.
>
> Actually, no, don't do that. Since dmagnetic is a package that is not in
> Debian yet, the first version to be uploaded must have a -1 revision;
> rebuild your package as 0.17-1 and try to upload it again. Then
> mentors.d.n will recognize that you are trying to upload a new version
> of the same package and (unlike the actual Debian archive) will allow
> you to replace the original upstream tarball.
>
> G'luck,
> Peter
>
> > > Hello,
> > >
> > > Unfortunately your package "dmagnetic" was rejected because of the
> > > following
> > > reason:
> > >
> > > dmagnetic dsc reference dmagnetic_0.17.orig.tar.gz, but the file
> differs:
> > > in dsc:
> 82c115920b5570e1e33c613b008736086db210bc8f9b2c2e75f970e9696d8ec5
> > > found: 64ca6eeb1d646e9992b134b4c89c7b0da5d2f9e141d03ffe29ff76729c4a4975
> > >
> > > Please, rebuild your package against the correct file.
> > >
> > > Please try to fix it and re-upload. Thanks,
> > >
> > > -- mentors.debian.net
> > > (The sha256sum in the .dsc file is correct, btw.)
>
> --
> Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
> PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
> Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
>
Re: Bits from the Release Team: ride like the wind, Bullseye!
On Sun, Aug 18, 2019 at 08:54:21AM +0100, Ian Jackson wrote: > > On 19/08/08 09:46, Paul Gevers wrote: > > > I think we should also try to improve the visibility towards reverse > > > dependencies that their autopkgtest is blocking other packages. I would > > > love tracker (and the old pts) to show this on their page. (Working on > > > such a patch is on my TODO list, except not at the top). > > I already made grep-excuses print this information. It has been very > helpful to me. Maybe we should make --autopkgtests the default ? I think no: --autopkgtests requires quite a bit more computation and connecting to udd and whatnot, I don't think that should be the default. Especially because udd-mirror is starting to be under-dimensioned so it's sometimes quite slow to serve responses (like in the times when its importing a new dump). -- 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: package uploads not being processed
On Sat, Jul 20, 2019 at 03:47:43PM +0530, Ritesh Raj Sarraf wrote:
> I made a couple of uploads in the last couple of weeks.
> I did get email confirmation for my uploads but that is it. None of my
> package uploads have been processed.
That's the obvious sign that your GPG key is not working anymore.
> thunarx-python_0.5.1-1_amd64.changes uploaded successfully to localhost
> mergerfs_2.28.1-1_source.changes uploaded successfully to localhost
20190720123419|process-upload|dak|thunarx-python_0.5.1-1_amd64.changes|Error
while loading changes: No valid signature found. (GPG exited with status code 0)
20190720123419|process-upload|dak|mergerfs_2.28.1-1_source.changes|Error while
loading changes: No valid signature found. (GPG exited with status code 0)
I.e. both your uploads are stuck in a loop, waiting for that signature
to validate.
Your GPG key is expired, so the way to go is:
1. update your key expiry (and whatever subkey you might have used to
sign those files)
2. upload the updated key to keyring.debian.org's hkp endpoint
3. wait a few days for the keyring team to pick up the change and
publish it
4. your uploads get accepted
Note that point 3 is going to happen in 3-5 days if everything goes as
planned, so you should hurry, or wait for the next keyring update at the
end of August!
And please add a note to your calendar to update the key expiry in the
next 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: Debhelper compat levels
On Wed, May 22, 2019 at 04:53:57PM +0200, Marc Haber wrote: > >> So in order to do the backport, I first had to get debhelper 11 (or 12). > > > >You make it sound so hard, but in my own experience it really isn't. > > I totally feel with Simon, especially in the later part of a stable > release backporting becomes a pain in the butt because so many > toolchain packages don't backport nicely. I agree that some packages (and, sometimes, whole chain of packages) can be hard to backport due to debhelper compat changes, but really, this is not the case of debhelper itself here (which is the topic of the discussion). And if a given packages is giving derivatives or 3rd parties troubles in backporting, that should be brought up with that single package's maintainer, gently asking to revert back to a previous compat level or something to ease the situation. -- 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: Debhelper compat levels
On Wed, May 22, 2019 at 02:06:03PM +0200, Simon Richter wrote: > So in order to do the backport, I first had to get debhelper 11 (or 12). You make it sound so hard, but in my own experience it really isn't. > The debhelper 12 package itself has a compat level of 12, which means I > couldn't compile it without the package itself being installed. Downgrading > the compat level to 10 and relaxing the build dependencies seems to have > worked, so I had a debhelper 12 package. That's not true. debhelper doesn't require debhelper to build itself, because it uses it runs itself instead of the system installed version. You can easily note this in d/rules: %: ./run dh $@ > This package then depends on dh-autoreconf, which in turn requires > debhelper 11 to build, so I had to again downgrade a compat level and build > dependencies to build. 1) you can drop the dh-autoreconf dependency in a private backport, it's not really needed if you don't use it 2) you can just build dh-autoreconf right after building debhelper, and you're done debhelper's d/control has a bunch of comments in its Dependencies: and Breaks: field, instructing people on the possible changes that can be done if the dependencies listed there are too strict for one's use case. Really dh-autoreconf is hardly the most annoying one. > - Should unstable/testing refrain from using any debhelper compat level >that isn't supported in stable? No, thank you. > - Should debhelper itself and its dependencies use a debhelper compat >level that is supported in stable? This doesn't really make sense, because debhelper doesn't use anything other than dpkg-perl (and *this* is the only contraint that we need to be afraid of, and it should stay at most at the version in the current stable) and perl to build. The dependencies can just be built after debhelper. -- 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: Do we want to Require or Recommend DH
On Mon, 13 May 2019, 4:43 pm Thibaut Paumard, wrote: > However converting a package with a more convoluted rules files > will take humanpower. While it may be justified to convert a mildly > complex rules file on a package that has some activity, I don't think I > would invest those resources to convert a package that's been working > for years without anyone touching it's rules files. > In the past I took the approach that nearly anything that required me to tweak it's build system more than flipping configure switches meant that the upstream build system needed _something_ to be more clever and do what I wanted by itself. That lead me to write patches that were then gladly accepted and therefore further simplified the rules file even more. So I would tend to treat this change as any other (e.g. the quilt > format): on a best effort basis, whenever you have to touch a rules > file, consider switching I did just that on several NMUs that I did: I needed to mildly touch the rules file, it proved easier to just rewrite it using dh :> > >
Re: Golang >= 1.12 in Buster?
On Sun, Apr 14, 2019 at 12:00:18PM +0100, Toni Mueller wrote:
> I strongly think that this decision very wrong and should be reversed.
> If the RT absolutely insist on cutting down the number of Go versions, I
> am not opposed to see eg. golang-1.11 go, however, as I don't see a
> compelling case for having it. But others may disagree. In this way, I
> fully agree with Eric on this matter.
You shouldn't really complain to the release team, but rather to the
golang maintainers, that couldn't manage to move everything off golang
1.11 in time.
If that really was a issue.
It is not any different from how, e.g. the versions of boost, or llvm
are cut down 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: pbuilder: create: how to set specific UID for some system user (e.g., _apt)
On Sat, Apr 13, 2019 at 11:29:47AM +0400, Jerome BENOIT wrote: > on my box I put special access for _apt. Now I would like to create some > pbuilder ball. > But the creation process is getting stick because _apt is set with an > arbitrary UID. > What is the best way, if we can, to set this arbitrary UID for _apt to the > one used in my firewall ? These are the options in my mind: * set APT::Sandbox::User to "root", and give up on sandboxing * add a hook to create a system user with the uid that you like, and set APT::Sandbox::User to that special user * add a hook to change the uid of the _apt user to the uid you want In pbuilder, hooks G are the ones that should be used for this job, to tweak the chroot right after debootstrap during its creation. For the first case, you can just inject that option through APTGETOPT (in the other cases, it's probably a good idea to add a file in the chroot's /etc/apt/apt.conf.d/; see also APTCONFDIR). -- 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 `-
Re: Bug#925288: ITP: diff-so-fancy -- Good-lookin' diffs. Actually… nah… The best-lookin' diffs.
On Fri, Mar 22, 2019 at 05:06:10PM +0200, Peter Pentchev wrote:
> On Fri, Mar 22, 2019 at 03:34:37PM +0100, Adam Borowski wrote:
> [snip]
> > Highlighting changes inside the line is a massive improvement.
> >
> > There's an implementation of this in "git" itself already, named
> > diff-highlight. Alas, either I'm a complete idiot, or its documentation is
> > not quite adequate -- some time ago I wasted over an hour trying to get that
> > implementation to work, without success.
>
> [roam@straylight ~]$ cat ~/bin/hdiff
> #!/bin/sh
>
> : "${DIFF_HIGHLIGHT:=/usr/share/doc/git/contrib/diff-highlight}"
>
> exec perl -I "$DIFF_HIGHLIGHT" -MDiffHighlight --
> "$DIFF_HIGHLIGHT/diff-highlight.perl" | exec less -r
Either this, or abuse your local sudo to run `make`, or convince the git
maintainer to apply the patch at https://bugs.debian.org/868871
(btw, I recommend less -R instead of -r)
--
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: French? (Re: Work-needing packages report for Mar 22, 2019)
On Fri, Mar 22, 2019 at 11:59:08AM +0100, W. Martin Borgert wrote: > On 2019-03-22 00:26, w...@debian.org wrote: > >bootp (#924999), orphaned 2 days ago > > Description: serveur pour le protocole bootp avec gestion de DHCP > ... > >bsd-finger (#925001), orphaned 2 days ago > > Description: Programme de recherche de renseignements sur les > >utilisateurs > ... > > Has WNPP report always been in French? :-) Pierre-Elliot ran the orphaning script on his machine that has LANG=fr_FR. Apparently that was enough to affect `apt-cache`'s output, but he didn't notice till too late :> He promised to improve the script for the next time :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: Removal of Wheezy and Jessie (except LTS) from mirrors
On Thu, Mar 21, 2019 at 08:56:58AM +0100, Joerg Jaspert wrote: > On 15347 March 1977, Thorsten Glaser wrote: > > > deb http://archive.debian.org/debian wheezy main > > deb http://archive.debian.org/debian-security wheezy/updates main > > deb http://archive.debian.org/debian wheezy-updates main > > deb http://archive.debian.org/debian wheezy-backports main > > … out of which the second and third line don’t work. > > > Looking manually, http://archive.debian.org/debian-security/dists/ > > misses anything past lenny, http://archive.debian.org/debian/dists/ > > similarily does not have any updates. > > > Were the wheezy/updates and wheezy-updates merged into just wheezy > > as last step before archiving, so that those two lines can just be > > dropped? > > Yes, it is common that the last point release, just at end of life time, > takes in what was in those suites at that time. Except that now, LTS keeps uploading to -security and there won't be a subsequent point release pulling all of -security into the main suite, so -security needs to be archived there as well. (I don't remember if this was the state also with wheezy, it was with jessie at least). -- 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: ITP: fossology -- FOSSology is an open source license compliance software system and toolkit.
On Sat, Mar 16, 2019 at 05:00:30PM +, Adam D. Barratt wrote: > On Sat, 2019-03-16 at 08:16 -0700, Sean Whitton wrote: > > Hello, > > > > On Sat 16 Mar 2019 at 10:17AM +08, Paul Wise wrote: > > > > > On Sat, Mar 16, 2019 at 6:06 AM Guillem Jover wrote: > > > > > > > $ deb-why-removed fossology > > > > > > I think this script would be a good addition to devscripts, could > > > you > > > file a bug about that? > > > > Very much seconded. Could you at least share a copy in this thread, > > please, Guillem? > > That would be https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644575 And not only this, but it's also in the form of an open MR (that I declied for buster, alas). https://salsa.debian.org/debian/devscripts/merge_requests/107 -- 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: Remainings of old versions of packages in UDD / tracker
On Tue, Jan 22, 2019 at 11:04:16AM +0100, Andreas Tille wrote: > > You have a cruft libmuparser-doc (that interestingly is not listed in > > the cruft-report…). > > Should I file a separate bug report or will you deal with this? Filed the one for libmuparser-doc myself. BTW, the changelog of the first version without that -doc package did not mention dropping the binary. That's bad, please mention such changes in the changelog. > BTW, if we are talking about this I found two other packages: > > $ rmadison -S -s unstable libmuscle > > $ rmadison -S -s unstable libmems > > Please let me know whether I should file separate bug reports about > deleting libmuscle 3.7+4565-2 and libmems 1.6.0+4725-4. These are the same of what you have been doing all these past days, so I'll let you handle 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: Remainings of old versions of packages in UDD / tracker
On Tue, Jan 22, 2019 at 08:48:15AM +0100, Andreas Tille wrote: > This has settled for R packages now but I found another really strange one: > > $ rmadison muparser | grep "unstable " > muparser | 2.2.3-6| unstable | source > muparser | 2.2.6.1+dfsg-1 | unstable | source > > According to buildd[1] muparser was build on all architectures. There is > a remaining version 2.2.3-6 and I have no idea why (neither why rmadison > does not list binaries). It does? mattia@warren ~ % rmadison -S -s unstable muparser libmuparser-dev | 2.2.6.1+dfsg-1 | unstable | amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, ppc64el, s390x libmuparser-doc | 2.2.3-6| unstable | all libmuparser2v5 | 2.2.6.1+dfsg-1 | unstable | amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, ppc64el, s390x muparser| 2.2.3-6| unstable | source muparser| 2.2.6.1+dfsg-1 | unstable | source You have a cruft libmuparser-doc (that interestingly is not listed in the cruft-report…). For the future, also what Lucas said may be relevant in some cases, although luckily it's a rare matter and not many developers need to mess with (or even know about) that. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: epoch for luakit versions
On Mon, Jan 14, 2019 at 12:51:27PM +0100, Markus Demleitner wrote: > For the luakit package that I'm trying to get back into Debian, I'd > like to use an epoch in the version. > > Here's the story: Originally (and still reflected on > http://luakit.org), luakit used a date-based versioning scheme. In > > Meanwhile (and that's not yet reflected on luakit.org), there are > releases on Github (https://github.com/luakit/luakit/releases) that > follow a major.minor scheme, and the upstream maintainer has > confirmed they want to keep that scheme in the future. Sounds reasonable to me, with that being the original goal of epochs. However, please use 1: and not 2: like what upstream seems to have used… -- 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: Remainings of old versions of packages in UDD / tracker
Hi Andreas,
On Tue, Jan 08, 2019 at 01:30:08PM +0100, Mattia Rizzolo wrote:
> cruft versions, usually hold up due to outdated binaries.
>
> In this case of r-bioc-deseq2, the reason is outdated binaries in
> kfreebsd-amd64 and kfreebsd-i386.
>
>
> using rmadison is a very quick way to notice this, as you will see the
> discrepancy in the architecture list.
I see that you started filing a lot of RM requests to remove many of
such outdated binaries.
However I need to ask whether you try to understand what was blocking
those builds. For example, looking at one of the last bugs you opened
to remove outdated binaries of r-cran-luminescence, I see those don't
seem to build just because r-cran-sp is missing a binNMUs against a new
enough r-base, which is something simple to take care of.
--
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: Remainings of old versions of packages in UDD / tracker
On Tue, Jan 08, 2019 at 01:25:48PM +0100, Andreas Tille wrote: > I was seeking for remaining references to anonscm in packages in UDD. > I've found the following strange hit: > > udd=> select source, version, maintainer, vcs_browser, release from sources > where source = 'r-bioc-deseq2' and release = 'sid' ; > source |version|maintainer > | vcs_browser > | release > ---+---+--+--+- > r-bioc-deseq2 | 1.16.1-1 | Debian Med Packaging Team > | > https://anonscm.debian.org/cgit/debian-med/r-bioc-deseq2.git | sid > r-bioc-deseq2 | 1.22.2+dfsg-1 | Debian R Packages Maintainers >| > https://salsa.debian.org/r-pkg-team/r-bioc-deseq2| sid > (2 Zeilen) > > > which means the source package r-bioc-deseq2 exists twice in sid. There > is also an entry in tracker[1] mentioning version 1.16.1-1 which should > have gone since a long time. The situation is similar for: […] > Any idea why old versions of these packages might remain in UDD (and > thus probably in tracker since it is reading UDD)? cruft versions, usually hold up due to outdated binaries. In this case of r-bioc-deseq2, the reason is outdated binaries in kfreebsd-amd64 and kfreebsd-i386. using rmadison is a very quick way to notice this, as you will see the discrepancy in the architecture list. -- 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: DEB_BUILD_OPTIONS vs DEB_BUILD_PROFILES: What is right and what is wrong?
On Sun, Jan 06, 2019 at 02:55:30AM +0100, Axel Beckert wrote: > Johannes Schauer wrote: > > > A) lintian by mixing up build tags and build profiles? (Maybe this > > >mentioning of build profiles was overseen when fixing #889746.) > > > > I assume this to be the case. > > Would be happy to hear, if Mattia sees this the same way. Yes, it's an oversight. ISTR you have commit rights for lintian, I think you should just commit an s/profile/option/ in that description. > > > If I want to build something with the build-profile nocheck, do I > > > really have to set DEB_BUILD_OPTIONS myself separately to "nocheck" in > > > addition to "-Pnocheck"? That sounds very counterintuitive to me… > > > > I fear you currently have to manually set DEB_BUILD_OPTIONS=nocheck in > > addition > > to -Pnocheck. The reason is, that currently no tool sets > > DEB_BUILD_OPTIONS=nocheck if the nocheck build profile is active. This > > could be > > changed in the future but I know of no such efforts right now. > > Ok, this is really not what I expected to be the case, especially > after #889746. The reason for referring to _OPTIONS is that that's the one defined by policy, and what everybody has been accustomed for many years. But josch explained quite a few things 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: UsrMerge: building issue
On Tue, Nov 13, 2018 at 04:13:47PM +0400, Jerome BENOIT wrote:
> I am encountering a UsrMerge issue with firehol:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913552
> When I build on a local Sid chroot environment, all is fine.
> But, apparently, now when we build from source, the environment seems to be
> UsrMerg-ed [1].
It is since this weekend, when an updated debootstrap landed in
stretch-backports, and was used to create the new building chroots.
If you recreate your chroot now you'll find it's usr merged as well.
> Is there a way to impose a non-usr-merg-ed environment at build time when we
> build from source ?
No. It's a bug in your package, please fix 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: Opt-in to continue as DD/DM? (was: I resigned in 2004)
On Mon, Nov 12, 2018 at 09:43:20PM +0200, Lars Wirzenius wrote: > Tollef Fog Heen : > > (I also wonder if we should just require people to opt in to their > > DD-ship on a yearly basis instead of doing most of the WAT/MIA dance. If > > people can't be bothered to reply to a single email saying «yup, another > > year please» with some reasonable amount of pinging and time to reply, > > they are effectively MIA, at least if they haven't let people know on > > -private or similar.) > > I support automatically retiring DDs and DMs that don't repond to a > ping, or don't upload, or don't vote, or otherwise show activity. Since last year it already kind of happens for DMs, that are removed from the keyring. We in the MIA team still manually process all of them before orphaning the packages, which is the much more nasty task than you may think, given that apparently some people want to keep being in Maintainer of stuff despite not uploading for years and having lost the technical ability to upload years before as well (yes, I'm not kidding). -- 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: I resigned in 2004
On Fri, Nov 09, 2018 at 09:29:29PM +0100, Mattia Rizzolo wrote: > > Leave me alone. Your project left me long ago. Do not contact me with > > regard to Debian bullshit. > > ACK, we will have DAM remove you instead of retire. I suppose there is > no harm as you don't seem interested in the "benefits" that the > "retired" DDs have over the "removed" ones. > I'm sorry to have bothered you more than necessary. > > > Good bye, and thank you for your contributions you made back then! FYI, DAM took care of his request, and a couple of hours ago DSA processed the request locking his account. So the story can be considered officially closed. > ¹ https://nm.debian.org/process/539 -- 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
