Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)

[Benjamin Drung]

Am Montag, den 23.11.2009, 08:42 +0100 schrieb Raphael Hertzog:
> Hi,
> 
> On Mon, 23 Nov 2009, Benjamin Drung wrote:
> > When a new upstream version is released, I have to check all patches
if
> > they were accepted by upstream or not. I have to check each patch if
I
> > can drop it. It would make packaging new releases easier if there
were
> > an optional Applied-Upstream field. Every patch that was applied
> > upstream can be dropped. "no" or "not-yet" would indicate that the
patch
> > was not applied yet. If the patch was applied, it could contain the
> > revision (like "r4681") or a link to the VCS commit.
> > 
> > What do you think about my suggestion?
> 
> I suppose that you would want to add the field as soon as the patch is
> committed upstream so that you can more easily identify patches to
remove
> when the next upstream version is out?

Yes, indeed.

> Do you expect to automate this operation?

Adding the field would be manual, but removing the patches can do a
simple script, when the next upstream release is out.

> I'm not sure we need a new field for this purpose, you could add a
comment
> in the description field or even change the Forwarded: URL to point to
the
> upstream VCS to make it clearer that it got merged.

Automating the removal would be hard then.

> BTW, speaking of DEP-3, someone mentioned that it doesn't tell the
> encoding to use. Does anyone oppose to adding a note saying that it
> should aim at being ASCII-only and if that's not possible then UTF-8
> should be used?

I think that the DEP-3 header should be in UTF-8 (ASCII would be the
subset).


-- 
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

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: Lintian based autorejects

[Stefano Zacchiroli]

On Tue, Oct 27, 2009 at 03:06:07PM +0100, Joerg Jaspert wrote:
> we are turning on lintian based autorejects within the next few days.
> This means that packages failing a defined set of lintian tags will no
> longer be accepted into the archive, but get rejected immediately.
> This should help to get rid of the worst policy violations before
> wasting time and resources of other people.
> 
> Those automated rejects will only be done on sourceful uploads to
> unstable and experimental.

I've noticed that for DELAYED/XX uploads, the lintian rejects are
triggered not when the package hits DELAYED/XX, but rather when the
package eventually hits the archive. The annoyance of this is that the
uploader losts "focus" on the specific fix.

Any chance/plan to fix this so that lintian rejects are checked at
DELAYED entrance time? (sorry if it has been asked before, I didn't find
it with a quick in the thread)

If for some architectural reasons this is hard / not worth to fix, I
guess we can alternatively add a corresponding check to dput, which
refuses to upload when it finds non-overridden fatal lintian errors
(unless --forced or something).

TIA,
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

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

Processed: Re: Bug#557431: general: there is no package to install all POSIX utilities at once

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 557431 wnpp
Bug #557431 [general] general: there is no package to install all POSIX 
utilities at once
Bug reassigned from package 'general' to 'wnpp'.
> retitle 557431 RFP: posix-utils
Bug #557431 [wnpp] general: there is no package to install all POSIX utilities 
at once
Changed Bug title to 'RFP: posix-utils' from 'general: there is no package to 
install all POSIX utilities at once'
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
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: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)

[Goswin von Brederlow]

Benjamin Drung  writes:

> Hi,
>
> When a new upstream version is released, I have to check all patches if
> they were accepted by upstream or not. I have to check each patch if I
> can drop it. It would make packaging new releases easier if there were
> an optional Applied-Upstream field. Every patch that was applied
> upstream can be dropped. "no" or "not-yet" would indicate that the patch
> was not applied yet. If the patch was applied, it could contain the
> revision (like "r4681") or a link to the VCS commit.
>
> What do you think about my suggestion?

Why would the source (or VCS head) ever contain a patch that was
applied upstream? The moment the patch gets applied you simply remove
it.

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

