Re: Difference between "python-debian team" and "Debian Python Team"

[Mattia Rizzolo]

On Fri, Oct 01, 2021 at 10:38:34AM +, c.bu...@posteo.jp wrote:
> what are the differences between this two salsa groups?
> 
> https://salsa.debian.org/python-team
> 
> https://salsa.debian.org/python-debian-team

This second one is specific for this one package and only that:
https://tracker.debian.org/pkg/python-debian


The first one (python-team) is probably the one you are looking for.

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://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: Fwd: keyman-config is marked for autoremoval from testing

[Mattia Rizzolo]

On Tue, Sep 28, 2021 at 05:06:01PM +0200, Eberhard Beilharz wrote:
> I got the email below which I don't understand. /keyman-config/ doesn't
> have any -dbg packages AFAICT.

Indeed, the mail says that *python-gevent* has such -dbg package, and
you depend on it.

> So - what do I have to do?

I suppose in this case it's easier to just wait for gevent's maintainer
to fix it.

I don't think you need to worry of this not happening in time for the
bookworm 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: Moving forward with more Python 2 removal, plus upgrading to markupsafe 2.0, jinja2 3.0, werkzeug 2.0 and flask 2.0

[Mattia Rizzolo]

On Sat, Sep 18, 2021 at 03:02:01PM +0200, Thomas Goirand wrote:
> During the python BoF of the last Debconf, we decided to go ahead with
> full removal of Python 2, so doing this looks like a move to the right
> direction.

Yes indeed.

> Is it fine for everyone (including Piotr, who's the only marked uploader
> for these) if I upload these to Experimental right now (which is where I
> am uploading OpenStack Xena), and in Unstable after the 8th of October
> (when OpenStack Xena will be finally released)?
> 
> I'm also aware that the packages I mentioned above are high profile (ie:
> used a lot in Debian), which is why I thought announcing my plan was a
> good idea (also so that Piotr can tell his opinion).

Sounds a sound plan to me, however please remember to check the
pseudo-excuses-experimental here before moving to unstable, to at least
fix whatever autopkgtest breaks before said breaking upload.
https://release.debian.org/britney/pseudo-excuses-experimental.html

That ought to prevent plenty of headaches we would otheriwse have.

-- 
regards,
    Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://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: Fwd: My deep mistake with the python-absl package

[Mattia Rizzolo]

Hi Arturo,

On Mon, Apr 19, 2021 at 03:46:55PM +0500, Andrey Rahmatullin wrote:
> On Mon, Apr 19, 2021 at 11:12:01AM +0200, Arturo Borrero Gonzalez wrote:
> > * We could upload a new version of python-absl and just replace/overwrite my
> > upload. I noticed your original repo [0] contains a pretty up-to-date
> > version that could work.
>
> I'm not the package maintainer but I'd suggest either rolling back to the
> contents of 0.11.0-1 (pro: we are frozen; con: unlikely that the second
> upload breaks anything as the package is not in testing and doesn't have
> revdeps) or just uploading 0.12.0-2 based on 0.11.0-1, integrating
> improvements from 0.12.0-1 if needed.
> There is also a question of the salsa repo history, not sure if it should
> contain 0.12.0-1 or not (pro: having all versions in the repo, no
> confusion over the missing version; con: confusion over two uploads each
> rewriting the previous one).

If you are fine, I can take this approach.  I'll include your 0.12.0-1
upload in the repository, merge them both, give back maintership to the
DPT and whoever was in Uploaders, and upload the final as 0.12.0-2.  I
don't think there is any gain whatsoever in rolling back to 0.11.0 at
this point.
Lastly, I'll ask the salsa admins to remove the repository you created
in the /debian/ space.

If you are interested in this package I recommend you join the DPT then
:)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://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#938076: python-pymetar: Python2 removal in sid/bullseye

[Mattia Rizzolo]

On Sat, Feb 06, 2021 at 08:37:45PM +0100, gregor herrmann wrote:
> > Find attached the full debdiff and the filtered debdiff with only the
> > debian/* files.
> > 
> > I tried to find a balance between doing all necessary changes and not
> > completely overhauling the packaging. It seems that the resulting
> > binary package works, both the commandline script and the module in
> > ipython3, but as I'm not a python person I'd welcome reviews and
> > suggestions for improvement.
> 
> I don't feel confident uploading this NMU myself but I'd like to see
> python-pymetar in bullseye.

Very quickly looking at the filter diff for debian/*, that looks just
fine.

But it's too late for bullseye.  Without an autopkgtest (which I'm not
going to write myself not knowing the package), this will go over the
12th, and as such won't be due to the freeze policy.

> Is this something the Debian Python Team could take over?

I'll keep a tab open to review and sponsor the nmu (but anybody feel
free to beat me).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: Policy proposal: Consistent use of UNRELEASED in debian/changelog

[Mattia Rizzolo]

On Sun, Sep 27, 2020 at 08:07:29PM -0400, Louis-Philippe Véronneau wrote:
> The problem this tries to solves is inconsistent use of UNRELEASED in
> debian/changelog. Some people do not use it at all, and it can make
> working on team packages harder.
> 
> Indeed, if you try to modify a package, if people don't use UNRELEASED,
> you first need to check if the current VCS version has been uploaded to
> the archive or not. This complicates the life of people doing mass
> updates, as they can't rely on packages with `unstable` having been
> uploaded.

I just want to point people towards the fact that the Janitor's is now
being clever about recognizing whether a package is using `gbp dch`
(which I believe is the case you refer to when you say that UNRELEASED
is not used), or changelog entires are added whenever a change is done.


That said, I acknoledge that it makes sense to converge on a single
solution for the whole team, and honestly I don't have much of a strong
preference towards either one.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: Move python-libusb1 from NEW/Unstable

[Mattia Rizzolo]

On Sat, May 23, 2020 at 05:03:50PM -0700, debianb...@felinefamily.org wrote:
> The package maintainer, Arnoud Fountaine uploaded the fix to the last
> bug a week or so ago but it’s been stuck in the NEW queue ever since.
> Is there anyone that can approve it so it can get moved to Sid

NEW is a manual process from the ftp-team.
It can take from a few hours up to months, and it's not really something
that can be prodded just to have a quicker backports.
The queue is processed in a non specified order, and you can see it
here: https://ftp-master.debian.org/new.html

*Usually* (not always!), if it's a small packages it is processed quite
quickly, but poking the ftp team before not even a month has passed
without a good reason (for example, it's blocking an RC bug fix) is just
inappropriate.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: py2removal: drop python-pytest by not running tests for python2 packages

[Mattia Rizzolo]

On Mon, Apr 13, 2020 at 12:22:21PM +0300, Dmitry Shachnev wrote:
> On Sun, Apr 12, 2020 at 11:05:13PM -0400, Scott Kitterman wrote:
> > On Sunday, April 12, 2020 9:56:01 PM EDT Sandro Tosi wrote:
> > > so i was playing with the idea of tackling python-pytest removal by
> > > updating all its rdeps and not run unittests for the python2 binary
> > > (so dropping pytest and the other b-d* only used for tests).
> >
> > Go for it.
> 
> +1 from me too.

Yeah, +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: RFS: PAPT: gui-ufw 20.04.1-1

[Mattia Rizzolo]

On Sun, Feb 16, 2020 at 11:56:08PM +0100, Devid Antonio Filoni wrote:
> please, could a DD take in care my request?
> 
> https://salsa.debian.org/python-team/applications/gui-ufw

I'm sponsoring this, however please consider writing a DEP-5 copyright
for it.

o/

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://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: Force pushing on salsa?

[Mattia Rizzolo]

On Tue, Feb 11, 2020 at 11:34:23AM -0500, Louis-Philippe Véronneau wrote:
> Looking at a package recently, I saw some important mistakes and I was
> wondering: would it be ok to force push to fix them?
> 
> More explicitly, the import of the new upstream version with
> pristine-tar contains a bunch of errors due to a wrong manipulation. It
> seems to me it would be "more clean" to start again and force push.
> 
> I know force pushing is normally frowned upon when working in a team
> environment, but I haven't seen any mention of it in the Python Team's
> policy.

Let me keep frowing deeply.

If pristine-tar data is corrupted, just use
% pristine-tar commit ../foo_1.2.3.orig.tar.xz upstream/1.2.3
to update the data, without force-pushing.  It's just one extra commit,
so why would that be "less clean"?!


The only thing I could *very frowingly* accept, is force-pushing a tag
because you are doing it again.  Having said that, I usually just append
a number if I need to re-repack again an upstream tarball (+dfsg1,
+dfsg2, etc).  But you mentioned only pristine-tar, so I suppose that's
not your 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: Separate lib and executable packages?

[Mattia Rizzolo]

On Fri, Feb 07, 2020 at 11:36:00AM +, Gordon Ball wrote:
> I wonder if this split really makes sense; it feels like adding the
> overhead of an extra binary package to avoid not having a very small
> file in /usr/bin if you're only planning to use the library.
> 
> Does it seem reasonable to drop the executable package and just make it
> a Provides: of the library package? (and is there any potential breakage
> here that I'm overlooking)


Maybe not for ipython3, since that's very much tied to python3-ipython3.

BUT, as a user (even forgetting I'm also a DD) I was hurt many times by
executables in python-foo but wanting to use python3-foo instead, or by
executables that moved from python-foo to python3-foo and I had to fix
my own deployments, and whatnot.

We are not going to have a python4 anytime soon (hopefully never), but I
think that keeping a separate binary package makes sense for almost all
cases I can think of packages shipping executables under /usr/bin/.

-- 
regards,
            Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://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: Non-migration of cssutils

[Mattia Rizzolo]

On Thu, Feb 06, 2020 at 12:29:08PM +0100, Martin wrote:
> If calibre gets removed from testing on 2020-02-16, the reason
> for non-migration of cssutils and removing depending packages
> from testing, e.g. gajim, vanishes. Will this work out due to
> britneys wisdom? Or should calibre better removed from testing
> before 2020-02-16, if problems are not fixed until then?

Given that the whole stack of packages is scheduled to get out on
2020-02-16, it's more likely that everything will be removed, and then
cssutils will migrate back (and with it everything that will be suitable
to migrate back into testing) at the next britney run.

If fixing those FTBFS is not on the table, I think you could just let it
be, and have it go out and then back in.  Tricks like pinging the bug to
delay the autorm will likely backfire since it might very well be that
very same bug that is also removing calibre.  At the same time,
bothering the release team for such minor matters feels somewhat
exaggerated.

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://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: Non-migration of cssutils

[Mattia Rizzolo]

On Thu, Feb 06, 2020 at 12:00:36PM +0100, Martin wrote:
> at https://tracker.debian.org/pkg/cssutils I don't see,
> why the package does not migrate. Some package depend on
> cssutils and will be removed from testing soon...
> 
> Any idea what's wrong with cssutils?

https://release.debian.org/britney/update_output.txt

trying: cssutils
skipped: cssutils (2, 1, 136)
got: 20+0: a-2:a-0:a-0:a-0:i-17:m-0:m-0:p-0:s-1
* amd64: calibre


That means that migrating cssutils would break calibre.
Probably because the version of calibre in testing is the python2 one,
and cssutils dropped its python2.
calibre from unstble is not migrating because of missing builds in arm64
and mipsel.

I reckon the way forward is to fix those two FTBFS in calibre.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: python-requests: adding a documentation package python-requests-doc

[Mattia Rizzolo]

On Tue, 31 Dec 2019, 7:42 pm Daniele Tricoli,  wrote:

> Hello Fabrice,
> thanks for pinging I did not notice the MR :(
> Please next time can you assign it to me? I should reveive some sort of
> notification I hope! :)
>

I recommend you enable notifications for all packages in you are interested
in, by setting the notification switch on salsa to "watch".
Otherwise, you could get into the habit of scrolling through your ddpo page
every so often anche check the VCS column (but there is a huge delay as
iirc salsa is queried once a week for MRs).


>

Re: Help with interpreting piuparts error

[Mattia Rizzolo]

There was a temporary bug in piuparts (after a migration from py2 to py3).
The bug has been fixed yesterday, and failed tests will be retried
automatically after a time.

There are probably hundreds of failed tests like that.

On Mon, 30 Dec 2019, 4:15 am Chow Loong Jin,  wrote:

> On Mon, Dec 30, 2019 at 01:49:12AM +0100, Martin wrote:
> > Hi,
> >
> > I'm not sure how to interpret this 14799 lines piuparts log:
> >
> https://piuparts.debian.org/sid/fail/python-aiohttp-session-doc_2.9.0-2.log
> > It says "ERROR: FAIL: Installation and purging test."
> > Any idea what's wrong with the package? TIA!
> >
> > Cheers
>
> Try searching for the line "0m28.7s ERROR: FAIL: After purging files
> have disappeared:" and viewing the stuff around that part of the log
> file.
>
> I'm not sure what the issue is exactly, but it does sound related to the
> failure in question.
>
> --
> Kind regards,
> Loong Jin
>
>

Re: Severity bump script

[Mattia Rizzolo]

On Mon, 2 Dec 2019, 10:25 pm Paul Gevers,  wrote:

> Hi,
>
> On 02-12-2019 22:15, Sandro Tosi wrote:
> > the blocks are only between py2removal packages, so if a package
> > un-related to the py2removal effort
> > depend/recomments/b-deps/autotest-triggers a py2removal *application*,
> that
> > is still considered a leaf package
>
> You'll fix that, right? Because why would the tree stop at Python? A
> leaf package is a package without Depends/Build-Depends in Debian.


Because the python2 removal is about python2.  If you depend on a python2
package then the dependant application needs to likewise be dropped or
updated, but it also is at the same time somewhat out of scope from "us".

So it's either file py2removal bugs also against packages that don't depend
on python, but just use an application that happens to use python2, or the
current status quo.
That's my take at least.

Also, I am one of those that think we should be much more forceful, and the
current situation looks just fine for me, so I might be biased.

Re: Bug#945775: python-sponge: should this package be removed.

[Mattia Rizzolo]

Control: reassign -1 ftp.debian.org
Control: severity -1 normal
Control: retitle -1 RM: python-sponge -- RoQA; RC buggy, unmaintained, low 
popcon


On Thu, Nov 28, 2019 at 01:33:25PM +, peter green wrote:
> To me this adds up to a package that is not in a fit state to remain
> in Debian, if noone disagrees I will likely convert this bug to a
> removal request in the not too distant future.

Sure, let's do this already!

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: getmail: Python2 removal in sid/bullseye

[Mattia Rizzolo]

On Wed, Nov 13, 2019 at 12:37:27AM +0900, Osamu Aoki wrote:
> Upstream is active and prides to keep python 2.5 compatibility code in
> it ... (Not just 2.7).  I (Osamu Aoki ) and dkg even
> made some effort to support both 2 and 3 but the idea was rejected by
> upstream in 2018.  (Then we both lost motivation since upstream will not
> include such code in near future)
>   https://marc.info/?l=getmail=151542515929707=2
> 
> The upstream is somehow convinced that python2 will be there for some
> time (Year ~2020 and later).
>   https://marc.info/?l=getmail=151542154628352=2

uh. meh.

I haven't looked at the code, but if you made the effort, how improbable
would it be for you to just keep the patches for py3 support yourself in
the packaging for the time being?

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: What is the process to update the DPMT and PAPT policies?

[Mattia Rizzolo]

Hi,

On Mon, 16 Sep 2019, 1:59 am Louis-Philippe Véronneau, 
wrote:

> What is the process to update the DPMT and PAPT policies? I feel the
> DPMT policy is pretty good and I feel the PAPT policy could copy a bunch
> of stuff from there.
>

I wonder, I think the historical reasons for papt and dpmt to be separated
don't quite stand anymore.  Perhaps the only difference left is the actual
technical difference between an application and a module as described in
the python policy (rather in the team one).

Could this be a good moment to make the two policies totally converge, and
actually merge them into a single "python team policy"?

Perhaps in a near-ish future the two "sub-"teams could even be merged?

>
>

Re: Packages depending on python-testtools are now RC: is bzr still a thing?

[Mattia Rizzolo]

Considering that this is bzr we are talking about, a package that is
already entering the graveyard, I think it would be easiest to just disable
the test suite and move on.

But I would be happier it Thomas at least checked the rdeps before dropping
packages, at least evaluating if breaking things is alrightif he really
likes to break packages :/


On Sun, 15 Sep 2019, 11:09 am Jelmer Vernooij,  wrote:

>
>
> On 15 September 2019 01:15:11 CEST, Scott Kitterman 
> wrote:
> >On Saturday, September 14, 2019 6:43:13 PM EDT Thomas Goirand wrote:
> >> Hi,
> >>
> >> As I wrongly thought python-extras was used only by OpenStack stuff,
> >I
> >> removed Python 2 support for it. Then someone filed a bug against
> >> python-testtools (ScottK, I believe) saying that it became RC.
> >> Therefore, I went ahead and removed Python 2 support for testtools,
> >but
> >> now, this implies that a few packages which I didn't wish to impact
> >are
> >> also RC:
> >>
> >> * bzr-builddeb
> >> * bzr-email
> >> * bzr-fastimport
> >> * bzr-git
> >> * bzr-stats
> >> * bzr-upload
> >> * loggerhead
> >>
> >> So, basically, unfortunately, Bazaar has lost some of its build
> >> dependencies.
> >>
> >> So, I went ahead, and looked what I could do for Bazaar.
> >Unfortunately,
> >> when looking at:
> >> https://launchpad.net/bzr
> >>
> >> I can see no release since January 2016, no daily archive. The last
> >> commit in the bzr repository of bzr is from 2017-03-17.
> >>
> >> Then I went to see how much Python 3 effort would be needed, and I
> >> quickly gave up. It'd be A LOT of work, but nobody seems doing ANY
> >work
> >> on bzr anymore.
> >>
> >> So I wonder: is it time to remove bazaar from Debian? Or is there any
> >> vague plan to make it work with Python 3? If we are to remove it from
> >> Debian, then we'd better do it ASAP.
> >
> >As I understand it, bazaar (bzr) is dead and being replaced by breezy
> >(brz),
> >which is python3 compatible.
> >
> >https://www.breezy-vcs.org/
> >
> >My inference is that anything bzr specific can go, but I'm not involved
> >in
> >either project.
>
> Bzr maintainer / breezy upstream here.
>
> I'm planning to upload transitional packages to trigger upgrades from bzr
> to Breezy.
>
> The packages for that are not ready yet though. Can we undo the dropping
> of python-testtools in the meantime?
>
> Jelmer
>
>

Re: Removing py2 support from python-xattr

[Mattia Rizzolo]

On Sat, Aug 24, 2019 at 08:03:55PM -0400, Scott Kitterman wrote:
> On Saturday, August 24, 2019 6:28:10 PM EDT Thomas Goirand wrote:
> > Please, let's generalize and see the whole picture. There will be A LOT
> > more cases like this one, and I don't think that waiting forever will
> > solve the situation. It is my opinion that we should set a kind of
> > policy (ie: wait for how long?) and then act...
> 
> If it were me, I'd go ahead and file a serious bug indicating a dependency of 
> the package is about to be removed.

And then, once it is autorm from testing without the maintainer saying
anything, open an RM bug for the rdep.

-- 
regards,
    Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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: Request for sponsor: pytest-bdd

[Mattia Rizzolo]

On Mon, Aug 05, 2019 at 02:18:18PM -0400, Scott Talbert wrote:
> Are you sure that it uploaded successfully?  I haven't seen any messages
> about upload being accepted and I don't see anything on the tracker.

The upload was successful, but dak is broken at the moment, it hasn't
processed any upload since ~11:20 AM UTC today.

-- 
regards,
    Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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: Request for sponsor: pytest-bdd

[Mattia Rizzolo]

Hi,

On Fri, Jul 26, 2019 at 10:05:34PM -0400, Scott Talbert wrote:
> I did a major update for pytest-bdd (new upstream release, dropped py2
> packages, other lintian fixes, etc.).  Does someone mind uploading it?
> 
> https://salsa.debian.org/python-team/modules/pytest-bdd

Uploaded!

Just, please do not push debian/ tags unless you are completely sure
that's what is going to be uploaded.
In this case I would have liked to run wrap-and-sort, and add a R³
header, but hold back just for 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: Use debhelper-compat instead of debian/compat

[Mattia Rizzolo]

On Mon, Jul 22, 2019 at 12:53:23PM +0200, Andreas Tille wrote:
> I wonder whether this is safe for backports and backports-sloppy.

Yes, stretch-backports already supported it, so clearly buster-bpo and
stretch-bpo-sl support 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: Dropping Python 2 support for web.py before buster

[Mattia Rizzolo]

while doing that, remember to file a RC bug against rebuildd, since it
won't be installable anymore and it will need to be removed from
testing.

On Tue, Jan 22, 2019 at 11:31 PM W. Martin Borgert  wrote:
>
> On 2019-01-22 15:02, Julien Danjou wrote:
> > I'm not actively maintaining rebuildd for years now. I'm not even sure
> > it has still any user. I wouldn't spend time on porting rebuildd nor I
> > would let it block it updating web.py.
> > Not sure what's the other solution would be (removal?) but if you have
> > any idea, go ahead.
>
> OK, I'll upload web.py without Python 2 support then.
> If someone has strong interest in rebuildd, they has to make a
> Python 3 version anyway. If the package is not in buster, there
> can still be a backport.
>
> Thanks for your input, Julien, Julien, and Mattia!



-- 
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: Dropping Python 2 support for web.py before buster

[Mattia Rizzolo]

On Tue, Jan 22, 2019 at 12:18:09PM +0100, W. Martin Borgert wrote:
> I'm going to package the latest git master of web.py¹, because of
> Python 3.7 compatibility. It has a new dependency on cheroot², which
> has only a Python 3 version in Debian. I could ask Julien to provide a
> Python 2 package of cheroot for buster, but I prefer to drop Python 2
> support of web.py instead. Any opinions?

I would say "go for the drop!!!" if not for the presence of a reverse
dependency of the python2 package (rebuildd).  So IMHO the best would
be:
 * port rebuildd to py3
 * drop the py2 package

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: [RFC] Dropping Python2 support for my package

[Mattia Rizzolo]

On Sat, Jan 12, 2019 at 04:39:44PM +0100, Bastian Venthur wrote:
> > just drop the python-debianbts binary, without doing any kind of
> > strange migration, and keep the name python-debianbts for the
> > python3 package, as the Debian Python Policy states.
> 
> I think there's an error in your advice and I can't figure out what
> you mean. You're suggesting to drop *and* to keep the python-debianbts
> package :) Can you please clarify?

Yes, I made an error there indeed (that I think Andrey corrected
already).  But let my try again:

just drop the python-debianbts binary, without doing any kind of
strange migration, and keep the name python3-debianbts for the
python3 package, as the Debian Python Policy states.

As Andrey wrote, don't touch the source package name either.


Sorry if I spread confusion accidentally…

-- 
regards,
    Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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: [RFC] Dropping Python2 support for my package

[Mattia Rizzolo]

On Sat, Jan 12, 2019 at 04:28:26PM +0100, Bastian Venthur wrote:
> The question is: if I drop Python2 support, what
> happens with the package names? Should I simply provide the
> python3-debianbts and drop python-debianbts, or shall I attempt some
> kind of migration to make the python-debianbts the new default package
> name for Python3?

just drop the python-debianbts binary, without doing any kind of strange
migration, and keep the name python-debianbts for the python3 package,
as the Debian Python Policy states.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: Mass commit: Rename d/tests/control.autodep8 to d/tests/control

[Mattia Rizzolo]

Go for it!
(I just hope that you check for any conflicting d/tests/control before
moving that file over)

On Mon, 7 Jan 2019, 9:42 p.m. Ondrej Novy  Hi,
>
> because of:
>
>- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908272
>-
>
> https://salsa.debian.org/ci-team/autodep8/commit/8b355f6128bffe58d2246e9d52435a81816dda5c
>-
>
> https://salsa.debian.org/lintian/lintian/commit/b9a7ca6d2701dc01e4745774597a5860a7b605e5
>
>
> I would like to mass commit that change in our Salsa repositories.
>
> Example:
>
> https://salsa.debian.org/python-team/modules/python-flake8/commit/9fc14c64a56a2e90bf6d4a35764fdd803e0e4285
>
> Any thoughts?
>
> Thanks.
>
> --
> Best regards
>  Ondřej Nový
>
> Email: n...@ondrej.org
> PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Numpy migration?

[Mattia Rizzolo]

On Sun, Jan 06, 2019 at 06:19:15PM +0100, Steffen Möller wrote:
> > The reverse build deps of python-astropy in testing are pyregion and
> > veusz. Veusz has the build-dep removed in unstable, but didn't migrate
> > since 192 days.
> This is because it does not build on arm64 and others 
> (https://buildd.debian.org/status/fetch.php?pkg=veusz=arm64=3.0-1=1530124204=0)
> - also because of some Numpy issue if I get this right:

Looks so indeed.  However it builds on reproducible (on arm64), and the
error is the same on mips and mips64el, so I asked for the build to be
retried.
However there is after that a different RC bug (that I can fix once the
build is confirmed to be fixed 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: Numpy migration?

[Mattia Rizzolo]

On Sat, Jan 05, 2019 at 08:30:28PM +0100, Ole Streicher wrote:
> >> Python-astropy is however going to be removed completely; it has
> >> however some cruft rdeps left in unstable. So, it cannot removed from
> >> unstable now, and therefore still remains in testing and
> >> (unnecessarily) blocks the numpy migration.  Python-astropy already
> >> has an RC bug, but its autoremoval from testing is still not even
> >> announced yet.
> >
> > Maybe you could ask the release team to hasten the removal of
> > python-astropy and rdeps from testing?  If the plan is to not relase
> > it in buster I don't see a reason to keep it further.
> 
> Couldn't we just also add a "breaks" to numpy? The important fact here
> is, that the new numpy and the current python-astropy don't work
> together; and this is independent of whether a fixed python-astropy
> version exists.

That wouldn't quite work, as without a working version of python-astropy
it would unilateraly block the migration of numpy as long as
python-astropy is in testing.

> This would remove one dependent party (release team) from the chain of
> blocking causes for the migration.

Given your email on -mentors a few minutes ago I see there are troubles
on removing python-astropy from unstable (I'll reply to that in a bit),
but for testing is quite easy.
Just file a bug against release.debian.org asking to remove it from
testing, and one against python-astropy at RC-level with "not release
with buster", and it will be out of testing beofore you even notice.

> >> The migration blocking CI tests seem to cause much more headaches than
> >> just "fix your bugs"...
> >
> > Well, from what I see, it has helped a lot in this half a year detect a
> > ton of regressions that would have otherwise bothered several people in
> > a later moment…
> 
> I usually regularly look into my packages and file bugs if a CI test
> fails caused by a buggy updated dependency. This works well without the
> need of blocks. It would also work, when a failing CI test would
> automatically trigger a bug report against the updated package, which
> then could be re-assigned to the rdep in case the problem was there.

There is elbrus that does that regularly (Except these last few weeks
when it was on vaction).  I think he said complete automation would miss
too many things that he is filtering out by hand for 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: Numpy migration?

[Mattia Rizzolo]

On Sat, Jan 05, 2019 at 04:15:04PM +0100, Ole Streicher wrote:
> There is one more problem, which are transitional dependencies:
> 
> The new python3-numpy version breaks (f.e.) python3-pyregion because of
> the problem in python3-astropy. The new upload of python3-astropy fixes
> this, so in unstable everything is OK. Even when one now adds a
> 
> Breaks: python3-astropy (<< fixed-version)
> 
> to python-numpy, it will not migrate due to the test failure of
> python3-pyregion in testing. Adding a "Breaks: python3-pyregion" is
> however wrong, since pyregion is perfect for the new numpy version.

If I understood correctly, pyregion is perfectly fine and needs no
action.  In that case, it's not a problem: with the "Breaks:
python3-astropy (<< fixed-ver)" in place, the pyregion test would
install the fixed version of python3-astropy from unstable as the broken
version from testing would not be installable using the numpy from
unstable.

> So, how to handle this?

No action needed once both astropy and numpy are "fixed". :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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: Numpy migration?

[Mattia Rizzolo]

On Sat, Jan 05, 2019 at 04:02:35PM +0100, Ole Streicher wrote:
> I'll do tonight. It however looks a bit suboptimal: when the CI test
> with a new version fails for an old reverse dependency, then the new
> version obviously breaks that old package. So, the breakage could be
> detected (and taken into account) automatically. Why do we need a manual
> action then?

Let me try to suggest you see from another side: the goal of the Breaks
field is to prevent a given combination of known broken packages to be
installed.
Currently autopkgtest blocks the migration of numpy, but if there wasn't
that block a Breaks should still be added, as the astropy in testing is
not compatible with the new numpy.  The fact that it hints britney to
trigger the right tests is just a "side effects", the Breaks should be
added nonetheless, theoretically; in practice, we rarely did it before
autopkgtest started blocking the testing migration.

> >> Another CI problem is python-astropy, which is the Python 2 version of
> >> Astropy. python-astropy is going to be removed as soon as there are no
> >> backward dependencies left; however there is still some cruft in
> >> unstable that depends on python-astropy. But this should not hinder
> >> numpy to migrate.
> >
> > I don't understand this, I don't see any python2-related issue right
> > now.  Could you please expand?
> 
> The new python-numpy breaks python-astropy in testing.

Oh, sorry.  I didn't realize python-astropy is a different source
package…

> Python-astropy is
> however going to be removed completely; it has however some cruft rdeps
> left in unstable. So, it cannot removed from unstable now, and therefore
> still remains in testing and (unnecessarily) blocks the numpy migration.
> Python-astropy already has an RC bug, but its autoremoval from testing
> is still not even announced yet.

Maybe you could ask the release team to hasten the removal of
python-astropy and rdeps from testing?  If the plan is to not relase it
in buster I don't see a reason to keep it further.

> The migration blocking CI tests seem to cause much more headaches than
> just "fix your bugs"...

Well, from what I see, it has helped a lot in this half a year detect a
ton of regressions that would have otherwise bothered several people in
a later moment…

For sure it's not just "fix your bugs" but more like "fix your bugs AND
all your rdeps", in fact you'd expect the maintainer of the package
breaking everything to be a tad more proactive, but in many cases like
this, it's not.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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: Numpy migration?

[Mattia Rizzolo]

)On Sat, Jan 5, 2019 at 3:18 PM Ole Streicher  wrote:
> However, astropy cannot migrate now, to testing, since it depends on the
> new numpy version (and therefore can only migrate after numpy). And
> numpy is blocked by the CI failure of astropy ...
>
> Looks like a deadlock. Which will be resolved before the migration delay
> ends. Which is in the second half of february, and therefore will cause
> all packages that depend on numpy and are not in testing yet to be kept
> outside of Buster (due to the release timeline).

Starting from half a month ago CI regressions are de-facto release blockers.

The way forward in cases like these is for the package that originally
cuased the breakage (i.e. numpy) to declare a versioned Breaks on the
borken and now fixed package (i.e. astropy (<< 3.1-1)).  This way
britney and debci will know they have to test numpy and astropy
together, and will be able to correctly migrate to testing at the same
time, and properly avoid a situation when two incompatible packages
are installed.
Maybe you could open a bug on numpy to get the maintainer to add the breaks.

BTW, that numpy upload also blocked our effort to remove Python 3.6
from buster...

> Another CI problem is python-astropy, which is the Python 2 version of
> Astropy. python-astropy is going to be removed as soon as there are no
> backward dependencies left; however there is still some cruft in
> unstable that depends on python-astropy. But this should not hinder
> numpy to migrate.

I don't understand this, I don't see any python2-related issue right
now.  Could you please expand?

-- 
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: Upcoming pytest-4 problems

[Mattia Rizzolo]

On Sun, Nov 25, 2018 at 02:08:52PM +0100, Ole Streicher wrote:
> Pytest 4 is however the upcoming version, and I could imagine that
> others may have similar problems with Python 2 legacy. Therefore, my
> question is how these problems should be solved:
> 
> * creating a legacy version package for pytest

This means yet another split.
It feels to me that too many packages are going this route.

> * remove the tests for these packages
> 
> * remove the legacy packages in question completely

I'd follow these two options.  For now, disable the tests when pytest 4
will land in Debian, and be ready to remove the legacy packages as a
whole soon.

After all, we are going to remove python2 itself in the upcoming years,
it doesn't really feel worth of anybody's time to work on yet other
splits, especially in cases like this where you are "only" talking about
tests for legacy and deprecated versions.

> For us, the third option would basically mean to remove the whole Python
> 2 astronomy ecosystem, and we would need to hurry in making some general
> packages Python 3 compatible (mainly astrometry.net).

I recommend you urge that ecosystem to migrate their codebases.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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#909239: lintian: ancient-python-version-field is wrong

[Mattia Rizzolo]

Control: tag -1 moreinfo

On Thu, Sep 20, 2018 at 09:43:46AM +0200, Julian Andres Klode wrote:
> lintian reports ancient-python-version-field for python-apt, but removing that
> causes py{,3}versions to complain:
> 
> pyversions: missing X(S)-Python-Version in control file, fall back to 
> debian/pyversions
> pyversions: missing debian/pyversions file, fall back to supported versions
> py3versions: no X-Python3-Version in control file, using supported versions
> 
> hence the autopkgtests fail because of stderr, so it is not possible to remove
> those fields as lintian suggests.
> 
> Lintian should not tell us to remove fields that then cause warnings in build
> tools. Or those tools should be fixed.

CCing the dh-python maintainers, as it's dh_python{2,3} that deals with
those fields...

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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: sphinx-build vs. Python 3

[Mattia Rizzolo]

On Tue, Aug 21, 2018 at 04:03:20PM +0300, Dmitry Shachnev wrote:
> If you depend on python3-sphinx (>= 1.7.5-4~) then most likely the scripts
> will be using Python 3. The opposite will happen only if the user manually
> updated the alternative, and this won’t be the case on a sane build
> environment.

I'm not so sure about this.  I don't remember Policy specifying whether
a build process can make assumptions on the configuration of possible
alternatives, and at any rate I wouldn't bet my build process on that:
after all you talk about "sane build environment", but I don't remember
any kind of consensus that said building on your dirty daily system is
not supported.

I'm personally biased as a member of the Reproducible Builds team that
believe any possible variable in the environment must not affect the
build result, this sounds like yet another one to me.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: [Python-modules-team] Bug#901621: src:python-gnutls: please support python3

[Mattia Rizzolo]

On Fri, Jun 15, 2018 at 04:08:19PM -0300, eamanu15 wrote:
> Hello Daniel,
> 
> I am available to work on maintain python-gnutls package.
> 
> But this package is not in wnpp list. I don't know if a could make update
> or maintain for python3.
> 
> I copy on this mail to Debian-python list and the actual maintainer.

The changelog doesn't know of any change done by Dan Pascu you CCed,
so I'm not sure how you decided he was "the actual maintainer" :)

Anyway, this package is maintained by DPMT, so you cou provide a patch
for this bug and find a DPMT member to sponsor 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: Help proposed for migration of PAPT repos to Salsa

[Mattia Rizzolo]

YES, please.

On Fri, Feb 23, 2018 at 10:46 PM Stefano Rivera  wrote:

> Hi Scott (2018.02.23_12:09:20_+0200)
> > Yes. I was planning on running the old scripts again. I'll do that
> > today.
>
> OK, I think I've got something that's ready.
>
> I think I'll just push them straight to Salsa, and we can review the
> result there. Sound sensible?
>
> SR
>
> --
> Stefano Rivera
>   http://tumbleweed.org.za/
>   +1 415 683 3272 <+1%20415-683-3272>
>
>

Re: How to switch python-pysam package from nosetest to pytest

[Mattia Rizzolo]

On Mon, Sep 18, 2017 at 10:54:40PM +0200, Andreas Tille wrote:
> in a Github issue[1] upstream told suggested to move from nosetest
> to pytest for python-pysam[2] package.  Any hint how to approach
> this?

You are asking for it in d/rules:
export PYBUILD_TEST_NOSE=1
(plus some related lines after).

I think you should try and see whether pybuild's autodetection works
fine, as it usually does.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: python-modules-commits-ow...@lists.alioth.debian.org bounces

[Mattia Rizzolo]

On Fri, Jul 07, 2017 at 05:54:54PM +1000, Brian May wrote:
> I am getting a constant stream of bounces from emails generated by the
> commit hooks.

I used to get them, I just gave up and subscribed the ML with "nomail".

> I tried sending an email to that address, but not got any response yet.

JFTR python-modules-commits-owner@ currently goes to
stratus at users.alioth.debian.org, piotr at users.alioth.debian.org,
bzed at users.alioth.debian.org, kitterman at users.alioth.debian.org,
barry at users.alioth.debian.org

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 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: PAPT git migration

[Mattia Rizzolo]

On Fri, Jun 02, 2017 at 04:23:20PM +0200, Raphael Hertzog wrote:
> Hi,
> 
> On Thu, 01 Jun 2017, Brian May wrote:
> > On 2017-06-01 07:32, Barry Warsaw wrote:
> > 
> > > Let's assume not (which is fine with me; i.e. why adopt git-dpm for PAPT 
> > > when
> > > we know we just want to get rid of it later?).  Then i tried to import a 
> > > new
> > > upstream as described here https://wiki.debian.org/Python/GitPackagingPQ
> > 
> > Another problem I have noticed with that document - but not had time to
> > come up with a solution yet. 
> > 
> > There are several places where "git push --all" (or variant) is
> > recommended. But this will also push the gbp pq branch(es), which should
> > never get pushed.
> 
> "git push origin : --tags" is what I use in general, it pushes branches
> available on both sides and tags.


I have recently discovered the config push.followTags=true, which pushes
all tags which reference objects that are being pushed.
That should save the '--tags' flag :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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: PAPT git migration

[Mattia Rizzolo]

On Thu, Jun 01, 2017 at 12:16:45AM +0200, Stefano Rivera wrote:
> > $ gbp pq export
> > - This doesn't work until you at least do a first pq import, but now I see 
> > the
> >   d/p/changlog-docs patch gets changed in ways that lose information:
> 
> Sounds like a limitation of pq import. I'm suprised it doesn't support
> DEP3. That was something that dpm got right (once we figured out the
> right parameters).

Yes it's a gbp pq bug: https://bugs.debian.org/785274
The support improved over time in the last years, but it's still not
great, as that bug documents.

> 3. leave this to the maintainer to resolve (I think we expect all pq use
>to be entirely local, so pq use isn't something we're imposing on
>anyone)

I would totally welcome this.  Really with gbp the use of pq is not
mandatory at all, as after all the output are always quit patches.  Sure
if somebody uses pq and somebody else doesn't it would end up with some
diff noise due to the import/export, but imho nothing worth concerning
about.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: [Python-modules-commits] [python-cpuinfo] 02/02: Import Debian changes 3.0.0-1

[Mattia Rizzolo]

On Mon, Apr 17, 2017 at 12:12:11PM -0400, Sandro Tosi wrote:
> are we really suggesting to create a separate binary package, for a
> single script, not even 400 bytes (in py-cpuinfo case, but i bet there
> are more just like this), mainly boilerplate, that simply loads the
> entrypoint from the main module and nothing else?

I think quite a lot of cases are better off without any /usr/bin/foo
installed, and have the user just call it with `python[3] -m foo`
instead.
It's up to the maintainer, of course.

But otherwise yes, I think a separated package is better.

I'm just thinking about how annoying is now changing the /usr/bin/foo
from the python2 to the python3 package, and in the meantime stuff
started to (build-)depend on it only for the /usr/bin/foo, stuff which
may or may not be easy to detect... This is just a case.

> that seems overkill
> to me (and probably not only to me, given how much discussion there
> was on d-devel about small node packages)

Well, to me it seems we either resigned about this situation, or stopped
cared, considering how many node packages appeared in the last months
without any pointless flame about it (personally, I resigned for 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: [Python-modules-commits] [python-cpuinfo] 02/02: Import Debian changes 3.0.0-1

[Mattia Rizzolo]

On Sun, Apr 16, 2017 at 09:07:09PM +0100, Ghislain Vaillant wrote:
> So what you guys are proposing is to introduce a new wrapper script, in
> its own binary package, whose name is not endorsed by upstream, and
> which will end-up completely Debian specific.
> 
> Am I really the only one in this team to think this proposal is a
> complete non-sense?

Ok, this is a different matter than what Sandro brought up, though.
Anyhow, I wouldn't call it "complete non-sense" but just a tad unwise,
as any non-upstreamed debian-specific change is, nothing more.
If instead of renaming that binary, it was called /usr/bin/cpuinfo my
own proposition would still make sense, and your too.

> > Surely I'm not the only one who would consider moving the file back to
> > python3-cpuinfo a step backward…
> 
> I fail to understand how your anti-Python-3 feelings add anything
> constructive to this thread. Moving on.

lol.
Trust me, I am very far from being an "anti-Python-3" person :D
If anything, I wish for Python 2 to be retired *soon* and python3 to
take the lead everywhere.
What I am "against" is for /usr/bin/ files to be in library packages, be
them python2's or python3's.

> AFAIC, I happily use pytest or sphinx via their respective python[3]-
> pytest

There is a peculiar thing about pytest: the version of python used
matters.  That's different than most python /usr/bin/* things.

> and python[3]-sphinx.

neither python-sphnix nor python3-sphinx ship anything in /usr/bin, so
bad example.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: [Python-modules-commits] [python-cpuinfo] 02/02: Import Debian changes 3.0.0-1

[Mattia Rizzolo]

On Sun, Apr 16, 2017 at 05:50:54PM +0200, Hugo Lefeuvre wrote:
> I introduced an additional binary package for this script because I thought
> people cold have found it useful. But, right, everything considered I should
> better drop it.

Wait a second before dropping this..

What would be the downside of having it in a separate package?  I
concur that the "py-" prefix strikes as odd, but I otherwise generally
recommend keeping /usr/bin/* stuff out of python-* packages, while
keeping in the latter only the python module, for a bunch of reasons.

Surely I'm not the only one who would consider moving the file back to
python3-cpuinfo a step backward…

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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: python-patch 1.16

[Mattia Rizzolo]

Hey Paolo, any news of this package?
(explicitly CCing you to be extra sure it'll reach you)


(And this is why I prefer RFS bugs, btw, saving me from digging in my
mail archive to find this one…)


On Thu, Dec 29, 2016 at 06:17:40PM +0100, Mattia Rizzolo wrote:
> On Tue, Nov 29, 2016 at 08:20:23AM +0100, Paolo Greppi wrote:
> > Hi,
> 
> Hi!
> 
> FYI, I found your RFS only thanks to the /topic in #debian-python.
> Unless you're very lucky most RFSes sent to random mailing lists have a
> tendency to get lost/ignored; that's why I suggest you always file a RFS
> bug and X-Debbugs-CC the relevant team, unless you know that team is
> going to react (like pkg-js recently).
> 
> > I packaged python-patch as per this ITP:
> > https://bugs.debian.org/845482, this is the repo:
> > https://anonscm.debian.org/cgit/python-modules/packages/python-patch.git
> > 
> > Please someone more experienced than me review it and if it's OK sponsor
> > its upload.
> 
> I fixed the file name in the pristine-tar branch (otherwise `origtargz`
> ignored it..).
> 
> > Please note that since the pypi tarball has no tests, whereas the github
> > tarball has no setup, I choose the latter and added the setup.py with a
> > git-dpm/quilt patch. I hope this is correct.
> 
> Yep, that's fine.  Please ask upstream to syncronize both, and have
> github ship the setup.py, and the tarball the release.
> 
> 
> more changes I ask you:
> * d/changelog:
>   + please kill the second changelog line; first uploads should only
> come with a "first upload" line
>   + finalize it (dch -r)
> * d/control:
>   + please wrap-and-sort that list of build-deps
>   + why are you commenting out the Testsuite field?
>   + Vcs-* are pointing to a repo that's not DPMT's, that's wrong
> (furthermore that URL first requires auth, and it gave me a 404, so
> I think it's a private repo)
> * d/compat:
>   + please bump to 10 (d/control already have the >= 10, so I guess you
> just forgot to push this one too)
> * d/rules:
>   + please repspect DEB_BUILD_OPTIONS=nocheck
>   + please use the method provided by pybuild to properly run the tests
> against all supported python versions, against what you just
> "built"; I think that one runs only one python version (2.7)
> against the original sources.
>   + you're overriding dh_auto_install when you only want to append
> --install-script to the command invoked.  Please use
> PYBUILD_INSTALL_ARGS=--install-scripts=... instead.
> * d/copyright:
>   + why are you licensing debian/ under a different license?
>   + personally I find a lot more readable to have all the file paragraph
> at the top, and all stand alone licenses at the bottom
>   + other/pack.py is under another license
> * I: python-patch: new-package-should-not-package-python2-module python-patch
>   + right, I was about to forget about this...
> * I: python-patch source: binary-control-field-duplicates-source field 
> "section" in package python-patch
> 
> -- 
> regards,
> Mattia Rizzolo
> 
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-



-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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 a package from collab-maint to python-modules

[Mattia Rizzolo]

On Sat, Mar 11, 2017 at 11:24:36AM +, Christopher Hoskin wrote:
> I'd like to package python-jsonpointer for Debian. The filer of the RFP (Bug 
> #754296) Pietro Battiston, has created a repository at
> 
> https://anonscm.debian.org/cgit/collab-maint/python-jsonpointer.git
> 
> but has no intention of becoming the maintainer, and the package has not been 
> uploaded. The existing repository does not use git-dpm or pristine-tar.
> 
> I'd like to maintain this package within DPMT. Is there a way I can migrate 
> the existing repository, or should I just start again?

Once you switched the RFP to ITP, and own it,

1) add a pristine-tar branch (just create branch without parents, and
   run `pristine-tar commit` (+ appropriate args))
2) convert to git-dpm (it should be something with `git-dpm init…` iirc)
3) push that repository you now got to DPMT
4) remove the old repository from collab-mainnt



-- 
regards,
    Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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: python-jsonref 0.1

[Mattia Rizzolo]

Hi Paolo,


On Tue, Nov 29, 2016 at 08:33:20AM +0100, Paolo Greppi wrote:
> I packaged python-jsonref as per this ITP:
> https://bugs.debian.org/844986, this is the repo:
> https://anonscm.debian.org/cgit/python-modules/packages/python-jsonref.git
> 
> Please someone more experienced than me review it and if it's OK sponsor
> its upload.

* git is lacking a pristine-tar branch, please push it (I don't even try
  to build without)
* d/control:
  + please wrap-and-sort that list of build-deps
  + maintainer is you, and DPMT is nowhere to be seen
  + why is Testsuite commented out?
* please bump compat to 10
* d/rules:
  + I think you need to also do --with sphinx to have dh_sphnixdocs do
it's job?
* d/copyright:
  + why are you listing all the files instead of using wildcards?!
  + is there a particular reason the license of debian/ is different and
more stricter than upstream's?
  + no need to repeat "Copyright (C)" on the Copyright: lines
  + also I very much like emails in d/copright
  + the license field of upstream also include the copyright notice, it
shouldn't
* that proxytypes.py has a "based on the implementation..", are you sure
  that's not under a different copyright/license? (if so upstream might
  be at fault here, and this package might not be redistributable)


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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: python-patch 1.16

[Mattia Rizzolo]

On Tue, Nov 29, 2016 at 08:20:23AM +0100, Paolo Greppi wrote:
> Hi,

Hi!

FYI, I found your RFS only thanks to the /topic in #debian-python.
Unless you're very lucky most RFSes sent to random mailing lists have a
tendency to get lost/ignored; that's why I suggest you always file a RFS
bug and X-Debbugs-CC the relevant team, unless you know that team is
going to react (like pkg-js recently).

> I packaged python-patch as per this ITP:
> https://bugs.debian.org/845482, this is the repo:
> https://anonscm.debian.org/cgit/python-modules/packages/python-patch.git
> 
> Please someone more experienced than me review it and if it's OK sponsor
> its upload.

I fixed the file name in the pristine-tar branch (otherwise `origtargz`
ignored it..).

> Please note that since the pypi tarball has no tests, whereas the github
> tarball has no setup, I choose the latter and added the setup.py with a
> git-dpm/quilt patch. I hope this is correct.

Yep, that's fine.  Please ask upstream to syncronize both, and have
github ship the setup.py, and the tarball the release.


more changes I ask you:
* d/changelog:
  + please kill the second changelog line; first uploads should only
come with a "first upload" line
  + finalize it (dch -r)
* d/control:
  + please wrap-and-sort that list of build-deps
  + why are you commenting out the Testsuite field?
  + Vcs-* are pointing to a repo that's not DPMT's, that's wrong
(furthermore that URL first requires auth, and it gave me a 404, so
I think it's a private repo)
* d/compat:
  + please bump to 10 (d/control already have the >= 10, so I guess you
just forgot to push this one too)
* d/rules:
  + please repspect DEB_BUILD_OPTIONS=nocheck
  + please use the method provided by pybuild to properly run the tests
against all supported python versions, against what you just
"built"; I think that one runs only one python version (2.7)
against the original sources.
  + you're overriding dh_auto_install when you only want to append
--install-script to the command invoked.  Please use
PYBUILD_INSTALL_ARGS=--install-scripts=... instead.
* d/copyright:
  + why are you licensing debian/ under a different license?
  + personally I find a lot more readable to have all the file paragraph
at the top, and all stand alone licenses at the bottom
  + other/pack.py is under another license
* I: python-patch: new-package-should-not-package-python2-module python-patch
  + right, I was about to forget about this...
* I: python-patch source: binary-control-field-duplicates-source field 
"section" in package python-patch

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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: can we disable the bounce kicker? Re: confirm

[Mattia Rizzolo]

On Sun, Sep 11, 2016 at 09:41:46AM +0100, Sandro Tosi wrote:
> now can we PLEASE stop talking about how the perfect smtp system
> should work and GET BACK to discuss if we are able and want to disable
> the suspend membership upon bounces (that's what the mail you receive
> says, so do not nitpick on this term again)

Yes it can be done.  In the administrative panel of mailman lists there
is this page at /admin//bounce:
https://volatile.mapreri.org/2016-09-11/80a0f21170e6f0098db20e2536b8dedb/mailman_Bounce_processing_.png

Now, you've got to ask to the admin of that mailing list, which appears
to be jwilk.  I find that particularly interesting, given that afaik he
left the team some time ago.
I don't know whether anybody else knows the administration password
other than him.

-- 
regards,
    Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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: can we disable the bounce kicker? Re: confirm

[Mattia Rizzolo]

On Sat, Sep 10, 2016 at 05:34:12PM +0200, Santiago Vila wrote:
> On Sat, Sep 10, 2016 at 04:15:19PM +0100, Sandro Tosi wrote:
> > On Sat, Sep 10, 2016 at 3:32 PM, Santiago Vila <sanv...@unex.es> wrote:
> Fine, but it is yet to be seen that the quoted message is rejected for
> being "spam" (which is not an exact science), it could also be rejected
> for having a broken DKIM signature (which may be checked automatically),
> as the email is clearly modified by the list server.

I've never seen rejected email from gmail's SMTP due to broken DKIM.
AFAICT it just puts them in Spam (and only for the domains that enforce
DKIM to be valid).

OTOH, in my rely mail hosts I often see messagges like this:
[wrapped for convenience]
Sep  5 07:42:41 kahlan postfix/smtp[25940]: C67BF41796:
to=<mapr...@gmail.com>, orig_to=<mat...@mapreri.org>,
relay=alt1.gmail-smtp-in.l.google.com[173.194.222.26]:25, delay=248373,
delays=248370/0.08/2.6/0.27, dsn=4.7.0, status=deferred (host
alt1.gmail-smtp-in.l.google.com[173.194.222.26] said: 421-4.7.0
[95.85.2.163  15] Our system has detected that this message is
421-4.7.0 suspicious due to the nature of the content and/or the links
within. 421-4.7.0 To best protect our users from spam, the message has
been blocked. 421-4.7.0 Please visit 421 4.7.0
https://support.google.com/mail/answer/188131 for more information.
24si4125534ljb.48 - gsmtp (in reply to end of DATA command))


Usually those kind of emails stick there and postfix keeps trying them
until they eventually hit the timeout and my rely rejects them too.

> The "[Python-modules-team]" thing in the subject is probably enough to
> break the DKIM signature.

also the footer, if there is one, as it's default of mailman.

> We should really not be sending messages having broken signatures to
> the outside world, including our own email inboxes.

~all mailman mailing lists distributes messagges with broken DKIM
signatures since the conception, the world did not end.  It's plain
annoying only for the very few domains that enforce them (notabily:
yahoo, but I stopped caring for it).

> And email users subscribed to one or more mailing lists should really
> use email filters to filter email, not rely on this obnoxious subject
> munging.

yes.

> More to the point, when you subscribe to a mailing list, you should be
> ready to accept all messages from such mailing list, not accept some
> messages and reject others.

I agree gmail is broken there (and not only there), though I'm still an
user too...
The correct behaviour if they really want to avoid spam to even reach
the spam folder, is to accept the email, and discard it.


Mattia,
whom suffers from this for the debian-science-maintainers ML.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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: on keep providing python 2 packages

[Mattia Rizzolo]

On Sun, Aug 21, 2016 at 12:30:42AM +0200, Piotr Ożarowski wrote:
> * libraries in Stretch should support 2.X (i.e. add python-foo binary
>   packages) if that doesn't require too much additional work (py2dsp
>   still creates them). I'm OK with shipping 3.X only packages in NEW
>   packages, though. I'd not encourage people to do so but also not
>   forbid it,

Thanks for having some trust in your fellow package maintainers...

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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: on keep providing python 2 packages

[Mattia Rizzolo]

On Sat, Aug 20, 2016 at 05:42:24PM +0100, Sandro Tosi wrote:
> anyway, why wouldnt you want to provide a python2 package  if the code
> supports it? if you got a py3k package working, it's usually
> straightforward to have a py pkg. Doing that i've found several issues
> with upsteam projects that were fixed, thus increasing the general
> quality of their code and our distribution

my opinion:

it just makes no sense to discuss this now:
 + it's less than 6 months from the freeze
 + I doubt that there will be that many "affected packages" right now,
   much less that many "buggy" (by your proposal) indroced in the next
   few months; I don't recall seeing any example in any email.
 + I very much hope we'll manage to get buster out without python2, in
   that case thinking about shipping py2 modules now when we're going to
   drop them next year would be a plain waste of time.


I'm curious: what triggered this email of yours?

-- 
regards,
    Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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#834768: RFS: codicefiscale/0.9-1

[Mattia Rizzolo]

On Fri, Aug 19, 2016 at 10:47:37PM +0200, Elena ``of Valhalla'' wrote:
> On 2016-08-18 at 22:27:42 +0000, Mattia Rizzolo wrote:
> > * Files-Excluded in d/copyright doesn't list all the files that are
> >   removed (at least according to `git diff --stat
> >   upstream/0.9..upstream/0.9+ds0`)
> >   besides, wrapping that list might not be a bad idea
> 
> Uhm, I used uscan to remove the files, so nothing that wasn't listed was
> removed.
> 
> Do you mean that I should explicitely list all of the content of the
> directory ``codicefiscale.egg-info``, instead of just listing the
> directory?

No, it just means that I rashed too much at reviewing it last night and
was already sleeping.
I didn't notice all those files where inside a directory -.-'

> > * why do you disable the tests?  (a comment on d/rules might not be a
> >   bad idea here either)
> >   + I see setup.py lists non-existant tests, if that's the issue maybe
> > you can get that tests= arg removed (or the actual tests included)
> > upstream?
> 
> That's exactly the issue, I've added a comment with a pointer to 
> https://github.com/ema/pycodicefiscale/issues/6

The project doesn't strike me as very active, but thanks :)

> > * just quickly skimming over the README, I think it would make sense to
> >   include in the binaries, as it provides quick documentation (I think)
> 
> yes, it does, you're right (added in git)

You did this:

diff --git a/debian/docs b/debian/docs
new file mode 100644
index 000..a1320b1
--- /dev/null
+++ b/debian/docs
@@ -0,0 +1 @@
+README.rst

This is not going to do what you expect, check both the produced
binaries ;)
(`debc` right after having built the package is handy for that, I run
it in a pbuilder hook for example)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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#834768: RFS: codicefiscale/0.9-1

[Mattia Rizzolo]

control: owner -1 !
control: tag -1 moreinfo

On Thu, Aug 18, 2016 at 10:24:31PM +0200, Elena ``of Valhalla'' Grandi wrote:
> On 2016-08-18 at 21:48:05 +0200, Elena ``of Valhalla'' wrote:

FYI: no need to explicitly CC d-mentors@, RFSes are somehow sent there
anyway.

> > To access further information about this package, please visit the 
> > following URL:
> > 
> >   https://mentors.debian.net/package/codicefiscale
> > 
> > 
> > Alternatively, one can download the package with dget using this command:
> > 
> > dget -x 
> > https://mentors.debian.net/debian/pool/main/c/codicefiscale/codicefiscale_0.9-1.dsc
> > 
> > Or directly from git at:
> > 
> > https://anonscm.debian.org/git/python-modules/packages/codicefiscale.git
> 
> sorry, I forgot about removing the codicefiscale.egg-info, the actual
> dsc is:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/c/codicefiscale/codicefiscale_0.9+ds0-1.dsc
> 
> (all other urls are ok, and their content have been updated, sorry)

This is DPMT, where the usage of git is mandated, so I expect the git
repository to match the generated .dsc (hence I'm ignoring mentors here)


A few small things I'd like to see:

* you email address in d/copyright
* Files-Excluded in d/copyright doesn't list all the files that are
  removed (at least according to `git diff --stat
  upstream/0.9..upstream/0.9+ds0`)
  besides, wrapping that list might not be a bad idea
* Also would be nice to see Build-Depends wrap-and-sort'ed
* python3-codicefiscale uses ${python:Depends} instead of
  ${python3:Depends}
* why do you disable the tests?  (a comment on d/rules might not be a
  bad idea here either)
  + I see setup.py lists non-existant tests, if that's the issue maybe
you can get that tests= arg removed (or the actual tests included)
upstream?
* in d/watch, you dversionmangle '.ds0' away, but you're using '+ds0'
  actually, so it's not actually mangling anything
* just quickly skimming over the README, I think it would make sense to
  include in the binaries, as it provides quick documentation (I think)


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

updating python-tidylib for libtidy5

[Mattia Rizzolo]

some weeks ago a transition happened from libtidy-0.99-0 (provided by
src:tidy) to libtidy5 (provided by src:tidy-html5).

The only actual issue arised with src:python-tidylib:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829178
https://github.com/countergram/pytidylib/issues/9
https://github.com/countergram/pytidylib/issues/13

upstream looks quite disinterested to the issue, so I wonder whether
some of you have some spare tuit to look at this issue.

If you manage something please do upload python-tidylib fixing this
issue, so we care remove src:tidy from the archive.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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 me from Uploader field of html5lib

[Mattia Rizzolo]

On Mon, Jul 04, 2016 at 04:52:52PM +0200, Olivier Berger wrote:
> Unfortunately, I'm no longer able to dedicate time to help maintaining
> the html5lib package.

That's totally ok!  Interest shifts, so it's ok to say stop at something
:)

> Thus I'm requesting that anyone uploading the next version as part of
> the team, please remove me from the uploaders field.

You can just remove yourself.  Just do it in the git repository of the
package, that way whoever in the team will do the next upload will have
the change staged.
It's also quite unluckily that somebody will remember such a mail
already next week, much less in some months.

> Btw, the docs on the wiki documents how to be added/contribue, but not
> really how to stop ;-)

A person usually just remove himself from the Uploaders field, from my
experience.

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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: django-pipeline

[Mattia Rizzolo]

On Tue, Mar 22, 2016 at 05:42:48PM +1100, Brian May wrote:
> I would appreciate help with #818730 for django-pipeline.
> 
> The reporter claims the package won't build however I can't reproduce
> any problems myself. Which makes it hard to fix.

FTR this is also visible in the reproducible CI:
https://tests.reproducible-builds.org/rb-pkg/unstable/amd64/django-pipeline.html

That's a standard pbuilder instance in a clean chroot.

I tried to reproduce it locally and I had the very same failure.
Though I can't help fix it, just saying I can reproduce the failure.

-- 
regards,
    Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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: pep8 python module is now in python-pep8 - triggers FTBFS

[Mattia Rizzolo]

On Thu, Mar 10, 2016 at 11:10:57AM +, Edward Betts wrote:
> The pep8 python module has moved from the pep8 package to python-pep8.
> 
> See https://tracker.debian.org/news/752214
> 
> /usr/bin/pep8 is still in the pep8 package but now uses python3-pep8
> 
> There are 32 packages with a Build-Depends on pep8. These packages usually
> make use of pep8 in their test suites. Many of them will need to be updated to
> use python-pep8 instead.
> 
> Here is the list of packages with a Build-Depends on pep8.
> 
>   actdiag aptdaemon autopkgtest
>   backup2swift blockdiag botch breadability byobu
>   cloud-init custodia
>   d-feet dirspec django-sekizai
>   fuzzywuzzy
>   genbackupdata
>   nwdiag
>   obnam ovirt-guest-agent
>   prospector pygobject python-apt python-cliapp python-flake8 python-netlib 
> python-ttystatus
>   seqdiag shortuuid ssh-import-id summain swiftsc syslog-ng
>   xcffib
> 
> I checked a few of these, in detail:
> 
>  - fix for fuzzywuzzy uploaded
>  - bug filed for blockdiag

#817789 — those are FTBFS bugs, they should be severity:serious.

>  - fix for django-sekizai pushed to git, e-mailed uploaders
> 
> I checked python-ttystatus and obnam. I found they use /usr/bin/pep8 instead 
> of
> importing the pep8 module, so they don't need updating.
> 
> More examples of pep8 use here:
> 
> https://codesearch.debian.net/results/import%20pep8

If I were you I'd just file bugs for all of them that now FTBFS.
For easy checking whether a package now fails to build you can just
check the status in reproducible.debian.net/$pkg, I think most (if not
all) of them have already been rebuilt in the meantime.

Unfortunately the only packages maintained by DPMT are
   breadability
   django-sekizai
   fuzzywuzzy
   python-flake8
whilst the only one by PAPT is prospector.  (information obtained by
dd-list(1)).
So I'm sorry there are no good chances of fixing those by just mailing
d-python@, you really need to file bugs for them all (if most were
maintained in the python teams somebody could have gone through them and
fixing them in little time).

But be assured, if you don't do that yourself somebody else will do them
in one of the several efforts/projects that involves rebuilding
packages and checking they don't FTBFS :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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: nose2 reverse dependancies

[Mattia Rizzolo]

On Wed, Mar 02, 2016 at 09:42:57AM +1100, Brian May wrote:
> According to https://udd.debian.org/cgi-bin/autoremovals.cgi:
> 
> Brian May <b...@debian.org>
>djangorestframework: buggy deps nose2, flagged for removal in 28.7 days
>python-mkdocs: buggy deps nose2, flagged for removal in 28.7 days
> 
> Which is fine, nose2 really is broken, am about to upload a fix.
> 
> However I can't see any reason why a buggy nose2 is affecting
> djangorestframework or python-mkdocs.
> 
> There doesn't appear to be anything that build-depends on nose2, or its
> binary packages python-nose2 or python3-nose2. Have I missed something
> obvious???

They are down the dep chain:

nose2 => nose2-cov => python-pytest-cov => python-watchdog =>
python-mkdocs => djangorestframework

(if I did my work correctly)

To be more precise, that's what will get removed from testing if you
don't fix that bug (from autoremovals.yaml.cgi):

nose2:
  bugs:
  - '812710'
  dependencies_only: false
  last_checked: 2016-03-01 17:51:47
  rdeps:
  - aodh
  - borgbackup
  - ceilometer
  - couchapp
  - cov-core
  - designate
  - django-countries
  - django-oauth-toolkit
  - djangorestframework
  - djangorestframework-gis
  - djoser
  - drf-fsm-transitions
  - drf-haystack
  - hovercraft
  - mistral
  - mitmproxy
  - nose2-cov
  - openstack-meta-packages
  - python-jsonrpc2
  - python-kdcproxy
  - python-mkdocs
  - python-pymemcache
  - python-pytest-cov
  - python-tooz
  - python-watchdog
  - vmware-nsx
  - vulture
  removal_date: 2016-03-30 17:33:24
  source: nose2
  version: 0.5.0-2

> Reason I ask is because I was planning on testing building packages
> against nose2 that were broken before uploading a new nose2, however I
> can't see any packages that require nose2, which I find somewhat
> confusing. So probably will upload anyway.

Hopefully I cleared some.
FYI, I don't know of a nice way to build a dependency graph, like
sometimes I see somewhere, with graphiz

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

python-support is dead, long live dh-python \o/

[Mattia Rizzolo]

A short email, just to notify you that python-support has just been
removed from stretch :D

With today evening (10pm UTC) Britney run the last blocker wend in
(mercurial-server was it), and she finally menaged to remove
python-support without causing any further breakage in testing:

[...]
trying: -python-support
accepted: -python-support
   ori: 62+0: a-7:i-3:a-1:a-1:a-1:m-1:m-1:p-44:p-1:s-2
   pre: 62+0: a-7:i-3:a-1:a-1:a-1:m-1:m-1:p-44:p-1:s-2
   now: 62+0: a-7:i-3:a-1:a-1:a-1:m-1:m-1:p-44:p-1:s-2
[...]
Apparently successful
final: -python-support,[...]
[...]


\o/


Thank you for all the parties involved :D
(especially to the maintainers who switched promptly and didn't wait
for the last time, and to the maintainers who actually maintain their
packages avoiding more work from QA guys who had to NMU them :P)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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#812117: RM: simpletal -- RoQA; unmaintained; low popcon

[Mattia Rizzolo]

Package: ftp.debian.org
X-Debbugs-Cc: debian-python@lists.debian.org

The maintainer (jenner) seems MIA (even if not declered officially by
the mia team), nobody in the DPMT stepped up maintaining it in the last
10 years, and packaging a new upstream release that is out since at
least 2009.



-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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#812117: RM: simpletal -- RoQA; unmaintained; low popcon

[Mattia Rizzolo]

control: tag -1 moreinfo

On Wed, Jan 20, 2016 at 07:00:01PM +, Mattia Rizzolo wrote:
> Package: ftp.debian.org
> X-Debbugs-Cc: debian-python@lists.debian.org
> 
> The maintainer (jenner) seems MIA (even if not declered officially by
> the mia team), nobody in the DPMT stepped up maintaining it in the last
> 10 years, and packaging a new upstream release that is out since at
> least 2009.

There are rdeps, though.

Checking reverse dependencies...
# Broken Depends:
advene: advene
loggerhead: loggerhead
mobyle: mobyle
pubtal: pubtal
pygopherd: pygopherd

# Broken Build-Depends:
loggerhead: python-simpletal
mobyle: python-simpletal
python-bottle: python-simpletal

Dependency problem found.


Now, probably removing them is not easy, so maybe I'm going to do a QA
upload and orphan the package in the meantime, but I still think it's
probably better to not have unmaintained stuff in the archive, so it'd
be nice if somebody could try fixing those.


-- 
regards,
            Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: Updating python-jsmin

[Mattia Rizzolo]

On Thu, Jan 14, 2016 at 11:44:09PM +0800, gustavo panizzo (gfa) wrote:
> I've generated a tarball using git archive and push it to pristine-tar
> branch
> 
> the md5sum of the tarball is 8f5e2fcdbe62b539efb5686ef0484831
> 
> I cloned the repo in a clean sid chroot, built it, and the md5sum
> coincided
> 
> thanks! I learned something today :)


cool, uploaded.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: Updating python-jsmin

[Mattia Rizzolo]

On Tue, Jan 12, 2016 at 10:18:43AM +0800, gustavo panizzo (gfa) wrote:
> Hello
> 
> anybody willing to sponsor the upload?
> 
> git.debian.org:/git/collab-maint/python-jsmin.git
> 
> thanks!

I can do it, but what should I use as a orig tarball?  what I get out of
uscan (from pypi) has sha256sum
8e7f19bc2cc467bccd02322dc0a6065d06a038e311f2531af1a33b410afea081
Please consider following a git format with packagin branch
(debian/unstable in your case and that's ok) + upstream branch +
pristine-tar.  according to debian/gbp.conf there should be master
branch, but maybe you didn't push it?

btw, from that tarball you miss .travis.yml so I can't get the source
built.

also, please consider fixing unused-file-paragraph-in-dep5-copyright
(you need to swap the paragraphs; in dep5 order matters).
and also please consider using https in Vcs-Browser.
(but I won't hold on those 2 if you say you don't want to bother)


So, I'm up, but you need to give me an upstream tarball.

> keybase: http://keybase.io/gfa
the key used to sign the tags on that repo is not the same as the one in
keybase, btw.  doesn't really help.  (063A6583 is the one used, 9F6C6333
the one on keybase)

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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 p9m4 from PAPT

[Mattia Rizzolo]

On Mon, Dec 14, 2015 at 02:41:09PM +0100, Piotr Ożarowski wrote:
> [Mattia Rizzolo, 2015-12-14]
> > Given that looks like nobody is interested in it, shall I do a QA upload
> > of the package kicking it out of the team?
> 
> yes please (and thanks)

OK, uploaded.

Best.
-- 
regards,
            Mattia Rizzolo

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


signature.asc
Description: PGP signature

about kicking python-uniconvertor out of the team

[Mattia Rizzolo]

Hi there, again:

Another package marked as O but still inside the team is
python-uniconvertor.  This time it's in DPMT, of which I'm a member, so
if you just tell me what I should do I'll happily follow.

Turned out Luca already did the pysupport→dh-python migration back the
time we were on svn, but didn't upload, so I'm just holding off a dput.

Please tell me what I should do with this :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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: about kicking python-uniconvertor out of the team

[Mattia Rizzolo]

On Mon, Dec 14, 2015 at 08:30:09PM +0100, Luca Falavigna wrote:
> 2015-12-14 19:17 GMT+01:00 Mattia Rizzolo <mat...@debian.org>:
> > Turned out Luca already did the pysupport→dh-python migration back the
> > time we were on svn, but didn't upload, so I'm just holding off a dput.
> 
> I actually dput'ed it myself, but the upload was autorejected due to #699301.

nice.

> I'd rather go and remove python-uniconvertor for good (see #787925),

yay \o/

> but tgif still depends on it (#796294, altough it can be dropped:
> uniconvertor only adds support for SVG output).

Uploaded a NMU for that to DELAYED/2.

-- 
regards,
    Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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#746741: release.debian.org: dh-python2 transition

[Mattia Rizzolo]

On Tue, May 27, 2014 at 10:59:56PM +0200, Emilio Pozuelo Monfort wrote:
> On 05/05/14 15:46, Julien Cristau wrote:
> > On Sat, May  3, 2014 at 07:48:03 +0100, Dimitri John Ledkov wrote:
> >> Debian python teams would find useful to evaluate on continuous basis
> >> removal of python-support from the archive and thus migrating to
> >> dh-python2. We are uncertain of the scope, and the pace at which this
> >> transition can be completed. But it would be extremely useful to have a
> >> transition tracker setup (permanent-type ?!).
> >>
> > I don't think that makes much sense as a transition / tracker, as it's
> > not something rebuilds would fix or where it's hard to find the set of
> > affected packages.
> 
> FWIW, you may get a lot of things switched by emailing debian-devel@ with a
> dd-list. And also by adding a lintian check.

I'm currently undergoing a sprint to push this to an end, I'm down to
~80 packages still affected, a handful already in deferred, and if I
continue with this pace I'm going to NMU/team upload all of them by the
end of the next week or so.

We came to a point where I think the number of affected packages is not
going down  by itself, since most of the packages have either the
maintianer that is de-facto MIA or the package is de-facto orphaned.

So I ask for permission to bump all those bugs to severity:serious, and
move on; that way I'll have the excuse to ask for RM: RoQA for a couple
of packages without feeling too guilty...


PS: let me guess, should this bug be reassigned to ftp-master for RM?
since you already stated -release is not the right place for this, and a
transition tracker is not really needed in this case.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

removing p9m4 from PAPT

[Mattia Rizzolo]

I'm in the process of NMUing/QA upload p9m4 for the python-support
removal, and noticed #740323 from the MIA team.

Given that looks like nobody is interested in it, shall I do a QA upload
of the package kicking it out of the team?

If that the case, please remove the svn repo or mark it as
old/deprecated (=> I'm not in the PAPT team, and anyway I don't know how
the python teams deal with packages going out of the team (whether there
is an attic or such.  If that was in git I'd have just cp the repository
to collab-maint, but with svn...).


I'll wait some time to hear from you before uploading.

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature

packages without any uploaders

[Mattia Rizzolo]

https://tracker.debian.org/pkg/python-cherrypy

This package, python-cherrpy, is Maintainer: DPMT, but has nobody listed
in Uploaders.

This is a serious policy violation[1].

Even without considering that, shall we continue to carry the team name
and keep the package in our git repository namespace, or shall we move
it out?

We can orphan it officially, for example.


I'm CCing the former maintainer, since I don't know if he follows this
list.



[1] https://lintian.debian.org/tags/no-human-maintainers.html
Though there are people who argued that the whole point of team
maintenance is you don't need to feel bound to a package.  Anyway, this
lead to a package rejection back this summer for some package of the X
team, where there are a lot of packages with this "issue" (even if
actively maintained).

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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: packages without any uploaders

[Mattia Rizzolo]

On Sat, Dec 12, 2015 at 11:54:12PM +0100, Piotr Ożarowski wrote:
> > This package, python-cherrpy, is Maintainer: DPMT, but has nobody listed
> > in Uploaders.
> 
> if nobody is interested in adopting it, package will be orphaned.
> (why wasn't the DPMT replaced with QA when Uploaders was removed in the
> first place?!)

dunno, I just noticed it while doing my shift for removing pysupport.

If you guys tell me so I'm happy to send an O bug, move the repo to
collab-maint and doing a QA upload orphanizing it.

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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: Git migration schedule

[Mattia Rizzolo]

On Sat, Oct 10, 2015 at 12:18:20PM +1100, Ben Finney wrote:
> Brian May <br...@microcomaustralia.com.au> writes:
> 
> > On Fri, 9 Oct 2015 at 19:26 Stefano Rivera <stefa...@debian.org> wrote:
> >
> > >
> > > Here:
> > > https://wiki.debian.org/Python/GitPackaging#Where_do_the_team.27s_git_branches_live.3F
> >
> > I seem to have problems with this because my username on my local box is
> > "brian" however my username on git.debian.org is "bam". There doesn't
> > appear to be an easy way of overriding it.
> 
> You need to specify which username to connect to over SSH. I have
> updated the Wiki page above to clarify this.
> 
> Now that you already have the remote configured, you can re-configure it
> with:
> 
> $ git remote set-url origin 
> git+ssh://usern...@git.debian.org/git/python-modules/tools/python-modules.git
> 
> where “origin” is the name of the remote, and “USERNAME” is your Alioth
> username.

You can also add a snipped like mine to ~/.ssh/config:

Host alioth svn.debian.org git.debian.org bzr.debian.org hg.debian.org 
darcs.debian.org arch.debian.org anonscm.debian.org
    HostName alioth.debian.org
User mapreri-guest


so you avoid fiddling with every git remote.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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: managing transitions

[Mattia Rizzolo]

On Tue, Oct 06, 2015 at 04:03:54PM +0200, Thomas Goirand wrote:
> On 10/06/2015 01:02 PM, Mattia Rizzolo wrote:
> > On Tue, Oct 06, 2015 at 08:39:48AM +, Brian May wrote:
> >> On Tue, 6 Oct 2015 at 18:46 Thomas Goirand <z...@debian.org> wrote:
> >>
> >>> This IMO is the same topic as having a Gerrit review system (and not
> >>> just Git) which could do tests on each change of a package even before
> >>> having them committed to our git.
> >>>
> >>
> >> Sounds like an interesting thing to discuss/test after we move to git...
> > 
> > Moreover, jenkins.debian.org is happening right about now, guess it
> > would help quite something (and I'd be happy to host such tests there).
> 
> I don't think a single machine is enough for this kind of workload.
> Imagine the upload of a new setuptools and rebuilding all packages
> build-depending on it. That's a lot of packages to rebuild in
> jenkins.d.o. I have offers from some cloud providers which we could use
> instead for this kind of job. We "only" need to do the work...

jenkins.d.o won't build anything but only keep the master node (without
builders, or maybe one or two to do maintenance stuff).

If what you would like to do is to "just" rebuild all rdeps, that's
really one of the thing I'd really like to do, it just takes time do all
the work (and atm I'm busy doing other stuff, if that wasn't clear) :)

To be precise, what I plan is to really improve the current
reproducible.d.n scripts and base everything on them.
I'd like to support both rebuilds on a modified toolchain on demand and
on all r-deps of a particular packages which uploads would act as a
trigger.
It just takes a shitload of time I don't currently have, as usual.
Currently there are means to ask for rebuild of stuff using a particular
packages (through the AWS credit, managed by lucas &
I-don't-remember-who), but to me it looks like it's not really used if
not for big packages (like, before gcc uploads), and the results are
somewhat difficult to access and understand and often used by a single
person, which sucks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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: managing transitions (was: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental)

[Mattia Rizzolo]

On Tue, Oct 06, 2015 at 08:39:48AM +, Brian May wrote:
> On Tue, 6 Oct 2015 at 18:46 Thomas Goirand <z...@debian.org> wrote:
> 
> > This IMO is the same topic as having a Gerrit review system (and not
> > just Git) which could do tests on each change of a package even before
> > having them committed to our git.
> >
> 
> Sounds like an interesting thing to discuss/test after we move to git...

Moreover, jenkins.debian.org is happening right about now, guess it
would help quite something (and I'd be happy to host such tests there).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

[Mattia Rizzolo]

On Mon, Oct 05, 2015 at 05:11:26PM -0400, Barry Warsaw wrote:
> On Oct 05, 2015, at 02:51 PM, Thomas Goirand wrote:
> 
> >In other distributions (Red Hat and Ubuntu), everyone is aware of this
> >kind of issue before uploading, and this kinds of things don't happen.
> 
> Ubuntu at least does have a technical solution that helps ameliorate
> archive-wide breakages, and that is -proposed migration.  When you upload
> e.g. to wily, it gets diverted to wily-proposed and to get promoted it has to
> pass a number of tests.  The package and their reverses have to build.  DEP-8
> tests have to pass, etc.  You can get a nice report about which -proposed
> promotions are failing:
> 
> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
> 
> The downside is that you should probably be proactively checking this list
> (poll vs ping) and it can sometimes be difficult to figure out why a promotion
> fails or how to fix it.
> 
> But this does mean that the archive itself is very rarely broken, and it can
> be a convenient way to stage package updates that may have effects in parts of
> the archive you might not be aware of.

Isn't this the whole point of unstable→testing?

Ok, the debian testing migration might do really few checks compared to
ubuntu's, but still it's the same thing, and I believe RT would like to
add more checks (at lest dep-8 tests) someday.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

[Mattia Rizzolo]

On Mon, Oct 05, 2015 at 05:26:38PM -0400, Barry Warsaw wrote:
> On Oct 05, 2015, at 09:16 PM, Mattia Rizzolo wrote:
> 
> >Isn't this the whole point of unstable→testing?
> 
> I guess, although it seems a lot of people run unstable so breakages affect
> more people.  I run unstable on most of my Debian machines.  I think almost
> nobody actually runs -proposed.

Scott replied with more detailed info about the britney2-derived thing
Ubuntu runs.
And really, as he said and you guessed, ${ubuntu-devel}-proposed is not
meant for humans.

Debian's unstable is run by humans → more people affected by breakages →
quicker fixes.  This is how I see it, at least.
And by humans here I mean Debian developers/contributors.


Still getting Debian's britney2 use dep8 tests as a data point for
migrations would be really, really cool+useful.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature