http://blog.gmane.org/gmane.comp.package-management.vcs-pkg hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/302 James Westby 2008-11-27T09:28:26 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/278 I've been using CVS, SVN, QUILT and GIT over 10 years. I'm lately playing with building rpm's from GIT and SVN repositories. I have a nice set of scripts called make-srpm (with a git helper and a less mature svn helper). The scripts will export a "pristine" source and a set of patches from the archive and make an srpm The release for the pristine source can be automatically determined based on the most recent tag matching a glob, or be specified directly. A set of patches between the source tar and the target released is automatically generated, coping with merging and branching by selecting the paths that have the most number of commits - as was done for the bitkeeper exports. Arguments can be specified as magic comments in the spec file, or on the command line - perhaps to make it easy to use makefile variables too. Build an srpm may be something like: $ make-srpm RELEASE=LOCAL VERSION=1.2 To build and RPM of checked out and uncommited source and call it version 1.2. For non-tagged release the git-hash is part of the release information, and for LOCAL builds, the date appended to the release infomation as well as the git hash. The hardest bit was the "find longest path" to break the patches into the most number of smaller patches, and that was written in awk, embedded in the scripts. Another hard bit was dealing with git-diff's delete/add empty file patches, which was solved by generating a double patch to use an intermediate 1 line file. Another hard bit was filtering out of empty patch files which occur at some merge points. All in all it produces srpms's and spec files full of patches just like the old redhat kernel rpm's. And they work. bash is required, but I think that is not too harsh a requirement for building rpm's. err.... how shall I post it for comment? Sam Sam Liddicott 2008-11-19T14:33:09 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/266 Nicolas Duboc 2008-11-16T16:00:13 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/230 Cornel 2008-11-06T12:19:57 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/130 Hello, My name is Stéphane Glondu. I've been using Debian for many years, and I've been contributing to Debian for one year now. I am DM (and in NM process). I work mainly in the Debian OCaml Team¹. I am interested in this list because I am interested in issues raised by packaging, and, more generally, in VCSs. I am familiar with packaging with subversion (as member of the OCaml Team) and git. Our team is slowly migrating to git packaging². In this context, I've migrated many repositories of Debian packages from svn to git with the help of a (quite dirty, I must admit) script of my own (I wasn't satisfied enough with existing ones). This was also a way to get more acquainted with svn and git. I still haven't adopted a clear workflow for my git packaging, as I am trying/using several ones. I am also familiar with cvs (but forgetting :-) and darcs (neither of them for packaging). I still tend to push people into using darcs (if they don't use any DVCS). I am a big fan of darcs and git. ¹ http://wiki.debian.org/Teams/OCamlTaskForce ² http://wiki.debian.org/Teams/OCamlTaskForce/GitMigration Cheers, Stéphane Glondu 2008-09-25T13:38:44 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/118 Greetings, I subscribed to the list a while back, but I don't believe I ever got around to introducing myself. My name is Chris Larson, but am most well known as Kergoth. I work in the embedded Linux field. I've done work on bootloaders, kernel, userland, distro, build tools, etc. I founded the OpenZaurus Linux distro for the Sharp Zaurus line of PDAs, and created the OpenEmbedded project, which was originally a portage fork. It exists because I got tired of gmake's limitations, and all of the existing distribution tools were limited, either lacking crosscompilation support, or expected to run the tools only -on- that distribution. I wanted a tool that would run anywhere, and could target any platform, and support multiple target packaging formats and distributions. The metadata repository is shared by multiple embedded distributions and projects, so in that aspect, the goal was quite similar to that of vcs-pkg.. collaboration. I've hacked on debian packages and tools, redhat packages and tools, and gentoo packages and tools, but never got around to pursuing actually becoming a developer for any (I know just how much time a distro can suck up..). Most of the OE target distros are debian based, as I found most debian distributionisms (I say that's a word, dangit) to be superior to redhat ones, and more stable than gentoo ones (i.e. interfaces(5)), though there are obvious exceptions. OE can output ipk, deb, or rpm files. Originally it could take either our metadata format or a source rpm as input (with a metadata conversion layer), but I doubt that's been maintained in my absence from the project (got burned out). I went a couple years without messing with distribution or build tools, but am finding my interest rekindled. On the source control front, I've experience using and maintaining CVS, svn, monotone, git, bk, svk, and a couple other types or repositories. Don't really know mercurial or bazaar, yet. I was the buildmeister / configuration management guy and a core developer of the Opie project (fork of Qtopia), also. Recently, I've been really enjoying messing with topgit and pristine-tar.. there's definate potential there, and I'm debating writing a new tool to better support that methodology for us crazy embedded folk :) I have a quick hack of a tg-rename here, by the way. It just updates the head & top-bases refs and zips through the branches, updating .topdeps for each, in case anyone wants such a thing. Sorry for the disorganization of that intro, I tend to wander at times ;) Chris Larson 2008-08-19T19:39:05 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/110 Bruno Cornec 2008-08-12T18:09:40 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/108 martin f krafft 2008-08-12T17:48:46 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/105 martin f krafft 2008-08-12T16:18:54 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/104 martin f krafft 2008-08-11T16:40:42 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/95 Pierre Habouzit 2008-08-03T13:54:19 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/94 Pierre Habouzit 2008-08-03T13:53:15 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/84 Stefano Zacchiroli 2008-07-15T18:37:01 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/83 Stefano Zacchiroli 2008-07-15T18:31:04 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/79 Hi all, Pierre posted a Debian changelog-specific merger a couple of months ago. Bryce just knocked another up from the Merge-o-matic source code not knowing about Pierre's. You can find it at http://people.ubuntu.com/~bryce/scripts/merge_changelog It's significantly longer, but I'm not sure how else it differs as I haven't had chance to compare them in detail yet. Bryce did say that he found this one handled epochs better than Pierre's. I can pass any feedback anyone has on. Thanks, James James Westby 2008-06-18T20:33:17 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/78 Hi all, I wanted to update the list on the proposal that I have been writing for the last couple of months (with code, but I think that's less interesting as the idea is pretty simple). https://wiki.ubuntu.com/DistributedDevelopment/ImporterSpecification It's a proposal to import all of Ubuntu in to branches of bzr, and then make these available for Ubuntu developers to work with. This brings a couple of things. Obviously we get the power of a VCS to do the work, which I don't think that anyone on this list needs convincing of. However, we also get consistency. You know you'll be able to get a branch of any package, and you know what you get when you grab that branch (rather than having to worry about whether it's debian/ only or not, you still have to work out which patch system it is, etc.). There's been a long desire to have this, but the past approaches weren't getting anywhere fast. This does ignore existing branches, and VCS that may be being used in Debian or upstream, but treating everything the same for now allows us to get somewhere. It is in no way the aim to go out on our own for ever, we are just using it as a slingshot to get started. I don't think that it conflicts with anything that vcs-pkg is trying to achieve, and I will be working to incorporate things from this list, both the ideas and the tools. I'm happy to talk to anyone about specifics, or about ways in which we can work with people outside of Ubuntu better on this, so just get in touch any time. Thanks, James James Westby 2008-06-18T18:35:06 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/76 Hi VCS packagers, on this year's DebConf, Martin will possibly hold a talk about vcs-pkg and hopefully excite lots of people for the issue. My hope was that this would generate enough interest to hold a Face-to-face meeting and get some offline discussion going, so to follow-up on the talk I registered a BoF session on the topic (which has been accepted). Unfortunately, due to the shaky sponsorship situation, the physical distance to Argentina, and other RL contraints, I absolutely cannot make it to DebConf this year. :-( So if anybody else is definately planning on going, sees value in this form of meeting, and will have a few spare cycles to prepare and host this BoF, please contact me per PM so we can arrange an event takeover with the DebConf organizers. Having said that, I'm definatly excited to have a more intensive work session in Extremadura this september. The wiki page [1] suggests June 23rd as the last possible date to register, so give your heart a shove (or some less germanish expression to the same effect), make room in your calendar, and register with Martin _now_. :-) And to you DebConf-goers, please still leave some work to be done for us in September. ;-) Philipp. [1] http://vcs-pkg.org/meetings/2008.09.extremadura/ Philipp 2008-06-16T16:57:27 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/74 Hello, My name is Jeremiah Foster and I am an active debian user. I started to work with the debian-perl team about a year ago and continue to co-maintain some packages there and am maintaining a couple other packages for debian on my own. I am interested in this list because I think cross-distro co-operation in general is a very good idea and a versioning packaging system makes sense to me. I hope to lurk a bit, try to build a package or two with this format, and contribute when I get up-to-speed. Regards, Jeremiah Jeremiah C. Foster 2008-05-28T07:51:05 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/68 martin f krafft 2008-05-18T13:12:27 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/53 Hi folks, I have been working on an analysis of various strategies people have posted about for handling topic branches, and an exploration of which methodology has advantages, and whether there are scenarios in which the _other_ work flow would have been better. http://www.golden-gryphon.com/software/misc/packaging.html The paper was mentioned in my blog (syndicated on the vcs-package blog aggregator), but now has been greatly expanded with help and feed back from readers (and now has pretty pictures to go with the text). I see this as a work in progress, comments and critiques welcome, and I'll try and meld any resulting discussion back into that page. manoj Manoj Srivastava 2008-04-10T04:33:36 http://comments.gmane.org/gmane.comp.package-management.vcs-pkg/30 [ the technical aspect of the problem I'm describing is debian+git specific, but the conceptual problem is applicable to every distro/$DVCS, I guess ] I've a git repository which has been used to version only the debian/ dir thus far [1]. Now that we have git and its space efficiency, I want to version both upstream sources and the debian dir in the very same system. The usual layout supported by git-buildpackage (but I guess one of the obvious layout) is to have two branches, an "upstream" branch with upstream source only and a "master" branch (which I believe is the one called informally "integration" branch) with both upstream sources + the debian/ dir. Moving to what I have (i.e. just a single "master" branch) to such a layout ain't easy apparently. The key problem is: how to generate from scratch an upstream branch which only contains upstream sources. The naive solution (which is actually what git-buildpackage tries to do when using git-import-orig/dsc) of branching off an upstream branch from the master branch and then deleting the debian/ dir does not work, as when we try to merge usptream back into master git will merge even the deletion of the debian/ dir. Ideally I should be branching the root of the commit dag, but unfortunately even that has a debian/ dir which has been added as the first commit (and no, at least in git there is no such a think as the parent of the commit dag root, I've tried that :)). I've found some ugly solution using git-filter-branch on an upstream branch branched from master, but the resulting history is horrible. What I would need is the ability to create a separate history line from scratch, call it "usptream", tie it with the master history with a new (fake) commit root, and then merge the two into master. Is that possible with git or some other $DVCS? I guess solving this issue will be a common need for anyone which want to move from the version of only distro-specific stuff to the versioning of distro+usptream stuff. TIA, Cheers. [1] actually it is a such only because it is a git repo generated converting from a svn repo, but this is not that relevant. Stefano Zacchiroli 2008-03-19T09:28:50 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.package-management.vcs-pkg