Re: New source package formats now available

[Goswin von Brederlow]

Charles Plessy  writes:

> Le Mon, Nov 30, 2009 at 11:47:04AM +0100, Goswin von Brederlow a écrit :
>> 
>> When someone (e.g. an NMUer) does edit an upstream file and builds the
>> package then the source do not contain those changes while the binary
>> will. That is clearly going to cause no end of pains.
>> 
>> Building the source package and unpacking it should always result in
>> the same source tree or fail to build in the first place. Simply
>> ignoring changes is too dangerous.
>
>
> Sorry Goswin, but I will be politically incorrect… Please do not take
> personnaly.
>
> Primo)
>
> I checked your Debian QA page and it does not seem that you are doing NMUs. On
> the other hand, if you check my QA page, you will see that do regular uploads
> quite frequently. Therefore, when I write that it is not convenient for quilt
> users that dpkg suddenly attempts to take control of the patch management they
> were taking care by themselves, and when you answer that it is a necessary
> feature for people who do NMU, isn't there a strong discrepancy in the
> discussion since I speak from experience and you don't?

Nowhere in my mail do I say that. I made no mention of quilt or dpkg
doing patch management. My argumentation has nothing to do with that
but only with your proposal.

Your suggestion to simply ignore all changes to upstream files makes
it dangerously simple to forget some of them and is totaly
avoidable. I have nothing against your proposed quiltless format but
then dpkg should fail if there are upstream changes. That way you can
not forget to update the patches or add a file to the patches or
forgot to commit to git or whatever is being used.

As for experience you are arguing from the experience of a good
maintainer that is carefull and methodical. I'm arguing from
experience of how badly maintainer manage to screw things up. I've
seen packages being uploaded with a syntax error in debian/rules but
still having all the binary debs build as well. Packages linked
against stable or experimental libraries. and the list goes on and on.
People do screw up. They are people.

> Secundo)
>
> As I already answered (too harshly) to Raphaël, I and many developers only
> upload packages that were built in a clean chroot. Therefore, I think that 
> your
> statement about ignoring changes being “too dangerous” is a gross 
> overstatement
> that is not backed by facts.

And many developers do not build in a clean chroot. Also the chroot
being clean or not has no affect on building the source. Unless you
build the source first and then do a clean  build starting with
unpacking the source again your "clean" build would still be broken.

Far too many people do not build source and then call pbuilder with
the dsc file for an upload (or equivalent).

And it only takes one to screw up.

> By the way, I started recently (for reasons unrelated to this thread) to
> document in README.Debian how to test the packages I maintain, to facilitate
> uploads by people not familiar with the package if needed, as well as to 
> inform
> the users about what level of testing they should expect. I encourage other
> maintainers—especially those concerned with helping “NMUers”—to do so.

Don't get me wrong. Documenting ways to test your package is
great. But why should I need to test something that dpkg can far
better test automatically with 100% accuracy?

> Cheers,

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Charles Plessy]

Le Mon, Nov 30, 2009 at 11:47:04AM +0100, Goswin von Brederlow a écrit :
> 
> When someone (e.g. an NMUer) does edit an upstream file and builds the
> package then the source do not contain those changes while the binary
> will. That is clearly going to cause no end of pains.
> 
> Building the source package and unpacking it should always result in
> the same source tree or fail to build in the first place. Simply
> ignoring changes is too dangerous.


Sorry Goswin, but I will be politically incorrect… Please do not take
personnaly.

Primo)

I checked your Debian QA page and it does not seem that you are doing NMUs. On
the other hand, if you check my QA page, you will see that do regular uploads
quite frequently. Therefore, when I write that it is not convenient for quilt
users that dpkg suddenly attempts to take control of the patch management they
were taking care by themselves, and when you answer that it is a necessary
feature for people who do NMU, isn't there a strong discrepancy in the
discussion since I speak from experience and you don't?

Secundo)

As I already answered (too harshly) to Raphaël, I and many developers only
upload packages that were built in a clean chroot. Therefore, I think that your
statement about ignoring changes being “too dangerous” is a gross overstatement
that is not backed by facts.


By the way, I started recently (for reasons unrelated to this thread) to
document in README.Debian how to test the packages I maintain, to facilitate
uploads by people not familiar with the package if needed, as well as to inform
the users about what level of testing they should expect. I encourage other
maintainers—especially those concerned with helping “NMUers”—to do so.


Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Goswin von Brederlow]

Russ Allbery  writes:

> Brian May  writes:
>
>> Just a general observation, it is rather painful to have to set and
>> maintian QUILT_PATCHES by hand everytime I want to modify a patch. There
>> have been a number of times now I have accidentally created the patch in
>> the wrong directory, which can be very confusing (mess two projects up
>> in one go!).
>
>> Maybe this is now fixed in unstable, last I checked it wasn't.
>
> If the only thing you use quilt for is Debian packaging and you perform
> quilt operations from the top of the tree, then this setting in ~/.quiltrc
> works fine:
>
> QUILT_PATCHES=debian/patches
>
> There's a more complex recipe in the quilt documentation that handles more
> cases.
>
> -- 
> Russ Allbery (r...@debian.org)   

http://bugs.debian.org/557623
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=26;filename=quilt-remember_locations.patch;att=1;bug=557623

Please do test.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Goswin von Brederlow]

Charles Plessy  writes:

> Le Tue, Nov 24, 2009 at 08:17:17AM +0100, Raphael Hertzog a écrit :
>> 
>> I can add a new option "--no-debian-patch" that would refuse to create the
>> automatic quilt patch debian-changes- and make it fail instead if
>> there are upstream changes.
>
> Hi Raphaël,
>
> even simpler, an option or a format that would completely ignore what is
> outside the debian directory:
>
>  - When packing a source package, a compressed tar archive would be made from
>the contents of the debian directory.
>
>  - When unpacking a source package, the compressed debian tar archive would be
>unpacked in the upstream sources, after deleting any existing debian
>directory.
>
> As it is already the case with Format 1.0 when the maintainer took care of
> having a diff.gz file that only contains files within the debian directory, 
> the
> packaging system would not patch or unpatch the upstream sources, leaving this
> task to the maintainer.
>
> Have a nice day,

With one HUGE difference.

When someone (e.g. an NMUer) does edit an upstream file and builds the
package then the source do not contain those changes while the binary
will. That is clearly going to cause no end of pains.

Building the source package and unpacking it should always result in
the same source tree or fail to build in the first place. Simply
ignoring changes is too dangerous.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Russ Allbery]

Brian May  writes:

> Just a general observation, it is rather painful to have to set and
> maintian QUILT_PATCHES by hand everytime I want to modify a patch. There
> have been a number of times now I have accidentally created the patch in
> the wrong directory, which can be very confusing (mess two projects up
> in one go!).

> Maybe this is now fixed in unstable, last I checked it wasn't.

If the only thing you use quilt for is Debian packaging and you perform
quilt operations from the top of the tree, then this setting in ~/.quiltrc
works fine:

QUILT_PATCHES=debian/patches

There's a more complex recipe in the quilt documentation that handles more
cases.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Brian May]

On Mon, Nov 23, 2009 at 04:12:58PM +1100, Brian May wrote:
> Am I doing something wrong?

Just a general observation, it is rather painful to have to set and maintian
QUILT_PATCHES by hand everytime I want to modify a patch. There have been a
number of times now I have accidentally created the patch in the wrong
directory, which can be very confusing (mess two projects up in one go!).

Maybe this is now fixed in unstable, last I checked it wasn't.
-- 
Brian May 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Charles Plessy]

Le Fri, Nov 27, 2009 at 02:28:26PM +0100, Raphael Hertzog a écrit :
> Obviously, we don't want to have many formats in the archive and it's best
> if "3.0 (quilt)" is flexible enough so that we don't have to invent many
> other formats.
 
Le Fri, Nov 27, 2009 at 02:49:39PM +0100, Raphael Hertzog a écrit :
> Unpacking should be under control of the unpacker and
> not under control of the one who crafted the source package.

I think that this is a monopolist point of view:

 - You have two different softwares (a packaging software and a patch
   management software) and you bundle them together so that people who would
   like the former must also use the latter.

 - You present the removal of a feature like a costly solution (like when
   people were asked to pay an extra if they do not want to use Windows on their
   new PC).

 - You plan to break backward compatibility to force users to upgrade, by
   making 3.0 the default before it is widely adopted. Remember this each time
   you get a .docx document that you can not open.

 - You try to hijack the directory where your competitors are doing their work
   (debian/patches), by applying quilt patches that were not made for the
   format 3.0 (and sometimes fail).

Your design decisions make the format ‘3.0 (quilt)’ not particularly useful for
the maintainers who already implemented a workflow based on a VCS and a patch
management system (or a VCS that does both). Worse, it seems that it creates
problems when one wants to keep the patch and unpatch targets in debian/rules.
I would be interested in the other improvements, namely the possibility to use
.tar.bz2 original upstream sources, and the possibiltiy to store the debian
directory in a tar archive, but I can also keep on working with format 1.0 as
before.

Last question: is the use of the Format field in debian/control deprecated, or
can I use it for the packages that I would like to stay in the format 1.0?

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Raphael Hertzog]

On Fri, 27 Nov 2009, Thibaut Paumard wrote:
> But the package is unpacked before it can be patched. The patches
> themselves are in debian/patches: when they become available,
> debian/source/options and debian/source/format are available as
> well.

Right, but unpacking should be under control of the unpacker and
not under control of the one who crafted the source package.

So it's still not a good idea. Furthermore I don't see at all
what putting this option in the source package would be used for.
If you don't want the patch system, you don't create patches with it but
creating patches only to not have them applied at unpack time is non-sense
IMO.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Thibaut Paumard]

Le 27 nov. 09 à 14:28, Raphael Hertzog a écrit :


On Fri, 27 Nov 2009, Charles Plessy wrote:
That would be a useful compromise. How about the second half, which  
is to not
patch anything during the unpacking of the package? Maybe this  
could be
combined in a single ‘no-patch’ option, or an alias like ’3.0  
(simple)’?


There's already --skip-patches, but options in debian/source/options  
only
apply at build time obviously (and not at unpack time since that  
file is

not unpacked yet).


But the package is unpacked before it can be patched. The patches  
themselves are in debian/patches: when they become available, debian/ 
source/options and debian/source/format are available as well.


Regards, Thibaut.

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Raphael Hertzog]

On Fri, 27 Nov 2009, Charles Plessy wrote:
> That would be a useful compromise. How about the second half, which is to not
> patch anything during the unpacking of the package? Maybe this could be
> combined in a single ‘no-patch’ option, or an alias like ’3.0 (simple)’?

There's already --skip-patches, but options in debian/source/options only
apply at build time obviously (and not at unpack time since that file is
not unpacked yet).

> Le Thu, Nov 26, 2009 at 12:30:12PM -0800, Russ Allbery a écrit :
> > I can understand not wanting, in the very long run, to support multiple 
> > patch
> > formats.
> 
> Does that mean that the use of options discussed above may become forbidden in
> our archive in the future? If yes, there is little point making concessions 
> now…

I don't understand how you can jump to that conclusion from this
discussion.

Obviously, we don't want to have many formats in the archive and it's best
if "3.0 (quilt)" is flexible enough so that we don't have to invent many
other formats. 

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Charles Plessy]

Le Thu, Nov 26, 2009 at 09:09:45AM +0100, Raphael Hertzog a écrit :
> On Thu, 26 Nov 2009, Charles Plessy wrote:
> > even simpler, an option or a format that would completely ignore what is
> > outside the debian directory:
> 
> That's option "-i.*". As I said I plan to support the -i -I option
> inside debian/source/options just like I recently added support for -z -Z
> there.

That would be a useful compromise. How about the second half, which is to not
patch anything during the unpacking of the package? Maybe this could be
combined in a single ‘no-patch’ option, or an alias like ’3.0 (simple)’?


Le Thu, Nov 26, 2009 at 12:30:12PM -0800, Russ Allbery a écrit :
> I can understand not wanting, in the very long run, to support multiple patch
> formats.

Does that mean that the use of options discussed above may become forbidden in
our archive in the future? If yes, there is little point making concessions now…

The best way to avoid the burden of supporting multiple patch formats in
dpkg-dev is to leave this task to the maintainers.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Brian May]

On Tue, Nov 24, 2009 at 02:02:02AM +0100, Raphael Hertzog wrote:
> >  dpkg-source -b heimdal-1.3.1.dfsg.1
> > dpkg-source: info: using source format `3.0 (quilt)'
> > dpkg-source: warning: patches have not been applied, applying them now (use 
> > --no-preparation to override)
> > dpkg-source: info: applying all patches with quilt push -q 030_autotools
> > Applying patch 011_sharedlibs
> > Applying patch 020_maintainermode
> > Applying patch 021_debian
> > Applying patch 022_openafs
> > Applying patch 024_rxtelnet
> > Applying patch 025_pthreads
> > Applying patch 027_rsh_use_ktelnet
> > Applying patch 030_autotools
> > Now at patch 030_autotools
> > dpkg-source: info: building heimdal using existing 
> > ./heimdal_1.3.1.dfsg.1.orig.tar.gz
> > dpkg-source: error: quilt --quiltrc /dev/null push -q 030_autotools gave 
> > error exit status 1
> > dpkg-buildpackage: error: dpkg-source -b heimdal-1.3.1.dfsg.1 gave error 
> > exit status 2
> 
> You probably have upstream changes that are not under quilt's control
> (they appear in the .diff.gz up to now). And one of your patches
> depends on that change... without it it doesn't apply. Thus the quilt
> series fails to apply on directory with only the upstream tarball
> unpacked.

Just for the record, I think I have a good guess what happened here, basically
the process I used to change to a new upstream source was flawed, and this was
not immediately obvious.

(this is not intended to be read as a complaint, just my general observations)

Anyway, I used uupdate to update to the new source code. I think at the time
there must have been some changes to the source code with respect to the
org.tar.gz I wasn't aware of. uupdate loyally copied these changes to the new
version, and I created a new autotools patch on top of these changes.

Previously, while yucky, this wouldn't be a problem, because the base changes
would get applied first, before the quilt patches get applies.

With the new source code system, my understanding is that the patches get
applied in the opposite order - patches from debian/patches get applied first,
and any extra changes are applied last in the list.

Hence it didn't work, as the autotools patch was based on changes I hadn't
realized were there.

It seems the best way to upgrade to a new upstream version may be to copy the
debian subtree by hand, and ignore uupdate.
-- 
Brian May 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Russ Allbery]

Raphael Hertzog  writes:
> On Wed, 25 Nov 2009, Russ Allbery wrote:

>> I've considered using TopGit to generate a real quilt patch set, but
>> it's kind of complicated and I'm not convinced that the work required
>> to generate the exported patch tree even with TopGit is really worth
>> it.  Given that, for packages currently maintained in Git, 3.0 (quilt)
>> is extra complexity over 1.0 that doesn't seem to be buying me very
>> much.

> Why not generate a single patch then instead of a patch set? If that
> single patch contains an header explaining why it's not split and where
> you can review the changes in a more friendly manner you can have all
> the other features of the new format and yet the the situation improve
> wrt to knowledge/advertisement of our debian-specific changes.

Generating the single patch out of Git is nearly as complex as generating
a patch series if dpkg-source doesn't just do it for me (as it does with
the 1.0 format).  I know 3.0 (quilt) will as well (without any header),
but it doesn't really provide any functionality over 1.0 for this use case
and adds some extra complexity.

However...

> I would be ok to add support for this in "3.0 (quilt)":
> - add an option "--single-debian-patch" that could be set in
>   debian/source/options. With this option dpkg-source would update
>   debian/patches/debian-changes (instead of debian-changes-)
> - support a debian/source/debian-patch-header that would be used
>   as header of the automatic patch (debian/patches/debian-changes in this
>   case)

> How does that sound? (Thanks to mrvn who suggested me the ideas)

...I think this is a really good idea, particularly since I can understand
not wanting, in the very long run, to support multiple patch formats.
Seems like a fairly reasonable approach to me.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[martin f krafft]

also sprach Raphael Hertzog  [2009.11.26.0920 +0100]:
> I would be ok to add support for this in "3.0 (quilt)":
> - add an option "--single-debian-patch" that could be set in
>   debian/source/options. With this option dpkg-source would update
>   debian/patches/debian-changes (instead of debian-changes-)
> - support a debian/source/debian-patch-header that would be used
>   as header of the automatic patch (debian/patches/debian-changes in this
>   case)
> 
> How does that sound? (Thanks to mrvn who suggested me the ideas)

How about implying --single-debian-patch when
debian/source/debian-patch-header exists?

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"a human being should be able to change a diaper, plan an invasion,
 butcher a hog, conn a ship, design a building, write a sonnet,
 balance accounts, build a wall, set a bone, comfort the dying, take
 orders, give orders, cooperate, act alone, solve equations, analyze
 a new problem, pitch manure, program a computer, cook a tasty meal,
 fight efficiently, die gallantly. specialization is for insects."
  -- robert heinlein


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Charles Plessy]

Le Thu, Nov 26, 2009 at 09:09:45AM +0100, Raphael Hertzog a écrit :
> 
> you can end up building a binary package that does not match the source
> package that you upload together with the binary packages.

“You”? Not me. What I upload comes from sbuild.

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Raphael Hertzog]

Hi,

On Wed, 25 Nov 2009, Russ Allbery wrote:
> I've considered using TopGit to generate a real quilt patch set, but
> it's kind of complicated and I'm not convinced that the work required to
> generate the exported patch tree even with TopGit is really worth it.
> Given that, for packages currently maintained in Git, 3.0 (quilt) is
> extra complexity over 1.0 that doesn't seem to be buying me very much.

Why not generate a single patch then instead of a patch set? If that
single patch contains an header explaining why it's not split and
where you can review the changes in a more friendly manner you can
have all the other features of the new format and yet the the situation
improve wrt to knowledge/advertisement of our debian-specific changes.

> It would be nice, however, to have the other features of the 3.0 format
> (including binaries in the debian directory, not shipping the debian
> directory as a patch, using multiple upstream tarballs, using
> bzip2-compressed upstream tarballs) without having the quilt-like patch
> system in play.

Even if quilt supports multiple patches, you are not forced to use
multiple patches. You can get the same than a 1.0 source package with a
single patch that you regenerate each time.

I would be ok to add support for this in "3.0 (quilt)":
- add an option "--single-debian-patch" that could be set in
  debian/source/options. With this option dpkg-source would update
  debian/patches/debian-changes (instead of debian-changes-)
- support a debian/source/debian-patch-header that would be used
  as header of the automatic patch (debian/patches/debian-changes in this
  case)

How does that sound? (Thanks to mrvn who suggested me the ideas)

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Raphael Hertzog]

On Thu, 26 Nov 2009, Charles Plessy wrote:
> even simpler, an option or a format that would completely ignore what is
> outside the debian directory:

That's option "-i.*". As I said I plan to support the -i -I option
inside debian/source/options just like I recently added support for -z -Z
there. But I'm pretty sure that using ".*" as value is a bad idea because
you can end up building a binary package that does not match the source
package that you upload together with the binary packages.

> As it is already the case with Format 1.0 when the maintainer took care of
> having a diff.gz file that only contains files within the debian directory, 
> the
> packaging system would not patch or unpatch the upstream sources, leaving this
> task to the maintainer.

That's still the same here, dpkg-source only comes into play ith its quilt
patch when the upstream files are modified.

If the automatic patch was not versionned, you would always regenerate a
single diff that is exactly like the old .diff.gz. Would that please those
that prefer staying with 1.0 ?

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Russ Allbery]

Raphael Hertzog  writes:
> On Mon, 23 Nov 2009, Joey Hess wrote:

>>> I understand that you do not want to throw away your work on this
>>> patch management system, but by making it optional, I think that you
>>> will actually increase your chances of success…

>> I think that's very wise.

> It is optional already. Just don't make any direct changes to upstream
> files.  What else do you need?

Until we have 3.0 (git), I think I'm going to stick with direct source
modifications to the upstream source and hence with version 1.0.  I've
considered using TopGit to generate a real quilt patch set, but it's kind
of complicated and I'm not convinced that the work required to generate
the exported patch tree even with TopGit is really worth it.  Given that,
for packages currently maintained in Git, 3.0 (quilt) is extra complexity
over 1.0 that doesn't seem to be buying me very much.

It would be nice, however, to have the other features of the 3.0 format
(including binaries in the debian directory, not shipping the debian
directory as a patch, using multiple upstream tarballs, using
bzip2-compressed upstream tarballs) without having the quilt-like patch
system in play.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Charles Plessy]

Le Tue, Nov 24, 2009 at 08:17:17AM +0100, Raphael Hertzog a écrit :
> 
> I can add a new option "--no-debian-patch" that would refuse to create the
> automatic quilt patch debian-changes- and make it fail instead if
> there are upstream changes.

Hi Raphaël,

even simpler, an option or a format that would completely ignore what is
outside the debian directory:

 - When packing a source package, a compressed tar archive would be made from
   the contents of the debian directory.

 - When unpacking a source package, the compressed debian tar archive would be
   unpacked in the upstream sources, after deleting any existing debian
   directory.

As it is already the case with Format 1.0 when the maintainer took care of
having a diff.gz file that only contains files within the debian directory, the
packaging system would not patch or unpatch the upstream sources, leaving this
task to the maintainer.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Goswin von Brederlow]

Raphael Hertzog  writes:

> On Tue, 24 Nov 2009, Goswin von Brederlow wrote:
>> > Bugs as of today.
>> > * Packages with different patch systems like linux-2.6. In this case
>> >   dpkg-source ignores failures to register a patch and produces
>> >   sources without the changes. (#557618)
>> 
>> As discussed on IRC this is a matter of false advertising by the
>> announcement and the wiki. Which also seems to be the main problem
>> Rhonda has with the format.
>
> It's not false advertising. The problem that Bastian saw is that quilt is
> not returning an error when debian/patches/series is not a file. I'm going
> to check for that in the next dpkg version.

In the special case of linux-2.6 that might be a bug. But how will 3.0
(quilt) format then work? So it doesn't go and do something crazy
anymore. Instead it fails. That is not working. And I there were more
examples in the thread like e.g. wesnoth.

>> YOU CAN NOT MIX PATCH SYSTEMS.
>
> You certainly can. It doesn't mean that it's always a good idea though.
> For packages like linux-2.6, it makes sense.
>
> I made some choices to avoid conflicts with other patch systems, in
> particular no .patch or .diff extension to automatic patches so that they
> are not picked up by patch systems like simple-patchsys.
>
> Cheers,
> -- 
> Raphaël Hertzog

If it works it is luck. It only works if the patch system does not
pick up any of the dpkg files and dpkg does not pick up any of the
patch systems files. Which generaly is not the case. Gnerally you have
to do some work to make sure nothing conflicts or to make it not
conflict.

Esspecially the case where the packages patch system is quilt is
tricky as it works if dpkg uses quilt (if quilt is installed before
dpkg-source is called) but not if quilt is pulled in later through
Build-Depends.

So while you can make the two work side by side, if you seperate them
enough, I stand by what I wrote for the general case. Blindly mixing
patch systems spells disaster. The advertising makes it sound like it
will magcially always work.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Raphael Hertzog]

On Tue, 24 Nov 2009, Goswin von Brederlow wrote:
> > Bugs as of today.
> > * Packages with different patch systems like linux-2.6. In this case
> >   dpkg-source ignores failures to register a patch and produces
> >   sources without the changes. (#557618)
> 
> As discussed on IRC this is a matter of false advertising by the
> announcement and the wiki. Which also seems to be the main problem
> Rhonda has with the format.

It's not false advertising. The problem that Bastian saw is that quilt is
not returning an error when debian/patches/series is not a file. I'm going
to check for that in the next dpkg version.

> YOU CAN NOT MIX PATCH SYSTEMS.

You certainly can. It doesn't mean that it's always a good idea though.
For packages like linux-2.6, it makes sense.

I made some choices to avoid conflicts with other patch systems, in
particular no .patch or .diff extension to automatic patches so that they
are not picked up by patch systems like simple-patchsys.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Raphael Hertzog]

On Mon, 23 Nov 2009, Joey Hess wrote:
> > I understand that you do not want to throw away your work on this patch
> > management system, but by making it optional, I think that you will actually
> > increase your chances of success…
> 
> I think that's very wise.

It is optional already. Just don't make any direct changes to upstream files.
What else do you need?

I can add a new option "--no-debian-patch" that would refuse to create the
automatic quilt patch debian-changes- and make it fail instead if
there are upstream changes.

That option can then be put in debian/source/options just like you can put
"compression = bzip2" currently.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Raphael Hertzog]

On Tue, 24 Nov 2009, Robert Collins wrote:
> On Mon, 2009-11-23 at 09:30 +0100, Raphael Hertzog wrote:
> > In the end, I decided to trust nothing and to verify if the first
> > patch can be applied or not. If it can be applied, we assume that the
> > patches have not been applied and we apply them all (unless
> > --no-preparation is given). If quilt is available, instead of checking the
> > first patch, I check the first patch returned by quilt unapplied
> > and apply the remaining of the patches if needed.
> 
> This heuristic is likely to fail - patches that solely add content can
> apply repeatedly without error.

I know, that's why it's called an heuristic (it doesn't get it right 100%
of the cases) and why --no-preparation exists and why it's best to not
allow for any fuzz in that test.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Goswin von Brederlow]

Bastian Blank  writes:

> On Sat, Nov 21, 2009 at 04:54:36PM +0100, Raphael Hertzog wrote:
>> since a few weeks the Debian archive accepts source package using the new
>> formats "3.0 (quilt)" and "3.0 (native)".
>
> I tried "3.0 (quilt)" with several packages today and none worked
> properly, so several large packages will be stuck with "3.0 (native)".
>
> Bugs as of today.
> * Packages with different patch systems like linux-2.6. In this case
>   dpkg-source ignores failures to register a patch and produces
>   sources without the changes. (#557618)

As discussed on IRC this is a matter of false advertising by the
announcement and the wiki. Which also seems to be the main problem
Rhonda has with the format.

YOU CAN NOT MIX PATCH SYSTEMS.

If the package uses a patch system, which might or might not be quilt,
and you declare it 3.0 (quilt) format then dpkg also uses a patch
system, which might or might not be quilt. You then pitch two patch
systems against each other and most likely both will be using
debian/patches/ with, unsurprisingly, catastrophic results.

If you convert to 3.0 (quilt) then remove the patch system from
debian/rules. In extrem cases, like linux-2.6, where that isn't
possible you need to make sure it does not interfere with dpkg. The
simplest way would be to not use debian/patches. Use
debian/kernel-patches/ or something other.

> * The "3.0 (quilt)" format is incompatible with "quilt" by using
>   different patch directories and features. (#557619)

Quilt supports alternative patches directories and series files. It
just isn't verry good at it as it requires QUILT_PATCHES /
QUILT_SERIES to be set correctly every time you work on the source.
The patch in #557623 makes quilt remember where it got its patches and
series file from the first time you use it (e.g. when called from
dpkg-source -x) so it just works out of the box after then.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557623

> * Fuzzy patches leads to silent ignore of the complete patchset.
>   (#557664)
> * Different behaviour between quilt installed/not installed.
> Several others against quilt themself are missing.
>
> The whole thing is super fragile. It is mostly impossible to use both
> "3.0 (quilt)" and quilt themself because you use it to develop.

Yes, a matter of false advertising. Use a different dir for the
packages quilt use.

>>   The last step for us (dpkg
>> maintainers) in this project is to change dpkg-source to use those new
>> formats by default.
>
> I will propose a GR to stop you if you go on until it works properly.
> And yes, this includes packages like linux-2.6, which have to use a more
> sophisticated patch system than quilt.
>
> Or you start and propose a different format that can be mostly like 3.0
> (quilt) for the result (multiple tars) but without the implicit quilt
> constraints.
>
>> However, before we do this we want to ensure that
>> no packages (in sid) will be broken due to this switch and there are
>> quite a few packages left to fix:
>
> You have to add the bugs above.
>
> Bastian

It seems more and more people are against switching and really what is
the point?

Everyone who wants the new format is creating debian/source/format
already. So all you do by switching the default is piss of those
people that are against 3.0 (quilt) format and please no one.

Further packages with patch systems need to be changed to work
reliably with 3.0 (quilt) format, i.e. need to remove the patch system
from debian/rules. Without adding debian/source/format at that time
the packages then don't build as 1.0 format anymore so backporting
breaks. Another large group of people and users pissed at you.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Goswin von Brederlow]

Joey Hess  writes:

> Raphael Hertzog wrote:
>> That's just wrong. I do it without problems by using the .quiltrc
>> snippet from /usr/share/doc/quilt/README.source.
>
> Hmm, that is verging on "beware of the leopard" non-obviousness. I mean,
> you just argued in another mail that such a README.source would soon not
> be necessary.
>
> Perhaps a little wrapper script to run quilt with the right
> QUILT_PATCHES could make this slightly easier.
>
> -- 
> see shy jo

#557623 Quilt should remember where it first got patches and series from

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557623

No more need to set QUILT_PATCHES.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Goswin von Brederlow]

Gerfried Fuchs  writes:

> * Raphael Hertzog  [2009-11-23 09:50:15 CET]:
>> On Mon, 23 Nov 2009, Gerfried Fuchs wrote:
>> >  Actually, I feel rather to convert my packages to 3.0 (native) + quilt.
>> > The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to
>> > me).
>> 
>> Yay for reuploading the full tarball for each revision! I'd rather you
>> keep using 1.0 instead of doing this...
>
>  But 1.0 won't give me orig.tar.bz2 support. And your plan is to kill
> off 1.0 and implicit convert it to 3.0 (quilt) so "keep using 1.0" would
> still mean having to change stuff in the package.
>
>> The automatic patch now features DEP-3 headers by default. The NMUer can
>> rename it and edit the headers easily. If he wants to create one patch
>> per feature, he can simply rebuild the source package after having applied
>> each patch.
>
>  Have you tried rebuilding the source package after having applied a
> patch in wesnoth? Or OpenOffice.org? Or nexuiz-data? Or fillets-ng-data?
> :)
>
>> For each patch:
>>  - apply patch
>>  - dpkg-buildpackage -S
>>  - rename debian/patches/debian-changes- into something else
>>and edit its headers
>>  - fix debian/patches/series
>> 
>> Note: this works only if quilt is not installed (or if you ensure
>> dpkg-source is called with --without-quilt which you currently can't pass
>> via dpkg-buildpackage).
>
>  Ah yes, again different workflows required - so we actually do need a
> README.Source to warn people to not having quilt installed when working
> with 3.0 (quilt) format? This sounds a bit backwards and strange, to be
> honest.

Full ACK. There should be a dpkg-edit-patch, dpkg-rename-patch,
dpkg-import-patch, ... to hide the difference of with or without quilt
if dpkg wants to keep going that way. I suggested something like that
in the past but the dpkg team didn't like it.

Or at a minimum dpkg should catch when a patch was manually renamed
while quilt is used and repair that. I.e. make just renaming work even
with quilt being used. I consider this a bug.

>> It's new, it's just that we haven't developed the toolset around it. I
>> always expected that people would start developing new tools à la
>> devscripts to make it easier for some specific scenario.
>
>  Expecting others to jump the wagon isn't something you should depend
> on, you are well adviced to be ready to do the work yourself in case
> your expectations are over the top. :)
>
>> Well, everything has a learning curve. It's normal to have to learn once.
>> The point of README.source was to document stuff that not all DD are
>> supposed to know. Knowledge of the new source format will be common
>> in the near future.
>
>  Given that there seems to be different workflows needed and required
> depending on what packages one has installed I still see the need for
> that, to be honest ...

Yes, but not in every pakage. At most a link to a file provided by
dpkg.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Manoj Srivastava]

On Mon, Nov 23 2009, Joey Hess wrote:

> Perhaps Raphael in turn was sensing that I didn't have a deep knowledge
> of git -- I had only used it for a month or so at the time. And in fact,
> we now know a much better way to do a git based format. I have been
> considering working on it again, after #554682 is fixed.

I would like to help, especially when it comes to support for
 submodules.

manoj
-- 
Youth had been a habit of hers so long that she could not part with it.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Brian May]

On Tue, Nov 24, 2009 at 02:30:59PM +1100, Brian May wrote:
> Ok, I did the following:

Disregard those results, I screwed up and forgot to cd into the new
working directory after I moved the old one. So it looked OK but
wasn't.

Retry. Hmmm. So far it looks better...
-- 
Brian May 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Norbert Preining]

On So, 22 Nov 2009, Steve Langasek wrote:
> > and as far as I see:
> > clean: unpatch
> 
> Well, the latter is wrong - this breaks if you're patching the build system.

Ah, good to know, but well, my poiint is that this is a bit a PITA
if the system changes again and again. But that has nothing to do with
the source package format (which would alleviate us from thinking about
that ;-)

Best wishes

Norbert

---
Dr. Norbert PreiningAssociate Professor
JAIST Japan Advanced Institute of Science and Technology   prein...@jaist.ac.jp
Vienna University of Technology   prein...@logic.at
Debian Developer (Debian TeX Task Force)prein...@debian.org
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
OSSETT (n.)
A frilly spare-toilet-roll-cosy.
--- Douglas Adams, The Meaning of Liff


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Brian May]

On Tue, Nov 24, 2009 at 02:02:02AM +0100, Raphael Hertzog wrote:
> On Tue, 24 Nov 2009, Brian May wrote:
> > Next problem:
> > 
> > [...]
> >  dpkg-source -b heimdal-1.3.1.dfsg.1
> > dpkg-source: info: using source format `3.0 (quilt)'
> > dpkg-source: warning: patches have not been applied, applying them now (use 
> > --no-preparation to override)
> > dpkg-source: info: applying all patches with quilt push -q 030_autotools
> > Applying patch 011_sharedlibs
> > Applying patch 020_maintainermode
> > Applying patch 021_debian
> > Applying patch 022_openafs
> > Applying patch 024_rxtelnet
> > Applying patch 025_pthreads
> > Applying patch 027_rsh_use_ktelnet
> > Applying patch 030_autotools
> > Now at patch 030_autotools
> > dpkg-source: info: building heimdal using existing 
> > ./heimdal_1.3.1.dfsg.1.orig.tar.gz
> > dpkg-source: error: quilt --quiltrc /dev/null push -q 030_autotools gave 
> > error exit status 1
> > dpkg-buildpackage: error: dpkg-source -b heimdal-1.3.1.dfsg.1 gave error 
> > exit status 2
> 
> You probably have upstream changes that are not under quilt's control
> (they appear in the .diff.gz up to now). And one of your patches
> depends on that change... without it it doesn't apply. Thus the quilt
> series fails to apply on directory with only the upstream tarball
> unpacked.

Ok, I did the following:

1. Extract clean tar ball
2. Copy debian directory from old
3. Ensure all patches are clean and apply
4. run debuild -us -uc -S, which runs dpkg-buildpackage -rfakeroot -d -us -uc -S

=== cut ===
 dpkg-buildpackage -rfakeroot -d -us -uc -S
dpkg-buildpackage: set CFLAGS to default value: -g -O2
dpkg-buildpackage: set CPPFLAGS to default value: 
dpkg-buildpackage: set LDFLAGS to default value: -Wl,-Bsymbolic-functions
dpkg-buildpackage: set FFLAGS to default value: -g -O2
dpkg-buildpackage: set CXXFLAGS to default value: -g -O2
dpkg-buildpackage: source package heimdal
dpkg-buildpackage: source version 1.3.1.dfsg.1-1
dpkg-buildpackage: source changed by Brian May 
 fakeroot debian/rules clean
test -x debian/rules
dh_testroot
/usr/bin/make  -C .  -k distclean
make[1]: Entering directory `/home/brian/tree/heimdal/heimdal-1.3.1.dfsg.1'
make[1]: *** No rule to make target `distclean'.
make[1]: Leaving directory `/home/brian/tree/heimdal/heimdal-1.3.1.dfsg.1'
make: [makefile-clean] Error 2 (ignored)
rm -f debian/stamp-makefile-build
for i in ./config.guess ./config.sub  ; do \
if test -e $i.cdbs-orig ; then \
mv $i.cdbs-orig $i ; \
fi ; \
done
dh_clean 
rm -f debian/stamp-autotools-files
/usr/bin/make -f debian/rules reverse-config
make[1]: Entering directory `/home/brian/tree/heimdal/heimdal-1.3.1.dfsg.1'
for i in ./config.guess ./config.sub  ; do \
if test -e $i.cdbs-orig ; then \
mv $i.cdbs-orig $i ; \
fi ; \
done
make[1]: Leaving directory `/home/brian/tree/heimdal/heimdal-1.3.1.dfsg.1'
if [ -d "." ]; then \
  cd . && 
QUILT_PATCHES=/home/brian/tree/heimdal/heimdal-1.3.1.dfsg.1/debian/patches 
quilt --quiltrc /dev/null pop -a -R || test $? = 2 ; \
fi
Removing patch 027_rsh_use_ktelnet
Restoring appl/rsh/rsh.c
Restoring appl/rsh/rsh.1

Removing patch 025_pthreads
Restoring cf/pthreads.m4

Removing patch 024_rxtelnet
Restoring appl/kx/rxtelnet.in
Restoring appl/kx/rxterm.in

Removing patch 022_openafs
Restoring lib/krb5/keytab_keyfile.c

Removing patch 021_debian
Restoring kdc/kdc.8
Restoring doc/setup.texi
Restoring appl/telnet/telnetd/telnetd.h

Removing patch 020_maintainermode
Restoring configure.in

Removing patch 011_sharedlibs
Restoring tools/krb5-config.in

No patches applied
rm -rf ./.pc
rm -f debian/stamp-patch*
# clean files not cleaned by make file
rm -f appl/rsh/login_access.c
rm -f appl/rsh/rsh.cat1
rm -f include/*.h
rm -f include/kadm5/*.h
rm -f include/version.h.in
rm -f krb5/libkrb5.ver
rm -f lib/com_err/Makefile
rm -f lib/com_err/snprintf.c
rm -f lib/com_err/strlcpy.c
rm -f lib/des/Makefile
rm -f lib/editline/Makefile
rm -f lib/krb5/libkrb5.ver
rm -f lib/otp/snprintf.c
rm -f lib/otp/strcasecmp.c
rm -f lib/otp/strlcat.c
rm -f lib/otp/strlcpy.c
rm -f lib/otp/strlwr.c
rm -f lib/otp/strncasecmp.c
rm -f lib/sl/slc-gram.c
rm -f lib/sl/slc-gram.h
rm -f lib/sl/slc-lex.c
rm -f appl/ftp/ftpd/ftpcmd.c
rm -f lib/otp/ndbm_wrap.c
rm -f lib/otp/ndbm_wrap.h
rm -f lib/wind/*.pyc
rm -f doc/heimdal.info
rm -f lib/hx509/sel-gram.c
rm -f lib/roken/roken-glob.h
 dpkg-source -b heimdal-1.3.1.dfsg.1
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: warning: patches have not been applied, applying them now (use 
--no-preparation to override)
dpkg-source: info: applying all patches with quilt push -q 030_autotools
Applying patch 011_sharedlibs
Applying patch 020_maintainermode
Applying patch 021_debian
Applying patch 022_openafs
Applying patch 024_rxtelnet
Applying patch 025_pthreads
Applying patch 027_rsh_use_ktelnet
Applying patch 030_autotools
9 out of 42 hunks FAILED
Patch 030_autotools does not apply (enforce wi

Re: New source package formats now available

[Joey Hess]

Raphael Hertzog wrote:
> That's just wrong. I do it without problems by using the .quiltrc
> snippet from /usr/share/doc/quilt/README.source.

Hmm, that is verging on "beware of the leopard" non-obviousness. I mean,
you just argued in another mail that such a README.source would soon not
be necessary.

Perhaps a little wrapper script to run quilt with the right
QUILT_PATCHES could make this slightly easier.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: New source package formats now available

[Joey Hess]

Charles Plessy wrote:
> Maybe it is because you never wanted to listen to people who were
> interested to have the debian directory in a tar.gz, without a patch
> system on top of it?
> 
> I answered to your feedback request, realised that you were not going to 
> change
> your mind about format ‘3.0 (quilt)’, and then gave up. How many others?

I didn't work much on 3.0 (git) beyond submission, because I was getting
a definite vibe that Raphael was interested in his quilt format and only
that format.

Perhaps Raphael in turn was sensing that I didn't have a deep knowledge
of git -- I had only used it for a month or so at the time. And in fact,
we now know a much better way to do a git based format. I have been
considering working on it again, after #554682 is fixed.

> I understand that you do not want to throw away your work on this patch
> management system, but by making it optional, I think that you will actually
> increase your chances of success…

I think that's very wise.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: New source package formats now available

[Charles Plessy]

Le Tue, Nov 24, 2009 at 12:32:40AM +0100, Raphael Hertzog a écrit :
> 
> > Or you start and propose a different format that can be mostly like 3.0
> > (quilt) for the result (multiple tars) but without the implicit quilt
> > constraints.
> 
> Not me, no. And people should have requested that 1-2 years ago when we were
> discussing the new formats in -devel.

Maybe it is because you never wanted to listen to people who were interested to
have the debian directory in a tar.gz, without a patch system on top of it?

I answered to your feedback request, realised that you were not going to change
your mind about format ‘3.0 (quilt)’, and then gave up. How many others?

I understand that you do not want to throw away your work on this patch
management system, but by making it optional, I think that you will actually
increase your chances of success…

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Carsten Hey]

On Tue, Nov 24, 2009 at 01:53:34AM +0100, Carsten Hey wrote:
> On Mon, Nov 23, 2009 at 09:50:15AM +0100, Raphael Hertzog wrote:
> > For each patch:
> >  - ...
> >
> > Note: this works only if quilt is not installed (or if you ensure
> > dpkg-source is called with --without-quilt which you currently can't pass
> > via dpkg-buildpackage).
>
> JFTR, is also works with quilt installed, given that you don't rename
> applied patches.
>
> The following shell function automates the required quilt pop/push and
> the adjustment of the series file:
>
> dquilt-rename() {
> ...
> }

Or just use quilt rename instead ;)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Robert Collins]

On Mon, 2009-11-23 at 09:30 +0100, Raphael Hertzog wrote:

> In the end, I decided to trust nothing and to verify if the first
> patch can be applied or not. If it can be applied, we assume that the
> patches have not been applied and we apply them all (unless
> --no-preparation is given). If quilt is available, instead of checking the
> first patch, I check the first patch returned by quilt unapplied
> and apply the remaining of the patches if needed.

This heuristic is likely to fail - patches that solely add content can
apply repeatedly without error.

-Rob


signature.asc
Description: This is a digitally signed message part

Re: New source package formats now available

[Raphael Hertzog]

On Tue, 24 Nov 2009, Brian May wrote:
> Next problem:
> 
> [...]
>  dpkg-source -b heimdal-1.3.1.dfsg.1
> dpkg-source: info: using source format `3.0 (quilt)'
> dpkg-source: warning: patches have not been applied, applying them now (use 
> --no-preparation to override)
> dpkg-source: info: applying all patches with quilt push -q 030_autotools
> Applying patch 011_sharedlibs
> Applying patch 020_maintainermode
> Applying patch 021_debian
> Applying patch 022_openafs
> Applying patch 024_rxtelnet
> Applying patch 025_pthreads
> Applying patch 027_rsh_use_ktelnet
> Applying patch 030_autotools
> Now at patch 030_autotools
> dpkg-source: info: building heimdal using existing 
> ./heimdal_1.3.1.dfsg.1.orig.tar.gz
> dpkg-source: error: quilt --quiltrc /dev/null push -q 030_autotools gave 
> error exit status 1
> dpkg-buildpackage: error: dpkg-source -b heimdal-1.3.1.dfsg.1 gave error exit 
> status 2

You probably have upstream changes that are not under quilt's control
(they appear in the .diff.gz up to now). And one of your patches
depends on that change... without it it doesn't apply. Thus the quilt
series fails to apply on directory with only the upstream tarball
unpacked.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Carsten Hey]

On Mon, Nov 23, 2009 at 09:50:15AM +0100, Raphael Hertzog wrote:
> For each patch:
>  - apply patch
>  - dpkg-buildpackage -S
>  - rename debian/patches/debian-changes- into something else
>and edit its headers
>  - fix debian/patches/series
>
> Note: this works only if quilt is not installed (or if you ensure
> dpkg-source is called with --without-quilt which you currently can't pass
> via dpkg-buildpackage).

JFTR, is also works with quilt installed, given that you don't rename
applied patches.

The following shell function automates the required quilt pop/push and
the adjustment of the series file:

dquilt-rename() {   

 (
source $HOME/.quiltrc;  

 cd "${QUILT_PATCHES:-patches}";

  j=`quilt applied | wc -l`;

   quilt pop -a;

if [ -f "$1" ] && ! [ -f "$2" ]; 
then
mv "$1" "$2";
sed -i "s/^$1\$/$2/" series;
fi;
for i in $(seq $j); do
quilt push || [ $? eq 2 ] || return 1;
done
)
}

I just wrote it and only ran it once, so don't expect it to be mature.
It requires the snippet given in /usr/share/doc/quilt/README.source as
$HOME/.quiltrc.


Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Brian May]

On Mon, Nov 23, 2009 at 04:12:58PM +1100, Brian May wrote:
> Am I doing something wrong?
> 
> sys11:/home/brian/tree/heimdal# lintian heimdal_1.2.e1.dfsg.1-5_i386.changes
> warning: lintian's authors do not recommend running it with root privileges!
> internal error: command failed with error code 25
> warning: could not unpack package to desired level
> warning: skipping check of source package heimdal
> 
> What does error 25 mean?

As I got no response, I submitted bug #557717.

Next problem:

[...]
 dpkg-source -b heimdal-1.3.1.dfsg.1
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: warning: patches have not been applied, applying them now (use 
--no-preparation to override)
dpkg-source: info: applying all patches with quilt push -q 030_autotools
Applying patch 011_sharedlibs
Applying patch 020_maintainermode
Applying patch 021_debian
Applying patch 022_openafs
Applying patch 024_rxtelnet
Applying patch 025_pthreads
Applying patch 027_rsh_use_ktelnet
Applying patch 030_autotools
Now at patch 030_autotools
dpkg-source: info: building heimdal using existing 
./heimdal_1.3.1.dfsg.1.orig.tar.gz
dpkg-source: error: quilt --quiltrc /dev/null push -q 030_autotools gave error 
exit status 1
dpkg-buildpackage: error: dpkg-source -b heimdal-1.3.1.dfsg.1 gave error exit 
status 2
debuild: fatal error at line 1330:
dpkg-buildpackage -rfakeroot -d -us -uc -S failed

-- 
Brian May 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Raphael Hertzog]

On Mon, 23 Nov 2009, Bastian Blank wrote:
> I tried "3.0 (quilt)" with several packages today and none worked
> properly, so several large packages will be stuck with "3.0 (native)".

1.0 is not going away even if we change the default.

> Bugs as of today.

Won't comment here. I have already commented an each individual bugs
and will fix those that make sense.

> The whole thing is super fragile. It is mostly impossible to use both
> "3.0 (quilt)" and quilt themself because you use it to develop.

That's just wrong. I do it without problems by using the .quiltrc
snippet from /usr/share/doc/quilt/README.source.

> I will propose a GR to stop you if you go on until it works properly.

That's always a nice thing to say at the start of a discussion. You have
proven once more that your social skills suck.

> And yes, this includes packages like linux-2.6, which have to use a more
> sophisticated patch system than quilt.

If you avoid the conflict on debian/patches/series being a directory
instead of a file, there's no reason it will be more problematic than
a random package. Just use another directory name and let that file empty
in case someone changes an upstream files without using your custom patch
system.

> Or you start and propose a different format that can be mostly like 3.0
> (quilt) for the result (multiple tars) but without the implicit quilt
> constraints.

Not me, no. And people should have requested that 1-2 years ago when we were
discussing the new formats in -devel.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Bastian Blank]

On Sat, Nov 21, 2009 at 04:54:36PM +0100, Raphael Hertzog wrote:
> since a few weeks the Debian archive accepts source package using the new
> formats "3.0 (quilt)" and "3.0 (native)".

I tried "3.0 (quilt)" with several packages today and none worked
properly, so several large packages will be stuck with "3.0 (native)".

Bugs as of today.
* Packages with different patch systems like linux-2.6. In this case
  dpkg-source ignores failures to register a patch and produces
  sources without the changes. (#557618)
* The "3.0 (quilt)" format is incompatible with "quilt" by using
  different patch directories and features. (#557619)
* Fuzzy patches leads to silent ignore of the complete patchset.
  (#557664)
* Different behaviour between quilt installed/not installed.
Several others against quilt themself are missing.

The whole thing is super fragile. It is mostly impossible to use both
"3.0 (quilt)" and quilt themself because you use it to develop.

>   The last step for us (dpkg
> maintainers) in this project is to change dpkg-source to use those new
> formats by default.

I will propose a GR to stop you if you go on until it works properly.
And yes, this includes packages like linux-2.6, which have to use a more
sophisticated patch system than quilt.

Or you start and propose a different format that can be mostly like 3.0
(quilt) for the result (multiple tars) but without the implicit quilt
constraints.

> However, before we do this we want to ensure that
> no packages (in sid) will be broken due to this switch and there are
> quite a few packages left to fix:

You have to add the bugs above.

Bastian

-- 
Lots of people drink from the wrong bottle sometimes.
-- Edith Keeler, "The City on the Edge of Forever",
   stardate unknown


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Goswin von Brederlow]

Gerfried Fuchs  writes:

> * Goswin von Brederlow  [2009-11-23 09:48:36 CET]:
>> Why do you think that? I can split patches any which way and edit the
>> debian/patches/series to match all completly without quilt.
>
>  How so? I don't find anything in man dpkg or dpkg-source that would
> help with that.

In the section about 3.0 (quilt) the section in Extracting says:

   All patches listed in debian/patches/debian.series or
   debian/patches/series are then applied.

And in Building it says "following the same logic as for the unpack"
and explains a bit more.

Nowhere does it say you can not split, merge, edit patches or the
series file to your likeing.

>> It only becomes simpler with quilt and you would always have it
>> installed. A 3.0 (native) + quilt package would force people to use
>> quilt and result in build failures for anyone missing the fact you use
>> quilt manually instead of 3.0 (quilt) format. There really is no
>> advantage in that.
>
>  ?! What build failures? Can you please elaborate on why would you see
> build failures down that path, anywhere?! There's the advantage in it
> that people actually *do* have quilt installed to work properly with the
> (implied) quilt patches instead of maybe having it not around and still
> are expected to work on the patches.

You unpack the source, edit some file and try to build. Suddenly quilt
fails to apply patches.

Or you unpack, build the package once to check the debian source still
builds cleanly, edit some file and then clean fails to unapply
patches.

Or you know the package uses quilt and you use it. But, since you are
new to quilt, you forget to "quilt add file" before editing and then
you don't know how to fix that again.


Note that with 3.0 (quilt) people are not required to work on the
patches and for an NMU I'm not sure what is better: A change in an
existing patch or a small additional patch on top.

>> >  It is causing troubles for people that are familiar with quilt and
>> > think they will be able to work with quilt with the source package when
>> > they dpkg-source -x it - which unfortunately isn't the case. Only when
>> > quilt is installed, but then, this is getting different results
>> > depending on the environment one has, and I thought this was always one
>> > of the big NO-GOs in Debian that we should avoid - and here we have it
>> > even intentional? Sorry that this doesn't make me (and from what I can
>> > see others too) happy  :/
>> 
>> And as a quilt using person you often have quilt not installed?
>
>  This isn't about me or you but about NMUing people or others you want
> to have working on the package. And the question is trying to distract
> from the issue and not answering the question, sorry.
>
>> Worst case you unpack the source again after installing quilt. So far
>> this only happened to me once. Since then I have quilt installed per
>> default in new chroots ment for compiling.
>
>  Worst case you don't know about it because it is said to not require a
> README.Source anymore and is nowhere really hinted that it will give you
> different results.

As said above. I'm not sure I want them to work on the existing
patches. Esspecially if you have meta infos in them about being send
upstream and so on. It is probably best if an NMUer just gets the
source, edits, builds and sends the automatically created
debian/patches/debian-changes-1.2-3.1 file to the BTS.

>> >  About "you just have to install quilt" - *before* you unpack the
>> > source. If you install it afterwards, you have lost.
>> 
>> So you do want a dpkg-source --quiltify-source to fix this post
>> unpacking instead of manually unpacking the source again?
>
>  I would expect a dpkg-source -x to always result in the same thing, no
> matter wether quilt is installed or not. And when the format claims to
> be (quilt) I expect it to be quilt-ready *by default*. Implementing just
> a subset but calling that subset with the same name is just confusing. :/

Yeah. It annoyed me once and then I added quilt to the list of
packages to be installed in a fresh chroot by default.

How about this solution: dpkg-dev should recommend quilt.
While dpkg-dev works fine without quilt I too believe quilt should
always be installed when 3.0 (quilt) format is supposed to be(come)
the default format. A recommends would install quilt by default but
not require it.

>  So long. :)
> Rhonda

and thanks for all the fish.

Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Mike Hommey]

On Mon, Nov 23, 2009 at 10:10:51AM +0100, Gerfried Fuchs wrote:
> * Raphael Hertzog  [2009-11-23 09:50:15 CET]:
> > On Mon, 23 Nov 2009, Gerfried Fuchs wrote:
> > >  Actually, I feel rather to convert my packages to 3.0 (native) + quilt.
> > > The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to
> > > me).
> > 
> > Yay for reuploading the full tarball for each revision! I'd rather you
> > keep using 1.0 instead of doing this...
> 
>  But 1.0 won't give me orig.tar.bz2 support. And your plan is to kill
> off 1.0 and implicit convert it to 3.0 (quilt) so "keep using 1.0" would
> still mean having to change stuff in the package.
> 
> > The automatic patch now features DEP-3 headers by default. The NMUer can
> > rename it and edit the headers easily. If he wants to create one patch
> > per feature, he can simply rebuild the source package after having applied
> > each patch.
> 
>  Have you tried rebuilding the source package after having applied a
> patch in wesnoth? Or OpenOffice.org? Or nexuiz-data? Or fillets-ng-data?
> :)

Actually, on big packages, the latest dpkg-source is now 5 to 10 times as
fast as the old one. (for any format, for that matter)

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Gerfried Fuchs]

* Raphael Hertzog  [2009-11-23 09:50:15 CET]:
> On Mon, 23 Nov 2009, Gerfried Fuchs wrote:
> >  Actually, I feel rather to convert my packages to 3.0 (native) + quilt.
> > The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to
> > me).
> 
> Yay for reuploading the full tarball for each revision! I'd rather you
> keep using 1.0 instead of doing this...

 But 1.0 won't give me orig.tar.bz2 support. And your plan is to kill
off 1.0 and implicit convert it to 3.0 (quilt) so "keep using 1.0" would
still mean having to change stuff in the package.

> The automatic patch now features DEP-3 headers by default. The NMUer can
> rename it and edit the headers easily. If he wants to create one patch
> per feature, he can simply rebuild the source package after having applied
> each patch.

 Have you tried rebuilding the source package after having applied a
patch in wesnoth? Or OpenOffice.org? Or nexuiz-data? Or fillets-ng-data?
:)

> For each patch:
>  - apply patch
>  - dpkg-buildpackage -S
>  - rename debian/patches/debian-changes- into something else
>and edit its headers
>  - fix debian/patches/series
> 
> Note: this works only if quilt is not installed (or if you ensure
> dpkg-source is called with --without-quilt which you currently can't pass
> via dpkg-buildpackage).

 Ah yes, again different workflows required - so we actually do need a
README.Source to warn people to not having quilt installed when working
with 3.0 (quilt) format? This sounds a bit backwards and strange, to be
honest.

> It's new, it's just that we haven't developed the toolset around it. I
> always expected that people would start developing new tools à la
> devscripts to make it easier for some specific scenario.

 Expecting others to jump the wagon isn't something you should depend
on, you are well adviced to be ready to do the work yourself in case
your expectations are over the top. :)

> Well, everything has a learning curve. It's normal to have to learn once.
> The point of README.source was to document stuff that not all DD are
> supposed to know. Knowledge of the new source format will be common
> in the near future.

 Given that there seems to be different workflows needed and required
depending on what packages one has installed I still see the need for
that, to be honest ...

> Well, people familiar with quilt have it already installed. And most
> packages are built out of VCS with patches un-applied so it doesn't even
> matter in most cases.

 That's unfortunately still evading the problem at hand. dpkg-source
isn't giving well-defined results, it acts differently with different
stuff installed. :/

> I have nothing against adding quilt to dependencies of dpkg-dev but I can
> tell that I will get the same number of grumbles from other people equally
> unhappy with that choice.

 Wouldn't it be possible to make dpkg able to create the .pc directory
with the stuff quilt needs to know? That would produce a well-defined
result and not different results on different systems.

 So long!
Rhonda


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Mike Hommey]

On Mon, Nov 23, 2009 at 09:30:00AM +0100, Raphael Hertzog wrote:
> On Mon, 23 Nov 2009, Goswin von Brederlow wrote:
> > > Well, they can drop the patch in debian/patches, and add it to
> > > the end of debian/patches/series. If quilt is installed, it should
> > > work as dpkg-source will use quilt applied to know
> > > whether patches needs to be applied. If quilt is not installed, it assumes
> > > all patches are applied, so you should also apply the patch.
> > 
> > Are you sure about that?
> 
> Yes.
> 
> > dpkg creates a debian/patches/dpkg-applied-patches file listing the
> > patches it has applied. It should notice when the series file has more
> > patches than were applied and remedy the situation.
> 
> It was partly the goal when I created this file but it simply creates
> more problems than it solves. You can't be sure that this file really
> corresponds to the current state of the tree, it's created at unpack time
> but it's not maintained over time when you rebuild.
> 
> In the end, I decided to trust nothing and to verify if the first
> patch can be applied or not. If it can be applied, we assume that the
> patches have not been applied and we apply them all (unless
> --no-preparation is given). If quilt is available, instead of checking the
> first patch, I check the first patch returned by quilt unapplied
> and apply the remaining of the patches if needed.

The more I read your mails in this thread, the more I think you should
dump the part that doesn't require quilt, and make dpkg-dev depend on
quilt.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Gerfried Fuchs]

* Goswin von Brederlow  [2009-11-23 09:48:36 CET]:
> Why do you think that? I can split patches any which way and edit the
> debian/patches/series to match all completly without quilt.

 How so? I don't find anything in man dpkg or dpkg-source that would
help with that.

> It only becomes simpler with quilt and you would always have it
> installed. A 3.0 (native) + quilt package would force people to use
> quilt and result in build failures for anyone missing the fact you use
> quilt manually instead of 3.0 (quilt) format. There really is no
> advantage in that.

 ?! What build failures? Can you please elaborate on why would you see
build failures down that path, anywhere?! There's the advantage in it
that people actually *do* have quilt installed to work properly with the
(implied) quilt patches instead of maybe having it not around and still
are expected to work on the patches.

> >  It is causing troubles for people that are familiar with quilt and
> > think they will be able to work with quilt with the source package when
> > they dpkg-source -x it - which unfortunately isn't the case. Only when
> > quilt is installed, but then, this is getting different results
> > depending on the environment one has, and I thought this was always one
> > of the big NO-GOs in Debian that we should avoid - and here we have it
> > even intentional? Sorry that this doesn't make me (and from what I can
> > see others too) happy  :/
> 
> And as a quilt using person you often have quilt not installed?

 This isn't about me or you but about NMUing people or others you want
to have working on the package. And the question is trying to distract
from the issue and not answering the question, sorry.

> Worst case you unpack the source again after installing quilt. So far
> this only happened to me once. Since then I have quilt installed per
> default in new chroots ment for compiling.

 Worst case you don't know about it because it is said to not require a
README.Source anymore and is nowhere really hinted that it will give you
different results.

> >  About "you just have to install quilt" - *before* you unpack the
> > source. If you install it afterwards, you have lost.
> 
> So you do want a dpkg-source --quiltify-source to fix this post
> unpacking instead of manually unpacking the source again?

 I would expect a dpkg-source -x to always result in the same thing, no
matter wether quilt is installed or not. And when the format claims to
be (quilt) I expect it to be quilt-ready *by default*. Implementing just
a subset but calling that subset with the same name is just confusing. :/

 So long. :)
Rhonda


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Raphael Hertzog]

On Mon, 23 Nov 2009, Gerfried Fuchs wrote:
>  Actually, I feel rather to convert my packages to 3.0 (native) + quilt.
> The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to
> me).

Yay for reuploading the full tarball for each revision! I'd rather you
keep using 1.0 instead of doing this...

>  If you want to really make proper use of it (like seperating into
> feature patches instead of one per upload) you need to have quilt
> installed anyway, and speaking of NMUs, people that just download the
> source, patch and upload will produce low-standard patches, most
> probably not following the DEP3 because dpkg with 3.0 (quilt) doesn't
> really offer what quilt offers. It feels a bit like the regression that
> svn brought on top of cvs with taking away the posibility to tag
> properly (but create tag-branches instead).

The automatic patch now features DEP-3 headers by default. The NMUer can
rename it and edit the headers easily. If he wants to create one patch
per feature, he can simply rebuild the source package after having applied
each patch.

For each patch:
 - apply patch
 - dpkg-buildpackage -S
 - rename debian/patches/debian-changes- into something else
   and edit its headers
 - fix debian/patches/series

Note: this works only if quilt is not installed (or if you ensure
dpkg-source is called with --without-quilt which you currently can't pass
via dpkg-buildpackage).

I would certainly prefer using quilt directly but it's not required
if you don't have it installed.

>  3.0 (quilt) looks like a good idea, but it's still rough at the edges
> somehow. :/  And about not needing a README.Source for it, I don't see

It's new, it's just that we haven't developed the toolset around it. I
always expected that people would start developing new tools à la
devscripts to make it easier for some specific scenario.

And I'm including improvements that make sense based on the feedback that
I get.

> that because otherwise we wouldn't have the need for discussions like
> that, especially if we want to have proper DEP3 tagged patches. :)

Well, everything has a learning curve. It's normal to have to learn once.
The point of README.source was to document stuff that not all DD are
supposed to know. Knowledge of the new source format will be common
in the near future.

>  It is causing troubles for people that are familiar with quilt and
> think they will be able to work with quilt with the source package when
> they dpkg-source -x it - which unfortunately isn't the case. Only when
> quilt is installed, but then, this is getting different results
> depending on the environment one has, and I thought this was always one
> of the big NO-GOs in Debian that we should avoid - and here we have it
> even intentional? Sorry that this doesn't make me (and from what I can
> see others too) happy  :/

Well, people familiar with quilt have it already installed. And most
packages are built out of VCS with patches un-applied so it doesn't even
matter in most cases.

I have nothing against adding quilt to dependencies of dpkg-dev but I can
tell that I will get the same number of grumbles from other people equally
unhappy with that choice.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Goswin von Brederlow]

Gerfried Fuchs  writes:

>   Hi! :)
>
> * Raphael Hertzog  [2009-11-22 10:48:14 CET]:
>> > Note that the squeeze release goal only talks about 3.0 (quilt), not 3.0
>> > (native), which kind of suggests 3.0 (quilt) is being forced down.
>> > That's maybe not what you are thinking, but it's how it feels.
>> 
>> Well, the combination 3.0 (quilt) + 3.0 (native) offers the same range of
>> choice as 1.0 alone in a more explicit manner. 3.0 (native) is for native
>> packages and 3.0 (quilt) is for all the other who have an upstream tarball
>> + a debian dir.
>
>  Actually, I feel rather to convert my packages to 3.0 (native) + quilt.
> The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to
> me).
>
>  If you want to really make proper use of it (like seperating into
> feature patches instead of one per upload) you need to have quilt
> installed anyway, and speaking of NMUs, people that just download the
> source, patch and upload will produce low-standard patches, most
> probably not following the DEP3 because dpkg with 3.0 (quilt) doesn't
> really offer what quilt offers. It feels a bit like the regression that
> svn brought on top of cvs with taking away the posibility to tag
> properly (but create tag-branches instead).

Why do you think that? I can split patches any which way and edit the
debian/patches/series to match all completly without quilt. It only
becomes simpler with quilt and you would always have it installed. A
3.0 (native) + quilt package would force people to use quilt and
result in build failures for anyone missing the fact you use quilt
manually instead of 3.0 (quilt) format. There really is no advantage
in that.

>  3.0 (quilt) looks like a good idea, but it's still rough at the edges
> somehow. :/  And about not needing a README.Source for it, I don't see
> that because otherwise we wouldn't have the need for discussions like
> that, especially if we want to have proper DEP3 tagged patches. :)

Improvements are always welcome.

>> > OTOH, "dpkg-source -x" should result in the same tree (including the .pc
>> > directory), whatever the status of quilt installation is on the system.
>> > Or if that is not possible without quilt, then dpkg-dev should depend on
>> > quilt.
>> 
>> I don't agree with that statement. dpkg-source implements a subset of
>> quilt to work without that tool installed, that subset defines the
>> interface of the source package and it does not include the .pc directory
>> in the general case. If you want that part which is internal to quilt
>> itself, you just have to install quilt.
>
>  It is causing troubles for people that are familiar with quilt and
> think they will be able to work with quilt with the source package when
> they dpkg-source -x it - which unfortunately isn't the case. Only when
> quilt is installed, but then, this is getting different results
> depending on the environment one has, and I thought this was always one
> of the big NO-GOs in Debian that we should avoid - and here we have it
> even intentional? Sorry that this doesn't make me (and from what I can
> see others too) happy  :/

And as a quilt using person you often have quilt not installed? Worst
case you unpack the source again after installing quilt. So far this
only happened to me once. Since then I have quilt installed per
default in new chroots ment for compiling.

>  About "you just have to install quilt" - *before* you unpack the
> source. If you install it afterwards, you have lost.

So you do want a dpkg-source --quiltify-source to fix this post
unpacking instead of manually unpacking the source again?

Maybe dpkg could note if a package was specifically unpacked without
quilt and otherwise quiltify the source during build when quilt
happens to be available now.

>  So long, and thanks. :)
> Rhonda

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Raphael Hertzog]

On Mon, 23 Nov 2009, Goswin von Brederlow wrote:
> > Well, they can drop the patch in debian/patches, and add it to
> > the end of debian/patches/series. If quilt is installed, it should
> > work as dpkg-source will use quilt applied to know
> > whether patches needs to be applied. If quilt is not installed, it assumes
> > all patches are applied, so you should also apply the patch.
> 
> Are you sure about that?

Yes.

> dpkg creates a debian/patches/dpkg-applied-patches file listing the
> patches it has applied. It should notice when the series file has more
> patches than were applied and remedy the situation.

It was partly the goal when I created this file but it simply creates
more problems than it solves. You can't be sure that this file really
corresponds to the current state of the tree, it's created at unpack time
but it's not maintained over time when you rebuild.

In the end, I decided to trust nothing and to verify if the first
patch can be applied or not. If it can be applied, we assume that the
patches have not been applied and we apply them all (unless
--no-preparation is given). If quilt is available, instead of checking the
first patch, I check the first patch returned by quilt unapplied
and apply the remaining of the patches if needed.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Gerfried Fuchs]

Hi! :)

* Raphael Hertzog  [2009-11-22 10:48:14 CET]:
> > Note that the squeeze release goal only talks about 3.0 (quilt), not 3.0
> > (native), which kind of suggests 3.0 (quilt) is being forced down.
> > That's maybe not what you are thinking, but it's how it feels.
> 
> Well, the combination 3.0 (quilt) + 3.0 (native) offers the same range of
> choice as 1.0 alone in a more explicit manner. 3.0 (native) is for native
> packages and 3.0 (quilt) is for all the other who have an upstream tarball
> + a debian dir.

 Actually, I feel rather to convert my packages to 3.0 (native) + quilt.
The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to
me).

 If you want to really make proper use of it (like seperating into
feature patches instead of one per upload) you need to have quilt
installed anyway, and speaking of NMUs, people that just download the
source, patch and upload will produce low-standard patches, most
probably not following the DEP3 because dpkg with 3.0 (quilt) doesn't
really offer what quilt offers. It feels a bit like the regression that
svn brought on top of cvs with taking away the posibility to tag
properly (but create tag-branches instead).

 3.0 (quilt) looks like a good idea, but it's still rough at the edges
somehow. :/  And about not needing a README.Source for it, I don't see
that because otherwise we wouldn't have the need for discussions like
that, especially if we want to have proper DEP3 tagged patches. :)

> > OTOH, "dpkg-source -x" should result in the same tree (including the .pc
> > directory), whatever the status of quilt installation is on the system.
> > Or if that is not possible without quilt, then dpkg-dev should depend on
> > quilt.
> 
> I don't agree with that statement. dpkg-source implements a subset of
> quilt to work without that tool installed, that subset defines the
> interface of the source package and it does not include the .pc directory
> in the general case. If you want that part which is internal to quilt
> itself, you just have to install quilt.

 It is causing troubles for people that are familiar with quilt and
think they will be able to work with quilt with the source package when
they dpkg-source -x it - which unfortunately isn't the case. Only when
quilt is installed, but then, this is getting different results
depending on the environment one has, and I thought this was always one
of the big NO-GOs in Debian that we should avoid - and here we have it
even intentional? Sorry that this doesn't make me (and from what I can
see others too) happy  :/

 About "you just have to install quilt" - *before* you unpack the
source. If you install it afterwards, you have lost.

 So long, and thanks. :)
Rhonda


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Goswin von Brederlow]

Mike Hommey  writes:

> On Sun, Nov 22, 2009 at 11:30:45AM +0100, Raphael Hertzog wrote:
>> On Sun, 22 Nov 2009, Mike Hommey wrote:
>> > On Sun, Nov 22, 2009 at 10:48:14AM +0100, Raphael Hertzog wrote:
>> > > Because you want the patch to be clearly identified and to carry its
>> > > meta-information. Or because maybe you're applying 2 separate patches in
>> > > the same NMU upload.
>> > 
>> > "Fixing cosmetic issues or changing the packaging style in NMUs is
>> > discouraged."
>> > 
>> > Adding a patching system is surely changing the packaging style.
>> 
>> Exactly, that is why 1.0 is less NMU-friendly than 3.0 (quilt)... you
>> can't do the right thing in a NMU, either you break the above rule or
>> you have to meld patches in the .diff.gz with no other information
>> than what you put in the changelog.
>
> No, you don't have to "meld patches in the .diff.gz", you just do your
> changes, put an entry in debian/changelog and do dpkg-source -b. Nothing
> more. It's actually much more NMU-friendly than having to deal with a
> patch system.
>
> OTOH, 3.0 (quilt) is a patch system without being one, so it is a bit
> less pain. But it is not more NMU-friendly than plain 1.0. It is more
> NMU-friendly than 1.0 + patch system, though.
>
> Mike

More friendly to the reciever of the NMU (maintainer) as the change
will be nicely sperated in debian/patches. At no cost to the NMUer if
he doesn't want to use quilt.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Goswin von Brederlow]

Mike Hommey  writes:

> On Sun, Nov 22, 2009 at 10:48:14AM +0100, Raphael Hertzog wrote:
>> Because you want the patch to be clearly identified and to carry its
>> meta-information. Or because maybe you're applying 2 separate patches in
>> the same NMU upload.
>
> "Fixing cosmetic issues or changing the packaging style in NMUs is
> discouraged."
>
> Adding a patching system is surely changing the packaging style.
>
>> > OTOH, "dpkg-source -x" should result in the same tree (including the .pc
>> > directory), whatever the status of quilt installation is on the system.
>> > Or if that is not possible without quilt, then dpkg-dev should depend on
>> > quilt.
>> 
>> I don't agree with that statement. dpkg-source implements a subset of
>> quilt to work without that tool installed, that subset defines the
>> interface of the source package and it does not include the .pc directory
>> in the general case. If you want that part which is internal to quilt
>> itself, you just have to install quilt.
>
> My point is : dpkg-source -x should be idempotent, whatever other
> packages are installed when you do it. The fact that you can't
> dpkg-source -x, and *then* install quilt to manage the patches is a
> nuisance.
>
> Mike

There could be a simple call to dpkg to "quiltify" the source. But
what it comes down to is to unpack the orig, apply patches witzh quilt
and then copy over the .pc directory.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Goswin von Brederlow]

Raphael Hertzog  writes:

> Hi,
>
> On Sat, 21 Nov 2009, Mike Hommey wrote:
>>  The modifications are implied, but it means that the source format is
>> already this "heavy modification", on a similarly heavy modification
>> scale. Additionally, if someone wants to sepearte the patches into
>> feature-patches instead of one-modification-patch-per-upload they will
>> have to additionally pull in quilt anyway to work on it properly,
>
> Well, they can drop the patch in debian/patches, and add it to
> the end of debian/patches/series. If quilt is installed, it should
> work as dpkg-source will use quilt applied to know
> whether patches needs to be applied. If quilt is not installed, it assumes
> all patches are applied, so you should also apply the patch.

Are you sure about that? dpkg creates a
debian/patches/dpkg-applied-patches file listing the patches it has
applied. It should notice when the series file has more patches than
were applied and remedy the situation.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Brian May]

On Sat, Nov 21, 2009 at 04:54:36PM +0100, Raphael Hertzog wrote:
> You need to put "3.0 (quilt)" or "3.0 (native)" in debian/source/format to
> indicate the desired format to dpkg-source (see the dpkg-source(1) manual
> page for more information).

Am I doing something wrong?

sys11:/home/brian/tree/heimdal# lintian heimdal_1.2.e1.dfsg.1-5_i386.changes
warning: lintian's authors do not recommend running it with root privileges!
internal error: command failed with error code 25
warning: could not unpack package to desired level
warning: skipping check of source package heimdal

What does error 25 mean?
-- 
Brian May 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Mike Hommey]

On Sun, Nov 22, 2009 at 11:30:45AM +0100, Raphael Hertzog wrote:
> On Sun, 22 Nov 2009, Mike Hommey wrote:
> > On Sun, Nov 22, 2009 at 10:48:14AM +0100, Raphael Hertzog wrote:
> > > Because you want the patch to be clearly identified and to carry its
> > > meta-information. Or because maybe you're applying 2 separate patches in
> > > the same NMU upload.
> > 
> > "Fixing cosmetic issues or changing the packaging style in NMUs is
> > discouraged."
> > 
> > Adding a patching system is surely changing the packaging style.
> 
> Exactly, that is why 1.0 is less NMU-friendly than 3.0 (quilt)... you
> can't do the right thing in a NMU, either you break the above rule or
> you have to meld patches in the .diff.gz with no other information
> than what you put in the changelog.

No, you don't have to "meld patches in the .diff.gz", you just do your
changes, put an entry in debian/changelog and do dpkg-source -b. Nothing
more. It's actually much more NMU-friendly than having to deal with a
patch system.

OTOH, 3.0 (quilt) is a patch system without being one, so it is a bit
less pain. But it is not more NMU-friendly than plain 1.0. It is more
NMU-friendly than 1.0 + patch system, though.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Henrique de Moraes Holschuh]

On Sun, 22 Nov 2009, Raphael Hertzog wrote:
> On Sun, 22 Nov 2009, Mike Hommey wrote:
> > My point is : dpkg-source -x should be idempotent, whatever other
> > packages are installed when you do it. The fact that you can't
> > dpkg-source -x, and *then* install quilt to manage the patches is a
> > nuisance.
> 
> It's a minor one, yes. But it should happen only once... the next time
> will be still be installed. And since quilt is not needed during a simple
> build, I don't see the need to add it the dependencies of dpkg-dev.

The principle of least surprise is a damn good reason to add that
dependency.

We don't need any extra aggravation right now, especially not related to the
3.0 format.  Please add the dependency.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Raphael Hertzog]

On Sun, 22 Nov 2009, Charles Plessy wrote:
> Also, as a side comment, I would like to add that the “NMU workflow” often
> advertised on this list completely ignores that a large number of packages are
> stored in a VCS where all DDs have write acceess. Uploading a package with an
> anonymous and monolithic patch puts an additional load on the maintainer's 
> work,
> which contradicts the goal of a NMU, to help a busy maintainer. 

Well, IMO, the VCS helper tool should have a tool to import an NMU.
git-buildpackage has git-import-dsc for example.

> The formats ‘2.0’ and ‘3.0 (variant)’ bring a lot of nice improvements, like
> the use of multiple tarballs, different compression systems, and having the
> debian directory in a single tarball, which removes the need of uuencoding
> binary documents. I would welcome a variant that leaves the patch system in 
> the
> hands of the maintainer. It would simplify our work by removing the need to
> fight against the modifications introduced by runing the autotools, which 
> would
> be simply ignored instead of being turned into an useless patch. And it would
> also open a way to unify with the VCS-based formats.

You're fighting the wrong target here, your clean rules should bring the
package in a clean state again.

However, we have debian/source/options now to pass default options to
dpkg-source, we can certainly add more options to change the default set
of ignored files (-i command line option currently) so that you don't end
up with a supplementary patch in that case.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Charles Plessy]

Le Sat, Nov 21, 2009 at 08:51:51PM +0100, Raphael Hertzog a écrit :
> 
> Currently a package without a patch system needs heavy modifications in
> debian/rules to setup the patch system. So when you want to add a patch in
> debian/patches and not in the .diff.gz, you have to choose a patch system
> in place of the maintainer.

That sounds like an artificial situation to me. Either the maintainer is active
and a patch system can be agreed with him, or the maintainer is MIA and the
package should be hijacked, orphaned, or removed. It is more work than just 
doing
a NMU, but it fixes the real problem, which is not the bug itself but the 
absence
of a maintainer to deal with it.

Also, as a side comment, I would like to add that the “NMU workflow” often
advertised on this list completely ignores that a large number of packages are
stored in a VCS where all DDs have write acceess. Uploading a package with an
anonymous and monolithic patch puts an additional load on the maintainer's work,
which contradicts the goal of a NMU, to help a busy maintainer. 

The formats ‘2.0’ and ‘3.0 (variant)’ bring a lot of nice improvements, like
the use of multiple tarballs, different compression systems, and having the
debian directory in a single tarball, which removes the need of uuencoding
binary documents. I would welcome a variant that leaves the patch system in the
hands of the maintainer. It would simplify our work by removing the need to
fight against the modifications introduced by runing the autotools, which would
be simply ignored instead of being turned into an useless patch. And it would
also open a way to unify with the VCS-based formats.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Raphael Hertzog]

On Sun, 22 Nov 2009, Mike Hommey wrote:
> On Sun, Nov 22, 2009 at 10:48:14AM +0100, Raphael Hertzog wrote:
> > Because you want the patch to be clearly identified and to carry its
> > meta-information. Or because maybe you're applying 2 separate patches in
> > the same NMU upload.
> 
> "Fixing cosmetic issues or changing the packaging style in NMUs is
> discouraged."
> 
> Adding a patching system is surely changing the packaging style.

Exactly, that is why 1.0 is less NMU-friendly than 3.0 (quilt)... you
can't do the right thing in a NMU, either you break the above rule or
you have to meld patches in the .diff.gz with no other information
than what you put in the changelog.

> My point is : dpkg-source -x should be idempotent, whatever other
> packages are installed when you do it. The fact that you can't
> dpkg-source -x, and *then* install quilt to manage the patches is a
> nuisance.

It's a minor one, yes. But it should happen only once... the next time
will be still be installed. And since quilt is not needed during a simple
build, I don't see the need to add it the dependencies of dpkg-dev.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Mike Hommey]

On Sun, Nov 22, 2009 at 10:48:14AM +0100, Raphael Hertzog wrote:
> Because you want the patch to be clearly identified and to carry its
> meta-information. Or because maybe you're applying 2 separate patches in
> the same NMU upload.

"Fixing cosmetic issues or changing the packaging style in NMUs is
discouraged."

Adding a patching system is surely changing the packaging style.

> > OTOH, "dpkg-source -x" should result in the same tree (including the .pc
> > directory), whatever the status of quilt installation is on the system.
> > Or if that is not possible without quilt, then dpkg-dev should depend on
> > quilt.
> 
> I don't agree with that statement. dpkg-source implements a subset of
> quilt to work without that tool installed, that subset defines the
> interface of the source package and it does not include the .pc directory
> in the general case. If you want that part which is internal to quilt
> itself, you just have to install quilt.

My point is : dpkg-source -x should be idempotent, whatever other
packages are installed when you do it. The fact that you can't
dpkg-source -x, and *then* install quilt to manage the patches is a
nuisance.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Raphael Hertzog]

Hi,

On Sat, 21 Nov 2009, Mike Hommey wrote:
> On Sat, Nov 21, 2009 at 08:51:51PM +0100, Raphael Hertzog wrote:
> > Currently a package without a patch system needs heavy modifications in
> > debian/rules to setup the patch system. So when you want to add a patch in
> > debian/patches and not in the .diff.gz, you have to choose a patch system
> > in place of the maintainer.
> 
> If there is no patch system when you are NMUing, why would you want to
> add one ?

Because you want the patch to be clearly identified and to carry its
meta-information. Or because maybe you're applying 2 separate patches in
the same NMU upload.

> > We're not forcing anyone, we make it easier for people to use that patch
> > system and we explain why we think it's a wise choice to consider quilt
> > as the default patch system to use when you don't have any specific reason
> > to pick one over the other.
> 
> Note that the squeeze release goal only talks about 3.0 (quilt), not 3.0
> (native), which kind of suggests 3.0 (quilt) is being forced down.
> That's maybe not what you are thinking, but it's how it feels.

Well, the combination 3.0 (quilt) + 3.0 (native) offers the same range of
choice as 1.0 alone in a more explicit manner. 3.0 (native) is for native
packages and 3.0 (quilt) is for all the other who have an upstream tarball
+ a debian dir.

The release goal is only about 3.0 (quilt) because switching from a native
source package in format 1.0 to 3.0 (native) will always work and thus
requires no preparation work.

> OTOH, "dpkg-source -x" should result in the same tree (including the .pc
> directory), whatever the status of quilt installation is on the system.
> Or if that is not possible without quilt, then dpkg-dev should depend on
> quilt.

I don't agree with that statement. dpkg-source implements a subset of
quilt to work without that tool installed, that subset defines the
interface of the source package and it does not include the .pc directory
in the general case. If you want that part which is internal to quilt
itself, you just have to install quilt.

On Sat, 21 Nov 2009, Gerfried Fuchs wrote:
> > Currently a package without a patch system needs heavy modifications in
> > debian/rules to setup the patch system. So when you want to add a patch in
> > debian/patches and not in the .diff.gz, you have to choose a patch system
> > in place of the maintainer.
> 
>  Heavy modification? What's so heavy on three entries there?

Don't be blocked on the heavy, it will of course depends on how the
package was built (CDBS, debhelper, dh7, hand-crafted). The point is that
you have to choose a patch system in place of the maintainer. You add a
quilt build-depends and associated changes when he uses CDBS and would
have preferred simple-patchsys.

>  Sorry, but these additions are next to nowhere "heavy modifications",
> that's a bit over overrating, to say the least.

Agreed, sorry.

>  The modifications are implied, but it means that the source format is
> already this "heavy modification", on a similarly heavy modification
> scale. Additionally, if someone wants to sepearte the patches into
> feature-patches instead of one-modification-patch-per-upload they will
> have to additionally pull in quilt anyway to work on it properly,

Well, they can drop the patch in debian/patches, and add it to
the end of debian/patches/series. If quilt is installed, it should
work as dpkg-source will use quilt applied to know
whether patches needs to be applied. If quilt is not installed, it assumes
all patches are applied, so you should also apply the patch.

>  Alright, thanks for explaining the issue - so for the time, what do you
> suggest? Remove the quilt handling?

Yes, there's no reason to keep it.

> Actually ignore the error that quilt gives (like you suggested on IRC)?

No, I did not suggest that. I was confused on why you saw the failure and
first thought that it was misusage of quilt.

> Or wait until the sbuild fix is applied everywhere?

No, by experience that would mean to wait for quite long, despite the
efforts of the wanna-build maintainers to get buildd maintainers to update
their buildd.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Raphael Hertzog]

Hi,

On Sun, 22 Nov 2009, Olivier Berger wrote:
> Maybe that's very explicit for eveyone, but I couldn't find any
> explenation for regular humans of what "quilt" is (ok, I think I have a
> clue, but remember not all newcomers may be familiar with it for
> instance), and then what the difference are between "native" and "quilt"
> formats in the page abobe.

The difference is explained in the dpkg-source manual page, if you feel
like a short introduction would be good on the above page, please write
one, I'll improve it if needed (I'm subscribed to changes on the wiki
page). 

Thanks for your help! ;-)

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Olivier Berger]

Hi.

Le samedi 21 novembre 2009 à 16:54 +0100, Raphael Hertzog a écrit :
> Hello,
> 

> We have collected some question/answers from early adopters in
> the dedicated wiki page, the most important information is pasted
> below. We hope you will find it helpful to convert your own packages.
> http://wiki.debian.org/Projects/DebSrc3.0#FAQ
> 

