Re: Status of pythondialog in Debian
'evening! Tristan Seligmann wrote: > Looks like your Debian account is marked emeritus; if you wish to > re-activate it you could follow the process described here: > > https://www.debian.org/doc/manuals/developers-reference/developer-duties.html#returning Thanks for the info, maybe later... > If you don't wish to do this, I think you would need to create a guest > account on Alioth (just sign up via the site) to use. Either way, you > can then apply to join DPMT here: > > https://alioth.debian.org/projects/python-modules OK, I've done that with my frn account, it is still usable. > I've added you to Uploaders in the meanwhile; I still want to do some > final checks on the package, but everything looks good so far, so I > will most likely be uploading the new version later today (although it > will still need to go through binary-NEW processing because of the new > python3-dialog package). Thank you very much, that was quick! I have subscribed using: http://packages.qa.debian.org/cgi-bin/pts.cgi?what=advanced&package=source_package_name&email=y...@email.com The package is already uploaded, right? -- Florent -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874muzeow8@frougon.crabdance.com
Re: Keeping upstream commits separate from Debian packaging commits
On 10/17/2014 01:01 AM, Tristan Seligmann wrote: > If such a tarball exists, and is suitable > for use in Debian, then having the upstream source in Debian match the > tarball distributed by upstream byte-for-byte makes it much easier to > verify that the source in Debian is unmodified from the upstream > source. I never understood why this is important, even though so many people told me they want to check for that. If the point is security, then I don't think we achieve anything by doing so. > This is harder when the tarball is generated from a git tag: > the source package does not include the information necessary to match > it against the git tag, comparing the individual files is necessary > instead of comparing the archive, and producing the upstream source > (.orig.tar.gz) will produce a tarball with different bytes every time > (even if the file contents will not change). This is anyway completely broken (see why Joey Hess decided to stop maintaining pristine-tar ...). > Alternatively, if you will never generate the upstream source from the > git repository, then you avoid this problem, but then building a > particular package version may require manually fetching the correct > tarball from the archive / snapshot.debian.org if they are no longer > available from the original source. When using xz compression, then anyway, the resulting orig.tar.xz will often not be the same when doing the same operation twice. So it's a broken concept. And I really hope you're not arguing that because of this, we should continue to use a 2 decade old compression thing... On 10/17/2014 02:12 AM, Hans-Christoph Steiner wrote: > I think there is a lot of value to always including the Debian > upstream/v1.0 tag. It provides a standard way to access the upstream > version across all repos. There is no such standard out there "in the > wild". There are tags like v1.0, 1.0, release-1.0, the-real-1.0, > etc. etc. The most common standard I've seen almost everywhere, is to use, for a version number, well ... just a version number. Eg, release version 1.0, then just tag 1.0. That's what you'll see almost everywhere. Yes, there's silly upstream who loves to prefix these with a single character (and surprisingly, they've decided it would be a "v"). But that's fine, just re-tag on top with: "git tag 1.0 v1.0" and then everything is fine. There's absolutely no need to re-tag "upstream/v1.0", that's a pristine-tar convention only, IMO. On 10/17/2014 11:19 PM, Dimitri John Ledkov wrote: > There are different tag types in git. "Soft" are just named commit > references and indeed can be renamed at will / point to new commits, > however signed tags encode: > object SHA1id > type type-of-above > tag tag-name > tagger normal user name, email, timestamp > > tag-message > > All signed with gpg. Thus any change to that metadata of a signed tag > will invalidate signature, or be treated as conflicting tag and thus > require --force push. > > Unsigned tags should not be publically used for e.g. release > identification. Though, if upstream publishes a gpg signed tag "v1.0", and then you don't like it and retag "1.0" on top, then it just points to the same pgp signature object, and you can still validate the signature. That's a very nice feature which I use often! :) On 10/17/2014 11:57 PM, Tristan Seligmann wrote: > The value of this is questionable if the upstream tags are unsigned, > especially if the released source tarballs *are* signed I haven't yet found any instance of the above. Most of the time, I see signed git tags, but no signed tarballs. On 10/17/2014 11:57 PM, Tristan Seligmann wrote: > I felt it > was worth the extra contortions to handle the upstream tags / > orig.tar.gz this way (the upstream tag in the packaging repository can > still be verified, as shown above). I did end up writing a 36 line > README.source discussing this process however... so I'm not sure how > suitable it is for the average DPMT/PAPT-maintained package. > > [1] The git repository is at > https://anonscm.debian.org/git/pkg-bitcoin/armory.git -- browse link > is https://anonscm.debian.org/cgit/pkg-bitcoin/armory.git My feeling is that it's not necessary. Just use upstream tags as-is, and do not attempt to prefix them with "upstream/", which adds very little to no benefits. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5445392a.4090...@debian.org
Re: Keeping upstream commits separate from Debian packaging commits
On 10/12/2014 09:30 PM, Scott Kitterman wrote: >> Also, during the Debconf discussion, we decided we would use the >> pristine-tar workflow, *not* using upstream VCS merge. A >> "git-import-orig" normally goes into a single commit, which I don't >> think would bother anyone (not on the list, or on IRC). While I don't >> agree with this decision, I prefer to just import upstream VCS and do >> packaging based on tags, but I will still respect it when packaging in >> the DPMT. Anyone who doesn't respect what we are collectively agree on >> should IMO take the blame for what happened on IRC and on the commit >> list, and pointing fingers at whoever configured it is IMO wrong. > > It's my fault someone else configured their git repos so IRC and the > ML get flooded? That's not what I wrote. Of course, it's not your fault. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54453af3.60...@debian.org
Re: Using pristine-tar
On 10/13/2014 06:14 AM, Barry Warsaw wrote: > In practice, I haven't seen any problems with pristine-tar. And given that > archive uploads still currently require a tarball, and PyPI releases are > overwhelmingly tarball-based, I think it still makes sense for DPMT to > continue to use pristine-tar workflows by default. In practice as well, I roughly estimate that 95% of upstream authors are these days using Git. Since we decided to use pristine-tar, I'll do that, but I still think it's the wrong choice, especially if you can find an upstream publicly accessible Git repo, and since we already know that pristine-tar is broken. So, just generating the orig.tar.xz from upstream Git tag, in practice, does the same thing as pristine-tar, except that you *know* you have to take past orig.tar.xz from the Debian archive, always, instead of discovering that pristine-tar lead to issues. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54453b90.8090...@debian.org
Re: Keeping upstream commits separate from Debian packaging commits
On 10/13/2014 06:11 AM, Barry Warsaw wrote: >> While I don't agree with this decision, I prefer to just import upstream VCS >> and do packaging based on tags, but I will still respect it when packaging in >> the DPMT. > > Thank you. I personally appreciate the accommodations to the majority team > decision. While I think it's important to do team work, and agree on some workflow conventions, I still want to explain my point of view, in the hope to make things better. I just hope I don't bother everyone too much with it... (I know I do...). Please keep in mind that this really is because I want the best and most efficient workflow, and the purpose is *not* to be annoying! :) Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54453ce2.3020...@debian.org
Re: Keeping upstream commits separate from Debian packaging commits
On Oct 21, 2014, at 12:48 AM, Thomas Goirand wrote: >While I think it's important to do team work, and agree on some workflow >conventions, I still want to explain my point of view, in the hope to >make things better. I just hope I don't bother everyone too much with >it... (I know I do...). Please keep in mind that this really is because >I want the best and most efficient workflow, and the purpose is *not* to >be annoying! :) Absolutely! I enjoy learning about other workflows, especially ones that others have good success with. It occurs to me too that the switch from svn to git (e.g. git-dpm) is already a large change to current team workflow, and dropping pristine-tar might just be too big a move to also do right now. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141020135534.28405...@anarchist.wooz.org
Re: Using pristine-tar
Le Tue, Oct 21, 2014 at 12:42:56AM +0800, Thomas Goirand a écrit : > > So, just generating the orig.tar.xz from upstream Git tag, in practice, > does the same thing as pristine-tar, except that you *know* you have to > take past orig.tar.xz from the Debian archive, always, instead of > discovering that pristine-tar lead to issues. Hi Thomas, this is two separate questions: - The source of the tarball: upstream or generated by the maintainer. - Making the tarball reproducible off-line with pristine-tar. I you generate a orig.tar.xz by yourself, then you can (or have to if it is the packaging team's requirement) register it with the command “pristine-tar ”. Since it is not much work, I thing that it is fair to ask people to do it even if personally they do not use it. Also, if one happens to forget (which I of course do not encourage), another person working on the package can just download the source package from the Debian archive, and register the tarball in the pristine-tar branch with the command above. Pristine-tar is much about preparing a package update while not having access to the Debian archive at the same time. Two' invokations of git-archive will not necessary generate byte-identical tarballs. However, when updating only the Debian part of a packags, one needs an identical copy of the tarball already present in the Debian archive, or at the very least its MD5 sum. As you see pristine-tar can be more usful to some than to others, but altogether it is easy and not much involving. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141020221838.GA8549@aqwa.igloo
Re: Status of pythondialog in Debian
On 19 October 2014 23:21, Florent Rougon wrote: > Thank you very much, that was quick! I have subscribed using: > > > http://packages.qa.debian.org/cgi-bin/pts.cgi?what=advanced&package=source_package_name&email=y...@email.com > > The package is already uploaded, right? It is, and processed through NEW. I uploaded -2 earlier today to fix #766041 and I believe it is now in unstable; it looks like the PTS isn't updated yet, though, possibly related to some problems with Debian infrastructure at the moment[1]. [1] http://article.gmane.org/gmane.linux.debian.infrastructure.announce/142 -- mithrandi, i Ainil en-Balandor, a faer Ambar -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAMcKhMTp+kPr+VX==afjeykmrdechfwyjjwsixxyrkocagk...@mail.gmail.com
Re: Using pristine-tar
Hi, Charles Plessy: > Pristine-tar is much about preparing a package update while not having access > to the Debian archive at the same time. Two' invokations of git-archive will > not necessary generate byte-identical tarballs. Two invocations of pristine-tar will not, either, if you happen to use a different version of tar than the one used to prepare the pristine-tar entry. I'd rather record the .orig.tar.?z's exact size and hash(es). -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Using pristine-tar
On 10/21/2014 06:18 AM, Charles Plessy wrote: > I you generate a orig.tar.xz by yourself, then you can (or have to if it is > the > packaging team's requirement) register it with the command “pristine-tar > ”. Since it is not much work, I thing that it > is fair to ask people to do it even if personally they do not use it. If we use xz compression, it simply wont work. And in such case, just using "git archive" achieves the same goal, but with a single unique packaging branch, which is a way better. The only thing is that this should be wired-in in debian/rules (which is what I always do). > Pristine-tar is much about preparing a package update while not having access > to the Debian archive at the same time. Doing this with a stored git tag and "git archive" provides the same convenience. > Two' invokations of git-archive will > not necessary generate byte-identical tarballs. Same with pristine-tar if using xz... And there's also this: On 10/21/2014 11:15 AM, Matthias Urlichs wrote: > Two invocations of pristine-tar will not, either, if you happen to > use a different version of tar than the one used to prepare the > pristine-tar entry. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5445e154.9050...@debian.org
Re: Keeping upstream commits separate from Debian packaging commits
On 10/21/2014 01:55 AM, Barry Warsaw wrote: > It occurs to me too that the switch from svn to git (e.g. git-dpm) is already > a large change to current team workflow, and dropping pristine-tar might just > be too big a move to also do right now. And things should move/improve incrementally as well, so that everyone has enough time to get used to it. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5445e1ac.50...@debian.org
