Re: [RFC] Add upstream VCS info to control file

On Thu, Jun 28, 2012 at 7:47 AM, Andrew Shadura wrote: > I wonder why not use #-syntax, just like hg does: > > Vcs-Qux: quux://host.org/path/to/repo#debian/unstable git does not support that, seems it doesn't know about the # character: $ git clone 'git://anonscm.debian.org/anonscm.debian.org/o

Re: [RFC] Add upstream VCS info to control file

Hello, On Thu, 14 Jun 2012 17:30:51 -0400 James McCoy wrote: > Since devscripts 2.11.7, you can do this: > Vcs-Git: git://anonscm.debian.org/anonscm.debian.org/openstack/nova.git -b > debian/unstable > I thought the patch that added that also updated the documentation, > but it looks like doc

Re: [RFC] Add upstream VCS info to control file

On Sat, 2012-06-16 at 20:40:03 +0900, Charles Plessy wrote: > Le Sat, Jun 16, 2012 at 07:58:03PM +0900, Osamu Aoki a écrit : > > > > We can think of 3 candidate files. > > #1, debian/copyright > > #2, debian/watch > > #3, debian/control (Not for me but you suggested) > > I would like to add de

Re: [RFC] Add upstream VCS info to control file

Le Sat, Jun 16, 2012 at 07:58:03PM +0900, Osamu Aoki a écrit : > > We can think of 3 candidate files. > #1, debian/copyright > #2, debian/watch > #3, debian/control (Not for me but you suggested) I would like to add debian/upstream to the list. It is machine-readable, documented, gathered, a

Re: [RFC] Add upstream VCS info to control file

Hi, On Thu, Jun 14, 2012 at 02:59:26PM +0200, Gregor Jasny wrote: > Hello, > > When one tries to fix a FTBFS bug a look into the upstream VCS is > often helpful. Sometimes a link to browse them is easily found on > the homepage linked from the PTS page. But often these links are > deeply buried i

Re: [RFC] Add upstream VCS info to control file

Ansgar Burchardt writes: > On 06/15/2012 11:33 AM, Thomas Goirand wrote: >> Yeah, a hook of any sorts is ok for me. The get-vcs-source in debian/rules >> seems quite ok to me. Should debcheckout be modified to call it? It's part >> of devscript, do you think it's ok if I submit a wishlist bug rep

Re: [RFC] Add upstream VCS info to control file

On 06/15/2012 11:33 AM, Thomas Goirand wrote: > Yeah, a hook of any sorts is ok for me. The get-vcs-source in debian/rules > seems quite ok to me. Should debcheckout be modified to call it? It's part > of devscript, do you think it's ok if I submit a wishlist bug report against > devscript to ask f

Re: [RFC] Add upstream VCS info to control file

On 06/15/2012 01:50 PM, Gergely Nagy wrote: > While having a standardized way would be useful, there's just so many > workflows, that you can't possibly cover all of them with a single > syntax, and in the end, you'd end up with having to call > package-specific scripts in the source. > > We alread

Re: [RFC] Add upstream VCS info to control file

On Thu, Jun 14, 2012 at 11:50:35PM +0800, Thomas Goirand wrote: > When using Git, it's quite a common practice to only store the debian > branch on Alioth, then have the master branch stored ... upstream. > See for example: > > http://openstack.alioth.debian.org/ How common? I've never seen it do

Re: [RFC] Add upstream VCS info to control file

On Thu, Jun 14, 2012 at 11:50:35PM +0800, Thomas Goirand wrote: > > I quite not agree with both "solutions" to use debian/README.source > or debian/upstream. Here's why. > > 1/ Packaging workflow with upstream Git repository > ... I agree that debian/README.source is no solution because it is no

Re: [RFC] Add upstream VCS info to control file

Gregor Jasny writes: > Does this sound reasonable? Yes. Please also read the earlier thread http://lists.debian.org/debian-devel/2011/04/msg00356.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.or

Re: [RFC] Add upstream VCS info to control file

Thomas Goirand writes: > On 06/15/2012 12:03 AM, Cyril Brulebois wrote: >> Anyway, here's what I've been doing for our 150+ X packages: >> >> $ cat xserver-xorg-video-ati.git/debian/watch >> #git=git://anongit.freedesktop.org/xorg/driver/xf86-video-ati >> version=3 >> http://xorg.freedesktop.org

Re: [RFC] Add upstream VCS info to control file

On Jun 14, 2012 11:51 AM, "Thomas Goirand" @ debian.org > wrote: > > 3/ How to achieve it > |=-=-=-=-=-=-=-=- > |To acheive this, we would need something like this: > > ||Vcs-Git-Debian-Branch-Name: debian/unstable > ||Vcs-Git: > |git://anonscm.debian.org

Re: [RFC] Add upstream VCS info to control file

On 06/15/2012 12:03 AM, Cyril Brulebois wrote: > Anyway, here's what I've been doing for our 150+ X packages: > > $ cat xserver-xorg-video-ati.git/debian/watch > #git=git://anongit.freedesktop.org/xorg/driver/xf86-video-ati > version=3 > http://xorg.freedesktop.org/releases/individual/driver/ > x

Re: [RFC] Add upstream VCS info to control file

Thomas Goirand (14/06/2012): > 1/ […] 2/ […] > 3/ How to achieve it > |=-=-=-=-=-=-=-=- > |To acheive this, we would need something like this: > > ||Vcs-Git-Debian-Branch-Name: debian/unstable > ||Vcs-Git: |git://anonscm.debian.org/openstack/nova.git > |||Vcs-Git-Upstream-Branch-Name: master > |V

Re: [RFC] Add upstream VCS info to control file

On 06/14/2012 09:23 PM, Gergely Nagy wrote: > Gregor Jasny writes: > >> When one tries to fix a FTBFS bug a look into the upstream VCS is >> often helpful. Sometimes a link to browse them is easily found on the >> homepage linked from the PTS page. But often these links are deeply >> buried in

Re: [RFC] Add upstream VCS info to control file

Gregor Jasny writes: > When one tries to fix a FTBFS bug a look into the upstream VCS is > often helpful. Sometimes a link to browse them is easily found on the > homepage linked from the PTS page. But often these links are deeply > buried in the linked website. > > What I'd like to see in the De

Re: [RFC] Add upstream VCS info to control file

Le Thu, Jun 14, 2012 at 02:59:26PM +0200, Gregor Jasny a écrit : > > When one tries to fix a FTBFS bug a look into the upstream VCS is > often helpful. Sometimes a link to browse them is easily found on > the homepage linked from the PTS page. But often these links are > deeply buried in the linke