Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Goswin von Brederlow]

Scott Kitterman  writes:

> On Wednesday, June 01, 2011 10:26:59 AM sean finney wrote:
>> On Wed, Jun 01, 2011 at 02:39:42PM +0200, Goswin von Brederlow wrote:
>> > And note that as maintainer or for the VCS copy you can allways
>> > configure debian/soruce/local-options to unapply patches if you so
>> > desire.
>> 
>> This is something i've been doing quite happily and I think it is
>> a pretty decent compromise for the user/maintainer use cases.
>> 
>> If you're building from the VCS there may be a difference in behavior,
>> but if you build a downloaded source package (or even a source package
>> generated from the VCS), the behavior is consistant.
>
> I tend to touch many packages and only revisit them infrequently so I don't 
> generally have a local copy of the package to have modified when I start 
> work.  
> So for me the general workflow for using debian/source/local-options would be 
> something like:
>
> download package/check out fom VCS

If it is from VCS and the workflow is with patches not checked in then
why isn't there a debian/source/local-options already?

> oh, this is V3
> unapply patches
> add debian/source/local-options
> work on package

Oh, this isn't a V3 packages. Read README.source, read debian/rules,
read manpage of strange patch system, run debuild and read the log to
figure out how this black box patches its source,  Works both ways.

Note that you do not need to unapply patches or care about them at all
to work on the package. So if you are doing an NMU or preparing a patch
for the BTS then it is just:

apt-get source foo
work on package
debuild
test
# Optionally: Just to be nice and fill out the header
# This would be improved by the --record-changes discussed earlier
edit debian/patches/debian-changes-version
reportbug -A debian/patches/debian-changes-version foo
(upload NMU)

With 1.0 packages you frequently first have to learn about the patch
system used before you can alter and build the package. That I think is
the greatest benefit of 3.0 (quilt): For the simple case of quickly
fixing a bug it is transparent and just works out of the box.

> apply patches if needed

That is never needed as building does that as needed. Unless you mean
going up and down the patch series while you work on the package. That
you have with 1.0 + patch system as well. No change then.

> upload
> rm -fr the package
>
> debian/source/local-options doesn't really help me much  Not making the 
> package source format 3 on the other hand conveniently provides the workflow 
> I 
> want in a persistent manner with no recurring effort needed.
>
> Scott K

Hardly persistent. Half the packages will have stuff pre-applied from
the diff.gz, half the packages will have $random patch system and the
third half :) will even mix the two.

I'm not saying 3.0 (quilt) is the ultimate format and I'm not saying
nobody should still use 1.0. But please don't call the 1.0 packages we
have in the archive consistent. If you just mean your own packages then
you could change them all to have debian/source/local-options in their
VCS too. If you mean other peoples packages then I don't see how you can
claim they behave in any persistent manner.

I think 3.0 (quilt) made a great step towards unifying the packaging of
most of the 1.0 packages with a patch system. Nearly all of those can be
easily changed to 3.0 (quilt) format to get a simple to use, flexible
(for the maintainer) and uniform (for the user) behaviour. Not all of
them but that is ok.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877h94bnst.fsf@frosties.localnet

Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Guido Günther]

On Thu, Jun 02, 2011 at 11:11:30AM +0200, Goswin von Brederlow wrote:
> Scott Kitterman  writes:
> 
> > On Wednesday, June 01, 2011 10:26:59 AM sean finney wrote:
> >> On Wed, Jun 01, 2011 at 02:39:42PM +0200, Goswin von Brederlow wrote:
> >> > And note that as maintainer or for the VCS copy you can allways
> >> > configure debian/soruce/local-options to unapply patches if you so
> >> > desire.
> >> 
> >> This is something i've been doing quite happily and I think it is
> >> a pretty decent compromise for the user/maintainer use cases.
> >> 
> >> If you're building from the VCS there may be a difference in behavior,
> >> but if you build a downloaded source package (or even a source package
> >> generated from the VCS), the behavior is consistant.
> >
> > I tend to touch many packages and only revisit them infrequently so I don't 
> > generally have a local copy of the package to have modified when I start 
> > work.  
> > So for me the general workflow for using debian/source/local-options would 
> > be 
> > something like:
> >
> > download package/check out fom VCS
> 
> If it is from VCS and the workflow is with patches not checked in then
> why isn't there a debian/source/local-options already?
> 
> > oh, this is V3
> > unapply patches
> > add debian/source/local-options
> > work on package
> 
> Oh, this isn't a V3 packages. Read README.source, read debian/rules,
> read manpage of strange patch system, run debuild and read the log to
> figure out how this black box patches its source,  Works both ways.
> 
> Note that you do not need to unapply patches or care about them at all
> to work on the package. So if you are doing an NMU or preparing a patch
> for the BTS then it is just:
> 
> apt-get source foo
> work on package
> debuild
> test
> # Optionally: Just to be nice and fill out the header
> # This would be improved by the --record-changes discussed earlier
> edit debian/patches/debian-changes-version
> reportbug -A debian/patches/debian-changes-version foo
> (upload NMU)

The problem is that you don't have an underlying VCS here so it's hard
to track what you've changed and split patches when doing more complex
changes. So I'm usually using:

git-import-dsc --download 
# If you want to unapply patches after the build:
/usr/share/doc/git-buildpackage/examples/gbp-configure-unpatched-source

which puts the package in a git repo with all the "git add -p/git
checkout -f/git format-patch" features. But that's probably slightly of
topic.
Cheers,
 -- Guido


> 
> With 1.0 packages you frequently first have to learn about the patch
> system used before you can alter and build the package. That I think is
> the greatest benefit of 3.0 (quilt): For the simple case of quickly
> fixing a bug it is transparent and just works out of the box.
> 
> > apply patches if needed
> 
> That is never needed as building does that as needed. Unless you mean
> going up and down the patch series while you work on the package. That
> you have with 1.0 + patch system as well. No change then.
> 
> > upload
> > rm -fr the package
> >
> > debian/source/local-options doesn't really help me much  Not making the 
> > package source format 3 on the other hand conveniently provides the 
> > workflow I 
> > want in a persistent manner with no recurring effort needed.
> >
> > Scott K
> 
> Hardly persistent. Half the packages will have stuff pre-applied from
> the diff.gz, half the packages will have $random patch system and the
> third half :) will even mix the two.
> 
> I'm not saying 3.0 (quilt) is the ultimate format and I'm not saying
> nobody should still use 1.0. But please don't call the 1.0 packages we
> have in the archive consistent. If you just mean your own packages then
> you could change them all to have debian/source/local-options in their
> VCS too. If you mean other peoples packages then I don't see how you can
> claim they behave in any persistent manner.
> 
> I think 3.0 (quilt) made a great step towards unifying the packaging of
> most of the 1.0 packages with a patch system. Nearly all of those can be
> easily changed to 3.0 (quilt) format to get a simple to use, flexible
> (for the maintainer) and uniform (for the user) behaviour. Not all of
> them but that is ok.
> 
> MfG
> Goswin
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/877h94bnst.fsf@frosties.localnet
> 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110602100947.ga17...@bogon.sigxcpu.org

Bug#628915: ITP: doconce -- document once, include anywhere

