Re: Securely retrieving dscs from snapshot.debian.org

[Paul Wise]

On Sat, Dec 30, 2017 at 6:57 PM, peter green wrote:

> * what keys would be used to sign these re-signed release files? You
> wouldn't want to use a regular Debian archive key because you wouldn't want
> people to be able to use snapshots to attack Debian users.

They would have to be separate keys to the Debian archive key because
that is on a HSM.

> * How secure would the re-signing infrastructure be?

I guess the signing would have to be online and on-demand, so we
probably would have one offline key with subkeys in HSMs at each
snapshot location.

> It wouldn't solve the issue of how to find that
> damn Release/Sources pair in the first place.

I would leave that part to apt plus the API:

https://anonscm.debian.org/cgit/mirror/snapshot.debian.org.git/tree/API
http://snapshot.debian.org/mr/package/iotop/
http://snapshot.debian.org/mr/package/iotop/0.6-2/srcfiles
http://snapshot.debian.org/mr/file/3671b737bad959b7c76dc1fad205951965b54f9a/info
http://snapshot.debian.org/archive/debian/20160729T163942Z/pool/main/i/iotop/iotop_0.6.orig.tar.gz.asc
deb-src http://snapshot.debian.org/archive/debian/20160729T163942Z/

> I have attatched my attempt at a tool for downloading source packages
> securely from snapshot.debian.org. It seems to work, comments/improvements
> welcome.

If you would like to add more endpoints to the API, that would
probably be a good idea to reduce the complexity of your script.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Securely retrieving dscs from snapshot.debian.org

[peter green]

On 27/12/17 23:42, Paul Wise wrote:

On Thu, Dec 28, 2017 at 5:41 AM, peter green wrote:


Unfortunately there doesn't seem to be a good way to securely retrive a dsc
from snapshot.debian.org given a package name and version number.

At this time there isn't any good way to do that securely, until
#763419 gets implemented.

That may help a little, though it raises questions of it's own, like

* what keys would be used to sign these re-signed release files? You wouldn't 
want to use a regular Debian archive key because you wouldn't want people to be 
able to use snapshots to attack Debian users.
* How secure would the re-signing infrastructure be?

And it would only solve one aspect of the problem, the fact that verifying 
Release signatures may involve old keys. It wouldn't solve the issue of how to 
find that damn Release/Sources pair in the first place.

I have attatched my attempt at a tool for downloading source packages securely 
from snapshot.debian.org. It seems to work, comments/improvements welcome.
#!/usr/bin/python3
import sys
import urllib.request
import urllib.error
import json
from bs4 import BeautifulSoup
import re
import deb822
import io
import gzip
import bz2
import lzma
import os
import subprocess
import hashlib
import argparse

parser = argparse.ArgumentParser(description="retrieve a source package from 
snapshot.debian.org with gpg verification\n"+
"the source package will be stored in the current directory\n"+
"in the process of verification files source_version_Release and 
source_version_Release.gpg will be created in the current directory, these will 
be "+
"removed unless --keepevidence is specified"
)
parser.add_argument("source", help="source package name")
parser.add_argument("version", help="source package version")
parser.add_argument("--keepevidence", help="keep Release.gpg, Release and 
Sources files as evidence of package integrity", action="store_true")
parser.add_argument("--1024", help="allow 1024 bit keys, this is needed for old 
packages but may leave you vulnerable to well-funded 
attackers",action="store_true",dest='allow_1024')
args = parser.parse_args()

package=args.source
version=args.version
scriptdir=os.path.dirname(os.path.realpath(__file__))

colonpos = version.find(':')

#regex used for checking  package name
pnallowed = re.compile('[a-z0-9][a-z0-9\-\+\.]+',re.ASCII)

#regex used for checking version number
#this is not a full implementation of Debian version number rules
#just a sanity check for unexcepted characters
vallowed = re.compile('[a-z0-9\-:\+~\.]+',re.ASCII)

#regex used for checking allowed characters in package filenames
#and a few other things.
pfnallowed = re.compile('[a-z0-9\-_:\+~\.]+',re.ASCII)

#regex used for checked allowed characters in timestamp strings
tsallowed = re.compile('[A-Z0-9]+',re.ASCII)

#regex used for matching duplicate or aincient (no Release.gpg) distribution 
names
dupain = 
re.compile('(Debian.*|bo.*|buzz.*|hamm.*|potato|rex|slink.*)/',re.ASCII)

if not pnallowed.fullmatch(package):
print('package name fails to match required format')

if not vallowed.fullmatch(package):
print('version number fails to match required format')

if colonpos >= 0:
versionnoepoch=version[colonpos+1:]
else:
versionnoepoch=version

url='http://snapshot.debian.org/mr/package/'+package+'/'+version+'/srcfiles?fileinfo=1'

with urllib.request.urlopen(url) as response:
jsondata = response.read()

jsondecoded = json.loads(jsondata.decode("utf-8"))

instances = []
for sha1, info in jsondecoded['fileinfo'].items():
for instance in info:
#print(repr(instance))
if instance['name'] == package+'_'+versionnoepoch+'.dsc':
#print(repr(instance))
instances.append(instance)

#unfortunately snapshot.debian.org doesn't seem to provide a mr interface for 
file listings, so we have to screen scrape
#the aim here is to only get true subdirs, not files or symlinks, these seem to 
be indicated by a trailing / in the link
#string. We also need to avoid any links with complex urls, which likely 
represent page chrome.
def snapshotsubdirlist(url):
result = []
with urllib.request.urlopen(url) as response:
pagedata = response.read()
soup = BeautifulSoup(pagedata, "lxml")
p = re.compile('[a-zA-Z0-9\-]+/',re.ASCII)
for item in soup.find_all('a'):
if not (finalentry is None): break
link = item['href']
if (p.fullmatch(link)):
result.append(link)
return result

#ideally we want sha256 but sometimes that doesn't exist
def findmostsecurereleasefiles(deb822):
if 'SHA256' in deb822:
return deb822['SHA256']
if 'SHA1' in deb822:
return deb822['SHA1']
return deb822['MD5SUM']

def findmostsecurespfiles(deb822):
if 'Checksums-Sha256' in deb822:

Re: Securely retrieving dscs from snapshot.debian.org

[Paul Wise]

On Thu, Dec 28, 2017 at 5:41 AM, peter green wrote:

> Unfortunately there doesn't seem to be a good way to securely retrive a dsc
> from snapshot.debian.org given a package name and version number.

At this time there isn't any good way to do that securely, until
#763419 gets implemented.

https://bugs.debian.org/763419

Your options are:

You can use debsnap, which is easy but not secure.

$ debsnap srcpkg version

Debian members can login to lw08.debian.org, that has NFS access to
the snapshot archive and guest access to the snapshot meta-data
database. That is probably the most secure you can get right now.
There are some Python functions for interacting with the DB here:

https://anonscm.debian.org/cgit/dex/census.git/tree/bin/compare-source-package-list#n517

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Prendi uno Spin sull'ultimo Casinò Ora!

[Alicia]

Visualizzazione
immagine qui sotto












































All rights reserved © 2017 AlphaInfolab Pvt. Ltd.
| Unsubscribe.

 
 
 










___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

autoforwardportergit call for testing.

[Peter Michael Green]

I have been working the past few days to remove raspbian-specific 
assumptions from autoforwardportergit and adding some documentation.


Autoforwardportergit is a tool for automating the process or merging
downstream changes with new versions from Debian.

At this point I would really appreciate people trying it out and telling 
me what they think.





___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: extracting upstream source.

[Ian Jackson]

Package: dgit
Version: 3.12

Peter Green writes ("extracting upstream source."):
> As part of my dgit based autoforwardporter I want to add a script that will 
> de-fuzz patches with fuzz and remove patches that cannot be applied.
> 
> To do this I need the "upstream" source tree. However the process of 
> extracting the upstream source is quite fiddly, there may be multiple 
> tarballs to deal with, tarballs may or may not have a top-level directory 
> that needs to be removed from the paths etc.
> 
> Both dpkg-source ("commit" and "build")and dgit (quilt fixup) clearly extract 
> the upstream source tree as part of their processing, so the code to do it 
> already exists but i'm not sure if there is a convenient way to access it.

dgit often has "something like" the upstream source tree as a git tree
object.  dgit should provide a way for you to get at it.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: extracting upstream source.

[Robie Basak]

On Tue, Jul 25, 2017 at 03:55:08PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: extracting upstream source."):
> > dgit often has "something like" the upstream source tree as a git tree
> > object.  dgit should provide a way for you to get at it.
> 
> This is now #869675.

For our Ubuntu git work, we're using pristine-tar branches to provide
these.


signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: extracting upstream source.

[Ian Jackson]

Ian Jackson writes ("Re: extracting upstream source."):
> dgit often has "something like" the upstream source tree as a git tree
> object.  dgit should provide a way for you to get at it.

This is now #869675.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

extracting upstream source.

[Peter Green]

As part of my dgit based autoforwardporter I want to add a script that will 
de-fuzz patches with fuzz and remove patches that cannot be applied.

To do this I need the "upstream" source tree. However the process of extracting 
the upstream source is quite fiddly, there may be multiple tarballs to deal with, 
tarballs may or may not have a top-level directory that needs to be removed from the 
paths etc.

Both dpkg-source ("commit" and "build")and dgit (quilt fixup) clearly extract 
the upstream source tree as part of their processing, so the code to do it already exists but i'm 
not sure if there is a convenient way to access it.

Any hints?



___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

[Robie Basak]

On Tue, Jun 13, 2017 at 03:18:27PM +0100, Ian Jackson wrote:
> Robie Basak writes ("Re: "git ubuntu" wrappers [was: What to do with .git 
> directories in source package uploads?]"):
> > I disagree here. We don't need to "hope". I don't expect the build to
> > see the importer's git history. It should be invisible to the build
> > process, and I intend to make our "git ubuntu build" wrapper make it
> > invisible.
> 
> I think this is the key difference in our points of view.

OK. I think we have agreement on the imported format though - the
principle of escaping on the way in? This matters more I think, because
if we agree then we get better compatibility.

Robie


signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

[Robie Basak]

On Tue, Jun 13, 2017 at 03:04:46PM +0100, Robie Basak wrote:
>   1. The imported git trees are defined to escape /^\.git.*/ by
>  prepending a '.'.

It just occurred to me that this would also escape '.gitignore' to
'..gitignore', which personally I'd like, but others might find
surprising. So the exact escaping rule might need a little more
thought/debate. I certainly want to escape '.git' to '..git' though, and
to avoid edge cases we also need to escape '..git' to '...git' and so
on. So perhaps the match should be /^\.+git$/.

Robie


signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

[Ian Jackson]

Robie Basak writes ("Re: "git ubuntu" wrappers [was: What to do with .git 
directories in source package uploads?]"):
> I disagree here. We don't need to "hope". I don't expect the build to
> see the importer's git history. It should be invisible to the build
> process, and I intend to make our "git ubuntu build" wrapper make it
> invisible.

I think this is the key difference in our points of view.

I look forward to a future where users routinely build Debian-format
source packages from their distro's provided git history.  For a user,
in the most usual and simplest case, these will usually be in-tree
builds run from the git working directory using dpkg-buildpackage.

In this future world, the "distro's" .git (ie, in your case, your
importer's) is present in the user's working tree.

I doubt that there are a significant number of package build systems
which rely on the presence or absence (or specific contents) of .git,
(or for that matter of ..git).  If such things exist right now they
need to be fixed ASAP - but I very much doubt they do.

Building historical versions ad-hoc may need an ad-hoc "detransform"
step; but in general, building historical versions is going to be
quite hard anyway for a whole host of reasons.  Building historical
versions in bulk may need the detransform to be automated, but this
should be confined to this archaeology exercise.

Ian.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

[Robie Basak]

On Mon, Jun 12, 2017 at 05:46:14PM +0100, Ian Jackson wrote:
> Again, I don't follow why `fail' occurs.  You seem to be suggesting
> that importing a .dsc containing a .git would generate ..git.

Correct. I'm suggesting "fail" for the round-tripping - for "git ubuntu
build-source" to "unescape" the ..git. Or if we don't agree, then I
think there are only three reasonable choices: (fail, discard,
unescape).

I'm suggesting:

1. Interactive use: fail.
2. Non-interactive use ("batch mode", eg. -B like ssh): unescape.

> (I assume that Launchpad would be taught to reject new introductions
> of \.+git other than in security support or ancient branches.)

Agreed - if it doesn't do that already.

> If someone has such an importer-generated tree, containing ..git, they
> can just use it and ignore the ..git.  Surely that's why this is a
> good choice of directory name.

Agreed.

> If there are any non-historical packages containing .git directories,
> we should file bugs and get them fixed.

Agreed.

Robie


signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

[Ian Jackson]

Robie Basak writes ("Re: "git ubuntu" wrappers [was: What to do with .git 
directories in source package uploads?]"):
> I don't really follow what you're saying. Are you saying that wrapping
> these types of things in general is bad, or that having a wrapper for
> the specific case of unescaping .git is bad?

Yes, the latter.

> For the latter, I think that safe round-tripping is an important
> property of an importer and that ditching this property shouldn't be
> taken lightly. I'm applying this principle in making design decisions
> that we can't easily change later, such as the imported "format".

There is some logic to this, indeed.  I think your model requires a
higher degree of fidelity.

So I guess it's worthwhile thinking about how to make any
transformations you do reversible, from which pov ..git is not too
bad an idea.

Before we adopt this I think we should consult more widely, though.

And: even if the transformation is reversible, I think this should be
for archeaological purposes, not for operational ones.  Ie you should
be able to inspect what's there, but any work based on the old branch
should probably either preserve it or discard it.

> OTOH, I wouldn't consider it to be a high priority to actually
> implement, and a default of failing if ..git exists would be perfectly
> acceptable for this extreme edge case. We could require the user to tell
> us exactly what is required (drop or unescape) when rebuilding the
> source package.
> 
> Though then we'd probably need a "batch mode" that would probably
> default to unescape to avoid creating a minefield of edge cases for
> script writers.

I'm not sure what you mean.  Do you mean something which contradicts
my previous paragraph.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

[Robie Basak]

On Mon, Jun 12, 2017 at 04:57:06PM +0100, Ian Jackson wrote:
> `dgit clone' disables these .gitattributes; provides a separate verb
> for disabling them in other trees; and `dgit fetch' warns about them
> if it finds them.

So...you have a wrapper?

I don't really follow what you're saying. Are you saying that wrapping
these types of things in general is bad, or that having a wrapper for
the specific case of unescaping .git is bad?

For the latter, I think that safe round-tripping is an important
property of an importer and that ditching this property shouldn't be
taken lightly. I'm applying this principle in making design decisions
that we can't easily change later, such as the imported "format".

OTOH, I wouldn't consider it to be a high priority to actually
implement, and a default of failing if ..git exists would be perfectly
acceptable for this extreme edge case. We could require the user to tell
us exactly what is required (drop or unescape) when rebuilding the
source package.

Though then we'd probably need a "batch mode" that would probably
default to unescape to avoid creating a minefield of edge cases for
script writers.

Robie


signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

[Ian Jackson]

Robie Basak writes (""git ubuntu" wrappers [was: What to do with .git 
directories in source package uploads?]"):
> Some examples:
> 
> Upstreams that ship .gitignore confuses distribution developers (IMHO)
> who want to see *everything* that has changed. I'd like to work with git
> upstream in adding a repository level configuration option (or similar)
> to completely ignore all dotfiles in the worktree that affect git's
> behaviour. As a distribution developer, git's behaviour should come from
> me, not some random upstream whose package I happen to be working on. In
> the meantime, our wrapper warns you if these are present.

AIUI .gitignore does not affect whether git shows you diffs to files
that have changed.  It simply suppresses listing of _added_ files.

> Similarly, there are upstreams that use $Id$ and similar abominations.
> The only sensible way to handle these and other corruptions is to turn
> off ident, text and eol in .git/info/attributes, which our wrapper adds
> on "git ubuntu clone".

`dgit clone' disables these .gitattributes; provides a separate verb
for disabling them in other trees; and `dgit fetch' warns about them
if it finds them.

> Having sensible default refspecs and dealing with sharing repositories
> when you can't push to the main importer repository is a pain. This is
> amplified when few developers work across many packages and don't keep
> persistent local git repositories for them. So "git ubuntu clone" and
> "git ubuntu remote add" deal with setting up reasonable default
> remotes and refspecs.

Obviously having sensible remotes is nice, but not IMO essential.

> In Ubuntu, the importer must maintain separate pristine-tar branches for
> Debian and Ubuntu because orig tarballs may not necessarily match. We
> try to make them match, but the importer must be able to represent
> everything that happened, including past mistakes. But "git clone"
> followed by "dpkg-buildpackage" won't be able to find the upstream
> tarball, and nor can gbp without adjusting the local pristine-tar
> branch. This is solved by "git ubuntu build-source", which takes care of
> getting the upstream tarball for you first.

dpkg-buildpackage -B does not need an upstream tarball.

It seemed obvious to me when writing dgit that it would be too hard to
to make a uniform data model and workflows that could be used to
generate source packages from git.

Anyway, I don't think a wrapper that does "unescaping" of .git is a
good idea.

Ian.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

"git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

[Robie Basak]

On Mon, Jun 12, 2017 at 04:31:48PM +0100, Ian Jackson wrote:
> Robie Basak writes ("Re: What to do with .git directories in source package 
> uploads?"):
> > In mitigation, we have "build" and "build-source" wrappers that could
> > always do the correct unescaping here. Then you'd only fall into the
> > trap if you aren't using the wrapper.
> 
> If these wrappers are what I think they are, they are IMO a bad idea.

I don't like them either, but for the moment, they are IMHO necessary. I
would like to see them go away, so I have been keen on not requiring
them for any workflow. I'd also like to make sure that all documentation
makes it clear how to _not_ use the wrappers. However, if you don't use
them, there is a growing list of caveats of which you need to be aware,
usually for edge cases.

Some examples:

Upstreams that ship .gitignore confuses distribution developers (IMHO)
who want to see *everything* that has changed. I'd like to work with git
upstream in adding a repository level configuration option (or similar)
to completely ignore all dotfiles in the worktree that affect git's
behaviour. As a distribution developer, git's behaviour should come from
me, not some random upstream whose package I happen to be working on. In
the meantime, our wrapper warns you if these are present.

Similarly, there are upstreams that use $Id$ and similar abominations.
The only sensible way to handle these and other corruptions is to turn
off ident, text and eol in .git/info/attributes, which our wrapper adds
on "git ubuntu clone".

Having sensible default refspecs and dealing with sharing repositories
when you can't push to the main importer repository is a pain. This is
amplified when few developers work across many packages and don't keep
persistent local git repositories for them. So "git ubuntu clone" and
"git ubuntu remote add" deal with setting up reasonable default
remotes and refspecs.

In Ubuntu, the importer must maintain separate pristine-tar branches for
Debian and Ubuntu because orig tarballs may not necessarily match. We
try to make them match, but the importer must be able to represent
everything that happened, including past mistakes. But "git clone"
followed by "dpkg-buildpackage" won't be able to find the upstream
tarball, and nor can gbp without adjusting the local pristine-tar
branch. This is solved by "git ubuntu build-source", which takes care of
getting the upstream tarball for you first.

None of these things *require* the wrappers, but we currently have no
way of making the things that they do unnecessary without causing
developer onboarding or edge case pain.

I believe there are other cases too; these are just off the top of my
head.

Robie


signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: What to do with .git directories in source package uploads?

[Robie Basak]

On Wed, May 24, 2017 at 10:56:52PM +0100, Ian Jackson wrote:
> But if there are packages where the .git directory is somehow actually
> used in the build, your scheme won't help because a build from the
> imported git tree will use your history, not the history found in the
> .dsc's .git.

I don't think this matters. By using our imported git tree and using git
to clone it, the user is explicitly requesting our importer's history in
.git, contrary to the source package's .git directory. I think it's
reasonable for "our git" to "take over" .git in this case. The original
uploader left a .git "trap" and we aren't in a position to remove the
trap for unsuspecting developers, but I don't think we're making it
worse. The badness happened in as an interaction between the bad source
package and the the decision to use git tooling and have an importer in
the first place, and the user is complicit in the latter decision.

In mitigation, we have "build" and "build-source" wrappers that could
always do the correct unescaping here. Then you'd only fall into the
trap if you aren't using the wrapper.

Robie


signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: What to do with .git directories in source package uploads?

[Ian Jackson]

Nish Aravamudan writes ("What to do with .git directories in source package 
uploads?"):
> I noticed today that our Ubuntu git importer failed to import
> src:nplan (which is only in Ubuntu). This is because the upload
> (incorrectly) includes a .git directory. I see that dgit's behavior
> for the same DSC file with `dgit import-dsc` is to delete the .git
> directory from the source package before import. Is that a reflection
> of Debian policy?

Debian ftpmasters REJECT out of NEW packages that contain .git
directories.  But there is a loophole, which I think is accidental,
that lets later uplods containing .git directories slip through.

> 1) What dgit currently does, which is remove .git directories from
> source packages, with a warning. This does mean that an imported
> object does not match an uploaded exactly. Perhaps this is OK, but for
> instance, in the case of nplan (purely as an example), if a developer
> were to then use our git repository to develop a follow-on change, the
> resulting debdiff would include (surprisingly to the end-user) a
> removal of .git/)

I think that is actually correct.  If Debian ftpmasters fix the bug in
their system, so that uploads containing .git are properly rejected,
it would even be necessary.

Furthermore many Debian package-handling tools will delete the .git
anyway.

> 2) In order from longest to shortest:
> Change any file in the source package matching ^\(\.+git\)$ to
>  \.\1
> [essentially prefixing a '.' to any file consisting of only
> leading '.' and the string 'git' ]
...
> I'm wondering, are there are any explicit policy statements that say a
> build system cannot rely on a git directory being present? Say a
> debian/rules that does a `git describe`? I don't want to break such a
> source package if it does exist.

I'm almost certain that all the .git directories found in actual
package uploads are accidents caused my buggy or misoperated packaging
tools.

> I'm planning on implementing 2), as it leaves us the most wiggle-room
> and we haven't asserted anything about hash stability yet in our
> imports. But I'd love for some input on why 1) was chosen, and, as I
> mentioned earlier, if it's considered 'policy' or not.

Your scheme is a possible alternative approach, indeed.  It might
result in slightly confusing git trees.  It doesn't lose information,
it's true, which is a slight advantage.

But if there are packages where the .git directory is somehow actually
used in the build, your scheme won't help because a build from the
imported git tree will use your history, not the history found in the
.dsc's .git.

Ian.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

What to do with .git directories in source package uploads?

[Nish Aravamudan]

Ian,

I noticed today that our Ubuntu git importer failed to import
src:nplan (which is only in Ubuntu). This is because the upload
(incorrectly) includes a .git directory. I see that dgit's behavior
for the same DSC file with `dgit import-dsc` is to delete the .git
directory from the source package before import. Is that a reflection
of Debian policy?

What I am hoping we can agree on is one of the two (it seems like)
options for handling .git directories. While it does seem that one can
trick git into representing .git in the treeish(s), `git push` will
fail and it just sort of conflicts with the notion of git-based
tooling, so I think actually having them in the source package treeish
is a non-starter.

The alternatives Robie and I devised are:

1) What dgit currently does, which is remove .git directories from
source packages, with a warning. This does mean that an imported
object does not match an uploaded exactly. Perhaps this is OK, but for
instance, in the case of nplan (purely as an example), if a developer
were to then use our git repository to develop a follow-on change, the
resulting debdiff would include (surprisingly to the end-user) a
removal of .git/)

