Re: Keeping upstream commits separate from Debian packaging commits

[Dimitri John Ledkov]

On 17 October 2014 16:57, Tristan Seligmann  wrote:
> On 17 October 2014 17:19, 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.
>
> I stand corrected, tag objects do indeed include a name. However, this
> name does not have to be the same as the name of the ref to that tag!
> For example, in a package I recently helped sponsor[1]:
>

LOLz!!!

was my initial reaction.

But honestly, this does sounds a bit broken =) I was not aware of this property.

It does make sense that a signed tag object has unique sha1 and thus
one can create multiple tags named "foo" with different sha1 IDs and
thus store them in a single git object store without ref names and/or
different ref names. However the implications of this are rather
severe - what if I copy/rename v1.0.3 tag as a v1.0.5 tag in my mirror
and thus trick people into an older version...

I'm concerned by this, I'll checkout git mailing list and/or raise
this issue there.

For some time now I have switched to providing people with sha1id of a
GPG signed commit, instead pushing signed tags and providing a signed
tag name only. That was only for the sake of minimising amount of refs
i publish/pollute. I guess this is for the best.

Regards,

Dimitri.


> mithrandi@lorien ~/d/p/armory> git tag -l | grep 0.92.3
> debian/0.92.3-1
> upstream/v0.92.3
> mithrandi@lorien ~/d/p/armory> git tag -v upstream/v0.92.3
> object 268db0f3fa20c989057bd43343a43b2edbe89aeb
> type commit
> tag v0.92.3
> tagger Armory Technologies, Inc  1412648447 -0400
>
> Tor privacy fixes and msg signing RNG fix
> gpg: Signature made Tue 07 Oct 2014 04:20:47 SAST using RSA key ID 98832223
> gpg: Good signature from "Alan C. Reiner (Offline Signing Key)
> "
> gpg: aka "Alan C. Reiner (Armory Signing Key)
> "
> gpg: aka "Alan C. Reiner (Armory Signing Key)
> "
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to the owner.
> Primary key fingerprint: 821F 1229 36BD D565 366A  C36A 4AB1 6AEA 9883 2223
>
> You'll notice that I've prefixed the upstream refs with upstream/ in
> order to organise them; it is possible to do this automatically with a
> configuration like:
>
> git config remote.upstream.tagopt --no-tags
> git config --add remote.upstream.fetch '+refs/tags/*:refs/tags/upstream/*'
>
> However, the name does not match the standard git-buildpackage naming
> scheme exactly (prefixed with 'v'), so setting --git-upstream-tag is
> necessary. You could avoid this at the cost of having to fetch each
> tag manually, with something like:
>
> mithrandi@lorien ~/d/p/armory> git fetch upstream
> +refs/tags/v0.92.3:refs/tags/upstream/this-is-nonsense
> From github.com:etotheipi/BitcoinArmory
>  * [new tag] v0.92.3-> upstream/this-is-nonsense
> mithrandi@lorien ~/d/p/armory> git tag -v upstream/this-is-nonsense
> object 268db0f3fa20c989057bd43343a43b2edbe89aeb
> type commit
> tag v0.92.3
> tagger Armory Technologies, Inc  1412648447 -0400
>
> Tor privacy fixes and msg signing RNG fix
> gpg: Signature made Tue 07 Oct 2014 04:20:47 SAST using RSA key ID 98832223
> gpg: Good signature from "Alan C. Reiner (Offline Signing Key)
> "
> gpg: aka "Alan C. Reiner (Armory Signing Key)
> "
> gpg: aka "Alan C. Reiner (Armory Signing Key)
> "
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to the owner.
> Primary key fingerprint: 821F 1229 36BD D565 366A  C36A 4AB1 6AEA 9883 2223
>
> And thus name the ref whatever you like locally, regardless of what
> upstream's name is. Since all of the commands that operate on a
> revision take the ref name as an argument, not the actual name given
> in the tag object, this is all that matters for things like
> pristine-tar (which just records the commit id regardless of how you
> identify the commit to use) and git-buildpackage.
>
> The value of this is questionable if the upstream tags are unsigned,
> especially if the released source tarballs *are* signed (in which case
> they can be verified by uscan...but only as long as they continue to
> be published, since the upstream signature is not kept anywhere in
> Debian). In the case of Armory, upstream does not publish source
> tarballs at all, only binary releases; the primary source release
> mechanism is through signed tags in their git repository, so I felt it
> was worth the extra contortions to handle the upstream tags /
> orig.tar.gz this way (

Re: Keeping upstream commits separate from Debian packaging commits

[Tristan Seligmann]

On 17 October 2014 17:19, 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.

I stand corrected, tag objects do indeed include a name. However, this
name does not have to be the same as the name of the ref to that tag!
For example, in a package I recently helped sponsor[1]:

mithrandi@lorien ~/d/p/armory> git tag -l | grep 0.92.3
debian/0.92.3-1
upstream/v0.92.3
mithrandi@lorien ~/d/p/armory> git tag -v upstream/v0.92.3
object 268db0f3fa20c989057bd43343a43b2edbe89aeb
type commit
tag v0.92.3
tagger Armory Technologies, Inc  1412648447 -0400

Tor privacy fixes and msg signing RNG fix
gpg: Signature made Tue 07 Oct 2014 04:20:47 SAST using RSA key ID 98832223
gpg: Good signature from "Alan C. Reiner (Offline Signing Key)
"
gpg: aka "Alan C. Reiner (Armory Signing Key)
"
gpg: aka "Alan C. Reiner (Armory Signing Key)
"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 821F 1229 36BD D565 366A  C36A 4AB1 6AEA 9883 2223

You'll notice that I've prefixed the upstream refs with upstream/ in
order to organise them; it is possible to do this automatically with a
configuration like:

git config remote.upstream.tagopt --no-tags
git config --add remote.upstream.fetch '+refs/tags/*:refs/tags/upstream/*'

However, the name does not match the standard git-buildpackage naming
scheme exactly (prefixed with 'v'), so setting --git-upstream-tag is
necessary. You could avoid this at the cost of having to fetch each
tag manually, with something like:

mithrandi@lorien ~/d/p/armory> git fetch upstream
+refs/tags/v0.92.3:refs/tags/upstream/this-is-nonsense
>From github.com:etotheipi/BitcoinArmory
 * [new tag] v0.92.3-> upstream/this-is-nonsense
mithrandi@lorien ~/d/p/armory> git tag -v upstream/this-is-nonsense
object 268db0f3fa20c989057bd43343a43b2edbe89aeb
type commit
tag v0.92.3
tagger Armory Technologies, Inc  1412648447 -0400

Tor privacy fixes and msg signing RNG fix
gpg: Signature made Tue 07 Oct 2014 04:20:47 SAST using RSA key ID 98832223
gpg: Good signature from "Alan C. Reiner (Offline Signing Key)
"
gpg: aka "Alan C. Reiner (Armory Signing Key)
"
gpg: aka "Alan C. Reiner (Armory Signing Key)
"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 821F 1229 36BD D565 366A  C36A 4AB1 6AEA 9883 2223

And thus name the ref whatever you like locally, regardless of what
upstream's name is. Since all of the commands that operate on a
revision take the ref name as an argument, not the actual name given
in the tag object, this is all that matters for things like
pristine-tar (which just records the commit id regardless of how you
identify the commit to use) and git-buildpackage.

The value of this is questionable if the upstream tags are unsigned,
especially if the released source tarballs *are* signed (in which case
they can be verified by uscan...but only as long as they continue to
be published, since the upstream signature is not kept anywhere in
Debian). In the case of Armory, upstream does not publish source
tarballs at all, only binary releases; the primary source release
mechanism is through signed tags in their git repository, so 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
-- 
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/camckhmsn0trwfex97kylkqq5w-uyeeomcwtb0cwf_o9c7ez...@mail.gmail.com

Re: Status of pythondialog in Debian

[Florent Rougon]

Hi,

Barry Warsaw  wrote:

> Please note that this is not a team-maintained package.  We could do a
> non-maintainer upload of it, but I'd rather see either 1) Adam, the current
> maintainer CC'd here, update the package, or 2) have Adam move the package to
> the Debian Python team, where we could collectively maintain it going
> forward.

As Mathias pointed out, the package in Debian has been abandoned for a
long time...

> That's excellent, thanks, and should help us (either the team or Adam) update
> the package.  Would you be able to file a bug on the package in Debian, and
> attach a diff (debdiff) of your packaging changes?
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=python-dialog

I'm not sure it is the way to go: current pythondialog versions only
support Python 3, although I made a backport of version 3.0.1 to
Python 2 (). The
implication is that python-dialog (currently in Debian) and
python3-dialog (as mentioned in my previous message) are different
source packages, built from different upstream tarballs. My packaging
isn't based on python-dialog either, but loosely on enum34 and the
suggestions from the Debian wiki. Even though many people are still
using Python 2, making substantial efforts to support it as well as
Python 3 is not a good use of resources IMHO...

Thanks

-- 
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/87tx32znye@frougon.crabdance.com

Re: Keeping upstream commits separate from Debian packaging commits

[Dimitri John Ledkov]

On 17 October 2014 07:39, Tristan Seligmann  wrote:
> On 16 October 2014 20:12, Hans-Christoph Steiner  wrote:
>>
>>
>> Tristan Seligmann wrote:
>>> If you are fetching the upstream revisions / tags into your packaging
>>> repository, you can use the upstream tag exactly as-is, no need to
>>> re-tag (and indeed re-tagging would generally be a bad idea).
>>
>> 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.
>
> Renaming the tag does not require retagging, git tag objects (perhaps
> unfortunately) do not include their name.

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.

-- 
Regards,

Dimitri.


-- 
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/CANBHLUgEnJ0P=s47lxsxu1hoefxo-_eishw+msvznpn9oh1...@mail.gmail.com

Re: Status of pythondialog in Debian

[Matthias Klose]

Am 17.10.2014 um 17:03 schrieb Barry Warsaw:
> Hi Florent,
> 
> On Oct 17, 2014, at 04:17 PM, Florent Rougon wrote:
> 
>> As the upstream maintainer of pythondialog, I feel a bit concerned about
>> its status in Debian, in particular about what is going to go into
>> jessie. In short, I'd rather see the package removed from Debian than
>> stay in the current status.
> 
> Please note that this is not a team-maintained package.  We could do a
> non-maintainer upload of it, but I'd rather see either 1) Adam, the current
> maintainer CC'd here, update the package, or 2) have Adam move the package to
> the Debian Python team, where we could collectively maintain it going
> forward.

see #673962. while it is ITA, there is no action, and it should be orphaned
again. Or adopt it.


-- 
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/54413093.30...@debian.org

Re: Status of pythondialog in Debian

[Barry Warsaw]

Hi Florent,

On Oct 17, 2014, at 04:17 PM, Florent Rougon wrote:

>As the upstream maintainer of pythondialog, I feel a bit concerned about
>its status in Debian, in particular about what is going to go into
>jessie. In short, I'd rather see the package removed from Debian than
>stay in the current status.

Please note that this is not a team-maintained package.  We could do a
non-maintainer upload of it, but I'd rather see either 1) Adam, the current
maintainer CC'd here, update the package, or 2) have Adam move the package to
the Debian Python team, where we could collectively maintain it going
forward.

>The package that is currently in unstable is terribly outdated (the
>version dates from 2004), has a few bugs, supports neither Unicode
>correctly nor Python 3, contrary to current upstream versions, not to
>mention a bunch of features including help and extra button support,
>easy pythondialog and backend version checking, autowidgetsize and the
>new Sphinx-generated manual[1].
>
>In case someone is interested, I've prepared a package of the latest
>version for Python 3, using dh, dh_python3 and pybuild, following the
>suggestions given on the Debian Python wiki (which is nice to have,
>thank you!).

That's excellent, thanks, and should help us (either the team or Adam) update
the package.  Would you be able to file a bug on the package in Debian, and
attach a diff (debdiff) of your packaging changes?

https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=python-dialog

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/20141017110335.50d2a...@anarchist.wooz.org

Status of pythondialog in Debian

[Florent Rougon]

Hello,

As the upstream maintainer of pythondialog, I feel a bit concerned about
its status in Debian, in particular about what is going to go into
jessie. In short, I'd rather see the package removed from Debian than
stay in the current status.

The package that is currently in unstable is terribly outdated (the
version dates from 2004), has a few bugs, supports neither Unicode
correctly nor Python 3, contrary to current upstream versions, not to
mention a bunch of features including help and extra button support,
easy pythondialog and backend version checking, autowidgetsize and the
new Sphinx-generated manual[1].

In case someone is interested, I've prepared a package of the latest
version for Python 3, using dh, dh_python3 and pybuild, following the
suggestions given on the Debian Python wiki (which is nice to have,
thank you!). It has been built on current sid and is available in the
following GPG-signed APT repository:

  deb http://people.via.ecp.fr/~flo/debian unstable main
  deb-src http://people.via.ecp.fr/~flo/debian unstable main

(along with other packages, don't upgrade blindly if you add the
repository to your sources.list)

Thanks

  [1] http://pythondialog.sourceforge.net/doc/

-- 
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/871tq62320@frougon.crabdance.com