Re: Dealing with autotools
On Mon, May 11, 2009 at 10:04:13AM +0200, martin f krafft wrote:
also sprach Stefano Zacchiroli z...@debian.org [2009.05.10.1616 +0200]:
I _think_ that Manoj's point was more about the fact that
re-creating the auto* files are not (necessarily) part of the
trust relationship that users put into the pristine-ness of
upstream tarball.
I am not sure I parse you correctly. Are you saying distro packagers
should or should not recreate auto* files?
Sorry for the unclear wording. I'm saying that the trust our users
have in the pristine-ity of upstream sources should not rely on the
fact that we do not change auto* files.
Hence if, for any reason, we find appropriate to recreate auto* files,
we should do that. In particular, if it helps in syncing with upstream
VCSs and get rid of tarballs, let's recreate auto* more often!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Dealing with autotools
On Sun, May 10, 2009 at 09:05:25AM +0200, martin f krafft wrote:
also sprach Manoj Srivastava sriva...@acm.org [2009.05.10.0030 +0200]:
Huh? These do not logically follow. I always autoreconf during
the build process for my Debian packages, and yet, I also ship pristine
sources. I see no contradiction.
The files generated by autotools are not in VCS, so when you build
from VCS, they don't exist and need to be created as part of the
build process. No tarball involved anymore.
I _think_ that Manoj's point was more about the fact that re-creating
the auto* files are not (necessarily) part of the trust relationship
that users put into the pristine-ness of upstream tarball.
I personally agree with that. As such, in a near future I would have
no problem in letting user putting their trust in the checksum of our
upstream branch being in sync with the checksum of upstream tag. The
main drawback of that is requiring homogeneity of VCS technology
between packagers and upstream.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: TopGit: How to retire obsolete topic branches?
On Thu, May 07, 2009 at 10:55:23AM +0200, martin f krafft wrote:
also sprach Frédéric Brière fbri...@fbriere.net [2009.05.07.0232 +0200]:
Yeah, but it'll remain in your refs/heads namespace forever, won't it?
Kinda sucks to have git-branch spew out every patch that's ever existed.
:(
Like git-tag spews out every tag ever created?
The level of annoyance is quite different.
When I, as a newcomer of a given repo, do git tag I know I'm looking
at a lot of not current information. On the contrary, when I do git
branch I start trying figure out what each branch means. Having
around a lot of no longer used branches is very annoying in that
respect.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Debconf
On Mon, Apr 13, 2009 at 10:26:31PM +0100, James Westby wrote:
OK, it's a bit last minute, sorry, but here is a proposal that I
will submit to debconf in 24 hours time, any feedback is welcome.
Thanks!
Event type: Workshop (or should it be BoF? There is no explanation)
I think it should be a BoF, but Martin can probably provide more info
about that.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Debconf
On Wed, Mar 25, 2009 at 02:00:19PM +, James Westby wrote:
On Mon, 2009-03-23 at 18:41 +0100, martin f krafft wrote:
I will probably be there and I am definitely interested in doing
something vcs-pkg. I am a little weary though about doing something
in a Debian/Ubuntu-only context, because this group is already
strongly Debian/Ubuntu-centric [0], so we better be careful not to
drive the others away.
I agree.
It seems to good an opportunity to pass up though.
Agreed, and I'll be there too.
Martin, given that you are also among DebConf organizers, how about
hosting *at* DebCamp a vcs-pkg meeting? We can announce it here and
see whether other people, not necessarily related to Debian, are
willing to attend such an event, which will just happen to be
co-located with DebCamp.
Sure it will be biased, but if we announce it as a more public event,
we have good chances to attract more people than only Debian/Ubuntu
contributors.
Maybe it is too late, but in principle we can also ask the Extremadura
guys to sponsor non-Debian people to attend, as they would have been
willing to do if it were an ordinary Extremadura work meeting.
Would all that make any sense?
... I'm not sure, but it was definitely worth asking :-)
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
migrating from patch series to a dag of patches
I've a simple problem with apparently a not so simple solution.
Before the advent of stuff like topgit, we all used patch stacks in
which you de facto have that the n-th patch (implicitly) depends on
all n-1 patches. When migrating to stuff like topgit you have the
ability to structure the patches in a dag with dependencies only where
they are needed.
Now, how would you migrate from the former setting to the latter?
I'm faced with such problem in basically all my packages that used to
use either dpatch or quilt and which are now willing to use topgit.
Would you just give up and declare the patches as depending on each
other according to the stack discipline? [1] ... or would you rather
figure out a clever way to detect real patch dependencies
automatically?
TIA.
Cheers.
[1] this, I believe, is what topgit's tg-import would do
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: instances of cooperation between distros
On Thu, Dec 18, 2008 at 09:26:17PM +0100, martin f krafft wrote:
Do you know of any instances of cross-distro collaboration where the
VCS is shared between packagers?
Have any of you reached out to other distros' packagers? Would you
share your experiences?
For packaging OCaml stuff, we are sharing patches (though not the VCS
itself) between Debian (us) and Fedora. The main packager, and
coordinator, of the Fedora packaging (a RedHat employee) is subscribed
to our mailing list (debian-ocaml-ma...@lists.debian.org) and
contribute to the discussions there.
Out of memory I do remember that there are cases where the actual VCS
is shared between Debian and Ubuntu, but I forgot the actual examples.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: bzr and Ubuntu: what it means for vcs-pkg (was: Re: Bazaar branches for all Ubuntu source packages available)
On Mon, Dec 01, 2008 at 05:09:58PM +, James Westby wrote: Why you don't think it would be a good idea? I'm not sure whether providing branches for each VCS is a good idea, as I'm not sure it would help collaboration that much. If I grab a bzr branch to work on a feature, and you want to use git to work on that feature too then we have to provide a service to synchronise branches for you, and you would have to wait while my branch was imported to git before you could start work. On that I agree, I was just thinking at your infrastructure as more general than Ubuntu's. Hence, on the assumption that other people might be interested to setting up something similar for their beloved Debian derivative, it just makes sense to have a choice of DVCSes. ACK / thanks for the info on the rest. Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime signature.asc Description: Digital signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Debian packaging with git and conflicts resolution
On Sun, Nov 23, 2008 at 02:25:14PM +0100, martin f krafft wrote: (b) I provide the pristine source and a quilt series in debian/patches, which applies, and thus gives very specific information about how the upstream source gets altered before building the Debian package. The downside of this approach is that upstream (or another distribution) cannot trivially extract patches. This raises the question of who is the target of the patches shipped as part of a source package. I've always implicitly assumed that the targets were our fellow developers, in case they need to make changes to packages which do not belong to them. Nowadays stuff like patch-tracking.debian.net (but I believe other distros have similar services) moves the target toward upstream authors, and maybe even to final users understanding what is different wrt pristine upstream. Now, assuming there is a sane way of storing the information needed to address both targets, what about providing patches for both targets? Series of patches for build purposes (i.e., the actual build process and fellow developers) on one side, and individual / non-series patches for who wants to apply single patches to pristine upstream. However, this can open a can of worms, because it implicitly assumes that single patches are picked from the patch set. If more than one patches are desired, conflicts between them will be need to be solved by the picker. Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime signature.asc Description: Digital signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: commit IDs in changelog messsages (was: Introductory mail)
On Thu, Nov 13, 2008 at 10:11:15AM -0500, James Westby wrote: You mean [fc5473a06be960382582ddbfb40e2a5f824be122] don't you? No, why? Short commit IDs are usually enough in Git. Why not use [f] then? Well, even thought the likelihood of clashes increase trivially with time, we are in the context of changelogs which are made of timestamp-ed entries. Hence it would be relatively simple, the day that a clash does occur, to disambiguate it by choosing the commit which is closest to the timestamp of the changelog entry referencing it. It wouldn't even be necessary to do that always, you can be lazy and do that only upon conflicts. To do that you will need connectivity to the repository, but without that the id is useless any how, and I also observe that most $DVCS help us in this respect, because we know that the full history is always available attached to each commit. Am I overlooking some serious intricacy? Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime signature.asc Description: Digital signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: commit IDs in changelog messsages (was: Introductory mail)
On Thu, Nov 13, 2008 at 10:40:15AM +0100, Guido Günther wrote: I don't have a need for it either - just iff we want to have a qualifier inside the braces we should at least use the type of VCS not only Commit:. OK, but note that there are drawbacks. For example if we go for (Git:af14e5) that would be annoying, as parsing will depend on the number of supported, or known, VCS. That was a wrong design choice of Vcs-* which I don't want to repeat. Hence, if we really want a VCS tag it should be something easily skipped over, e.g.: (Commit:Git:af14e5) where one can skip the tag and look only at the ID if she wants so. Frankly speaking though, this notation already looks too cumbersome to me. Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime signature.asc Description: Digital signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: commit IDs in changelog messsages (was: Introductory mail)
On Thu, Nov 13, 2008 at 11:22:56AM +0100, martin f krafft wrote: But instead of one parser, I'd really rather think of it as a number of parsers, each getting a chance. So Closes would be handled by the dak-bts parser, and Git: by a git parser, SVN: by an SVN parser, etc. Consider the following two snippets of changelog entry metadata (which I think is what we are aiming to generalize): 1) (Closes: #1234567, git: fba134) 2) (Closes: #1234567, Commit: git:fba134) I do agree that no matter what, if you are not git-aware, the git commit numbers is useless for you. That can't be otherwise. Still, even if you are not git-aware, in snippet (2) you can recognize that git:fba134 is a commit identifier. You don't know what to do with that, but at least you know that it is. On the contrary, in snippet (1) you aren't even able to understand that it is a commit identifier. So, for instance, you can't do neutral stuff like passing it to some other applications which comes after you in a processing pipeline which *might* be git-aware themselves. A real-life use case is dpkg-parsechangelog. With snippet (2) it can output a commit identifier and tell to the world that the VCS in use is git, even if dpkg-parsechangelog is not git-aware itself. With snippet (1) the only possibility is to add to dpkg-parsechangelog the list of recognized VCS tags. It is well possible that this fuss is excessive, as it introduces a more cumbersome syntax we do not tolerate for a relative minor gain. Still, the right(tm) design seems to be (2). Maybe it is just not worth. YMMV. Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime signature.asc Description: Digital signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Introductory mail
On Sun, Sep 28, 2008 at 11:58:37AM +0200, Stéphane Glondu wrote: I've read topgit's README.source. I am currently experimenting with it. Shameless OT: Stéphane, I had a look at topgit myself, and I was going to propose on top of it a workflow to be adopted for *all* debian-ocaml-maint packages maintained used git (i.e., all of them in the near future). The reason I haven't yet done that is that I wanted to have first a sort of tutorial/best practice to propose to our fellow debian/ocaml maintainers. If you have time to take notes about an ideal workflow for us it would be great! Thanks :-) -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ I'm still an SGML person,this newfangled /\ All one has to do is hit the XML stuff is so ... simplistic -- Manoj \/ right keys at the right time signature.asc Description: Digital signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: how to generate patches out of $DVCS branches: best practices?
On Tue, Sep 23, 2008 at 08:25:38AM +0200, martin f krafft wrote: also sprach Stefano Zacchiroli [EMAIL PROTECTED] [2008.07.15.2031 +0200]: I'm a happy (Debian) package maintainer which have just switched most of his packages from svn to git. All nice, finally I can work directly on a real source code tree instead of fiddling with patch management system. Nevertheless, patches are separate in topic branches which enable knowing the conceptual changes applied to upstream sources. So that I can remove this thread from my pending list, have you looked at topgit? I know it's still rough, but I think it's what you're looking for. topgit's source package has a README.source, and I've looked at least at what topgit is and I indeed got convinced that it is what I was looking for. Still, I haven't put it into use to be able to comment any further. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ I'm still an SGML person,this newfangled /\ All one has to do is hit the XML stuff is so ... simplistic -- Manoj \/ right keys at the right time signature.asc Description: Digital signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
how to generate patches out of $DVCS branches: best practices?
I'm a happy (Debian) package maintainer which have just switched most of his packages from svn to git. All nice, finally I can work directly on a real source code tree instead of fiddling with patch management system. Nevertheless, patches are separate in topic branches which enable knowing the conceptual changes applied to upstream sources. But. Even though I can declare where my git repository for package management is, there is still people only playing with the (Debian) source package. Unfortunately, there all changes are flattened in .diff.gz, with neither change separation, nor description of which changes have been made. I know I can use git format-patch to serialize patches into patch series and make them available with dpatch/quilt/..., and precisely here is my question. Have I to do that by hand and by myself? Even though I can do it, I'm convinced there is room for creating a best practice on this, if not even some tools. Is anybody aware of anything like that? Specifically for Debian: do we have any guideline on how to do that? If not it is probably worth to create one ... And finally, the problem of the problems: how about the situation where one patch for topic branch is not enough as topic branches have got intertwined? (I guess this can happen fairly easily with changes evolution, unless git rebase is used). A guideline/best practice on that as well would be utterly welcome. TIA, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ I'm still an SGML person,this newfangled /\ All one has to do is hit the XML stuff is so ... simplistic -- Manoj \/ right keys at the right time signature.asc Description: Digital signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: how to generate patches out of $DVCS branches: best practices?
On Tue, Jul 15, 2008 at 01:38:14PM -0500, John Goerzen wrote: I don't split out patches, but all my Debian packages live on git.debian.org (except software where I'm the upstream, in which case it's on my own git server). Using gitweb, people can inspect the changelog and download diffs of individual changesets. You can also craft URLs for people that will do things such as spit out a diff between upstream and debian heads, or between two different Debian releases. Well, it's all fine and I'm already doing all of this, but this doesn't really address my problem. My problem is to cope with people not knowing git at all. I feel they have the right to understand what changes I applied wrt upstream (remember the discussions after the OpenSSL security flaw?). Also, diffs and individual changesets fail to address a problem which is instead addressed by commented patches. That is, they are missing a single description for the whole topic branch. You can address this in git (AFAIK) only by keeping topic branches as single changesets using a describing commit message, but this requires rebasing which is bad in published topic branches. Also, currently in Debian you have tools which help maintainers describing their patches, e.g. lintian complaining about dpatches not commented. You loose this benefit if you go for $DVCS branches alone. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ I'm still an SGML person,this newfangled /\ All one has to do is hit the XML stuff is so ... simplistic -- Manoj \/ right keys at the right time ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: switching versioning from distro only to distro+upstream
Thanks to all who have replied, with the branch with no ancestry trick I've indeed solved the issue. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