2) In order from longest to shortest:
Change any file in the source package matching ^\(\.+git\)$ to
 \.\1
[essentially prefixing a '.' to any file consisting of only
leading '.' and the string 'git' ]

The idea here is that while we can't save the .git directory as-is, we
can losslessly convert the name (which might collide with other files,
so we must rename anything in that 'namespace'). This won't help
`dpkg-buildpackage` users, but if using our tooling, we can catch this
and rename files back before building with a conversion, in order from
shortest to longest:
^\.\(.+git\)$ -> \1

I'm wondering, are there are any explicit policy statements that say a
build system cannot rely on a git directory being present? Say a
debian/rules that does a `git describe`? I don't want to break such a
source package if it does exist.

I'm planning on implementing 2), as it leaves us the most wiggle-room
and we haven't asserted anything about hash stability yet in our
imports. But I'd love for some input on why 1) was chosen, and, as I
mentioned earlier, if it's considered 'policy' or not.

Let me know if I can clarify anything here!

-Nish

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Su respuesta urgente es necesaria / your urgent response is needed

[Gloria]

Fondos donados a usted. Tu nombre es uno de los 5 afortunados personas contacto 
[  gloriacmackenzi...@gmail.com ] para más detalles
 
 Funds donated to you. your name is among the 5 lucky people contact [ 
gloriacmackenzi...@gmail.com ] for details


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

!!!! Greetings !!!!

[kong khemara]

Hello,
I am Barr Kong Khemara, I humbly ask if you are related to my client who died 
couple of
years ago in a car accident here in my country Cambodia. I wish to also inquire 
if
it is possible to have different families with the same last name as yours by 
coincidence
who do not share the same common roots? Kindly get back to me if your email is 
still
Valid to enable me give you the details of my message or make headway in my 
search.
Regards,
Kong Khemara
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

on quilt, dpkg, dgit and symlinks.

[peter green]

I recently discovered some unusual behaviour in a source package I was working 
on.

I was using some scripts I put together myself to generate patch series for a 
debian package.

dgit claimed I was creating a new symlink and that creation of a new symlink could not be 
represented by 3.0 (quilt). So I removed the symlink, dpkg-source called by dgit then 
warned about "deletion" of said symlink. Furthermore when I extracted the 
resulting source package the symlink reappeared.

After some tracking down it seems a patch *can* create a symlink and that both 
dpkg-source and "quilt push" will happily apply such a patch.

quilt pop on the other hand is not so happy. Sometimes it will remove the patch, 
sometimes it will complain that it "won't remove cleanly". I haven't figured 
out the exact trigger.

dgit will import a dsc with such a patch, then fail to build a source package 
from the tree it has just imported complaining about changes that cannot be 
represented by 3.0 (quilt).

not sure what to make of all this.

I have attached a source package demonstrating the issue (you will need to grab 
the orig tarball from the debian archive)




hello_2.10-1+symlink.debian.tar.xz
Description: application/xz
Format: 3.0 (quilt)
Source: hello
Binary: hello
Architecture: any
Version: 2.10-1+symlink
Maintainer: Santiago Vila 
Homepage: http://www.gnu.org/software/hello/
Standards-Version: 3.9.6
Build-Depends: debhelper (>= 9.20120311)
Package-List:
 hello deb devel optional arch=any
Checksums-Sha1:
 f7bebf6f9c62a2295e889f66e05ce9bfaed9ace3 725946 hello_2.10.orig.tar.gz
 692a93f818ec349fbe130bfa3c6f5aff20b01e24 6408 
hello_2.10-1+symlink.debian.tar.xz
Checksums-Sha256:
 31e066137a962676e89f69d1b65382de95a7ef7d914b8cb956f41ea72e0f516b 725946 
hello_2.10.orig.tar.gz
 f8eb5f4161568f7e30874f12bf2d5262ec7cef8ce2eef8353a681a320a81d002 6408 
hello_2.10-1+symlink.debian.tar.xz
Files:
 6cd0ffea3884a4e79330338dcc2987d6 725946 hello_2.10.orig.tar.gz
 3a0426222a13f7f40147fd865088f032 6408 hello_2.10-1+symlink.debian.tar.xz
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: PSA: github file size limit means that some debian package imports can't be pushed to github.

[peter green]

On 09/03/17 16:05, s...@vilain.net wrote:

git-lfs is your friend. And supported natively by GitHub.


Thanks but it seems like a highly undesirable soloution to me.

Firstly it seems to require mangling your git repo. That is going to make it at 
best a PITA to use with things like dgit.

Secondly AIUI git-lfs stores every version of the file seperately. If so then 
one would very quickly blow through the default storage and bandwidth 
limitations for githubs lfs offering.



On March 9, 2017 7:42:20 AM PST, peter green  wrote:

I have recently started pushing source for packages where we carry 
modifications for in raspbian to github. The packages are imported into git 
using dgit.

However I have discovered that this is not possible for all packages. In 
particular github rejects files over 100 megabytes and the current libreoffice 
package has a 107 megabyte (upstream) ChangeLog in it.

You might want to bear this in mind when considering packaging workflows 
that may involve github.


--

vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss


___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: PSA: github file size limit means that some debian package imports can't be pushed to github.

[Sam Vilain]

On Mar 9, 2017 09:08, "peter green"  wrote:

On 09/03/17 16:05, s...@vilain.net wrote:

git-lfs is your friend. And supported natively by GitHub.

Thanks but it seems like a highly undesirable soloution to me.

Firstly it seems to require mangling your git repo. That is going to make
it at best a PITA to use with things like dgit.


I didn't realize it was in upstream. That makes things harder. You might be
able to do something with grafts but I'm not sure if that works for trees.

Secondly AIUI git-lfs stores every version of the file seperately. If so
then one would very quickly blow through the default storage and bandwidth
limitations for githubs lfs offering.


It does. For a changelog file this isn't the right solution.

The right solution is to make sure all the information in the changelog is
converted to commit messages via history rewriting, and then remove that
changelog from the checked in content. This requires forking the repo and
ideally popularizing the cleaned-up fork with the core maintainers so that
it isn't an ongoing maintenance problem. It's painful but it works and
eventually everyone is thankful - I did this with the Perl 5 history. You
could skip the history rewriting and just remove the changelog but then you
have to maintain the maintenance scripts.

Another option would be to ask someone at GitHub to remove this limit for
this repo. Have you tried that?

Sam
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: PSA: github file size limit means that some debian package imports can't be pushed to github.

[s...@vilain.net]

git-lfs is your friend. And supported natively by GitHub.

On March 9, 2017 7:42:20 AM PST, peter green  wrote:
>I have recently started pushing source for packages where we carry
>modifications for in raspbian to github. The packages are imported into
>git using dgit.
>
>However I have discovered that this is not possible for all packages.
>In particular github rejects files over 100 megabytes and the current
>libreoffice package has a 107 megabyte (upstream) ChangeLog in it.
>
>You might want to bear this in mind when considering packaging
>workflows that may involve github.
>
>___
>vcs-pkg-discuss mailing list
>vcs-pkg-discuss@lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

PSA: github file size limit means that some debian package imports can't be pushed to github.

[peter green]

I have recently started pushing source for packages where we carry 
modifications for in raspbian to github. The packages are imported into git 
using dgit.

However I have discovered that this is not possible for all packages. In 
particular github rejects files over 100 megabytes and the current libreoffice 
package has a 107 megabyte (upstream) ChangeLog in it.

You might want to bear this in mind when considering packaging workflows that 
may involve github.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

!! GREETINGS !!!

[hassan karam]

Hello

I am Mr. Hassan Karam, from Syria due to brutal civil war in my country, I am 
seeking your
partnership in going into a private investment venture. I am interested in 
investing in your
country, so I will like us to begin our acquaintance through this medium so we 
can deliberate
more.I hope to hear from you soon thanks.

Yours faithfully,
Hassan Karam
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: git based autoforwardporter.

[peter green]

On 19/01/17 19:36, Ian Jackson wrote:


I think such a tool would be very useful in general, if it could be
used for individual users.

I see no reason why it couldn't be used by an individual user.

I have posted the current code at .

https://github.com/plugwash/dscdirtogit (import tool)
https://github.com/plugwash/autoforwardporter (actual autoforwardporter)

Feel free to take a look at it and comment/criticize.

Currently there are a bunch of assumptions in the code that are either raspbian-specific 
or specific to the box I run the code on. I guess I will need to introduce some sort of 
config file so that "distro" names, file paths, urls, committer emails etc can 
be configured.

The code is a mixture of python3 and shell script, anyone have any suggestions 
for the best way to do a config file that can be easilly read from both python3 
and shell script?

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: git based autoforwardporter.

[Ian Jackson]

peter green writes ("git based autoforwardporter."):
> I can't imagine raspbian is the only project who would find such a
> tool useful. OTOH it would be a fair bit of work to clean up the
> tool to seperate local raspbian assumptions from more generally
> applicable functionality.
> 
> Are there people who would be interested in using and collaborating
> on such a tool?

I think such a tool would be very useful in general, if it could be
used for individual users.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: git based autoforwardporter.

[Robie Basak]

Hi Peter,

On Thu, Jan 19, 2017 at 02:16:27AM +, peter green wrote:
> Some time ago I put together what I call the "autoforwardporter". The
> aim of this is to take downstream changes and apply them on top of new
> debian uploads.

Can you expand on this? We do exactly this in Ubuntu as another Debian
derivative, and we are developing a bunch of tooling and workflow around
this with a view to eventually being able to automate most of it.

We're maintaining a bunch of Ubuntu deltas in git repositories now. We
keep the Ubuntu delta as a patch series as a set of git commits (a bit
like how git-dpm does it with quilt, but for everything we change,
including debian/). We have an "importer" that integrates new Debian and
Ubuntu uploads that are being made out of this system automatically.

Re-applying changes on top of new Debian uploads is then just a case of
"git rebase --onto". This works today. Though we are doing it manually
right now, the long term goal is for this to be automatic for the
non-conflicting cases, though with human review before upload.

> Are there people who would be interested in using and collaborating on
> such a tool?

Yes, if we can find enough commonality in our needs. Our plans are
pretty mature in the details now. Can you tell us more about yours?

Robie

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

re: patches-applied historical imports (usd import)

[peter green]

I haven't run dgit's dsc importer on a whole historical archive but
Peter Green of Raspian has been running it and filing bugs.  I haven't
seen such a bug recently so I hope it has been working for all the
packages he's seen.

I haven't really been doing large scale importing, I have just imported 
relatively shallow histories of a relative handful of packages.



___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

git based autoforwardporter.

[peter green]

First let me introduce myself, I am Peter Michael Green, cofounder of the 
Raspbian project. I have quite a bit of experiance with Debian

Some time ago I put together what I call the "autoforwardporter". The aim of 
this is to take downstream changes and apply them on top of new debian uploads.

Originally this was diff/patch based but I got into a conversation with Ian 
Jackson at the minidebconf and he convinced me it would be a good idea to use 
dgit.

I can't imagine raspbian is the only project who would find such a tool useful. 
OTOH it would be a fair bit of work to clean up the tool to seperate local 
raspbian assumptions from more generally applicable functionality.

Are there people who would be interested in using and collaborating on such a 
tool?


___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: patches-applied historical imports (usd import)

[Ian Jackson]

Nish Aravamudan writes ("patches-applied historical imports (usd import)"):
> 1) Some source packages (bouncycastle, php7.0 are the ones I can think
> of off the top of my head) upstream tarballs contain .gitattributes

I investigted this.  After looking at the docs and playing about, I
concluded that the only sane approach is to record as the actual tree
object (in the git history) the contents of the Debian source package.
Otherwise it will become impossible to represent certain source
packages and all sorts of unanticipated madness could occur.

So I'm currently testing an enhancement to dgit which causes it to
 * unconditionally suprress transforming gitattributes when working
   behind the scenes to import a .dsc
 * by default, configure suppression of these attributes, when
   creating a fresh tree with `dgit clone' (and also in `dgit
   setup-new-tree')

The only other possiblity would be to apply a lossless rename
operation to all .gitattributes, which would be worse.

Ian.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

SPENDE GRANT

[WESTERN UNION]

Sir/Madam,

Hiermit mchten wir Sie informieren, dass WESTERN UNION Internationale 
Spendenprojekt hat Ihnen eine Barzuwendung von ausgezeichnet [50,000 EURO], als 
Charity-Spende von Western union International, Grobritannien, 
frderte in Verbindung mit Kinderfonds der Vereinten Nationen [UNICEF] .

Fr weitere Informationen ber die Verarbeitung und Auszahlung Ihrer 
Zuschsse Ansprche Bitte kontaktieren Sie Mr Albert Wayne, der 
nationale Sekretr der Stiftung mit Ihrer Qualifikation Number 
[WNI/101/231/BDB] so schnell wie mglich

Western Union Bezirksleiter (Herr Albert Wayne)
Website: www.westernunion.com
E-mail: westernunionunicefdonat...@gmail.com

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: patches-applied historical imports (usd import)

[Ian Jackson]

Ian Jackson writes ("Re: patches-applied historical imports (usd import)"):
> I suggest you read "Intent to commit craziness - source package
> unpacking" et seq, which were on this list in September.  Here's the
> archive:
> 
>   
> http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/2016-September/thread.html

And after you've read that, you can see that what I actually did was
even worse.

  
https://browse.dgit.debian.org/dgit.git/commit/?id=05db7ab051736bb106467e7f83b9e45684dd227c

You will want to look at the most recent dgit HEAD for the full
algorith, because there are other workarounds for bugs in dpkg-source
etc.  Near here:

  https://browse.dgit.debian.org/dgit.git/tree/dgit#n2365

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: patches-applied historical imports (usd import)

[Ian Jackson]

Ian Jackson writes ("Re: patches-applied historical imports (usd import)"):
> Urk!  I have just filed:
...
>  https://bugs.debian.org/850845
>   dpkg-source fails to extract samba_3.6.5-2.dsc but exits status 0 - 
> https://bugs.debian.org/850845

This was actually in dget, not dpkg-source.  dpkg-source exits 2.

Ian.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: patches-applied historical imports (usd import)

[Nish Aravamudan]

On 09.01.2017 [14:33:29 -0800], Nish Aravamudan wrote:
> On 09.01.2017 [13:40:16 +], Ian Jackson wrote:
> > Nish Aravamudan writes ("patches-applied historical imports (usd import)"):



