gmane.comp.package-management.vcs-pkg

Re: My use case of git-buildpackage

Daniel Dehennin — 2012-04-20T14:29:17


Hello,

As this mailing-list is quite calm, I make a status point of what I'm
doing ;-)


I finalize a poor man debian wanna-build documentation as the second
part of my automatic building setup, with diagram of the setup in
attachement.

Now I need to concentrate on the "git <-> packaging" gateway and
workflow, with some points in mind:

- debian/changelog is managed automatically[1] and out of the way of the
  packager

- extend the behaviour of git-flow to handle packaging and ease some
  processes like: a user found a bug on package version X-Y, as I'm the
  upstream too I want to fix upstream code and integrate it in package[2]

I was thinking of making a git-buildpackage daemon, making a post-update
hook triggering the machinery to build a source package when ever a tag
is added and upload it to my poor man wanna-build setup.

Now I wonder of calling git-buildpackage directly from the hook, using
one signed "to-build" tag[3] per distribution.

I need some process to make git-buildpackage create a "re

Re: My use case of git-buildpackage

Guido Günther — 2011-11-24T17:47:07

You can merge the upstream branch on your debian branch, create the orig
tarball using git-buildpackage and use pristine-tar to store the binary
delta in the repo. I plan to add an extra command for this in
git-buildpackage in the future.
Cheers,
 -- Guido

Re: My use case of git-buildpackage

Daniel Dehennin — 2011-11-24T17:21:07


There is already a debian package for the 2 or 3 packages I build, my
work is no more than something like:

git clone git://upstream.software/project && cd project
git remote add debian git://git.debian.org/project
git fetch debian
git checkout -b snapshot
git merge debian master
git buildpackage

Another point is that I'm working in a french educational ubuntu
derivative and try to do things not to badly ;-)


Yes, I'm looking at a good workflow to use it without storing it in my
branches, this will permit to avoid conflicts during merge/rebase.

When I'll merge a temporary branch of my doc, I'll explain a workflow
with tags, git rev-log, git describe.


Yes, of course, I'm looking at validation of packages, with piupart, CD
building and automatic installation tests.


Every example I saw use git-import-orig, what about using upstream VCS
directly and not the tar.gz?


Thanks.

Re: My use case of git-buildpackage

Yaroslav Halchenko — 2011-11-23T23:28:57

On Thu, 03 Nov 2011, Daniel Dehennin wrote:

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?


git-dch?


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?


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


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

Re: My use case of git-buildpackage

Daniel Dehennin — 2011-11-07T20:43:43

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

My use case of git-buildpackage

Daniel Dehennin — 2011-11-03T20:51:10

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

Re: Patch mgmt workflow proposal

Teemu Ikonen — 2011-08-10T13:10:08

Hi,

Are there any packages implementing this scheme (or plans to use it)?

I've been maintaining meshlab (for some value of 'maintain', I've been
somewhat busy with other things lately) with a cherry-pick based git
workflow. Upstream touching commits are made to the debian branch, but
are also cherry-picked to separate patch branches. Patches are
generated by diffing the upstream and patch branches and using
separate dep3 header files ('debian/metapatches').

Interested persons can check meshlab at
http://anonscm.debian.org/gitweb/?p=debian-science/packages/meshlab.git
and some helper scripts (and very little docs) at
http://gitorious.org/gdp/gdp/trees/master The scripts are probably not
ready for general usage unless you read and understand what they do.

The advantages of this approach are linear history in the debian
branch while also having clean separation of patch commits to topic
branches and the ability to do 'continuous integration' (i.e. builds
testing a single change) during package development

Re: Patch mgmt workflow proposal

martin f krafft — 2011-08-02T18:58:55

also sprach Thomas Koch <thomas< at >koch.ro> [2011.08.02.1732 +0200]:

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

Re: Patch mgmt workflow proposal

Thomas Koch — 2011-08-02T15:32:00

Thomas Koch:
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

Re: Patch mgmt workflow proposal

martin f krafft — 2011-08-02T08:45:11

also sprach Ben Finney <bignose+hates-spam< at >benfinney.id.au> [2011.08.02.0229 +0200]:

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


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 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.


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

Thanks for your time,

Re: Patch mgmt workflow proposal

martin f krafft — 2011-08-02T08:34:23

also sprach Ben Finney <bignose+hates-spam< at >benfinney.id.au> [2011.08.02.0223 +0200]:

That is a very wise statement, and I agree.


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.

Re: Patch mgmt workflow proposal

Ben Finney — 2011-08-02T00:29:49


This matches how I happily work on Debian packaging with Bazaar, except
for some minor details.


Right. The feature branches stay only with the people who are
interested; usually the people actually working on each one.


Yes. The central repository where team members coordinate their
revisions only has branches of interest to many or all.


Generalise “SHA-1 of the feature branch head” to “identifier of the
feature branch revision”, and that matches my workflow too.


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?


I don't see that brittleness; maybe that's because of the way Bazaar
keeps track of merges explicitly.


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.

Re: Patch mgmt workflow proposal

martin f krafft — 2011-08-01T18:47:56

also sprach Thomas Koch <thomas< at >koch.ro> [2011.08.01.1914 +0200]:

This comes about ¾ of the way to the history pollution done by
TopGit. 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.

I am currently investigating means to store information outside the
worktree in an immutable and automatically tracked-and-shared way:

  http://permalink.gmane.org/gmane.comp.version-control.git/178349
  (msgid 20110801121946.GA575< at >fishbowl.rw.madduck.net)
  http://permalink.gmane.org/gmane.comp.version-control.git/178393
  (msgid 20110801182015.GA3100< at >fishbowl.rw.madduck.net)

Feedback welcome, of course.

Re: Patch mgmt workflow proposal

Thomas Koch — 2011-08-01T17:14:03

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

martin f krafft:
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 ab

Re: Patch mgmt workflow proposal

martin f krafft — 2011-08-01T09:34:48

also sprach Thomas Koch <thomas< at >koch.ro> [2011.07.30.1229 +0200]:

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 th

Branch dependencies with Git hooks

martin f krafft — 2011-07-30T16:34:36

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 un

Patch mgmt workflow proposal

Thomas Koch — 2011-07-30T10:29:32

Hi,

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

I'd be happy over any feedback.

Regards,

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

Reply by email

Hoffman, Ronald — 2011-07-04T13:18:28

Good Day,

I am Peter Wong in Hong Kong. Please
I would like you to assist me in a business
project worth Forty Four Million Five Hundred
Thousand Dollars.

You will have 50% of the total Funds as your share.
If you are interested to know more details contact me
back at my private email: {hsb39peterwong< at >yahoo.com.hk<http://uk.mc246.mail.yahoo.com/mc/compose?to=%7bhsb39peterwong< at >yahoo.com.hk>}

I will be waiting to hear from you.

Best Regards,
Mr. Peter T.S Wong

[ s1n9thczfbm4ygsy] : medical mailing list

Marcella scurry — 2011-06-01T01:50:36

Value priced Data: $395 for everything below! (only until Friday)

All 100% optin data / Full resale rights

---HEALTHCARE LISTS

 

Physicians (34 specialties)
Database: 788k records, 17k emails, 200k fax numbers
 
Chiropractors
Database: 108,421 total records * 3,414 emails * 6,553 fax numbers
 
Alternative Medicine
Database: 1,141,602 total records with 36,320 emails and 38.935 fax numbers
 
Dentists
Database: 164k records, 45k emails, 77k fax numbers
 
Dentists with Specialties
Database: 30k records all with emails
 

Veterinarians
Database: 78,986 total records with 1,438  emails and 1,050  fax numbers
 
Hospitals
Database: 10,661 Emails for hospitals in the USA
 
Nursing Homes
Database: 31,589 Senior Administrators, 11,288 Nursing Directors in over 14,706 Nursing Homes (full contact info no emails)
 
Pharmaceutical Companies
Database: 47,000 emails of pharma company employees
 
Physical Therapists
Database: 125,460 total records with 5,483 emails and 4,405 fax numbers
 

Oncology

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

Bruno Cornec — 2011-05-27T10:26:43

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 <bruno< at >project-builder.org> -----

From: Bruno Cornec <bruno< at >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-announce< at >project-builder.org, pb-devel< at >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 -----

Re: Shared pidgin releases and vcs-pkg

Vincent Untz — 2009-05-29T02:02:31

Le dimanche 24 mai 2009, à 18:27 -0400, Olivier Crête a écrit :

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:Factory&package=pidgin

Cheers,

Vincent