Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

dpkg-source again broken wrt to 3.0 (quilt)???

197 views
Skip to first unread message

Norbert Preining

unread,
Jan 17, 2012, 8:00:01 PM1/17/12
to
Hi everyone,

maybe its just me, but I cannot get the hang of that 3.0 (quilt)
and pre/post applying patches.

Recently I prepared a NMU for less to finally fix the missing xz(tar.xz)
support, added a new patch, but it is *impossible* for me to build
a package. Irrelevant wether the patches were applied beforehand
or not, dpkg-buildpackage always ends up in trying to apply them TWO
times, which of course does not work.

Here a terminal log:
$ dpkg-buildpackage -us -uc -rfakeroot
dpkg-buildpackage: source package less
dpkg-buildpackage: source version 444-1.1
dpkg-buildpackage: source changed by Norbert Preining <prei...@debian.org>
dpkg-buildpackage: host architecture amd64
dpkg-source --before-build less-444
dpkg-source: info: using options from less-444/debian/source/options: --compression=bzip2 --compression-level=9
dpkg-source: info: patches are not applied, applying them now
dpkg-source: info: applying 01-434417-LESS_IS_MORE.patch
dpkg-source: info: applying less-support-xz.patch
fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp
# Add here commands to clean up after the build process.
[ ! -f Makefile ] || /usr/bin/make distclean
dh_clean
rm -f debian/less.substvars
rm -f debian/less.*.debhelper
rm -rf debian/less/
rm -f debian/*.debhelper.log
rm -f debian/files
find . \( \( -type f -a \
\( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
-o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
-o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \
-o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \
\) -exec rm -f {} \; \) -o \
\( -type d -a -name autom4te.cache -prune -exec rm -rf {} \; \) \)
rm -f *-stamp
dpkg-source -b less-444
dpkg-source: info: using options from less-444/debian/source/options: --compression=bzip2 --compression-level=9
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building less using existing ./less_444.orig.tar.bz2
patching file debian/lesspipe.1
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file debian/lesspipe.1.rej
patching file debian/lesspipe
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file debian/lesspipe.rej
dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -E -b -B .pc/less-support-xz.patch/ < less-444.orig.kWo0pm/debian/patches/less-support-xz.patch gave error exit status 1
dpkg-buildpackage: error: dpkg-source -b less-444 gave error exit status 2
$

Well. And if I do pre-apply the patches qith quilt push -a then the same
error happens.

So what is it that dpkg-buildpackage, dpkg-source, and all the quilt 3.0
stuff is soooo braindamaged????

I expect a package to build when I call dpkg-buildpackage, and if the
source format is so super-intelligent to breeak that, than there is
an error in the design.

So, let the flame war start again, or the enlightning procedure. I am open
to explanations.

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
You're bound to be unhappy if you optimize everything.
--- Donald E. Knuth


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012011800...@gamma.logic.tuwien.ac.at

Jakub Wilk

unread,
Jan 17, 2012, 8:20:02 PM1/17/12
to
* Norbert Preining <prei...@logic.at>, 2012-01-18, 09:15:
>dpkg-source: info: using options from less-444/debian/source/options: --compression=bzip2 --compression-level=9
>dpkg-source: info: using source format `3.0 (quilt)'
>dpkg-source: info: building less using existing ./less_444.orig.tar.bz2
>patching file debian/lesspipe.1
>Reversed (or previously applied) patch detected! Skipping patch.
>1 out of 1 hunk ignored -- saving rejects to file debian/lesspipe.1.rej
>patching file debian/lesspipe
>Reversed (or previously applied) patch detected! Skipping patch.
>1 out of 1 hunk ignored -- saving rejects to file debian/lesspipe.rej

Wait, are you patching files inside debian/? That won't fly.

Of course, it would nice if dpkg died earlier (and with a nicer error
message).

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012011801...@jwilk.net

Norbert Preining

unread,
Jan 17, 2012, 9:10:02 PM1/17/12
to
On Mi, 18 Jan 2012, Jakub Wilk wrote:
> Wait, are you patching files inside debian/? That won't fly.

Umpf, and, is that so evil? Esp for a NMU this is *very* good
as it allows to see what the changes of the NMU are ...

Not that I am patching debian/control or debina/rules ...

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
BERKHAMSTED
The massive three-course midmorning blow-out enjoyed by a dieter who
has already done his or her slimming duty by having a teaspoonful of
cottage cheese for breakfast.
--- Douglas Adams, The Meaning of Liff


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120118020...@gamma.logic.tuwien.ac.at

Arno Töll

unread,
Jan 17, 2012, 9:20:01 PM1/17/12
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18.01.2012 03:08, Norbert Preining wrote:
> Umpf, and, is that so evil? Esp for a NMU this is *very* good
> as it allows to see what the changes of the NMU are ...

debdiff(1)/nmudiff(1). Or just ... diff and don't add it to
debian/patches/series, although that would be quite uncommon.

- --
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPFipXAAoJEMcrUe6dgPNtJqEP/2Kg1Obmx2r/0yL9h4qFg1sv
cuv0WXXmazP18uyojl/zI6dcVmE9B097MS2B5byjxXi32XqdYNauIcrcOjycRpBD
DouWNGwZR0zNJ8MUC1FZGj3sXdI4rRJTzITI2IJZcOZY/4FtLBzChvafQkxeib29
JSoK6k0GP5x2uAAN4duSQN1kT0MQzIOjPea+jc4k8Hwgvbdv04OWwjLfShuxiUZc
I3BQT1uKkbeKzTnCQMHM712z9ZGpnb/ugVfh4ulvQQs3WB4rOkqWAm7UVHaLFmgz
UvabvCL71etFavTtNoYcT5W/mfqXWEJfWWeeI81H1G4Qx8gIa2aaSsaVobTvs2x7
SxdPgqWTavbzdFo46TIqa1aJo21DqZd/tKwN+YotMyEdUvxxUPcW+MN7PoAzgSDQ
YE6KCvR7wABH1hCFHPPFSo8LQFZNizjYEegnXCAp9AIoOqIDsIkHRO+u6eilFp6w
4OprqVup7TcmzSJuO6EXQevBhIF096vJ0BCMlNf/Sfukp3xRrdb6aYs8BmL1fqLS
o25WDhpkdxTg3R+1wY2BJDrSQvF98vLYya2KuLGlgNxhhAi84qytgvOzs8aiMgFs
njtDvNyuHdisn4LxZbBVsNYXP5irUVYMFb9xjlAAYJqy8ejwJs/s2C+UNU3h0kOa
os+NhEpEoyC2Pf89ZXnI
=IaID
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4F162A57...@toell.net

Raphael Hertzog

unread,
Jan 18, 2012, 2:30:02 AM1/18/12
to
Hi,

On Wed, 18 Jan 2012, Norbert Preining wrote:
> So, let the flame war start again, or the enlightning procedure. I am open
> to explanations.

It would be nice if you could avoid the "flaming tone" in all your mails.
In particular since most of the time it ends up being a mistake of yours.

On Wed, 18 Jan 2012, Norbert Preining wrote:
> On Mi, 18 Jan 2012, Jakub Wilk wrote:
> > Wait, are you patching files inside debian/? That won't fly.
>
> Umpf, and, is that so evil? Esp for a NMU this is *very* good
> as it allows to see what the changes of the NMU are ...

Yes, it's evil. dpkg-source tries to generate a new diff between the
currently unpacked source package and a "pristine" one which it generates
by unpacking the original tarball, copying the debian directory and
applying the patches.

But if the debian directory already contains changes which are part of the
patches, then it will fail trying to re-apply those changes.

There's a lintian error for this if for some reason you still manage to
build it:
http://lintian.debian.org/tags/patch-modifying-debian-files.html

(This was possible with source format "1.0" because there was only one big
patch which is regenerated every time, and because the source was built with
quilt patches unapplied)

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120118072...@rivendell.home.ouaza.com

Bernhard R. Link

unread,
Jan 18, 2012, 3:50:02 AM1/18/12
to
* Norbert Preining <prei...@logic.at> [120118 03:08]:
> On Mi, 18 Jan 2012, Jakub Wilk wrote:
> > Wait, are you patching files inside debian/? That won't fly.
>
> Umpf, and, is that so evil?

One of the problems "3.0 (quilt)" solves is upstream tarballs already
having a debian/ directory. By having the complete debian/ contents
in the .debian.tar.gz and the unpacking replacing any upstream debian
directory with those contents, the maintainer of the Debian package does
not have to care what upstream placed there[1] and any automated tool
looking for debian information (like copyright or changelog) can extract
this information in an easy way from a well specified location [2].

Once you start with the new contents of debian/, what is a patch of
those files supposed to do? Either it is already applied or the package
was not in proper state while building...

> Esp for a NMU this is *very* good
> as it allows to see what the changes of the NMU are ...
>
> Not that I am patching debian/control or debina/rules ...

So you suggest that someone interested at what this NMU does needs to
compare the two debian/ directories (of the old and the new package)
for changes in control, rules and changelog but then read some other
changes of the same directory in the form of a patch places in the
same directory?

I'd say that is the exactly opposite of "allows to see what the changed
of the NMU are".

So to answer you question: Yes, it is that evil.


Bernhard R. Link

[1] especially debhelper likes to behave differently if some file is
there or not, so left over files can have ugly consequences.
[2] the .orig.tar is hard to cope with, as it must allow pristine
upstream files which can have quite a variety and absurdity in them.
And having information split in the form of some content in the one file
and a diff in the other file is hard, too. (You either need to do a full
unpack or restrict to the case the information is either fully in the
one or in the other like e.g. reprepro and changestool do to get Section
and Priority information from a .dsc).


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012011808...@server.brlink.eu

Mehdi Dogguy

unread,
Jan 18, 2012, 4:10:01 AM1/18/12
to
On 18/01/12 03:08, Norbert Preining wrote:
> On Mi, 18 Jan 2012, Jakub Wilk wrote:
>> Wait, are you patching files inside debian/? That won't fly.
>
> Umpf, and, is that so evil? Esp for a NMU this is *very* good as it
> allows to see what the changes of the NMU are ...
>

You're supposed to send a debdiff when NMUing. That's even better to see
what the changes of the NMU are (See devref §5.11.1). Personally, I find
patching files under debian/ directory makes things more difficult to
track (probably because I don't expect to find those changes there).

Regards,

--
Mehdi Dogguy


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4F168BBB...@dogguy.org

Norbert Preining

unread,
Jan 18, 2012, 8:20:02 AM1/18/12
to
On Mi, 18 Jan 2012, Raphael Hertzog wrote:
> It would be nice if you could avoid the "flaming tone" in all your mails.
> In particular since most of the time it ends up being a mistake of yours.

And it would be nice if dpkg-buildpackage gives a decent error message.
What is shipped here is plain incomprehensible.

How should I *guess* that patching files in debian is not allowed in
quilt (3.0), since it was in older versions (I am quite sure you remeber
that) of source standards.

Am I supposed to dig into the source of dpkg-buildpackage/dpkg-source?

> But if the debian directory already contains changes which are part of the
> patches, then it will fail trying to re-apply those changes.

So well, but if out of some crazy reasin I *want* to do that, then
dpkg-* should tell me: Sorry, this is not possible with quilt (3.0),
please go back to 1.0 source format (which was anyway a better IMHO).

Since we are at quilt 3.0 bashing: Maybe you can give me a rational
why I *ALWAYS* have to type in
export QUILT_PATCHES=debian/patches
before working with debian source packages? And when I forget it
I get hurt by quilt?

Is this the *easy*handling* as promised?

And NO, I wil lnot set this by default in my env, since I am working
with quilt in several other projects out of debian, and I cannot afford
getting even worse bitten.

> There's a lintian error for this if for some reason you still manage to
> build it:

No I didn't managed, as I wrote.

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
SHOEBURYNESS (abs.n.) The vague uncomfortable feeling you get when
sitting on a seat which is still warm from somebody else's bottom.
--- Douglas Adams, The Meaning of Liff


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120118131...@gamma.logic.tuwien.ac.at

Stefano Rivera

unread,
Jan 18, 2012, 8:30:02 AM1/18/12
to
Hi Norbert (2012.01.18_15:18:27_+0200)
> Since we are at quilt 3.0 bashing: Maybe you can give me a rational
> why I *ALWAYS* have to type in
> export QUILT_PATCHES=debian/patches
> before working with debian source packages?

Because you haven't set up a .quiltrc? The maint-guide has a really nice
example you can steal.

SR

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


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120118132...@bach.rivera.co.za

Cyril Brulebois

unread,
Jan 18, 2012, 8:40:02 AM1/18/12
to
Norbert Preining <prei...@logic.at> (18/01/2012):
> On Mi, 18 Jan 2012, Raphael Hertzog wrote:
> > It would be nice if you could avoid the "flaming tone" in all your mails.
> > In particular since most of the time it ends up being a mistake of yours.
>
> And it would be nice if dpkg-buildpackage gives a decent error message.
> What is shipped here is plain incomprehensible.

I'd like to echo Raphael's wishes here. Please stop yelling on this
mailing list, and start filing bugs, possibly with patches, to implement
the missing bits.

Mraw,
KiBi.
signature.asc

Jakub Wilk

unread,
Jan 18, 2012, 8:40:02 AM1/18/12
to
* Norbert Preining <prei...@logic.at>, 2012-01-18, 22:18:
>Since we are at quilt 3.0 bashing: Maybe you can give me a rational why
>I *ALWAYS* have to type in
> export QUILT_PATCHES=debian/patches
>before working with debian source packages? And when I forget it I get
>hurt by quilt?

dpkg (>= 1.15.8.6) creates the .pc/.quilt_series file. So no, not always.

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012011813...@jwilk.net

Norbert Preining

unread,
Jan 18, 2012, 8:40:03 AM1/18/12
to
On Mi, 18 Jan 2012, Stefano Rivera wrote:
> Because you haven't set up a .quiltrc? The maint-guide has a really nice
> example you can steal.

Ugg, and call dquilt or quilt --quiltrc=... yeah
I will try to remember that, and will forget it as well as I forget
setting QUILT_PATCHES

Thanks, that was not helpful

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
NOTTAGE (n.)
Nottage is the collective name for things which you find a use for
immediately after you've thrown them away. For instance, your
greenhouse has been cluttered up for years with a huge piece of
cardboard and great fronds of gardening string. You at last decide to
clear all this stuff out, and you burn it. Within twenty-four hours
you will urgently need to wrap a large parcel, and suddenly remember
that luckily in your greenhouse there is some cardb...
--- Douglas Adams, The Meaning of Liff


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120118133...@gamma.logic.tuwien.ac.at

Raphael Hertzog

unread,
Jan 18, 2012, 9:20:02 AM1/18/12
to
On Wed, 18 Jan 2012, Norbert Preining wrote:
> On Mi, 18 Jan 2012, Raphael Hertzog wrote:
> > It would be nice if you could avoid the "flaming tone" in all your mails.
> > In particular since most of the time it ends up being a mistake of yours.
>
> And it would be nice if dpkg-buildpackage gives a decent error message.

[... snip useless flames ...]

> > But if the debian directory already contains changes which are part of the
> > patches, then it will fail trying to re-apply those changes.
>
> So well, but if out of some crazy reasin I *want* to do that, then
> dpkg-* should tell me: Sorry, this is not possible with quilt (3.0),

Please submit a wishlist bug for this.

> Since we are at quilt 3.0 bashing

You decide whether you're doing useless bashing or constructive
discussion... and we would be all better off if you picked the second
choice.

> : Maybe you can give me a rational
> why I *ALWAYS* have to type in
> export QUILT_PATCHES=debian/patches
> before working with debian source packages? And when I forget it
> I get hurt by quilt?

First, this is not true. As pointed out by Jakub, dpkg-source -x sets up
the .pc directory so that quilt knows where to find the series file and
the patches.

Then, for the cases where you end up without this directory, you could
follow the advice of /usr/share/doc/quilt/README.source which provides
a .quiltrc snippet that only sets QUILT_PATCHES if you're within a Debian
source package...

RTFM, man.

> Is this the *easy*handling* as promised?

If you have an unpacked source package with all patches already applied,
the easy handling is to just do your changes and then run "dpkg-source
--commit". It will create and register the patch for you.

> And NO, I wil lnot set this by default in my env, since I am working
> with quilt in several other projects out of debian, and I cannot afford
> getting even worse bitten.

The recommended snippet does avoid this problem...

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120118141...@rivendell.home.ouaza.com

Paul Wise

unread,
Jan 18, 2012, 9:30:02 AM1/18/12
to
On Wed, Jan 18, 2012 at 9:13 AM, Jakub Wilk wrote:

> Wait, are you patching files inside debian/? That won't fly.

I've personally missed this feature for a package I need to patch
outside of Debian. When it was dpkg-source v1 I could just drop in the
patches/series and everything would work. Now with dpkg-source v3 the
patches do not apply and months later I'm still wondering what to do
in this situation.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAKTje6EQffbDCHSHzMG4BfhF...@mail.gmail.com

Neil Williams

unread,
Jan 18, 2012, 10:00:01 AM1/18/12
to
On Wed, 18 Jan 2012 22:24:22 +0800
Paul Wise <pa...@debian.org> wrote:

> On Wed, Jan 18, 2012 at 9:13 AM, Jakub Wilk wrote:
>
> > Wait, are you patching files inside debian/? That won't fly.
>
> I've personally missed this feature for a package I need to patch
> outside of Debian.

This is something I'll need to look at again when Emdebian starts
preparing modified cross-built packages to modify the dependency chain
(Emdebian Crush). Currently that's stalled waiting for MultiArch but
the only reliable way I found to do it is to maintain a separate
debian/ directory in a VCS and apply it to the orig.tar.gz. Maintenance
will be a problem but then getting debian/rules to support minor
variants is also plagued with problems of maintenance because most
maintainers will not (have time to / be able to) build the variants,
let alone test them on device.

One example here is qtembedded. I'm currently keeping a debian/
directory based on the version in Squeeze and it could possibly work as
an alternative build inside the Qt debian packages but it's not a short
build and testing it isn't a small task either. (I failed to get a sane
cross-build out of it, so now have to wait 16hrs for a native build.)
We're maintaining this build out-of-tree for now.

It is useful to have the (unchanged) debian/patches/ to include into the
build for the embedded derivative but in other ways, it is just hard to
do well.

> When it was dpkg-source v1 I could just drop in the
> patches/series and everything would work. Now with dpkg-source v3 the
> patches do not apply and months later I'm still wondering what to do
> in this situation.

However, I disagree with you here, Paul. Patches, especially quilt
patches, to debian/ files are NOT maintainable because you still need
to update the patches when a minor debian revision takes place. i.e.
you need the files to which to make the patches so you might as well
make those files use conditionals within the build to enable that
variant and then you at least have the chance to build the full Debian
version with a simple DEB_BUILD_OPTION for sanity reasons.

ifneq (,$(findstring qtembedded,$(DEB_BUILD_OPTIONS)))

I did a LOT of patching to debian/ for the initial development of
Emdebian Crush based on Lenny and the only way to do it is to base on a
suite which is already frozen, otherwise the patches just fail
almost everytime the maintainer does anything to the package. It just
doesn't scale, so it's better to pick a frozen/stable suite and don't
try to keep up with more than a handful of packages.

In future, there will be no patches applied automatically to existing
Debian packages for Emdebian - we'll work out-of-tree and work on some
kind of conditional / derivative buildd support, possibly related to
the idea of partial architectures and existing work on bootstrap builds.

http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/223-Qt-embedded-armel-for-Emdebian.html

http://lists.debian.org/debian-embedded/2011/10/msg00023.html

http://www.emdebian.org/trac/browser/current/emdebian/trunk/qt4-embedded/trunk/debian

Maintaining a separate tree in VCS is also easy in that various tools
already support it. I used svn-inject with the -o option. Then a
judicious use of meld against apt-get source is enough to add a few
updates for the next build.

Admittedly in the current build, the option is explicitly set for ease
but that's just debug. There are niggles which I'll get around to
filing as bugs once I start doing this seriously again.

What I'd like to see is better support for conditionals in debian/rules
to allow packages like busybox, cairo, curl, openssh and others to be
routinely built with certain optional components turned off or
particular configurations turned on (in the case of busybox) -
possibly only on certain architectures. Yes, those builds may well be
dangerous to install on a regular Debian box (busybox in particular) but
there are still situations where ldap and the like make installation of
standard Debian packages (or packages from Emdebian Grip) completely
infeasible.

http://www.emdebian.org/trac/browser/current/target

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Goswin von Brederlow

unread,
Jan 18, 2012, 10:00:02 AM1/18/12
to
Norbert Preining <prei...@logic.at> writes:

> Hi everyone,
>
> maybe its just me, but I cannot get the hang of that 3.0 (quilt)
> and pre/post applying patches.
>
> Recently I prepared a NMU for less to finally fix the missing xz(tar.xz)
> support, added a new patch, but it is *impossible* for me to build
> a package. Irrelevant wether the patches were applied beforehand
> or not, dpkg-buildpackage always ends up in trying to apply them TWO
> times, which of course does not work.

As others have pointed out the error is this:

> patching file debian/lesspipe.1
> Reversed (or previously applied) patch detected! Skipping patch.
> 1 out of 1 hunk ignored -- saving rejects to file debian/lesspipe.1.rej

No patching of files in debian/.


But that has been said. The reason why I write this mail is to suggest a
change in how you prepare a patch for a 3.0 (quilt) package that will
prevent you from running into this situation alltogether:

Just edit the files directly and build the (source) package.

Dpkg-buildpackage will automatically build (and update on repeated
builds) a debian/patches/debian-changes(-version) patch for you. Then
when you are satisfied that everything is as it should be you rename the
patch (quilt rename this-is-a-patch-for-foo) and edit the patch header to
properly annotate your work.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87ty3t8...@frosties.localnet

Agustin Martin

unread,
Jan 18, 2012, 11:30:01 AM1/18/12
to
On Wed, Jan 18, 2012 at 02:35:23PM +0100, Jakub Wilk wrote:
> * Norbert Preining <prei...@logic.at>, 2012-01-18, 22:18:
> >Since we are at quilt 3.0 bashing: Maybe you can give me a
> >rational why I *ALWAYS* have to type in
> > export QUILT_PATCHES=debian/patches
> >before working with debian source packages? And when I forget it
> >I get hurt by quilt?
>
> dpkg (>= 1.15.8.6) creates the .pc/.quilt_series file. So no, not always.

It is sometimes removed. It is still unclear to me when/why that happens,
guess that dh_quilt_unpatch may be the responsible for that.

Of course, there is the alternative of README.source snippet.

Regards,

--
Agustin


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012011816...@agmartin.aq.upm.es

Russ Allbery

unread,
Jan 18, 2012, 12:10:01 PM1/18/12
to
Norbert Preining <prei...@logic.at> writes:
> On Mi, 18 Jan 2012, Stefano Rivera wrote:

>> Because you haven't set up a .quiltrc? The maint-guide has a really
>> nice example you can steal.

> Ugg, and call dquilt or quilt --quiltrc=... yeah
> I will try to remember that, and will forget it as well as I forget
> setting QUILT_PATCHES

The point of .quiltrc is that you put it in your home directory and forget
about it. /usr/share/doc/quilt/README.source has:

for where in ./ ../ ../../ ../../../ ../../../../ ../../../../../; do
if [ -e ${where}debian/rules -a -d ${where}debian/patches ]; then
export QUILT_PATCHES=debian/patches
break
fi
done

Put that in ~/.quiltrc and be happy.

--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87aa5lr...@windlord.stanford.edu

Raphael Hertzog

unread,
Jan 18, 2012, 1:40:01 PM1/18/12
to
Hi,

On Wed, 18 Jan 2012, Agustin Martin wrote:
> On Wed, Jan 18, 2012 at 02:35:23PM +0100, Jakub Wilk wrote:
> > * Norbert Preining <prei...@logic.at>, 2012-01-18, 22:18:
> > >Since we are at quilt 3.0 bashing: Maybe you can give me a
> > >rational why I *ALWAYS* have to type in
> > > export QUILT_PATCHES=debian/patches
> > >before working with debian source packages? And when I forget it
> > >I get hurt by quilt?
> >
> > dpkg (>= 1.15.8.6) creates the .pc/.quilt_series file. So no, not always.
>
> It is sometimes removed. It is still unclear to me when/why that happens,
> guess that dh_quilt_unpatch may be the responsible for that.

You should not use dh_quilt_patch / dh_quilt_unpatch with a "3.0 (quilt)"
source package. dpkg-source takes care of everything, you should not
apply/unapply patches in debian/rules.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120118182...@rivendell.home.ouaza.com

Agustin Martin

unread,
Jan 19, 2012, 6:10:02 AM1/19/12
to
On Wed, Jan 18, 2012 at 07:29:18PM +0100, Raphael Hertzog wrote:
> Hi,
>
> On Wed, 18 Jan 2012, Agustin Martin wrote:
> > On Wed, Jan 18, 2012 at 02:35:23PM +0100, Jakub Wilk wrote:
> > > * Norbert Preining <prei...@logic.at>, 2012-01-18, 22:18:
> > > >Since we are at quilt 3.0 bashing: Maybe you can give me a
> > > >rational why I *ALWAYS* have to type in
> > > > export QUILT_PATCHES=debian/patches
> > > >before working with debian source packages? And when I forget it
> > > >I get hurt by quilt?
> > >
> > > dpkg (>= 1.15.8.6) creates the .pc/.quilt_series file. So no, not always.
> >
> > It is sometimes removed. It is still unclear to me when/why that happens,
> > guess that dh_quilt_unpatch may be the responsible for that.

Hi, Raphael, thanks for the reply,

> You should not use dh_quilt_patch / dh_quilt_unpatch with a "3.0 (quilt)"
> source package.

In the particular case of last QA upload for wdm, it is not explicitly used
anywhere in the package. Seems that is implicitly used by some other tool.
Before looking at the quilt snippet I considered having .pc/.quilt_series
in the VCS but it was removed.

By the way, just looked at quilt README.Debian and found no mention of above
"3.0 (quilt)" related info when dealing with dh_quilt_patch/dh_quilt_unpatch.
Some note about it may worth.

> dpkg-source takes care of everything, you should not apply/unapply patches in
> debian/rules.

This is sometimes useful when using "3.0 (quilt)" together with a VCS.
Although I'd expect it be similar to using the "3.0 (quilt)" format option to
unapply patches, still have to look at this more carefully.

I used this patch/unpatch targets before that option was available and still
keep them in some packages, having possible migration to unapply option in my
TODO list.

Regards,

--
Agustin


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012011911...@agmartin.aq.upm.es
0 new messages