> > > ii) some patches may fail to apply with a trivial `quilt push`. This
> > > occurs with, at least, a historical publish of samba.
> > 
> > Do you have an example source package ?
> 
> I will re-run the import today and get that info for you.

src:samba 2:3.6.5-2 fails via `pull-debian-source` and (which the former
calls) `dpkg-source -x` and `quilt push`:

dpkg-source: info: the patch has fuzz which is not allowed, or is malformed
dpkg-source: info: if patch 'waf-as-source.patch' is correctly applied by 
quilt, use 'quilt refresh' to update it
dpkg-source: info: restoring quilt backup files for waf-as-source.patch
dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B 
.pc/waf-as-source.patch/ --reject-file=- < 
samba-3.6.5/debian/patches/waf-as-source.patch gave error exit status 1
pull-debian-source: Error: Source unpack failed.

Thanks,
Nish

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: patches-applied historical imports (usd import)

[Nish Aravamudan]

On 09.01.2017 [13:40:16 +], Ian Jackson wrote:
> Nish Aravamudan writes ("patches-applied historical imports (usd import)"):
> > 1) Some source packages (bouncycastle, php7.0 are the ones I can think
> > of off the top of my head) upstream tarballs contain .gitattributes
> > files, which will change the behavior of git itself when checking out a
> > branch.
> 
> I need to do some tests to see exactly how to work around this.
> Can you point me at an affected source package version ?

I believe all php7.0 source packages will have a .gitattributes entry
containing 'ident' attributes amongst others.

> > 2) How do we determine if a source package is 1.0 vs. 3.0? I am
> > currently using `dpkg-source --print-format`, but have found one source
> > package (util-linux 2.13~rc3-5), where dpkg-source emits:
> > 
> > syntax error in /tmp/tmp3y515osf/util-linux-2.13~rc3/debian/control at
> > line 14: duplicate field Depends found
> > 
> > and thus we error out.
> 
> How exciting.  dgit looks at debian/source/format, which is what
> dpkg-source reads when generating the package.

Yep, based upon Sean's advice, I will switch to using that as well.

> > 3) Imagine the following graph in the git repository:
> > 
> >A   D
> >  ->o.f>o->
> >^ .   . ^
> >|  c e  |
> >o   .   .   o
> >^. .^
> >| B |
> >o o o
> >^ ^ ^
> >| | |
> >  ->o>o>o-> 
> >a b d
> ...
> > Let's assert that there is a problem with obtaining the patches-applied
> > version of b. This can occur for (at least) the following reasons:
> > 
> > i) as in 2), we might not be able to determine the source package format
> > (implementation detail, to some degree), so are unable to correctly
> > derive if there is a patches-applied state that is distinct from b.
> 
> You can use dpkg-source -x to extract the patches-applied state
> corresponding to any .dsc, I think.  Any case where you can't is a bug
> in dpkg-source.

Right, that will get me to the fully patches-applied state, but what
about the intervening ones?

> > ii) some patches may fail to apply with a trivial `quilt push`. This
> > occurs with, at least, a historical publish of samba.
> 
> Do you have an example source package ?

I will re-run the import today and get that info for you.

> > In theory, there are other reasons/cases where this might happen and the
> > importer needs to never fail (so it is of some use to run automatically
> > :)
> 
> I haven't run dgit's dsc importer on a whole historical archive but
> Peter Green of Raspian has been running it and filing bugs.  I haven't
> seen such a bug recently so I hope it has been working for all the
> packages he's seen.

And it's also very possible that it may not be a Debian publish, but an
Ubuntu publish where this occurs :)

> > The questions I have relate to what to do when we encounter this
> > situation, which in turn is divided into two parts:
> 
> I think this situation must be excluded.
> 
> This kind of difficulty is one of the main reasons for the failure of
> previous efforts to transition universally to git.  It is why dgit
> does not currently work, in Debian, with a full history of each
> package.  Instead there's a bit of a bodge, with a locally generated
> history.  Joey Hess and I came up with this approach at the Vaumarcus
> Debconf.
> 
> Eventually I intend to import the whole history but not yet.
> 
> If you intend to go forward without fully solving this problem, your
> choices are not good.

Agreed.

> > Let's presume that this failure is not persistent and that D is able to
> > be imported successfully, we again have to make decisions about
> > parenting. I think it only makes sense for one of c or f to exist, based
> > upon what we decide is the right policy above.
> 
> This is particularly troublesome.  When you can generate the missing
> package, you will not be able to make it an ancestor of your existing
> history.
> 
> You could rewrite the existing history and then pseudomerge the old
> and new histories together, but that means duplicating most of the
> history metadata.
> 
> 
> If you wait with making an official import until it is suitable for
> use with dgit, then I might consider using the relevant parts of your
> imports history as the official Debian dgit history.
> 
> That would save you from the problem which I foresee in our future,
> where Debian and Ubuntu have disjoint imports of the same history.

Right, ideally, we'd be able (at some point in the future) perhaps stop
importing Debian manually (from Launchpad) and trust dgit or some other
source of information for the Debian history (with some translation
layer to go from a version string to a commitish in that source).

-Nish

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org

Re: patches-applied historical imports (usd import)

[Nish Aravamudan]

Hi Sean,

On 08.01.2017 [21:34:50 -0700], Sean Whitton wrote:
> Hello Nish,
> 
> On Fri, Jan 06, 2017 at 02:26:29PM -0800, Nish Aravamudan wrote:
> > 2) How do we determine if a source package is 1.0 vs. 3.0? I am
> > currently using `dpkg-source --print-format`, but have found one source
> > package (util-linux 2.13~rc3-5), where dpkg-source emits:
> 
> I would just introspect for the debian/source/format file.  If it has a
> line "3.0 (.*)" then it's 3.0, otherwise it's 1.0 (for all packages that
> were ACCEPTed to ftp-master).

Ok, is this documented in the manual or anything (for my own
edification). I spent some time searching, but didn't find anything
definitive except for the hint provided by `dpkg-source --print-format`.
And, presumably, if a historical publish exists without any
debian/source/format file, it should be treated as 1.0? Ah, yep, I see
that documented in `man dpkg-source` under DIAGNOSTICS.

> > ii) some patches may fail to apply with a trivial `quilt push`. This
> > occurs with, at least, a historical publish of samba.
> 
> Have you considered obtaining the patches-applied tree using
> `dpkg-source -x`?  That applies the patches without using quilt(1), so
> might workaround this sort of bug (if it didn't, the package would
> FTBFS).

Well, I would do that, but afaict, there is no way to tell dpkg-source
to only apply one patch at a time? This is to go from a
patches-unapplied state to the fully patches-applied state, commiting
each patch application into the repository. Perhaps I missed a flag in
the manpage, though?

Thanks,
Nish


-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: patches-applied historical imports (usd import)

[Robie Basak]

On Mon, Jan 09, 2017 at 05:17:08PM +, Ian Jackson wrote:
> Robie Basak writes ("Re: patches-applied historical imports (usd import)"):
> > Right now, we're accepting rich history only for Ubuntu-specific
> > commits. I don't think we have really considered yet what would be best
> > for Debian. But in the future, if Debian is interested in the same
> > mechanism, then the same would apply to Debian's ancestory trees. I
> > don't see any reason why it wouldn't make sense for Debian to do the
> > same thing here.
> 
> When Debian has its own complete and ongoing git history, with a
> mixture of rich and imported histories, you will obviously want to
> fold that into your ongoing Ubuntu history.  How do you plan to do
> that ?

Using the same "adopt rich history" mechanism. Give the importer, in
advance, a map of (srcpkgname, versionstring) -> (commithash). When the
importer imports, if the map lookup succeeds, the corresponding commit
is added as an additional parent.

Then the question just becomes: whence do we get this map? Right now one
mechanism is that the uploader provides it to the importer repository in
advance via a tag. We could also use the dgit-like mechanism of putting
a commit hash in the changes file together with some known place to find
that commit object.

Further mechanisms might be able to locate a commit object by following
a Vcs-Git header and expecting a dep14 tag there, though I think this
needs some thought about safety and edge cases (repository unavailable,
etc).

Ultimately either we agree on a known way to find the commit objects, or
we rely on uploaders to provide them, or we do not get the rich history.

If Debian does not provide a mechanism for the importer to pick this up
automatically (or we cannot use it for whatever reason), an Ubuntu
uploader could still manually pull in Debian VCS history by preparing a
commit that uses Debian VCS in its history, and providing that as the
"rich history commit object" to the importer before uploading to Ubuntu.

Does this answer your question? I'm not sure what else you're looking
for here.

> > I believe it does currently, unless Nish steps in to correct me. So this
> > part could indeed be the same. However, I think the same rich history
> > case above applies here too. We're not doing it right now, but if a
> > maintainer wants to supply rich upstream commits (for example by
> > connecting upstream's VCS to the commit graph), then I think this is
> > something the importer could support. And in this case, the commit
> > hashes would start to mismatch.
> 
> Indeed.  I don't think this can be made perfect but the more we make
> it similar the better.
> 
> dgit's imports of tarball are always origin commits, with a separate
> commit to stitch them into history.  That allows for a different
> import of the same tarball to have different parents, but still share
> the same tarball origin commit.

Ah. We could do the same then, to use the same tarball origin commit
hash. That might be useful.

Robie


signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: patches-applied historical imports (usd import)

[Robie Basak]

On Mon, Jan 09, 2017 at 02:02:34PM +, Ian Jackson wrote:
> Robie Basak writes ("Re: patches-applied historical imports (usd import)"):
> > On Mon, Jan 09, 2017 at 01:45:52PM +, Ian Jackson wrote:
> > > Ideally you and I could agree on a commit structure for the imported
> > > packages, and metadata processing rules, so that the commits are
> > > identical (not just the trees).
> > 
> > By "commits are identical", are you including parent commit hashes? Or
> > just everything else?
> 
> It's true that not all of the parent hashes could be identical.

Right. In particular, our importer has two sources of input for the
unapplied branches: archive history, and rich history supplied by
developers. Commits generated by the importer end up having parents from
both of these sources (subject to source availability).

The rich history input source breaks the "reproducible commit hash"
invariant somewhat. If identical rich history is available on re-import
then the importer should produce the same result commit hash, but the
timing of supply of the rich history affects things. For example, if an
uploader forgets to give us some rich history but supplies it months
later, we still want to keep it but it will not have been adopted into
the graph of commits by the importer. But the importer would take it on
a re-import, thus mutating all subsequent commit hashes.

Right now, we're accepting rich history only for Ubuntu-specific
commits. I don't think we have really considered yet what would be best
for Debian. But in the future, if Debian is interested in the same
mechanism, then the same would apply to Debian's ancestory trees. I
don't see any reason why it wouldn't make sense for Debian to do the
same thing here.

The applied branches (created on your request) has the unapplied branch
as a parent (sort of like git-dpm does), so the same
non-reproducible-ness filters through.

> dgit imports orig tarballs in a way that is supposed to produce a
> stable commit hash for each tarball, so that different revisions of
> the same upstream version have the upstream as a common ancestor.
> 
> Does Nish's importer try to generate a fast-forwarding upstream
> branch ?  If not then part of the imported commit structure could be
> the same.

I believe it does currently, unless Nish steps in to correct me. So this
part could indeed be the same. However, I think the same rich history
case above applies here too. We're not doing it right now, but if a
maintainer wants to supply rich upstream commits (for example by
connecting upstream's VCS to the commit graph), then I think this is
something the importer could support. And in this case, the commit
hashes would start to mismatch.

Robie


signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: patches-applied historical imports (usd import)

[Ian Jackson]

Nish Aravamudan writes ("patches-applied historical imports (usd import)"):
> [stuff]

It occurs to me that it would be a good idea for you to check that
your importer produces identical answers to dgit.  If nothing else,
from your point of view dgit can help you test that your importer
DTRT.

At the very least, for every .dsc which is successfully imported by
both dgit and your tool, the resulting imported tree object should be
identical.

Since I think dgit should be able to import every .dsc in the whole of
history (given new enough underlying tools), I would encourage you to
report every import failure as a bug against dgit.  When considering
such bugs:
 * I do not mind if you do not repro the bug on Debian
 * Point me at the exact .dsc
 * Run dgit with -D and include the output in the bug report
 * Use Severity: important

Ideally you and I could agree on a commit structure for the imported
packages, and metadata processing rules, so that the commits are
identical (not just the trees).

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: patches-applied historical imports (usd import)

[Ian Jackson]

Nish Aravamudan writes ("patches-applied historical imports (usd import)"):
> 1) Some source packages (bouncycastle, php7.0 are the ones I can think
> of off the top of my head) upstream tarballs contain .gitattributes
> files, which will change the behavior of git itself when checking out a
> branch.

I need to do some tests to see exactly how to work around this.
Can you point me at an affected source package version ?

> 2) How do we determine if a source package is 1.0 vs. 3.0? I am
> currently using `dpkg-source --print-format`, but have found one source
> package (util-linux 2.13~rc3-5), where dpkg-source emits:
> 
> syntax error in /tmp/tmp3y515osf/util-linux-2.13~rc3/debian/control at
> line 14: duplicate field Depends found
> 
> and thus we error out.

How exciting.  dgit looks at debian/source/format, which is what
dpkg-source reads when generating the package.

> 3) Imagine the following graph in the git repository:
> 
>A   D
>  ->o.f>o->
>^ .   . ^
>|  c e  |
>o   .   .   o
>^. .^
>| B |
>o o o
>^ ^ ^
>| | |
>  ->o>o>o-> 
>a b d
...
> Let's assert that there is a problem with obtaining the patches-applied
> version of b. This can occur for (at least) the following reasons:
> 
> i) as in 2), we might not be able to determine the source package format
> (implementation detail, to some degree), so are unable to correctly
> derive if there is a patches-applied state that is distinct from b.

You can use dpkg-source -x to extract the patches-applied state
corresponding to any .dsc, I think.  Any case where you can't is a bug
in dpkg-source.

> ii) some patches may fail to apply with a trivial `quilt push`. This
> occurs with, at least, a historical publish of samba.

Do you have an example source package ?

> In theory, there are other reasons/cases where this might happen and the
> importer needs to never fail (so it is of some use to run automatically
> :)

I haven't run dgit's dsc importer on a whole historical archive but
Peter Green of Raspian has been running it and filing bugs.  I haven't
seen such a bug recently so I hope it has been working for all the
packages he's seen.

> The questions I have relate to what to do when we encounter this
> situation, which in turn is divided into two parts:

I think this situation must be excluded.

This kind of difficulty is one of the main reasons for the failure of
previous efforts to transition universally to git.  It is why dgit
does not currently work, in Debian, with a full history of each
package.  Instead there's a bit of a bodge, with a locally generated
history.  Joey Hess and I came up with this approach at the Vaumarcus
Debconf.

Eventually I intend to import the whole history but not yet.

If you intend to go forward without fully solving this problem, your
choices are not good.

> Let's presume that this failure is not persistent and that D is able to
> be imported successfully, we again have to make decisions about
> parenting. I think it only makes sense for one of c or f to exist, based
> upon what we decide is the right policy above.

This is particularly troublesome.  When you can generate the missing
package, you will not be able to make it an ancestor of your existing
history.

You could rewrite the existing history and then pseudomerge the old
and new histories together, but that means duplicating most of the
history metadata.


If you wait with making an official import until it is suitable for
use with dgit, then I might consider using the relevant parts of your
imports history as the official Debian dgit history.

That would save you from the problem which I foresee in our future,
where Debian and Ubuntu have disjoint imports of the same history.


Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: patches-applied historical imports (usd import)

[Sean Whitton]

Hello Nish,

On Fri, Jan 06, 2017 at 02:26:29PM -0800, Nish Aravamudan wrote:
> 2) How do we determine if a source package is 1.0 vs. 3.0? I am
> currently using `dpkg-source --print-format`, but have found one source
> package (util-linux 2.13~rc3-5), where dpkg-source emits:

I would just introspect for the debian/source/format file.  If it has a
line "3.0 (.*)" then it's 3.0, otherwise it's 1.0 (for all packages that
were ACCEPTed to ftp-master).

> ii) some patches may fail to apply with a trivial `quilt push`. This
> occurs with, at least, a historical publish of samba.

Have you considered obtaining the patches-applied tree using
`dpkg-source -x`?  That applies the patches without using quilt(1), so
might workaround this sort of bug (if it didn't, the package would
FTBFS).

-- 
Sean Whitton


signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

patches-applied historical imports (usd import)

[Nish Aravamudan]

Hi Ian,

I've got a few questions/comments about git-based publishing imports and
history for patches-applied imports that I was hoping to bounce off you
and other VCS folks. I apologize for the very long e-mail to follow!

For context for everyone: I (along with Robie Basak and others) have
been developing an importer that will take the publishing history of a
source package and import the source package contents into a git tree,
with tags for each publish and branches for each 'series'. That's a
broad gloss of the details, of course, but probably sufficient. This
could be, I think, of use to both Ubuntu and Debian. If you're not
interested in this, though, please feel free to disregard :)

On to the questions/comments:

1) Some source packages (bouncycastle, php7.0 are the ones I can think
of off the top of my head) upstream tarballs contain .gitattributes
files, which will change the behavior of git itself when checking out a
branch. This is not by definition a problem, except that to get to a
fully patches-applied state, I believe you must be checkout an
appropriate commit to be at (meaning you're adjusting the working
directory's contents) -- which may then differ from what is shipped by
the upstream tarball. I have seen this with eol adjustments, and much
more annoyingly (because git knows it is doing it, while vi/emacs do
not) the special ident handling. For now, we've added the following to
our git repository's .git/info/attributes at checkout time (using our
wrapper to `git clone`):

* -ident
* -text
* -eol

In other words, the underlying issue is that the upstream uses git as
well, and their git 'configuration' (not necessarily just .gitconfig)
will interfere with the behavior of any git using the upstream contents
in the working tree. Does the above seem reasonable? Afaict, there is no
way for me to really enforce the above in the repository itself, without
patching the upstream source.

2) How do we determine if a source package is 1.0 vs. 3.0? I am
currently using `dpkg-source --print-format`, but have found one source
package (util-linux 2.13~rc3-5), where dpkg-source emits:

syntax error in /tmp/tmp3y515osf/util-linux-2.13~rc3/debian/control at
line 14: duplicate field Depends found

and thus we error out.

3) Imagine the following graph in the git repository:

   A   D
 ->o.f>o->
   ^ .   . ^
   |  c e  |
   o   .   .   o
   ^. .^
   | B |
   o o o
   ^ ^ ^
   | | |
 ->o>o>o-> 
   a b d

Each o is a commit in the repository

a, b, d are patches-unapplied imports of publishes for a given release,
which are on a fast-forwarding, branch-unnapplied branch.

A is the corresponding patches-applied import of a (with each o
reflecting one patch application from the source package).

D is the corresponding patches-applied import of d (with each o
reflecting one patch application from the source package).

c, e and f are for demonstration purposes and do not necessarily exist
(except as discussed below).

Ideally, we'd have a fast-forwarding branch for the patches-applied
imports, as well.

