Re: Intent to commit craziness - source package unpacking
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
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: output from the vcs-pkg BoF @DebConf9
Hi Stéphane, On Wed, Aug 05, 2009 at 07:31:13PM +0200, Stéphane Glondu wrote: Guido Günther a écrit : Looks pretty similar to what I do except that you use upstream while I use the debian branch as the base. This is done on purpose ;-) thought so ;) this wasn't ment as criticism, i'm just interested in finding out the reason for the differences to learn from it. Actually, my (and Mehdi's) workflow is largely inspired on yours, the only thing I changed is basing the patch-queue branch on upstream (and not pushing it to the central repository). I find basing the patch-queue branch on the upstream one more convenient because it's much easier to reference the branching point. In this regard, basing patch-queue on master doesn't really make sense to me and/or leads to too much useless rebasing (at least with the way I work). You'll have to rebase against the Debian branch if you did changes on it but that's cheap. Finding the branching point can be done by looking at the ancestors of the merge commit (if one needs to identify it). I do that so I can have different patch-queues for different debian releases like: patch-queue/master patch-queue/lenny patch-queue/bpo-lenny patch-queue/experimental I don't really see the benefit of keeping patch-queue branches around, and I even think they are troublesome. Having each queue serialized in its branch's debian/patches is enough, isn't it? They don't have to be kept around. Whole point is that recreating the patch-queue branch (for e.g. backports or point releases) works out of the box. If I understand things correctly in your workflow you'd have to identify the tag or branch of the old upstream version first and pass that on to dom-apply-patches? (This could as well be automated of course by looking at the right tag). The branch point for the patch-queue branch would then always be the tip of the corresponding debian branch, like: git branch patch-queue/lenny lenny git quilt-import debian/patches/series IMHO, this is really not convenient. What does the not convenient refer to? Cheers, -- Guido ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: output from the vcs-pkg BoF @DebConf9
On Tue, Aug 04, 2009 at 04:37:46PM +, Frédéric Brière wrote: martin f krafft madd...@debconf.org wrote: The workflows I know currently are: my topgit workflow, Mehdi's quilt workflow, and Guido's git-buildpackage approach. There my be others. Aren't Mehdi and Guido basically doing the same thing? From what I understand, the only difference is that Guido uses git-rebase, while Mehdi manually applies the old patches to a new branch (which is exactly what git-rebase does). I think they're pretty similar. I'm just not sure how Mehdi reimports the patch series onto the patch-queue branch. I'm doing this as described here: https://honk.sigxcpu.org/piki/development/debian_packages_in_git/ Cheers, -- Guido ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Using quilt to store patches
Hi Martin, On Mon, May 25, 2009 at 10:52:42AM +0200, martin f krafft wrote: 1. due to the rebasing, it's not possible to work with other people, unless everyone maintains their own patch queue. Not true. You just have to agree beforehand what branches do keep the patch queues (therefore the patch-queue namespace) and you have to fetch them with a refspec that starts with a plus sign (see git-fetch (1) and look for refspec). 2. each patch on the patch queue branch is presumably the result of a squash-commit or the like. The feature has likely been developed on a branch of its own, squashed into a single commit, and then removed. If the patch needs modification later on, you have to recreate a branch and work off the single squash-commit. While this prevents you from looking at history, the bigger problem is that it's repetitive manual work: create branch, cherry-pick patch, work, squash-commit delete branch. It gets worse if you do publish the feature branch, because then you need to keep it up to date with other branches by merging before you can work on it and squash-commit. In practice I found this to be quiet seldom the case and you can always keep the feature branch around (I usually don't but rather try to get the code merged upstream). I don't mean to say that TopGit isn't a nicer way to do this. I just never got around to wrap my head around it. Cheers, -- Guido ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Using quilt to store patches
On Sun, May 24, 2009 at 03:57:04PM +0200, Stefano Zacchiroli wrote: On Sat, May 23, 2009 at 12:55:57AM +0200, martin f krafft wrote: Now: - all patches are saved in debian/patches/ and can be used directly with quilt. Yes, and you can use TopGit to actually develop features on all those TopGit branches, from which you can create that initial patch series. Now we need to figure out how to get the conflict resolutions you made during your git-am loop back onto the TopGit branches where their features are developed. This is the advantage of TopGit: it's centred around the idea of keeping changes to a feature very close to the feature's branch. I think the approach hinted by Mehdi is quite interesting and that it deserves a bit more of investigation. In particular, what do you think you will loose practically using that instead of full-fledged TopGit? That is not that clear to me. Better, I know what information will not be stored not using TopGit (e.g. the merging history), but practically I don't see any disadvantage descending from that. On the contrary, what you gain is quite clear: you don't fiddle with the complexity of TopGit and you don't have forever lasting branches. Also, your patch history is trivially versioned as the content of debian/patches/ in master. FWIW I'm using a similar scheme except that I don't recreate the patch-queue branch from quilt but simply rebase it frequently on top of the tracked debian branch (i.e. master). I'm keeping different patch-queue branches for each release like: patch-queue/master patch-queue/bpo-lenny patch-queue/experimental The script[1] then figures out which branch I'm on and recreates the patch-queue for that branch. This assumes you have all of the patches condensed on a single branch. In case of team maintenance either push the patch-queue branch too or recreate it from quilt as already described. Cheers, -- Guido [1] http://honk.sigxcpu.org/projects/git-buildpackage/redo-patches ___ 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 Fri, Nov 14, 2008 at 07:42:02AM +0100, martin f krafft wrote: also sprach Martin Bähr [EMAIL PROTECTED] [2008.11.13.1540 +0100]: On Thu, Nov 13, 2008 at 01:42:44PM +0100, martin f krafft wrote: Except, of course, there is no such thing as an SVN-Commit. r123 is a state, a snapshot, the commit if the diff against r-1. I think hg is like Git well, in git the commit-ids also represent the state of the whole tree like in svn. Yes, but we are talking about commits, about changes which resolve a given bug. It's only SVN's limitation that you cannot do 'svn show r123' and get what you want to see. But trac can help with this. This shows the changeset that leads to r123: https://trac.calendarserver.org/changeset/123 Cheers, -- Guido ___ 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 Wed, Nov 12, 2008 at 01:20:10PM +0100, Stefano Zacchiroli wrote: Following the (good) path of Closes, it should probably be something like [Commit: fed3f3d]. Also, can't it be put inside the same parentheses than Closes, as in (Closes: #7005180, #7005181; Commit: fed3f3d). If we really want a tag in front of the commit identifier we should specify the VCS: [Git:fed3f3d], [Svn:r1234], [Hg:fed3f3d] this would help in the case where a package switches VCSs. Finally, I missed if the aim is finding something Git-specific or not, in the latter case the commit ID can be paired via a VCS identifier, though I acknowledge that it risks to become too heavy ... It's (of course) not git specific at all, that wouldn't help much. In order to link back from the changelog to the VCS, we have all the needed information in debian/control already. I just noticed that Manoj picked up the propsed format for kernel-package too: https://honk.sigxcpu.org/cl2vcs/index.cgi?pkg=kernel-package Cheers, -- Guido ___ 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 Wed, Nov 12, 2008 at 11:09:45AM -0500, James Westby wrote: On Wed, 2008-11-12 at 08:39 +0100, martin f krafft wrote: also sprach Guido Günther [EMAIL PROTECTED] [2008.11.08.1419 +0100]: Does this look like a worthwhile extension to the current changelog format? For me it makes reviewing changes a lot easier. I think this is very important to have, but why put them at the front? Changelogs are for consumption by humans and machines, and humans have it easier if they can just start reading on the left side and get the information they want. Machines don't really care very much. So, similar to how we close bugs, how about * fixed segfault during daemon startup (Closes: #7005180) [fed3f3d] instead? You mean [fc5473a06be960382582ddbfb40e2a5f824be122] don't you? You can abbreviate that (git-rev-parse(1), see --short). I don't think we need a VCS identifier there. I don't see why anyone would specify a bzr revision id in a git package. How would this differ from using annotate on the changelog? Do some people write the changelog at the end? Using annotate on the changelog assumes you're committing the changelog entry together with the actual change. That's not a workflow everyone uses and IMHO makes little sense when using a DVCS since merging branches from different people/places creates unnecessary conflicts in the changelog. Cheers, -- Guido ___ 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
Hi, I think i'd be nice if once could link changelog entries back to VCS commits more easily (to see how a bug actually got fixed). Git-dch has support for including parts of the SHA1 for some time so together with Vcs-Browser we can easily link back to the VCS: http://honk.sigxcpu.org/con/Linking_Debian_Changelogs_back_to_the_Vcs.html Does this look like a worthwhile extension to the current changelog format? For me it makes reviewing changes a lot easier. -- Guido ___ 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 Tue, Sep 30, 2008 at 10:27:13PM +0200, Martin Bähr wrote: On Tue, Sep 30, 2008 at 02:27:34PM -0500, Manoj Srivastava wrote: Not really. I prefer to have the source packages be unpackged even on a machine which does not run Debian, using just plain old tar and patch. Thus I tend to ship the diff.gz as something that creates the set of bytes the package build was done from, and which is extracted easily without you having to have dpkg installed. I see the source package as something useful perhaps even in a non distro specific setting. indeed, they are. but exactly for working outside of debian it would be preferable to have the patches easely accessible seperately. i occasionally try to pick patches from other distributions when packaging for foresight because in the end we share most of the problems and patches for it. to work with a debian package i currently have to pull out the patch from the diff either by applying the diff to the source or by manually editing the diff file. from fedora i can just download the patch from fedoras cvs, in fact, if i don't need to edit the patch, then i can just directly refer to the cvs url in conary recipes, thus making it very obvious where the patch comes from: r.addPatch(http://cvs.fedoraproject.org/viewvc/rpms/cone/F-9/cone-gcc43.patch?revision=1.1;) Patches are easily accesible from within gitweb (using Vcs-Browser) when the package uses git-dch to generate the changelog. Git-dch allows to store the abbreviated commit id in the changelog so people can find patches easily by looking at the changelog first: libvirt (0.4.6-1) experimental; urgency=low * [e20d3d4] Imported Upstream version 0.4.6 * [0c840ab] disable numactl ... then using git-web: http://git.debian.org/?p=pkg-libvirt/libvirt.git;a=commitdiff_plain;h=0c840ab Cheers, -- Guido ___ 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 Mon, Sep 29, 2008 at 08:43:18AM +0200, martin f krafft wrote: [..snip..] If git-buildpackage expects master, then it is inflexible; you should be able to tell it to build from build. git-buildpackage builds from any branch you tell it to. -- Guido ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: [debian] where to document branch layout
On Wed, Jul 16, 2008 at 12:04:38AM +0200, Stefano Zacchiroli wrote: On Tue, Jul 15, 2008 at 01:45:16PM -0700, Russ Allbery wrote: [..snip..] FWIW, I've been keeping notes on what I'm personally doing at: http://www.eyrie.org/~eagle/notes/debian/git.html Very interesting reading! This is very interesting, thanks a lot for it! What others here do think of the workflow / branch layout you propose? Are there any other usual suspect as possible workflows / layouts? Despite of filtering non dfsg things out onto upstream/ already I usually import the verbatim upstream sources as is and create a dfsg-clean branch instead: git-branch dfsg-clean upstream rm doc/rfc* and in $REPO/.git.conf: [git-buildpacakge] upstream-branch = dfsg-clean [git-import-orig] debian-branch = dfsg-clean This lets git-buildpackage build the orig.tar.gz form dfsg-clean while git-import-orig merges onto dfsg-clean instead of master (so if you've removed the rfcs once, they'll stay gone forever). This is has the minimal advantage that co-maintainers don't have to worry about the correct import line when importing new upstream versions. Concerning backports I'm usually using bpo/release branches (e.g. bpo/sarge, bpo/etch). This way you can handle backports for different versions easily. I also keep the simple just add another changelog entry changes there so that I have a history of what versions were backported. Cheers, -- Guido ___ 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 handle Debian patches
On Fri, May 16, 2008 at 04:04:20PM -0400, Joey Hess wrote: Raphael Hertzog wrote: I totally agree that we need to make our changes more visible. In the openssl case, the patch in question is inside the .diff.gz and you don't notice it in the unpacked source package. I tend to give a look to what's in debian/patches/ when I rebuild a package but not to what's in .diff.gz only. To me this one proof more than even when VCS are used to maintain packages, our source packages must clearly identify the Debian patches that are applied. You're insinuatiog that a VCS does not allow easily browsing and examining patches, and I just don't buy it. The current git version of git-dch allows to automatically prefix the debian/changelog entries with git commit id's like: * [958c4b1] attach multipath.conf to bugreports * [2ac083e] make multipath-tools-boot arch all This, together with the VCS-Browser/Git fields in debian/control makes mapping the modifications to an easily reviewable patch quiet comfortable. This is only a very special case, but could certainly be done for other VCS too. -- Guido stating: - a description of the patch and its purpose - the associated bug number - who wrote the patch - where it has been forwarded upstream - sign-off by reviewers maybe All stuff that you get essentially for free by committing to a VCS. [2] And IMO we should go further than patches.d.o, we need to create a cross-distro infrastructure where we can share patches. We really have to show the way here... (we complained enough that ubuntu patches were unusable, surely we can show how to do it right when it comes to sharing patches with others and upstream) We didn't just complain that Ubuntu's patches were unusable, but that their whole means of communication of them back to upstream, ie Debian, was/is flawed. We [1] complained that automatically publishing patches was not sufficient to get those patches integrated back into Debian because -- a) People cannot be expected to poll a directory somewhere for new patches. (Which Ubuntu has partially addressed, if your proposal does, it's not clear to me specifically how.) b) Monolithic patches that make multiple changes are near-useless. (Which Ubuntu has not satisfactorally addressed, IMHO; I still get automated patch mails with multiple changes in them. Your propsal tries to address this.) c) Patches lacked explanations of why changes were made, beyond the changelog, and it was difficult to figure out more. (Which Ubuntu has not particularly addressed, and I'm not sure your proposal addresses entirely..) d) The best way to get good code is to go out and get in communication with upstream about it, explain the rationalle so that they can fully understand it, and take their advice into account. (Which Ubuntu maintainers generally still fail to do with Debian, and which your proposal doesn't really facilitate Debian doing more than we do now.) I can certianly see some good benefits to the lines that you're thinking, but if this turns into a pile of patches on a website that upstream has to manually go find, and rarely does, and a lot of busywork keeping the patches up-to-date, and maintaining redundant metadata ... then why would I want to use that when I can shoot a mail off to upstream with a git-format-patch in it? -- see shy jo [1] specifically, me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