[Johannes Ring]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

Package name: doconce
Version: 0.5
Upstream authors: Hans Petter Langtangen 
URL: http://doconce.googlecode.com/
License: BSD-3-clause
Description: document once, include anywhere

 Doconce is two things:
 .
 1. Doconce is a very simple and minimally tagged markup language that
 looks like ordinary ASCII text (much like what you would use in an
 email), but the text can be transformed to numerous other formats,
 including HTML, Wiki, LaTeX, PDF, reStructuredText (reST), Sphinx,
 Epytext, and also plain text (where non-obvious formatting/tags are
 removed for clear reading in, e.g., emails). From reStructuredText
 you can go to XML, HTML, LaTeX, PDF, OpenOffice, and from the latter
 to RTF and MS Word.  (An experimental translator to Pandoc is under
 development, and from Pandoc one can generate Markdown, reST, LaTeX,
 HTML, PDF, DocBook XML, OpenOffice, GNU Texinfo, MediaWiki, RTF,
 Groff, and other formats.)
 .
 2. Doconce is a working strategy for never duplicating information.
 Text is written in a single place and then transformed to a number of
 different destinations of diverse type (software source code,
 manuals, tutorials, books, wikis, memos, emails, etc.).  The Doconce
 markup language support this working strategy.  The slogan is: "Write
 once, include anywhere".
 .
 Here are some Doconce features:
 .
  * Doconce markup does include tags, so the format is more tagged
than Markdown and Pandoc, but less than reST, and very much less
than LaTeX and HTML.
  * Doconce can be converted to plain *untagged* text, often desirable
for computer programs and email.
  * Doconce has good support for copying in parts of computer code,
say in examples, directly from the source code files.
  * Doconce has full support for LaTeX math, and integrates very well
with big LaTeX projects (books).
  * Doconce is almost self-explanatory and is a handy starting point
for generating documents in more complicated markup languages,
such as Google Wiki, LaTeX, and Sphinx. A primary application of
Doconce is just to make the initial versions of a Sphinx or Wiki
document.
  * Contrary to the similar Pandoc translator, Doconce integrates with
Sphinx and Google Wiki. However, if these formats are not of
interest, Pandoc is obviously a superior tool.
 .
 Doconce was particularly written for the following sample
 applications:
 .
  * Large books written in LaTeX, but where many pieces (computer
demos, projects, examples) can be written in Doconce to appear in
other contexts in other formats, including plain HTML, Sphinx, or
MS Word.
  * Software documentation, primarily Python doc strings, which one
wants to appear as plain untagged text for viewing in Pydoc, as
reStructuredText for use with Sphinx, as wiki text when publishing
the software at web sites, and as LaTeX integrated in, e.g., a
thesis.
  * Quick memos, which start as plain text in email, then some small
amount of Doconce tagging is added, before the memos can appear as
MS Word documents or in wikis.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktikght5czgxcydjes1p+w9efkhv...@mail.gmail.com

Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Charles Plessy]

Le Thu, Jun 02, 2011 at 11:11:30AM +0200, Goswin von Brederlow a écrit :
> 
> apt-get source foo
> work on package
> debuild
> test
> # Optionally: Just to be nice and fill out the header
> # This would be improved by the --record-changes discussed earlier
> edit debian/patches/debian-changes-version
> reportbug -A debian/patches/debian-changes-version foo
> (upload NMU)

Hi Goswin,

this is how a change of a couple of characters become a much larger patch.  See
for instance the following, which I have received in #606004 (not a NMU).

http://launchpadlibrarian.net/60144486/samtools_0.1.12a-1_0.1.12a-1ubuntu1.diff.gz

64 lines of patch for one line changed in examples/Makefile…

I see that debcheckout now has a --source option with ‘auto’ as a default
value, to “retrieve the remaining parts of the source using apt-get source and
move the files into the checkout” when only the debian directory of a package
is managed in a VCS.  In parallel, the most used patch systems honor the Debian
Policy's §4.9 by providing a ‘patch’ target for debian/rules.  So for many
packages, there is actually a quite uniform entry point.

When working on actively maintained packages, I think that using debcheckout
and committing the changes is more efficient as a whole.

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110602121105.gi14...@merveille.plessy.net

Uploading to multiple distros

[Ian Jackson]

Didier Raboud writes ("Re: Color Management in Debian"):
> Given that Debian is currently not frozen (and that the Oneiric
> release will very probably happen before Wheezy's), I really think
> that not uploading those packages to Debian first would be a shame,
> as this would only mean doubling efforts.

As a structural matter I think it's wrong to have either Debian or
Ubuntu end up being blocked on the other, if it can be avoided.  One
of the ways that free software really works well is that it enables
people to get their work done right away and worry about interacting
with others later.

One thing I have done a few times is to upload the very same package
simultaneously to (say) Debian and Ubuntu.

Where the package wants to be identical, and the person doing the
upload is the same, it would be nice if this could be made simpler.
At the moment you basically need to build the whole thing twice with
minor edits to the changelog to set the target suite.

It would be nice if this could be made simpler.  In principle it would
be nice if you could use the same .changes file for uploading to two
distros (provided that only one of them wants binaries) but that may
be too much to ask.

At the very least it should be possible to do one upload to two
distros without altering the debian/changelog.

For this to work I think the "suite" target in the changelog entry
should be qualified by the distro, so you could say (picking a random
example):

  picocom (1.4-1) debian:unstable ubuntu:oneiric; urgency=low

* new upstream version:
  - Changed the behavior of the C-a command. Now pressing C-a
   twice sends C-a to the serial port
  - Added the C-\ command that generates a break sequence
  - Added (optional) UUCP-lockfiles support

   -- Oliver Kurth   Tue, 14 Sep 2004 11:25:07 -0700

or something.

What do people think ?

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19943.32760.612045.586...@chiark.greenend.org.uk

Re: Uploading to multiple distros

[Iain Lane]

On Thu, Jun 02, 2011 at 01:20:08PM +0100, Ian Jackson wrote:

Didier Raboud writes ("Re: Color Management in Debian"):

Given that Debian is currently not frozen (and that the Oneiric
release will very probably happen before Wheezy's), I really think
that not uploading those packages to Debian first would be a shame,
as this would only mean doubling efforts.


[...]

At the very least it should be possible to do one upload to two
distros without altering the debian/changelog.

For this to work I think the "suite" target in the changelog entry
should be qualified by the distro, so you could say (picking a random
example):

 picocom (1.4-1) debian:unstable ubuntu:oneiric; urgency=low

   * new upstream version:
 - Changed the behavior of the C-a command. Now pressing C-a
   twice sends C-a to the serial port
 - Added the C-\ command that generates a break sequence
 - Added (optional) UUCP-lockfiles support

  -- Oliver Kurth   Tue, 14 Sep 2004 11:25:07 -0700

or something.


You can do this already by using syncpackage(1) from ubuntu-dev-tools — 
I don't think the archive software looks at the changelog, but the 
distribution in the changes file.


For "normal" syncs we generally advise not using syncpackage, but it 
might make sense when doing simultaneous uploads.


This at least works when uploading packages prepared for Debian to 
Ubuntu. I'm not sure how well Debian's infrastructure would cope if the 
changelog specifies an Ubuntu release.


Cheers,
Iain


signature.asc
Description: Digital signature

Re: Semantic change for dpkg triggers?

[Ian Jackson]

Raphael Hertzog writes ("Semantic change for dpkg triggers?"):
> I am considering changing the default behaviour of dpkg triggers. [1]
> Currently when a package activates a trigger (except if it uses
> dpkg-trigger directly with the --no-await option, and that is a minority
> of cases), the trigerring package ends up in "triggers-awaited" status
> and it doesn't satisfy dependencies.
>
> This tends to be not needed and requires trigger processing sooner than
> what's really required in many cases. Thus I am considering to change
> this: the triggering package would directly go to the installed status
> (the old behaviour could be kept if the package implementing the trigger
> switched to another trigger directive named "interest-crucial" for example
> instead of the usual "interest").

In general, the reason for this rule about satisfying dependencies is
that a triggering package may well not be functional at all until the
trigger is run.  For example, if the triggering package T needs to be
registered with the interested package I, a package D which depends on
T may find that T does not work - and D's postinst may fail due to T
being broken.

But I can see that there might be a need for a less-restrictive
trigger, where the functionality which will be provided by trigger
processing is not crucial.  But it seems to me that whether the
functionality is crucial is at least as much a property of the
triggering package, not the interested package.

If a new behaviour is needed, it should have a new name.  Otherwise
you break existing packages.

So I would suggest:

 * New trigger directive "trigger-noawait", works like 
   dpkg-trigger --no-await 

But we do also need a way to do this for file triggers:

 * New trigger directive "interest-filenoawait" which has the
   following semantics:
  - when triggered explicitly by name by a triggering package,
the triggering package awaits the trigger unless the
triggering package specifies --no-await
  - when triggered implicitly by installation of a file, the
triggering package does not await the trigger

> My question is thus: are there triggers currently in use where this
> relaxed behaviour would be wrong? Or more simply are there packages which
> are really not working before the processing of their awaited triggers?

I haven't done a survey but I would expect there to be some.

> Alternatively we could also discuss whether it would make sense
> to change the meaning of the triggers-awaited status to something where
> it would be enough to satisfy dependencies.

That would be wrong IMO.  If triggering without impeding dependencies
is required, simply going straight to "installed" is correct.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19943.33579.996365.262...@chiark.greenend.org.uk

Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Ian Jackson]

Bernhard R. Link writes ("Re: Behaviour of dpkg-source with "3.0 (quilt)" and 
VCS and automatic patches"):
> The more Debian packages you have seen, the more different ways you
> have encountered and the less likely you are to be confused or to
> forget to apply the patches before looking at the source, but as
> much as this kept repelling me from looking deeper into some packages
> even after some years of being DD, I can only imagine how someone not
> so deep into debian development is obstructed by this to help themselves
> and us.

Quite so.  The source code we supply is not there just for our
benefit.  It is also there so that our users can modify the software
to suit themselves, and run the modified versions.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19943.33653.534799.722...@chiark.greenend.org.uk

Bug#628920: O: asunder -- GTK Audio CD ripper and encoder

[Jens Peter Secher]

Package: wnpp
Severity: normal

Asunder is in good shape, upstream is responsive (and would like to not
have his email made public).
-- 
Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1.

A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4d4jt5y.fsf@turing.RAVNEHOLM26

Re: Uploading to multiple distros

[Ian Jackson]

Iain Lane writes ("Re: Uploading to multiple distros"):
> You can do this already by using syncpackage(1) from ubuntu-dev-tools ? 
> I don't think the archive software looks at the changelog, but the 
> distribution in the changes file.

I wasn't aware of syncpackage.  The manpage is quite discouraging.

> For "normal" syncs we generally advise not using syncpackage, but it 
> might make sense when doing simultaneous uploads.

Hrm.  So syncpackage generates a .changes for uploading to ubuntu from
the .dsc (which presumably came out of the Debian build).  That does
mean though that the Ubuntu target suite is not visible in the
changelog of the ultimate Ubuntu package.  And if the package is not
accepted into the Debian archive for any reason, the changelog is very
misleading because it looks like a sync from Debian.

> This at least works when uploading packages prepared for Debian to 
> Ubuntu. I'm not sure how well Debian's infrastructure would cope if the 
> changelog specifies an Ubuntu release.

Debian's archive tools don't look at the changelog either, I think.
But the .changes file is generated from it.  Both Debian and Ubuntu
will reject a .changes file containing unrecognised suites.

One way to enable simultaneous uploads would be to arrange for
dpkg-genchanges to filter out suites for "other" distros when
generating the .changes file.  Then you would have the same files
being uploaded but two different .changes files.

One .changes file would be nice but there are conceptual and practical
problems with it.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19943.34829.69443.412...@chiark.greenend.org.uk

Bug#628923: O: budy -- Binary Decision Diagram library

[Jens Peter Secher]

Package: wnpp
Severity: normal

Package in good shape, very low activity.

-- 
Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1.

A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hb88jryr.fsf@turing.RAVNEHOLM26

Bug#628924: O: changetrack -- automatic log book, recording what files were changed

[Jens Peter Secher]

Package: wnpp
Severity: normal

Package in good shape, very low maintenance.

-- 
Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1.

A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ei3cjrus.fsf@turing.RAVNEHOLM26

Re: Uploading to multiple distros

[Stefano Rivera]

Hi Ian (2011.06.02_14:54:37_+0200)
> I wasn't aware of syncpackage.  The manpage is quite discouraging.

It's discouraging for a reason, the Ubuntu archive admins would prefer
that we sync packages through them if possible (which results in ~1 days
wait). An API method for syncing (+ a button on launchpad) is supposed
to be available really soon now™.

> Hrm.  So syncpackage generates a .changes for uploading to ubuntu from
> the .dsc (which presumably came out of the Debian build).  That does
> mean though that the Ubuntu target suite is not visible in the
> changelog of the ultimate Ubuntu package.  And if the package is not
> accepted into the Debian archive for any reason, the changelog is very
> misleading because it looks like a sync from Debian.

Yes. It tries to do the same thing as the archive admins' sync script.
And obviously it can easily mislead people, which is why it should be
used with care, and has a big warning in the manpage.

> One way to enable simultaneous uploads would be to arrange for
> dpkg-genchanges to filter out suites for "other" distros when
> generating the .changes file.  Then you would have the same files
> being uploaded but two different .changes files.

Excepting the changelog bit, that's effectively what syncpackage does.
It doesn't modify anything except the .changes file, if possible.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110602131914.go14...@bach.rivera.co.za

Bug#628935: O: libcrypto++ -- C++ class library of cryptographic schemes

[Jens Peter Secher]

Package: wnpp
Severity: normal

Package in good shape, upstream responsive and has a Debian guest
account for debugging failures.

-- 
Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1.

A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87boygjrp7.fsf@turing.RAVNEHOLM26

Bug#628936: O: libfile-ncopy-perl -- Perl library for extended file copy functionality

[Jens Peter Secher]

Package: wnpp
Severity: normal

Package has not been touched for years, very low activity upstream.

-- 
Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1.

A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vtkjrge.fsf@turing.RAVNEHOLM26

Re: Uploading to multiple distros

[William Grant]

On 02/06/11 23:19, Stefano Rivera wrote:
> [snip]
>> One way to enable simultaneous uploads would be to arrange for
>> dpkg-genchanges to filter out suites for "other" distros when
>> generating the .changes file.  Then you would have the same files
>> being uploaded but two different .changes files.
> 
> Excepting the changelog bit, that's effectively what syncpackage does.
> It doesn't modify anything except the .changes file, if possible.

Note that you can append the series name to any Launchpad upload path to
override the .changes file. eg. /ubuntu/oneiric will upload to oneiric
in the primary archive, /~wgrant/ppa/ubuntu/oneiric to oneiric in my PPA.

So you *can* use an identical .changes file, if you really want to.

This is deliberately not well documented, and is somewhat discouraged.

William



signature.asc
Description: OpenPGP digital signature

Bug#628937: O: libpam-ssh -- Use SSH keys to login and enable eg. single sign-on

[Jens Peter Secher]

Package: wnpp
Severity: normal

pam-ssh has unclear upstream development, has a lot of Debian changes,
and in general need a firm hand.

-- 
Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1.

A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762oojr86.fsf@turing.RAVNEHOLM26

Bug#628938: O: lua-mode -- Emacs mode for Lua programming

[Jens Peter Secher]

Package: wnpp
Severity: normal

Package in good shape, unclear upstream development.

-- 
Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1.

A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739jsjr5k.fsf@turing.RAVNEHOLM26

Bug#628939: O: neko -- Virtual machine (byte code), interpreter and compiler

[Jens Peter Secher]

Package: wnpp
Severity: normal

Package in good shape, upstream responsive, low activity.

-- 
Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1.

A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkm0ichg.fsf@turing.RAVNEHOLM26

Bug#628941: O: siggen -- Signal generation tools

[Jens Peter Secher]

Package: wnpp
Severity: normal

Package in good shape, very low activity upstream.

-- 
Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1.

A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wrh4icek.fsf@turing.RAVNEHOLM26

Bug#628942: O: sml-mode -- Emacs mode for Standard-ML programming

[Jens Peter Secher]

Package: wnpp
Severity: normal

Package in good shape, very low upstream activity.

-- 
Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1.

A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87tyc8iccc.fsf@turing.RAVNEHOLM26

Bug#628943: O: trayer -- lightweight GTK-based systray

[Jens Peter Secher]

Package: wnpp
Severity: normal

Package in good shape, responsive (new) upstream.

-- 
Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1.

A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r57cic9g.fsf@turing.RAVNEHOLM26

Bug#628948: O: haxe -- Compiler for the Web-oriented haXe programming language

[Jens Peter Secher]

Package: wnpp
Severity: normal

Package in good shape, reposive upstream, although getting stable
upstream sources is little tricky.

The package has pseudo build failures on kFreeBSD because of the way
disks are mounted on the buildds.  I would suggest to simply exclude
kFreeBSD to avoid this hassle because the porters apparently cannot fix
it.

-- 
Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1.

A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87oc2gibrx.fsf@turing.RAVNEHOLM26

Bug#628953: O: mercurial-buildpackage -- Utillities for maintaining a deb package in Hg repository

[Jens Peter Secher]

Package: wnpp
Severity: normal

Native package written by yours truly.  Pristine-tar part does not work
anymore, reason unknown.  Everything is written in haXe, which entails
some problems wrt. Process control & input/output, and I have created a
branch (combined-process-input-output) in which I have started taking
care of these problems, but you will need a good deal of dedication.  I
will help if needed.

-- 
Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1.

A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipsoiarc.fsf@turing.RAVNEHOLM26

Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Scott Kitterman]

On Thursday, June 02, 2011 05:11:30 AM Goswin von Brederlow wrote:
> Scott Kitterman  writes:
> > On Wednesday, June 01, 2011 10:26:59 AM sean finney wrote:
> >> On Wed, Jun 01, 2011 at 02:39:42PM +0200, Goswin von Brederlow wrote:
> >> > And note that as maintainer or for the VCS copy you can allways
> >> > configure debian/soruce/local-options to unapply patches if you so
> >> > desire.
> >> 
> >> This is something i've been doing quite happily and I think it is
> >> a pretty decent compromise for the user/maintainer use cases.
> >> 
> >> If you're building from the VCS there may be a difference in behavior,
> >> but if you build a downloaded source package (or even a source package
> >> generated from the VCS), the behavior is consistant.
> > 
> > I tend to touch many packages and only revisit them infrequently so I
> > don't generally have a local copy of the package to have modified when I
> > start work. So for me the general workflow for using
> > debian/source/local-options would be something like:
> > 
> > download package/check out fom VCS
> 
> If it is from VCS and the workflow is with patches not checked in then
> why isn't there a debian/source/local-options already?
> 
> > oh, this is V3
> > unapply patches
> > add debian/source/local-options
> > work on package
> 
> Oh, this isn't a V3 packages. Read README.source, read debian/rules,
> read manpage of strange patch system, run debuild and read the log to
> figure out how this black box patches its source,  Works both ways.
> 
> Note that you do not need to unapply patches or care about them at all
> to work on the package. So if you are doing an NMU or preparing a patch
> for the BTS then it is just:
> 
> apt-get source foo
> work on package
> debuild
> test
> # Optionally: Just to be nice and fill out the header
> # This would be improved by the --record-changes discussed earlier
> edit debian/patches/debian-changes-version
> reportbug -A debian/patches/debian-changes-version foo
> (upload NMU)
> 
> With 1.0 packages you frequently first have to learn about the patch
> system used before you can alter and build the package. That I think is
> the greatest benefit of 3.0 (quilt): For the simple case of quickly
> fixing a bug it is transparent and just works out of the box.
> 
> > apply patches if needed
> 
> That is never needed as building does that as needed. Unless you mean
> going up and down the patch series while you work on the package. That
> you have with 1.0 + patch system as well. No change then.
> 
> > upload
> > rm -fr the package
> > 
> > debian/source/local-options doesn't really help me much  Not making the
> > package source format 3 on the other hand conveniently provides the
> > workflow I want in a persistent manner with no recurring effort needed.
> > 
> > Scott K
> 
> Hardly persistent. Half the packages will have stuff pre-applied from
> the diff.gz, half the packages will have $random patch system and the
> third half :) will even mix the two.
> 
> I'm not saying 3.0 (quilt) is the ultimate format and I'm not saying
> nobody should still use 1.0. But please don't call the 1.0 packages we
> have in the archive consistent. If you just mean your own packages then
> you could change them all to have debian/source/local-options in their
> VCS too. If you mean other peoples packages then I don't see how you can
> claim they behave in any persistent manner.
> 
> I think 3.0 (quilt) made a great step towards unifying the packaging of
> most of the 1.0 packages with a patch system. Nearly all of those can be
> easily changed to 3.0 (quilt) format to get a simple to use, flexible
> (for the maintainer) and uniform (for the user) behaviour. Not all of
> them but that is ok.

I agree that 3.0 (quilt) has a lot of advantages.  I don't find though that 1.0 
packages are particularly difficult to deal with as a rule.  Most of them 
either 
use no patch system (which I dislike for the same reason I don't like 3.0 
(quilt) applying patches by default) or quilt.  Sometimes I hit packages that 
still use dpatch or the CDBS simple patchsys.  These are easy enough to deal 
with using *-edit-patch.  Then there are a few odd cases that are difficult, 
but 
they are rare.  So I agree that they aren't consistent, but in practice this 
is easy enough to deal with.

When making a new package with modern DH based rules integrating quilt into a 
package is trivially simple, so ease of having quilt as your patch system 
really isn't an argument for 3.0 (quilt).

If 3.0 (quilt) didn't apply patches by default I'd have no reason not to just 
use it.  Keeping local_options in a VCS is a bit of a workaround for this, but 
it seems wrong to have a persistent diff between what's in the VCS for a 
package and what's in the archive.  I'd really like to have a way to just 
control this globally on my system.

Scott K


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

Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Stefano Rivera]

Hi Scott (2011.06.02_16:30:13_+0200)
> Keeping local_options in a VCS is a bit of a workaround for this
...
> I'd really like to have a way to just control this globally on my system.

+1 to that. Esp for team-maintained packages where people have different
preferences, and QA work.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110602145032.gp14...@bach.rivera.co.za

Re: Uploading to multiple distros

[Martin Owens]

On Thu, 2011-06-02 at 13:20 +0100, Ian Jackson wrote:
> For this to work I think the "suite" target in the changelog entry
> should be qualified by the distro, so you could say (picking a random
> example):
> 
>   picocom (1.4-1) debian:unstable ubuntu:oneiric; urgency=low
> 
> * new upstream version: 

Why not just make ppa uploading simpler at the same time? (if you can
change the changelog file processing):

picocom (1.4-1) debian:unstable oneiric natty maverick lucid;
urgency=low

Instead of pushing 6 different packages, we could push just the one.
Have the tools search for a match and build for that archive.

Martin,


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1307025634.3781.122.camel@delen

Re: Uploading to multiple distros

[Cristian Henzel]

I had this very same discussion with another packager and we came to the same
conclusion: changing stuff around a bit to make uploading to multiple
distributions easier, would greatly help packagers IMO.

One thing I would welcome, if possible, would be conditional build-deps, so that
you can set different build-deps for Debian/Ubuntu for example. I'm saying this
because my package for example depends on 'libappindicator-dev' in Ubuntu, but I
can't set this dependency in Debian, because that package doesn't exist there
(yet). Also, from what I've seen there are some packages which have different
names in Ubuntu/Debian, so a conditional build-depends might make
synchronisation of packages between different distributions a bit easier.
Now, one could also check how many packages actually *do* have different
build-depends fields in Ubuntu compared to Debian (not sure how I could do that)
to see how useful of an addition this would be.

For the changelog part, I thought *not* requiring a specific suite would also be
a good compromise. Then, in the case that a suite isn't specified, each
distribution would have a 'default' suite, where this package would be uploaded,
in Debian it might make sense to set 'sid' to default and in Ubuntu, the current
development version. Then, you only need to set a suite when you build the
package for a specific suite, and can have the 'default' package the same for
multiple distros.

-- 

Best regards,
Mit freundlichen Grüßen,

Cristian Henzel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de7a60d.2050...@b3r3.info

Re: Uploading to multiple distros

[Peter Samuelson]

[Ian Jackson]
> Hrm.  So syncpackage generates a .changes for uploading to ubuntu from
> the .dsc (which presumably came out of the Debian build).  That does
> mean though that the Ubuntu target suite is not visible in the
> changelog of the ultimate Ubuntu package.  And if the package is not
> accepted into the Debian archive for any reason, the changelog is very
> misleading because it looks like a sync from Debian.

Since syncs from Debian are actually supposed to be the majority of
packages in Ubuntu anyway, why not just do that - a real sync, not a
fake simultaneous one.  I don't live in the Ubuntu dev universe, but
given how common of an operation this apparently is, I'd think the
tool(s) to do it would be mature and easy to use.  Sure, you have to
wait a few minutes until you get your ACCEPTED mail from dak, but what
of it?  The mail is your reminder to finish the job.

(And if the 'sync from debian' process can't pull your .dsc out of
incoming, that's something I imagine would be easy enough to add.)

> One way to enable simultaneous uploads would be to arrange for
> dpkg-genchanges to filter out suites for "other" distros when
> generating the .changes file.  Then you would have the same files
> being uploaded but two different .changes files.

I suppose you mean put that functionality into this syncpackage thing.
Because otherwise you're still going to need to run dpkg-genchanges
twice, once presumably by hand with some sort of suite override switch,
and that does rather break the abstractions of debian/rules, debhelper,
and the like.

-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110602152809.ga4...@p12n.org

Re: Uploading to multiple distros

[Steve Langasek]

On Thu, Jun 02, 2011 at 03:19:14PM +0200, Stefano Rivera wrote:
> Hi Ian (2011.06.02_14:54:37_+0200)
> > I wasn't aware of syncpackage.  The manpage is quite discouraging.

> It's discouraging for a reason, the Ubuntu archive admins would prefer
> that we sync packages through them if possible (which results in ~1 days
> wait). An API method for syncing (+ a button on launchpad) is supposed
> to be available really soon now™.

Proof of concept for the button was shown around at the last UDS in early
May.  So we're hopeful that "really soon now™" is measured in weeks.

> > Hrm.  So syncpackage generates a .changes for uploading to ubuntu from
> > the .dsc (which presumably came out of the Debian build).  That does
> > mean though that the Ubuntu target suite is not visible in the
> > changelog of the ultimate Ubuntu package.  And if the package is not
> > accepted into the Debian archive for any reason, the changelog is very
> > misleading because it looks like a sync from Debian.

> Yes. It tries to do the same thing as the archive admins' sync script.

It tries, but it does not succeed, which is why the archive admins
discourage its use.

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


signature.asc
Description: Digital signature

Re: Uploading to multiple distros

[Iain Lane]

On Thu, Jun 02, 2011 at 01:54:37PM +0100, Ian Jackson wrote:

[...]
Hrm.  So syncpackage generates a .changes for uploading to ubuntu from
the .dsc (which presumably came out of the Debian build).  That does
mean though that the Ubuntu target suite is not visible in the
changelog of the ultimate Ubuntu package.  And if the package is not
accepted into the Debian archive for any reason, the changelog is very
misleading because it looks like a sync from Debian.


Yes, this is one reason why it's probably better to wait for acceptance 
into Debian first before uploading anywhere else. NEW delays really 
are rather short these days in my experience so in all but the most 
urgent cases that would be the right thing to do.


Anyway, unless you're proposing changing the version string based on 
target distribution there is going to be confusion regardless IMO. It's 
simpler to just rebuild the source package with an Ubuntu changelog 
entry or wait the couple of days to sync. :-)


Regards,
Iain


signature.asc
Description: Digital signature

Re: Uploading to multiple distros

[Matt Zimmerman]

On Thu, Jun 02, 2011 at 01:54:37PM +0100, Ian Jackson wrote:
> Iain Lane writes ("Re: Uploading to multiple distros"):
> > For "normal" syncs we generally advise not using syncpackage, but it 
> > might make sense when doing simultaneous uploads.
> 
> Hrm.  So syncpackage generates a .changes for uploading to ubuntu from
> the .dsc (which presumably came out of the Debian build).  That does
> mean though that the Ubuntu target suite is not visible in the
> changelog of the ultimate Ubuntu package.

That's true for most Ubuntu packages anyway, since the source packages are
copied unmodified from Debian.  We've accepted this since the beginning, as
it's certainly not worth modifying the package just to have this be correct.

It's similar to how in Debian, the changelog says the package was uploaded
to unstable but now it's in testing or stable having propagated there
unmodified.

> And if the package is not accepted into the Debian archive for any reason,
> the changelog is very misleading because it looks like a sync from Debian.

True, but perhaps harmless.

> > This at least works when uploading packages prepared for Debian to 
> > Ubuntu. I'm not sure how well Debian's infrastructure would cope if the 
> > changelog specifies an Ubuntu release.
> 
> Debian's archive tools don't look at the changelog either, I think.
> But the .changes file is generated from it.  Both Debian and Ubuntu
> will reject a .changes file containing unrecognised suites.
> 
> One way to enable simultaneous uploads would be to arrange for
> dpkg-genchanges to filter out suites for "other" distros when
> generating the .changes file.  Then you would have the same files
> being uploaded but two different .changes files.

Yes, it seems like it would be straightforward enough to generate two
appropriate .changes files for this case, and it would do the right thing.

-- 
 - mdz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110602165233.gc19...@alcor.net

British Chambers of Commerce Email: Strike action in current economic climate misguided

[anndesmo]

Hello,

My name is Anna Desmond, I saw your profile today through the help of chamber 
of commerce in Bamako the capital of Mali) and became interested in you, I will 
also like to know you the more,and I want you to send an email to my email 
address so I can give you my picture for you to know whom i am. Please i am 
waiting for your mail reply urgently. Remember that distance or color does not 
matter but love matters a lot in life

Best regards

Anna Desmond

Miss Anna Desmond saw this article on British Chambers of Commerce and thought 
you should see it.

Strike action in current economic climate misguided
Commenting on the decision by Council workers to hold walkouts in a dispute 
over pay
http://www.britishchambers.org.uk/zones/policy/press-releases_1/strike-action-in-current-economic-climate-misguided.html



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/opteronblade1ebbsvj001a6...@smtp.feedrrr.com

Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Goswin von Brederlow]

Guido Günther  writes:

> On Thu, Jun 02, 2011 at 11:11:30AM +0200, Goswin von Brederlow wrote:
>> Scott Kitterman  writes:
>> 
>> > On Wednesday, June 01, 2011 10:26:59 AM sean finney wrote:
>> >> On Wed, Jun 01, 2011 at 02:39:42PM +0200, Goswin von Brederlow wrote:
>> >> > And note that as maintainer or for the VCS copy you can allways
>> >> > configure debian/soruce/local-options to unapply patches if you so
>> >> > desire.
>> >> 
>> >> This is something i've been doing quite happily and I think it is
>> >> a pretty decent compromise for the user/maintainer use cases.
>> >> 
>> >> If you're building from the VCS there may be a difference in behavior,
>> >> but if you build a downloaded source package (or even a source package
>> >> generated from the VCS), the behavior is consistant.
>> >
>> > I tend to touch many packages and only revisit them infrequently so I 
>> > don't 
>> > generally have a local copy of the package to have modified when I start 
>> > work.  
>> > So for me the general workflow for using debian/source/local-options would 
>> > be 
>> > something like:
>> >
>> > download package/check out fom VCS
>> 
>> If it is from VCS and the workflow is with patches not checked in then
>> why isn't there a debian/source/local-options already?
>> 
>> > oh, this is V3
>> > unapply patches
>> > add debian/source/local-options
>> > work on package
>> 
>> Oh, this isn't a V3 packages. Read README.source, read debian/rules,
>> read manpage of strange patch system, run debuild and read the log to
>> figure out how this black box patches its source,  Works both ways.
>> 
>> Note that you do not need to unapply patches or care about them at all
>> to work on the package. So if you are doing an NMU or preparing a patch
>> for the BTS then it is just:
>> 
>> apt-get source foo
>> work on package
>> debuild
>> test
>> # Optionally: Just to be nice and fill out the header
>> # This would be improved by the --record-changes discussed earlier
>> edit debian/patches/debian-changes-version
>> reportbug -A debian/patches/debian-changes-version foo
>> (upload NMU)
>
> The problem is that you don't have an underlying VCS here so it's hard
> to track what you've changed and split patches when doing more complex
> changes. So I'm usually using:

It automatically tracks what you've changed every time you build a
source package. That part is automatic.

Splitting the changes into suitable patches is another matter. The
easiest is to work on one thing at a time and rename the automatically
generated patch after each. If you do it all at once then you have to
split the resulting mess yourself.

But that is no worse than getting all the changes in the diff.gz and
having to split that into suitable patches.

> git-import-dsc --download 
> # If you want to unapply patches after the build:
> /usr/share/doc/git-buildpackage/examples/gbp-configure-unpatched-source
>
> which puts the package in a git repo with all the "git add -p/git
> checkout -f/git format-patch" features. But that's probably slightly of
> topic.
> Cheers,
>  -- Guido

Yes. Evil attempt to do some product placement. :)

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r57ckt9g.fsf@frosties.localnet

Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Goswin von Brederlow]

Charles Plessy  writes:

> Le Thu, Jun 02, 2011 at 11:11:30AM +0200, Goswin von Brederlow a écrit :
>> 
>> apt-get source foo
>> work on package
>> debuild
>> test
>> # Optionally: Just to be nice and fill out the header
>> # This would be improved by the --record-changes discussed earlier
>> edit debian/patches/debian-changes-version
>> reportbug -A debian/patches/debian-changes-version foo
>> (upload NMU)
>
> Hi Goswin,
>
> this is how a change of a couple of characters become a much larger patch.  
> See
> for instance the following, which I have received in #606004 (not a NMU).
>
> http://launchpadlibrarian.net/60144486/samtools_0.1.12a-1_0.1.12a-1ubuntu1.diff.gz
>
> 64 lines of patch for one line changed in examples/Makefile…

That is what happens if you blindly send a debdiff. Also no change
compared to a 1.0 + patchsystem package. The debdiff for 1.0 + quilt
would look exactly the same. For dpatch too iirc, or maybe 5 lines less.

The right thing to do would have been to fill out the patch header
properly and send just the patch. For both 1.0 and 3.0 format.

> I see that debcheckout now has a --source option with ‘auto’ as a default
> value, to “retrieve the remaining parts of the source using apt-get source 
> and
> move the files into the checkout” when only the debian directory of a 
> package
> is managed in a VCS.  In parallel, the most used patch systems honor the 
> Debian
> Policy's §4.9 by providing a ‘patch’ target for debian/rules.  So for 
> many
> packages, there is actually a quite uniform entry point.
>
> When working on actively maintained packages, I think that using debcheckout
> and committing the changes is more efficient as a whole.
>
> Cheers,

In which case you get the debian/source/local-options and the proper
patched or not patched behaviour depending on what the VCS system
workflow is using. So again. It makes no difference wether it is 1.0 or
3. format in that case.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxi0ksv2.fsf@frosties.localnet

Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Goswin von Brederlow]

Stefano Rivera  writes:

> Hi Scott (2011.06.02_16:30:13_+0200)
>> Keeping local_options in a VCS is a bit of a workaround for this
> ...
>> I'd really like to have a way to just control this globally on my system.
>
> +1 to that. Esp for team-maintained packages where people have different
> preferences, and QA work.
>
> SR

+1 for the global thing. But an alias can do that for the initial
unpacking of source packages.

But if you are working with a VCS then I don't think this has anything
to do with peoples preferences but with the workflow of the VCS. Wether
sources are commited with patches applied or not. Having the patch
behaviour differ from the workflow of the VCS is just trouble.

And I hope all team-maintained packages do use some VCS.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipsoksnr.fsf@frosties.localnet

Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Goswin von Brederlow]

Scott Kitterman  writes:

> If 3.0 (quilt) didn't apply patches by default I'd have no reason not to just 
> use it.  Keeping local_options in a VCS is a bit of a workaround for this, 
> but 
> it seems wrong to have a persistent diff between what's in the VCS for a 
> package and what's in the archive.  I'd really like to have a way to just 
> control this globally on my system.

You have .git/.svn/.hg/CVS in your VCS and working directory but not in
the debian package. Or .*tags and .*ignore files and probably a bunch of
others. Only difference for local_options is that it isn't a hidden file
in the top dir.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ei3cksid.fsf@frosties.localnet

Re: Uploading to multiple distros

[Dustin Kirkland]

On Thu, Jun 2, 2011 at 8:20 AM, Ian Jackson
 wrote:
...
> One thing I have done a few times is to upload the very same package
> simultaneously to (say) Debian and Ubuntu.
>
> Where the package wants to be identical, and the person doing the
> upload is the same, it would be nice if this could be made simpler.
> At the moment you basically need to build the whole thing twice with
> minor edits to the changelog to set the target suite.
>
> It would be nice if this could be made simpler.  In principle it would
> be nice if you could use the same .changes file for uploading to two
> distros (provided that only one of them wants binaries) but that may
> be too much to ask.
>
> At the very least it should be possible to do one upload to two
> distros without altering the debian/changelog.

I handle this using a set of scripts in Ubuntu's bikeshed package:
 * http://manpg.es/release-build
 * http://manpg.es/release

'release-build' builds me one binary package, which I test locally,
and gives me instructions on what to do next, if I want to proceed
with the upstream release and upload to a bunch of different places
simultaneously.  It also builds source packages for each of the
supported Ubuntu releases.  If my testing goes well, I'm informed to
run the 'release' command.

'release' then does a handful of things (like tagging the release,
bumping and opening the next version), and prints a series of commands
that I run manually, if I want to actually do the release (such as the
bzr push to the trunk, lp-project-upload to put the tarball on
Launchpad, dput of the backport changes file to that package's PPA,
and dput to Ubuntu Oneiric).  (If I had Debian Maintainer privileges,
I'd also simultaneously dput to Debian too).  I just used
release-test, release-build, and release to publish bikeshed-1.15, and
captured its log here:
 * http://paste.ubuntu.com/616969/

These helpers allow me to consistently release dozens of open source
projects simultaneously to the current development series of Ubuntu,
but also publish "backports" to PPAs of that same package for
Lucid/Maverick/Natty.  They keep me from making many of the most
common mistakes and allow me to upload pretty effortlessly.

These scripts are a little Ubuntu/Launchpad/Bzr specific, so I'm not
advocating their use to you (Debian), but acknowledging and supporting
Ian's suggestion to solve some duplication of effort!

-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktikd1xrgsjgotbobhrpih81resl...@mail.gmail.com

Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Scott Kitterman]

On Thursday, June 02, 2011 02:17:14 PM Goswin von Brederlow wrote:
> Scott Kitterman  writes:
> > If 3.0 (quilt) didn't apply patches by default I'd have no reason not to
> > just use it.  Keeping local_options in a VCS is a bit of a workaround
> > for this, but it seems wrong to have a persistent diff between what's in
> > the VCS for a package and what's in the archive.  I'd really like to
> > have a way to just control this globally on my system.
> 
> You have .git/.svn/.hg/CVS in your VCS and working directory but not in
> the debian package. Or .*tags and .*ignore files and probably a bunch of
> others. Only difference for local_options is that it isn't a hidden file
> in the top dir.
> 
True, but that's part of the internal structure of the VCS.  This isn't so I 
see it as different.

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201106021710.17035.deb...@kitterman.com

Re: Uploading to multiple distros

[Barry Warsaw]

On Jun 02, 2011, at 10:28 AM, Peter Samuelson wrote:

>Since syncs from Debian are actually supposed to be the majority of
>packages in Ubuntu anyway, why not just do that - a real sync, not a
>fake simultaneous one.  I don't live in the Ubuntu dev universe, but
>given how common of an operation this apparently is, I'd think the
>tool(s) to do it would be mature and easy to use.  Sure, you have to
>wait a few minutes until you get your ACCEPTED mail from dak, but what
>of it?  The mail is your reminder to finish the job.

How can we help Ubuntu developers do the right thing?  Are there tools,
processes, or documentation that we can develop that would make it easy(er)
for someone who works on an Ubuntu machine, is well versed in Ubuntu culture
(processes, tools, etc), to integrate with Debian?

-Barry


signature.asc
Description: PGP signature

Bug#629001: ITP: libxml-atom-microformats-perl -- parse microformats in Atom content

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: libxml-atom-microformats-perl
  Version : 0.002
  Upstream Author : Toby Inkster 
* URL : http://search.cpan.org/dist/XML-Atom-Microformats/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : parse microformats in Atom content

 The XML::Atom::Microformats module brings the functionality of
 HTML::Microformats to Atom 1.0 Syndication feeds. It finds microformats
 embedded in the  elements (note: not ) of Atom
 entries.
 .
 The general pattern of usage is to create an XML::Atom::Microformats
 object (which corresponds to an Atom 1.0 feed) using the "new_feed"
 method; then ask for the data, as a Perl hashref, a JSON string, or an
 RDF::Trine model.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110602221204.24497.2943.reportbug@localhost.localdomain

Re: Uploading to multiple distros

[Andres Rodriguez]

>
>
> I handle this using a set of scripts in Ubuntu's bikeshed package:
>  * http://manpg.es/release-build
>  * http://manpg.es/release


+1! I have been using these scripts extensively to do my releases, and
preparing the packages to upload them into the archive or
PPA's. Specifically for TestDrive and PowerNap. A common example is
PowerNap, on which I use these scripts to prepare a release, test it, and
once I'm satisfied, I upload them to the PPA's without having to do manual
modifications to the changelogs and being able to easily release a backport
in PPA for PowerNap.

These scripts are a little Ubuntu/Launchpad/Bzr specific, so I'm not
> advocating their use to you (Debian), but acknowledging and supporting
> Ian's suggestion to solve some duplication of effort!
>

I agree with you Dustin that the use of scripts like this can resolve some
duplication! Even though they don't work with Debian itself, I don't see the
problem of adapting them to handle both cases and then making life easier
for everybody!