Let's assert that there is a problem with obtaining the patches-applied
version of b. This can occur for (at least) the following reasons:

i) as in 2), we might not be able to determine the source package format
(implementation detail, to some degree), so are unable to correctly
derive if there is a patches-applied state that is distinct from b.

ii) some patches may fail to apply with a trivial `quilt push`. This
occurs with, at least, a historical publish of samba.

In theory, there are other reasons/cases where this might happen and the
importer needs to never fail (so it is of some use to run automatically
:)

The questions I have relate to what to do when we encounter this
situation, which in turn is divided into two parts:

i) Do we want to 'tag' this failed-to-apply patches-applied import in
the repository (currently, every successful patches-applied import is
tagged as 'applied/')? This is important
for semantics for end-users (and the importer itself).
  - We assert, currently that tagged objects in the tree correspond to
the source package as published in Launchpad/archive. Tagging this
failed-to-apply state as that, would violate that assertion.
  - We also rely (implementation detail) on being able to find 'nearest'
publishes by tag name, which sort of leads into the next issue...

ii) What should happen to the branch?
  - if the branch is left at A, then (even if only momentarily), upon
finishing the import at B, the branch does not reflect the latest
state in Launchpad relative to the importer's progress. 
  - if the branch is left at B, then it is no longer fast-forwarding, as
there is no connection between A and B.
  - if the branch is left at B, and we add the connection c to make it
fast-forwarding, we violate a different semantic we assert about
parenting relationships in our 

Re: Idea: sbuild/pbuilder "--dgit" option

[Bernhard R. Link]

* Ian Jackson  [161231 01:57]:
> What I was suggesting was that users should, as an alternative, be
> able to do the build themselves rather than via dgit, and still get
> the .gitignore included.

To highlight a point that I think is quite important here: adding
-i.git/ instead of the default is at least for 3.0 (quilt) packages
is not about including the .gitignore.
The effect it has (and what I understand the thing you want), is that it
will make a build *fail* if there is a .git-ignore file that has a
different content than the .orig.tar.* (or is not included in the form
of a debian/patches/ file). Because when it is no longer an ignored
derivation between unpacked source and current clean working directory,
it is by definition an fatal error. (Unless one was to reintroduce the
annoying, error-hiding, error-introducing 'generate new patches at build'
time behaviour).

Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

schroot default chroot path (was: Re: Intent to commit craziness - source package unpacking)

[Johannes Schauer]

Hi,

Quoting Ian Jackson (2016-11-30 12:11:22)
> ~Johannes Schauer writes ("Re: Intent to commit craziness - source package 
> unpacking"):
> > sbuild supports multiple backends. The default backend is schroot. How to 
> > get
> > from "apt-get install sbuild" to actually building packages depends on the
> > backend used. For the default schroot backend, sbuild provides the
> > sbuild-createchroot tool which runs debootstrap and creates a schroot config
> > file. So if you stay with the defaults, then you run:
> > 
> > $ apt-get install sbuild
> > $ sbuild-createchroot unstable /srv/chroot/unstable-amd64
> 
> WIBNI the final argument had a default ? :-)

it would. If anybody knows a good argument for a default location for schroot
containers then I can add such a default. I am not aware of such a standard
path for system-wide schroot directories or tarballs.

Anybody with a good argument for such a default location can feel free to open
a wishlist bug against sbuild and then we can discuss this there. Probably good
to do this together with the schroot maintainer (Roger Leigh in CC).

Thanks!

cheers, josch


signature.asc
Description: signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Intent to commit craziness - source package unpacking

[Ian Jackson]

~Johannes Schauer writes ("Re: Intent to commit craziness - source package 
unpacking"):
> sbuild supports multiple backends. The default backend is schroot. How to get
> from "apt-get install sbuild" to actually building packages depends on the
> backend used. For the default schroot backend, sbuild provides the
> sbuild-createchroot tool which runs debootstrap and creates a schroot config
> file. So if you stay with the defaults, then you run:
> 
> $ apt-get install sbuild
> $ sbuild-createchroot unstable /srv/chroot/unstable-amd64

WIBNI the final argument had a default ? :-)

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Intent to commit craziness - source package unpacking

[Johannes Schauer]

Hi,

