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 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. ¹ ht 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 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 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 exp 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 m 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