[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

[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: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)

[Benjamin Drung]

Am Montag, den 23.11.2009, 09:18 +0100 schrieb Goswin von Brederlow:
> Benjamin Drung  writes:
> 
> > Hi,
> >
> > When a new upstream version is released, I have to check all patches if
> > they were accepted by upstream or not. I have to check each patch if I
> > can drop it. It would make packaging new releases easier if there were
> > an optional Applied-Upstream field. Every patch that was applied
> > upstream can be dropped. "no" or "not-yet" would indicate that the patch
> > was not applied yet. If the patch was applied, it could contain the
> > revision (like "r4681") or a link to the VCS commit.
> >
> > What do you think about my suggestion?
> 
> Why would the source (or VCS head) ever contain a patch that was
> applied upstream? The moment the patch gets applied you simply remove
> it.

Not until the next upstream release.

-- 
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)

[Mike Hommey]

On Mon, Nov 23, 2009 at 09:18:37AM +0100, Goswin von Brederlow wrote:
> Benjamin Drung  writes:
> 
> > Hi,
> >
> > When a new upstream version is released, I have to check all patches if
> > they were accepted by upstream or not. I have to check each patch if I
> > can drop it. It would make packaging new releases easier if there were
> > an optional Applied-Upstream field. Every patch that was applied
> > upstream can be dropped. "no" or "not-yet" would indicate that the patch
> > was not applied yet. If the patch was applied, it could contain the
> > revision (like "r4681") or a link to the VCS commit.
> >
> > What do you think about my suggestion?
> 
> Why would the source (or VCS head) ever contain a patch that was
> applied upstream? The moment the patch gets applied you simply remove
> it.

Ever heard of branches ?

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