Quoting Ian Jackson (2016-10-04 18:55:14)
> Russ Allbery writes ("Re: Intent to commit craziness - source package 
> unpacking"):
> > If sbuild is now at the point where you can just apt-get install sbuild,
> > run a single setup command, and be ready to build packages (which is where
> > cowbuilder is right now), I personally would be happy to use something
> > that's a bit closer to what the buildds are doing.
> 
> There is sbuild-setupchroot or something.  I do find that I don't want
> it because I like fiddling with the config, so I just use lower level
> commands myself.

to answer above questions:

sbuild supports multiple backends. The default backend is schroot. How to get
from "apt-get install sbuild" to actually building packages depends on the
backend used. For the default schroot backend, sbuild provides the
sbuild-createchroot tool which runs debootstrap and creates a schroot config
file. So if you stay with the defaults, then you run:

$ apt-get install sbuild
$ sbuild-createchroot unstable /srv/chroot/unstable-amd64
$ sbuild mypackage.dsc

The sbuild version in stable also requires you to generate a gpg keypair
(instructions are at https://wiki.debian.org/sbuild) but this inconvenience was
dropped when squeeze (which had a too-old apt) reached end of life this year.

If you use another backend than schroot (like lxc, qemu or ssh) you are so far
on your own with preparing the build chroot.

Please report any wishlist bugs that would make your life with sbuild easier in
the Debian bts.

Thanks!

cheers, josch


signature.asc
Description: signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: git workflows for general Ubuntu development

[Sean Whitton]

Dear Robie,

On Tue, Nov 15, 2016 at 05:41:56PM +, Robie Basak wrote:
> On Tue, Nov 15, 2016 at 10:24:32AM -0700, Sean Whitton wrote:
> > The most important part of the tutorial for realising this is putting
> > "single-debian-patch" and "auto-commit" in debian/source/options, but I
> > would also encourage you to read the section "Sample text for
> > README.source".
> 
> If this is necessary, then it breaks our use case unless you can also
> require all Debian packages to switch to dgit first.
> 
> In Debian, a package maintainer can decide to switch VCS system and
> write things in README.source to explain how things should be done.
> 
> In Ubuntu, switching a package's VCS, debian/source/options, and so
> forth would make it increasingly difficult to maintain a delta against
> Debian. In general we never add such a (VCS of debian/source/options)
> delta. Whatever solution we employ, it must be able to work with
> unmodified Debian source packages.

Okay, I see what you mean.  I support my suggestion was actually quite
radical: adding those two lines to d/source/options for every package
you maintain a delta for.  In that case, the merges would be easy (a
simple helper script that ensured the lines were present post-merge) and
you wouldn't need README.source because everyone would know that was how
things worked.  But that would be a massive social change!

-- 
Sean Whitton


signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: git workflows for general Ubuntu development

[Robie Basak]

Hi Sean,

Since our UOS session will start very soon, I'll reply just to the
things that I think I can address immediately for now.

On Tue, Nov 15, 2016 at 10:24:32AM -0700, Sean Whitton wrote:
> The most important part of the tutorial for realising this is putting
> "single-debian-patch" and "auto-commit" in debian/source/options, but I
> would also encourage you to read the section "Sample text for
> README.source".

If this is necessary, then it breaks our use case unless you can also
require all Debian packages to switch to dgit first.

In Debian, a package maintainer can decide to switch VCS system and
write things in README.source to explain how things should be done.

In Ubuntu, switching a package's VCS, debian/source/options, and so
forth would make it increasingly difficult to maintain a delta against
Debian. In general we never add such a (VCS of debian/source/options)
delta. Whatever solution we employ, it must be able to work with
unmodified Debian source packages.

> Like Ian, I beg you to reconsider this in the strongest possible terms!

This will only be possible if dgit actually helps us with our use cases.
If it cannot, then we either need to figure out how to add functionality
to dgit to make this possible, or we cannot use dgit.

I think a path forward might be for our system to be able to take dgit
as input, and also provide dgit as output. But this remains to be seen.

Robie


signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: git workflows for general Ubuntu development

[Sean Whitton]

Dear Robie,

Thank you for your detailed explanation of your project.  I'd like to
make just a few remarks in response to your criticisms of dgit.

Firstly, *everything* that you discuss under "Differences from Debian"
was in fact a target when dgit was designed.  I'm not going to respond
point-by-point, but in particular, dgit is designed to deal with the
fact that DDs make uploads not using dgit.  `dgit pull` handles this
very well.

On Tue, Nov 15, 2016 at 04:25:23PM +, Robie Basak wrote:
> 1. Removing .pc breaks quilt. Going with my incremental theme again, our
> import format does not break this; users do not have to learn any
> additional tools. dgit punts on this with "If you want to manipulate the
> patch stack you probably want to be looking at tools like git-dpm".

Secondly, with regard to the patches-unapplied/patches-applied debate, I
would encourage you to read dgit-maint-merge(7), a workflow tutorial
I wrote that is shipped with recent versions of dgit (or online[1]).
While this tutorial is targeted at Debian package maintainers, I think
that it could easily be adapted for use by a downstream distro.

What this tutorial encourages you to do is *stop* manipulating the patch
stack.  Users do not have to learn any additional tools basides git best
practices, which they should know anyway.  And new users do not have to
learn quilt.  IMO this is really important.

The most important part of the tutorial for realising this is putting
"single-debian-patch" and "auto-commit" in debian/source/options, but I
would also encourage you to read the section "Sample text for
README.source".

Like Ian, I beg you to reconsider this in the strongest possible terms!

[1]  
http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git-manpage/dgit.git/dgit-maint-merge.7

-- 
Sean Whitton


signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: DEP14 policy for two dots

[Robie Basak]

FTR, I answered most questions about "why not dgit?" in the thread I
just moved to vcs-pkg-discuss only[1].

For some specific questions here:

On Thu, Nov 10, 2016 at 12:31:31AM +, Ian Jackson wrote:
> dgit can work on Ubuntu too, in a readonly mode.  (It would be nice to
> make `dgit push' work on Ubuntu but that requires a suitable git
> server, and some configration on the dgit client side.)

A key difference with our system is that no infrastructure is required.
It's distributed (-able), with no special git remote.

> The --skip-patches is a vital difference.
> Has the decision to use --skip-patches been definitively taken ?

For now, to fulfill our use case, yes. In the general case, no, not at
all. Probably the best place to enter into this would be in a reply to
my fuller explanation of the reasons in [1].

> I would like to beg you to reconsider this, in the strongest possible
> terms.  --skip-patches generates a patches-unapplied tree.
> 
> A patches-unapplied tree:

Sorry, I missed reference to this list when I wrote [1]. I'll study
these and consider how they related to my reasons later.

> If you are making patches-unapplied trees I think you cannot possibly
> be representing the quilt patch stack of a `3.0 (quilt)' source
> package as a series of git commits.

Correct. This has not been our goal.

> Representing a `3.0 (quilt)' package that way is desirable, as it
> means that `git blame' and `git log' can be used to see which patches
> do what.

In contrast, in our Ubuntu development workflow, what you mention is not
a requirement, but what is a requirement is to use "git blame" and "git
log" to see when the quilt patches applied were altered. We don't want
to drill down as far as you are suggesting; instead, we want the
information at one level removed.

Robie


signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: git workflows for general Ubuntu development

[Robie Basak]

Cutting out the debian-devel and ubuntu-devel-discuss lists. I think
this subthread has quite a risk of fragmenting, so I'm moving it to the
one list (vcs-pkg-discuss) that seems most appropriate for this thread.

I have seen a few comments about "why not dgit?" and I realise that I
have yet to reply to these. Over the years I have internalised the
reasons, so have found it difficult to write down my arguments in a
cogent way. I'll attempt that here now, and I welcome replies that try
to convince me that I'm wrong. I have may some other ideas in my head I
have failed to remember right now.

I've tried hard to get this written and posted in advance of our Ubuntu
Online Summit session on this topic[4]. It took me a while though, and I
realise there is not much time left for participants to read and absorb
this. So sorry for the short notice.

For clarity, I'll call our system "usdi" as we don't have a better name
for it yet. And one fundamental point of difference appears to be
whether the git tree is "quilt popped" (usdi) or "quilt pushed with .pc
removed" (dgit). Note that an "Ubuntu merge" (our primary use case)
isn't the same as a git merge. It's more like a git rebase, but formerly
without the benefit of a VCS. If you're not familiar with this, see [1]
for details.

Please understand that we did not set off trying to solve all use cases
at once. Our goal in the design of this was not "one git to rule them
all". It was more "how can we use git to solve our immediate problem?"
My first effort[1] did not even have an automatically imported git tree.
I did it manually from source packages.

# A technical summary of what our importer does

Our imports appear in regular git repositories (not special remotes);
one per source package.

The importer (and only the importer) maintains one branch pointer per
distribution and series. These branch pointers fast forward, so users
can follow them easily.

When the importer runs for a given source package, it checks for any
newer source uploads, imports their trees and updates the
distribution+series branch pointers. These commits are equivalent to the
source packages with quilt patches popped and with no .pc directory.
This isn't enforced on other commits pushed by uploaders (see below) but
it wouldn't make sense do so anyway.

An uploader can choose to push to the git repository before the importer
runs against a corresponding upload. The uploader should push just a tag
in the form "upload/" to indicate to the importer that this is
a set of logical commits that can represent the upload (instead of
having to fall back on a wholesale import in one commit). The uploader
should not update any branch pointers. When the importer sees a new
published source version, it will find and use this tag if it passes
sanity checks. The updated distribution+series branch pointers will then
have the "upload/" commit in their histories as appropriate.

You can run the importer locally. If you run it against some current
remote tree (perhaps in future the "official" tree), then you will end
up with the same new imports as some other importer run (perhaps in the
future the "official" importer) with identical commit hashes. This is
quite convenient during development, since you can propose a branch
against a future official branch that doesn't necessarily exist yet.

# Other parts of our workflow

We have a bunch of documention-in-progress[2] and tooling[3] to help us
manipulate the tree in common ways to help us with our use cases. I
argue below why I think our model works for our use cases, so in that
sense I guess that they're relevant. But you don't need to understand
what we do in order to understand what we've done.

# Differences from Debian

Some unique challenges I think Ubuntu has over Debian:

1. Like Debian, we have NMUs (effectively). Unlike Debian, these happen
all the time. Unlike Debian, we can't choose to switch a package
maintainership over to a particular git model. In addition to non-git
uploads from other Ubuntu developers, we also have to deal with non-git
uploads from Debian, which is the primary source of commits and uploads
for the package. Whatever model we choose, we have to be able to deal
with the fact that the primary input from the system will not contain
nicely separated logical commits.

2. Being derived from Debian, we get far more benefit from git if git
understands our inheritence model. 1.0-1ubuntu1 in Ubuntu should have
1.0-1 from Debian as a parent in our git model. We may be able to get
away without this, since "Ubuntu merges" are primarily a rebase-based
workflow for us. However, getting the inheritance graph correct allows
us to automate more and more of this. Right now, we have the rebase
graft points identified for us automatically. In the future, we might
even be able to create a git-based "merge-o-matic" which could do
"Ubuntu merges" automatically where there are no conflicts.

3. As an Ubuntu development team, we need a system that presents 

WESTERN UNION SPENDE

[WESTERN UNION ©]

Sir/Madam,

   Hiermit möchten wir Sie informieren, dass WESTERN UNION Internationale 
Spendenprojekt hat Ihnen eine Barzuwendung von ausgezeichnet [200,000EURO], als 
Charity-Spende von Western union International,Großbritannien, förderte in 
Verbindung mit Kinderfonds der Vereinten Nationen [UNICEF] .

   Für weitere Informationen über die Verarbeitung und Auszahlung Ihrer 
Zuschüsse Ansprüche Bitte kontaktieren Sie Mr Mike Morris, der nationale 
Sekretär der Stiftung mit Ihrer Qualifikation Number [WNI/101/231/BDB] so 
schnell wie möglich

 WESTERN UNION © Bezirksleiter (Herr Mike Moris)
 Website: www.westernunion.com
 E-mail: wester...@outlook.com

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: DEP14 policy for two dots

[Raphael Hertzog]

On Wed, 09 Nov 2016, Ian Jackson wrote:
> Raphael Hertzog writes ("Re: DEP14 policy for two dots"):
> > Ok, can you prepare a patch for DEP-14 then? I'll apply it as it looks like
> > a reasonable extension.
> 
> Attached.  FYI I intend to implement this in dgit.

Thanks, committed to the dep svn repository.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: DEP14 policy for two dots

[Ian Jackson]

I forgot one:

Ian Jackson writes ("Re: DEP14 policy for two dots"):
> A patches-unapplied tree:
> 
>  * produces confusing and sometimes misleading output from
>git grep, or (even if appropriate history is available)
>with git blame;
> 
>  * cannot be used with `git cherry pick ';
> 
>  * cannot be used as a basis for `git merge upstream/';
> 
>  * requires that the user not say `git diff upstream/master'
>but rather that they read patches in debian/patches;
> 
>  * cannot be directly edited by the user;
> 
>  * leaves the git tree dirty after every build with dpkg-buildpackage
>no matter how careful or tidy the package's build system.

   * when built with the upstream build system (eg, for a GNU package,
 ./configure && make), silently and successfuly produces wrong
 output - perhaps dangerously wrong output, such as binaries
 lacking important security patches.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: DEP14 policy for two dots

[Nish Aravamudan]

On 09.11.2016 [21:27:14 +], Ian Jackson wrote:
> Raphael Hertzog writes ("Re: DEP14 policy for two dots"):
> > Ok, can you prepare a patch for DEP-14 then? I'll apply it as it looks like
> > a reasonable extension.
> 
> Attached.  FYI I intend to implement this in dgit.

Thank you! We will follow the same in the Ubuntu tooling used by the Server
Team.

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: DEP14 policy for two dots

[Ian Jackson]

Raphael Hertzog writes ("Re: DEP14 policy for two dots"):
> Ok, can you prepare a patch for DEP-14 then? I'll apply it as it looks like
> a reasonable extension.

Attached.  FYI I intend to implement this in dgit.

Thanks,
Ian.

>From 5c63400e9be8cb1532515764a1179730aed550fb Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Wed, 9 Nov 2016 18:36:23 +
Subject: [PATCH] DEP-14: Version -> refname mangling: Escape dots

Signed-off-by: Ian Jackson 
---
 deps/dep14.mdwn | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/deps/dep14.mdwn b/deps/dep14.mdwn
index 4c7ce63..a7328a4 100644
--- a/deps/dep14.mdwn
+++ b/deps/dep14.mdwn
@@ -3,7 +3,7 @@
 Title: Recommended layout for Git packaging repositories
 DEP: 14
 State: DRAFT
-Date: 2014-11-04
+Date: 2016-11-09
 Drivers: Raphael Hertzog 
 URL: http://dep.debian.net/deps/dep14
 Source: http://anonscm.debian.org/viewvc/dep/web/deps/dep14.mdwn
@@ -60,8 +60,26 @@ Version mangling
 
 When a Git tag needs to refer to a specific version of a Debian package,
 the Debian version needs to be mangled to cope with Git's restrictions.
-The colon (`:`) needs to be replaced with a percent (`%`), and the tilde
-(`~`) needs to be replaced with an underscore (`_`).
+This mangling is deterministic and reversible:
+
+ * Each colon (`:`) is replaced with a percent (`%`)
+ * Each tilde (`~`) is replaced with an underscore (`_`)
+ * A hash (`#`) is inserted between each pair of adjacent dots (`..`)
+ * A hash (`#`) is appended if the last character is a dot (`.`)
+ * If the version ends in precisely `.lock`
+   (dot `l` `o` `c` `k`, lowercase, at the end of the version),
+   a hash (`#`) is inserted after the dot, giving `.#lock`.
+
+This can be expressed concisely in the following Perl5 statements:
+
+ y/:~/%_/;
+ s/\.(?=\.|$|lock$)/.#/g;
+
+The reverse transformation is:
+
+ * Each percent (`%`) is replaced with a colon (`:`)
+ * Each underscore (`_`) is replaced with a tilde (`~`)
+ * Each hash (`#`) is deleted
 
 Packaging branches and tags
 ===
@@ -274,3 +292,4 @@ Changes
 ===
 
 * 2014-11-05: Initial draft by Raphaël Hertzog.
+* 2016-11-09: Extended version mangling to troublesome dots - Ian Jackson.
-- 
2.10.2



-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: DEP14 policy for two dots

[Raphael Hertzog]

On Tue, 08 Nov 2016, Ian Jackson wrote:
> > The reverse rule is to convert _ and % and delete all #.
> 
> Quoted for completeness.

Ok, can you prepare a patch for DEP-14 then? I'll apply it as it looks like
a reasonable extension.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: DEP14 policy for two dots

[Ian Jackson]

Ian Jackson writes ("Re: DEP14 policy for two dots"):
> Raphael Hertzog writes ("Re: DEP14 policy for two dots"):
> > On Fri, 04 Nov 2016, Ian Jackson wrote:
> > > My proposal is reversible.  It does not need to be extensible.
> > 
> > So what about "..."? Would it give ".#.#."?
> 
> Yes.  I said (fixing my bug):
> 
>  > Insert "#":
>  >- between each pair of adjacent dots
>  >- after any trailing dot
>  >- before any leading dot
>   - after the `.' of a trailing `.lock'
> 
> The latter is necessary because git reserves .lock.  (!)
> The summary is `add # after any troublesome dot' (discounting leading
> dots which you say are now illegal in Debian).
> 
> I'm running some exhaustive tests to check that this rule is
> sufficient, because I'm not sure I trust the git docs.

I have now:

 * Read the code in git upstream master.  It's not particularly easy
   to analyse conclusively, but I'm pretty sure it doesn't have any
   special cases which involve longer strings than ".lock".  I felt I
   was able to identify the manpage rule corresponding to each element
   of the logic.

 * Conducted an exhaustive search of all strings of length 6
   or less.  Specifically, I generated all strings of between
   zero and 6 characters from this set (in C notation):

   "0123456789"
   "abcdefghijklmnopqrstuvwxyz"
   "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
   ".-+:~"

   filtered them by whether the `parseversion' function in
   dpkg likes them, escaped them with the following perl
   script

 #!/usr/bin/perl -pw
 use strict;

 y/:~/%_/;
 s/\.(?=\.|$|lock$)/.#/g;

   prepended "refs/tags/" to each one and fed them to
   git-check-ref-format (modified to run in a pipe mode).

   I also verified that when I don't escape ".lock", my exhaustive
   search correctly detects the illegal ref name "refs/tags/1.lock"
   genrated by version "1.lock" (and similar).

> The reverse rule is to convert _ and % and delete all #.

Quoted for completeness.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: DEP14 policy for two dots

[Ian Jackson]

Raphael Hertzog writes ("Re: DEP14 policy for two dots"):
> On Fri, 04 Nov 2016, Ian Jackson wrote:
> > My proposal is reversible.  It does not need to be extensible.
> 
> So what about "..."? Would it give ".#.#."?

Yes.  I said (fixing my bug):

 > Insert "#":
 >- between each pair of adjacent dots
 >- after any trailing dot
 >- before any leading dot
  - after the `.' of a trailing `.lock'

The latter is necessary because git reserves .lock.  (!)
The summary is `add # after any troublesome dot' (discounting leading
dots which you say are now illegal in Debian).

I'm running some exhaustive tests to check that this rule is
sufficient, because I'm not sure I trust the git docs.

> What's the rule to apply? if it's just to drop the "#", then yes
> it's reversible in a single step. If it's "s/\.#\./../g" then you need
> to do it multiple times until you no longer find ".#.".

The reverse rule is to convert _ and % and delete all #.

> > > My suggestion would be to allow "##". 
> > > Thus my personal preference would be to replace ".." with ".#2e#".
> > 
> > This is a bad idea because it (implicitly) makes the conversion
> > nondeterministic.
> 
> We define the conversion rule in DEP-14. We can define it in a
> deterministic way.

If you define it in a deterministic way then it is by definition not
extensible, because all valid version strings have a definitive git
tag representation.

Unless by `extensible' you mean `we can update the rule if we discover
that some of the specified git tag representations are not accepted by
git', or `we can update the rule if the set of valid Debian version
strings is extended'.  But this is true of any proposal, no matter
what the syntax is.

> I wanted something extensible because what's allowed in git ref names
> might evolve. It would not be the first time that a special syntax
> is introduced with a new feature.

I think the git folks are going to try not to further restrict the git
ref name syntax.  After all, if they do restrict it, what about
existing tags with the now-forbidden names ?

> Which of # or = is more likely to be used for a new syntax/feature in git?
> My bet would go for "#" so that "=" is an even better choice.

I think = is more likely to be used for other things (both by git and
by others).

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: DEP14 policy for two dots

[Raphael Hertzog]

On Fri, 04 Nov 2016, Ian Jackson wrote:
> Raphael Hertzog writes ("Re: DEP14 policy for two dots"):
> > We have defined simple "readable" mappings for the common cases that
> > we encounter frequently. Now if we need mappings for silly things
> > that we don't encounter, I would suggest to use something easily
> > reversible and extendable.
> 
> My proposal is reversible.  It does not need to be extensible.

So what about "..."? Would it give ".#.#."?

What's the rule to apply? if it's just to drop the "#", then yes
it's reversible in a single step. If it's "s/\.#\./../g" then you need
to do it multiple times until you no longer find ".#.".

I wanted something extensible because what's allowed in git ref names
might evolve. It would not be the first time that a special syntax
is introduced with a new feature.

> > My suggestion would be to allow "##". 
> > Thus my personal preference would be to replace ".." with ".#2e#".
> 
> This is a bad idea because it (implicitly) makes the conversion
> nondeterministic.

We define the conversion rule in DEP-14. We can define it in a
deterministic way.

> You might write some rule about which . should be replaced by #2e#
> but it would be easy to misimplement.

It's possible to misimplement almost any rule.

> Also if we are going to introduce an arbitrary codepoint quoting
> system like this it should be identical to quoted-printable (bad as
> that is).

It's limited to ASCII but I guess it's highly unlikely that we will
one day allow unicode in version strings. So yes, that would be an option
as well. Given that "=" is forbidden in version numbers and allowed in git
refnames, it should work.

Which of # or = is more likely to be used for a new syntax/feature in git?
My bet would go for "#" so that "=" is an even better choice.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: DEP14 policy for two dots

[Ian Jackson]

Nish Aravamudan writes ("DEP14 policy for two dots"):
> [ Raphael, apologies for sending twice, had a error in the headers in
> the prior one ]
> 
> Not sure exactly where to ask this better than debian-devel, but I am
> working on an importer for the Ubuntu Server team which parses published
> versions of source packages in Debian and Ubuntu. I ran into an issue
> today where there is a published version of src:pcre3 with version
> '8.30..2'. `man git-check-ref-format` says that reference names "cannot
> have two consecutive dots ..  anywhere." DEP14 specifies appropriate
> substitutions for : and ~, but it seems like .. should also be accounted
> for so I can correctly tag historic versions?

Urk.  How exciting.  I think we may need a more general escaping
scheme for these and other weirdnesses.

I have an interest as dgit uses DEP-14 tag escaping.  I have CC'd the
vcs-pkg list.


tl;dr: I think we should insert `#' characters as needed.


Looking at git-check-ref-format(1) and
https://wiki.debian.org/Punctuation:

  .special to git, generally permitted in versions,
   and we want it usually to be literal - this is our problem

  ~special to git, permitted in versions, handled by DEP-14 as _
  :special to git, epoch in versions, handled by DEP-14 as %

  @special to git (although sometimes allowed), forbidden in versions

  % _  not special to git but already used by DEP-14

  # , =
   not mentioned in the git manual as special, forbidden in versions

  ]not special to git, although [ is so let's not, eh ?

  + -  not special to git, permitted in versions

  " ' $ & ( ) * ; < > ? `
   not mentioned in the git manual but troublesome shell
   metacharacters which we would be insane to use here

  [ / { }
   interpreted specially by git some of the time,
   forbidden in versions - not really useful

  ^ ? * \
   all of these are forbiden by git, not permitted in versions

So I think in fact the only thing we have a problem with is multiple
dots.  Looking at the summary above, we have the choice of one of
these:

  #   Its use as a shell comment character is fine, because when inside
  a version tag it is always preceded by some string like
  "debian/" or "upstream/".  We would almost never need to put it
  at the start of the encoded version string anyway, and we have
  already tolerated a similar situation with ~.

  There is possible confusion with HTML fragment identifiers, and
  possibly in languages other than shell which use # for
  comments (athough hopefuly they aren't dealing with our versions
  as literals anyway).

   Proposed rule:

   Insert "#":
  - between each pair of adjacent dots
  - after any trailing dot
  - before any leading dot

   Examples:
8.30..2 => 8.30.#.2
8.30.   => 8.30.#
.42 => #.42

  ,   I would like to avoid this because lots of people are probably
  using it as a list separator in ways that are difficult for us
  to predict.  If we used it, I would suggest the same as for #.

  =   In principle we could use this.  I don't like it for a similar
  reason to above.  If we did use it it might look a bit like
  Q-P encoding in some contexts.

  @   We could use this although I wouldn't like to rely on the fact
  that git dislikes `@{' and `@' but not @ followed by other
  things.

  % Reusing this is tempting because an epoch separator can never
  follow `.', so any `%' after any `.' would unambiguously mean
  `escape for dot rather than colon'.  But in principle `.' can
  occur at the start of the version, so `:3' and `.3' both =>
  `%3'.  There would have to be some horror of an exception rule.
  (Although `:3' and `3' compare equal as Debian versions, they
  are different textual strings and the tag needs to convey the
  whole string.)

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Intent to commit craziness - source package unpacking

[Ian Jackson]

Russ Allbery writes ("Re: Intent to commit craziness - source package 
unpacking"):
> Ian Jackson  writes:
> > I'm not sure of the logic behind that.  I don't think dgit helps much
> > with the kind of tasks that pristine-tar helps with.
> 
> The main benefit of pristine-tar is that you can clone the development
> repository on any random host and do package development, build local
> packages for testing, and do a package upload without having to locate any
> additional pieces.  I haven't been following dgit development closely, but
> it did sound like you were addressing the same use case.

dgit will fetch the orig tarball for you.  So you don't have to
"locate" the pieces, but you do have to pay the download cost.

> If sbuild is now at the point where you can just apt-get install sbuild,
> run a single setup command, and be ready to build packages (which is where
> cowbuilder is right now), I personally would be happy to use something
> that's a bit closer to what the buildds are doing.

There is sbuild-setupchroot or something.  I do find that I don't want
it because I like fiddling with the config, so I just use lower level
commands myself.

> However, cowbuilder does just work, in my experience, and it's nice to not
> have to change.

Of course.

I'm sorry I stepped into the argument about which chroot build tool is
best :-).

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Intent to commit craziness - source package unpacking

[Ian Jackson]

Guido Günther writes ("Re: Intent to commit craziness - source package 
unpacking"):
> On Mon, Oct 03, 2016 at 04:15:08PM +0100, Ian Jackson wrote:
> [..snip..]
> >   Recommends: pristine-tar (>= 0.5)
...> > 
> > pristine-tar has been declared unmaintainable by its original
> > author and abandoned.
...
> > Certainly dgit users do not need pristine-tar.  But our dependency
> > system does not allow us to honour only direct Recommends and not
> > transitive ones.
> 
> Looking at git.debian.org I found plenty of users. I did an archive
> import of sid during Debconf and was only ran into 20 pristine-tar
> failures (bugs yet to be filed).

Interesting.

> From the discussions at DC16 we're on our way to make this a hard
> dependency:
> 
>  http://lists.sigxcpu.org/pipermail/git-buildpackage/2016-July/000143.html
> 
> The only thing I can think of (since we will keep support for not using
> pristine-tar nevertheless) is using:
> 
>  Recommends: pristine-tar | dgit

I'm not sure of the logic behind that.  I don't think dgit helps much
with the kind of tasks that pristine-tar helps with.

> >   Recommends: cowbuilder<= jessie
> >   Recommends: cowbuilder | pbuilder | sbuild<= sid
...
> gbp buildpackage has integration with pbuilder/cowbuilder (via
> git-builder) and I know people are using it since its better integrated
> into gbp since you don't need additional and it's documented in the
> manual. The sbuild dependency is there to have people not pull in
> cowbuilder/pbuilder so they can use --git-builder=sbuild.

Ah.

> Not sure what can be done here.

It sounds like it should be left as-is, TBH.

> >   Depends: devscripts
> > 
> > devscripts is very full of commands with poor namespacing.  It
> > also has an enormous dependency chain.
> > 
> > Unfortunately dgit has a dependency on devscripts too.  Maybe we
> > should work to take the pieces of devscripts that we really need
> > and put them in something else, or something.
> 
> We're mostly using dch with "gbp dch" and I would also be happy to have
> the dependency chain shortened.

If it were my package, and that was all I depended on devscripts for,
I would drop it entirely.  I think it's fair to expect someone who
uses `gbp dch' to install the package containing dch.  But this is a
matter of taste.

dgit has a much harder dependency because dgit push uses dput.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Intent to commit craziness - source package unpacking

[Guido Günther]

Hi Ian,
On Mon, Oct 03, 2016 at 04:15:08PM +0100, Ian Jackson wrote:
[..snip..]
> Because I'm a pernickety type of person I reviewed the dependencies of
> git-buildpackage.  I have some qualms about the following
> dependencies:
> 
>   Recommends: pristine-tar (>= 0.5)
> 
> pristine-tar has been declared unmaintainable by its original
> author and abandoned.
> 
> IDK know what proportion of actual git trees that gbp users will
> encounter would break without pristine-tar.  Perhaps this
> dependency can be demoted to Suggests, but I don't really know.
> 
> Certainly dgit users do not need pristine-tar.  But our dependency
> system does not allow us to honour only direct Recommends and not
> transitive ones.

Looking at git.debian.org I found plenty of users. I did an archive
import of sid during Debconf and was only ran into 20 pristine-tar
failures (bugs yet to be filed).

>From the discussions at DC16 we're on our way to make this a hard
dependency:

 http://lists.sigxcpu.org/pipermail/git-buildpackage/2016-July/000143.html

The only thing I can think of (since we will keep support for not using
pristine-tar nevertheless) is using:

 Recommends: pristine-tar | dgit

>   Recommends: cowbuilder<= jessie
>   Recommends: cowbuilder | pbuilder | sbuild<= sid
> 
> Many users of dgit will never want to build a package for upload.
> This is probably true of gbp users too.  I'm not sure why it's
> valuable to have this as a Recommends dependency for gbp.
>
> I think more people now are using sbuild.  I'm not sure that
> pulling in cowbuilder on systems where the user has not yet
> installed such a tool is right.

gbp buildpackage has integration with pbuilder/cowbuilder (via
git-builder) and I know people are using it since its better integrated
into gbp since you don't need additional and it's documented in the
manual. The sbuild dependency is there to have people not pull in
cowbuilder/pbuilder so they can use --git-builder=sbuild.

Not sure what can be done here.

>   Depends: devscripts
> 
> devscripts is very full of commands with poor namespacing.  It
> also has an enormous dependency chain.
> 
> Unfortunately dgit has a dependency on devscripts too.  Maybe we
> should work to take the pieces of devscripts that we really need
> and put them in something else, or something.

We're mostly using dch with "gbp dch" and I would also be happy to have
the dependency chain shortened.

> Overall I don't think these are an impediment.  But since I had done
> the review, I thought I'd share my thoughts.

Cheers,
 -- Guido

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Intent to commit craziness - source package unpacking

[Ian Jackson]

Ian Jackson writes ("Re: Intent to commit craziness - source package 
unpacking"):
> Guido Günther writes ("Re: Intent to commit craziness - source package 
> unpacking"):
> > 'gbp pq import' does have 'debian/patches' since it just puts the
> > patches that are in debian/patches on top of the unpatched source
> > tree. In contrast to your solution it doesn't try to be able to
> > roundtrip without changes for any given series on "gbp pq export". This
> > is only true if the series was also created by "gbp pq" (or adheres to
> > what git-format-patch does).
> 
> Currently the output of dpkg-source --commit doesn't look much like
> the output of git-format-patch.
> 
> I have tried to make dgit produce patches (when it needs to produce
> patches) that look like dpkg-source --commit.  But maybe it should
> produce patches using git-format-patch (or that look like
> git-format-patch).

I have looked at the specs (including DEP-3) and the behaviour of the
various tools a bit more.  I have decided that when I should replace
dgit's adhoc algorithm for generating a DEP-3 compliant commit
message, with a call to git-format-patch.  (The actual patch body has
to come from dpkg-soure, because of the special handling of debian/,
etc.  This code path is used when a dgit user is pushing and needs to
convert raw git commits into `3.0 (quilt)' patches.)

And, after having half-written a DEP-3 importer (ie a thing that turns
a DEP-3 patch message into a git commit), and investigating the
behaviour of various tools, I have decided I should just use gbp pq.
(This will replace the repeated use of dpkg-source --before-build as a
described in my previous mail.)

This will mean that dgit will grow a hard dependency on
git-buildpackage.


Because I'm a pernickety type of person I reviewed the dependencies of
git-buildpackage.  I have some qualms about the following
dependencies:

  Recommends: pristine-tar (>= 0.5)

pristine-tar has been declared unmaintainable by its original
author and abandoned.

IDK know what proportion of actual git trees that gbp users will
encounter would break without pristine-tar.  Perhaps this
dependency can be demoted to Suggests, but I don't really know.

Certainly dgit users do not need pristine-tar.  But our dependency
system does not allow us to honour only direct Recommends and not
transitive ones.

  Recommends: cowbuilder<= jessie
  Recommends: cowbuilder | pbuilder | sbuild<= sid

Many users of dgit will never want to build a package for upload.
This is probably true of gbp users too.  I'm not sure why it's
valuable to have this as a Recommends dependency for gbp.

I think more people now are using sbuild.  I'm not sure that
pulling in cowbuilder on systems where the user has not yet
installed such a tool is right.

  Depends: devscripts

devscripts is very full of commands with poor namespacing.  It
also has an enormous dependency chain.

Unfortunately dgit has a dependency on devscripts too.  Maybe we
should work to take the pieces of devscripts that we really need
and put them in something else, or something.

Overall I don't think these are an impediment.  But since I had done
the review, I thought I'd share my thoughts.

Regards,
Ian.


-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Intent to commit craziness - source package unpacking

[Ian Jackson]

Guido Günther writes ("Re: Intent to commit craziness - source package 
unpacking"):
> The authorship and subject information is taken from the patch if
> available or made up from the filename and committer when not.
> 
> If patches in the series file are in subdirs of debian/patches we store
> that in "Gbp-Pq: topic" in the commit message. The patch name itself
> is stored in "Gbp-Pq: Name" we can reproduce it on "gbp pq export"
> independent from the patch's subject.

Right.

> >   Bear in mind that because the output of gbp-pq import doesn't
> >   contain debian/patches, I would need to rewrite its output (perhaps
> >   with git-filter-branch).
> 
> 'gbp pq import' does have 'debian/patches' since it just puts the
> patches that are in debian/patches on top of the unpatched source
> tree. In contrast to your solution it doesn't try to be able to
> roundtrip without changes for any given series on "gbp pq export". This
> is only true if the series was also created by "gbp pq" (or adheres to
> what git-format-patch does).

Currently the output of dpkg-source --commit doesn't look much like
the output of git-format-patch.

I have tried to make dgit produce patches (when it needs to produce
patches) that look like dpkg-source --commit.  But maybe it should
produce patches using git-format-patch (or that look like
git-format-patch).

Thanks for suggesting libvirt as an example.  I will play about with
it.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Intent to commit craziness - source package unpacking

[Ian Jackson]

Ian Jackson writes ("Re: Intent to commit craziness - source package 
unpacking"):
> Guido Günther writes ("Re: Intent to commit craziness - source package 
> unpacking"):
> > Hi Ian,
> 
> Hi, thanks for your attention.

Please disregard this email.  I hadn't finished editing it!

Ian.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Intent to commit craziness - source package unpacking

[Guido Günther]

Hi Ian,
On Wed, Sep 28, 2016 at 11:09:03AM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: Intent to commit craziness - source package 
> unpacking"):
> > Thanks for your comments.  I feel unblocked :-).
> 
> So, I now intend to go and implement my plan.
> 
> There will be a little while (perhaps a few weeks) before I am in a
> postion to release this in dgit 2.0.  But after I do that, I will not
> want to change the import algorithm again: it is important that the
> imports be as stable as possible.
> 
> So now would be a good time for maintainers of git packaging tools (eg
> git-dpm and gpb) to have an opinion about the detail of the generated
> pseudohistory - in particular, the detail of the commits generated
> from the `3.0 (quilt)' dpkg-source patches.

>From what I understand the format to produce is not compatible in what
"gbp pq" currently expects, that is just one commit per patch without
any chnages to other files in debian/ (like the series file). 'gbp pq'
is just a helper for handling the quilt patches, not more.

I don't understand yet how you expect the actual workflow between gbp
and dgit to look like but I would be happy to have a look at a prototype
dgit created history. I can e.g. imagine telling "gbp pq" to filter out
chnages in debian/ during patch creation.
 
> Also, I would welcome suggestions for what kind of compatibility test
> I could perform on such a series of commits.  dgit has an extensive
> test suite (advertised via autopkgtest) which would be well-suited to
> such a compatibility test.
> 
> An example of such a tree might be, "split out the patch queue part of
> the git pseudohistory and feed it to gbp-pq, asking gbp-pq to
> regenerate the source package, and expect the output to be identical
> to the original input source package".  Guido, if I get the
> preconditions right, should I expect such a test to pass ?  Is there a
> risk it would break in the future due to changes in gbp-pq's
> conversion algorithm ?

It would be nice to have "gbp pq" reproduce debian/patches identically
on such a tree but I would rather have a look at how the dgit created
history finally looks once you implemented it. gbp-pq's conversion
algorithm is not expected to change (at least in the default
configuration, I have some other ideas about patch handling but that
would not modify the current workflow ).
Hope that helps,
 -- Guido

> I confess that I am less familiar with git-dpm.  I don't know what I
> should be thinking about to try to make the output most useful to
> git-dpm users.
> 
> (I also don't know whether the goals of helping git-dpm users and
> gbp-pq users, and potentially users of any other tools, are in
> conflict.
> 
> It would be annoying if these tools would disagree about the best form
> of import of a particular patch queue: the import algorithm should be
> the same for different dgit users, so I wouldn't be able to make this
> a per-user configuration option and would have to choose..)
> 
> Thanks,
> Ian.
> 
> -- 
> Ian Jackson    These opinions are my own.
> 
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
> 
> ___
> vcs-pkg-discuss mailing list
> vcs-pkg-discuss@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
> 

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Intent to commit craziness - source package unpacking

[Ian Jackson]

Ian Jackson writes ("Re: Intent to commit craziness - source package 
unpacking"):
> Thanks for your comments.  I feel unblocked :-).

So, I now intend to go and implement my plan.

There will be a little while (perhaps a few weeks) before I am in a
postion to release this in dgit 2.0.  But after I do that, I will not
want to change the import algorithm again: it is important that the
imports be as stable as possible.

So now would be a good time for maintainers of git packaging tools (eg
git-dpm and gpb) to have an opinion about the detail of the generated
pseudohistory - in particular, the detail of the commits generated
from the `3.0 (quilt)' dpkg-source patches.

Also, I would welcome suggestions for what kind of compatibility test
I could perform on such a series of commits.  dgit has an extensive
test suite (advertised via autopkgtest) which would be well-suited to
such a compatibility test.

An example of such a tree might be, "split out the patch queue part of
the git pseudohistory and feed it to gbp-pq, asking gbp-pq to
regenerate the source package, and expect the output to be identical
to the original input source package".  Guido, if I get the
preconditions right, should I expect such a test to pass ?  Is there a
risk it would break in the future due to changes in gbp-pq's
conversion algorithm ?

I confess that I am less familiar with git-dpm.  I don't know what I
should be thinking about to try to make the output most useful to
git-dpm users.

(I also don't know whether the goals of helping git-dpm users and
gbp-pq users, and potentially users of any other tools, are in
conflict.

It would be annoying if these tools would disagree about the best form
of import of a particular patch queue: the import algorithm should be
the same for different dgit users, so I wouldn't be able to make this
a per-user configuration option and would have to choose..)

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Intent to commit craziness - source package unpacking

[Ian Jackson]

tl;dr:

 * dpkg developers, please tell me whether I am making assumptions
   that are likely to become false.  Particularly, on the behaviour of
   successive runs of dpkg-source --before-build with successively
   longer series files.

 * git-buildpackage and git-dpm developers, please point me to
   information about what metadata to put into the commit message for
   a git commit which represents a dpkg-source quilt patch.  I would
   like these commits to be as convenient for gbp and git-dpm users as
   possible.


Hi.

Currently when dgit needs to import a .dsc into git, it just uses
dpkg-source -x, and git-add.  The result is a single commit where the
package springs into existence fully formed.  This is not as good as
it could be.  I would like to represent (in the git pseudohistory) the
way that the resulting tree is constructed from the input objects.

In particular, I would like to: represent the input tarballs as a
commit each (which all get merged together as if by git merge -s
subtree), and for quilt packages, each patch as a commit.  But I want
to avoid (as much as possible) reimplementing the package extraction
algorithm in dpkg-source.

dpkg-source does not currently provide interfaces that look like they
are intended for what I want to do.  And dgit wants to work with old
versions of dpkg, so I don't want to block on getting such interfaces
added (even supposing that a sane interface could be designed, which
is doubtful).

So I intend to do as follows.  (Please hold your nose.)

* dgit will untar each input tarball (other than the Debian tarball).

  This will be done by scanning the .dsc for things whose names look
  like (compressed) tarballs, and using the interfaces provided by
  Dpkg::Compression to get at the tarball.

  Each input tarball unpack will be done separately, and will be
  followed by git-add and git-write tree, to obtain a git tree object
  corresponding to the tarball contents.

  That tree object will be made into a commit object with no parents.
  (The package changelog will be searched for the earliest version
  with the right upstream version component, and the information found
  there used for the commit object's metadata.)

* dgit will then run dpkg-source -x --skip-patches.

  Again, git plumbing will be used to make this into a tree and a
  commit.  The commit will have as parents all the tarballs previous
  mentioned.  The metadata will come from the .dsc and/or the
  final changelog entry.

* dgit will look to see if the package is `3.0 (quilt)' and if so
  whether it has a series file.  (dgit already rejects packages with
  distro-specific series files, so we need worry only about a single
  debian/patches/series file.)

  If there is a series file, dgit will read it into memory.  It will
  then iterate over the series file, and each time:
- write into its playground a series file containing one
  more non-comment non-empty line to previously
- run dpkg-source --before-build (which will apply that
  additional patch)
- make git tree and commit objects, using the metadata from
  the relevant patch file to make the commit (if available)
- each commit object has as a parent the previous commit
  (either the previous commit, or the commit resulting from
  dpkg-source -x)

  After this the series file has been completely rewritten.

* dgit will then run one final invocation of dpkg-source
  --before-build.  This ought not to produce any changes, but if
  it does, they will be represented as another commit.

* As currently, there will be a final no-change-to-the-tree
  pseudomerge commit which stitches the package into the relevant dgit
  suite branch; ie something that looks as if it was made with git
  merge -s ours.

* As currently, dgit will take steps so that none of the git trees
  discussed above contain a .pc directory.


This has the following properties:

* Each input tarball is represented by a different commit; in usual
  cases these commits will be the same for every upload of the same
  upstream version.

* For `3.0 (quilt)' each patch's changes to the upstream files appears
  as a single git commit (as is the effect of the debian tarball).
  For `1.0' non-native, the effect of the diff is represented as a
  commit.  So eg `git blame' will show synthetic commits corresponding
  to the correct parts of the input source package.

* It is possible to `git-cherry-pick' etc. commits representing `3.0
  (quilt)' patches.  It is even possible fish out the patch stack as
  git branch and rebase it elsewhere etc., since the patch stack is
  represented as a contiguous series of commits which make only the
  relevant upstream changes.

* Every orig tarball in the source package is decompressed twice, but
  disk space for only one extra copy of its unpacked contents is
  needed.  (The converse would be possible in principle but would be
  very hard to arrange with the current interfaces provided by the
  various tools.)

* 

Re: git, debian/ tags, dgit - namespace proposal [and 1 more messages]

[Ian Jackson]

Ian Jackson writes ("Re: git, debian/ tags, dgit - namespace proposal 
[and 1 more messages]"):
> Colin Watson suggested (in pers.comm)
>pkg/debian/
> This is better but it still has a problem with collate order.
> 
> It may seem a petty thing to worry about, but for the reasons I
> explain above I want something that sorts before `debian/'.

A conversation with Owen Dunn produced suggestions of `actual' and
`archive' as name components.

I'm considering:
   archive/{debian,ubuntu}/
   {debian,ubuntu}/archive/

I'm still considering the capitalisation idea.

Other suggestions welcome.

Thanks,
Ian.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

git, debian/ tags, dgit - namespace proposal

[Ian Jackson]

Currently, the debian/ git tag namespace is used by a number
of different tools, and can mean different things in different
packages and sometimes even different things for the same package in
different repos or trees.

dgit produces, and the dgit git server requires, tags of this form,
which refer to the dgit branch, which is roughly what some people call
a `patches-applied packaging branch'.

So far, dgit has been using debian/ for this.  But this is a
problem because this tag namespace is used for other purposes and has
no clear meaning.  I'm currently working on dgit native push support
for users of 3.0-quilt+git-buildpackage, where this is particularly
bad because it would involve dgit making two tags with the same
name (!)

Having considered things, I think it would be best for dgit to concede
this area of namespace for all the existing uses.  Declaring those
existing uses wrong, just because they're varied and and mutually
inconsistent, is not very helpful.  Consequently I need a new
namespace.  I don't want to put `dgit' in the name because the format
is not specific to dgit.  It is simply the result of `dpkg-source -x'
(only without the .pc directory which dpkg-source sometimes produces).


I am currently thinking that dgit would start to use the tag namespace

   Debian/

instead.  These tags would always refer to a

  Patches-applied packaging branch (where applicable containing a
  patch to add or update .gitignore).

For other distros, I would likewise capitalise just the first
character of the distro name (with `ucfirst' in Perl).  So
`Ubuntu/'.   is translated as specified in DEP-14.


So this message is:

* A request for anyone to say if they know of a reason I shouldn't do
  this.

* A declaration (currently, tentative) of intent to claim this part of
  the git tag namespace.

* A proposal to update DEP-14 to declare that "vendor" in DEP-14
  should start with a lowercase letter, and ideally, to reserve the
  corresponding starts-with-uppercase tags for dgit.


Thanks,
Ian.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: git-buildpackage / dgit integration

[Ian Jackson]

Guido Günther writes (Re: git-buildpackage / dgit integration):
 On Sun, Aug 16, 2015 at 03:46:46PM +0100, Ian Jackson wrote:
   * .gitignore: We agree that the source package should contain
 .gitignore if the git tree does.  (dgit requires this.)
  
 If the way that gbp does builds currently ends up with .gitignore
 missing from source packages, this needs to be fixed.

 I do wonder if this is an open issue? I looked at git trees
 containing .gitignore and they ended up in the source package.
 In case the Debian maintainer modifies .gitignore this will then end up
 as a quilt patch of course.

Thanks for looking at this.  My summary was inaccurate.  If _upstream_
have a gitignore then it does indeed end up in the package.  But if
the gitignore is created or changed by the maintainer, the default -I
omits it, I think.

I haven't tried this with gbp yet.  (I'm currently wrestling with some
dgit misbehaviour with 3.0 single-debian-patch.)  If I'm wrong then
excellent.

Ian.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: My use case of git-buildpackage

[Yaroslav Halchenko]

On Thu, 03 Nov 2011, Daniel Dehennin wrote:
 First, I'm not a Debian maintainer, I mostly do some package for my
 personal use, to follow SVN trunk or git HEAD of some softwares.

that is the idea behind Debian -- personal use could benefit others
alike -- why not to share those packages with the rest of debian
community through finalizing packaging so it is compliant with debian
standards, and then seeking sponsored upload?

 There are some items about which I would like to discuss, like:
 - automatic handling of debia/changelog

git-dch?

 - multi-distributions/version packaging (and avoiding conflicts)

for neurodebian we use our backport-dsc
http://github.com/neurodebian/neurodebian/blob/HEAD/tools/backport-dsc

NB yet to create a blog post on our set of little helpers, altogether
usually we just call nd_build4all X.dsc to get it built across releases
of debian and ubuntu... interested to learn more?

 - management of orig.tar.gz

do you mean filtering?  git-import-orig does that if you specify
'filter' option in your debian/gbp.conf for the package

 I already read some maling-list archives, mostly the Patch mgmt
 workflow proposal plus the links givent in the thread, but the
 conversations are way to high for me.

thanks for the links -- I am yet to read them ;) decided to reply first
;-)

-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: My use case of git-buildpackage

[Daniel Dehennin]

Hello,

As I'm really interested in automatic building, here[1] is an updated
section of my previous document.

If any one has feedback on it, specially on the way to manage a Debian
repository.

Regards.

Footnotes: 
[1]  git clone git://git.baby-gnu.net/packaging-with-dvcs.git

-- 
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1


pgpyYP7QVUEyl.pgp
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

My use case of git-buildpackage

[Daniel Dehennin]

Hello,

First, I'm not a Debian maintainer, I mostly do some package for my
personal use, to follow SVN trunk or git HEAD of some softwares.

As I use Debian, I do not want to make install things ;-).

I attach[1] a rough document about my actual uses of git for debian
packaging and post it here for comments.

There are some items about which I would like to discuss, like:

- automatic handling of debia/changelog

- multi-distributions/version packaging (and avoiding conflicts)

- automatic build of packages

- management of orig.tar.gz

I already read some maling-list archives, mostly the Patch mgmt
workflow proposal plus the links givent in the thread, but the
conversations are way to high for me.

I read the Debian wiki[2] plus its links, I like Russ Allbery page[3],
it's a real life example[4].

Regards.

Footnotes: 
[1]  I need to setup some web access to my git repositories ;-)

[2]  http://wiki.debian.org/PackagingWithGit/

[3]  http://www.eyrie.org/~eagle/notes/debian/git.html

[4] Thanks for the trick to split a upstream/debian combined source
http://www.eyrie.org/~eagle/notes/debian/git.html#combine

-- 
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1

#+TITLE: Manage Debian packaging with git
#+AUTHOR: Daniel Dehennin
#+LANGUAGE: en_GB

* Introduction

This documentation is based on my personal packaging of the
enlightenment display manager: elsa.

It's code can be found in the enlightenment [[http://svn.enlightenment.org/svn/e/trunk/PROTO/elsa][SVN repository]].


* git-buildpackage workflow

My current usage is [[https://honk.sigxcpu.org/piki/projects/git-buildpackage/][git-buildpackage]] oriented:

- One branch is upstream
- One branch is patches to upstream sources
- One branch is packaging

Upstream is mostly VCS based, I do not use the [[http://kitenet.net/~joey/code/pristine-tar][pristine-tar]] mechanism.

My first use was to package SVN/git snapshot of some softwares like
cfengine3, gnus and elsa.

For convention I always use a dedicated mirror of upstream branch, in
which I only pull from upstream.

Another convention is to always prepend my trigraph (=dad/=) to my
branches.

The basic setup is the following:

- Upstream branch is under =upstream/= and reflect the VCS used by
  upstream: =upstream/svn/trunk= or =upstream/git/master=
- Packaging: =dad/debian/snapshot=
- Patches to upstream: =patch-queue/dad/debian/snapshot=

** git-buildpackage configuration

I use one global full git-buildpackage configuration, stored
in =~/.gbp.conf= and one minimal configuration per packaging.

The following is my default, I use pbuilder to keep a clean
workstation and track dependency problems.

#+begin_src conf
  # Configuration file for git-buildpackage and friends
  
  [DEFAULT]
  # Where I track upstream
  upstream-branch = upstream
  
  # Branch I use to build package
  debian-branch = debian/snapshot
  
  # the default tag formats used:
  upstream-tag = upstream/%(version)s
  debian-tag = debian/%(version)s
  
  # Use a clean environment to build
  # Need some setup with sudo cowbuilder --create
  builder = /usr/bin/git-pbuilder
  
  # Use color when on a terminal, alternatives: on/true, off/false or auto
  color = auto
  
  [git-buildpackage]
  # Look for a tag matching the upstream version when creating a tarball
  upstream-tree = tag
  
  # Sign tags by default:
  sign-tags = True
  
  # Sign after the build, required because of cowbuilder
  postbuild = debsign ${GBP_CHANGES_FILE}
  
  # Let the working tree clean
  export-dir=../build-area
  
  # Transparently handle submodules
  # submodules = True
  
  [git-dch]
  # Use my git identity
  git-autor = True
  
  # Merge the commits by maintainer
  multimaintmerge = True
  
  # Do not use merge log
  git-log = --no-merges
  
  # Parse meta tags like Closes: from commit messages
  meta = True
  
  # Add seven digits of the commits sha1 to the commit message
  id-length=7
  
  # Regex for matching bugs to close
  meta-closes = Closes|LP|BZ|Fixes|fixes
  
  # Use the full commit message instead of the first line only
  full = True
  
  # Ignore these in commit messages
  ignore-regex = (git-svn-id|(Signed-off|Acked)-by):
#+end_src


** Setup a new package

*** Base is upstream repository

As I do not use pristine-tar, everything is based on the upstream
version control repository.

If upstream do not use git, you must look for a plugin to make the mapping.

Actually I tested following SVN and bzr repository, I may write some
separate documentations about this but for the moment I just show how
to start from SVN and git.

 SVN upstream

#+begin_src sh
  dad@home:~/src/$ git svn clone --prefix=upstream/svn/trunk http://svn.enlightenment.org/svn/e/trunk/PROTO/elsa  cd elsa
  dad@home:~/src/elsa$ git branch upstream/svn/trunk upstream/svn/trunk
#+end_src

 Git upstream

#+begin_src sh
  dad@home:~/src git clone http://git.gnus.org/gnus.git  cd gnus
  dad@home:~/src/gnus$ cd gnus  git branch 

Re: Patch mgmt workflow proposal

[martin f krafft]

also sprach Ben Finney bignose+hates-s...@benfinney.id.au [2011.08.02.0223 
+0200]:
  This comes about ¾ of the way to the history pollution done by TopGit.
 
 I consider it very useful information, when needed. It's only pollution
 if you let it be so.

That is a very wise statement, and I agree.

  Not only would users potentially get confused by this additional
  branch (which is an implementation detail), it would also get in
  the way in gitk output (cf. pristine-tar) and annoy even the
  unconfused.
 
 That's an argument not for hobbling a useful branching-and-merging
 workflow, but for improving the output of those programs. Advocate
 with Git (and other VCSen) to hide merged revisions by default,
 the way Bazaar does.

One person's reasonable default is another person's nightmare.

Fact is that we have new contributors who are being shyed away by
complexity.

Fact is also that you can already hide information explicitly.

I have already dipped my foot in the water on this
[http://bugs.debian.org/636228], but I feel somewhat it's an
uphill battle.

In the end, the best solution is one that doesn't expose
implementation details in the first place. The discussion at

  http://www.spinics.net/lists/git/msg162549.html

is shaping up to be interesting.

-- 
 .''`.   martin f. krafft madduck@d.o  Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
http://lavender.cime.net/~ricky/badgers.txt


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Patch mgmt workflow proposal

[martin f krafft]

also sprach Ben Finney bignose+hates-s...@benfinney.id.au [2011.08.02.0229 
+0200]:
1. you develop your features on branches, but you do not push the
   branch heads;
 
 Right. The feature branches stay only with the people who are
 interested; usually the people actually working on each one.

You do need to ensure that everyone has the objects they reference,
as these objects are used to generate the patches.

4. at a later stage, when someone wants to edit a patch, they can
   create a branch off the SHA-1, merge the branch into the build
   branch and provide the updated patch (with updated SHA-1), or
   just provide an updated patch file and let the maintainer
   update the branch with an interdiff.
 
 With Bazaar, the branches have their own distinct existence, and can be
 re-created at will by anyone who has the identifier. Is that the same
 for Git?

Yes. Git's branches are just human-readable aliases for SHA-1's,
with the added functionality that a commit advances them to the
child.

  I see an advantage in this approach because it focuses on
  debian/patches/* rather than using a potentially-confusing set of
  branch heads.
 
  However, it employs a possibly brittle way to keep track of branch
  heads (SHA-1's in text files).
 
 I don't see that brittleness; maybe that's because of the way Bazaar
 keeps track of merges explicitly.

I don't think it has anything to do with merges. The brittleness
comes from the fact that we are storing a text-representation of an
implementation detail in a content blob in the repository. This
is redundant information in a place that users might well touch with
their text editors, and this means that the redundant information
could go out-of-sync.

  The thing I do not like about it is that the build branch has all
  features merged (hence applied to the worktree), *in addition* to
  tracking the generated patch files in debian/patches/* in the
  repository.
 
 That's a big plus, in my view; but then again Bazaar has the sensible
 default of hiding merged revision data until it's requested by the user.

Why is it a plus? If you already applied all changes, why bother
exporting the patches?

Thanks for your time,

-- 
 .''`.   martin f. krafft madduck@d.o  Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
if ever somethin' don't feel right to you, remember what pancho said
 to the cisco kid...  `let's win, before we are dancing at the end of
 a rope, without music.'
 -- sailor


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Patch mgmt workflow proposal

[Thomas Koch]

Thomas Koch:
 I had some time on my way back to think about patch bases. Is it right,
 that it isn't actually necessary to save the commit sha-1s of patch bases?
 It is my understanding that you could calculate them:
 
   1. $CANDIDATE=$(git merge-base --octopus $DEPENDENCY_NAMES)
   2. for each $PATCH_BRANCH_HEAD
if NOT $PATCH_BRANCH_HEAD in_history_of $CANDIDATE
  echo WARNING! $PATCH_BRANCH_HEAD has unmerged commits!
 
 I'll leave on a two weeks bycycle tour on wednesday and have a lot of time
 to think how the above could go wrong.
Sorry,

the above algorithm is completly wrong, written in a hurry. The idea however 
was to merge all dependencies in a commit and to merge this commit in the 
patch branch.
The one can search for the oldest commit in the patch branch's history 
containing all dependencies.

Regards,

Thomas Koch, http://www.koch.ro

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Patch mgmt workflow proposal

[martin f krafft]

also sprach Thomas Koch tho...@koch.ro [2011.08.02.1732 +0200]:
 the above algorithm is completly wrong, written in a hurry. The idea however 
 was to merge all dependencies in a commit and to merge this commit in the 
 patch branch.

This is exactly what TopGit does: a top-base is the merge of
a branch's dependencies.

-- 
 .''`.   martin f. krafft madduck@d.o  Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
if a man treats life artistically, his brain is his heart.
-- oscar wilde


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Patch mgmt workflow proposal

[martin f krafft]

also sprach Thomas Koch tho...@koch.ro [2011.07.30.1229 +0200]:
 Martin F. Krafft (madduck) was so kind to remind me posting this here. We're 
 right now at debconf discussing different patch mgmt workflows. Thanks to 
 contributions from Joachim Breitner and Guido Günther I've written down an 
 appealing (IMHO) patch mgmt workflow:
 
 http://wiki.debian.org/ThomasKoch/GitPackagingWorkflow

Here's a summary of what Thomas told me about this:

  1. you develop your features on branches, but you do not push the
 branch heads;

  2. the feature branches get merged into an integration/build
 branch, which is pushed. This way, all contributors get the
 commits;

  3. as part of the build process, the feature branches are exported
 to a debian/patches series, and each patch file includes
 additional information, such as dependency data, and also the
 SHA-1 of the feature branch head at the time when the patch
 was made;

  4. at a later stage, when someone wants to edit a patch, they can
 create a branch off the SHA-1, merge the branch into the build
 branch and provide the updated patch (with updated SHA-1), or
 just provide an updated patch file and let the maintainer
 update the branch with an interdiff.

I see an advantage in this approach because it focuses on
debian/patches/* rather than using a potentially-confusing set of
branch heads.

However, it employs a possibly brittle way to keep track of branch
heads (SHA-1's in text files).

The thing I do not like about it is that the build branch has all
features merged (hence applied to the worktree), *in addition* to
tracking the generated patch files in debian/patches/* in the
repository.

Finally, I would like to highlight that this is very much like the
TopGit workflow used in mdadm, with the exception that features are
not merged into the build branch, but instead the branch heads are
kept around. It is my hope that I can simplify TopGit a bit to make
this an equally viable approach, which would be more natural and
closer to normal Git usage, at least to me.

Cheers,

-- 
 .''`.   martin f. krafft madduck@d.o  Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
may the bluebird of happiness twiddle your bits.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Patch mgmt workflow proposal

[Thomas Koch]

CC: debian-devel. Please subscribe to vcs-pkg-discuss@lists.alioth.debian.org 
to follow this topic!

martin f krafft:
 also sprach Thomas Koch tho...@koch.ro [2011.07.30.1229 +0200]:
  Martin F. Krafft (madduck) was so kind to remind me posting this here.
  We're right now at debconf discussing different patch mgmt workflows.
  Thanks to contributions from Joachim Breitner and Guido Günther I've
  written down an appealing (IMHO) patch mgmt workflow:
  
  http://wiki.debian.org/ThomasKoch/GitPackagingWorkflow
 
 Here's a summary of what Thomas told me about this:
 
   1. you develop your features on branches, but you do not push the
  branch heads;
 
   2. the feature branches get merged into an integration/build
  branch, which is pushed. This way, all contributors get the
  commits;
 
   3. as part of the build process, the feature branches are exported
  to a debian/patches series, and each patch file includes
  additional information, such as dependency data, and also the
  SHA-1 of the feature branch head at the time when the patch
  was made;
 
   4. at a later stage, when someone wants to edit a patch, they can
  create a branch off the SHA-1, merge the branch into the build
  branch and provide the updated patch (with updated SHA-1), or
  just provide an updated patch file and let the maintainer
  update the branch with an interdiff.
 
 I see an advantage in this approach because it focuses on
 debian/patches/* rather than using a potentially-confusing set of
 branch heads.
 
 However, it employs a possibly brittle way to keep track of branch
 heads (SHA-1's in text files).
 
 The thing I do not like about it is that the build branch has all
 features merged (hence applied to the worktree), *in addition* to
 tracking the generated patch files in debian/patches/* in the
 repository.
 
 Finally, I would like to highlight that this is very much like the
 TopGit workflow used in mdadm, with the exception that features are
 not merged into the build branch, but instead the branch heads are
 kept around. It is my hope that I can simplify TopGit a bit to make
 this an equally viable approach, which would be more natural and
 closer to normal Git usage, at least to me.
 
 Cheers,
Hallo Martin,

seems you've also arrived well at home? Thank you for your additional 
explanations, I'll work them in my wiki page. I hope I can also address your 
concerns.

It was my initial thought to work on build branches and merge the patch 
branches in, since this would reflect my latest personal workflow. This is 
however totally optional. The only thing needed is to get a hold on the 
commits to save them from garbage collection and a possibility to push them.

So as a variation of the described workflow you can establish a special branch 
that holds references to all feature branch commits in its history. The 
content of this branch does not matter. A status command should warn you if 
the head of any feature branch is not in the history this special branch. 
Another command could create a new commit in this special branch with the 
parent pointing to all new heads.

The concern about brittleness depends a bit on personal judgement. The 
greatest risk I see is that commit objects could be lost. The tools for this 
workflow should detect dangling commits in patch branches and print big 
warnings.

The canonical information is stored in debian/patches/*. Inconsistencies 
between the patch branches and debian/patches/* can also be detected 
automatically.

I had some time on my way back to think about patch bases. Is it right, that 
it isn't actually necessary to save the commit sha-1s of patch bases? It is my 
understanding that you could calculate them:

  1. $CANDIDATE=$(git merge-base --octopus $DEPENDENCY_NAMES)
  2. for each $PATCH_BRANCH_HEAD
   if NOT $PATCH_BRANCH_HEAD in_history_of $CANDIDATE 
 echo WARNING! $PATCH_BRANCH_HEAD has unmerged commits!

I'll leave on a two weeks bycycle tour on wednesday and have a lot of time to 
think how the above could go wrong.

Best regards,

Thomas Koch, http://www.koch.ro

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Branch dependencies with Git hooks

[martin f krafft]

Dear list,

I had this idea today while sitting with Guido and studying TopGit.
I have no investigated any of this, but since DebConf is coming to
an end and I won't have much time in the weeks to come, I wanted to
make sure to capture the idea.

TopGit manages dependencies between branches. If B is a branch off
A, and A is a branch off upstream, then TopGit helps you update all
branches in the right order if upstream releases a new version.

Let's say we have a way to store branch dependencies (quite possibly
that information is right there in the DAG). Couldn't we conceive of
a hook of some sort that made sure that updates to dependent
branches result in (controlled) merges/updates of the depending
branches?

Obviously, we do not want to kick off a massive merging massacre
for every new upstream commit, but we may well want to do this for
the packaging branch. And we certainly want to update all feature
branches when we merge a new upstream tag (or something like that).

The hook would therefore trigger under a certain condition (e.g.
a tag, or a special commit message) and recursively update all
depending branches.

I hope I managed to capture the idea enough for us to have
a discussion about this.

Cheers,

-- 
 .''`.   martin f. krafft madduck@d.o  Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
if you are going to run a rinky-dink distro made by a couple of
 volunteers, why not run a rinky-dink distro made by a lot of
 volunteers?
-- jaldhar h. vyas


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

[FW: [ANNOUNCE] Project pb version 0.11.3 is now available]]

[Bruno Cornec]

Hello,

I'd encourage people interested in following the project to subscribe to
the announce ML at least in order to receive more regular info.
http://mondorescue.org/sympa/wwsympa-wrapper.fcgi/subscribe/pb-announce

Full Announce is at: http://www.project-builder.org/news.shtml

Best regards,
Bruno.

- Forwarded message from Bruno Cornec br...@project-builder.org -

From: Bruno Cornec br...@project-builder.org
Date: Fri, 27 May 2011 12:11:27 +0200
Subject: [ANNOUNCE] Project pb version 0.11.3 is now available
To: pb-annou...@project-builder.org, pb-de...@project-builder.org

Project pb version 0.11.3 is now available

The project team is happy to announce the availability of a newest version of
pb 0.11.3. Enjoy it as usual!

Now available at ftp://ftp.project-builder.org And commented at
http://brunocornec.wordpress.com/2011/05/27/project-builder-org-0-11-3-is-published/

Most notably, this version adds signature support and various smaller fixes.

[...]
- End forwarded message -

-- 
Open Source  Linux Profession Lead EMEA   / http://opensource.hp.com
HP/Intel/Red Hat Open Source Solutions Initiative  / http://www.hpintelco.net
http://www.HyPer-Linux.org  http://mondorescue.org http://project-builder.org
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

- End forwarded message -

-- 
Open Source  Linux Profession Lead EMEA   / http://opensource.hp.com
HP/Intel/Red Hat Open Source Solutions Initiative  / http://www.hpintelco.net
http://www.HyPer-Linux.org  http://mondorescue.org http://project-builder.org
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Shared pidgin releases and vcs-pkg

[Felipe Contreras]

On Mon, May 25, 2009 at 12:35 AM, Richard Laager rlaa...@wiktel.com wrote:
 On Sun, 2009-05-24 at 14:13 +0300, Felipe Contreras wrote:
 Optionally, each package maintainer can push their patches to
 this repository so that other people can easily fetch them, and
 perhaps even share patches between distributions!

 This is an interesting idea. There was talk at UDSJaunty of Ubuntu
 wanting to do this distro-wide. Of course, they'd want to use BZR.

 Some downsides and points for discussion:

 1) Competing DVCSes. Unless everyone is using the same one or you have
 really good tools that can keep multiple different repositories in sync,
 a lot of the benefits are lost.

From what I have seem git is the most widely used:
http://git.debian.org/
http://git.fedoraproject.org/
http://git.opensuse.org/

So it makes sense to use it. Also, git-bzr and git-hg tools work pretty well.

 2) In Ubuntu's case, it's more useful if Debian is doing it first. Given
 that's not likely to happen for every project, they were talking about
 needing support in BZR for splicing stuff into the previous history as
 upstream and/or Debian get on board. If this happens, issue #1 makes it
 even worse. No DVCS deals with this case right now. Splicing in stuff
 would generally change all the revision IDs.

I'm not sure what you mean by splicing, but it sounds like git graft points:
http://git-scm.org/gitwiki/GraftPoint

 3) You already pointed this one out:
 Also, I guess some maintainers might want the tarball contents as
 opposed to the versioned files, that could also be versioned in the
 same repo.

 The right way here, I think, is to have your releases branch come off of
 trunk. Assuming you started at 2.5.5, as an example: The 2.5.5
 tag/revision on the releases branch would be a child of the 2.5.5 tag on
 trunk, minus files we don't distribute, plus the generated files. Then
 2.5.6 would be a merge between 2.5.5 on the releases branch and 2.5.6 on
 trunk. As far as the contents go, it would be equal to 2.5.6 on trunk,
 minus files we don't distribute, plus the generated files for 2.5.6.

Yeah, if you need releases that's the way to go I think. A piece of
cake to do in git.

 4) Is this really useful? Why aren't tarballs enough? I think defining
 some concrete use cases would be the best way to start designing such a
 setup.

How about these:
 * Upstream makes a new release and the patches need to be rebased on top of it
 * Upstream makes a new release and some commits need to be backported
to a maintainance branch
 * A vulnerability is found and another distro already made a release
with a patch, you want it too

Another advantage is that similar distros (ubuntu-debian,
fedora-opensuse) can share most of the packaging stuff (.spec,
debian/*).

 5) Do we really want to encourage direct sharing of patches between
 distros? Wouldn't we want to get them upstream ASAP if they're useful
 and cut a new release?

Yes, that would be ideal, but in my experience upstream does not make that easy.

-- 
Felipe Contreras

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Shared pidgin releases and vcs-pkg

[Olivier Crête]

On Mon, 2009-05-25 at 01:14 +0300, Felipe Contreras wrote:
 On Mon, May 25, 2009 at 12:35 AM, Richard Laager rlaa...@wiktel.com wrote:
  5) Do we really want to encourage direct sharing of patches between
  distros? Wouldn't we want to get them upstream ASAP if they're useful
  and cut a new release?
 
 Yes, that would be ideal, but in my experience upstream does not make that 
 easy.

From my Gentoo point of view, I prefer not to ship any patches that are
not already upstream. So having some kind of Git tree isn't so useful.

-- 
Olivier Crête
tes...@gentoo.org
Gentoo Developer


signature.asc
Description: This is a digitally signed message part
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Shared pidgin releases and vcs-pkg

[Warren Togami]

On 05/24/2009 06:14 PM, Felipe Contreras wrote:


Another advantage is that similar distros (ubuntu-debian,
fedora-opensuse) can share most of the packaging stuff (.spec,
debian/*).



Fedora and Opensuse's specs are very different, so this is not an advantage.

Warren Togami
wtog...@redhat.com

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Re: Shared pidgin releases and vcs-pkg

[Vincent Untz]

Le dimanche 24 mai 2009, à 18:27 -0400, Olivier Crête a écrit :
 On Mon, 2009-05-25 at 01:14 +0300, Felipe Contreras wrote:
  On Mon, May 25, 2009 at 12:35 AM, Richard Laager rlaa...@wiktel.com wrote:
   5) Do we really want to encourage direct sharing of patches between
   distros? Wouldn't we want to get them upstream ASAP if they're useful
   and cut a new release?
  
  Yes, that would be ideal, but in my experience upstream does not make that 
  easy.
 
 From my Gentoo point of view, I prefer not to ship any patches that are
 not already upstream. So having some kind of Git tree isn't so useful.

It's more or less the same for openSUSE -- we prefer to avoid adding
patches, unless really needed. That being said, having everything in
git can't hurt, and it might help for patches that we might need to keep
around, indeed.

In the case of pidgin, we have some patches since before I started
contributing to openSUSE, and I have absolutely no idea what to do with
them... If people are interested in reviewing them/pushing them
upstream, help is welcome. You can easily download them from
http://tmp.vuntz.net/opensuse-packages/browse.py?project=GNOME:Factorypackage=pidgin

Cheers,

Vincent

-- 
Les gens heureux ne sont pas pressés.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss

Fwd: [pb-announce] Project pb version 0.11.1 is now available

[Bruno Cornec]

Hello,

FTI, project-builder.org is tool to support the Continuous Packaging
approach that we are working on jointly beyween HP and Intel.

Best regards,
Bruno.

- Forwarded message from Bruno Cornec br...@project-builder.org -

From: Bruno Cornec br...@project-builder.org
Date: Wed, 9 Mar 2011 07:18:36 +0100
Subject: [pb-announce] [ANNOUNCE] Project pb version 0.11.1 is now available
To: pb-annou...@project-builder.org, pb-de...@project-builder.org

Project pb version 0.11.1 is now available

The project team is happy to announce the availability of a newest version of
pb 0.11.1. Enjoy it as usual!

Major changes in this version which again requires an update of VM/VE/RM
embedded pb to work correctly (use setupvm|ve|rm for that), including:

  • Add support of Remote Machines: pb can now be used in a build farm context
very easily
  • Bug fixes: #83, #86, #87, parallelism build issues, additional sources and
patch support, ebuild generation
  • Improved security with sudo restrictions
  • Improved internal structure management with introduction of $pbos (Thanks
to Fosdem conf !)

Now available at ftp://ftp.project-builder.org

./gentoo/nover/ProjectBuilder-0.11.1-r1.ebuild 
./gentoo/nover/rpmbootstrap-0.11.1-r1.ebuild
./gentoo/nover/project-builder-0.11.1-r1.ebuild./mageia/1/i386/
   
project-builder-0.11.1-1.mga1.noarch.rpm
./mageia/1/i386/   ./fedora/9/i386/
rpmbootstrap-0.11.1-1.mga1.noarch.rpm  
project-builder-0.11.1-1.fc9.noarch.rpm
./fedora/9/i386/   ./fedora/9/x86_64/
rpmbootstrap-0.11.1-1.fc9.noarch.rpm   
project-builder-0.11.1-1.fc9.noarch.rpm
./fedora/9/x86_64/ ./fedora/8/i386/
rpmbootstrap-0.11.1-1.fc9.noarch.rpm   
rpmbootstrap-0.11.1-1.fc8.noarch.rpm
./fedora/8/i386/   ./fedora/8/x86_64/
project-builder-0.11.1-1.fc8.noarch.rpm
rpmbootstrap-0.11.1-1.fc8.noarch.rpm
./fedora/8/x86_64/ ./fedora/6/x86_64/
project-builder-0.11.1-1.fc8.noarch.rpm
rpmbootstrap-0.11.1-1.fc6.noarch.rpm
./fedora/6/x86_64/ ./fedora/11/i386/
project-builder-0.11.1-1.fc6.noarch.rpm
rpmbootstrap-0.11.1-1.fc11.noarch.rpm
./fedora/11/i386/  ./fedora/11/x86_64/
project-builder-0.11.1-1.fc11.noarch.rpm   
rpmbootstrap-0.11.1-1.fc11.noarch.rpm
./fedora/11/x86_64/./fedora/14/i386/
project-builder-0.11.1-1.fc11.noarch.rpm   
rpmbootstrap-0.11.1-1.fc14.noarch.rpm
./fedora/14/i386/  ./fedora/14/x86_64/
project-builder-0.11.1-1.fc14.noarch.rpm   
rpmbootstrap-0.11.1-1.fc14.noarch.rpm
./fedora/14/x86_64/./fedora/10/i386/
project-builder-0.11.1-1.fc14.noarch.rpm   
project-builder-0.11.1-1.fc10.noarch.rpm
./fedora/10/i386/  ./fedora/10/x86_64/
rpmbootstrap-0.11.1-1.fc10.noarch.rpm  
project-builder-0.11.1-1.fc10.noarch.rpm
./fedora/10/x86_64/./fedora/13/i386/
rpmbootstrap-0.11.1-1.fc10.noarch.rpm  
rpmbootstrap-0.11.1-1.fc13.noarch.rpm
./fedora/13/i386/  ./fedora/13/x86_64/
project-builder-0.11.1-1.fc13.noarch.rpm   
rpmbootstrap-0.11.1-1.fc13.noarch.rpm
./fedora/13/x86_64/./fedora/12/i386/
project-builder-0.11.1-1.fc13.noarch.rpm   
project-builder-0.11.1-1.fc12.noarch.rpm
./fedora/12/i386/  ./fedora/12/x86_64/
rpmbootstrap-0.11.1-1.fc12.noarch.rpm  
project-builder-0.11.1-1.fc12.noarch.rpm
./fedora/12/x86_64/./fedora/7/i386/
rpmbootstrap-0.11.1-1.fc12.noarch.rpm  
project-builder-0.11.1-1.fc7.noarch.rpm
./fedora/7/i386/   ./fedora/7/x86_64/
rpmbootstrap-0.11.1-1.fc7.noarch.rpm   
project-builder-0.11.1-1.fc7.noarch.rpm
./fedora/7/x86_64/ ./asianux/2/x86_64/
rpmbootstrap-0.11.1-1.fc7.noarch.rpm   
project-builder-0.11.1-1.asx2.noarch.rpm
./asianux/2/x86_64/./mandrake/10.2/i386/
rpmbootstrap-0.11.1-1.asx2.noarch.rpm  
rpmbootstrap-0.11.1-1.mdk10.2.noarch.rpm
./mandrake/10.2/i386/  ./mandrake/10.1/i386/
project-builder-0.11.1-1.mdk10.2.noarch.rpm
project-builder-0.11.1-1.mdk10.1.noarch.rpm
./mandrake/10.1/i386/  ./sles/9/i386/
rpmbootstrap-0.11.1-1.mdk10.1.noarch.rpm   
project-builder-0.11.1-1.sles9.noarch.rpm
./sles/9/i386/ ./sles/11/i386/
rpmbootstrap-0.11.1-1.sles9.noarch.rpm 
rpmbootstrap-0.11.1-1.sles11.noarch.rpm
./sles/11/i386/   

[no subject]

[L'ALTRA DIMENSIONE]

Richiesta di autorizzazione all'invio dell'email
 
 
L'Altra Dimensione  esegue  lavori di Ristrutturazione, imbiancature, 
controsoffittature,
decorazione, coibentazioni termoacustici, trattamenti antimuffa, rifacimento 
tetti, canne fumarie ecc...
Fornitura e posa di parquet, porte, finestre, zanzariere, sanitari, 
rubinetteria, piastrelle ...
www.laltradimensione.it
 
Informativa sulla Privacy: Non abbiamo alcun  Vs. dato personale, è stato 
raccolto da elenchi pubblici disponibili sia in forma cartacea che on-line 
(Pagine Gialle, Pagine bianche, motori di ricerca) e sono trattati secondo le 
disposizioni del D.Lgs 196/03.
Qualora non desideriate ricevere in futuro comunicazioni commerciali dalla 
ditta scrivente potete opporVi ed esercitare i diritti previsti dall'art. 7 del 
codice della privacy inviando un messaggio di posta elettronica cliccando NON 
AUTORIZZO e indicando i dati da cancellare. Un messaggio Vi confermerà 
l'accoglimento della Vs. istanza e la conseguente cancellazione della vostra 
posta elettronica. 
 
NON AUTORIZZO

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

git-flow

[martin f krafft]

Dear folks,

in case you missed this, it's worth a look (although I have not yet
checked out the actual tool):

  http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

-- 
 .''`.   martin f. krafft madduck@d.o  Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
he gave me his card
 he said, 'call me if they die'
 i shook his hand and said goodbye
 ran out to the street
 when a bowling ball came down the road
 and knocked me off my feet
-- bob dylan


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Fwd: [ANNOUNCE] Project pb version 0.10.1 is now available]

[Bruno Cornec]

- Forwarded message from Bruno Cornec br...@project-builder.org -

Project pb version 0.10.1 is now available

The project team is happy to announce the availability of a newest version of
pb 0.10.1. Enjoy it as usual!

A lot has been done in that version, so look at the ChangeLogs file below for
details. In particular, that version of pb is not backward compatible with the
previous one, thus the change of version. Which also means that it is highly
recommended to update your VMs/VEs with that new version of pb with the setupvm
|ve command. Another incompatibility is with the cms2* commands which new
really take the content of the CMS/VCS not the sandbox status. In order to get
the previous behaviour, please use the sbx2* commands instead. man pb is
probably helpful ;-)

This version now supports parallelism during the sbx|cms2build, sbx|cms|
build2vm|ve phases which can drastically reduce build time for packages. For
this to work, you need the perl module Parallel::ForkManager installed on your
system. The VMs|VEs may benefit from it but it is not required.

Now available at ftp://ftp.project-builder.org

./debian/4.0/i386/project-builder_0.10.1-1_all.deb  
./debian/4.0/i386/rpmbootstrap_0.10.1-1_all.deb
./debian/4.0/x86_64/./debian/4.0/x86_64/
project-builder_0.10.1-1_all.deb
rpmbootstrap_0.10.1-1_all.deb
./debian/5.0/i386/project-builder_0.10.1-1_all.deb  
./debian/5.0/i386/rpmbootstrap_0.10.1-1_all.deb
./debian/5.0/x86_64/./debian/5.0/x86_64/
project-builder_0.10.1-1_all.deb
rpmbootstrap_0.10.1-1_all.deb
./fedora/6/x86_64/  ./fedora/6/x86_64/
project-builder-0.10.1-1.fc6.noarch.rpm 
rpmbootstrap-0.10.1-1.fc6.noarch.rpm
./fedora/7/i386/./fedora/7/i386/
project-builder-0.10.1-1.fc7.noarch.rpm 
rpmbootstrap-0.10.1-1.fc7.noarch.rpm
./fedora/7/x86_64/  ./fedora/7/x86_64/
project-builder-0.10.1-1.fc7.noarch.rpm 
rpmbootstrap-0.10.1-1.fc7.noarch.rpm
./fedora/8/i386/./fedora/8/i386/
project-builder-0.10.1-1.fc8.noarch.rpm 
rpmbootstrap-0.10.1-1.fc8.noarch.rpm
./fedora/8/x86_64/  ./fedora/8/x86_64/
project-builder-0.10.1-1.fc8.noarch.rpm 
rpmbootstrap-0.10.1-1.fc8.noarch.rpm
./fedora/9/i386/./fedora/9/i386/
project-builder-0.10.1-1.fc9.noarch.rpm 
rpmbootstrap-0.10.1-1.fc9.noarch.rpm
./fedora/9/x86_64/  ./fedora/9/x86_64/
project-builder-0.10.1-1.fc9.noarch.rpm 
rpmbootstrap-0.10.1-1.fc9.noarch.rpm
./fedora/10/i386/   ./fedora/10/i386/
project-builder-0.10.1-1.fc10.noarch.rpm
rpmbootstrap-0.10.1-1.fc10.noarch.rpm
./fedora/10/x86_64/ ./fedora/10/x86_64/
project-builder-0.10.1-1.fc10.noarch.rpm
rpmbootstrap-0.10.1-1.fc10.noarch.rpm
./fedora/11/i386/   ./fedora/11/i386/
project-builder-0.10.1-1.fc11.noarch.rpm
rpmbootstrap-0.10.1-1.fc11.noarch.rpm
./fedora/11/x86_64/ ./fedora/11/x86_64/
project-builder-0.10.1-1.fc11.noarch.rpm
rpmbootstrap-0.10.1-1.fc11.noarch.rpm
./fedora/12/i386/   ./fedora/12/i386/
project-builder-0.10.1-1.fc12.noarch.rpm
rpmbootstrap-0.10.1-1.fc12.noarch.rpm
./fedora/12/x86_64/ ./fedora/12/x86_64/
project-builder-0.10.1-1.fc12.noarch.rpm
rpmbootstrap-0.10.1-1.fc12.noarch.rpm
./fedora/13/x86_64/ ./fedora/13/x86_64/
project-builder-0.10.1-1.fc13.noarch.rpm
rpmbootstrap-0.10.1-1.fc13.noarch.rpm
./fedora/13/i386/   ./fedora/13/i386/
project-builder-0.10.1-1.fc13.noarch.rpm
rpmbootstrap-0.10.1-1.fc13.noarch.rpm
./fedora/14/x86_64/ ./fedora/14/x86_64/
project-builder-0.10.1-1.fc14.noarch.rpm
rpmbootstrap-0.10.1-1.fc14.noarch.rpm
./fedora/14/i386/   ./fedora/14/i386/
project-builder-0.10.1-1.fc14.noarch.rpm
rpmbootstrap-0.10.1-1.fc14.noarch.rpm
./gentoo/nover/i386/./gentoo/nover/i386/
project-builder-0.10.1-r1.ebuild
ProjectBuilder-0.10.1-r1.ebuild
./gentoo/nover/i386/rpmbootstrap-0.10.1-r1.ebuild   ./gentoo/nover/x86_64/

project-builder-0.10.1-r1.ebuild
./gentoo/nover/x86_64/  ./gentoo/nover/x86_64/
ProjectBuilder-0.10.1-r1.ebuild 
rpmbootstrap-0.10.1-r1.ebuild
./mandrake/10.2/i386/   ./mandrake/10.2/i386/
project-builder-0.10.1-1.mdk10.2.noarch.rpm 

Blessing 2 1 o217351 nhldwf0 oh3133

[상범 이]

Hey, friend: if you are interested in our product (as Laptop,Television, Phone, 
Camera ,PSP, Car DVD and so on .).  all items  are Original and best price. If 
you have any questions, please feel free to contact us.
   (www:  youtoi . com   E-mail:  youtoi  @ 188 . com) ⊙


yzocpn3257

mkzn375

yj63  ___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

oferta cursuri de perfectionare

[oferta cursuri de perfectionare]

Title: oferta cursuri de perfectionare



EVRIKA GROUP - cursuri de perfectionare :
-contabilitate - costul cursului este de 300 ron, cu incepere dingrupa in formare;
-expert fiscal - costul cursului este de 600 ron, cu incepere din25august2010;
-inspector protectia muncii - nivel baza (studii medii - 40 ore ) - costul cursului este de 250 ron, cu incepere din23 august 2010
-inspector resurse umane - costul cursului este de 250 ron, cu incepere din24 august 2010.




 In urma sustinerii examenului final se obtine un CERTIFICAT DE ABSOLVIRE eliberat de MINISTERUL MUNCII FAMILIEI SI EGALITATII DE SANSE si MINISTERUL EDUCATIEI CERCETARII SI TINERETULUI recunoscut pe piata muncii.
 Daca vreti sa profitati de oportunitatile ce pot aparea apasati SUBSCRIBE, daca nu, apasati UNSUBSCRIBE.

 
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

(Dear God's elect,)

[Mrs.Margaret Brown]

(Dear God's elect,)

 

I am touched by God to hand you over this money considering my last wish, and 
you should also know that my contact to you is by special grace of God, please 
understand that you are not helping me rather you are working for God the 
creator of heaven and earth.

In respect of my previous message; Nevertheless, (30% Percent) of the total 
money 8,500,000.00 USD is for your personal use and 70 Percent to help 
orphanages, Building a Clinic school and widows to endeavor that the house of 
God is maintained, I hope you will utilize this money the way I instructed you 
herein.

 

On the process of receiving your first response, i have now extented the 
communication to the knowledge of my personal lawyer who will take a proper 
charge of the fund remiting procedure to your destination to enable you excute 
my last wished project. The contact of the attoney in charge will be made 
available to you as soon as i am convinced of your honesty in this project for 
the release of the amount. With regard to my ill health and the presence of my 
husband's relatives around me here in the hospital, I do not need any telephone 
communication in this mostly because I seldom them to know about this as they 
are not aware of the deposited money.

 

Moreover, further discusion in this matter will require your official presence 
to change the related documents to your name due to my illness of course will 
not allow me to move out of this hospital bed, meanwhile the bank will also 
request your present to sign the release order document considering the amount 
of money involve (8,500,000.00 USD) On this reason you will make arrangement to 
undertake (Three to Four 3/4) working days in order to meet with my lawyer to 
enable him make sure that you are properly handed over the fund to go on with 
processing of my project.

 

Don't forget to always pray for me because all my hope to survive is in God the 
creator who holds death and life. 

Hoping to receive your reply.

Mrs.Margaret Brown___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

CAN YOU SUPPLY THE PRODUCT TO US.

[David West]

CAN YOU SUPPLY THE PRODUCT TO US.

Dear Sir,
I hope this mail meet you in good health. There is this product I suggest
you may be able to supply to our company.  The name of the product is Diamond 
Misers use in Diamond Companies. I use to supply it to my company directly from 
Dubai UAE. I use to buy it and supplies to my company without my company knowing
actual price of the product. Now I have been transfer from the department that 
make it easier for me .The new person that took over my
position in that department did not know the seller of the Product. I will
introduce you to him as the seller of the product so that they can buy from you 
directly after you might have buy from the original seller.
 
This is my reason of contacting you, if you will be able to be supplying the 
product to my company on regular bases as needed. The supply or transaction has 
to be well handled, since it is going to be a continue transaction between you 
and our company,
it will be of a good benefit to us. This is how you should handle the business. 
Please, don’t allow My Company Director to know the seller and don’t let the 
seller to know My Company Director, because if they know each other, both of us 
will not get anything from the business anymore, both of them will be handling 
the business by themselves, and for me I will have a big problem with my 
company because I don’t want them to know how much I use to buy the product 
from the seller.
 
My Company need about 150 to 200 cartons, it's not under most you supplier the 
quantity my Company need. you can start by 20 or 30 cartons depending on the 
cash you hold at
hand and supply to my Company. My Company will pay you cash on delivery then 
you will go back and buy the remaining from the seller and supply to my 
Company. When you buy in Dubai my office can send one of our company.
You will buy per Carton from the seller at 1carton contains 12bottles one 
bottle's $200 and supply to my  Company  at $400 per bottle, my Company will  
pay you cash, Please let me know if it will be possible for you or your company 
to be supplying this product for my company.
Yours faithfully
Mr. David West.___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss