Re: Re: Bug#920127: Removed package(s) from unstable
On September 9, 2019 3:25:43 AM UTC, Paul Wise wrote: >On Mon, Sep 9, 2019 at 4:11 AM Scott Kitterman wrote: > >> This was sent to the FTP Team, but it seems like someone with some >bandwidth >> to assist from DPMT/PAPT would be a better audience. Note that the >removal's >> already been done, but if someone wants to sponsor a python3 update >to the >> package, they can ping me for a quick trip through New to bring it >back. > >It seems like a little bit more due diligence is needed before filing >removals. In theory yes, but in practice because this is a multi-thousand package transition we're trying to get through, I think it's better to move fast even if we break a few things than to be super careful and slow. Things like this can be fixed. It's better to push hard early in the development cycle so there's time to recover. Scott K
Re: Re: Bug#920127: Removed package(s) from unstable
On Sun, Sep 8, 2019 at 11:26 PM Paul Wise wrote: > > On Mon, Sep 9, 2019 at 4:11 AM Scott Kitterman wrote: > > > This was sent to the FTP Team, but it seems like someone with some bandwidth > > to assist from DPMT/PAPT would be a better audience. Note that the > > removal's > > already been done, but if someone wants to sponsor a python3 update to the > > package, they can ping me for a quick trip through New to bring it back. > > It seems like a little bit more due diligence is needed before filing > removals. Nope. This package did not see an upload since Aug 2013. it was orphaned since Jan 2019. Nobody stepped up. It ended up removed. If the upstream author or a debian packager wants it in debian, it's easy enough to re-introduce it. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Re: Re: Bug#920127: Removed package(s) from unstable
On Mon, Sep 9, 2019 at 4:11 AM Scott Kitterman wrote: > This was sent to the FTP Team, but it seems like someone with some bandwidth > to assist from DPMT/PAPT would be a better audience. Note that the removal's > already been done, but if someone wants to sponsor a python3 update to the > package, they can ping me for a quick trip through New to bring it back. It seems like a little bit more due diligence is needed before filing removals. -- bye, pabs https://wiki.debian.org/PaulWise
PyConFR and python packaging
Hi Samuel, I want make a Talks for PyConAr (Argentina). I send a mail https://lists.debian.org/debian-python/2019/08/msg00158.html asking about my ideas. So I will send my proposal with that ideas. If you (and the community) have some comments or advices, please let me know. They are welcomes :-) Cheers, Arias Emmanuel @eamanu http://eamanu.com
Fwd: Re: Bug#920127: Removed package(s) from unstable
This was sent to the FTP Team, but it seems like someone with some bandwidth to assist from DPMT/PAPT would be a better audience. Note that the removal's already been done, but if someone wants to sponsor a python3 update to the package, they can ping me for a quick trip through New to bring it back. Scott K - Forwarded Message -- Subject: Re: Bug#920127: Removed package(s) from unstable Date: Sunday, September 8, 2019, 3:05:59 PM EDT From: John Eikenberry To: Debian FTP Masters Hello, I am up upstream maintainer for colortest-python and wanted to communicate that it is not dead and it fully supports running with python3. I responded with the same message to the ticket about this (#936320). I'd be happy to help maintain it the package if necessary. Thanks. Debian FTP Masters wrote: > We believe that the bug you reported is now fixed; the following > package(s) have been removed from unstable: > > colortest-python | 2.2-1 | source, all > > --- Reason --- > python2-only; orphaned; dead upstream; low popcon > -- > > Note that the package(s) have simply been removed from the tag > database and may (or may not) still be in the pool; this is not a bug. > The package(s) will be physically removed automatically when no suite > references them (and in the case of source, when no binary references > it). Please also remember that the changes have been done on the > master archive and will not propagate to any mirrors until the next > dinstall run at the earliest. > > Packages are usually not removed from testing by hand. Testing tracks > unstable and will automatically remove packages which were removed > from unstable when removing them from testing causes no dependency > problems. The release team can force a removal from testing if it is > really needed, please contact them if this should be the case. > > We try to close bugs which have been reported against this package > automatically. But please check all old bugs, if they were closed > correctly or should have been re-assigned to another package. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 920...@bugs.debian.org. > > The full log for this bug can be viewed at https://bugs.debian.org/920127 > > This message was generated automatically; if you believe that there is > a problem with it please contact the archive administrators by mailing > ftpmas...@ftp-master.debian.org. > > Debian distribution maintenance software > pp. > Scott Kitterman (the ftpmaster behind the curtain) > -- John Eikenberry [ j...@zhar.net - http://zhar.net ] "Perfection is attained, not when no more can be added, but when no more can be removed." -- Antoine de Saint-Exupery -
Re: Git, gbp blues
On Sat, Sep 07, 2019 at 11:57:42PM +0200, Guðjón Guðjónsson wrote: > Hi again > > One more question. > If I have updated the sources with uscan and when running lintian I > find out that > there is an unwanted file in the upstream sources. > > How can I remove the file from the upstream tarball after it has been > imported into upstream and pristine-tar? If the tarball was not previously repacked, then you need to use a different version number (e.g. +dfsg or +repack). List the file in Files-Excluded in debian/copyright and add repack options to debian/rules (e.g. opts=dversionmangle=s/\+dfsg//,repacksuffix=+dfsg — see pyqt5 for example). After that, you have a new upstream version so you can import the tarball using the normal procedure (gbp import-orig --uscan --pristine-tar). Although, this depends on how much unwanted the file is. If it does not violate DFSG and is not large, then it may be better to leave the tarball as is and add that file to debian/clean. If the tarball is already repacked, and you need to exclude one more file (and you have not yet uploaded the current version to archive), then I would suggest you to manually remove the files from upstream branch, and run pristine-tar commit after generating the new tarball. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Git, gbp blues
Hi Guðjón, On Sat, Sep 07, 2019 at 08:44:53AM +0200, Guðjón Guðjónsson wrote: > I am now working on my gspiceui package (which is in fact not a python > package) > But the master branch is just master, not debian/master > > Here debian/master is preferred > https://wiki.debian.org/Python/GitPackaging > > But in this page the branch name is master. > https://wiki.debian.org/PackagingWithGit > > What is the standard? > Shall I change? If the package is not in DPMT or PAPT then you can use any branch names. Just if you use debian/master, do not forget to specify it in debian/gbp.conf (gbp expects master by default). There is an attempt to standardize, DEP-14 (which suggests debian/master), but it is not yet widely adopted: https://dep-team.pages.debian.net/deps/dep14/ -- Dmitry Shachnev signature.asc Description: PGP signature