Maybe that's very explicit for eveyone, but I couldn't find any
explenation for regular humans of what "quilt" is (ok, I think I have a
clue, but remember not all newcomers may be familiar with it for
instance), and then what the difference are between "native" and "quilt"
formats in the page abobe.

As this was a general announcements, maybe recapping these background
facts would have helped.

Sorry if I'm the only one who thinks that this wasn't really obvious for
all concerned parties.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Steve Langasek]

On Sun, Nov 22, 2009 at 01:16:47AM +0100, Norbert Preining wrote:
> Besides that that snippet is broken? It made me nuts that quilt people
> are changing that snippet and breaking many packages, like all of mine.
> It should be:

> build-stamp: $(QUILT_STAMPFN)
>   ...

> and as far as I see:
> clean: unpatch

Well, the latter is wrong - this breaks if you're patching the build system.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: New source package formats now available

[Goswin von Brederlow]

Gerfried Fuchs  writes:

>   Hi!
>
>  Some few comments.
>
> * Raphael Hertzog  [2009-11-21 16:54:36 CET]:
>>  * even if you don't have any upstream patch right now, next time that
>>someone must NMU your package, they can cleanly add a patch (with a
>>proper DEP-3 header) without having to modify the build system
>
>  This is nothing new for the 3.0 (quilt) format, this is a reason for
> any patch system format, so this feels a bit like false-advertising,
> sorry. Don't get me wrong, I use quilt where I have to touch upstream
> sources myself and totally like it, I just don't see the need to use
> this as advertising for the 3.0 format because that doesn't buy you much
> more in that respect.

The BIG difference is that you (as NMUer) can just

apt-get source foo
cd foo*/
dch -i
$EDITOR file
debuild

and a new patch will be created automatically. You work on the source
as if there is no patch system involved and it will do the right
thing. If you do happen to know about quilt and the package already
has patches you can take advantage of quilt features. You can edit
patches or annotate files to find the guilty patch and so on. But if
you don't know or don't like quilt you can also totaly ignore it.

So what you get is a free (as in nothing needs to be in debian/rules
or Build-Depends) patch system that is also free to anyone using the
source. There is no required learning curve.

>>  * in the long run it's best to standardize on a single patch system (new
>>contributors need to learn a single system, more people can help you,
>>etc.) and quilt appears to be that patch system.
>
>  That part feels also a bit strange - I don't think it should be the
> decision of the dpkg team to force people to use a specific patch
> system. Again, I use quilt myself. Though, Debian (and free software in
> general) always was about choice. And yes, I know, there's 3.0 (native),
> but that wasn't mentioned.

And the choice is still there. As you say yourself there is 3.0
(native) even if it wasn't advertized. Also things like topgit can be
used and the resulting source package can still use 3.0 (quilt)
format. That will allow for the maintainer to use his/her favourite
environment while everybody else still has to option to use the
resulting source package with or even without quilt. Again, no
learning curve to modify the source.

Maybe think of 3.0 (quilt) more as an interchange format of debian
patches.

>> When you switch to "3.0 (quilt)", there are other changes that you might
>> want to do:

addressed in other mails

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Norbert Preining]

On Sa, 21 Nov 2009, Gerfried Fuchs wrote:
>  Heavy modification? What's so heavy on three entries there?
> 
> include /usr/share/quilt/quilt.make
> 
> clean:
>   [...]
>   unpatch
> 
> build-stamp: patch

Besides that that snippet is broken? It made me nuts that quilt people
are changing that snippet and breaking many packages, like all of mine.
It should be:

build-stamp: $(QUILT_STAMPFN)
...

and as far as I see:
clean: unpatch


DOn't get me wrong, I am already using quilt, but the interface with
quilt.make should not change (again, hopefully).

Best wishes

Norbert

---
Dr. Norbert PreiningAssociate Professor
JAIST Japan Advanced Institute of Science and Technology   prein...@jaist.ac.jp
Vienna University of Technology   prein...@logic.at
Debian Developer (Debian TeX Task Force)prein...@debian.org
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
ABERBEEG (vb.)
Of amateur actors, to adopt a Mexican accent when called upon to play
any variety of foreigner (except Pakistanis - from whom a Welsh accent
is considered sufficient).
--- Douglas Adams, The Meaning of Liff


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Gerfried Fuchs]

* Raphael Hertzog  [2009-11-21 20:51:51 CET]:
> Hi,
> 
> On Sat, 21 Nov 2009, Gerfried Fuchs wrote:
> > * Raphael Hertzog  [2009-11-21 16:54:36 CET]:
> > >  * even if you don't have any upstream patch right now, next time that
> > >someone must NMU your package, they can cleanly add a patch (with a
> > >proper DEP-3 header) without having to modify the build system
> > 
> >  This is nothing new for the 3.0 (quilt) format, this is a reason for
> > any patch system format, so this feels a bit like false-advertising,
> > sorry.
> 
> Currently a package without a patch system needs heavy modifications in
> debian/rules to setup the patch system. So when you want to add a patch in
> debian/patches and not in the .diff.gz, you have to choose a patch system
> in place of the maintainer.

 Heavy modification? What's so heavy on three entries there?

include /usr/share/quilt/quilt.make

clean:
[...]
unpatch

build-stamp: patch

 Sorry, but these additions are next to nowhere "heavy modifications",
that's a bit over overrating, to say the least.

> With 3.0 (quilt), you don't need to do any such modification... the patch
> system is already available even if not used. That's what this point
> means.

 The modifications are implied, but it means that the source format is
already this "heavy modification", on a similarly heavy modification
scale. Additionally, if someone wants to sepearte the patches into
feature-patches instead of one-modification-patch-per-upload they will
have to additionally pull in quilt anyway to work on it properly,
without having it implied through the build-depends and being guided in
the right direction through README.Source.

> In general it should work, but you're right that we have a problem
> here with the buildds running an old version of sbuild (there are still
> many buildd in that situation) because they do "dpkg-source -x" outside
> of the buildd chroot where quilt is not installed even if you added
> quilt in your build-depends.
> 
> AFAIK newer sbuild should do "dpkg-source -x" in the chroot where quilt is
> installed due to build-depends and the .pc directory is then created
> at unpack time.
> 
> >  -) quilt doesn't find any applied patches (because dpkg doesn't create
> > the .pc/ directory structure)
> 
> dpkg-source -x uses quilt if it's installed, so if it's here the .pc
> structure is created.

 Alright, thanks for explaining the issue - so for the time, what do you
suggest? Remove the quilt handling? Actually ignore the error that quilt
gives (like you suggested on IRC)? Or wait until the sbuild fix is
applied everywhere?

 Thanks,
Rhonda


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Mike Hommey]

On Sat, Nov 21, 2009 at 08:51:51PM +0100, Raphael Hertzog wrote:
> Currently a package without a patch system needs heavy modifications in
> debian/rules to setup the patch system. So when you want to add a patch in
> debian/patches and not in the .diff.gz, you have to choose a patch system
> in place of the maintainer.

If there is no patch system when you are NMUing, why would you want to
add one ?

> We're not forcing anyone, we make it easier for people to use that patch
> system and we explain why we think it's a wise choice to consider quilt
> as the default patch system to use when you don't have any specific reason
> to pick one over the other.

Note that the squeeze release goal only talks about 3.0 (quilt), not 3.0
(native), which kind of suggests 3.0 (quilt) is being forced down.
That's maybe not what you are thinking, but it's how it feels.

> In general it should work, but you're right that we have a problem
> here with the buildds running an old version of sbuild (there are still
> many buildd in that situation) because they do "dpkg-source -x" outside
> of the buildd chroot where quilt is not installed even if you added
> quilt in your build-depends.
> 
> AFAIK newer sbuild should do "dpkg-source -x" in the chroot where quilt is
> installed due to build-depends and the .pc directory is then created
> at unpack time.

OTOH, "dpkg-source -x" should result in the same tree (including the .pc
directory), whatever the status of quilt installation is on the system.
Or if that is not possible without quilt, then dpkg-dev should depend on
quilt.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Raphael Hertzog]

Hi,

On Sat, 21 Nov 2009, Gerfried Fuchs wrote:
> * Raphael Hertzog  [2009-11-21 16:54:36 CET]:
> >  * even if you don't have any upstream patch right now, next time that
> >someone must NMU your package, they can cleanly add a patch (with a
> >proper DEP-3 header) without having to modify the build system
> 
>  This is nothing new for the 3.0 (quilt) format, this is a reason for
> any patch system format, so this feels a bit like false-advertising,
> sorry.

Currently a package without a patch system needs heavy modifications in
debian/rules to setup the patch system. So when you want to add a patch in
debian/patches and not in the .diff.gz, you have to choose a patch system
in place of the maintainer.

With 3.0 (quilt), you don't need to do any such modification... the patch
system is already available even if not used. That's what this point
means.

> >  * in the long run it's best to standardize on a single patch system (new
> >contributors need to learn a single system, more people can help you,
> >etc.) and quilt appears to be that patch system.
> 
>  That part feels also a bit strange - I don't think it should be the
> decision of the dpkg team to force people to use a specific patch
> system.

We're not forcing anyone, we make it easier for people to use that patch
system and we explain why we think it's a wise choice to consider quilt
as the default patch system to use when you don't have any specific reason
to pick one over the other.

> >  * You can remove everything related to quilt in debian/rules
> >(patch/unpatch logic, cleanup of quilt stamp file and its .pc
> >directory).
> 
>  Unfortunately, I can't follow that "can remove". It sounds like it
> would work if you keep it in.

In general it should work, but you're right that we have a problem
here with the buildds running an old version of sbuild (there are still
many buildd in that situation) because they do "dpkg-source -x" outside
of the buildd chroot where quilt is not installed even if you added
quilt in your build-depends.

AFAIK newer sbuild should do "dpkg-source -x" in the chroot where quilt is
installed due to build-depends and the .pc directory is then created
at unpack time.

>  -) quilt doesn't find any applied patches (because dpkg doesn't create
> the .pc/ directory structure)

dpkg-source -x uses quilt if it's installed, so if it's here the .pc
structure is created.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Gerfried Fuchs]

Hi!

 Some few comments.

* Raphael Hertzog  [2009-11-21 16:54:36 CET]:
>  * even if you don't have any upstream patch right now, next time that
>someone must NMU your package, they can cleanly add a patch (with a
>proper DEP-3 header) without having to modify the build system

 This is nothing new for the 3.0 (quilt) format, this is a reason for
any patch system format, so this feels a bit like false-advertising,
sorry. Don't get me wrong, I use quilt where I have to touch upstream
sources myself and totally like it, I just don't see the need to use
this as advertising for the 3.0 format because that doesn't buy you much
more in that respect.

>  * in the long run it's best to standardize on a single patch system (new
>contributors need to learn a single system, more people can help you,
>etc.) and quilt appears to be that patch system.

 That part feels also a bit strange - I don't think it should be the
decision of the dpkg team to force people to use a specific patch
system. Again, I use quilt myself. Though, Debian (and free software in
general) always was about choice. And yes, I know, there's 3.0 (native),
but that wasn't mentioned.

> When you switch to "3.0 (quilt)", there are other changes that you might
> want to do:
>  * You can remove everything related to quilt in debian/rules
>(patch/unpatch logic, cleanup of quilt stamp file and its .pc
>directory).

 Unfortunately, I can't follow that "can remove". It sounds like it
would work if you keep it in. Unfortunately that's not the case. Please
take a look at the build logs for wesnoth 1:1.7.8-1. The story is easy:

 -) The buildd does a debian/rules clean.
 -) quilt doesn't find any applied patches (because dpkg doesn't create
the .pc/ directory structure)
 -) The buildd then starts with the building.
 -) quilt likes to apply the patches and failes because they already
*are* applied but quilt doesn't know about it.

 So pretty please, change that "can remove" into a "MUST remove",
otherwise you will stumble into problems.

> === Does a 3.0 (quilt) source package need to build-depend on quilt? ===
> 
> If you drop the quilt usage in debian/rules (patch/unpatch logic), then no.

 You *HAVE* to drop the quilt usage in debian/rules, otherwise it will
fail.

 So long, and thanks for the work involved, but this minor issues should
still be addressed, in one way or the other. :)

 *waves*
Rhonda


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org