[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, 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

[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

[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]

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

Unversioned .so file in /usr/lib vs dh_makeshlibs vs postinst-must-call-ldconfig

[Nikita V. Youshchenko]

Hi

I tried to prepare and NMU to fix an RC bug #553111, which is 
postinst-must-call-ldconfig.

I found that adding missing call to dh_makeshlibs does not fix the issue, 
because package installs a private shared library to /usr/lib/libxxx.so, 
and dh_makeshlibs does not add call to ldconfig to postinst/postrm if it 
finds unversioned libraries.

Is that a bug in debhelper, or in lintian (i.e. postinst-must-call-ldconfig 
is false-positive)?

I guess ldconfig should be called even if package installs unversioned 
libraries, since ldconfig not only adds symlinks but also 
updates /etc/ld.so.cache.

Nikita


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

Re: Unversioned .so file in /usr/lib vs dh_makeshlibs vs postinst-must-call-ldconfig

[Julien Cristau]

On Mon, Nov 23, 2009 at 13:33:17 +0300, Nikita V. Youshchenko wrote:

> Hi
> 
> I tried to prepare and NMU to fix an RC bug #553111, which is 
> postinst-must-call-ldconfig.
> 
> I found that adding missing call to dh_makeshlibs does not fix the issue, 
> because package installs a private shared library to /usr/lib/libxxx.so, 
> and dh_makeshlibs does not add call to ldconfig to postinst/postrm if it 
> finds unversioned libraries.
> 
> Is that a bug in debhelper, or in lintian (i.e. postinst-must-call-ldconfig 
> is false-positive)?
> 
I'd say it's a bug in the package because private objects shouldn't be
installed in /usr/lib directly.  lintian should probably use a different
tag for this, though.

Cheers,
Julien


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

Re: Unversioned .so file in /usr/lib vs dh_makeshlibs vs postinst-must-call-ldconfig

[Nikita V. Youshchenko]

> On Mon, Nov 23, 2009 at 13:33:17 +0300, Nikita V. Youshchenko wrote:
> > Hi
> >
> > I tried to prepare and NMU to fix an RC bug #553111, which is
> > postinst-must-call-ldconfig.
> >
> > I found that adding missing call to dh_makeshlibs does not fix the
> > issue, because package installs a private shared library to
> > /usr/lib/libxxx.so, and dh_makeshlibs does not add call to ldconfig to
> > postinst/postrm if it finds unversioned libraries.
> >
> > Is that a bug in debhelper, or in lintian (i.e.
> > postinst-must-call-ldconfig is false-positive)?
>
> I'd say it's a bug in the package because private objects shouldn't be
> installed in /usr/lib directly.

Probably, however some packages do use that, and AFAIK this is not RC... or 
not?


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

Re: Unversioned .so file in /usr/lib vs dh_makeshlibs vs postinst-must-call-ldconfig

[Josselin Mouette]

Le lundi 23 novembre 2009 à 14:00 +0300, Nikita V. Youshchenko a
écrit : 
> > > I found that adding missing call to dh_makeshlibs does not fix the
> > > issue, because package installs a private shared library to
> > > /usr/lib/libxxx.so, and dh_makeshlibs does not add call to ldconfig to
> > > postinst/postrm if it finds unversioned libraries.

> > I'd say it's a bug in the package because private objects shouldn't be
> > installed in /usr/lib directly.
> 
> Probably, however some packages do use that, and AFAIK this is not RC... or 
> not?

I think it fails to comply with policy §8.1.

And regardless of the policy, it completely breaks the dependency
system, so it should be avoided.

Cheers, 
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: Unversioned .so file in /usr/lib vs dh_makeshlibs vs postinst-must-call-ldconfig

[Mike Hommey]

On Mon, Nov 23, 2009 at 12:05:28PM +0100, Josselin Mouette wrote:
> Le lundi 23 novembre 2009 à 14:00 +0300, Nikita V. Youshchenko a
> écrit : 
> > > > I found that adding missing call to dh_makeshlibs does not fix the
> > > > issue, because package installs a private shared library to
> > > > /usr/lib/libxxx.so, and dh_makeshlibs does not add call to ldconfig to
> > > > postinst/postrm if it finds unversioned libraries.
> 
> > > I'd say it's a bug in the package because private objects shouldn't be
> > > installed in /usr/lib directly.
> > 
> > Probably, however some packages do use that, and AFAIK this is not RC... or 
> > not?
> 
> I think it fails to comply with policy §8.1.
> 
> And regardless of the policy, it completely breaks the dependency
> system, so it should be avoided.

Actually, only the shlibs systems breaks. The symbols system supports
.so files.

Anyways, this may be a place where policy could be improved. While I do
agree that in the general case we don't want unversioned sonames, there
are a few cases where adding a debian specific soname breaks
compatibility with other distros and upstream, while the library ABI is
known or even guaranteed to be stable.

What is the point of requiring so versioning when it is known there
won't be any bump in version ? And even if there is such a bump, can't
we just wait until it happens before adding incompatibilities ?

Mike, with his nspr maintainer hat on.


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

Re: Unversioned .so file in /usr/lib vs dh_makeshlibs vs postinst-must-call-ldconfig

[Nikita V. Youshchenko]

> On Mon, Nov 23, 2009 at 12:05:28PM +0100, Josselin Mouette wrote:
> > Le lundi 23 novembre 2009 à 14:00 +0300, Nikita V. Youshchenko a
> >
> > écrit :
> > > > > I found that adding missing call to dh_makeshlibs does not fix
> > > > > the issue, because package installs a private shared library to
> > > > > /usr/lib/libxxx.so, and dh_makeshlibs does not add call to
> > > > > ldconfig to postinst/postrm if it finds unversioned libraries.
> > > >
> > > > I'd say it's a bug in the package because private objects
> > > > shouldn't be installed in /usr/lib directly.
> > >
> > > Probably, however some packages do use that, and AFAIK this is not
> > > RC... or not?
> >
> > I think it fails to comply with policy §8.1.
> >
> > And regardless of the policy, it completely breaks the dependency
> > system, so it should be avoided.
>
> Actually, only the shlibs systems breaks. The symbols system supports
> .so files.
>
> Anyways, this may be a place where policy could be improved. While I do
> agree that in the general case we don't want unversioned sonames, there
> are a few cases where adding a debian specific soname breaks
> compatibility with other distros and upstream, while the library ABI is
> known or even guaranteed to be stable.
>
> What is the point of requiring so versioning when it is known there
> won't be any bump in version ? And even if there is such a bump, can't
> we just wait until it happens before adding incompatibilities ?
>
> Mike, with his nspr maintainer hat on.

I've also seen cases when upstream build system puts some code in 
a 'private shared library' which is installed into $prefix/lib, but is 
never intended to use outside of current package (and has absolutely 
unstable ABI, etc).

How to handle that case, if not putting private library as-is to /usr/lib ?

Move it to /usr/lib/packagename, and use rpath on binaries? debian tries to 
avoid rpath AFAIK ...
Or alter upstream's build system to stop producing shared library? that's 
at least maintaince headache without any win...

Nikita


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

Re: NMU question

[Charles Plessy]

Le Sun, Nov 22, 2009 at 09:31:59PM +0300, Nikita V. Youshchenko a écrit :
> 
> I've just met an uninstallable package with 3-week-old RC bug, caused by 
> soname change of one of dependences. This bug could be fixed by a simple 
> rebuild - I've checked if package builds against today's sid - yes it 
> does.
 
> Also, is it ok to NMU keeping existing lintian warnings (such as 
> package-uses-deprecated-debhelper-compat-version, 
> out-of-date-standards-version, patch-system-but-no-source-readme)?
> I don't intend to (co)maintain this package in future, it is just a 
> single-time interest.

Dear Nikita,

it is difficult to judge since you did not give the package name. Nevertheless,
the combination of RC bug left unfixed and signs of obsolescence
(package-uses-deprecated-debhelper-compat-version) suggests that the maintainer
might be MIA. If nobody wants to maintain this package, it should better be
orphaned or removed than NMUed. If the maintainer is active, it is of course
with him and not this list that the contents of the NMU have to be discussed.
If he gives you green light, there is of course no problem fixing no-RC issues.

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: Unversioned .so file in /usr/lib vs dh_makeshlibs vs postinst-must-call-ldconfig

[Josselin Mouette]

Le lundi 23 novembre 2009 à 14:39 +0300, Nikita V. Youshchenko a
écrit : 
> I've also seen cases when upstream build system puts some code in 
> a 'private shared library' which is installed into $prefix/lib, but is 
> never intended to use outside of current package (and has absolutely 
> unstable ABI, etc).
> 
> How to handle that case, if not putting private library as-is to /usr/lib ?
> 
> Move it to /usr/lib/packagename, and use rpath on binaries? debian tries to 
> avoid rpath AFAIK ...

Just because we hunt down stupid rpath cases doesn’t mean there aren’t
valid uses for it. And this is precisely the case for which rpath is
intended.

> Or alter upstream's build system to stop producing shared library? that's 
> at least maintaince headache without any win...

No, that would be a net loss in terms of disk and memory usage.

Cheers, 
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: NMU question

[Nikita V. Youshchenko]

> Dear Nikita,
>
> it is difficult to judge since you did not give the package name.
> Nevertheless, the combination of RC bug left unfixed and signs of
> obsolescence (package-uses-deprecated-debhelper-compat-version) suggests
> that the maintainer might be MIA. If nobody wants to maintain this
> package, it should better be orphaned or removed than NMUed. If the
> maintainer is active, it is of course with him and not this list that
> the contents of the NMU have to be discussed. If he gives you green
> light, there is of course no problem fixing no-RC issues.
>
> Have a nice day,

Package in question was ibm-3270 [source], maintainer is Bastian Blank, bug 
is 553481.

I did not put that info into my above mail because my question was actually 
about procedure, so I did not want to go into discussing this particular 
bug or package or maintainer.
IMO procedure on NMUing is not documented clear enogh in Developer 
Reference. At least I got confused, although I'm in debian already for 
years.

Nikita

> > I've just met an uninstallable package with 3-week-old RC bug, caused
> > by soname change of one of dependences. This bug could be fixed by a
> > simple rebuild - I've checked if package builds against today's sid -
> > yes it does.
> >
> > I've never done an NMU before, but this looks like a case to try :) 
> >
> > However, reading developer reference about NMUs, I got confused by
> > normal vs binary-only uploads for this case.
> >
> > Is it ok just to add something like
> >
> > * Non-Maintainer Upload
> > * Rebuild against newer libicu (Closes: XXX)
> >
> > to deban/changelog, build with pbuilder, upload with dput --delayed 2,
> > and drop a mail to maintainer?
> >
> > Or something else should be done?
> > Triggering binary-only NMUs on every architecture somehow?
> > Build-depending on newer libicu-dev [I guess no since package perfectly
> > builds against older libicu-dev]?
> > Something else?
> >
> > Also, is it ok to NMU keeping existing lintian warnings (such as
> > package-uses-deprecated-debhelper-compat-version,
> > out-of-date-standards-version, patch-system-but-no-source-readme)?
> > I don't intend to (co)maintain this package in future, it is just a
> > single-time interest.


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

Re: Unversioned .so file in /usr/lib vs dh_makeshlibs vs postinst-must-call-ldconfig

[Nikita V. Youshchenko]

> > How to handle that case, if not putting private library as-is to
> > /usr/lib ?
> >
> > Move it to /usr/lib/packagename, and use rpath on binaries? debian
> > tries to avoid rpath AFAIK ...
>
> Just because we hunt down stupid rpath cases doesn’t mean there aren’t
> valid uses for it. And this is precisely the case for which rpath is
> intended.

Moving package-private shared libraries outside of /usr/lib is some amount 
of additional work that maintainer has to do.

I would like to understand the status of this "package-private libraries 
vs /usr/lib" thing. I'm unable to find explicit allow or deny of 
installation of package-private libraries into /usr/lib in the current 
policy text, in 8.1 or anywhere else.

If it is a requirement, then perhaps it should be clearly written in the 
policy, reasoning should be explained, and we all should follow that.

If it is not a requirement, then we could find better things to spend time 
on, than introducing and maintaining patches to move package-private libs 
out of /usr/lib, and then dealing with incompatibilities with upstream 
code or other distros or whatever that such a move may introduce.

After all, what's wrong with package-private libs in /usr/lib?

Nikita


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

Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)

[Goswin von Brederlow]

Benjamin Drung  writes:

> Am Montag, den 23.11.2009, 09:18 +0100 schrieb Goswin von Brederlow:
>> Benjamin Drung  writes:
>> 
>> > Hi,
>> >
>> > When a new upstream version is released, I have to check all patches if
>> > they were accepted by upstream or not. I have to check each patch if I
>> > can drop it. It would make packaging new releases easier if there were
>> > an optional Applied-Upstream field. Every patch that was applied
>> > upstream can be dropped. "no" or "not-yet" would indicate that the patch
>> > was not applied yet. If the patch was applied, it could contain the
>> > revision (like "r4681") or a link to the VCS commit.
>> >
>> > What do you think about my suggestion?
>> 
>> Why would the source (or VCS head) ever contain a patch that was
>> applied upstream? The moment the patch gets applied you simply remove
>> it.
>
> Not until the next upstream release.

Sorry. Didn't quite grasp what you ment.

So what you want is (overly verbose)

Accepted-upstream: r1234 345836583468534854856834568395648
Will-Be-Obsolete-in: 1.2

while you still only have upstreams 1.1 in Debian.

I think the idea is good. The implementation seems to be in
doubt (where should it mention this, what should the field be called).
I would like to have both the information when it was commited and
when it will be released. The commit would be interesting because
often it differs from the debian patch to accomodate the newer
upstream developement. The release to know when the patch can be
removed.

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:

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

Bug#557680: ITP: pep8simulator -- Pep/8 assembler and simulator

[Ezra Reeves]

Package: wnpp
Severity: wishlist
Owner: Ezra Reeves 


* Package name: pep8simulator
  Version : 8.1.1
  Upstream Author : J. Stanley Warford 
* URL : http://code.google.com/p/pep8-1/
* License : GPL
  Programming Lang: C++
  Description : Pep/8 assembler and simulator

 Pep/8 is a virtual machine for writing machine language and assembly
 language programs. It is designed to be used with the textbook,
 Computer Systems, J. Stanley Warford, Fourth edition, Jones and Bartlett,
 Publishers, 2010.



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

Re: Bug#556643: ITP: togl -- a Tk OpenGL widget

[Aaron M. Ucko]

Christophe Trophime  writes:

> The license states that "Modifications to this software may be copyrighted by 
> their authors
> and need not follow the licensing terms described here, provided that
> the new terms are clearly indicated on the first page of each file where
> they apply.". Does it mean the it is not DFSG?

No, it just means that it's not under the GPL or another "copyleft"
license.

http://togl.cvs.sourceforge.net/viewvc/togl/Togl/LICENSE?revision=1.3&view=markup

looks like a typical MIT- (or modern BSD-) style license to me; the
portion you quoted is simply a reminder that it's legal to produce
non-free derived works.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu


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

Re: Lintian based autorejects

[Joerg Jaspert]

> I've noticed that for DELAYED/XX uploads, the lintian rejects are
> triggered not when the package hits DELAYED/XX, but rather when the
> package eventually hits the archive. The annoyance of this is that the
> uploader losts "focus" on the specific fix.

> Any chance/plan to fix this so that lintian rejects are checked at
> DELAYED entrance time? (sorry if it has been asked before, I didn't find
> it with a quick in the thread)

No.

Long answer: Delayed is nothing dak knows about at all. It is all
handled by debianqueued, which is a perl script running far before
dak. Due to its age it is also not quite of the standard one wants to
have when editing code, so supporting anything like rejects in there is
not done.
So for that, yes, you want to think about the dput solution. Which would
have the nice added benefit to actually save people form uploading and
wasting bandwidth and time.


Also, should there be someone with a little too much free time ( :) )
and willing to code a bit in python, there are various thoughts and
plans around for a rewrite of the queued with much nicer functionality
and stuff. Just none of us existing team members has the time to do it,
there are always more important things (and debianqueued works).
If someone is interested, either mail me or join #debian-dak on
irc.oftc.net.

-- 
bye, Joerg
> 16. What should you do if a security bug is discovered in one of your 
> packages?
1) Notify t...@s.d.o ASAP.
2) Notify upstream.
3) Try to create a patch.
4) Find out that Joey was faster.
[...]


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

DEP3 and even more incompatible "RFC-2822" formats

[Carl Fürstenberg]

I took my time reading DEP3 (http://dep.debian.net/deps/dep3/) and
notice they introduce an new "RFC-2822-like" format. This time they
introduce an ambiguous rules where either the Description or the
Subject field and contain verbatim data (which one is uncertain to me,
the text implies one of them, but says Description first, and Subject
later). This will off course require an specific parser as a parser
for the debcontrol format can't be used due to this rule. Including
this with the policy that only debian/control can contain comments
(policy 5.2) and that DEP5 (http://dep.debian.net/deps/dep5/)
introduces a "superset of RFC2822".
Wouldn't it now be a good time to formally define a format that can be
parsed with a generic parser, instead of continuing the invention of
additional RFC-2822++ formats?

On an other note, the DEP3 verbatim data specifier doesn't define any
limits on what data it can contain, so the content "...as you can see
in the following\nbug: blablabla" is ambiguous as best.

-- 
/Carl Fürstenberg 


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

Re: Lintian based autorejects

[Philipp Kern]

On 2009-11-23, Joerg Jaspert  wrote:
> So for that, yes, you want to think about the dput solution. Which would
> have the nice added benefit to actually save people form uploading and
> wasting bandwidth and time.

Everybody should pipe his uploads through lintian.  That's nothing that
should be in the upload tool, IMHO.  A unixy tool does one job, not two.

Of course the Lintian standards for rejects could vary between package
build and upload time and it hitting the archive.  But then that's nothing
a dput hook would catch neither.

Kind regards,
Philipp Kern

PS: A working p-u-new would be much appreciated.


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

Re: Unversioned .so file in /usr/lib vs dh_makeshlibs vs postinst-must-call-ldconfig

[Russ Allbery]

"Nikita V. Youshchenko"  writes:

> How to handle that case, if not putting private library as-is to /usr/lib ?

> Move it to /usr/lib/packagename, and use rpath on binaries?

Yes.

> debian tries to avoid rpath AFAIK ...

Debian tries to avoid RPATH used in ways that might break multilib or
override local administrator settings, which means we want to avoid RPATH
pointing to /usr/lib or to build directories and the like.  But RPATH is
the correct solution for finding private libraries in a subdirectory
included in the package or built from the same source package.

-- 
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: Bug#557515: ITP: rail -- Replace Agent-string Internal Library

[Bernd Zeimetz]

Youhei SASAKI wrote:
> Package: wnpp
> Owner: Youhei SASAKI 
> Severity: wishlist
> 
> * Package name: rail
>   Version : 1.2.6
>   Upstream Author : Mitsunobu Shimada 
> * URL or Web page : http://ring.riken.jp/archives/elisp/rail/
> * License : GPL
>   Description : Replace Agent-string Internal Library
> 
>  1. compatibility for tm's enjis.el (japanize 'mule-version)
>  2. Japanize ( FLIM / SEMI / XEmacs / UTF-2000 Mule / Meadow )'s code name.
> And apply it for User-Agent: field.
>  3. On irchat-pj, Japanize ( Mule / XEmacs / Meadow )'s code name
> for "CTCP VERSION" return string.


I think you should really use a proper and better description here. The lines
above don't tell what the package is for, at least not for the common user.
Maybe if you know what the package is for you will understand the description -
so there is no chance that a normal user is able to figure it out.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
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: Unversioned .so file in /usr/lib vs dh_makeshlibs vs postinst-must-call-ldconfig

[Josselin Mouette]

Le lundi 23 novembre 2009 à 15:30 +0300, Nikita V. Youshchenko a
écrit : 
> Moving package-private shared libraries outside of /usr/lib is some amount 
> of additional work that maintainer has to do.

Yes. This is one of the reasons why there are maintainers instead of
robots.

> If it is not a requirement, then we could find better things to spend time 
> on, than introducing and maintaining patches to move package-private libs 
> out of /usr/lib, and then dealing with incompatibilities with upstream 
> code or other distros or whatever that such a move may introduce.

It’s actually a good way to find if some other package uses some library
intentionally kept private. Sometimes you simply don’t want this to be
possible.

As for compatibility with other distros, same answer: if the library is
private, it should not be used outside the package itself, or a small
set of selected packages. This is not something you can rely on for
cross-distribution compatibility. If you need a defined ABI, you need a
regular library with a defined SONAME. 

> After all, what's wrong with package-private libs in /usr/lib?

It’s a recipe for failure. It’s a private interface, not defined to
remain compatible. If you make it available in a public place, people
will use it. If people use it, it will fail.

Cheers, 
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

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: Unversioned .so file in /usr/lib vs dh_makeshlibs vs postinst-must-call-ldconfig

[Modestas Vainius]

Hello,

On pirmadienis 23 Lapkritis 2009 23:35:28 Russ Allbery wrote:
 
> Debian tries to avoid RPATH used in ways that might break multilib or
> override local administrator settings, which means we want to avoid RPATH
> pointing to /usr/lib or to build directories and the like.  But RPATH is
> the correct solution for finding private libraries in a subdirectory
> included in the package or built from the same source package.

Is RUNPATH any better? At least "override local administrator settings" should 
not be a problem with it.

-- 
Modestas Vainius 


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

Bug#557731: ITP: lptools -- desktop tools for Launchpad

[Robert Collins]

X-Debbugs-CC: debian-devel@lists.debian.org
package: wnpp

Description:
 LP Tools allow you to work with Launchpad without ever having to deal
 with the web interface. The review-list tool can list reviews, and
 review-notifier provides a desktop notifier about reviews that can be
done.
 .
 milestone2ical converts milestones on a project or project group into
the
 iCal format.



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

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

[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

[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

[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

Tool suggestions for new formats?

[Rodrigo Gallardo]

Part of my usual workflow with the 1.0 format is to do an interdiff on
the .diff.gz from the previous version to the one I intend to upload,
to check that the changes correspond to what my vcs says they are. Now
that the changes are in a tarball, are there any recommended tools to
do that comparison?

A quick check on the intertubes found this
 http://tardiff.coolprojects.org/
Anyone tried it? What package would this (or some other equivalent but
better suggestion) be a good addition to? devscripts?


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

[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: Tool suggestions for new formats?

[Guillem Jover]

Hi!

On Mon, 2009-11-23 at 17:28:39 -0800, Rodrigo Gallardo wrote:
> Part of my usual workflow with the 1.0 format is to do an interdiff on
> the .diff.gz from the previous version to the one I intend to upload,
> to check that the changes correspond to what my vcs says they are. Now
> that the changes are in a tarball, are there any recommended tools to
> do that comparison?
> 
> A quick check on the intertubes found this
>  http://tardiff.coolprojects.org/
> Anyone tried it? What package would this (or some other equivalent but
> better suggestion) be a good addition to? devscripts?

Just use debdiff, which even supports stuff like comparing a source
format 1.0 against a 3.0.

regrads,
guillem


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

[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

[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

[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

[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: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: Unversioned .so file in /usr/lib vs dh_makeshlibs vs postinst-must-call-ldconfig

[Eduard Bloch]

#include 
* Josselin Mouette [Tue, Nov 24 2009, 12:00:34AM]:
> Le lundi 23 novembre 2009 à 15:30 +0300, Nikita V. Youshchenko a
> écrit : 
> > Moving package-private shared libraries outside of /usr/lib is some amount 
> > of additional work that maintainer has to do.
> 
> Yes. This is one of the reasons why there are maintainers instead of
> robots.

And maintainers should also have a sane sense of reality.

> > If it is not a requirement, then we could find better things to spend time 
> > on, than introducing and maintaining patches to move package-private libs 
> > out of /usr/lib, and then dealing with incompatibilities with upstream 
> > code or other distros or whatever that such a move may introduce.

The argument of "compatibility with other distros" is void, IMHO. We are
talking about cases where just some code is shared among few binaries
of the same package, not more, not less.

And introducing a sophisticated structure (also remember multi-arch)
only to give someones eyes the aesthetic satisfaction is pure waste of
time.

> It’s actually a good way to find if some other package uses some library
> intentionally kept private. Sometimes you simply don’t want this to be
> possible.

"Sometimes". Is this case relevant now? I don't think so. It is not even
possible (unless somebody intends to use kludges) since the headers are
not available to others.

> > After all, what's wrong with package-private libs in /usr/lib?
> 
> It’s a recipe for failure. It’s a private interface, not defined to
> remain compatible. If you make it available in a public place, people
> will use it. If people use it, it will fail.

C'mon, you are making a mountain out of a molehill.

Regards,
Eduard.

-- 
"Ein schäbiges Kamel trägt immer noch die Lasten vieler Esel."
-- Goethe, Maximen und Reflektionen, Nr. 548


signature.asc
Description: Digital signature

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

[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

[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]

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

[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

[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: Tool suggestions for new formats?

[Mike Hommey]

On Tue, Nov 24, 2009 at 03:43:42AM +0100, Guillem Jover wrote:
> Hi!
> 
> On Mon, 2009-11-23 at 17:28:39 -0800, Rodrigo Gallardo wrote:
> > Part of my usual workflow with the 1.0 format is to do an interdiff on
> > the .diff.gz from the previous version to the one I intend to upload,
> > to check that the changes correspond to what my vcs says they are. Now
> > that the changes are in a tarball, are there any recommended tools to
> > do that comparison?
> > 
> > A quick check on the intertubes found this
> >  http://tardiff.coolprojects.org/
> > Anyone tried it? What package would this (or some other equivalent but
> > better suggestion) be a good addition to? devscripts?
> 
> Just use debdiff, which even supports stuff like comparing a source
> format 1.0 against a 3.0.

By unpacking ? 

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]

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