Josselin Mouette wrote:
> On sam, 2008-01-26 at 22:37 +0200, Riku Voipio wrote:
>> On Sat, Jan 26, 2008 at 08:37:54PM +0100, Stefano Zacchiroli wrote:
>> > If I were you I would have tried "fakeroot debian/rules
>> > get-orig-source", which is the policy mandated target to retrieve
>> > orig.tar.g
Andreas Tille kirjoitti:
> On Sat, 26 Jan 2008, Teemu Likonen wrote:
> > I do maintain some unofficial packages which - of course - I can do
> > anything I want with, but I also want to do things right, so I'd
> > appreciate your help in this.
>
> May I ask for the sake of interest what unofficial
On Sat, 26 Jan 2008, Teemu Likonen wrote:
I do maintain some unofficial packages which - of course - I can do
anything I want with, but I also want to do things right, so I'd
appreciate your help in this.
May I ask for the sake of interest what unofficial packages you
are maintaining? Sometim
On Mon, 28 Jan 2008, Cyril Brulebois wrote:
everything is DFSG free). I'm not aware of a default extension for
the tarball name in case of repackaged tarballs.
I already pointed to Devref 6.7.8.2, now quoting it:
| A repackaged .orig.tar.gz:
| ?
| 4. should use -.orig as the name of the
| top
On Sun, 27 Jan 2008, Stefano Zacchiroli wrote:
Many people correctly pointed out that get-orig-source is only suggested
by the policy and that, as a best practice, it is recommended only when
repacking is needed. Fair enough. Can we either change its meaning or
add a new target which does what y
On 28/01/2008, Andreas Tille wrote:
> There are other reasons for repackaging (for instance large chunks of
> precompiled binary data that would just bloat the archive even if
> everything is DFSG free). I'm not aware of a default extension for
> the tarball name in case of repackaged tarballs.
I
On Sun, 27 Jan 2008, Raphael Geissert wrote:
Not only "dfsg", "debian" and "ds" are also used (when repackaging wasn't
because the real source isn't completely DFSG-free).
There are other reasons for repackaging (for instance large chunks of
precompiled binary data that would just bloat the ar
Cyril Brulebois wrote:
>
> Note that the get-orig-source target isn't really mandated, but optional
> (Policy 4.9), and usually implemented when a repack is needed (Devref
> 6.7.8.2). Whether a repack happened is easily detected by looking at the
> Debian changelog (through the presence of a “dfsg
Stefano Zacchiroli wrote:
> On Sat, Jan 26, 2008 at 10:37:10PM +0200, Riku Voipio wrote:
>
> Many people correctly pointed out that get-orig-source is only suggested
> by the policy and that, as a best practice, it is recommended only when
> repacking is needed. Fair enough. Can we either change i
On 27/01/2008, Lars Wirzenius wrote:
> Roberto already pointed out that get-orig-source is optional, not
> mandatory, but I'm wondering about the fakeroot. Why should the
> get-orig-source target be run as root, or even as a fake root?
I guess it only comes from an habit, when one is testing/hacki
On la, 2008-01-26 at 20:37 +0100, Stefano Zacchiroli wrote:
> On Sat, Jan 26, 2008 at 08:58:27PM +0200, Riku Voipio wrote:
> > I just tried this on madwifi, and it only pulled me contents of debian/
> > directory. Now I can't use that to anything, since there is no matching
> > upstream sources ava
On sam, 2008-01-26 at 22:37 +0200, Riku Voipio wrote:
> On Sat, Jan 26, 2008 at 08:37:54PM +0100, Stefano Zacchiroli wrote:
> > If I were you I would have tried "fakeroot debian/rules
> > get-orig-source", which is the policy mandated target to retrieve
> > orig.tar.gz. I haven't tried, but lookin
On Sat, Jan 26, 2008 at 10:37:10PM +0200, Riku Voipio wrote:
> This was a really usefull bit of information, thanks. Thou
> get-orig-source of madwifi pulls the source to ../tarballs so some manual
> work is still required.
> Maybe debcheckout could run get-orig-source if only debian/ directory
>
On Sat, Jan 26, 2008 at 08:37:54PM +0100, Stefano Zacchiroli wrote:
> If I were you I would have tried "fakeroot debian/rules
> get-orig-source", which is the policy mandated target to retrieve
> orig.tar.gz. I haven't tried, but looking at madwifi's debian/rules it
> is indeed implemented and ret
On 26/01/2008, Stefano Zacchiroli wrote:
> If I were you I would have tried "fakeroot debian/rules
> get-orig-source", which is the policy mandated target to retrieve
> orig.tar.gz.
I guess that trying uscan first might be a good rules of thumb (as well
as bugging the maintainer if no (usable) wat
On Sat, Jan 26, 2008 at 08:37:54PM +0100, Stefano Zacchiroli wrote:
>
> If I were you I would have tried "fakeroot debian/rules
> get-orig-source", which is the policy mandated target to retrieve
> orig.tar.gz. I haven't tried, but looking at madwifi's debian/rules it
> is indeed implemented and
On Sat, Jan 26, 2008 at 08:58:27PM +0200, Riku Voipio wrote:
> I just tried this on madwifi, and it only pulled me contents of debian/
> directory. Now I can't use that to anything, since there is no matching
> upstream sources available. I wonder if it would make sense to require
> that the Vcs- f
On Sat, Jan 26, 2008 at 08:58:27PM +0200, Riku Voipio wrote:
>
> I just tried this on madwifi, and it only pulled me contents of debian/
> directory. Now I can't use that to anything, since there is no matching
> upstream sources available. I wonder if it would make sense to require
> that the Vcs
On Sat, Jan 26, 2008 at 01:00:51PM +0100, Cyril Brulebois wrote:
> On 26/01/2008, Teemu Likonen wrote:
> > About these new Vcs-* fields in debian/control: it's not clear to me
> > where the URLs should be pointing at.
> See for yourself:
> | $ PAGER=cat man debcheckout | grep -A1 ^NAME
> | NAME
>
On Sat, 26 Jan 2008 11:21:41 +0200, Teemu Likonen wrote:
> About these new Vcs-* fields in debian/control: it's not clear to me
> where the URLs should be pointing at.
They are explained in the Developer's Reference, section 6.2.5:
http://www.debian.org/doc/developers-reference/ch-best-pkging-pr
On 26/01/2008, Teemu Likonen wrote:
> About these new Vcs-* fields in debian/control: it's not clear to me
> where the URLs should be pointing at. Are they meant to point to the
> upstream VCS where the actual development happens, so that users can
> checkout the upstream trunk (?) directory easily
Hi
I do not maintain any official Debian package nor I'm a Debian developer
but I'm interested in some of the Debian's technical points anyway.
About these new Vcs-* fields in debian/control: it's not clear to me
where the URLs should be pointing at. Are they meant to point to the
upstream VCS
22 matches
Mail list logo
