Re: Debian versioning question
On Thu, Nov 09, 2023 at 11:06:32PM +0100, Hilmar Preuße wrote:
> I just noticed that it is not just a display issue on the web page, but a
> real issue: my latest uploaded was rejected telling me:
>
> Your upload included the source package proftpd-dfsg, version 1.3.8a+dfsg-1,
> however testing already has version 1.3.8+dfsg-8.
> Uploads to unstable must have a higher version than present in testing.
I mean, of course. What were you even expecting...?
> Can we override that anyhow?
Even if it was possible, how would that be of any help? You do realize
that versioning order matters for much more than whatever is shown on a
web page, right? Like, apt policy. Or what dpkg does.
> I can open an issue at upstream trying to
> remove the RfC files, but I guess he's not really interested in these Debian
> internals. Further it does not solve the issue for this particular upload.
You seem to have skipped the last paragraph of my last email. What
about that?
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Mysterious uscan problem
On Tue, Oct 31, 2023 at 12:26:54PM +, Wookey wrote:
> But why? I thought brackets in regexes (this is a regex, right?) were
> just for saving matches into parameters. Why does it make the version number
> double-up in this case?
I don't know how regexes work in perl, but the thing is that
@ANY_VERSION@ already contains ( ), so you are effectively duplicating
them. From your log:
v((?:[-_]?v?(\d[\-+\.:\~\da-zA-Z]*)))
So I wouldn't be surprised that those brackets where causing some double
capturing or something similar, or at least this would be my
speculation.
BTW, @ANY_VERSION@ also already contains a v? in there, so you can do
away with your own.
--
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: Spotted small bug after upload to NEW: Wait or fix now?
On Mon, Oct 16, 2023 at 06:36:48PM +0300, Jonathan Rubenstein wrote: > If this package was already in > the archive the bug would likely be of priority "normal" or even "minor". > > Since this bug really doesn't affect the package that much as it works fine > anyway with only a few broken links, is it worth going through the trouble > of getting it fixed while it's still in NEW, or is it better to leave it and > get the fix uploaded after it has cleared NEW and entered the archive? > > Would a few broken links (of note on the front page, easy to see) reasonably > be enough to have the package rejected from NEW? That would surely be enough > of a reason to go through the trouble, to potentially save further delay. YMMV (and not only yours), but I vote for the "leave the current NEW version where it is, don't upload, wait until approved and upload the fit". Reasons: 1) it was never really clear to me what the ftp-team look at when there are multiple versions of the same package pending in the queue (because technically when there are they go and approve all of them at once); I wouldn't want to burden them with an extra version and figure out why there is an extra version for such a minor thing 2) asking them to reject the current version to fix a minor bug, it's also just bothering already busy people for very little gain -- 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 versioning question
On Thu, Oct 12, 2023 at 11:52:30PM +0200, Preuße, Hilmar wrote: > The upstream minor versions are always determined by letters, so I'm unsure > how to make clear that 1.3.8a+ is later than 1.3.8+. Any hints? This is a real sad interaction between the letters and the + in this case. Clearly the best solution would be to not need to repack anymore, this would throw the problem away. What's even the point of carrying the RFC in the tarball nowadays? Another solution would be to change the character used to separate the 'dfsg' string. + tends to be preferred, but you could use ~ with the same result most of the time, and it would likewise fix the problem: % dpkg --compare-versions 1.3.8a~dfsg-1 gt 1.3.8~dfsg-1 => TRUE Lastly, you could convince upstream to *always* release their first release with the trailing character, so there are not release that end with a number, similar to tzdata. That said, for this 1.3.8 case you are quite stuck, as you can't do any of the above. The only option that comes to my mind is to just mess up the upstream version string to something like 1.3.8.a+dfsg, and keep at that until 1.3.9 comes 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: Repack source lacking root directory?
On Wed, Aug 16, 2023 at 08:23:14AM +0200, Christian Kastner wrote:
> uscan will automatically repack the ZIP, but I couldn't figure out the
> magic incantation necessary in debian/watch to move these to a root
> folder 'srcname'.
Why would you need to do so?
dpkg-source handles tarballs with no top-level directory just fine,
AFAIK.
--
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: Lost sponsor & autoremoval
On Mon, Jul 17, 2023 at 07:31:35AM +, Gábor Németh wrote: > My earlier sponsor expressed lack of resources earlier this year so I > contacted another person who first responded but now I cannot reach for > a month+. So basically I think I'm now looking for a new sponsor. I > don't think I can file a new RFS so that my package is in the repos > already. By all means, you can file a RFS for anything, there is no such rule that RFS are only for new packages (in fact, if you look at the template, there is a difference regarding new packages, regular updates, critical updates in the Severity of the RFS, in your case it would be sev:important as you are fixing an RC bug). > I'd be grateful if someone could take a look and help upload the new > version before end of July and the autoremoval deadline. That said, I don't have time myself right now, sorry. -- 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: HELP - package not arrived
On Fri, Nov 25, 2022 at 06:14:57PM +0500, Andrey Rahmatullin wrote: > On Fri, Nov 25, 2022 at 10:23:26PM +1100, David Bannon wrote: > > OK, my dput.cf has "fqdn = mentors.debian.net", I assumed that was that was > > for. > It has it in a section named "mentors" and you didn't tell dput to use > that section. > And https://mentors.debian.net/intro-maintainers/ tells to both create the > section and pass its name to dput. In fact, the default dput configuration already has an entry for mentors, so there is actually no need to add one manually 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: HELP - package not arrived
easy...
On Fri, Nov 25, 2022 at 11:50:15AM +0100, Geert Stappers wrote:
> > I move the .upload file out of the way, check the signature, dput
> >
> > dbannon@debTestMate:~/Build35qt5$ dput tomboy-ng_0.35-1_source.changes
> > Trying to upload package to ftp-master (ftp.upload.debian.org)
↑↑
You are not uploading to mentors, but to ftp-master, which will silently
discard your uploads.
You need to specify an upload target, since the default is ftp-master,
like so:
dput mentors tomboy-ng_0.35-1_source.changes
--
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: mentors.debian.net: upload stuck
On Sun, Nov 13, 2022 at 07:11:54PM +0100, Alec Leamas wrote: > I did something I should not have done: I uploaded a package without sources > to mentors. Now, I cannot upload the correct package with sources, it seems > that the bad one is in the way. Is it, now? When I logged in 3 minutes ago, I could see only this in the upload queue: -rw--- 1 expo ftp 4356 Nov 13 18:05 ddupdate_0.6.6-2.debian.tar.xz -rw--- 1 expo ftp 1882 Nov 13 18:05 ddupdate_0.6.6-2.dsc -rw--- 1 expo ftp 7058 Nov 13 18:05 ddupdate_0.6.6-2_source.buildinfo -rw--- 1 expo ftp 2158 Nov 13 18:05 ddupdate_0.6.6-2_source.changes -rw--- 1 expo ftp 37716 Nov 13 18:06 ddupdate_0.6.6.orig.tar.gz And at 18:18:22 the importer task started and ate them successfully :> Nov 13 18:18:30 wv-debian-mentors1 celery[1129]: [2022-11-13 18:18:30,512: INFO/ForkPoolWorker-2] Package ddupdate_0.6.6-2 accepted into unstable > The package is ddupdate-0.6.6-2. Is there anyone listening who can clear > things on the mentors incoming queue? Or, will it happen automatically over > time? I'm not sure what you were seeing earlier (and I haven't dug the logs for it), but I reckon everything's fine. Also, the people who can mess with mentors.d.n can be reached privately at supp...@mentors.debian.net - we are all also on debian-mentors@l.d.o, but we might be a tad more responsive there (can't speak for the others, but mails to support@mentors.d.n are high-priority notified to me, mails to d-mentors@l.d.o are very much hidden in the background). -- 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 does not show up and no REJECT e-mail
On Wed, Aug 31, 2022 at 02:53:26PM -0700, Steve M wrote:
> My package "swiftlang" has been accepted on mentors now. It is missing lintian
> results: "lintian failed to run: None", but that is ok.
This is great!
however that "None" shows a different bug! :P
https://salsa.debian.org/mentors.debian.net-team/debexpo/-/issues/146
--
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: Free component in a non-free tarball
On Tue, Aug 30, 2022 at 12:00:39PM -0500, Ryan Pavlik wrote: > The easiest way to do the tarball cleaning is with Files-Excluded in the > copyright file, uscan will involve something (mkorigtargz?) that uses it to > repack. That's a technical answer to the technical side of the question. Even better, probably: Files-Excluded: * Files-Included: AmberTools > On the "policy"/legal question of whether it's permissible to package the > internal open source in this larger source for the Debian project, I have > no specific opinion but it sounds complicated. You might gauge upstream's > feelings by asking if they can provide a tarball with just the open source > parts. If not, even if your interpretation of the license situation is that > you can package the inner code, it may not be worth it if it's fought by > upstream. Exactly. It wouldn't be the first time that we package something that the original developers never intended to, only to find ourself in some sort of passive-agressive situation, with some sort of hostile upstream. At which point, I would wholeheartedly recommend you don't even start... Instead, if they are happy with you packaging this, they might just be happy enough to extract AmberTools and distribute it in some nicer way not requiring identification on a website… -- 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 does not show up and no REJECT e-mail
On Mon, Aug 29, 2022 at 08:31:44PM -0700, Steve M wrote: > > Quite interestingly, all these 3 uploads caused the service to be killed > > by the OOM killer > > https://salsa.debian.org/mentors.debian.net-team/debexpo/-/issues/143 > > > > So I guess that's why you are not seeing any answer from mentors. > > Thank you for looking into this. Please let me know if there is anything you > need me to do to help with the debug. I could probably recommend you subscribe to that salsa issue above, so that you are notify of updates, and subsequently try again once it's fixed (which probably won't take too long, no promises however). -- 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 does not show up and no REJECT e-mail
Hi! On Fri, Aug 26, 2022 at 11:30:09PM -0700, Steve M wrote: > My apologies for making another "my package won't show up" thread, but that is > my problem and I can't figure it out. My package "swiftlang" takes about 3 > hours > to build and uses about 23GiB of disk space, so that may play a role. > > My first upload on Tuesday afternoon resulted in a REJECT e-mail due to an > error > in the d/copyright file. I fixed that and uploaded again on Tuesday evening. > We > are now about 72 hours later and no acknowledgment has been received. I tried > again 14 hours ago and it has been the same, no REJECT or ACCEPT e-mail and it > doesn't show up in the list of mentor packages. mentors processes uploads every few minutes, so waiting more than 1 hour almost certanly means something went wrong. Anyway, I don't want to compute what "afternoon" and "evening" is for you, but this is from mentors' logs: Aug 23 23:05:33 wv-debian-mentors1 celery[1121]: [2022-08-23 23:05:33,095: INFO/Beat] Scheduler: Sending due task importer (debexpo.importer.tasks.importer) Aug 23 23:05:33 wv-debian-mentors1 celery[524]: [2022-08-23 23:05:33,098: INFO/MainProcess] Received task: debexpo.importer.tasks.importer[f0d330ec-73c2-423a-a537-d85eca4ef8bb] Aug 23 23:05:35 wv-debian-mentors1 celery[1120]: [2022-08-23 23:05:35,989: INFO/ForkPoolWorker-3] POST https://bugs.debian.org/cgi-bin/soap.cgi Aug 23 23:06:00 wv-debian-mentors1 celery[1120]: Failed to import swift: Source package is invalid Aug 23 23:06:00 wv-debian-mentors1 celery[1120]: Failed to parse debian/copyright: Files paragraph missing License field Aug 23 23:06:00 wv-debian-mentors1 celery[1120]: [2022-08-23 23:06:00,703: ERROR/ForkPoolWorker-3] Failed to import swift: Source package is invalid Aug 23 23:06:00 wv-debian-mentors1 celery[1120]: Failed to parse debian/copyright: Files paragraph missing License field Aug 23 23:06:04 wv-debian-mentors1 celery[1120]: [2022-08-23 23:06:04,021: INFO/ForkPoolWorker-3] Task debexpo.importer.tasks.importer[f0d330ec-73c2-423a-a537-d85eca4ef8bb] succeeded in 30.92165717900206> This is likely the reject you had. Then, I see another upload on Aug 24 04:30:25 of "swift" and another one on Aug 26 15:30:16. This is followed by a "swiftlang" upload on Aug 28 00:31:15. Quite interestingly, all these 3 uploads caused the service to be killed by the OOM killer https://salsa.debian.org/mentors.debian.net-team/debexpo/-/issues/143 So I guess that's why you are not seeing any answer from mentors. -- 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: tests failing without specific locales
On Thu, Jun 09, 2022 at 04:37:45PM +0800, Paul Wise wrote: > On Thu, 2022-06-09 at 08:38 +0200, Marc Haber wrote: > > I havent looked at the test in detail, I have not yet decided whether > > the package would be helpful in Debian. It looks like the test has > > en_GB.UTF-8 hardcoded, sets the locale to that value and then fails > > it it's not there. Most likely it's the home locale of the dev. > > It sounds like you could simply patch it to use C.UTF-8 instead? > > Or send upstream a patch to take the locale from the environment > variables. Of course then tests might fail if someone uses a weird > locale and the test results depend on the locale At which point you have most likely uncovered a bug! (unless you are running something that by definition is supposed to be locale-dependant). -- 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: gnutls30 and gnutls28-dev
On Wed, Mar 02, 2022 at 04:50:20PM +0100, Geert Stappers wrote: > At https://packages.debian.org/source/bullseye/gnutls28 > are the packages 'gnutls30' and 'gnutls28-dev'. > > And missing to me are the packages 'gnutls28' and 'gnutls30-dev' Just historical cruft if you ask me. > But are they truely missing? In other words: > Why is there no 'gnutls28'? (There is a 'gnutls28-dev' ) There used to be, simply the SONAME changed over time from 28 to 30 (back in 2015). > Why is there a 'gnutls30' whitout a 'gnutls30-dev'? Because renaming -dev packages is hard. If I were the maintainer I would make the effort to rename it to gnutls-dev without the number (and there is a Provides in place already, so you could just go with that). Back in the time versioned -dev packages were considered ok, nowadays they are discouraged. -- 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: Handling upstream versioning scheme 2.40c >> 2.40b >> 2.40
On Wed, Feb 23, 2022 at 08:53:26AM +0200, Andrius Merkys wrote: > dpkg-genchanges: warning: the current version (2.40c+ds-1) is earlier > than the previous one (2.40+ds-1) mh, yeah, that one's annoying. > The naming scheme could be adjusted to add '.' before the letter in > version string (2.40c -> 2.40.c), but I cannot craft a watch file which > could perform this. I'm not sure if that's the correct answer to your problem, but this extra rule seems to work on src:c2x: uversionmangle=s#([a-z])$#\.\1# -- 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 purpose of marking a package Multi-Arch: foreign
On Sun, Jan 16, 2022 at 12:56:38PM -0500, Tong Sun wrote: > I guess I don't understand the concept and implication of Debian's > cross built, as I see that easygen is being cross built without > 'Multi-Arch: foreign', yet golang-github-danverbraganza-varcaser-dev > is not, despite having the 'Multi-Arch: foreign' . Reading your words, I think your first step should be to look up the concept of "cross builds" and what that means and implies (as opposed to what you normally use and know, that are "native builds"), as I don't think you understand what that is. I don't think trying to understand the concept of cross-satisfable dependencies and the limitation imposed by the model used by dpkg (and as such why the Multi-Arch field is needed at all) is useful before that. > https://buildd.debian.org/status/package.php?p=easygen vs. > https://buildd.debian.org/status/package.php?p=golang-github-danverbraganza-varcaser These are not cross builds: buildd.d.o only does native builds. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Reproducible builds erroneous ticks
Hi!
On Mon, Oct 11, 2021 at 06:41:19PM -0700, Matthew Fernandez wrote:
> I was reviewing one of my own packages on the QA page¹ and was
> surprised to notice it gets full marks for CI/Rep. “Surprised? Isn’t
> that a good thing?” you say. It’s surprising because I’ve been
> tracking an upstream bug that I *know* makes this package’s build
> not-reproducible. Clicking into the Rep tick mark, I note it’s indeed
> flagged as not-reproducible. Is the tick mark a mistake? Or am I just
> wanting to judge my own package more harshly than CI judges it?
Can you share more details on the bug you know of? Is it related to
build paths?
Varying build paths is not done for builds outside of unstable, and the
reproducible builds website exports its data based on testing instead.
The reason is simply because varying build paths causes still way too
many unreproducibility that most single maintainers can do nothing about
(they really require toolchain-wide changes that are slowly happening),
which is way they are "hidden" from the default view you see in DDPO.
--
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: Removing repositories from salsa.debian.org/debian
On Fri, Sep 24, 2021 at 03:16:34PM +0300, Andrius Merkys wrote:
> I have created repositories under salsa.debian.org/debian, and later
> pushed their contents to repositories in another group (I should have
> transferred instead). Could someone with appropriate privileges remove
> them?:
The process is to open a ticket in
https://salsa.debian.org/salsa/support
--
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: [d/watch] Need to modify name of upstream tar ball
On Sat, Jan 30, 2021 at 04:37:23PM +0100, Hilmar Preuße wrote: > The part of the Debian udd database, which lists new upstream versions [1] > prints that error message, hence there was a scan. BTW, that's also visible here: https://qa.debian.org/cgi-bin/watch?pkg=texworks-manual > I now tested your pattern > using uscan from Debian stable and now get the same message as in the udd. > After reverting back to my tags based pattern the scan works fine on stable > & unstable. > > Hence I'd deduce that your pattern does only work on testing/unstable and I > have to modify by watch file again. that was fixed in devscripts version 2.20.5, which ftbfs in buster-backports, which is fixed in the devscripts' git, and I'll likely release in a few days, so it wasn't that strictly needed to do that :) But guess it works either way. -- 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: New comment on package microsocks
On Thu, Oct 08, 2020 at 01:10:36PM +0500, Andrey Rahmatullin wrote: > On Wed, Oct 07, 2020 at 03:44:57PM -0400, Tong Sun wrote: > > > Nice: > > > https://metadata.ftp-master.debian.org/changelogs//main/m/microsocks/microsocks_1.0.1-1_changelog > > > > > > Not sure why it's still here... maybe because it went to experimental > > > only? > I don't think this should matter for the mentors website though. what's relevant for mentors is that in mentors that specific version was uploaded to unstable, whereas in ftp-master that same version was uploaded to experimental. As such, mentors is not auto-removing it's copy as it's "not in ftp-master's unstable" yet. > > Hmm... I'm not sure about the procedures involved, why it is all > > happening etc. > It went to experimental because that's where the sponsor uploaded it. Indeed, you should ask siretart. However my guess is that he wanted to do that so that the next upload to unstable will be source-only. -- 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: Questions about buildinfo
Hi Alec, On Tue, Sep 22, 2020 at 10:48:39AM +0200, Alec Leamas wrote: > > I have problems with the debugging info containing the local build path > > and the buildinfo. Status: > > > > As uploaded, the Build-Path stanza is not part of buildinfo. As I > > understand it, this is inconsistent with the local build path in the > > debug package which does exist (and is really hard to get rid of). > > > > A plain 'dpkg-genbuildinfo --always-include-path ' does include > > Build-Path in the buildinfo > > > > Using DEB_BUILD_OPTIONS as documented in dpkg-genbuildinfo(1) generates > > a warning message and does not include the Build-Path: > > > > $ DEB_BUILD_OPTIONS="+path" dpkg-genbuildinfo > > dpkg-genbuildinfo: warning: invalid flag in DEB_BUILD_OPTIONS: +path > > dpkg-genbuildinfo: warning: invalid flag in DEB_BUILD_OPTIONS: +path > > > > $ grep Build-Path ../libcxx-serial_1.2.1-2_amd64.buildinfo > > $ You misread the dpkg-genbuildinfo(1) manpage, the correct env var would be DEB_BUILD_OPTIONS=buildinfo=+path (in general, the format of DEB_BUILD_OPTIONS is a space separated list of options followed by their value after the = sign) However, what you are seeing is likely a byproduct of how your are doing your builds. If you run your build in pbuilder or sbuild, the build would happen in a path starting with /build/, and dpkg would include that path. That's done as to not leak the personal local paths which might include details you might not want to disclose. However, as you likely noticed, that path is also embedded in some compiled files; if you would like to remove them you might try to build specifying (see dpkg-buildflags(1)): DEB_BUILD_MAINT_OPTIONS=reproducible=+fixfilepath We are in the process of making this flag a default of the debian toolchain. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library
On Mon, Jun 01, 2020 at 01:39:10PM +, Vasyl Gello wrote: > >* d/control: > > + Vcs-* have to point to the packaging repository, not the upstream > > one. Since this is something maintained by the multimedia team > > (according to Maintainer) it should have a repo within the multimedia > > team space. > > Fixed by setting Maintainer to me until I get into the team. I have not even > raised > the application intent yet. Mhh, would you please instead consider joining it now, rather than move stuff around later? I don't think I saw your joining mail in the last 20 days (sorry for ghosting - I had some personal matters going on). > >* libudfread-dev.install > > + you are installing the .a file: do you really need it? As a personal > > policy I try to remove static libraries rather than adding them… > > I often link software statically, especially targeting Android. > So I guess keeping static library won't hurt as part of -dev > package. I see that you removed it following pabs' suggestion. Well, just know that whilst I generally agree with him that static libraries are usually just an old renmant and they should be avoided, I also consider them alright if somebody really need them (as long as they are not used to statically link stuff within the archive). Then, I notice that you are bumping the version while uploading to mentors. In the end we shall only upload a -1 with only one changelog entry to the archive, so feel free to just remove and re-upload the -1 version to mentors (IIRC you can also just re-upload the same version and it would overwrite it). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#961919: RFS: shairplay/1.0-1 [ITP] -- AirPort Express server emulator.
Control: owner -1 ! Control: tag -1 moreinfo On Sun, May 31, 2020 at 02:33:33PM +, Vasyl Gello wrote: > dget -x > https://mentors.debian.net/debian/pool/main/s/shairplay/shairplay_0.9.0+git20180824-1.dsc * d/control: + vcs is set to your private space, but the package is team maintained + why did you decide to use "shairplay-bin" instead of just "shairplay"? + drop the full stops from the synopsis (lintian flags this, didn't you see it?) * d/changelog: + it's not closing an ITP * d/libshairplay-dev.install: + same as the other pacakge regarding the .a file. * d/shairplay-bin.install: + imho, you could just reduce the line length with "usr/bin" and "usr/share/man" without specifying the single files, since there is no risk here to pick up stuff from other binary packages accidentally * d/rules: + beware of what that dh_installdocs call you did actually do. I believe you don't want that. hint: check the package contents. + you are -X'ing the .la file in dh_install? is that really needed? + same as the other package regarding dh_missing. * d/patches: + did you forward them? if you did please add some headers following DEP-3. * d/watch: + since now uscan supports scanning bare git repositories, I think you should add a watchfile novertheless Incidentally, the git repository and what you uploaded to mentors are slightly different: |--- shairplay-0.9.0+git20180824/debian/control 2020-05-31 02:00:00.0 +0200 |+++ shairplay-0.9.0+git20180824/debian/control 2020-05-31 02:00:00.0 +0200 |@@ -34,7 +34,7 @@ | . | Currently only AirPort Express emulation is supported. | . |- This package installs the shairplay server executable |+ This package installs the shairplay server executable. | | Package: libshairplay-dev | Architecture: any :P NOTE: I haven't reviewd the copyright yet. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library
Control: owner -1 ! Control: tag -1 moreinfo On Sun, May 24, 2020 at 12:11:42PM +, Vasyl Gello wrote: > dget -x > https://mentors.debian.net/debian/pool/main/libu/libudfread/libudfread_1.0.0-1.dsc * d/control: + Vcs-* have to point to the packaging repository, not the upstream one. Since this is something maintained by the multimedia team (according to Maintainer) it should have a repo within the multimedia team space. + Homepage points to the upstream VCS: doesn't this project have a real homepage? + Both descriptions are way way too short (1 line). please strive to find at least 3 lines... * d/*.dirs + those two files are totally useless, get rid of them * libudfread-dev.install + you are installing the .a file: do you really need it? As a personal policy I try to remove static libraries rather than adding them… * d/changelog: + Please add the "Initial upload" words in there :) * d/rules: + since you are using dh compat 13, you can go and use "execute_before_dh_installexamples" instead of the current override + you may prefer to add that .la file in d/not-installed instead of overriding dh_missing that way (also relevant if you stop installing the .a file). * d/copyright: + I see that debian/* has a different license than the rest of the package. Theoretically that might cause issue if for example sombody writes a patch for debian, place it under the debian/* license (GPL2+ in this case). That patch then it would taint the upstream license, as combining code with LGPL2.1 and GPL2+ leads to something that is only GPL2+, likely something that upstream wouldn't want. + furthermore, the project is not released under LGPL-2.1, but LGPL-2.1+ ... please pay attention to these details + in the copyright you wrote "2014-2020 VLC authors and VideoLAN", but I can't find any year later than 2017. Lastly, I see all files have only one "Author:" listead in them, I'd find nice if you added at least a Comment: line in that "Files: *" paragraph mentioning that single author. + you missed m4/attributes.m4 - please take note that that GPL-2+ file has a special exception * you uploaded a .asc file, but you have not provided either public signing key in d/upstream/signing-key.asc nor set an appropriate pgp option in d/watch. Nor I can find any signature on the upstream repository (note that I haven't tried to check the signature). Where is it coming from? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#961429: Subject: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.
On Sun, May 31, 2020 at 02:54:34PM +, Vasyl Gello wrote:
> I do still appreciate additional reviews on packaging and security of
> cryptopass, because I thought it could be a great example of "making a
> small pavkage to learn Debian packaging".
From my side, the only thing that I would have to say about the new
release, is that since there is now an upstream testsuite, it would be
good to have an autopkgtest.
Apart from that, I notice that some of my previous comments have not
been applied, but those are not new by definition :)
I reckon that asking for review of a small package is indeed a great way
to learn; nevertheless, thank you for thinking more deeply about the
package and retract the RFS.
I would have also wanted to ask you to close this RFS, but I see bartm's
script is too quick these days, removing the package as soon as you
removed it from mentors u.U
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.
On Wed, 27 May 2020, 1:12 pm Vasyl Gello, wrote: > Hi Wookey! > > >OK, but you have to build new packages in a sid chroot too to check > >they work, as that's the suite they get uploaded to. It's fine to > >package in such a way that the package also builds in buster, but the > >primary target of a new package in debian is always sid (unstable). > > So I can target debhelper-compat 12 to keep it buildable on buster or I > shoukd strictly go with 13 as Mattia suggested? Developer 13 is available in buster-backports. Since updates as such the ones you are proposing need to go -backports, they can't go to the main suite, you can rely on packages that already in bpo.
Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.
On Wed, May 27, 2020 at 06:46:42AM +, Vasyl Gello wrote:
> BTW I fixed all the stuff GCC 8.3.0 reported me with FORTIFY_SOURCE=2 before
> pushing code to GitHub.
> Did you use GCC 10?
I just used the current default in Debian sid, which is GCC 9.
You should be building your packages in a chroot (possibly using wrapper
tools such as pbuilder or sbuild) to, as from what you said you aren't
building them in sid.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.
Control: owner -1 ! Control: tag -1 moreinfo On Sun, May 24, 2020 at 02:22:42PM +, Vasyl Gello wrote: > I am looking for a sponsor for my package "cryptopass" o/ > * Vcs : https://salsa.debian.org/basilgello-guest/cryptopass I'm mostly looking at the VCS, but I'm not ignoring the regular source package either. Things: * you are not using git-buildpackage, instead everything is just thrown into the master branch. Please look into gbp. Since this is a totally new package, I'm actually recommending you just destroy this repository and create it anew, starting with a blank `gbp import-orig`. Please also enable pristine-tar in your local configuration unless you have a reason not to, and I also recommend you put "sign-tags = True" in the DEFAULT section as well. * d/control: + any reason not to go to compat 13? + just to please my OCD, could you please move the Section field up next to Priority? (this is just me, I just can't look at that! :|) + on that note, you should review the Section, since this is not a library from what I can see + the synopsis is not a sentence, as such it shouldn't end with a full stop + also in the synopsis, grammar improvement: s/for generating/to generate/ + in contrast, the long description is made up of whole sentences, but it's not really flowing: "This program can be used to generate passwords from a seed composed by: " is more welcoming to read than your initial line * d/changelog: + Make that only "Initial upload. Closes: #xxx", no need for 3 lines and "initial upload" is kind of standard. * d/copyright: + place the full local URI for the Apache-2.0 License + likewise for the CC0, you only wrote the remote URL + you assert that lib/base64/* is BSD-3-clause, but I can't really say it by looking at the source. Since you are upstream, I urge you to include an extra file (like the referenced README?) explaining the origin of those bundled files * d/rules: + you have clearly copied this file from somewhere without understanding it… didn't you? + that DH_OPTIONS export to make "some magic below work", do you know what? AFAIK it's pretty useless as it is, so please drop that + also go read the section "COMPATIBILITY LEVELS" of debhelper(7), to discover that starting with compat 10 "--with autoreconf" is implied + can you please explain what's so special of this package that you don't want to call ldconfig? Since it's something so odd there ought to be a comment. * d/upstream/metadata: + Contact is obsoleted by Upstream-Contact in d/copyright (avoids duplication) * building the package shows this "scary" GCC warning: |In file included from /usr/include/string.h:495, | from cryptopass.c:19: |In function 'strncpy', |inlined from 'main' at cryptopass.c:200:9: |/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: '__builtin___strncpy_chk' specified bound depends on the length of the source argument [-Wstringop-overflow=] | 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); | | ^~ |cryptopass.c: In function 'main': |cryptopass.c:191:25: note: length computed here | 191 | passlenbuflen = strlen(argv[3]); | | ^~~ Overall all of the above are indeed trivial matters, but this is likewise a very trivial project to package. One thing I have to think about is if this is something that debian would benefit to have. I'm not really security-minded, so I tend to be wary about anything that tried to do crypto or handling passwords. I hope some random 3rd party will tell me that this is fine ^^ -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Update repositories on salsa
On Fri, May 22, 2020 at 07:23:43AM +, Håvard Flaget Aasen wrote: > I have update some packages but haven't been able to update the > repositories on salsa. Can someone push the changes to the correct > repo's? > > These are the forked repo's i made. > https://salsa.debian.org/haava/antimony also moved the "upstream" branch to the latest upstream/ tag. > https://salsa.debian.org/haava/FeedReader this apparently I was forced to click the "merge" button since the repo configuration prevented direct pushes -.- > https://salsa.debian.org/haava/pygresql this didn't have the fork bit and didn't have a MR open, opposed to the other two. yay consistency \o/ But all done, thank you! :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: repo rights request help Fwd: yiyantang_0.7.0-7_source.changes ACCEPTED into unstable
On Sat, May 16, 2020 at 10:53:40AM +0800, atzlinux 肖盛文 wrote: > Hi, > > I'm the new maintainer of the package. > > please give me the rights on salsa official package git. > > package name: yiyantang > > my salsa username: atzlinux-guest > > url: https://salsa.debian.org/debian/yiyantang Done. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#960987: RFS: inkscape/1.0-1~bpo10+1 -- vector-based drawing program
Control: close -1 Hi here, On Tue, May 19, 2020 at 05:27:34AM +0100, Phil Wyett wrote: > dget -x > https://mentors.debian.net/debian/pool/main/i/inkscape/inkscape_1.0-1~bpo10+1.dsc > > Changes since the last upload: > >* Rebuild for buster-backports. >* d/control: Use build dep 'debhelper-compat (=12)'. >* d/rules: Use 'override_dh_dwz' to disable debug symbol compression. Thanks for this, but I went ahead and did it myself. Mostly because I see no reason to revert the debhelper compat bump, and I wanted to look for myself at dwz failing (I will add it to d/rules directly on the next unstable upload, conditionally disabling dwz on buster-backports builds). So overall it was just quicker for me to do the work. Since this is a new backport it will have to go through NEW, expect to find it availalbe within a week. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Moving salsa repo to debian group
On Mon, Apr 20, 2020 at 03:13:14AM +0200, Adam Borowski wrote: > On Sun, Apr 19, 2020 at 10:33:19PM +0200, Baptiste BEAUPLAT wrote: > > Could someone move the following repository to the debian group? > > > > https://salsa.debian.org/lyknode/vitetris > > ✓ > > The original is still there. If you want a real move, you'll have to ask the salsa admins to do that since it requires owner permissions in the source namespace and maintainer permissions in the target namespace. Or first move it to a place where are DD has owner permissions and then said DD can move it again to /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: package prevented from migration due to "regression", but regression bug is fixed
On Tue, Apr 14, 2020 at 03:37:03PM +0200, Stephen Sinclair wrote:
> On Fri, Apr 10, 2020 at 4:56 PM Mattia Rizzolo wrote:
> >
> > On Fri, Apr 10, 2020 at 04:51:01PM +0200, Stephen Sinclair wrote:
> > That's because you didn't close the bug in the upload.
> >* debian/rules: Remove use of ccache. (Closes: #945613 #954497)
> > > Is this not the correct syntax for fixing multiple bugs?
> > you'd need a comma to list more than bug after the 'Closes:', so it
> > wasn't closed.
>
> Thank you, I am confused because I actually checked the policy manual
> carefully before doing this, and it clearly states that multiple bugs
> should be space-separated. Is it an error in the document?
>
> https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-closes
That's about the .changes file. For the changelog file see §4.4:
|If this upload resolves bugs recorded in the Bug Tracking System (BTS),
|they may be automatically closed on the inclusion of this package into
|the Debian archive by including the string: closes: Bug#n in the
|change details. [5] This information is conveyed via the Closes field
|in the .changes file (see Closes).
if you then go look at what is the currently number 5 footnote:
|To be precise, the string should match the following Perl regular
|expression:
|/closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
there you can see the comma.
that footnote mentions dak, but this is actually parsed by
dpkg-genchanges. More specifically, the perl module
Dpkg::Changelog::Entry::Debian::find_closes(), there you can see:
453 while ($changes && ($changes =~ m{
454closes:\s*
455(?:bug)?\#?\s?\d+
456(?:,\s*(?:bug)?\#?\s?\d+)*
457}pigx)) {
458 $closes{$_} = 1 foreach (${^MATCH} =~ /\#?\s?(\d+)/g);
459 }
then the list of bugs is copied into the Closes: field of the .changes
in the format that you mentioned, space separated.
--
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 prevented from migration due to "regression", but regression bug is fixed
On Fri, Apr 10, 2020 at 04:51:01PM +0200, Stephen Sinclair wrote: > An update to my package siconos was recently uploaded to fix some > outstanding bugs. However, I have noticed that it has been blocked > and prevented from migration to testing: > > https://qa.debian.org/excuses.php?package=siconos > > The reason given is "introduces new bugs", however the bug indicated, > #954497, is one that was _fixed_ by my update. That's because you didn't close the bug in the upload. * debian/rules: Remove use of ccache. (Closes: #945613 #954497) > Is this not the correct syntax for fixing multiple bugs? you'd need a comma to list more than bug after the 'Closes:', so it wasn't closed. > If I manually close the bug, will it then migrate automatically? yes, that's exactly what you'll need to do. Also, it would be better if you closed it with a fixed version as well. -- 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: gbp export-orig for multiple source tarballs
On Sat, Mar 28, 2020 at 06:11:54PM -0300, Eriberto Mota wrote:
> The airport-utils[1] repository has several .orig.tar.gz files, all
> they committed in upstream and pristine-tar branches.
>
> When I run 'gbp export-orig', I got several error messages[2]. So, is
Please also have a look at https://bugs.debian.org/917789
It seems me (and others) sometimes expect something else.
Honestly, that issue hit me so rarely that I haven't bothered looking
deeper after finding a workaround that works for me (changing the .id).
--
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: Access to repositories
On Mon, Mar 09, 2020 at 10:11:19PM +0100, Håvard Flaget Aasen wrote:
> This is the repositories:
>
> https://salsa.debian.org/haava-guest/python-h2.git
>
> Can you also accept the merge request from Salsa Pipeline, in the original
> repo?
> https://salsa.debian.org/haava-guest/c-icap-modules.git
>
> https://salsa.debian.org/haava-guest/c-icap.git
> https://salsa.debian.org/haava-guest/python-libarchive-c.git
> https://salsa.debian.org/haava-guest/pygresql.git
This is missing a debian/ tag.
> https://salsa.debian.org/haava-guest/antimony.git
I should have done everything, thank you! :)
(but please check!)
--
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: Access to repositories
On Sat, Mar 07, 2020 at 04:46:34PM +0100, Håvard Flaget Aasen wrote: > I have updated a couple of packages and hope that someone can give me access > to the repositories. I'm somewhat reluctant to give you access to those repositories... The salsa admins gave precises thoughts of what was wrong with alioth's collab-maint, and that was that access to random repositories was effectively given to random people. Now, just spreading this access to "random" people for no reason sounds… unappealing, especially if it's for a one-off upload. And definitely I wouldn't do that for NMUs. I know somebody else might very easily think differently than me here though, as I'm known as somebody stingy on the permissions given! ;) > I also have two uploads which is nmu. I don't know whats preferred, access > to the repo or a merge request. Definitely I won't give you access to those repositories for NMUs. Having said that, if you push everything to some private space, I'll happily pull from you and re-push to those repositories (MRs don't scale well with 3 branches). -- 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#953292: RFS: c-icap/1:0.5.6-1 [QA] -- ICAP server implementation
On Sun, Mar 08, 2020 at 01:00:34AM +0100, Adam Borowski wrote: > On Sat, Mar 07, 2020 at 10:26:05AM +0100, Håvard Flaget Aasen wrote: > >* Change path from /var/run/ to /run/ in postinst and postrm scripts > > Hi! > I don't understand the /var/run/ -> /run/ change -- it looks grossly > incomplete. You change it only for the newly created user, but: > * systems which ever had a previous version of c-icap will have the > user's home in /var/run/c-icap Incidentally, ssh itself did this, and indeed in my system: % getent passwd sshd sshd:x:107:65534::/var/run/sshd:/usr/sbin/nologin % inside a chroot: # getent passwd sshd sshd:x:101:65534::/run/sshd:/usr/sbin/nologin # After seeing that ssh didn't really care about transitioning between the directories I also sponsored another package changing directories without bothering about it. > * postrm will remove only the new location (on most systems /var/run/ is a > symlink to /run/, though) Consider that /run is a tmpfs in a standard system, so this is not *that* important. -- 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 respository
Hello,
On Mon, Mar 09, 2020 at 01:38:06PM +0100, W. van den Akker wrote:
> The repository for gtkterm for which I am maintainer, is sourced from
> my personal SALSA git environment.
> I want to migrate to a public SALSA repository but I dont have the
> rights to do that.
>
> Can somebody create the gtkterm repository and give me master rights to
> that repository? My username is wvdakker-guest.
done.
--
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: Breaks or Conflicts
You should use Breaks for that kind of thing. See debian-policy for quite the extensive details of the differences between the two fields. On Mon, 3 Feb 2020, 7:30 am Tommi Höynälänmaa, wrote: > Hello > > I have upgraded package Theme-D to version 1.4.1-1 and package Theme-D- > Gnome to version 0.8.2-1 (not yet in unstable). Theme-D-Gnome versions > << 0.8.2 don't work with Theme-D 1.4.1-1. Should I use "Breaks: Theme- > D-Gnome (<< 0.8.2)" or "Conflicts: Theme-D-Gnome (<< 0.8.2)" in the > debian/control file of Theme-D? > > - Tommi Höynälänmaa > > >
Bug#948530: RFS: coinor-vol/1.5.4-1 [QA] -- Coin-or linear programming solver
Control: owner -1 !
Control: tag -1 moreinfo
On Thu, Jan 09, 2020 at 09:16:37PM +, Sudip Mukherjee wrote:
> dget -x
> https://mentors.debian.net/debian/pool/main/c/coinor-vol/coinor-vol_1.5.4-1.dsc
reviewing this .dsc, I have to comment on the changelog:
> Changes since the last upload:
>
>* QA upload.
>* Update to upstream v1.5.4
>* Update d/copyright.
Mention that you rewrote it using copyright-format 1.0.
(also, since you did this, I'm going to trust you on it without further
reviewing it for correctness)
>* Rename package based on SONAME major version.
>* Remove dbg package in favor of dbgsym.
>* Mark QA as maintainer.
Rewrite this as "Mark the package as orphaned (see #645082)."
>* Update Standards-Version to 4.4.1
Mention that by doing this you are changing the priority.
>* Update compat level to 12
>* Remove build dependency on cdbs.
>* Simplify d/rules and rework on d/*.
I want more details for this. mention that you moved from cdbs from dh
(I think it's good that after this you drop the line above).
For example, it's important to say that you added a .symbols file.
>* Update Vcs to salsa.
>* Mark source format as 3.0
>* Add Rules-Requires-Root: no
Also, you did this:
+override_dh_auto_configure:
+ ./configure --prefix=${PREFIX} --includedir=${PREFIX}/include
--mandir=${PREFIX}/share/man --libdir=${PREFIX}/lib/${DEB_HOST_MULTIARCH}
--enable-static --with-dot COIN_SKIP_PROJECTS="Osi CoinUtils OsiVol Sample"
why not using dh_auto_configure?
for this instead:
+override_dh_autoreconf:
use `--without autoreconf` on the dh line.
and
+LDFLAGS += -lm
please read dpkg-buildflags(1) and follow what it says.
I'd rather have these done now, rather than in a subsequent upload. In
the next upload you can take care of the duplicate-short-description :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: gbp import-orig after upstream force update
On Wed, Jan 01, 2020 at 11:45:02AM -0500, Tong Sun wrote:
> - From the source side, everything is ready. It is only when it comes
> to Debian building, I found that I need do trivial updates to the
> upstream.
In which case, I'd do that trivial update, and put it a debian patch,
pending the next upstream 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: gbp import-orig after upstream force update
On Tue, Dec 31, 2019 at 06:28:55PM -0500, Tong Sun wrote: > How to do gbp import-orig after upstream did *force* push/update with > the same tag? > > While doing packaging, there will always some trivial things I found I > need to update the upstream source (I'm the author for both upstream > and Debian packaging). > > However, if I have to give a new tag each time I do such trivial > updates, then they'll go very fast for very trivial changes, which > does not look good. So I always force push/update with the same tag. At the same time, it looks *horribly* from my side every time I see such things. Don't tag things until you really want to release, and by then you ought to have tested things well enough. If it's really trivial changes, then it can just wait for whenever you feel like doing a new release. > The problem is that I haven't been able to figure out how to have `gbp > import-orig` to deal with such situation -- I always get: > > gbp:error: Upstream tag 'upstream/...' already exists > > How to fix it? Thx Get a new upstream version. If from the upstream side really want to do such horrible things, then fake the version in debian by appending some +a1 version (or whatever string you prefer). Versions are meant to uniquely identify a thing. If the same version string matches different objects at different point in times, it's just conceptually wrong. Anyway, if it's really just that, gbp only checks for the presence of the upstream/ git tag; if you remove it (`git tag -d`) then it won't complain anymore. -- 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#947610: Bug#947611: Debian Bugs #947611, #947610
On Sun, Dec 29, 2019 at 07:56:18PM +0100, Jörg Frings-Fürst wrote:
> already uploaded.
Note that bartm had already closed this bugs (using the 'close' control@
command, so you received no notifications - nor people on
debian-mentors@ did, as it's forwarded to specific mailing list where
~nobody is…)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Salsa repo for opendkim
On Fri, Dec 27, 2019 at 09:51:38AM +0100, David Bürgin wrote:
> the package opendkim doesn’t yet have a Git repository. I’d like to have
> one if possible, at https://salsa.debian.org/debian/opendkim maybe?
created and granted you access.
--
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: Unhide todo list entry in the Ultimate Debian Database
On Thu, Dec 19, 2019 at 06:34:37PM -0500, Tong Sun wrote:
> I accidentally hid a todo list entry in my Ultimate Debian Database.
> Now I regret it and want it back again.
> How can I do that? Thx
TODOs in DMD are saved only in cookies. See the hide_todo() function in
https://udd.debian.org/js/dmd.js which is what is called when you click
the "hide" link.
So, if you look at the list of saved cookies in your browser, and delete
that one, it will come back. The name of the cookie should be
self-explanatory.
--
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: Refresh PGP key with nm.debian.org
On Fri, Dec 20, 2019 at 11:35:00AM -0500, John Scott wrote: > I'm working on requesting a guest account, and unfortunately I've had to > generate new subkeys since starting my application. There doesn't seem to be > an option to refresh my key. Switching to another fingerprint and back > doesn't > work either. Indeed, the function to refresh the caches key is not that available (notably, it's handy only for processes that require a keycheck, dc_ga is not one of it…) > Could someone help me get my key refreshed, or would I be better off starting > a > new application? Alas, even starting a new process wouldn't help your case. I now refreshed the key from the backend, so you should be able to do what you need to. I also opened a bug against nm.d.o to take note of this deficiency of the website. -- 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: Any clue how to use pbuilder / cowbuilder in connection with Rules-Requires-Root: no
On Mon, Dec 09, 2019 at 10:11:34PM +0100, Andreas Tille wrote: > > I'm honestly a bit at loss on how to further debug this issue at this > > time. > > Which at least is relaxing that I'm not asking a stupif FAQ here. :/ Could you please try to provide a full log, with --debug? As an attachment would be best, since it will be huge. And maybe consider scrolling through it yourself, since it might contains "private" informations such a personal paths and whatnot that people might consider sensitive, depending on how one names their directories :> -- 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: Any clue how to use pbuilder / cowbuilder in connection with Rules-Requires-Root: no
On Mon, Dec 09, 2019 at 12:56:22PM +0100, Andreas Tille wrote: > On Mon, Dec 09, 2019 at 12:14:30PM +0100, Mattia Rizzolo wrote: > > Uh, sorry for being imprecise. I meant, that you *should not* set that > > option, and let dpkg decide by itself. > > OK, In my case dpkg has no choice to decide since the pbuilder > chroot is just lacking fakeroot. I get Which is perfectly fine. I now tried and indeed there is no trace of fakeroot usage, as it should be. I: Building the package D: no hooks of type A found -- ignoring I: Running cd /build/python-datrie-0.8/ && env PATH="/usr/lib/ccache:/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-buildpackage -us -uc && env PATH="/usr/lib/ccache:/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-genchanges -S > ../python-datrie_0.8-1_source.changes dpkg-buildpackage: info: source package python-datrie dpkg-buildpackage: info: source version 0.8-1 dpkg-buildpackage: info: source distribution UNRELEASED dpkg-buildpackage: info: source changed by Ondřej Nový dpkg-source --before-build . […] dpkg-source: info: using options from python-datrie-0.8/debian/source/options: --extend-diff-ignore=^[^/]*[.]egg-info/ dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building python-datrie using existing ./python-datrie_0.8.orig.tar.gz dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: building python-datrie in python-datrie_0.8-1.debian.tar.xz dpkg-source: info: building python-datrie in python-datrie_0.8-1.dsc debian/rules binary […] This last line (`debian/rules binary`) is the revealing string that indicates that dpkg-buildpackage understood this is a R³:no build, invoking directly the "binary" target skipping the "build" target. And I likewise have no fakeroot in my chroots. > ... > I: Building the package > I: Running cd /build/python-datrie-0.8/ && env > PATH="/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-buildpackage > -us -uc -i\.git -I.git && env PATH="/usr/sbin:/usr/bin:/sbin:/bin" > HOME="/nonexistent" dpkg-genchanges -S > > ../python-datrie_0.8-1_source.changes > dpkg-buildpackage: error: fakeroot not found, either install the fakeroot > package, specify a command with the -r option, or run this as root > I: copying local configuration > E: Failed autobuilding of package > ... I'm honestly a bit at loss on how to further debug this issue at this time. Even if for some odd reason you had an old dpkg, pbuilder knows how to detect that and it installs fakeroot in that case, but given that it doesn't that's not the case. :\ -- 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: Any clue how to use pbuilder / cowbuilder in connection with Rules-Requires-Root: no
Uh, sorry for being imprecise. I meant, that you *should not* set that option, and let dpkg decide by itself. On Mon, 9 Dec 2019, 12:05 pm Andreas Tille, wrote: > On Mon, Dec 09, 2019 at 11:38:59AM +0100, Mattia Rizzolo wrote: > > > > Are you explicitly specifying -rfakereoot in your dpkg-buildpackage > > options? > > Ahhh, I was actually missing this in my gbp-pbuilder script. > > Thanks for the hint, Andreas. > > -- > http://fam-tille.de > >
Re: Any clue how to use pbuilder / cowbuilder in connection with Rules-Requires-Root: no
On Mon, Dec 09, 2019 at 11:35:10AM +0100, Andreas Tille wrote:
> ...
> dpkg-buildpackage: error: fakeroot not found, either install the fakeroot
> package, specify a command with the -r option, or run this as root
> I: copying local configuration
> E: Failed autobuilding of package
> ...
Are you explicitly specifying -rfakereoot in your dpkg-buildpackage
options?
pbuilder is not installing fakeroot if the package to be built has
R³:no, and likewise dpkg-buildpackage shouldn't be looking up for
fakeroot either.
pbuilder has been doing that for more than a year now, and there are
plenty of packages with R³:no at this date, so I believe something is
wrong with either the package or your setup.
Note that adding fakeroot to the build-deps would be wrong in this
particular case, since that's an error from even before the build
starts.
--
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#941928: RFS: scons-doc/3.1.1+repack-1 -- Documentation for SCons, a replacement for Make
> >* New upstream release.
> Otherwise, looks good.
I want to take this occasion to ask: any chance for this package to
built using python3? I'm looking at dropping the py2 packages from
libxml2 and libxslt, and in paticular the latter doesn't have py3
support at all upstream at this 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: proftpd-dfsg not migrating
On Mon, Nov 04, 2019 at 04:54:07PM +0100, Hilmar Preuße wrote:
> Thanks for the pointer! As the 1.3.6a probably does not contain an API
> change I'll revert the API version change in the Debian package...and
> package 1.3.6b at the same time.
It's not about the API, but the ABI. Be mindful of not breaking the ABI
without doing a proper transition.
--
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#942250: RFS: inkscape-ext-textext/0.12~git32+febf8f7-1 [ITP] -- Re-editable LaTeX graphics for Inkscape
[ note: not taking ownership of this bug, as I'm not willing to sponsor
this ITP due to my own policy; also don't explicitly expect an asnwer
from me to any follow up, I was just curious so I took a little peek ]
Hi,
since you used mentors.d.n to keep your package, please consider using
the template it provides to send the RFS, so it is nicely formatted.
On Sat, Oct 12, 2019 at 08:53:18PM -0600, Antonio Russo wrote:
> There are a couple outstanding issues, most importantly I don't understand
> how Inkscape is getting dh_python3 to py3compile its extensions (and not
> mine). I'd appreciate any help on that end, too.
Sure.
First though, let me mention a bunch of other issues.
> [5] https://salsa.debian.org/aerusso-guest/textext/
I recommend you look up gbp for handling the git repository for a debian
package. Despite having something of a learning curve, once you get the
hang of the basis it will greatly help you managing your package. Also,
there is a growing number of DDs that are more than happy to sponsor
from such a formatted git repository, than a .dsc.
Also, you CCed the debian-multimedia team, if you wish to maintain this
in the team, you may want to look up on how to join them, so you can
also place the repository in the team space.
> [3] https://mentors.debian.net/package/inkscape-ext-textext
This page also already shows a few issues:
1. don't close the RFS bug in your upload, that's closed by the
sponsor, or automatically by a script after the upload
2. there is an upstream signature key, but that doesn't really help
with tarballs created by you from a git repository. You can't
really provide a signature for those…
> [4] dget -x
> https://mentors.debian.net/debian/pool/main/i/inkscape-ext-textext/inkscape-ext-textext_0.12.0~git32-gfebf8f7-1.dsc
It looks like there is some odd method to build that package, mhh.
So, the problem with the python3 dependency, is that the files are
installed in a non-standard directory. Now, it totally numbs my mind
why inkscape produces the correct dependency without specifying it (and
that's even when I am the inkscape maintainer -.-; perhaps it's not
corect after all, I'll check), but in your case, this does the trick:
|--- inkscape-ext-textext-0.12~git32+febf8f7/debian/rules2019-10-13
07:54:29.0 +0200
|+++ inkscape-ext-textext-0.12~git32+febf8f7/debian/rules2019-10-15
20:03:16.0 +0200
|@@ -27,4 +27,4 @@
|dh_installdocs
|
| override_dh_python3:
|- dh_python3 -p inkscape-ext-textext
|+ dh_python3 -p inkscape-ext-textext
/usr/share/inkscape/extensions/textext/
debdiff'ing the .deb:
|Files in second .deb but not in first
|-
|-rwxr-xr-x root/root
/usr/share/python3/runtime.d/inkscape-ext-textext.rtupdate
|-rwxr-xr-x root/root DEBIAN/postinst
|-rwxr-xr-x root/root DEBIAN/prerm
|
|Control files: lines which differ (wdiff format)
|
|Depends: inkscape (>= 1.0~), pdf2svg | ghostscript, pdf2svg | pstoedit (>=
3.74), python3 (>= 3.7), python3-gi | python3-tkinter, python3-gi-cairo |
python3-tkinter, [-texlive-base-] {+texlive-base, python3:any+}
|Installed-Size: [-206-] {+211+}
You can see it added a python3:any dependency. If you were also
expecting the various modules, then you misunderstood dh_python3: for
that you need to provide a requires.txt file (or specify the eggs names
in d/rules, then it would fill them in ${python3:Depends}, see the
diffoscope package for one that does 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 cmake options to dh
On Sat, Aug 17, 2019 at 09:24:09PM +0200, Marc Haber wrote: > On Fri, Aug 16, 2019 at 04:45:50PM +0200, Mattia Rizzolo wrote: > > The way to go with that would be for you to set DH_VERBOSE, notice *which* > > tool issue a particular command (in this case it's _confugure, not _build), > > then know that you can just append options to the command like I did above. > > Is the latter, just appending options to the dh_foo command line, > documented anywhere, and how do I know which of the emitted commands are > the extra arguments added to? Or is this basically trial-and-error? Well, appending arguments to the commands is not something *all* dh_* tools do. In this case, it's documented in the dh_auto_configure(1) manpage: SYNOPSIS dh_auto_configure [build system options] [debhelper options] [-- params] OPTIONS See "BUILD SYSTEM OPTIONS" in debhelper(7) for a list of common build system selection and control options. -- params Pass params to the program that is run, after the parameters that dh_auto_configure usually passes. For example: dh_auto_configure -- --with-foo --enable-bar I'd expect your dh_auto_configure to call only one program once, so it shouldn't be hard to guess where it adds them. In a random package using cmake I see: dh binary-arch --with python3 ... debian/rules override_dh_auto_configure make[1]: Entering directory '/<>' ... dh_auto_configure -- \ -DUSE_SYSTEM_LIBS=1 \ -DSYSTEM_LIBS_REQUIRED=1 \ -DINSTALL_BUNDLED_DICTS=0 \ -DMATHJAX_DIR=/usr/share/javascript/mathjax/ \ ... install -d obj-x86_64-linux-gnu cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DUSE_SYSTEM_LIBS=1 -DSYSTEM_LIBS_REQUIRED=1 -DINSTALL_BUNDLED_DICTS=0 -DMATHJAX_DIR=/usr/share/javascript/mathjax/ .. ... make[1]: Leaving directory '/<>' dh_auto_build -a ... i.e. the only two commands called by dh_auto_configure are `install` to create the build directory, `cd` and `cmake` itself. So it's really quite easy to figure to which of the emitted commands are the extra arguments added to. -- 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 cmake options to dh
On Fri, 16 Aug 2019, 4:31 pm Marc Haber, wrote: > Hi, > > I am compiling a cmake-using project using dh with the following simple > debian/rules: > #!/usr/bin/make -f > export DH_VERBOSE=1 > export DEB_BUILD_OPTIONS="nocheck" > > %: > dh $@ > > override_dh_auto_test: > echo "skipping test" > > To enable a feature I need, upstream suggests > cmake -D METEREXEC_ROOTACCESS=true . > > Where would I add this? override_dh_auto_configure: dh_auto_configure -- -DMETEREXEC_ROOTACCESS=true Do > I need to find out what dh_auto_build does > and add all this manually to my override_dh_auto_build target just to > add the single setting? The way to go with that would be for you to set DH_VERBOSE, notice *which* tool issue a particular command (in this case it's _confugure, not _build), then know that you can just append options to the command like I did above.
Re: Access to Porter machines as Debian Maintainer?
On Mon, 29 Apr 2019, 5:23 pm Hilmar Preuße, wrote: > Am 29.04.2019 um 13:41 teilte Mattia Rizzolo mit: > Yes, this is the message I got. Please be so kind to flap the value. > Done! username: hilmar-gu...@users.alioth.debian.org → hill...@debian.org Please confirm it works for you :) > >
Re: Access to Porter machines as Debian Maintainer?
On Sun, Apr 28, 2019 at 08:52:13PM +0200, Hilmar Preuße wrote: > > At this point, to actually ask access for a given porterbox you'll need > > to ask to renew your access permission. See the "Expired Accounts" > > section of https://dsa.debian.org/doc/guest-account/ - you fall into > > that one, since your account has shadowExpire=15143, which means > > 2011-06-18. > > > As said: I tried already to do that, but for any reason I get the > message that my login can't be matched to any known person, after login > into nm.debian.org using my Debian cert. > > "You are currently logged in with SSO username , but you cannot be > matched to any person in the site. > If you are already in the site, for example as a Debian Maintainer, you > can try to correct the situation using the claim interface." > > I tried already to use the claim interface, but I'm pretty sure this did > not give the expected results. Therefore I'll try to fix the match and > then try to get access to the servers as described by you above. Ah, here you are talking about the nm.d.o website. I think you have now issued a new SSO cert using your @d.o account instead of the alioth one, which is entirely fine since you have that. Currently your account on nm.d.o is matched to your alioth username; that can be changed easily - by default it sticks to the alioth username for non-DDs and the @d.o one for DDs, however it doesn't really consider guest accounts that also can use both. Am I right that the "claim" interface fails with The GPG fingerprint corresponds to a person that has a valid Single Sign-On username. ? If you confirm this is what is happening, I can easily flip the value. Anyway, this detail doesn't have anything to do with requesting access to the porterboxes, you are free to go ahead with the below. > > Just mail admin@rt.d.o, asking to grant again access to a porterbox for > > architecture X because of Y, they will re-enable your account in no > > time. > > I'll keep that in mind. Many thanks! -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Access to Porter machines as Debian Maintainer?
On Sat, Apr 27, 2019 at 11:33:53PM +0200, Hilmar Preuße wrote: > On 27.04.19 03:27, Paul Wise wrote: > > Hi, > > > Since you are not a Debian member, that address is not to be used. > > The welcome mail you got from DSA should have made that clear. > > > I'm not aware of any welcome mail I should have received. Not sure, to > which address it was sent, but the LDAP entry lists my web.de address, > which is correct. I simply noticed that my NM process (#608) was closed. I'm not sure what happened, but I'm pretty confidend that there was an account comment pointing to a very old (2011, indeed, since I also added a note with that year in the nm process) RT ticket, as well as some "allowedHost"s fields. The NM process was from dc_ga to dm_ga, we did absolutely nothing to the LDAP account (we also have no write access to it), except asking keyring maint to update the keyFingerPrint field. Most likely, you received a welcome email from DSA back on 2011, when that account was created. At this point, to actually ask access for a given porterbox you'll need to ask to renew your access permission. See the "Expired Accounts" section of https://dsa.debian.org/doc/guest-account/ - you fall into that one, since your account has shadowExpire=15143, which means 2011-06-18. Just mail admin@rt.d.o, asking to grant again access to a porterbox for architecture X because of Y, they will re-enable your account in no time. (I know rt is kinda annoying to deal with, also there were thoughts of also including this particular task of "renewing" guest accounts into NM to save you this, but it's yet there. in the meantime, here is the doc: https://wiki.debian.org/rt.debian.org#Mail_Access) -- 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: Access to Porter machines as Debian Maintainer?
On Fri, 26 Apr 2019, 4:48 am Paul Wise, wrote: > On Thu, Apr 25, 2019 at 6:11 PM Hilmar Preuße wrote: > > > Unfortunately, that does not work. Because I suspect rather an > > organizational, than a technical problem suspect, I don't post extensive > > logs. What am I missing? Do I need to be DD to login into porter boxes > > or should it be possible as DM too? > > Debian guest accounts are only allowed to access particular machines > but according to your account information in LDAP, you don't appear to > be allowed to access any Debian hosts. It looks like whoever did the > LDAP update forgot to add which machines you are allowed to access or > something. Please contact the person who requested you get a guest > account so they can follow up on the request ticket. > The problem here is that guest accounts need to be approved for each host, and the approval has an expiration (iirc it lasts 3 months by default). Now, your account was created on 2011 if memory serves right, and it expired right after, and this year we just updated the attached got key while you became a DM. So at this point you'd need to ask access to the single hosts you need; being a DM is just a trivial matter that doesn't need approval, afaik DSA just adds the bits, but will still expire at some point. (One could argue for DMs they could drop these steps, but LDAP at this time doesn't properly know about DMs..)
[ANN] mentors.debian.net upgraded to buster
Dear people,
The machine hosting mentors.debian.net has been upgraded to buster.
In the previous year we improved significantly the test coverage of the
codebase, so we don't expect many fallouts, but please report any issue
you may encounter in our issue tracker at
http://salsa.debian.org/mentors.debian.net-team/debexpo .
Also, we would like to remind you of the pending deprecation of the old
upload directory, as announced previously on this list:
https://lists.debian.org/debian-mentors/2018/02/msg00261.html ; since we
still see several uploads happening at the old location, we are going to
keep the current status quo for some more time, but please consider
updating your configuration.
Thank you for flying mentors.d.n!
- the mentors team
--
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: Where is it?
On Mon, Feb 25, 2019 at 06:44:41PM +, Popout3D wrote:
> Source package now created and uploaded successfully. If I try to
> upload it again I get this, which rather proves the point:
You should have received a rejection email:
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,157
INFO [debexpo.worker] Importing upload:
/var/cache/debexpo/incoming/pub/popout3d_1.5.0_amd64.changes
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,158
INFO [debexpo.importer.527] Changing dir to /var/cache/debexpo/incoming/
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,159
DEBUG [debexpo.importer.527] Determining user from 'Changed-By:' field: Chris
Rogers
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,385
DEBUG [debexpo.importer.527] GPG signature matches user popou...@yahoo.com
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,395
DEBUG [debexpo.importer.527] GPG signature matches user Chris Rogers
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,395
DEBUG [debexpo.importer.527] GPG signature matches user Chris Rogers
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,405
DEBUG [debexpo.importer.527] GPG signature mapped to user Chris Rogers
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,405
DEBUG [debexpo.importer.527] GPG signature mapped to user Chris Rogers
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,405
DEBUG [debexpo.importer.527] User found in database. Has id: 6834
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,406
ERROR [debexpo.importer.527] Rejected: You are not uploading to one of those
Debian distributions: bulls
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,406
ERROR [debexpo.importer.527] Rejected: You are not uploading to one of those
Debian distributions: bulls
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,407
DEBUG [debexpo.lib.email] Getting mail template: importer_reject_maintainer
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,411
DEBUG [debexpo.lib.email] Starting SMTP session to localhost:25
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,411
DEBUG [debexpo.lib.email] Starting SMTP session to localhost:25
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,425
DEBUG [debexpo.lib.email] Sending email to popou...@yahoo.com
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,433
DEBUG [debexpo.lib.email] Successfully sent
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,433
CRITI [debexpo.worker] Importer failed to import package
/var/cache/debexpo/incoming/pub/popout3d_1.5.0_
Feb 25 19:42:58 wv-debian-mentors1 python[527]: 2019-02-25 + 19:42:58,434
DEBUG [debexpo.worker] Job importuploads complete
> chris@desktop:~/debian/popout3d$ dput mentors ../popout3d_1.5.0_amd64.changes
> Package has already been uploaded to mentors on mentors.debian.net
> Nothing more to do for ../popout3d_1.5.0_amd64.changes
Incidentally, this doesn't prove anything, as that message is only
caused due to the .upload file that you have locally. See the manpage
about the -f option.
> What have I done wrong now???
According to that log, you have set a distrubtion that is not allowed.
--
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: Problems with packaging on mentors
On Fri, Feb 15, 2019 at 10:15:39AM -0300, eamanu15 wrote: > *gpgv: Signature made Fri 15 Feb 2019 10:01:57 AM UTCgpgv: > using RSA key 13796755BBC72BB8ABE2AEB5FA9DEC5DE11C63F1gpgv: Can't check > signature: No public keydpkg-source: warning: failed to verify signature on > ./hollywood_1.14-2.dscdpkg-source: error: cannot fstat file > ./hollywood_1.14.orig.tar.gz.asc: No such file or directory* > > Looking on .dsc file appear *hollywood_1.14.orig.tar.gz.asc* > But on my .changes file does not. > > How could I package it to include *tar.gz.asc on .changes file? > > Currently I am using* sbuild -s -A *to package. Add -sa (it's a dpkg-genchanges option, which is also accepted by dpkg-buildpackage and then passed on, not sure what you'd need to do to get sbuild take it.). https://salsa.debian.org/mentors.debian.net-team/debexpo/issues/51 (it's not the first time we encounter this, but I always forgot to open a bug to track its status…). -- 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 problem with an upload
On Sat, Feb 02, 2019 at 10:04:57AM -0500, Tong Sun wrote:
> Would such such upload problem affected my ffcvt package as well? --
> as Pirate has done the upload for me, but so far I haven't received
> any response for it yet either.
ffcvt is now in NEW:
mattia@coccia ~ % xzgrep ffcvt /srv/ftp-master.debian.org/log/2019-01.xz
20190125163421|process-upload|dak|Processing changes
file|ffcvt_1.3.1-1_amd64.changes
20190125163430|process-upload|dak|ACCEPT-TO-NEW|ffcvt_1.3.1-1_amd64.changes
~> https://ftp-master.debian.org/new/ffcvt_1.3.1-1.html
You should have received exactly one mail about it, and so did the ML:
https://alioth-lists.debian.net/pipermail/pkg-go-maintainers/Week-of-Mon-20190121/024742.html
https://alioth-lists.debian.net/pipermail/pkg-go-maintainers/Week-of-Mon-20190121/024743.html
If you did upload the package to mentors, indeed it most likely got
lost, but you shouldn't need to worry about it anymore, since you
already found a sponsor :)
--
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 problem with an upload
On Mon, Jan 28, 2019 at 10:48:05PM +0100, Baptiste BEAUPLAT wrote:
> We have identified a few problems with the importer. A patch is under
> review and hopefully, everything should be fixed in the next few days.
On that note, I want to thank you for you patience and I apologize for
the disruption you encountered with your uploads to mentors.
> I'll let you know.
You can follow the first step through
https://salsa.debian.org/mentors.debian.net-team/debexpo/merge_requests/33
--
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 problem with an upload
On Sun, Jan 27, 2019 at 10:12:19AM +0200, Tommi Höynälänmaa wrote: > On 26.01.2019 17:24, Mattia Rizzolo wrote: > > On Sat, Jan 26, 2019 at 04:… > > > > That said, I could find no trace of your upload, so could you please try > > uploading again? > > > > Just done. Ok, I think something broke horribly somehow but I'm not sure what nor how. It seems the importer just suddenly stuck in some kind of loop doing nothing (the log normally would update every minute) and in the meantime it also loses uploaded files. I just can't imagine how that happened, since the last time the importer was touched was on January 12, and uploads were flowing regularly... In particular, your upload also lost a file somewhere, so it couldn't be processed either… How did you do the upload? If my guess is right you uploaded via ftp, as a test could you maybe try uploading via http? TIA… I'm sorry… -- 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 problem with an upload
On Sat, Jan 26, 2019 at 04:26:49PM +0200, Tommi Höynälänmaa wrote:
> I uploaded a new version 0.7.5-2 of package theme-d-gnome about five hours
> ago but so far I haven't received any response.
I think the importer was stuck somewhere, at least the log stopped a
couple of days ago suddenly…
That said, I could find no trace of your upload, so could you please try
uploading again?
--
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: Removing a package from unstable
sounds awesome :) On Sun, Jan 6, 2019 at 10:54 PM Svante Signell wrote: > > On Sun, 2019-01-06 at 18:37 +0100, Mattia Rizzolo wrote: > > On Sun, Jan 06, 2019 at 04:41:51PM +0100, Ole Streicher wrote: > > > That is a different thing: once the dependencies on Hurd are fixed, > > > you > > > > Of course the hurd issue turned out more complex once I actually read > > past the first post, btw… > > > > > get python3-astropy back on that platform, independently whether > > > python-astropy was removed or not. If the dependencies remain > > > unfixed, I will remove python-astropy anyway at some point. > > > > sure. > > > > > But if you fix it, I can wait a while before requesting removal. Is > > > a week enough? > > > > Hardly, I don't think I can squash in also that in my schedule. > > I have preliminary patches of python-psutil for kFreeBSD now, and will > soon have patches for Hurd too. How does that sound? > -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo
Re: Removing a package from unstable
On Sun, Jan 06, 2019 at 04:41:51PM +0100, Ole Streicher wrote: > That is a different thing: once the dependencies on Hurd are fixed, you Of course the hurd issue turned out more complex once I actually read past the first post, btw… > get python3-astropy back on that platform, independently whether > python-astropy was removed or not. If the dependencies remain unfixed, I > will remove python-astropy anyway at some point. sure. > But if you fix it, I can wait a while > before requesting removal. Is a week enough? Hardly, I don't think I can squash in also that in my schedule. > > As I stated, removing from testing looks much simpler > > But it would happen automatically once the package is not in unstable, > right? Yup. My suggestion was to get it out of buster sooner, as that would "fix" the autopkgtest regression of numpy. -- 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: Removing a package from unstable
On Sat, Jan 05, 2019 at 09:24:06PM +0100, Ole Streicher wrote: > I have a source package (python-astropy) that I now want to remove from > unstable. I took care that all reverse dependencies were removed now in > recent uploads. As suggested in [1], I first issued > > $ ssh mirror.ftp-master.debian.org "dak rm -Rn python-astropy" > > to see whether it would run without errors. The output is however: […] > In total, more than 50 mpackages are listed. Many of them because of the > python3-astropy (build) dependency in hurd (which is unavoidable to > break, but that is not a release platform anyway); but also a lot of old > cruft. I though that this would be removed automatically? cruft is not automatically removed as long as it would break stuff, like in this case… You say "unavoidable", but to me it seems: * hurd is blocked because src:astropy doesn't build simply because src:python-psutil is not building which is very simply because of #676450 which has a patch for 6 years and is team maintained even! * kbsd is not building because of a known issue in src:python3.7 that misdetects the avalability of sem_open() on kbsd, but alas the kbsd porters are too few and despute knowing the issue they can't work on them; however I've also been assured that it's not that hard to fix, so I guess somebody caring enough could try spending some time on this (in which case, let me point you to James Clark, he looked a bit at the issue in the past, he could tell you where to look). > So what is the correct way now to get the package removed? You could go ahead on the bug report, listing the rdeps that you investigated and stating that you are willing to break them. However, looking at how many there are, I think that would be rude and as a supporter of the ports project I try my best to fix such issues before going the way of breaking the rdeps. At least the hurd one looks incredibly trivial to deal with from a quick glance. As I stated, removing from testing looks much simpler though: % dak rm -Rn -s testing python-astropy Will remove the following packages from testing: python-astropy |2.0.9-1 | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x Maintainer: Debian Astronomy Maintainers --- Reason --- -- Checking reverse dependencies... # Broken Build-Depends: pyregion: python-astropy veusz: python-astropy Dependency problem found. -- 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: RFS: impacket/0.9.17-1
Hi Emmanuel,
On Mon, Dec 31, 2018 at 12:11:53AM -0300, eamanu15 wrote:
> Package: sponsorship-requests
> Severity: normal
> X-Debbugs-CC: kact...@debian.org
Taking this random RFS bug as an example, please:
* don't explicitly CC anybody while sending mails to submit@, as they
will receive your mail without the bug reference, making answering
properly a mess.
This is particularly interesting since you seem to be aware of the
X-Debbugs-CC field that you use
* don't CC debian-mentors, as they are recipients of the
sponsorship-requests pseudo-package anyway, so currently
debian-mentors received double of your mails.
Thank you.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: No reply on uploading wxMaxima-18.12.0-1
On Wed, Dec 26, 2018 at 10:10:50AM +0200, Yavor Doganov wrote: > On Tue, 25 Dec 2018 22:09:20 +0200, > Gunter Königsmann wrote: > > I have uploaded the new version to wxMaxima to mentors today. At least > > dput did tell me that the upload succeeded, but it never appeared on > > mentors.debian.net. Also I didn't receive the info that the package is > > uploaded. > > I had exactly the same problem a few days ago. It seemed to resolve > by itself as the package was finally processed but it took more than > 24 hours. Like what happened a few days ago, the importer crashed. At least for me it's more helpful if people email supp...@mentors.debian.net which I tend to read sooner than debian-mentors. I restarted the importer now, and wxmaxima_18.12.0-1_source.changes is the first thing that was picked up. FTR, this is the crash: https://salsa.debian.org/mentors.debian.net-team/debexpo/issues/40 that happened for the second time the 24th, but I never saw before, and I can't connect it to any of the recent changes with did to the mentors codebase. > > A while later it seemed to have disappeared from there: dupload was able > > to upload it again. > > I was not able to upload again (with dput), so my guess is that it was > stuck in the queue for some reason. It's weird. if it was removed it means it was processed at some point… -- 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: My debian/control and possible-unindented-list-in-extended-description
On Sat, Dec 01, 2018 at 12:57:36PM -0500, Tong Sun wrote: > > contains an unindented line which starts with a dash (-) > > while my view of my lines 30 to 45 are *already* indented with a > leading space, so they are NOT unindented & starts with a dash (-) That's the "wrong" view: that single space intendation is part of the rfc822 specification for multi-line fields, and as such that space is not part of the field content. What that "intentation" is about, it's within the content of the field, which you can see as "two leading spaces" while looking at the whole file. Again, I recommend you write and propose a better wording in the form of a lintian 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: My debian/control and possible-unindented-list-in-extended-description
On Sat, Dec 01, 2018 at 12:21:17PM -0500, Tong Sun wrote: > My debian/control has the > possible-unindented-list-in-extended-description warning. > > I've checked back-and-forth several times but really couldn't figure > out where that possibility could be. Have you also read the long description of that lintian tag? mattia@warren ~ % lintian-info -t possible-unindented-list-in-extended-description W: possible-unindented-list-in-extended-description N: N: The package "Description:" contains an unindented line which starts N: with a dash (-) or asterisk (*). If this was meant to be a list of N: items these lines need to be indented (dselect would word-wrap these N: lines otherwise). N: N: Refer to Debian Policy Manual section 5.6.13 (Description) for N: details. Also please follow the Policy reference if that's still unclear (in which case, I recommend you open a lintian bug proposing a better wording once you understand). > Could somebody check it for me please? I've post it at -- > https://gist.github.com/suntong/f57cb2aeff58541ebab4f07d637ff86e Indeed lintian is right :) -- 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: Troubles with mentors.debian.net
Hi! On Wed, Nov 28, 2018 at 06:17:20PM +0100, Domenico Andreoli wrote: > The first roadblock is that I'm already registered on mentors.debian.org > as DD, from the times I was active, and now I cannot switch the role > for uploading any package. I don't understand this part, sorry. Sure, there is an account with your email, which I suppose is your account, but I don't understand what's the problem. You should still be able to login and perfectly use this. Whilst the mentors.d.n code has the idea of "roles", in the end they don't have any use and are not even exposed to the interface, so I'm at a loss to what you may mean with "I cannot switch the role for uploading any package". Could you explain in more detail what issues you are facing? (Also, for mentors.d.n support, the address is support@mentors.d.n, though d-mentors works as well if there aren't private data involved) -- 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: Closing RFS bugs
On Thu, Oct 25, 2018 at 03:03:36PM +0300, Tommi Höynälänmaa wrote:
> I have found a sponsor for my packages and hence RFS bugs #910604 and
> #910663 may be closed. How is this done or do the mentors close them?
You close them like you'd close any other bug, explaining that you found
a sponsor. Or your sponsor closes them, as that's how it is usually
done.
--
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 repository request
On Wed, Oct 24, 2018 at 01:42:00PM +0300, Yavor Doganov wrote:
> I'd appreciate if someone creates an empty gnome-mastermind repository
> at salsa.d.o and grants me (yavor-guest) commit access. This package
> has been orphaned by Bart Martens (bartm) in 2016 (#826926).
Done. https://salsa.debian.org/debian/gnome-mastermind/project_members
Please consider to use `gbp import-dscs --debsnap` for the initial
repository creation, so to have all the package's history in git.
--
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: Problem with pristine-tar (which tarball should I commit?)
On Mon, Oct 15, 2018 at 05:02:51AM -0300, Samuel Henrique wrote: > * there's no pristine-tar commit of the upstream release 3.3.1 > * there was a NMU, so the last upload was 3.3.1-1.1 > * 3.3.1-1.1 was not committed on the packaging repository > * we committed changes before making sure the git repo was up to date, > for the release 3.3.4 > > If I clone the repository and do a gbp import-dsc of 3.3.1-1.1 it mess > up the repository because it will create the commits after the 3.3.4-1 > ones in the master branch. of course... > My plan of action was: > 1) commit 3.3.1 to pristine-tar sure, and that's straightforward simple with no way it could clash... > 2) commit the changes of 3.3.1-1.1 of master on the correct place, > rewriting git history[1] why do people think about rewriting that easily... do this instead: git checkout -b tmp debian/3.3.1-1 gbp import-dsc --debian-branch=tmp ../supervisor_3.3.1-1.1.dsc git checkout master git merge debian/3.3.1-1.1 # solve your merge conflicts. I expect that you pretty much # want to keep only the changelg if that patch is already # upstream git branch -d tmp there. > 3) confirm that both the tags debian/3.3.1-1 and debian/3.3.1-1.1 > builds correclty well… not sure this is particularly useful tbh :) > The main problem is on the first step, I described the whole plan in case > anybody has a different suggestion on how to fix this but nonetheless I > would like to at least understand what is going on with pristine-tar: > > First plan was to import the github tarball of the 3.3.1 release: > wget https://github.com/Supervisor/supervisor/archive/3.3.1.tar.gz -O \ that's wrong a different level: you should strive to commit to the debian git repository what is being uploaded to the debian archive, which can easily be different than what upstream published. (even if it might be same this time). > All of this makes me think that I'm missing something very crucial > here, the possibilities I can think are: > * I should not assume that the contents of upstream and master branch > should be the same (even when using 3.0 quilt sources format) they should, but sometimes people get things wrong so they diverge… > * I'm doing something wrong when generating the tarballs of the > upstream and master branch, I highly believe this is one of the > problems regardless of anything, I think you should be using http://debian.backend.mirrors.debian.org/debian/pool/main/s/supervisor/supervisor_3.3.1.orig.tar.gz > * I should not assume that if the hash of a tarball being equal as the > one which Pristine-tar expects to is the correct one, because I > received that errors when committing the tarball from GH and it looks > like it's the one which pristine-tar doesn't complain of hash > mismatch. probably that tarball was ok, but the master branch had changed files. Have you looked at the temporary file created by dpkg-source that was mentioned in the error? That contains the list of diff that you should check. also look at the git history and see if anything was changed in the upstream files but only in the master branch. -- 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#909057: Fwd: calibre_3.31.0+dfsg-1~bpo9+1_amd64.changes REJECTED
Hi Chris :) On Tue, Sep 18, 2018 at 12:04:06PM +0100, Chris Lamb wrote: > tags 909057 - pending > thanks > > (Forwarding for completeness) > > - Original message - > From: Debian FTP Masters > To: la...@debian.org, Norbert Preining , Nicholas D > Steeves > Subject: calibre_3.31.0+dfsg-1~bpo9+1_amd64.changes REJECTED > Date: Tue, 18 Sep 2018 09:04:06 + > > > > Version check failed: > Your upload included the source package calibre, version 3.31.0+dfsg-1~bpo9+1, > however stretch-backports already has version 3.31.0+dfsg-1~bpo9+1. > Uploads to stretch-backports must have a higher version than present in > stretch-backports. Nah, it's alright, I just uploaded it 20 minutes before your mail! Sorry for clashing! -- 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#904028: RFS: freetype/2.9.1-0.1 [NMU]
Control: owner -1 !
Control: tag -1 moreinfo
On Wed, Jul 18, 2018 at 01:40:15PM +, Hugh McMaster wrote:
> I am looking for a sponsor for an NMU of the package "freetype".
o/
> dget -x
> https://mentors.debian.net/debian/pool/main/f/freetype/freetype_2.9.1-0.1.dsc
So, you made many (long overdue, IMHO) changes. Given that this is
still an NMU I'll stop my review to the debdiff from the version
currently in the archive.
* please let's upload this to experimental. If anything to check it
actually builds everywhere… We can upload a -0.2 to unstable few days
after it lands to experimental
* the version on the gettext build-dep can go away
* why did you remove the alternative dependency 'libc6-dev | libc-dev'?
the changelog doesn't mention this change, and it doesn't look so
correct to me; if somebody took the time to explicit a dependency on
libc-dev there is probably a good reason… (same for libz-dev)
* freetype2-demos lost its ${shlibs:Depends}? (also undocumented)
- and indeed it seems the built package has no dependencies.
* you moved away from dh_installdocs --link-doc. I personally like it,
because it can be source of many pitfalls, like this case: moving from
symlinks to directories requires using dpkg-maintscript-helper's
symlink-to-dir... however I'm conflicted on whether this is a change
you should do in a NMU (but then, considering the already huge
changelog…).
* /usr/bin/freetype-config is not a thing anymore, are rdeps fine?
Also, this something I'd mention in the changelog as well.
Thank you for the really thorough update, forwarding years-old patches
upstream, etc, very nice! :)
--
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#903880: RFS: pw/1.2-1 [ITP] -- simple command-line password manager
On Mon, Jul 16, 2018 at 08:57:35AM +0200, Dashamir Hoxha wrote: > I have not ignored any remarks. But a stupid question cannot have a cleaver > answer. erm… > If you are the one who makes the final decisions on Debian, then I have no > choice > but to accept your decision. But my impression is that there is no central > authority > on Debian, and a new package proposal needs just a single sponsor in order > to be accepted. Erm… You are wrong on your "impression", and I encourage you to verify your facts before sending mails to the world. *There is* an authority on the archive: that would be the ftp-masters, who can one-sidedly decide whether a package can stay in the archive. > So, I am just going to be patient until someone sponsors it. > And meanwhile I will try to avoid any stupid questions or stupid people. I find you attitude in this single email (as well in the others, but I read with enough attention only this one), very, *very* counterproductive (en_GB reading), and I urge you to change your tone if you plan on interacting with the project. And for you information, it's very rare that once a DD says a package is no good, a random other DD oversteps the former and goes ahead uploading 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: missing email after mentors upload and other problems
On Mon, Jun 25, 2018 at 01:34:53PM -0500, Matt Zagrabelny wrote:
> On Mon, Jun 25, 2018 at 1:03 PM, Mattia Rizzolo wrote:
> > Problem is that you are not uploading any source. Binary-only uploads
> > are silently discarded.
>
> What do folks think about having an autoreply email that states something
> like:
Sure, whatever the wording, but somebody needs to code it :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: missing email after mentors upload and other problems
Thnaks for CCing support@mentors.d.n. On Mon, Jun 25, 2018 at 07:07:10PM +0200, Geert Stappers wrote: > On Mon, Jun 25, 2018 at 11:08:57AM -0500, Matt Zagrabelny wrote: > > > > $ dput -f mentors cdpr_2.4-3_amd64.changes > > Checking signature on .changes > > gpg: /home/mzagrabe/git/debian/cdpr/build-area/cdpr_2.4-3_amd64.changes: > > Valid signature from 07E2BFA842A00942 > > Uploading to mentors (via https to mentors.debian.net): > > Uploading cdpr-dbgsym_2.4-3_amd64.deb: done. > > Uploading cdpr_2.4-3_amd64.buildinfo: done. > > Uploading cdpr_2.4-3_amd64.deb: done. > > Uploading cdpr_2.4-3_amd64.changes: done. > > Successfully uploaded packages. > > > > According to [0] the upload should be available between 0 and 2 minutes > > (HTTPS upload.) It has been over 10 minutes now. Problem is that you are not uploading any source. Binary-only uploads are silently discarded. You are probably using sbuild, which in its default configuration does binary-only architecture-dependand builds (i.e. -B). You usually want to perform -F builds in your local system. -- 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#898954: thank for reviewing
ore details about that repository. > 'gbp' to me sounds like Great Britain Pound, but I'm sure you don't mean > that. so I guess I've never heard about the one you mean. gbp is short for git-buildpackage (and the command line program is called `gbp`). It simplifies importing new upstream tarballs into git repositories and other stuff. https://honk.sigxcpu.org/piki/projects/git-buildpackage/ Nonetheless, you are probably better off without for now, as it's yet another tool that is true it's very handy, but it's clear that it enforces a workflow that is very different than what you are doing now. > As you surely understand and see, I'm quite new to publishing for > Debian. Yes :) But don't worry! ^^ > my focus is on developing software, and I'm now trying to get > ghini.desktop/bauble/fibra into Debian myself more of out of despair > than anything else, after so many years not managing to find anyone who > could do this, and do this properly. Let me help you and pull you out of your despair! You have clearly come a long way by yourself, and this is a tiny simple package so it's very handy to get accostumed to it. Once you get the hang of it you'll see it's nothing particularly hard by itself; alas the hardest parts are about policies and how to interact with the rest of the project... > I wrote myself a small helper script, that I hoped would allow me not > need learning anything: > > https://github.com/mfrasca/fibra/blob/master/makedeb.sh I see some big problems with that script: 1) you seem to be recreating the tarballs every single time: that's not acceptable. Once you cut a release and upload the tarball to pypi, that's it: you have to use that tarball you uploaded. Seriously different tarballs are different versions, don't mix them. 2) you call dh_make, and I can't quite understand why. You already have the packaging done in the debian/ directory, so dh_make's job is done and good, time to ditch it All in all I believe the problem you are having there is because you are mixing the upstream development with the packaging part. The usual way to deal with it by the same person is to keep the packaging part on a different branch. Let me explain a bit the workflow I recommend here; of course there are basically infinite variants, but I believe this is good enough and simple at the same time: - master branch: upstream stuff, no debian/ directory at all - hack and stuff, commits in there with upstream stuff - time to do an upstream release: bump version in setup.py, git tag, run sdist to upload to pypi - get a copy of the same tarball you uploaded to pypi in the parent directory, and name it e.g. 'fibra_0.0.20.orig.tar.gz' - `git clean -fdx` and clean it all up and checkout the 'debian' branch, which is a descendant of the master branch, but contains the debian/ directory with the packaging. This is also called "packaging branch" - `git merge v0.0.20` (or whatever you named the tag) to "import" the upstream changes in the packaging branch - `dch -v 0.0.20-1` to edit the changelog and note that you imported the new upstream release. - at this point you are able to call `debuild` and get the package built debuild will use the tarball you put in .. just before This makes possible to seperate the upstream stuff and the packaging stuff, that really needs to be separated and not mixed up. At this point, every change to the upstream stuff, will need to be made on the master branch; equivalently, anything related to the packaging, lives in the debian branch. At this point in time 0.0.20 is good as it is (ok, IMHO it has the problem of not having a changelog and that copyright thing, but those are my own opinion, and I'm not sure whether it makes sense to do a new upstream release just for that, your choice). Incidentally, uploads accepted in debian archive are usually tagged with tags named like 'debian/0.0.20-1'. -- 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#898954: RFS: python-fibra/0.0.18-1 [ITP]
Control: forcemerge -1 898773 Control: owner -1 ! Control: tag -1 moreinfo Control: retitle -1 RFS: python-fibra [ITP] On Thu, May 17, 2018 at 01:47:30PM -0500, Mario Frasca wrote: > I'm looking for a sponsor for my package 'fibra'. Hi Mario, I'll be looking at this RFS of yours, and provide a review both of your work on the workflow you seem to have employed. > It is now marked as "no" in the column "needs a sponsor", in my page > "https://mentors.debian.net/packages/uploader/mario%40anche.no";, even if > I opened bug report 898773. That's a flag you'd need to change yourself on mentors.d.n, anyway, we don't really care about that as the ones needing a sponsor need to open a RFS bug anyway. > dget -x > https://mentors.debian.net/debian/pool/main/f/fibra/fibra_0.0.18-1.dsc > > Changes since the last upload: > > I've removed all the warnings in the debuild/lintian process as far as I > could see from the machine where running debuild. You have opened two RFS bugs for the same package despite it not ever being uploaded to the debian archive. Please keep only one. I've merged them and I'm writing on the newest one just because the other has unrelated history on it. Now, I've downloaded the version 0.0.20-1 that you uploaded in the meantime, so I'll look at that. * d/changelog: + please only keep one paragarph, you should not create new paragraph until it's uploaded to the archive. Only the line with "Inital packaging" should stay. + also please use urgency=low for a new upload * d/compat: + any reason not to use the newest compat level available? See debhelper(7) for the difference * d/control: + I'm sure lintian is emitting tons of warning about this file. Have you run lintian on it? * d/fibra.1: + I understand you adopted the upstream maintenance of this package, so why not move the manpage upstream and have the upstream build system install it, etc? + at any rate, you are not providing any binary, so I can't figure what that manpage should be documenting, not to mention it's not installed anyway * d/fibra-docs.doc: + you are not building any such package, so what is this file about? + also referring a non-existing file? * d/fibra.doc-base: + likewise. And I'm sure lintian talks about this file as well? * d/README.Debian: + another contentless file?? * d/rules: + please get rid of all those uselless comments that only mkes reading of an otherwise simple rules file needlessly harder * d/copyright: + you wrote 2009 as the upstream year, but README says 2007 + I understand you did a bunch of upstream work too, but you haven't claim any copyright for it? * do you actually need to introduce the python2 package? We are going to need remove them next year or so while removing python2, so introducing a new py2 module is kind of weird When you run lintian please always run the most recent version from testing/sid if you are running buster, or from stretch-backports if you are running stretch (actually, you should be building your package in a sid chroot, it's a good habit to instruct your software to run lintian automatically inside the chroot after the build), and use the flags -Ii --pedantic to have also the pedantic tags. You also seem to not be maintaining this package in any VCS, which is considered a weird habit in this age. Have you heard about gbp? -- 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: Move packages from alioth to salsa
On Fri, May 11, 2018 at 11:55:33AM +0200, Arturo Borrero Gonzalez wrote:
> @Mattia, he seems to be looking for something similar to collab-main
> (Debian/?)
Right, key being *seems*, I'd rather not speculate :)
Also, there are conceptual differences (in particular about
collaboration that is now made clear) between collab-maint and the
salsa's Debian group:
https://wiki.debian.org/Salsa/Doc#Namespace_concepts_.28Users.2C_Teams.29
https://lists.debian.org/debian-devel-announce/2017/12/msg3.html
(stuff that you all should have read by 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: Move packages from alioth to salsa
On Fri, May 11, 2018 at 11:40:00AM +0200, Jörg Frings-Fürst wrote: > Am Freitag, den 11.05.2018, 11:34 +0200 schrieb Arturo Borrero > Gonzalez: > > On 11 May 2018 at 11:04, Jörg Frings-Fürst wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA512 > > > > > > Hello, > > > > > > please can someone move my packages from alioth to salsa. > > > My Username on both systems are jff-guest. > > > > > > > Aren't you DM? You should be if not already! Not sure if being DM > > would allow you to create salsa repos (why not?). > > > > No, I'm not a DM. And even if he was a DM, in the Debian/ group only DDs can create new repositories. Which is where I *assume* Jörg wants those repositories to be, right? You should be much more explicit in your request on where you would like things to do. -- 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 fix symbols files to work with gcc-7 and gcc-8 (Was: Bug#897794: libquazip: ftbfs with GCC-8)
On Sat, May 05, 2018 at 12:45:08AM +0200, Svante Signell wrote:
> But why log symbols at all? It
> seems to be very much not needed. If so tell me why it is!
Mainly I see two reasons:
1. being able to use properly versioned dependencies on the library
2. have a safety net against what are imho the most common ABI breaks
1: without symbols file you should take care of properly bumping the
shlibs version whenever you introduce a new symbols: in that case either
you don't know you are adding a new symbol, and so you won't bump the
shlibs version and you are going end up with a broken dependency (just
most of the times you are not going to notice it because just out of
luck you get a new enough version of the shared lib together of the
binary requiring the new symbol), or you use -V and force an overly
strict versioned dependency. Please read:
- dpkg-gensymbols(1)
- dpkg-shlibdeps(1)
- deb-shlibs(5)
- deb-symbols(5)
- dh_makeshlibs(1)
2: you'll notice ABI breaks whenever an under-diligent upstream drops a
public method —so dropping also the symbol— without changing SONAME
I personally find the second one particularly interesting: the amount of
upstreams who develop a library with the goal of providing a shared
library but nonetheless won't pose much interest and attention in proper
ABI (in particular symbols) handling is astonishing.
ABI breaks are awful to handle after they land in unstable, catching one
before can save the maintainer, release team and all the rdeps *a lot*
of otherwise wasted time and headaches.
--
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 fix symbols files to work with gcc-7 and gcc-8 (Was: Bug#897794: libquazip: ftbfs with GCC-8)
On Fri, May 04, 2018 at 02:52:30PM +0200, Andreas Tille wrote: > there are several bugs filed against packages of the Debian Med > team. Well, it's not really only about Debian Med... > What's the correct way to fix the symbols file to work > with both versions of gcc? As usual. Investigate why symbols disappear and decide what to do. In case of symbols disappearing after changing the compiler, most likely those symbols were weak and only leaked an implementation detail, and so they need to be marked as "optional". For example: [ #897794 ] > > [...] > > - (optional)_ZN5QListI16QuaZipFileInfo64ED1Ev@Base 0.7.3 > > - (optional)_ZN5QListI16QuaZipFileInfo64ED2Ev@Base 0.7.3 > > +#MISSING: 0.7.3-6# (optional)_ZN5QListI16QuaZipFileInfo64ED1Ev@Base 0.7.3 > > +#MISSING: 0.7.3-6# (optional)_ZN5QListI16QuaZipFileInfo64ED2Ev@Base 0.7.3 These are fine, dpkg-gensymbols is only being noisy here. > > - (optional)_ZN5QListI7QStringED1Ev@Base 0.7.3 > > - (optional)_ZN5QListI7QStringED2Ev@Base 0.7.3 > > +#MISSING: 0.7.3-6# (optional)_ZN5QListI7QStringED1Ev@Base 0.7.3 > > +#MISSING: 0.7.3-6# (optional)_ZN5QListI7QStringED2Ev@Base 0.7.3 > > _ZN5QListI9QFileInfoE13detach_helperEi@Base 0.7.3 > > - (optional)_ZN5QListI9QFileInfoED1Ev@Base 0.7.3 > > - (optional)_ZN5QListI9QFileInfoED2Ev@Base 0.7.3 > > +#MISSING: 0.7.3-6# (optional)_ZN5QListI9QFileInfoED1Ev@Base 0.7.3 > > +#MISSING: 0.7.3-6# (optional)_ZN5QListI9QFileInfoED2Ev@Base 0.7.3 same. > > - (optional)_ZN7QStringD1Ev@Base 0.7.3 > > - (optional)_ZN7QStringD2Ev@Base 0.7.3 > > +#MISSING: 0.7.3-6# (optional)_ZN7QStringD1Ev@Base 0.7.3 > > +#MISSING: 0.7.3-6# (optional)_ZN7QStringD2Ev@Base 0.7.3 same. Those ones probably come from a previous iteration, like gcc5→gcc6 or gcc6→gcc7. > > dpkg-gensymbols: warning: some symbols or patterns disappeared in the > > symbols file: see diff output below > > dpkg-gensymbols: warning: debian/libquazip5-1/DEBIAN/symbols doesn't match > > completely debian/libquazip5-1.symbols > > --- debian/libquazip5-1.symbols (libquazip5-1_0.7.3-6_amd64) > > +++ dpkg-gensymbolsslI1lw 2018-05-02 13:22:04.076864552 + > > @@ -74,8 +74,8 @@ > > _ZN10QuaZipFileD0Ev@Base 0.7.3 > > _ZN10QuaZipFileD1Ev@Base 0.7.3 > > _ZN10QuaZipFileD2Ev@Base 0.7.3 > > - _ZN11QStringListC1ERK7QString@Base 0.7.3 > > - _ZN11QStringListC2ERK7QString@Base 0.7.3 > > +#MISSING: 0.7.3-6# _ZN11QStringListC1ERK7QString@Base 0.7.3 > > +#MISSING: 0.7.3-6# _ZN11QStringListC2ERK7QString@Base 0.7.3 This is the actual error. |mattia@warren ~ % echo " |dquote> > - _ZN11QStringListC1ERK7QString@Base 0.7.3 |dquote> > - _ZN11QStringListC2ERK7QString@Base 0.7.3 |dquote> " | c++filt |> - QStringList::QStringList(QString const&)@Base 0.7.3 |> - QStringList::QStringList(QString const&)@Base 0.7.3 Yes, these are symbols that leaked through, so they can (and should) be marked as "optional". -- 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 fix symbols files to work with gcc-7 and gcc-8 (Was: Bug#897794: libquazip: ftbfs with GCC-8)
Yavor, On Fri, May 04, 2018 at 04:06:05PM +0300, Yavor Doganov wrote: > Andreas Tille wrote: > > What's the correct way to fix the symbols file to work with both > > versions of gcc? > > Don't use symbols files for C++ libraries? Please do not advocate nor recommend such pointless stands. Yes, C++ symbols are harder to track than C symbols. Yes, C++ symbols handling requires more work than doing C symbols. Yes, many C++ libraries do a very horrible job at ABI maintenance that for them maintaining a symbols file is impossible. No, it's not impossible to maintain a symbols file for a C++ library. Yes, for decent libraries it's totally feasible also for mere humans. Guess what, C++ is more complex than C. -- 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: ed25519 keys and mentors.d.n
On Sun, Apr 08, 2018 at 04:41:32PM -0600, Daniele Nicolodi wrote: > I just tried to upload a package to mentors.debian.net and it got > rejected because is is signed with an ed25519 key: > > gpg: Signature made So 08 Apr 2018 22:00:14 UTC using ? key ID C18A4F7D > gpg: Can't check signature: unknown pubkey algorithm > > I guess the infrastructure has not been upgraded to GnuPG 2. Yes, when we upgraded the host 1,5 months ago we tried also moving to gpg2, but that wasn't as straightforward as we'd hoped… So, we've installed gnupg1 and changed the binary used. Patches welcome, as usual :) > Does this limitation apply only to > mentors.d.n or does it apply to the Debian infrastructure in general? Each service it's on his own in Debian. dak works with gpg2, but apparently debvotee uses gpg1, etc 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: cmake packages fail to build since yesterday even if package has build before
On Sun, Apr 08, 2018 at 10:25:44AM +0200, Andreas Tille wrote:
> since yesterday packages using cmake are failing.
> Nothing inside libbpp-seq was changed that should affect the build
> process. I have the same problem with other cmake based packages.
>
> Any clue what might go wrong here?
Debhelper did a bit of a refactoring of the cmake build system, and here
you have a debhelper bug :) https://bugs.debian.org/895181
--
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.cf WAS: Upload failed: 301 Moved Permanently
On Wed, Mar 21, 2018 at 12:31:39AM +0100, Georg Faerber wrote:
> I've to admit: I'm not really getting your point, Mattia.
Like I said in my first post¹, just to fulfil my curiosity.
As an admin of mentors.d.n (and as a chronically lazy person) I'm
curious as to why anybody would go to the extra length of using a local
configuration when both dput and dput-ng ship with good enough default
one.
Nothing more, really.
¹ https://lists.debian.org/debian-mentors/2018/03/msg00268.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: .dput.cf: File contains no section headers.
On Tue, Mar 20, 2018 at 11:54:47PM +0100, Geert Stappers wrote:
> On Tue, Mar 20, 2018 at 06:48:47PM +0100, Elimar Riesebieter wrote:
> > Read 'How to upload packages to mentors.debian.net?' at [0].
> >
> > [0] https://mentors.debian.net/intro-maintainers
> >
>
> Euh ... that is also '.ini' format.
> Over here I have dput-ng with documention saying I should
> provide JSON, so I did.
>
> Got parse error ".dput.cf: File contains no section headers."
>
> | stappers@bob:~/src/foo-pkg/foobarbaz$ dput ../foobarbaz.4.0-1_armhf.changes
> | Error parsing file /home/stappers/.dput.cf: File contains no section
> headers.
> | file: /home/stappers/.dput.cf, line: 1
> | '{\n'
> | stappers@bob:~/src/foo-pkg/foobarbaz$ which dput
> | /usr/bin/dput
> | stappers@bob:~/src/foo-pkg/foobarbaz$ dpkg -S $( which dput )
> | dput-ng: /usr/bin/dput
> | stappers@bob:~/src/foo-pkg/foobarbaz$
>
>
> Using '.ini' format got it working.
>
> Content is as at [0]
Please don't ignore my emails.
https://lists.debian.org/debian-mentors/2018/03/msg00270.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: .dput.cf WAS: Upload failed: 301 Moved Permanently
On Tue, Mar 20, 2018 at 06:50:27PM +0100, Georg Faerber wrote: > > Questions, just to fulfil my curiosity: > > 1) why do you prefer https over ftp? > > That's not a sign of my preference. I've just changed this ~ one > week ago, because uploads weren't possible anymore. I've read the > announcement regarding the change of the incoming directory, but > changing 'ftp' to 'https' just worked. I didn't dig to find [1], but now > I did.. :) "one week ago" doesn't match anything that happened on mentors. The change we made about the *recommended* ftp upload path (i.e., the old one should work just fine) have nothing to do with the http upload method. What changed, back the 2018-02-23, is that before there was a redirect from http to https for everything except /upload, whereas now we accidentally moved to redirect everything *including* /upload. Apparently there was a reason for that exception that was accidentally dropped, but I believe moving to https is fine, and things seem to work just fine after s/http/https/ so I'd rather not add that exception anymore. FWIW: https://salsa.debian.org/mentors.debian.net-team/debexpo/compare/168425582bd76f23ad5f0763d55a24ef50f6c0d2...dd753d68f1a7adb72268dfc2b9b0fbcf57df64a6 > > 2) are you aware that both dput and dput-ng ships with a default > >'mentors' profile to upload through ftp? > > Yes, thanks. Then, especially after you switched your local user configuration to use ftp so it's basically the same as the one shipped by dput, why aren't you using 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: .dput.cf WAS: Upload failed: 301 Moved Permanently
On Tue, Mar 20, 2018 at 06:42:40PM +0100, Geert Stappers wrote:
> Why the ".ini format"?
> At http://dput.readthedocs.io/en/latest/reference/configs.html#practice is
> JSON ...
That's docs for dput-ng, not dput.
If you have dput-ng installed, like I think you do, read dput(5) for
more information on the configuration formats supported by dput-ng.
--
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.cf WAS: Upload failed: 301 Moved Permanently
On Tue, Mar 20, 2018 at 06:23:36PM +0100, Georg Faerber wrote: > On 18-03-20 18:12:36, Geert Stappers wrote: > > And what is now the content of you .dput.cf ? > > > > Yes, I'm looking for working .dput.cf > > [mentors] > fqdn = mentors.debian.net > incoming = /upload > method = https Questions, just to fulfil my curiosity: 1) why do you prefer https over ftp? 2) are you aware that both dput and dput-ng ships with a default 'mentors' profile to upload through ftp? -- 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: moving teams to salsa
On Thu, Mar 15, 2018 at 10:44:16AM +, Gianfranco Costamagna wrote: > 1) I can't create new teams teams are created through signup.salsa.d.o > 2) I don't know how to move the lists See https://wiki.debian.org/Alioth/#Mailing_lists > 3) I lack the time to find/look for the documentation (and I lost it) https://wiki.debian.org/Salsa/Doc > 4) I need some "import git repo" link, because uploading a git repo from > scratch from my laptop will > takes days, specially for virtualbox-guest-additions-iso and vbox team > packages. Ever noticed the "import" feature of gitlab? But that may timeout quite quicker anyway. Though you could push directly from alioth (just temporarly add a ssh key from alioth). Anyway, see 3. > Is anybody willing to point me some wiki and help in doing the migration? not me, sorry! -- 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: dch "eating" changelog entries?
On Mon, Mar 05, 2018 at 10:44:13PM +0100, Sven Hartge wrote:
> I am co-maintaining bacula with Carsten Leonhardt and this problem now
> occured several times for me. (Most probably because of misuse by me,
> but I want to understand what went wrong.)
…
> Note how the last entry is unfinished, because of ongoing development.
> When I now call "dch" to add another entry, the editor looks like this:
…
> dch of course complains loudly:
Bug: https://bugs.debian.org/784397
--
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