-- 
Andres Rodriguez (RoAkSoAx)
Ubuntu Server Developer
Systems Engineer

Re: Uploading to multiple distros

[Brian May]

On 3 June 2011 01:02, Cristian Henzel  wrote:

> For the changelog part, I thought *not* requiring a specific suite would
> also be
> a good compromise.


Why do we even bother putting the suite into the changelog? I don't see the
point myself.

I believe it is the DISTRIBUTION header in the changes file that matters,
the changelog value is only used as a default for the DISTRIBUTION header
(unless overridden in the build process).

Once the file is uploaded, the value is not used again, and may become
obsolete, e.g. as the package migrates from unstable to stable.

Personally, my build script sets the DISTRIBUTION header automatically based
on the chroot I build the package in.
-- 
Brian May 

Re: Uploading to multiple distros

[Robert Collins]

On Fri, Jun 3, 2011 at 2:40 AM, Martin Owens  wrote:
> On Thu, 2011-06-02 at 13:20 +0100, Ian Jackson wrote:
>> For this to work I think the "suite" target in the changelog entry
>> should be qualified by the distro, so you could say (picking a random
>> example):
>>
>>   picocom (1.4-1) debian:unstable ubuntu:oneiric; urgency=low
>>
>>     * new upstream version:
>
> Why not just make ppa uploading simpler at the same time? (if you can
> change the changelog file processing):
>
> picocom (1.4-1) debian:unstable oneiric natty maverick lucid;
> urgency=low
>
> Instead of pushing 6 different packages, we could push just the one.
> Have the tools search for a match and build for that archive.

The challenge with ppas here  is that a package can only be built once
in a given archive: the binary package names are the same for all of
unstable/oneiric/natty/maverick/lucid : the APT archive which makes up
a PPA cannot present different binary versions for each series.

We could build only in lucid and then promote the package forward (the
same as doing a 'binary + source copy' between
lucid->maverick->natty->oneiric. For many packages though, that will
run into various dependency / toolchain hell issues - particularly
because source packages tend to be updated to build with the latest
dpkg/debhelper etc, rather than staying geared to build with lucids
dpkg.
-Rob


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTinm+4q4BG_X3peEPHFnpPv=aqp...@mail.gmail.com

Re: Uploading to multiple distros

[Evan Broder]

On Thu, Jun 2, 2011 at 6:05 PM, Robert Collins
 wrote:
> On Fri, Jun 3, 2011 at 2:40 AM, Martin Owens  wrote:
>> Why not just make ppa uploading simpler at the same time? (if you can
>> change the changelog file processing):
>>
>> picocom (1.4-1) debian:unstable oneiric natty maverick lucid;
>> urgency=low
>>
>> Instead of pushing 6 different packages, we could push just the one.
>> Have the tools search for a match and build for that archive.
>
> The challenge with ppas here  is that a package can only be built once
> in a given archive: the binary package names are the same for all of
> unstable/oneiric/natty/maverick/lucid : the APT archive which makes up
> a PPA cannot present different binary versions for each series.

Hmm...a lot of this discussion seems to be getting caught up in the
ubuntu-devel moderation queue, but I'll try to guess context as best
as I can...

If you want to upload a package to a PPA for a bunch of versions
simultaneously, I'd recommend my backportpackage script in
ubuntu-dev-tools. You can do something like

  backportpackage --destination natty --destination maverick
--destination lucid --upload ppa:broder/ppa picocom_1.4-1.dsc

Or instead of a .dsc, you can give it a --source release (e.g.
oneiric) and a package name. It handles bumping (well, dropping) the
package version number appropriately (e.g. ~natty1). It can also build
locally (--build/-b) and save the build products (-w WORKDIR)

It will still push 3 different packages, but the generation and upload
process is totally automated, and it avoids issues with version
numbers, toolchains, and upgrades.

- Evan


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktimqvqszuheorr3urjb_1etndtb...@mail.gmail.com

Texas Invitation Mailing List Unsubscription Confirmation

[Texas Invitation]

This message has been sent to you as the final step to confirm your
email *removal* for the following list: 

Texas Invitation

To confirm this unsubscription, please follow the URL below:

http://hsvpp.com/cgi-bin/dada/mail.cgi/u/txinvite/debian-devel/lists.debian.org/5BcIX2RokH8d2/

(Click the URL above, or copy and paste the URL into your browser. 
Doing so will remove you to this list.)

---

The following is the description given for this list: 

This list is used to promote home lot sales in Hot Springs Village, AR. 
Subscribers to this list ARE entered in the 6th Annual Home Site Give Away. No 
purchase, attendance, or participation is required.  

---

This Closed-Loop Opt-Out confirmation email was sent to protect the privacy
of the owner of this email address. 

Furthermore, the following privacy policy is associated with this list: 

This list is the SOLE property of HSVPP Inc. The names and data on this list 
will not be shared, sold or rented in anyway. 

Please read and understand this privacy policy. 

If you did not ask to be removed from this particular list, please
do not visit the confirmation URL above. The confirmation for removal 
will not go through and no other action on your part will be needed.

To contact the owner of this email list, please use the address below: 



The following physical address is associated with this mailing list: 

HSVPPI, 
7024 Arch Street, 
Little Rock, AR 72206
501-350-0227


- 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110602210957.48429...@hot-springs-village.net

Bug#629029: general: Screen scrambled up after hibernation wake up

[etienne]

Package: general
Severity: important


  Hello,

after the 2nd or 3rd wake up from hibernation, the screen is all  
scrambled and I have to reboot the computer (maybe killing X would be  
sufficient but in either case, my session goes down the drain).


   Etienne

P.S. Thanks for making Debian!

-- System Information:
Debian Release: 6.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



This message was sent using IMP, the Internet Messaging Program.




--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110602210958.13004140zkmzh...@webmail.isr.ist.utl.pt

Re: Semantic change for dpkg triggers?

[Raphael Hertzog]

Hi,

On Thu, 02 Jun 2011, Ian Jackson wrote:
> If a new behaviour is needed, it should have a new name.  Otherwise
> you break existing packages.

I know this. This is precisely why I'm asking the question of which
packages require this behaviour. If none or very few require it, I might
consider doing the change with the current name and provide new names
for the old behaviour.

Just for reference, if you review my patch at
http://anonscm.debian.org/gitweb/?p=users/hertzog/dpkg.git;a=commitdiff;h=c98b69d76f78114afd344b9dc0aef47c6f3fe00b
...

> So I would suggest:
> 
>  * New trigger directive "trigger-noawait", works like 
>dpkg-trigger --no-await 

...you will notice this is called "activate-noawait"

> But we do also need a way to do this for file triggers:
> 
>  * New trigger directive "interest-filenoawait" which has the
>following semantics:
>   - when triggered explicitly by name by a triggering package,
> the triggering package awaits the trigger unless the
> triggering package specifies --no-await
>   - when triggered implicitly by installation of a file, the
> triggering package does not await the trigger

this is called "interest-noawait" except that I have made no difference
when the file trigger is explicitly called by dpkg-trigger. I don't see a
good reason for this.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110603065709.gi13...@rivendell.home.ouaza.com