Re: Bug#1067831: libaio: the t64 package slipped through and is in testing

[Guillem Jover]

Hi!

On Wed, 2024-03-27 at 17:56:25 +0700, Arnaud Rebillout wrote:
> Source: libaio
> Version: 0.3.113-7
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali

> I noticed that the t64 variant of the package libaio is already in
> testing. I did a quick check, and it seems that it's the only t64 package
> in testing at the moment, I suppose it wasn't intentional?

In theory, compared to the other packages involved in the transition,
it should not matter whether it transitioned as it is using a new
actual bumped SONAME (instead of only modifying the package name and
reusing the old SONAME). But because the udeb did not get renamed that
is indeed a problem for d-i. See also the thread at:

  https://lists.debian.org/debian-boot/2024/03/msg00125.html

> $ chdist apt-file trixie search -x '/lib/.*lib[^/]+t64$'
> libaio1t64: /usr/lib/x86_64-linux-gnu/libaio.so.1t64
> 
> The libaio1-udeb package is now also using the t64 lib, and it breaks
> the installer ISO that is built from testing. When trying to partition
> the disk using LVM, it fails, and we can see this error in the logs:
> 
> partman: pvscan: error while loading shared libraries: libaio.so.1:
>   cannot open shared object file: No such file or directory
> partman: vgscan: error while loading shared libraries: libaio.so.1:
>   cannot open shared object file: No such file or directory
> partman-lvm: vgchange: error while loading shared libraries: libaio.so.1:
>   cannot open shared object file: No such file or directory
> 
> I must say that this issue was reported in the Kali Linux bugtracker
> [1], as Kali is built on top of Debian testing, so our weekly images are
> now broken for users who try to use LVM partitioning.
> 
> I didn't check if it _really_ affects the weekly Debian installer ISOs,
> but I suppose so.
> 
> I don't know if anything can/should be done at this point, apart from
> waiting for the t64 transition to complete? Or should there be a binNMU
> for the d-i packages partman-*, would that fix the issue?

A binNMU would fix that, but given that no one has apparently asked
for that yet, I think instead I'll just add (later today) a compat
symlink only for the udeb for the old SONAME, because the new SONAME is
ABI compatible, but done to avoid stomping on the upstream SONAME in
case they end up merging something else or rejecting the patches, but
in d-i we do not care about backwards compatibility as long as it is
ABI compatible, then no binNMU will be needed anymore.

Thanks,
Guillem

Re: lvm2 udebs vs. libaio1-udeb (was: Progress on t64 transition -> building the installer in sid)

[Guillem Jover]

Hi!

On Thu, 2024-03-21 at 23:13:31 +0100, Cyril Brulebois wrote:
> Cyril Brulebois  (2024-03-21):
> > I'm a bit conflicted about what to do here. At the moment, libaio1-udeb
> > is the only udeb with t64 (at least according to the output of
> > `apt-file search -Iudeb t64`); but a rebuild of the reverse dependencies
> > would be sufficient (and might happen at some point anyway).
> > 
> > For the sake of consistency, I think I'm tempted to suggest a revert of
> > the udeb part (it wasn't renamed so there's a contents vs. package name
> > mismatch anyway).
> 
> Checking libaio's changelog (last mail got sent a little too fast,
> sorry) is enlightening: this library required special attention and
> wasn't just about getting rebuilt with a different package name.
> 
>   
> https://tracker.debian.org/news/1509816/accepted-libaio-03113-6-source-into-unstable/
> 
> Guillem is absolutely right regarding avoiding the roundtrip to NEW and
> d-i's not caring, but some kind of heads-up to debian-boot@ (now cc'd)
> would have been welcome.

Ah, sorry, the heads-up part didn't cross my mind, as I guess I
assumed transitory breakage was expected as part of that transition,
and that it would auto-heal after the release-team would trigger the
necessary binNMUs. Will try to have that in mind in the future. (I'll
do so as well once/if I revert the libaio SONAME bump, even though there
I'd be planning to add backwards compatibility symlinks if the ABI does
not change from what upstream accepts.)

Thanks,
Guillem

Bug#856060: Please don't use obsolete libsysfs-dev any more

[Guillem Jover]

Hi!

On Sun, 2017-04-09 at 10:17:41 +0200, Philipp Kern wrote:
> On 02/24/2017 11:05 PM, Michael Biebl wrote:
> > Some years ago libsysfs (source package: sysfsutils) was written as an
> > abstraction layer for accessing /sys/. However, this turned out to be
> > a historical error and evolutionary dead end: It does not actually
> > abstract anything (it's just as specific to the Linux kernel and a
> > particular version thereof as /sys itself), and just adds unnecessary
> > complexity, RAM overhead, and bugs. Thus its development has ceased
> > years ago, in favor of programs just using /sys as it is.

Upstream development for sysfsutils is still going, they have f.ex.
merged all patches Debian was carrying, plus several cleanup patch
series I've sent, and have done new upstream releases. As the current
maintainer in Debian I do not consider it obsolete, and would
encourage anyone to use it, in preference of having to manually parse
stuff from /sys.

> > In fact, most applications probably don't want to access /sys at all,
> > but use libudev [1] or gudev [2] instead. These provide a better API
> > for device enumeration, properties, and callbacks for hardware
> > changes.
> 
> I can see how we ended up here, but it still does abstract something
> away: access to sysfs, avoiding bugs in accessing it from C in the process.

Indeed.

So from my side, if you'd like to switch to something else, for
whatever reason, that's fine, but if you'd rather keep using libsysfs,
then that should also be fine.

Thanks,
Guillem

Re: Bug#982273: libbsd0-udeb: depends on libmd0

[Guillem Jover]

On Mon, 2021-02-08 at 14:54:28 +0100, Guillem Jover wrote:
> On Mon, 2021-02-08 at 14:07:08 +0100, Cyril Brulebois wrote:
> > Feel free to let us know about a source package/git repository so that
> > we have a chance of experimenting with it before or while it's being
> > reviewed/processed by ftp-masters.
> 
> Ok, thanks, then I'll upload in 1h at most, and provide repo + src +
> bin packages.

I've uploaded it now, once it hits NEW I'll poke ftp-masters. The git
and source+binary packages at:

  <https://git.hadrons.org/cgit/debian/pkgs/libmd.git/>
  <https://people.debian.org/~guillem/libmd-udeb/>

Thanks,
Guillem

Re: Bug#982273: libbsd0-udeb: depends on libmd0

[Guillem Jover]

On Mon, 2021-02-08 at 14:07:08 +0100, Cyril Brulebois wrote:
> Guillem Jover  (2021-02-08):
> > On Mon, 2021-02-08 at 02:25:01 +0100, Samuel Thibault wrote:
> > > Source: libbsd0-udeb
> > > Version: 0.11.1-1
> > > Severity: serious
> > > Justification: makes debian-installer FTBFS
> > 
> > > The "new upstream" upload of libbsd builds a udeb that depends on a
> > > non-udeb:
> > > 
> > > The following packages have unmet dependencies:
> > >  libbsd0-udeb : Depends: libmd0 (>= 1.0.3) but it is not installable
> > > 
> > > Please avoid linking against libmd0, or else add a libmd0-udeb
> > > package to libmd.
> 
> Thanks for filing this bug report, Samuel.
> 
> > I'd rather not revert the switch to use libmd…
> 
> Assuming that means not linking against it isn't an option (at least for
> the udeb)…

The upstream project had md5 and sha512 code embedded, which I
stripped away in that upstream version, to use the one in libmd. So
reverting would require reintroducing those local copies, build
machinery etc.

> > but that requires the d-i team to approve (CCed) such package and
> > ftp-masters to approve such package. :/
> 
> … I have no objections on principle for a new udeb at this stage, even
> if it seems quite late in the release cycle. (We've traditionally had
> some more wiggle room on the d-i side, but that doesn't mean we should
> push too hard… ;))
> 
> > I could have the libmd udeb package uploaded today, though.
> 
> Feel free to let us know about a source package/git repository so that
> we have a chance of experimenting with it before or while it's being
> reviewed/processed by ftp-masters.

Ok, thanks, then I'll upload in 1h at most, and provide repo + src +
bin packages.

Regards,
Guillem

Re: Bug#982273: libbsd0-udeb: depends on libmd0

[Guillem Jover]

Hi!

On Mon, 2021-02-08 at 02:25:01 +0100, Samuel Thibault wrote:
> Source: libbsd0-udeb
> Version: 0.11.1-1
> Severity: serious
> Justification: makes debian-installer FTBFS

> The "new upstream" upload of libbsd builds a udeb that depends on a
> non-udeb:
> 
> The following packages have unmet dependencies:
>  libbsd0-udeb : Depends: libmd0 (>= 1.0.3) but it is not installable
> 
> Please avoid linking against libmd0, or else add a libmd0-udeb package
> to libmd.

Hmm right, missed that one. :( I'll file a bug against lintian, which
said nothing about this. I'd rather not revert the switch to use libmd,
but that requires the d-i team to approve (CCed) such package and
ftp-masters to approve such package. :/

I could have the libmd udeb package uploaded today, though.

Thanks,
Guillem

Re: New udeb for libacl and acl? (was Re: Bug#949712: please provide an udeb to be used by rsync-udeb)

[Guillem Jover]

On Mon, 2020-04-13 at 17:52:08 +0100, Samuel Henrique wrote:
> On Sun, 26 Jan 2020 at 17:29, Cyril Brulebois  wrote:
> > Guillem Jover  (2020-01-26):
> > > I'm also not sure whether it would make sense to add also an acl-udeb
> > > binary package, which would match for example the attr-udeb one.
> >
> > Does rsync really depend on libacl in the first place? I'm seeing
> > --disable-acl-support in its configure.ac; I haven't had to toy with
> > rsync in rescue mode just yet, so I'm not sure how imperative it would
> > be to have ACL support there…
> >
> > (I don't mind the acl udeb addition anyway, just putting some
> > ideas/options on the table.)

> My initial assumption was that having libacl-udeb wouldn't cause a
> considerable overhead, while having the benefit of shipping an
> rsync-udeb which supports the same features as the regular one (total
> size of rsync binary is around 500kb).

> I reckon Guillem mentions acl-udeb would match the already existent
> attr-udeb package, but I don't know how rsync deals with both libs and
> how they cap its features exactly, since it seems that libattr1 is
> only used in some archs (hppa, m68k, powerpcspe, sh4, sparc64). I can
> say that having support for ACLs on rsync-udeb would help in a
> scenario where the user wants to do a full copy of the files, maybe
> copying the whole system's FS with its ACLs along.

I thought having xattr and ACL support in an rsync-udeb did make sense,
because as you say, if you want to use it to initialize a filesystem
then you probably want all file attributes to be preserved as much as
possible. libattr might not be used on some arches depending on the
glibc support which has provided the syscall wrappers for some time
now.

> Guillem, please give me a heads up in case you think this is a good
> argument for providing libacl1-udeb, in such case I will stop
> investigating how to build rsync without having it symlinked to the
> lib.

Yeah, I think it does, otherwise I'd not have asked for an ack from
the d-i team. :) This is possibly slightly more overhead when the freeze
comes around, but several of the packages I maintain already ship udebs,
so this is soemthing I already need to keep in mind.

Thanks,
Guillem

New udeb for libacl and acl? (was Re: Bug#949712: please provide an udeb to be used by rsync-udeb)

[Guillem Jover]

Hi!

On Thu, 2020-01-23 at 22:33:52 +, Samuel Henrique wrote:
> Package: libacl1
> Version: 2.2.53-5
> Severity: wishlist

> Hello Maintainer, as per requested in #729069 (rsync package)
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729069
> 
> I would like to provide an udeb for rsync, It seems that the only thing
> missing is to have libacl1-udeb available.
> 
> Could you please provide an udeb for the package?

As was mentioned in debian-devel, this usually needs an ACK from the
d-i team (CCed).

I'm also not sure whether it would make sense to add also an acl-udeb
binary package, which would match for example the attr-udeb one.

Thanks,
Guillem

Bug#944984: live-installer: Scripts access internal dpkg database

[Guillem Jover]

Source: live-installer
Source-Version: 57
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains several scripts, which directly access the dpkg
internal database, instead of using one of the public interfaces
provided by dpkg.

These scripts check for the presence of the .list and .postinst files to
assert whether packages are installed. These components should be switched
to use something else. For example check the status for each of these
packages via dpkg-query.


This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#944836: discover-data: Embeds old copies of pci.ids and usb.ids

[Guillem Jover]

Source: discover-data
Source-Version: 2.2013.01.11
Severity: normal

Hi!

This package embeds old copies of the pci.ids and usb.ids databases
which get converted into xml files.

These databases are now packaged on their own source and binary
packages so that it's very easy to update regularly.

It would be best if this package could switch to use those, at least
as Build-Depends-Indep. So that just with a binNMU it could get the
updated databases.

(I guess ideally the consumer(s) of the xml files would switch to use
the pci.ids and usb.ids files directly.)

Thanks,
Guillem

Bug#932258: console-setup-freebsd: missing dependency

[Guillem Jover]

On Wed, 2019-07-17 at 18:06:00 +0300, Anton Zinoviev wrote:
> On Wed, Jul 17, 2019 at 04:15:51PM +0200, Guillem Jover wrote:
> > this seems like a problem with console-setup-freebsd being arch:all 
> > and depending on kFreeBSD-specific packages which will not be 
> > available elsewhere, in the same way console-setup-linux is an 
> > arch:all depending on Linux-specific packages.
> 
> Why is it a problem to have an arch:all package which is installable 
> only on some architectures (due to missing dependencies)?

Because that's generally confusing for users, as they might not know
off-hand whether the unsatisfiable problem is due to a bug or it being
intended that way (even though it could be made very clear in the
Description). It also triggers all kind of alarms on automatic
dependency satisfiability checkers, which then need to be ignored
(like apparently this being the cause for thus bug report :). And
I guess in the metadata sense it seems wrong, as even though the
contents do not change across different architectures (so it has one
of the facets of an arch:all package) it is still not an archecture
indepdenent package (one of the other facets of an arch:all package).

Thanks,
Guillem

Bug#932258: console-setup-freebsd: missing dependency

[Guillem Jover]

Hi!

[ I'm not sure this bug closure is entirely correct? See below. ]

On Wed, 2019-07-17 at 13:25:50 +0100, James Clarke wrote:
> On 17 Jul 2019, at 10:55, Holger Wansing  wrote:
> > Héctor Orón Martínez  (2019-07-17):
> > > Package: console-setup-freebsd
> > > Version: 1.191
> > > Severity: grave

> > >  console-setup-freebsd has a dependency on vidcontrol, which is not
> > > part of buster|bullseye|unstable, and causes the package to be
> > > uninstallable.

> > The same counts for kbdcontrol, also not existing in all suites.

> vidcontrol, and the rest of src:freebsd-utils, is available in unreleased,
> since the source package only builds for kfreebsd-amd64 and kfreebsd-i386.
> Avoiding this would require either getting the source package to build on 
> Linux
> architectures, or building at least one arch:all package, neither of which 
> seem
> to have much point to them. As an architecture on Debian Ports, it is expected
> that you also have the "unreleased" suite enabled, as is clearly documented on
> the main site[1]. This is especially important on kFreeBSD, since
> bin:freebsd-utils is Essential, containing many of the core utilities required
> for a functioning system. All ports buildds should have unreleased available,
> and debian-installer learnt over 2 years ago to include unreleased when
> downloading udebs. Thus, I consider this not a bug; as much as we would like 
> it
> to not be, as far as Debian Ports goes, unreleased is a necessary addition to
> unstable, with cases like these stemming from the fact that ftp-master does 
> not
> allow sources to exist that don't build packages for any of its architectures.

I'm not sure the report was noticed on a kFreeBSD system (and due to
the unreleased confusion), but otherwise this seems like a problem with
console-setup-freebsd being arch:all and depending on kFreeBSD-specific
packages which will not be available elsewhere, in the same way
console-setup-linux is an arch:all depending on Linux-specific packages.

The solution to the latter problem is to make these packages
Architecture kfreebsd-any and linux-any respectively, because even if
they are written in scripting languages they are not arch-independent.

Thanks,
Guillem

Re: Bug#930788: creating /var/lib/dpkg/cmethopt

[Guillem Jover]

On Sun, 2019-06-23 at 21:32:19 +0200, Sven Joachim wrote:
> On 2019-06-20 18:19 +0200, Ansgar Burchardt wrote:
> > Package: apt,dselect
> > Severity: normal

> > today I learned that debootstrap as special code to create the file
> > /var/lib/dpkg/cmethopt (contents: "apt apt"); this is the function
> > setup_dselect_method in functions.  It seems wrong that debootstrap
> > has to know about such a particular detail.

This is related to
. The
problem is that dselect conflates the selection of its access method
with its configuration, so when you choose the apt access method it
will try to reconfigure apt, which is annoying because debootstrap
already did configure it. So it does make sense to me that given that
debootstrap configured apt as the system access/download method it
would notify dselect of this fact, and not require the user to do
this again.

But I do agree that this is an internal implementation detail, and
deboostrap should be provided with a better interface.

> That code has been in debootstrap forever, at least since woody (the
> oldest version on snapshot.debian.org is 0.1.17.7woody1).  I suspect
> back in the days this was actually useful, but nowadays rather few
> people actually use dselect, and debootstrap should stop creating
> /var/lib/dpkg/cmethopt.

I guess that's another option, yes.

> > Alternatives to debootstrap might also not create the file at all.
> >
> > So I wonder if this could be created somewhere else.  An APT developer
> > said this is used by dselect and suggested to file a bug against
> > apt,dselect; he also had the idea that the file might be created in
> > dselect's postinst.
> 
> Makes sense, although dselect happily starts without that file; the
> admin would have to select an install method and had better know that
> they should choose "apt" from the list, but people willingly using
> dselect probably can be expected to know what they are doing.

I think dselect could get its access method selection split from
its configuration, maybe supporting something similar to the
alternatives system with auto/manual mode and priorities, etc.

Or perhaps the better option, is to switch its access method
configuration to use something like apt's sources.list format.

> Removing /var/lib/dpkg/cmethopt when dselect is purged seems also
> logical to me.

Right, I'll do that right away.

Thanks,
Guillem

Bug#923091: That merged-usr is mandatory is RC

[Guillem Jover]

On Mon, 2019-05-13 at 17:24:55 +0200, Bastian Blank wrote:
> On Mon, May 13, 2019 at 11:22:35AM +0100, Ian Jackson wrote:
> > In #923091, Guillem (with dpkg maintainer hat on) asks for a
> > base-installer option to allow installing buster without merged-usr.
> 
> No, he did not mention dpkg.

Indeed I didn't, even though (as I've mentioned on d-d) I consider any
system installed with such layout completely broken from dpkg's PoV. I
could not be bothered filing this with an RC severity, given that AFAIR
one of the Release Team members uploaded the breaking change, and didn't
(and still do not) have the energy or will to get into such an argument
over severities and similar.

I do still consider this pretty much unsupported from dpkg's PoV though…

Thanks,
Guillem

Bug#923091: base-installer: Allow installing w/o the broken merged-usr-via-symlinks

[Guillem Jover]

Package: base-installer
Version: 1.187
Severity: wishlist

Hi!

The current base-installer uses the default debootstrap settings
which end up unconditionally installing systems with the
merged-usr-via-symlinks deployment method which is broken by design,
please see:

  

I'm aware the original request to change the debootstrap default got
unfortunately moved to the tech-ctte. :(

But regardless of that outcome I'd like to request to have a way to
install using debootstrap's --no-merged-usr option, to not have to
install from stretch and then upgrade to buster, or having to drop into
a shell and do manual stuff from within the installer.

In addition it would be also nice if that option was passed whenever
/usr is not on its own partition, because then the properties from
the merged-/usr concept are not relevant anymore, but we get all the
downsides of the broken deployment method.

If this was to be applied for buster, I'd be happy to provide patches.

Otherwise I guess I might need to end up looking to generate
alternative netinst somewhere else or something. :(

Thanks,
Guillem

Re: Processed: block 839046 with 134758

[Guillem Jover]

On Mon, 2018-05-07 at 12:08:36 +0200, Marco d'Itri wrote:
> On May 07, Debian Bug Tracking System  wrote:
> > > block 839046 with 134758
> > Bug #839046 [debootstrap] debootstrap: enable --merged-usr by default
> > Bug #839162 [debootstrap] Enabled merged-/usr by default

> I totally disagree that this is in any way a blocking issue: it is at 
> best cosmetical since dpkg has always worked this way.

BTW, I think this might have been mentioned before, but if not, just in
case. dpkg will *not* be able to detect *nor* error on file conflicts
that happen due to merged-/usr (say pkg-a ships /bin/foo, and pkg-b
ships /usr/bin/foo). You'll get _silent_ overwrites of content, to the
point of flip-flops depending on the installation/upgrade order.

I don't know whether someone is continuously checking for this kind of
problem within Debian, besides the usual checks that Ralf Treinen is
doing. But this will obviously not catch conflicts originating from
third-parties or local packages.

Thanks,
Guillem

Bug#839046: debootstrap: enable --merged-usr by default

[Guillem Jover]

On Mon, 2018-02-05 at 22:32:05 +, Holger Levsen wrote:
> On Mon, Feb 05, 2018 at 08:19:33PM +0100, Julien Cristau wrote:
> > On Sat, Feb  3, 2018 at 09:16:40 +0100, Marco d'Itri wrote:
> > > On Dec 23, md wrote:
> > > > On Dec 20, Julien Cristau  wrote:
> > > > > > This change was reverted in 1.0.87 as dpkg-shlibdeps didn't cope
> > > > > > properly with a merged-usr system. Thus reopening this bug report 
> > > > > > for
> > > > > > that version.
> > > > > > 
> > > > > > The dpkg-shlibdeps bugs has been fixed [1] in the mean time. So it 
> > > > > > would
> > > > > > be great if this bug report could be re-considered.

> > > > > That'll be after stretch now.

> > > > Stretch was been released long ago: please re-enable --merged-usr in 
> > > > debootstrap.

> > > There has not been any negative feedback, can we move on please?

> > Is there buy-in from the dpkg maintainer?

As I've mentioned in the past, I think the usrmerge filesystem layout
has merit and can solve some issues, and to state it very clearly, I
have no technical issue with it *what*so*ever*. But the same can be
said about the non-usrmerge layout with multiple mount-points, which
while not general anymore in Debian, can still be used perfectly fine
on controlled subsets of packages and custom built kernels w/o reliance
on an initramfs.

What I still find to be terrible is the way it's been tried to be
deployed in Debian, via the usrmerge package, which does not support
reverting the change (#848626), for which there's (AFAIK) no way to
select not using this irreversible hack from d-i, which breaks
dpkg-query --search (at least #848622 and #858331). This seems like
a nice PoV for people to play with it, in the same way local admins
can use, to some extent, symlinks to redirect subtrees to other mount
points, but I don't see how this can be seen as a production-ready
solution shipped by default, TBH.

In any case, I looked the other day into implementing the
--map-pathname option for dpkg-query, and I've got most of the code
ready. The problem is that this requires adding support for config
files and config fragments to dpkg-query, which has the additional
problem of making it possible to mess with the --showformat option
and breaking the expectations from maintscripts, for example. The
other problem is with the search behavior changing depending on the
packages providing those mappings being installed (because dpkg would
certainly not provide them).


So I'll eventually try to find a solution for the dpkg-query issue,
because it's a long-standing paper-cut in dpkg for local admins. But
I'd not be very amused if this hack is enabled by default again and
suddenly RC bugs start popping up in dpkg again, and people start
pressuring with RCness to get those fixed again because well, it's
obviously breaking people's systems…


Thanks,
Guillem

Bug#836525: debootstrap: doesn't support arch-qualified dependencies

[Guillem Jover]

Hi!

On Mon, 2016-12-19 at 13:59:51 +0100, Julien Cristau wrote:
> Control: severity -1 normal
> 
> On 12/19/2016 10:58 AM, Sven Joachim wrote:
> > Control: severity -1 serious
> > 
> > On 2016-11-12 20:32 +0100, Sven Joachim wrote:
> >> On 2016-09-04 19:28 +0200, Sven Joachim wrote:
> >>> The attached patch should fix the problem with arch-qualifiers in
> >>> debootstrap, tested with
> >>> "debootstrap --variant=minbase --include=autoconf-dickey" which fails
> >>> right now in unstable but succeeds with the patch (autoconf-dickey
> >>> depends on perl:any).
> >>
> >> It should be noted that dpkg-dev in unstable now also depends on
> >> perl:any.  This does not cause problems yet, but only because
> >> libdpkg-perl depends on perl and debootstrap silently ignores any
> >> dependencies it cannot resolve, which is a bug in itself.
> >>
> >> This bug is a ticking time bomb, would be nice to apply my patch before
> >> it explodes.
> > 
> > The latest dpkg upload (1.18.17) changed the dependency of libdpkg-perl
> > to perl:any as well, and now "debootstrap --variant=buildd" fails
> > because it no longer downloads perl.

Oww, sorry, had forgotten about your previous thread where you
mentioned this. :/

> I think that needs to be reverted in dpkg, we really want to be able to
> create sid chroots with stable debootstrap.

Hmm, certainly right, I'll queue the revert for 1.18.18.

Also Ansgar mentioned on IRC that the other pkgdetails implementation
in base-installer also needed to be handled, perhaps by stripping the
arch-qualification centrally from debootstrap itself. And josch also
mentioned that perhaps it might be a good idea to consider switching
to use multistrap in Debian, as that's always going to be more feature
complete.

Thanks,
Guillem

Re: Debian Installer Stretch Alpha 8 release

[Guillem Jover]

Control: clone 843073 -1
Control: reassign -1 debootstrap 1.0.85
Control: retitle -1 debootstrap: Please revert merged-/usr by default as it 
breaks builds
Control: severity -1 serious
Control: affects -1 dpkg-dev
Control: severity 843073 wishlist
Control: block 810499 by 843073
Control: severity 810499 serious
Control: affects 810499 dpkg-dev

Hi!

On Sun, 2016-11-13 at 08:38:53 +0100, Helmut Grohne wrote:
> On Sat, Nov 12, 2016 at 08:55:43PM +0100, Michael Biebl wrote:
> > Is this really so for all buildds?
> > See #843433, the sparc64 buildds apparently do use a merged-usr chroot.
> 
> The issue depends on the loader path of the architecture. Although I do
> not understand why, it seems that /lib64 is less prone to exposing it
> than /lib is. We have people saying:
>  * not reproducible on amd64 /lib64 (Marco)
>  * not reproducible on sparc64 /lib64 (Michael)
>  * reproducible on i386 /lib (#810499)
>  * reproducible on armhf /lib (Uwe)
> 
> So the expectation I have is that it'll break:
>  * armel
>  * armhf
>  * i386
>  * mips
>  * mipsel
>  * s390x
> 
> Plus a number of non-release architectures.

Thanks for taking a look!

> > Hm, I would still consider it release critical, i.e. something which
> > needs to be fixed before we can release stretch. Otherwise this will
> > bite us later.
> 
> I agree.

Ok fine, this looks pretty worse than it looked before. So I'm rearranging
the bugs to where they belong.

> The /usr merge violates core assumptions in dpkg-shlibdeps. The reason
> that amd64 isn't broken is sheer luck.
> /etc/ld.so.conf.d/x86_64-linux-gnu.conf lists /lib before /usr/lib, so
> dpkg-shlibdeps considers that first. Swapping them or simply removing
> /lib (as seems reasonable on a merged /usr), breaks almost any build on
> amd64 (e.g. dash). The breakage on amd64 is simply hidden.

Right. I'm happy to assist people who want to fix this to try to find
a proper solution in dpkg-dev, but I'm not planning on spending time
on this on my own.

On Sun, 2016-11-13 at 12:04:07 +0100, Marco d'Itri wrote:
> On Nov 13, Helmut Grohne  wrote:
> > Thus I think that debootstrap should revert to unmerged /usr until
> > dpkg-shlibdeps has been fixed. Fixing is non-trivial and likely requires
> > an archive rebuild on several architectures.

> Not really: dpkg-shlibdeps just needs to be fixed to search for 
> libraries in $directory and /usr/$directory, and then everything will 
> work again as usual.
> And yes, hacks like this one are a side effect of maintaining support 
> for non-merged systems.

Err, well exactly because usemerge is a major hack, and I'm actually
surprised we are deploying systems by default with that. As an
interesting thing to install and try out on ones system that's
perfectly fine though. But IMO if the merge needs to be done it should
be done by installing things into their final desired destination on
each package. Of course that makes split installations not possible,
but oh well.

Thanks,
Guillem

Re: Debian Installer Stretch Alpha 8 release

[Guillem Jover]

Control: severity 843073 important

On Sat, 2016-11-12 at 18:37:52 +0100, Guillem Jover wrote:
> On Sat, 2016-11-12 at 16:24:32 +0100, Cyril Brulebois wrote:
> > Important change in this release of the installer
> > =
> > 
> >  * debootstrap now defaults to merged-/usr, that is with /bin, /sbin,
> >/lib* being symlinks to their counterpart in /usr (more details on:
> >https://lists.debian.org/debian-devel/2016/09/msg00269.html).
> 
> This has caused build issues with dpkg-shlibdeps (#843073) on some
> architectures, which was a known problem (#810499) at the time of
> the default switch. :(
> 
> As I'm told the buildds regenerate the chroots every couple of weeks (?),
> which means several of those buildds will most probably start failing,
> I'd appreciate if the proponents of this change could either help
> Felipe Sateler (many thanks to him for working on this!) to track down
> and find an acceptable solution for dpkg-shlibdeps, or revert the change
> in debootstrap.

Ok, Mattia Rizzolo tells me (thanks!) that it's actually twice per
week, and that the debootstrap used is from jessie so this should not
be such a big deal for the Debian buildds. I'm thus lowering the
severity. All other comments still apply though.

> Otherwise I guess I might just reassign the dpkg-shlibdeps bug to both
> usrmerge and debootstrap.

Thanks,
Guillem

Re: Debian Installer Stretch Alpha 8 release

[Guillem Jover]

Hi,

On Sat, 2016-11-12 at 16:24:32 +0100, Cyril Brulebois wrote:
> Important change in this release of the installer
> =
> 
>  * debootstrap now defaults to merged-/usr, that is with /bin, /sbin,
>/lib* being symlinks to their counterpart in /usr (more details on:
>https://lists.debian.org/debian-devel/2016/09/msg00269.html).

This has caused build issues with dpkg-shlibdeps (#843073) on some
architectures, which was a known problem (#810499) at the time of
the default switch. :(

As I'm told the buildds regenerate the chroots every couple of weeks (?),
which means several of those buildds will most probably start failing,
I'd appreciate if the proponents of this change could either help
Felipe Sateler (many thanks to him for working on this!) to track down
and find an acceptable solution for dpkg-shlibdeps, or revert the change
in debootstrap.

Otherwise I guess I might just reassign the dpkg-shlibdeps bug to both
usrmerge and debootstrap.

Thanks,
Guillem

Bug#799883: [PATCH v2 1/2] Treat *-{i386,amd64} as x86

[Guillem Jover]

Hi!

On Wed, 2015-09-23 at 19:04:03 +0100, James Clarke wrote:
> --- a/debian/rules
> +++ b/debian/rules
> @@ -6,7 +6,7 @@
>   dh $@
>  
>  ARCH=$(shell dpkg-architecture -qDEB_HOST_ARCH)
> -ifneq (,$(findstring :$(ARCH):,:i386:amd64:))
> +ifneq (,$(filter i386 amd64 %-i386 %-amd64,$(ARCH)))
>  ARCH=x86
>  endif

I think you want DEB_HOST_ARCH_CPU instead here.

Thanks,
Guillem

Bug#793559: udpkg: Update status keywords to match dpkg

[Guillem Jover]

Package: udpkg
Version: 1.17
Severity: wishlist
Tags: patch

Hi!

Here's a patch I had laying around, updating the status field values to
match the ones in dpkg. It does the following:

  Remove obsolete keyword aliases, as dpkg autoupgraded these keywords
  to their modern counterparts at run-time long time ago. And they are
  no longer supported by dpkg itself. Moreover one of the keywords was
  mispelled here ("post-inst-failed" should have been "postinst-failed"),
  presumably from a typo carried over from apt.

  Add triggers-awaited and triggers-pending keywords.

  Sort status keywords in their normal transition sequence order.

Beware, only build-tested.

Thanks,
Guillem
From f5e8222c2211a8f6f85c2320201dd91d34a87424 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 3 Aug 2014 12:40:33 +0200
Subject: [PATCH] Update status keywords

Remove obsolete keyword aliases, as dpkg autoupgraded these keywords
to their modern counterparts at run-time long time ago. And they are
no longer supported by dpkg itself. Moreover one of the keywords was
mispelled here ("post-inst-failed" should have been "postinst-failed"),
presumably from a typo carried over from apt.

Add triggers-awaited and triggers-pending keywords.

Sort status keywords in their normal transition sequence order.
---
 status.c | 10 --
 udpkg.h  | 20 +---
 2 files changed, 13 insertions(+), 17 deletions(-)

diff --git a/status.c b/status.c
index 305e234..d1c20ad 100644
--- a/status.c
+++ b/status.c
@@ -24,12 +24,10 @@
 static const char *statuswords[][10] = {
 	{ (char *)STATUS_WANTSTART, "unknown", "install", "hold", 
 		"deinstall", "purge", 0 },
-	{ (char *)STATUS_FLAGSTART, "ok", "reinstreq", "hold", 
-		"hold-reinstreq", 0 },
-	{ (char *)STATUS_STATUSSTART, "not-installed", "unpacked", "half-configured",
-		"installed", "half-installed",
-		"config-files", "post-inst-failed", 
-		"removal-failed", 0 }
+	{ (char *)STATUS_FLAGSTART, "ok", "reinstreq", 0 },
+	{ (char *)STATUS_STATUSSTART, "not-installed", "config-files",
+		"half-installed", "unpacked", "half-configured",
+		"triggers-awaited", "triggers-pending", "installed", 0 }
 };
 
 int package_compare(const void *p1, const void *p2)
diff --git a/udpkg.h b/udpkg.h
index 30fc8c2..48bc877 100644
--- a/udpkg.h
+++ b/udpkg.h
@@ -35,20 +35,18 @@
 #define STATUS_FLAGSTART		(5)
 #define STATUS_FLAGOK			(1 << 5)
 #define STATUS_FLAGREINSTREQ		(1 << 6)
-#define STATUS_FLAGHOLD			(1 << 7)
-#define STATUS_FLAGHOLDREINSTREQ	(1 << 8)
-#define STATUS_FLAGMASK			~(STATUS_FLAGOK | STATUS_FLAGREINSTREQ | STATUS_FLAGHOLD | STATUS_FLAGHOLDREINSTREQ)
+#define STATUS_FLAGMASK			~(STATUS_FLAGOK | STATUS_FLAGREINSTREQ)
 
 #define STATUS_STATUSSTART		(9)
 #define STATUS_STATUSNOTINSTALLED	(1 << 9)
-#define STATUS_STATUSUNPACKED		(1 << 10)
-#define STATUS_STATUSHALFCONFIGURED	(1 << 11)
-#define STATUS_STATUSINSTALLED		(1 << 12)
-#define STATUS_STATUSHALFINSTALLED	(1 << 13)
-#define STATUS_STATUSCONFIGFILES	(1 << 14)
-#define STATUS_STATUSPOSTINSTFAILED	(1 << 15)
-#define STATUS_STATUSREMOVALFAILED	(1 << 16)
-#define STATUS_STATUSMASK		~(STATUS_STATUSNOTINSTALLED | STATUS_STATUSUNPACKED | STATUS_STATUSHALFCONFIGURED | STATUS_STATUSINSTALLED | STATUS_STATUSCONFIGFILES | STATUS_STATUSPOSTINSTFAILED | STATUS_STATUSREMOVALFAILED | STATUS_STATUSHALFINSTALLED)
+#define STATUS_STATUSCONFIGFILES	(1 << 10)
+#define STATUS_STATUSHALFINSTALLED	(1 << 11)
+#define STATUS_STATUSUNPACKED		(1 << 12)
+#define STATUS_STATUSHALFCONFIGURED	(1 << 13)
+#define STATUS_STATUSTRIGGERSAWAITED	(1 << 14)
+#define STATUS_STATUSTRIGGERSPENDING	(1 << 15)
+#define STATUS_STATUSINSTALLED		(1 << 16)
+#define STATUS_STATUSMASK		~(STATUS_STATUSNOTINSTALLED | STATUS_STATUSCONFIGFILES | STATUS_STATUSHALFINSTALLED | STATUS_STATUSUNPACKED | STATUS_STATUSHALFCONFIGURED | STATUS_STATUSTRIGGERSAWAITED | STATUS_STATUSTRIGGERSPENDING | STATUS_STATUSINSTALLED)
 
 #define COLOR_WHITE			0
 #define COLOR_GRAY			1
-- 
2.5.0.rc2.392.g76e840b

Bug#793558: udpkg: asprintf failure handling

[Guillem Jover]

Package: udpkg
Version: 1.17
Severity: normal

Hi!

With commit c13d9c8529d2e1b09767b5f0b6a524721c9951ec to udpkg, there
is a new error handling for asprintf(), moved into the new xasprintf(),
but xasprintf() can still return NULL in some cases, which could end up
with segfaults or bad behavior. It should never return NULL.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150725024045.ga29...@gaara.hadrons.org

Re: Changing in d-i manual: head up

[Guillem Jover]

Hi!

On Wed, 2014-08-20 at 20:11:28 +0200, Holger Wansing wrote:
> Hello ,

I stepped down as translator for the manual some time ago, if there is
still some place that says otherwise I'd like to know, to be able to
correct it.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140820220430.gb10...@gaara.hadrons.org

Bug#756462: busybox: Update deb format support

[Guillem Jover]

Package: busybox
Version: 1:1.22.0-6
Severity: wishlist
Tags: patch

Hi!

As part of an effort [S] to try to get as much tools to understand
the current .deb format (see deb(5)), I'm attaching a patch updating
the busybox dpkg and dpkg-deb applets against that spec.

 [S] <https://wiki.debian.org/Teams/Dpkg/DebSupport>

As those applets are only built for the busybox-static package, I've
tested that one against the test packages from the dpkg/pkg-tests.git
repository [T], which can be found in the t-deb-format directory.

  [T] 

I only found an issue with a control.tar.xz member, and the dpkg-deb
applet that prints a corrupted data error, but outputs the entire
control file correctly, and extracts it also correctly, so I think
this is an issue with the existing xz decoder in busybox, and as a
wild guess probably from the 0 padding in the tar archive. Here's an
excerpt from the session:

,---
$ dpkg-deb -I pkg-control-xz.deb
 new debian package, version 2.0.
 size 744 bytes: control archive=348 bytes.
 193 bytes, 7 lines  control
 Package: pkg-deb-format
 Version: 0.0-1
 Section: test
 Priority: extra
 Maintainer: Dpkg Developers 
 Architecture: all
 Description: test package - deb format support
$ busybox dpkg-deb -f pkg-control-xz.deb 
Package: pkg-deb-format
Version: 0.0-1
Section: test
Priority: extra
Maintainer: Dpkg Developers 
Architecture: all
Description: test package - deb format support
dpkg-deb: corrupted data
$ busybox dpkg-deb -e pkg-control-xz.deb DEBIAN
dpkg-deb: corrupted data
$ ls -l  DEBIAN/
total 4
-rw-r--r-- 1 guillem guillem 193 Jul 30 04:27 control
`---

Thanks,
Guillem
Description: Add support for latest .deb format members
 This adds support for control.tar, control.tar.xz, data.tar, data.tar.xz
 and data.tar.lzma in the dpkg and dpkg-deb applet. It also removes support
 for control.tar.bz2 which has never been supported.
 .
 This should make these applets conform to deb(5).
Author: Guillem Jover 
Origin: vendor
Forwarded: no
Last-Update: 2014-07-30


diff --git a/archival/dpkg.c b/archival/dpkg.c
index 2893cfc..71eae66 100644
--- a/archival/dpkg.c
+++ b/archival/dpkg.c
@@ -1472,11 +1472,12 @@ static void init_archive_deb_control(archive_handle_t *ar_handle)
 	tar_handle->src_fd = ar_handle->src_fd;
 
 	/* We don't care about data.tar.* or debian-binary, just control.tar.* */
+	llist_add_to(&(ar_handle->accept), (char*)"control.tar");
 #if ENABLE_FEATURE_SEAMLESS_GZ
 	llist_add_to(&(ar_handle->accept), (char*)"control.tar.gz");
 #endif
-#if ENABLE_FEATURE_SEAMLESS_BZ2
-	llist_add_to(&(ar_handle->accept), (char*)"control.tar.bz2");
+#if ENABLE_FEATURE_SEAMLESS_XZ
+	llist_add_to(&(ar_handle->accept), (char*)"control.tar.xz");
 #endif
 
 	/* Assign the tar handle as a subarchive of the ar handle */
@@ -1492,12 +1493,19 @@ static void init_archive_deb_data(archive_handle_t *ar_handle)
 	tar_handle->src_fd = ar_handle->src_fd;
 
 	/* We don't care about control.tar.* or debian-binary, just data.tar.* */
+	llist_add_to(&(ar_handle->accept), (char*)"data.tar");
 #if ENABLE_FEATURE_SEAMLESS_GZ
 	llist_add_to(&(ar_handle->accept), (char*)"data.tar.gz");
 #endif
+#if ENABLE_FEATURE_SEAMLESS_XZ
+	llist_add_to(&(ar_handle->accept), (char*)"data.tar.xz");
+#endif
 #if ENABLE_FEATURE_SEAMLESS_BZ2
 	llist_add_to(&(ar_handle->accept), (char*)"data.tar.bz2");
 #endif
+#if ENABLE_FEATURE_SEAMLESS_LZMA
+	llist_add_to(&(ar_handle->accept), (char*)"data.tar.lzma");
+#endif
 
 	/* Assign the tar handle as a subarchive of the ar handle */
 	ar_handle->dpkg__sub_archive = tar_handle;
diff --git a/archival/dpkg_deb.c b/archival/dpkg_deb.c
index 13f9db9..48920f6 100644
--- a/archival/dpkg_deb.c
+++ b/archival/dpkg_deb.c
@@ -70,10 +70,16 @@ int dpkg_deb_main(int argc, char **argv)
 	ar_archive->dpkg__sub_archive = tar_archive;
 	ar_archive->filter = filter_accept_list_reassign;
 
+	llist_add_to(&ar_archive->accept, (char*)"data.tar");
+	llist_add_to(&control_tar_llist, (char*)"control.tar");
 #if ENABLE_FEATURE_SEAMLESS_GZ
 	llist_add_to(&ar_archive->accept, (char*)"data.tar.gz");
 	llist_add_to(&control_tar_llist, (char*)"control.tar.gz");
 #endif
+#if ENABLE_FEATURE_SEAMLESS_XZ
+	llist_add_to(&ar_archive->accept, (char*)"data.tar.xz");
+	llist_add_to(&control_tar_llist, (char*)"control.tar.xz");
+#endif
 #if ENABLE_FEATURE_SEAMLESS_BZ2
 	llist_add_to(&ar_archive->accept, (char*)"data.tar.bz2");
 	llist_add_to(&control_tar_llist, (char*)"control.tar.bz2");
diff --git a/archival/libarchive/Kbuild.src b/archival/libarchive/Kbuild.src
index 968fdf8..fda05d8 100644
--- a/archival/libarchive/Kbuild.src
+++ b/archival/libarchive/Kbuild.src
@@ -33,6 +33,7 @

Bug#739411: udpkg: Support for data.tar, control.tar and control.tar.xz

[Guillem Jover]

On Tue, 2014-02-18 at 13:01:48 +0100, Guillem Jover wrote:
> Package: udpkg
> Version: 1.16
> Severity: wishlist
> Tags: patch
> X-Debbugs-CC: Philipp Kern 

> Here's a patch series adding data.tar, control.tar and control.tar.xz
> support, the uncompressed member support just out of completeness. To
> create a deb package with a different control.tar compression you can
> use «dpkg-deb --uniform-compression pkg/» for example.
> 
> Note I've only tested «udpkg -c» and «udpkg -f», the changes in unpacking
> are pretty obvious, but testing them would be nice. I've also used cat
> for the uncompressed members as I didn't think further optimization there
> was worth it(?). I've also tried to use the prevailing coding-style,
> which in some cases conflicted with the immediate surrounding code.

And then forgot to attach the patches…

Thanks,
Guillem
From b806fc9a73e79b561fad9e40e34d44d86031e4a1 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 16 Feb 2014 02:25:10 +0100
Subject: [PATCH 1/4] Pass member_base as an argument to get_compression_type()

Allow other member base names, instead of hardcoding data.tar.
---
 udpkg.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/udpkg.c b/udpkg.c
index 2adfd16..73fa9d8 100644
--- a/udpkg.c
+++ b/udpkg.c
@@ -163,7 +163,9 @@ static const char *decompression_tool (const compression_type t) {
 	}
 }
 
-static compression_type get_compression_type (struct package_t *pkg) {
+static compression_type get_compression_type(struct package_t *pkg,
+	const char *member_base)
+{
 	FILE *infp = NULL;
 	char buf[1024];
 	char *extension = NULL;
@@ -177,8 +179,8 @@ static compression_type get_compression_type (struct package_t *pkg) {
 	}
 
 	while (fgets(buf, sizeof(buf), infp)) {
-		if (strncmp(buf, data_member_base, strlen(data_member_base)) == 0) {
-			extension = buf + strlen(data_member_base);
+		if (strncmp(buf, member_base, strlen(member_base)) == 0) {
+			extension = buf + strlen(member_base);
 			if (extension[strlen(extension) - 1] == '\n')
 extension[strlen(extension) - 1] = '\0';
 			break;
@@ -188,7 +190,7 @@ static compression_type get_compression_type (struct package_t *pkg) {
 
 	if (extension == NULL) {
 		FPRINTF(stderr, "No %s* found in %s\n",
-			data_member_base, pkg->file);
+			member_base, pkg->file);
 		return unknown_compression;
 	}
 
@@ -200,7 +202,7 @@ static compression_type get_compression_type (struct package_t *pkg) {
 	}
 	else {
 		FPRINTF(stderr, "Invalid compression type for %s* of %s\n",
-			data_member_base, pkg->file);
+			member_base, pkg->file);
 		return unknown_compression;
 	}
 }
@@ -226,7 +228,7 @@ static int dpkg_dounpack(struct package_t *pkg)
 
 	DPRINTF("Unpacking %s\n", pkg->package);
 
-	compression_type = get_compression_type(pkg);
+	compression_type = get_compression_type(pkg, data_member_base);
 	if (compression_type == unknown_compression)
 		return 1;
 
@@ -556,7 +558,7 @@ static int dpkg_contents(struct package_t *pkg)
 
 	reqarg(pkg);
 
-	compression_type = get_compression_type(pkg);
+	compression_type = get_compression_type(pkg, data_member_base);
 	if (compression_type == unknown_compression)
 		return 1;
 
-- 
1.9.0.rc3.244.g3497008

From 193c1b896291da42844953bdf693245ec4c8adaa Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 16 Feb 2014 02:28:34 +0100
Subject: [PATCH 2/4] Add support for uncompressed deb members

---
 udpkg.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/udpkg.c b/udpkg.c
index 73fa9d8..ef6bdf7 100644
--- a/udpkg.c
+++ b/udpkg.c
@@ -18,7 +18,7 @@
 static int force_configure = 0;
 static int loadtemplate = 1;
 
-static const char *data_member_base = "data.tar.";
+static const char *data_member_base = "data.tar";
 
 /* 
  * Main udpkg implementation routines
@@ -144,21 +144,24 @@ typedef enum compression_type compression_type;
 enum compression_type {
 	gz_compression,
 	xz_compression,
+	no_compression,
 	unknown_compression,
 };
 
 static const char *compression_extension (const compression_type t) {
 	switch (t) {
-		case gz_compression: return "gz";
-		case xz_compression: return "xz";
+		case gz_compression: return ".gz";
+		case xz_compression: return ".xz";
+		case no_compression: return "";
 		default: return "";
 	}
 }
 
 static const char *decompression_tool (const compression_type t) {
 	switch (t) {
-		case gz_compression: return "gunzip";
-		case xz_compression: return "unxz";
+		case gz_compression: return "gunzip -c";
+		case xz_compression: return "unxz -c";
+		case no_compression: return "cat";
 		default: return "";
 	}
 }
@@ -200,6 +203,10 @@ static compression_type get_compression_type(struct package_t *pkg,
 	else i

Bug#739411: udpkg: Support for data.tar, control.tar and control.tar.xz

[Guillem Jover]

Package: udpkg
Version: 1.16
Severity: wishlist
Tags: patch
X-Debbugs-CC: Philipp Kern 

Hi!

Here's a patch series adding data.tar, control.tar and control.tar.xz
support, the uncompressed member support just out of completeness. To
create a deb package with a different control.tar compression you can
use «dpkg-deb --uniform-compression pkg/» for example.

Note I've only tested «udpkg -c» and «udpkg -f», the changes in unpacking
are pretty obvious, but testing them would be nice. I've also used cat
for the uncompressed members as I didn't think further optimization there
was worth it(?). I've also tried to use the prevailing coding-style,
which in some cases conflicted with the immediate surrounding code.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140218120148.ga32...@gaara.hadrons.org

Bug#739136: debootstrap: Sync deb support with latest dpkg-deb

[Guillem Jover]

Package: debootstrap
Version: 1.0.59
Severity: wishlist
Tags: patch

Hi!

When using the fallback code instead of dpkg-deb the implementation
is missing support for uncompressed data.tar and control.tar and
control.tar.xz. Although this should not be needed in Debian for
the base system, it might be needed by downstreams, or when a user
includes a package manually. And I think it does not harm to have
deb support in sync with what dpkg-deb supports.

The attached two patches implement this. Although I've only tested
the functions in isolation, not as part of a debootstrap run with
such packages.

Thanks,
Guillem
From 009dc7588934809654a1eac28d66e323601215f8 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 30 Jul 2013 18:18:42 +0200
Subject: [PATCH 1/2] Add uncompressed data.tar deb member support

These are currently not accepted by the Debian archive, but have been
supported since dpkg 1.10.24, and they do not incur any additional
dependency from the host system. This is mostly for completeness' sake,
as Debian base packages with uncompressed data.tar members are probably
not going to be used at all.
---
 functions | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/functions b/functions
index 4e3955a..8fc0bee 100644
--- a/functions
+++ b/functions
@@ -813,12 +813,13 @@ extract_ar_deb_field () {
 
 extract_ar_deb_data () {
 	local pkg="$1"
-	local tarball=$(ar -t "$pkg" | grep "^data.tar.[bgx]z")
+	local tarball=$(ar -t "$pkg" | grep "^data.tar")
 
 	case "$tarball" in
 		data.tar.gz) cat_cmd=zcat ;;
 		data.tar.bz2) cat_cmd=bzcat ;;
 		data.tar.xz) cat_cmd=xzcat ;;
+		data.tar) cat_cmd=cat ;;
 		*) error 1 UNKNOWNDATACOMP "Unknown compression type for %s in %s" "$tarball" "$pkg" ;;
 	esac
 
-- 
1.9.0.rc3.244.g3497008

From aa3e446f3f87cec655dd66929c85050f6776c812 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Thu, 23 Jan 2014 20:14:11 +0100
Subject: [PATCH 2/2] Add uncompressed and xz control.tar deb member support

These are currently not accepted by the Debian archive, but are
supported since dpkg 1.17.6, and they do not incur any additional
dependency from the host system. This is mostly for completeness'
sake, as Debian base packages with uncompressed or xz control.tar
members are probably not going to be used at all.
---
 functions | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/functions b/functions
index 8fc0bee..0d48390 100644
--- a/functions
+++ b/functions
@@ -805,10 +805,22 @@ extract_dpkg_deb_data () {
 extract_ar_deb_field () {
 	local pkg="$1"
 	local field="$2"
+	local tarball=$(ar -t "$pkg" | grep "^control\.tar")
 
-	ar -p "$pkg" control.tar.gz | zcat |
-	tar -O -xf - control ./control 2>/dev/null |
-	grep -i "^$field:" | sed -e 's/[^:]*: *//' | head -n 1
+	case "$tarball" in
+		control.tar.gz) cat_cmd=zcat ;;
+		control.tar.xz) cat_cmd=xzcat ;;
+		control.tar) cat_cmd=cat ;;
+		*) error 1 UNKNOWNCONTROLCOMP "Unknown compression type for %s in %s" "$tarball" "$pkg" ;;
+	esac
+
+	if type $cat_cmd >/dev/null 2>&1; then
+		ar -p "$pkg" "$tarball" | $cat_cmd |
+		tar -O -xf - control ./control 2>/dev/null |
+		grep -i "^$field:" | sed -e 's/[^:]*: *//' | head -n 1
+	else
+		error 1 UNPACKCMDUNVL "Extracting %s requires the %s command, which is not available" "$pkg" "$cat_cmd"
+	fi
 }
 
 extract_ar_deb_data () {
-- 
1.9.0.rc3.244.g3497008

Re: xz-compressed control metadata

[Guillem Jover]

Hi!

On Sun, 2012-11-04 at 22:27:58 +0100, Guillem Jover wrote:
> On Sun, 2012-11-04 at 08:11:25 +0100, Guillem Jover wrote:
> > On Sat, 2012-11-03 at 21:56:12 +0100, Philipp Kern wrote:
> > > are there plans on the dpkg side to support other compression methods
> > > for the control.tar in .deb files? Some of the d-i udebs have large
> > > debconf templates which are only compressed with gzip, while xz would
> > > yield smaller udebs.
> 
> > One problem is that I don't really feel like adding options to select
> > the compressor for each different ar member, so if the compressor is
> > global it means it cannot be switched to compress the control member
> > with anything other than gzip until a dpkg supporting unpacking that
> > is in stable, which would seem to be too late for that now (barring
> > an exception from the RT of course, althought that might still require
> > string changes which would be pretty annoying). And special casing
> > udebs is not an option either, because dpkg-deb does not have any
> > kind of knowledge about them in the first place.
> 
> Having slept over this, it just ocurred to me that I'd be fine with a
> new option (something in spirit like --compressor-unified) for dpkg-deb,
> which once implemented could be used by debhelper exclusively for udebs
> already during jessie, and which would become a noop once and if the
> switch to the unified members compressor happens after jessie+1.
> 
> I've added this to my TODO list for when I continue reworking the
> (un)packing code.

This is now implemented in dpkg 1.17.6, as the --uniform-compression
option for dpkg-deb.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140115180510.ga14...@gaara.hadrons.org

Bug#733179: debootstrap should abort if the keyring is missing, not just warn

[Guillem Jover]

Hi Joey!

On Thu, 2013-12-26 at 22:21:52 -0400, Joey Hess wrote:
> I actually think it would be more of a win to change the default mirror
> url from the current http://ftp.us.debian.org/ to a https url. This
> provides weak (CA) verification on systems without the Debian keyring,
> which is considerably better than nothing.
> 
> A good candiate for such a mirror is https://mirrors.kernel.org/debian,
> although it's not currently in the {ftp,http}.us.debian.org rotation for
> some reason, and lacks IPv6. (None of the {ftp,http}.us.debian.org
> mirrors currently support https.) Due to those limitations, and to avoid
> overloading it, I've modified debootstrap to default to the https mirror only
> when the gpg keyring is not available.

I see this in the latest debootstrap upload:

,---
  [ Joey Hess ]
  * When deboostrapping Debian, and the debian-archive-keyring is not
available, switch the default mirror to a https url. This way at
least the CA level of security is available even for users who
have no way to check gpg keys in the WoT. The https mirror is
currently https://mirrors.kernel.org/debian.
  * Avoid writing https urls into sources.list, as apt does not support https.
`---

Although apt should support https if one has apt-transport-https
installed. You might already know that or you might still not want to
use https URIs on the target system, just dropping a note here in case
you didn't know about this.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131230100446.ga16...@gaara.hadrons.org

Bug#706571: kernel-wedge: Remove explicit field exporting rules

[Guillem Jover]

Package: kernel-wedge
Version: 2.85
Severity: wishlist
Tags: patch

Hi!

kernel-wedge generates .udeb:s with XC-Package-Type and
XB-Kernel-Version fields, but the explicit field exporting rules are
not needed any more as dpkg-dev supports these fields since 2007.

Attached a patch fixing this.

Thanks,
Guillem
From 5906bc0f32a0c8187fa2f28ad23ddc34d604306d Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Wed, 1 May 2013 18:34:02 +0200
Subject: [PATCH] gen-control: Remove explicit field exporting rules

These fields have been known by dpkg-dev since 2007.
---
 commands/gen-control | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/commands/gen-control b/commands/gen-control
index afffa2d..19a6978 100755
--- a/commands/gen-control
+++ b/commands/gen-control
@@ -4,7 +4,7 @@
 use strict;
 use warnings;
 
-my @controlfields=qw(Package XC-Package-Type Provides Depends Architecture XB-Kernel-Version Section Priority Description);
+my @controlfields=qw(Package Package-Type Provides Depends Architecture Kernel-Version Section Priority Description);
 my @versions;
 my @packages;
 my %packages;
@@ -152,8 +152,8 @@ foreach my $ver (@versions) {
 		$pkg{Architecture}=$arch;
 		$pkg{orig_package}=$package->("Package");
 		$pkg{Package}=$package->("Package")."-".$kernelversion."-".$flavour."-di";
-		$pkg{'XC-Package-Type'}="udeb";
-		$pkg{'XB-Kernel-Version'}=$kernelversion."-".$flavour;
+		$pkg{'Package-Type'}="udeb";
+		$pkg{'Kernel-Version'}=$kernelversion."-".$flavour;
 
 		next if $excluded{$pkg{Package}};
 		
-- 
1.8.3.rc0

Re: [d-i manual] Deactivate translations?

[Guillem Jover]

Hi!

On Sun, 2013-02-03 at 18:38:08 +0100, Christian PERRIER wrote:
> Quoting Holger Wansing (li...@wansing-online.de):
> > ca
> > catalan hasn't receive any updates since the release of Squeeze / 
> > AND catalan is an xml based translation, what means that the translation 
> > stays 
> > the same even if there are changings in en!
> > 52 files are not up-to-date ATM
> > IMHO this translation should be deactivated for official builds!
> 
> I agree it should be de-activated, but maybe try to CC
> debian-l10n-catalan, which is a quite busy list, while Guillem and
> Jordi are less involved in translations nowadays.

I resigned as Catalan translator and coordinator last year.

(.)

I still have pending locally a review that got submitted to me long
time ago, that I need to check and commit, but except for that I'm
not planning on doing anything else.

> But I doubt that a very outdated XML-based translation is easy to
> update. Particularly in a rush.

When I was taking care of the manual, we managed to update it in a
week or so (?), I don't think that should be a problem.

Regards,
Guillem


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130203174738.ga26...@gaara.hadrons.org

Bug#698818: anna: asprintf failure handling

[Guillem Jover]

Package: anna
Version: 1.45
Severity: normal

Hi!

On Sat, 2012-12-01 at 11:27:07 +0100, Guillem Jover wrote:
> With commit a731c80638abe827b206d8dbe7e51311f5981dd8 to anna, the error
> handling for asprintf() is moved into the new xasprintf(), and those
> call sites no longer check for error conditions, but xvasprintf() can
> still return NULL in some cases, which could end up with segfaults.

Filing this as a bug report now that a version with that commit has
been released, so that it does not get forgotten.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130124000754.ga18...@gaara.hadrons.org

Bug#697985: debian-installer: Remove explicit field exporting rules from docs

[Guillem Jover]

Package: debian-installer
Version: 20121115
Severity: wishlist
Tags: patch

Hi!

Prompted by a reference in a mail to policy by Jonathan Nieder, I
checked and removed all explicit exporting rules for fields known by
dpkg-dev since 2007. Attached is the patch.

Thanks,
Guillem
From 5046d54855bb9c4f683516fc9a1d1107e89a84ea Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 12 Jan 2013 14:00:24 +0100
Subject: [PATCH] Remove explicit field exporting rules from those understood
 by dpkg-dev

These have been supported for a long time now, since 2007.
---
 doc/devel/historic/kernel-modules.txt  | 4 ++--
 doc/devel/internals/udebs.xml  | 8 
 doc/devel/modules.txt  | 2 +-
 doc/talks/d-i_debconf6/d-i_debconf6.tex| 6 +++---
 doc/talks/d-i_debconf6/slides/d-i_debconf6.tex | 4 ++--
 5 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/doc/devel/historic/kernel-modules.txt b/doc/devel/historic/kernel-modules.txt
index 9280325..9efb21e 100644
--- a/doc/devel/historic/kernel-modules.txt
+++ b/doc/devel/historic/kernel-modules.txt
@@ -9,9 +9,9 @@ kernel modules for the running kernel, so anna needs a way to figure
 out
   1. Whether a udeb is a kernel modules udeb
   2. What kernel versino it belongs to
-To solve this, we introduce the  XB-kernel-version  control field. It
+To solve this, we introduce the  Kernel-Version  control field. It
 will simply say
-  XB-kernel-version: 2.4.19
+  Kernel-Version: 2.4.19
 for the 2.4.19 kernel module udebs, et.c.
 
 The memory footprint is small, on i386 I think installing all available
diff --git a/doc/devel/internals/udebs.xml b/doc/devel/internals/udebs.xml
index 664d600..bc64841 100644
--- a/doc/devel/internals/udebs.xml
+++ b/doc/devel/internals/udebs.xml
@@ -129,17 +129,17 @@ Build-Depends: debhelper (>= 7.3.10), libdebian-installer4-dev (>= 0.41),
 
 Package: kbd-chooser
 Architecture: i386 amd64 powerpc alpha hppa sparc [...]
-XC-Package-Type: udeb
+Package-Type: udeb
 Depends: ${shlibs:Depends}, ${misc:Depends}, console-keymaps
 Description: Detect a keyboard and select layout
-XB-Installer-Menu-Item: 1200
+Installer-Menu-Item: 1200
 
 
 
 
-The line XC-Package-Type tells
+The line Package-Type tells
 debhelper to treat the package as a udeb. The
-XB-Installer-Menu-Item is added in the control file for
+Installer-Menu-Item is added in the control file for
 the udeb and will eventually end up in the dpkg
 status file to help main-menu figure out that this
 udeb should be included in the menu and in what order
diff --git a/doc/devel/modules.txt b/doc/devel/modules.txt
index ffd4618..fc3b9f1 100644
--- a/doc/devel/modules.txt
+++ b/doc/devel/modules.txt
@@ -118,5 +118,5 @@ A 2 minute primer on building udebs.
 
 
 1. Add a Build-Dependency against debhelper (>= 4.2).
-2. Add "XC-Package-Type: udeb" to the package's stanza in the control file.
+2. Add "Package-Type: udeb" to the package's stanza in the control file.
 3. Build the package!
diff --git a/doc/talks/d-i_debconf6/d-i_debconf6.tex b/doc/talks/d-i_debconf6/d-i_debconf6.tex
index f53e88a..0d2c45f 100644
--- a/doc/talks/d-i_debconf6/d-i_debconf6.tex
+++ b/doc/talks/d-i_debconf6/d-i_debconf6.tex
@@ -365,13 +365,13 @@ Build-Depends: debhelper (>= 5.0.22), libdebian-installer4-dev (>= 0.41), po-deb
 
 Package: kbd-chooser
 Architecture: i386 amd64 powerpc alpha hppa sparc [...]
-XC-Package-Type: udeb
+Package-Type: udeb
 Depends: ${shlibs:Depends}, ${misc:Depends}, console-keymaps
 Description: Detect a keyboard and select layout
-XB-Installer-Menu-Item: 12
+Installer-Menu-Item: 12
 \end{verbatim}
 
-The line \texttt{XC-Package-Type} tells debhelper to treat the package as a udeb. The \texttt{XB-Installer-Menu-Item} is added in the control file for the udeb and will eventually end up in the dpkg status file to help main-menu figure out that this udeb should be included in the menu and in what order\footnote{The file \texttt{installer/doc/devel/menu-item-numbers.txt} in the d-i SVN repository documents menu numbers currently in use.}. Packaging a udeb becomes a bit harder if it is derived from a regular package but needs to be compiled with different compiler options (e.g. some features disabled or a different optimization). 
+The line \texttt{Package-Type} tells debhelper to treat the package as a udeb. The \texttt{Installer-Menu-Item} is added in the control file for the udeb and will eventually end up in the dpkg status file to help main-menu figure out that this udeb should be included in the menu and in what order\footnote{The file \texttt{installer/doc/devel/menu-item-numbers.txt} in the d-i SVN repository documents menu numbers currently in use.}. Packaging a udeb becomes a bit harder if it is derived from a regular package but needs to be compiled with different compiler options (e.g. some features disabled or a different optimization). 
 
 The main thing t

Re: Bug#694886: dpkg: Complain about missing descriptions for packages in /var/lib/dpkg/available

[Guillem Jover]

Control: reassign -1 debootstrap
Control: retitle -1 debootstrap: Creates available file w/o Description fields

On Sat, 2012-12-01 at 21:21:33 +0100, Petter Reinholdtsen wrote:
> [Guillem Jover]
> > Was it obvious from the log when did it start to warn?
> 
> Yes.  It happened while deboostrap was running.  Just after e2fsprogs
> was configured and before adduser was unpacked:

> Dec  1 17:16:00 debootstrap: Setting up sysvinit (2.88dsf-34) ...
> Dec  1 17:16:00 debootstrap: sysvinit: creating /run/initctl
> Dec  1 17:16:00 debootstrap: Not restarting sysvinit: init not running
> Dec  1 17:16:00 debootstrap: Setting up e2fsprogs (1.42.5-1) ...
> Dec  1 17:16:00 debootstrap: dpkg: warning: parsing file 
> '/var/lib/dpkg/available' near line 35 package 'libc-bin':
> Dec  1 17:16:00 debootstrap:  missing description
> [...]
> Dec  1 17:16:01 debootstrap:  missing description
> Dec  1 17:16:01 debootstrap: dpkg: warning: parsing file 
> '/var/lib/dpkg/available' near line 3870 package 'whiptail':
> Dec  1 17:16:01 debootstrap:  missing description
> Dec  1 17:16:01 debootstrap: (Reading database ... 
> Dec  1 17:16:01 debootstrap: 6256 files and directories currently installed.)
> Dec  1 17:16:01 debootstrap: Unpacking adduser (from 
> .../adduser_3.113+nmu3_all.deb) ...
> Dec  1 17:16:01 debootstrap: Unpacking libstdc++6:i386 (from 
> .../libstdc++6_4.7.2-4_i386.deb) ...
> Dec  1 17:16:01 debootstrap: Unpacking libapt-pkg4.12:i386 (from 
> .../libapt-pkg4.12_0.9.7.6_i386.deb) ...
> Dec  1 17:16:02 debootstrap: Unpacking gpgv (from .../gpgv_1.4.12-6_i386.deb) 
> ...

> > Maybe the file was not right from the start; I'm not sure if d-i
> > populates it.
> 
> No idea. :)

Ok, having checked debootstrap code now, it would seem like
functions:setup_available() is the culprit. And the setup_available()
call in sid:second_stage_install() would seem to match what's
happening on the log.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121201205916.ga23...@gaara.hadrons.org

anna: asprintf failure handling

[Guillem Jover]

Hi!

With commit a731c80638abe827b206d8dbe7e51311f5981dd8 to anna, the error
handling for asprintf() is moved into the new xasprintf(), and those
call sites no longer check for error conditions, but xvasprintf() can
still return NULL in some cases, which could end up with segfaults.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121201102707.ga17...@gaara.hadrons.org

Re: Bug#693922: dpkg: amd64 dpkg refuses to install i386 package when dependencies are installed

[Guillem Jover]

Control: severity -1 whishlist
Control: clone -1 -2
Control: reassign -1 xserver-common
Control: retitle -1 xserver-common: Please mark as M-A:foreign
Control: reassign -2 keyboard-configuration
Control: retitle -2 keyboard-configuration: Please mark as M-A:foreign

Hi!

[ Beware, I've not checked if other binary packages from the producing
  source package might need marking too. ]

On Wed, 2012-11-21 at 23:26:14 +, Noel David Torres Taño wrote:
> On Miércoles, 21 de noviembre de 2012 20:01:17 Guillem Jover wrote:
> > On Wed, 2012-11-21 at 19:40:38 +, Noel David Torres Taño wrote:
> > > Package: dpkg
> > > Version: 1.16.9
> > > Severity: important
> > > 
> > > *** Please consider answering these questions, where appropriate ***
> > > 
> > >* What led up to the situation?
> > > 
> > > amd64 system trying to install an i386 package required for multiarch
> > > setup of Wine
> > > 
> > >* What exactly did you do (or not do) that was effective (or
> > >
> > >  ineffective)?
> > > 
> > > dpkg -i
> > > 
> > >* What was the outcome of this action?
> > > 
> > > error
> > > 
> > >* What outcome did you expect instead?
> > > 
> > > install
> > > 
> > > *** End of the template - remove these lines ***
> > > 
> > > root@host:~# LANG=C dpkg -l xserver-common keyboard-configuration
> > > Desired=Unknown/Install/Remove/Purge/Hold
> > > 
> > > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig
> > > | -pend
> > > |
> > > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> > > |
> > > ||/ Name  Version   Architecture 
> > > ||Description
> > > 
> > > +++-=-=-=-===
> > > = ii 
> > > keyboard-configuration1.87  all  
> > > system-wide keyboard preferences ii  xserver-common   
> > > 2:1.12.4-3all   common files used by various X
> > > servers root@host:~# LANG=C dpkg -i
> > > xserver-xorg-core_2%3a1.12.4-3_i386.deb (Reading database ... 318831
> > > files and directories currently installed.) Preparing to replace
> > > xserver-xorg-core 2:1.12.4-3 (using
> > > xserver-xorg-core_2%3a1.12.4-3_i386.deb) ... Unpacking replacement
> > > xserver-xorg-core ...
> > > 
> > > dpkg: dependency problems prevent configuration of xserver-xorg-core:
> > >  xserver-xorg-core depends on xserver-common (>= 2:1.12.4-3).
> > >  xserver-xorg-core depends on keyboard-configuration.
> > > 
> > > dpkg: error processing xserver-xorg-core (--install):
> > >  dependency problems - leaving unconfigured
> > > 
> > > Processing triggers for libglx-nvidia-alternatives ...
> > > Processing triggers for man-db ...
> > > 
> > > Errors were encountered while processing:
> > >  xserver-xorg-core
> > > 
> > > You can see that dependencies are installed, but dpkg refuses to
> > > install xserver-xorg-core
> > 
> > That's as expected as per the current spec, arch:all packages are
> > treated as arch:native, so the dependencies are not fulfilled. For now
> > (at least) those packages would need to be marked M-A:foreign to be
> > able to install a foreign xserver-xorg-core, so not a bug in dpkg.
> > 
> > What I don't really understand is why you need to install
> > xserver-xorg-core:i386 to be able to install wine:i386?
> 
> Many thanks. This seems to be a bug in the multiarch documentation instead.

What exact documentation? Most of it is mainly on wikis currently, but
I think this should be covered.

> How can I (or where can I read how to) mark as foreign as you suggest?

That's something that needs to be done on the source package, so it
needs to go through the maintainer. I've reassigned this bug to those
packages now.

> Please note that I need the :all package to fulfill dependencias both for 
> xserver-xorg-core:i386 and for xserver-xorg-core:amd64

Well these are not co-installable, but the marking is needed anyway in
case one wants the foreign X server.

> About wine... I have wine:i386 corerctly installed, but it does not run
> the games properly without libgl1-nvidia-glx:i386 whose dependencies
> chain to this.

I still don't see why using foreign wine with a foreign
libgl1-nvidia-glx would require to install a foreign X server too,
AFAIR I've used such setup but w/ a foreign -mesa-glx and mesa-dri
package. OTOH wanting to use a foreign X server does not invalidate
these bug reports, so I guess this does not matter much.

Thanks,
Guillem


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121128165227.gb18...@gaara.hadrons.org

Re: xz-compressed control metadata

[Guillem Jover]

On Sun, 2012-11-04 at 08:11:25 +0100, Guillem Jover wrote:
> On Sat, 2012-11-03 at 21:56:12 +0100, Philipp Kern wrote:
> > are there plans on the dpkg side to support other compression methods
> > for the control.tar in .deb files? Some of the d-i udebs have large
> > debconf templates which are only compressed with gzip, while xz would
> > yield smaller udebs.

> One problem is that I don't really feel like adding options to select
> the compressor for each different ar member, so if the compressor is
> global it means it cannot be switched to compress the control member
> with anything other than gzip until a dpkg supporting unpacking that
> is in stable, which would seem to be too late for that now (barring
> an exception from the RT of course, althought that might still require
> string changes which would be pretty annoying). And special casing
> udebs is not an option either, because dpkg-deb does not have any
> kind of knowledge about them in the first place.

Having slept over this, it just ocurred to me that I'd be fine with a
new option (something in spirit like --compressor-unified) for dpkg-deb,
which once implemented could be used by debhelper exclusively for udebs
already during jessie, and which would become a noop once and if the
switch to the unified members compressor happens after jessie+1.

I've added this to my TODO list for when I continue reworking the
(un)packing code.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121104212758.ga26...@gaara.hadrons.org

Re: xz-compressed control metadata

[Guillem Jover]

Hi!

On Sat, 2012-11-03 at 21:56:12 +0100, Philipp Kern wrote:
> are there plans on the dpkg side to support other compression methods
> for the control.tar in .deb files? Some of the d-i udebs have large
> debconf templates which are only compressed with gzip, while xz would
> yield smaller udebs.

This is something that crossed my mind when I thought about considering
changelog and copyright as dpkg metadata files as those tend to be big,
and when moved to the control member, they would benefit from better
compression methods. I don't really know what was the rationale for
adding other compressors support only for the data member, because
those archives cannot be extracted with really old tools anyway, *but*
their metadata could still be analyzed, although that does not seem
like a much compelling argument to me.

One problem is that I don't really feel like adding options to select
the compressor for each different ar member, so if the compressor is
global it means it cannot be switched to compress the control member
with anything other than gzip until a dpkg supporting unpacking that
is in stable, which would seem to be too late for that now (barring
an exception from the RT of course, althought that might still require
string changes which would be pretty annoying). And special casing
udebs is not an option either, because dpkg-deb does not have any
kind of knowledge about them in the first place.

> As far as I know control.tar.gz is hardcoded in various places, though.

And there's that too.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121104071125.ga17...@gaara.hadrons.org

Re: debian-cd BoF at DebConf

[Guillem Jover]

Hi!

On Wed, 2012-07-18 at 17:19:40 +0100, Steve McIntyre wrote:
> CD sizing problems
> ==

> There has been much discussion about switching packages over to using
> xz compression instead of gzip by default, including Hideki Yamane's
> excellent session "Let's shrink Debian package archive!" [3]. Ansgar
> has been looking into the possibilities here of re-building a subset
> of the core packages using xz, and I think it's clear that this is the
> solution for Wheezy at least. In discussion after Hideki's xz talk, I
> think there was broad agreement that we should just switch to xz by
> default, *but* with the option to use a different (or even null)
> compressor where it makes sense (e.g. in packages full of
> already-compressed files such as open-clipart). There has been a
> suggestion that we should leave base packages using gzip for the sake
> of foreign users of debootstrap, but I firmly believe we should just
> tell them they'll need xz in future. Let's not hold ourself back
> here...

I cooked a patch for dpkg several weeks ago, when this got discussed
in debian-devel, to add configurable default compressor at dpkg build
time and to switch it to xz for Debian, including updated documentation,
etc. So if there's agreement, and the release team would accept this
change, then I can quickly prepare such dpkg upload.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120718190121.ga22...@gaara.hadrons.org

Re: Wheezy release: CDs are not big enough any more...

[Guillem Jover]

On Sat, 2012-05-12 at 17:04:16 +0100, Steve McIntyre wrote:
> Remembering the fun that we had during the Squeeze release with trying
> to make single-CD installations work well, it's time to consider what
> we're going to *claim* to support in Wheezy. We've had a history of
> supporting the following single-CD installations:

Yes, I'd not see any problem from my side with switching the default
dpkg-deb compression to xz for 1.16.4, if people are fine with that (as
long as it's not conditional). Last time there were some concerns about
slow architectures or low memory systems, but the default preset is
quite conservative so I don't really see the issue. And if specific
packages are problematic they can always decide to use another
compression type or level. Also if udeb:s are going to be using
xz then it makes even more sense to use it for everything.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120513000625.ga6...@gaara.hadrons.org

Re: Proposal: convert all udebs to xz compression

[Guillem Jover]

On Sat, 2011-11-19 at 17:32:49 -0200, Otavio Salvador wrote:
> On Sat, Nov 19, 2011 at 17:21, Philipp Kern  wrote:
> >  We could start with -z0 of course, which would be
> > supported by dpkg-dev and hence a trivial patch of debhelper would do.
> > But it doesn't gain that much.

If you mean dpkg-deb, then as mentioned on the bug report -z0 will switch
the compressor to none. The closer thing you can get right now is -z1.

> Dpkg people, can you comment on that? I've pinged people on IRC
> already about this bug earlier today.

I'm not on IRC anymore. In any case I've been making up my mind over
this and playing with some possible options and some draft code, I'll
reply to the bug report when I have something more concrete.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2020011931.ga21...@gaara.hadrons.org

Re: Bug#605009: serious performance regression with ext4

[Guillem Jover]

Hi Ted!

On Sun, 2010-11-28 at 23:11:52 -0500, Ted Ts'o wrote:
> I did some experimenting, and I figured out what was going on.  You're
> right, (c) doesn't quite work, because delayed allocation meant that
> the writeout didn't take place until the fsync() for each file
> happened.  I didn't see this at first; my apologies.

Thanks for the analysis.

> However, this *does* work:
> 
> extract(a);
> sync_file_range(fd.a, 0, 0, SYNC_FILE_RANGE_WRITE); 
> extract(b.dpkg-new);
> sync_file_range(fd.b, 0, 0, SYNC_FILE_RANGE_WRITE); 
> extract(c.dpkg-new);
> sync_file_range(fd.c, 0, 0, SYNC_FILE_RANGE_WRITE); 

The man page and the kernel sources seem to indicate this might block
depending on the size of the request queue?

> sync_file_range(fd.a, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE); 
> sync_file_range(fd.b, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE); 
> sync_file_range(fd.c, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE); 

> fdatasync(a);
> fdatasync(b.dpkg-new);
> fdatasync(c.dpkg-new);
> 
> rename(b.dpkg-new, b);
> rename(c.dpkg-new, c);

> What's going on here?  sync_file_range() is a Linux specific system
> call that has been around for a while.  It allows program to control
> when writeback happens in a very low-level fashion.  The first set of
> sync_file_range() system calls causes the system to start writing back
> each file once it has finished being extracted.  It doesn't actually
> wait for the write to finish; it just starts the writeback.

Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)
instead, skimming over the kernel source seems to indicate it might
end up doing more or less the same thing but in a portable way?

Could someone with ext4/btrfs/xfs/etc test w/ and w/o the attached patch
against dpkg?

thanks,
guillem
diff --git a/src/archives.c b/src/archives.c
index a2cba6a..a94096f 100644
--- a/src/archives.c
+++ b/src/archives.c
@@ -683,6 +683,9 @@ tarobject(void *ctx, struct tar_entry *ti)
_("backend dpkg-deb during `%.255s'"),
path_quote_filename(fnamebuf, ti->name, 256));
 }
+
+posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED);
+
 r = ti->size % TARBLKSZ;
 if (r > 0)
   if (safe_read(tc->backendpipe, databuf, TARBLKSZ - r) == -1)

Re: Bug#605009: serious performance regression with ext4

[Guillem Jover]

Hi!

On Fri, 2010-11-26 at 16:52:54 -0500, Ted Ts'o wrote:
> On Fri, Nov 26, 2010 at 03:53:27PM +0100, Raphael Hertzog wrote:
> > Just to sum up what dpkg --unpack does in 1.15.8.6:
> > 1/ set the package status as half-installed/reinst-required
> > 2/ extract all the new files as *.dpkg-new
> > 3/ for all the unpacked files: fsync(foo.dpkg-new) followed by
> >rename(foo.dpkg-new, foo)

> What are you doing?

We already had this conversation some time ago in
.

> 1) Suppose package contains files "a", "b", and "c".  Which are you
> doing?

[...]

Anyway, dpkg is currently doing the variation on c that Raphaël
posted, including making backups so that it can rollback the entire
package if something goes wrong.

> (c) will perform the best for most file systems, including ext4.

Well it does not, and that's also what was mentioned in the bug
report. Something we've found out recently (as Raphaël mentioned too)
is that with nodelalloc the performance issues *and* the zero-length
issues disappear, which seems like a clear win to me, and so IMO
changing the default file system mount option to nodelalloc seems to
be the way to go.

> As a further optimization, if "b" and "c" does not exist, of course
> it would be better to extract into "b" and "c" directly, and skip the
> rename, i.e.:

> d)  extract(a.dpkg-new);
> extract(b);   # assuming the file "b" does not yet 
> exist
> extract(c);   # assuming the file "c" does not yet 
> exist
> fsync(a.dpkg-new);
> fsync(b);
> fsync(c);
> rename(a.dpkg-new, a);
> 
> ... and then set the package status as unpacked.

That would make possible for partial files to appear on their final path
and thus available for external use while they are being extracted. I
don't think that's a good idea.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101127094018.ga14...@gaara.hadrons.org

Re: Bug#584254: dpkg should support a --force-unsafe-io option or such

[Guillem Jover]

Hi!

On Sun, 2010-10-10 at 12:37:27 +0300, Modestas Vainius wrote:
> On sekmadienis 10 Spalis 2010 01:06:41 Otavio Salvador wrote:
> > On Fri, Oct 8, 2010 at 8:55 PM, Modestas Vainius  wrote:
> > > It does not make much sense for dpkg to be in this uber-paranoid mode at
> > > debian-installer time. If power fails, install process will probably have
> > > to be started from scratch anyway. What's more, obviously I have no
> > > choice to use libeatmydata or similar to fight this dpkg behaviour at
> > > debian installer time.
> > > 
> > > In my opinion, dpkg should provide a way to turn off those offensive
> > > *sync() calls and debian installer should make use of it.
> > 
> > I fully agree that d-i doesn't need and shouldn't use it by default.
> > In fact some embedded systems shouldn't use it either in production
> > mode if the media suffer of wearing.
> > 
> > As previously said in this thread, d-i needs to be restarted in case
> > of power outage or something broken and fsync won't help on that
> > except make it taking longer.
> 
> I feel rather strong about this issue because I keep running and running into 
> it in different situations. I truly believe that it should be high priority 
> for squeeze but I won't bump severity myself. To sum up:

I had planned to include changes for this for squeeze, but then the
sudden freeze happened, and after the initial reaction from the
release team on the first exception request I didn't feel like begging
for this and other changes.

> 1) current dpkg is bog slow on modern file systems (brtfs, ext4). What is 
> more, due to frequent sync() calls, it is a very bad idea to run dpkg when 
> other unrelated disk I/O (esp. on modern FSes) is in the background. It just 
> slows everything down.

Right, for some time now I've considered the switch from fsync() to
sync() (on Linux) to be a mistake, as it will affect unrelated file
systems, which might be disruptive in case there's background work being
done.

But this was done because those "modern file systems" didn't perform
adequately with fsync(), and they are the ones which require the syncs
or they will actually lose data.

> 3) dpkg is pointlessly slow in such use cases as buildds where *sync() is not 
> important at all.

Well, even if the buildd chroot supposedly should be able to be recreated
easily, if the zero-lenght file issues appear on it, then it might not
be obvious something is wrong, and might produce bogus packages.

> 2) current dpkg is arguably not suitable for flash media (i.e. embedded 
> devices). This hurts the "universal" part of Debian OS.

> 4) while typical dpkg could be work arounded with libeatmydata, there is no 
> cure for debian-installer.

Sure, I agree the user should be able to disable this, at their own
risk. Or on specific cases, like on d-i.

> And all this is to protect against power failure? Sure, the purpose is noble 
> and maybe it's a good default but due to negative side effects I find it 
> unacceptable that this behaviour is not configurable.

Not only power failures, any abrupt system crash, say the bus getting
locked up, or a user assisted reboot, can produce for example
zero-lenght files on at least ext4 file systems, I don't know about
btrfs. The worst though is that the performance issues affect the file
systems which really need those safety measures. Also take into account
these are not anecdotal cases, Ubuntu who has offered ext4 on installation
for some time now had *hundreds* of duped bug reports on broken systems
due to this.

Anyway, I actually had the changes around last July, and I'll run them
through the release team to see what they say. I've rebased them now,
and will polish them a bit, but they are essentially these:

  
  

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101010122146.ga31...@gaara.hadrons.org

Bug#598729: debootstrap: Does not use correct data.tar in .deb ar extractor

[Guillem Jover]

Package: debootstrap
Version: 1.0.25
Tags: patch

Hi!

Commit r61340 introduced a small bug to the ar extractor for non-gz
data.tar in .debs. Attached is a trivial fix for that.

thanks,
guillem
Index: functions
===
--- functions	(revision 64876)
+++ functions	(working copy)
@@ -777,7 +777,7 @@
 	esac
 
 	if type $cat_cmd >/dev/null 2>&1; then
-		ar -p "$pkg" data.tar.gz | $cat_cmd | tar -xf -
+		ar -p "$pkg" "$tarball" | $cat_cmd | tar -xf -
 	else
 		error 1 UNPACKCMDUNVL "The $cat_cmd is not available on the system"
 	fi

Re: Limiting non-build-time relationships to a set of architectures?

[Guillem Jover]

Hi!

[ CCing #400322 for the additional data. ]

On Tue, 2010-02-09 at 20:25:11 +0100, Cyril Brulebois wrote:
> Frans Pop  (09/02/2010):
> > On Tuesday 09 February 2010, Cyril Brulebois wrote:
> > > Frans Pop  (09/02/2010):
> > > > This format is not (yet) allowed by policy: rootskel-gtk
> > > > (>=0.05) [!s390] (except for build dependencies)
> > >
> > > AFAICT, it just works, and not only for Build-Depends. It can't be
> > > used for an arch: all package, though, since it gets substituted
> > > at build time, so it probably won't do what you would want.
> > 
> > I know that it is going to be allowed in the future and because of
> > that I don't doubt that it (mostly?) works.  But AFAIK *currently*
> > it's not allowed by policy [1], except for build deps. And thus it
> > should not yet be used in uploads.

Actually checking now, there does not seem to have been any wording
proposed yet on #400322, I might try to come up with one.

> Oops, indeed. Looks like I forgot about that particular point, thanks
> for pointing this out. It looks like I've been taking it granted for
> quite some time.

Hmm, I also seem to have forgotten about this (I'll call that fair
bias :). I was curious anyway about how long this support has been
around as I thought it had been long, so did some digging the other
day:

 * Introduced in dpkg 1.10.11 (Tue, 16 Sep 2003 12:52:11 -0500)
   Bug: #170575

 * Regression in dpkg 1.10.14 (Fri, 19 Sep 2003 12:29:34 -0500)

 * Fixed again in dpkg 1.13.17 (Mon, 20 Mar 2006 03:33:03 +0200)
   Bugs: #252657, #324741, #347819

Also I don't think much tools except for dpkg-dev scripts actually
parse the dependency fields in the binary package stanzas in
debian/control. So this should supposedly not break stuff (but then
I've not checked, etc).

> > A reference to an (official) statement from FTP-masters would be.
> 
> I'd rather have -policy@ folks share their mind about it. I guess
> updating the Policy to allow limiting non-build-time relationships
> (Depends, Recommends, …) to some architectures would be nice to
> have.

Right. And I don't see why ftp-masters would have a special say on
this issue either.

> I'm not sure whether warning people about the substitution which
> happens at build time[1] would have its place in the Policy since that
> could be considered an (dpkg-dev) implementation detail (but that can
> cause some headaches).

> [1] Meaning an Architecture: all package with Depends: foo [bar] will
> have foo, or won't have foo, depending on which architecture it
> will be built upon, rather than the conditional Depends stored in
> the resulting binary.

Yeah, this is something the dpkg scripts should detect and error out
on, I've added it to the TODO list (to be pushed).

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100219160021.ga16...@gaara.hadrons.org

Bug#557296: debootstrap: Use dpkg-deb instead of ar when available

[Guillem Jover]

Hi!

On Sun, 2009-11-22 at 19:53:29 -0200, Otavio Salvador wrote:
> debootstrap don't _need_ to support all features of all valid .debs
> but the features accepted in base packages. This doesn't mean we
> shouldn't add features when possible but it is not a requirement for
> debootstrap POV.

One of my initial arguments was that debootstrap can be easily used
with stuff other than Debian, were those policies/restrictions might
not apply.

> On Sun, Nov 22, 2009 at 4:51 AM, Guillem Jover  wrote:
> > Right. Additionally an option could be added to explicitly choose the
> > extractor, to ease testing.
> 
> This indeed is a possible solution to be easier to test it. As Frans
> pointed out d-i is one "tester" of "basic *nix tools backend" already.

I went ahead and implemented it as a separate patch, take it if you
want, or leave it out if you wish.

> > The extractor choosed could be output to avoid that kind of situation.
> > I can amend the patch adding that if desired.
> 
> Ok, you convinced me. Could you amend the patch and send it for review?

I'm attaching the three patches, the first one has not changed, but
adding it for convenience.

thanks,
guillem
>From 0f78dd071235cbcbc9d2d27a74a76c673e06b4a8 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Fri, 20 Nov 2009 19:51:44 +0100
Subject: [PATCH 1/3] Refactor deb extractors into two new functions

---
 functions   |   43 ++
 scripts/debian/potato   |6 +
 scripts/debian/sarge|6 +
 scripts/debian/sarge.buildd |6 +
 scripts/debian/sarge.fakechroot |6 +
 scripts/debian/sid  |6 +
 scripts/debian/woody|6 +
 scripts/debian/woody.buildd |6 +
 scripts/ubuntu/breezy   |6 +
 scripts/ubuntu/dapper   |6 +
 scripts/ubuntu/edgy |6 +
 scripts/ubuntu/feisty   |6 +
 scripts/ubuntu/gutsy|6 +
 scripts/ubuntu/hoary|6 +
 scripts/ubuntu/hoary.buildd |6 +
 scripts/ubuntu/warty|6 +
 scripts/ubuntu/warty.buildd |6 +
 17 files changed, 45 insertions(+), 94 deletions(-)

diff --git a/functions b/functions
index e832d70..66021e8 100644
--- a/functions
+++ b/functions
@@ -717,27 +717,42 @@ get_debs () {
 
  extraction
 
+extract_deb_field () {
+	local pkg="$1"
+	local field="$2"
+
+	ar -p "$pkg" control.tar.gz | zcat |
+	tar -O -xf - control ./control 2>/dev/null |
+	grep -i "^$field:" | sed -e 's/[^:]*: *//' | head -n 1
+}
+
+extract_deb_data () {
+	local pkg="$1"
+	local tarball=$(ar -t "$pkg" | grep "^data.tar.[bgx]z")
+
+	case "$tarball" in
+		data.tar.gz) cat_cmd=zcat ;;
+		data.tar.bz2) cat_cmd=bzcat ;;
+		data.tar.xz) cat_cmd=xzcat ;;
+		*) error 1 UNKNOWNDATACOMP "Unknown compression type for %s in %s" "$tarball" "$pkg" ;;
+	esac
+
+	if type $cat_cmd >/dev/null 2>&1; then
+		ar -p "$pkg" data.tar.gz | $cat_cmd | tar -xf -
+	else
+		error 1 UNPACKCMDUNVL "The $cat_cmd is not available on the system"
+	fi
+}
+
 extract () { (
 	cd "$TARGET"
-	local p=0 tarball cat_cmd
+	local p=0 cat_cmd
 	for pkg in $(debfor "$@"); do
 		p="$(($p + 1))"
 		progress "$p" "$#" EXTRACTPKGS "Extracting packages"
 		packagename="$(echo "$pkg" | sed 's,^.*/,,;s,_.*$,,')"
 		info EXTRACTING "Extracting %s..." "$packagename"
-		tarball=$(ar -t "./$pkg" | grep "^data.tar.[bgx]z")
-		case "$tarball" in
-			data.tar.gz) cat_cmd=zcat ;;
-			data.tar.bz2) cat_cmd=bzcat ;;
-			data.tar.xz) cat_cmd=xzcat ;;
-			*) error 1 UNKNOWNDATACOMP "Unknown compression type for %s in %s" "$tarball" "$pkg" ;;
-		esac
-
-		if type $cat_cmd >/dev/null 2>&1; then
-			ar -p "./$pkg" data.tar.gz | $cat_cmd | tar -xf -
-		else
-			error 1 UNPACKCMDUNVL "The $cat_cmd is not available on the system"
-		fi
+		extract_deb_data "./$pkg"
 	done
 ); }
 
diff --git a/scripts/debian/potato b/scripts/debian/potato
index 3204c7d..304cbe0 100644
--- a/scripts/debian/potato
+++ b/scripts/debian/potato
@@ -43,11 +43,7 @@ first_stage_install () {
 x_feign_install () {
 local pkg=$1
 local deb="$(debfor $pkg)"
-local ver="$(
-ar -p "$TARGET/$deb" control.tar.gz | zcat |
-tar -O -xf - control ./control 2>/dev/null |
-grep -i ^Version: | sed -e 's/[^:]*: *//' | head -n 1
-)"
+loca

Bug#557296: debootstrap: Use dpkg-deb instead of ar when available

[Guillem Jover]

Hi!

On Sat, 2009-11-21 at 18:48:51 -0200, Otavio Salvador wrote:
> On Sat, Nov 21, 2009 at 6:34 PM, Frans Pop  wrote:
> > On Saturday 21 November 2009, Otavio Salvador wrote:
> >> In my opinion debootstrap shouldn't work differently inside of Debian
> >> so I think we shouldn't use dpkg-deb for this. Even though it would
> >> make our life easier giving us "new features" for free it also makes
> >> much more difficult to spot possible missing features when using it in
> >> foreign distributions and I believe this is something we ought to
> >> support well.

Yes, that's why I explicitly pointed that out in the bug report. And I
can understand the reservations.

But then debootstrap has not supported all valid .debs for some time
now, so if ar would be only used outside Debian, it would have been
on the same situation as currently (prior to the extra compression
patch being applied).

And debootstrap already works differently depending on the environment,
say when retrieving the architecture using udpkg, dpkg or a text file.
Or in the pkgdetails case. Just two examples I've seen. Which is not
justification enough to introduce more divergence, of course!

> > That was my initial reaction as well. One thing that could count against
> > that is that in Debian Installer dpkg-deb is not available either, which
> > would probably ensure sufficient testing of that path.

Right. Additionally an option could be added to explicitly choose the
extractor, to ease testing.

> > I should IMO be agreed that debootstrap should never rely on features not
> > commonly available using basic *nix tools.

Sure, and one of the features of the deb format is that it can be
handled that way if desired. But that it can be handled that way does
not mean we should not use the best tool for the job if available, and
falling back to the basic Unix tools variant otherwise.

> Supporting dpkg-deb in this case will only add code complexity
> maintainence issues.

Well, the refactoring patch IMO can be applied regardless of this bug
being rejected.

And I could understand this complaint if we'd be talking about
thousands of lines of code, but the code using dpkg-deb instead of ar
is pretty small (29 lines changed in the functions file including the
chooser logic), with the dpkg-deb variant being the simpler one. :)

> I can foresee we asking: This debootstrap failure were with it running
> inside of Debian or d-i?

The extractor choosed could be output to avoid that kind of situation.
I can amend the patch adding that if desired.

thanks,
guillem



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

Bug#557296: debootstrap: Use dpkg-deb instead of ar when available

[Guillem Jover]

Package: debootstrap
Version: 1.0.21
Severity: wishlist
Tags: patch

Hi!

Here's two patches to use dpkg-deb if available instead of manually
handling the deb files with ar. This will make the code future-proof
in case the format would change, say new compression formats, etc.
OTOH it might make it harder to spot that the non dpkg-deb case does
not support it. And it also avoids the dependency on binutils on
Debian based systems.

regards,
guillem
>From dd9ba9a3243457b5b5b6545bbfaf5c5ac1578180 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Fri, 20 Nov 2009 19:51:44 +0100
Subject: [PATCH 1/2] Refactor deb extractors into two new functions

---
 functions   |   43 ++
 scripts/debian/potato   |6 +
 scripts/debian/sarge|6 +
 scripts/debian/sarge.buildd |6 +
 scripts/debian/sarge.fakechroot |6 +
 scripts/debian/sid  |6 +
 scripts/debian/woody|6 +
 scripts/debian/woody.buildd |6 +
 scripts/ubuntu/breezy   |6 +
 scripts/ubuntu/dapper   |6 +
 scripts/ubuntu/edgy |6 +
 scripts/ubuntu/feisty   |6 +
 scripts/ubuntu/gutsy|6 +
 scripts/ubuntu/hoary|6 +
 scripts/ubuntu/hoary.buildd |6 +
 scripts/ubuntu/warty|6 +
 scripts/ubuntu/warty.buildd |6 +
 17 files changed, 45 insertions(+), 94 deletions(-)

diff --git a/functions b/functions
index e832d70..66021e8 100644
--- a/functions
+++ b/functions
@@ -717,27 +717,42 @@ get_debs () {
 
  extraction
 
+extract_deb_field () {
+	local pkg="$1"
+	local field="$2"
+
+	ar -p "$pkg" control.tar.gz | zcat |
+	tar -O -xf - control ./control 2>/dev/null |
+	grep -i "^$field:" | sed -e 's/[^:]*: *//' | head -n 1
+}
+
+extract_deb_data () {
+	local pkg="$1"
+	local tarball=$(ar -t "$pkg" | grep "^data.tar.[bgx]z")
+
+	case "$tarball" in
+		data.tar.gz) cat_cmd=zcat ;;
+		data.tar.bz2) cat_cmd=bzcat ;;
+		data.tar.xz) cat_cmd=xzcat ;;
+		*) error 1 UNKNOWNDATACOMP "Unknown compression type for %s in %s" "$tarball" "$pkg" ;;
+	esac
+
+	if type $cat_cmd >/dev/null 2>&1; then
+		ar -p "$pkg" data.tar.gz | $cat_cmd | tar -xf -
+	else
+		error 1 UNPACKCMDUNVL "The $cat_cmd is not available on the system"
+	fi
+}
+
 extract () { (
 	cd "$TARGET"
-	local p=0 tarball cat_cmd
+	local p=0 cat_cmd
 	for pkg in $(debfor "$@"); do
 		p="$(($p + 1))"
 		progress "$p" "$#" EXTRACTPKGS "Extracting packages"
 		packagename="$(echo "$pkg" | sed 's,^.*/,,;s,_.*$,,')"
 		info EXTRACTING "Extracting %s..." "$packagename"
-		tarball=$(ar -t "./$pkg" | grep "^data.tar.[bgx]z")
-		case "$tarball" in
-			data.tar.gz) cat_cmd=zcat ;;
-			data.tar.bz2) cat_cmd=bzcat ;;
-			data.tar.xz) cat_cmd=xzcat ;;
-			*) error 1 UNKNOWNDATACOMP "Unknown compression type for %s in %s" "$tarball" "$pkg" ;;
-		esac
-
-		if type $cat_cmd >/dev/null 2>&1; then
-			ar -p "./$pkg" data.tar.gz | $cat_cmd | tar -xf -
-		else
-			error 1 UNPACKCMDUNVL "The $cat_cmd is not available on the system"
-		fi
+		extract_deb_data "./$pkg"
 	done
 ); }
 
diff --git a/scripts/debian/potato b/scripts/debian/potato
index 3204c7d..304cbe0 100644
--- a/scripts/debian/potato
+++ b/scripts/debian/potato
@@ -43,11 +43,7 @@ first_stage_install () {
 x_feign_install () {
 local pkg=$1
 local deb="$(debfor $pkg)"
-local ver="$(
-ar -p "$TARGET/$deb" control.tar.gz | zcat |
-tar -O -xf - control ./control 2>/dev/null |
-grep -i ^Version: | sed -e 's/[^:]*: *//' | head -n 1
-)"
+local ver="$(extract_deb_field "$TARGET/$deb" Version)"
 
 mkdir -p "$TARGET/var/lib/dpkg/info"
 
diff --git a/scripts/debian/sarge b/scripts/debian/sarge
index e49a490..252e180 100644
--- a/scripts/debian/sarge
+++ b/scripts/debian/sarge
@@ -111,11 +111,7 @@ first_stage_install () {
 x_feign_install () {
 local pkg="$1"
 local deb="$(debfor $pkg)"
-local ver="$(
-ar -p "$TARGET/$deb" control.tar.gz | zcat |
-tar -O -xf - control ./control 2>/dev/null |
-grep -i ^Version: | sed -e 's/[^:]*: *//' | head -n 1
-)"
+local ver="$(extract_deb_field "$TARGET/$deb" Version)"
 
 mkdir -p "$TARGET/var/li

Re: xz support in dpkg (was Re: dpkg plans for the squeeze cycle)

[Guillem Jover]

Hi!

On Tue, 2009-09-22 at 01:40:20 -0500, Jonathan Nieder wrote:
> LZMA decompressors can use large amounts of memory when processing
> archives built with a large dictionary size.  Running out of memory
> can have bad effects, so the decompressor takes an argument
> representing maximum memory usage and (1) does not even bother if it
> is obvious that limit will be exceeded and (2) aborts decompression
> if the limit was exceeded anyway.  What should that limit be for dpkg?
> 
> I asked the XZ Utils author for advice.  Here’s what he said:
> 
> > What you need to do:
> >
> > 1. Find out how much RAM it is OK to use for decompressing packages.
> >This may vary between architectures. I hope this would be at
> >least 10 MiB, but 20 MiB would be very nice.

I guess a better question is, how much benefit a bigger dictionary size
would give us?

> > 2. Make sure that all packages will be compressed with settings
> >that will keep the decompressor memory usage below this limit.

We can try to specify it, and codify it in the tools, but there's people
out there building packages with ar and tar... (this should not affect
Debian though).

> > 3. Enforce this limit in dpkg so that installing a third-party
> >package on a phone doesn't cause a nasty surprise of too high
> >memory usage.
> 
> The xz command (by default) refuses to use more than 40% of installed RAM
> when decompressing.  That’s not appropriate for dpkg, since dpkg should
> not refuse to unpack policy-compliant packages just because unpacking
> them would be uncomfortable.  The default dictionary size is 8 MiB.  If
> we were to standardize on that, a 10 MiB memory usage limit would be
> enough.
> 
> I am very uncomfortable picking a number here, since there are I don’t
> know well involved:
> 
>  a. debian-installer has tight memory constraints but needs to be able
> to do a debootstrap.  Is it reasonable to assume 10 MiB of memory
> will be available just to decompress a binary package when the time
> comes?
> 
> I think the answer should be yes, because the installer would have
> mounted swap by then.  Is this correct?  Any words of wisdom about
> memory constraints for unpacking .debs in the installer?  How much
> memory should we assume is available and use for this?
> 
> Related question: If an LZMA-based file format might ever be used
> for udebs, what are the memory constraints for unpacking those?

Well this is outside the scope of dpkg itself, and more a project wide
decision, but I'm not sure we'd want any package in the base system
built with anything but gzip, as that's shared by derivatives,
embedded distros, etc. xz should probably be used for big packages that
are guaranteed to be used on desktops or huge boxes (think games,
openoffice.org, etc).

>  b. Some users might build their own packages that are compressed with
> too large a dictionary size.  How should dpkg deal with these?
> 
> Usually, reporting the error and a suggested memlimit and providing
> a command-line option to increase the limit would be good enough,
> but what about when dpkg is invoked through a front-end?  Should
> there be an environment variable to set the memory limit, or do the
> front-ends all have easy-to-find facilities for passing extra options
> to dpkg?

This does not seem very nice. Is there no way to know how much memory
will we need from the file headers? If we could do that dynamically
that'd be great. Is there a maximum dictionary size?

OTOH if the package is out of spec we can do whatever we want, but I'd
rather make dpkg cope with such packages gracefully.

thanks,
guillem


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

Bug#465402: O: directfb -- direct frame buffer graphics

[Guillem Jover]

Package: wnpp
Severity: normal

Now that the library transition is over, and all major bugs should be
fixed, I've been able to finally orphan the directfb suite of packages.

It might make sense for whoever takes over, to adopt the whole suite
(directfb, dfb++ and fusionsound), they have been maintained in the
pkg-directfb alioth project, which I can hand over to the new
maintainer(s).

All patches have been sent and merged upstream, except for one, which
I'm taking care of. There's intructions in that patch header on how to
proceed for next upstream release.


The package description is:
 DirectFB is a graphics library which was designed with embedded systems
 in mind. It offers maximum hardware accelerated performance at a minimum
 of resource usage and overhead.


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.24.1-zulo (PREEMPT)
Locale: LANG=C, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: D-I Manual - String freeze / Call to update translations (deadline: Feb 10)

[Guillem Jover]

Hi,

On Mon, 2008-02-11 at 13:07:55 +0100, Frans Pop wrote:
> On Wednesday 06 February 2008, Frans Pop wrote:
> > On Saturday 02 February 2008, Frans Pop wrote:
> > > On Saturday 26 January 2008, Frans Pop wrote:
> > > > So, please update your translations before *Sunday February 10*.
> 
> Deadline ended yesterday.

Ugh, sorry, I think we mixed up the 10th and 14th deadlines, and
thought the latter was an extension for the former.

> Before I start the build for the manual, I would appreciate status updates 
> for the following two translations:
> - Catalan: work was started and some changes committed, but currently 8
>   files still need update.

> And 1 file untranslated.

We are only missing three files, they rest need review and commit, but
I fear I'll not be able to do that until later today.

> Please reply ASAP.

If you are in a hurry, just go ahead from our side, we'll catch up
later.

thanks and sorry for the delay,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: unknown-field-in-control homepage

[Guillem Jover]

On Thu, 2008-02-07 at 10:23:51 +0100, Raphael Hertzog wrote:
> Except it will only work if the package uses 'Package-Type' and not
> 'X*-Package-Type'.

X*B*-Package-Type should work as well.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: unknown-field-in-control homepage

[Guillem Jover]

Hi,

On Wed, 2008-02-06 at 20:23:37 +0100, Jonas Meurer wrote:
> On 06/02/2008 Russ Allbery wrote:
> > > I'm not sure whether this is an issue with dpkg or rather with lintian,
> > > but if I check the cryptsetup deb+udeb packages after building them,
> > > lintian reports that udebs don't allow the Homepage field in
> > > debian/control.
> > 
> > This is what I was told by (a d-i maintainer | someone who was willing to
> > express an opinion).  I'm happy to change lintian if having Homepage in
> > udeb is deemed acceptable.  Otherwise, dpkg should probably be modified to
> > not propagate Homepage fields into udebs.
> 
> I raised this issue on #debian-boot (irc), and was told that the
> concerns by "(a d-i maintainer | someone who was willing to express an
> opinion" were correct. Frans Pop from the debian-installer team verified
> that the Homepage field should not be included in the udeb:
> 
> 20:11 < mejo> fjp: did you see Russ's response to my question regarding
>   Homepage Field in udebs?
> 20:11 < mejo> fjp: i mean on [EMAIL PROTECTED]
> [...]
> 20:12 < fjp> mejo: Please file a bug against dpkg-dev.
> 20:14 < fjp> mejo: Russ is correct: we don't want the homepage field in
>  the control file of udebs
> 
> 
> If nobody has any objections, i'll follow Frans' advice and file a bug
> against dpkg-dev.

Yes, makes sense. I've just fixed it in dpkg's git [0].

regards,
guillem

[0] 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Please unblock directfb/1.0.1-6

[Guillem Jover]

Hi,

Please unblock directfb/1.0.1-6. The sparc binaries are still missing,
though.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Transition to directfb 1.0.1

[Guillem Jover]

[ CCed maintainers for delicate rev-depends ]

Hi,

Some weeks ago I uploaded directfb 1.0.1-2 to experimental. I've
successfully built the following packages, which are the only ones
really Build-Depending on libdirectfb-dev:

  In unstable
  ---
  directvnc_0.7.5-8
  freesci_0.3.5-5
  gst-plugins-bad0.10_0.10.5-4
  gtk+2.0_2.12.0-2
  libcairo_1.4.10-1
  libsdl1.2_1.2.12-1
  links2_2.1pre28-1
  mplayer (from svn)
  qingy_0.9.6-1
  xine-lib_1.1.8-1

  In experimental
  ---
  fusionsound_1.0.0-1
  dfb++_1.0.0-1

Packages with problems:

  splashy

  I've been in contact with the developers, and they should have a fix
  ready, which they could upload (if they have not done so yet) once
  the transition starts.

  asc

  It does not Build-Depend on directfb, but yet it has a Dependency,
  this is still an incarnation of #375924. Would need a binNMU as
  well, after libsdl1.2 has been binNMUed.

Packages Build-Depending on directfb, but not really using it:

  pigment
  gnash

  I'll be filing bug reports to these one. No action needed from d-r.


I'd like to upload to unstable once I've been given green light. The
transition should be able to be handled by me uploading the packages
from experimental to unstable, and triggering binNMUs.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#440320: Permission to provide a udeb for libaio

[Guillem Jover]

Hi,

On Wed, 2007-09-05 at 19:27:17 -0300, Otavio Salvador wrote:
> Joey Hess <[EMAIL PROTECTED]> writes:
> > Is that really true? If bin-nmus, which require finding and prodding one
> > of a small set of very busy people, are more maintenence cost than
> > managing one more udeb, we're doing something wrong.
> >
> > It certianly can be true if the library is used by lots of packages and
> > tends to be involved in complex testing transitions. (Agurably that's
> > because there's something wrong, like like too-tight library deps that
> > cause such transitions.) I don't see any reason why libaio1-udeb would
> > be harder to manage than other simple udebs though. The reverse
> > dependencies of libaio are very small.

> Guillem, the Joey's above comment[1] made clear that would be better to
> have the udeb then the effort of coordinating bin-nmu and like in case
> of an security update or so.

Right, and I agree.

> 1. Message-ID: <[EMAIL PROTECTED]> at debian-boot
> 
> So please add it on your next upload.

Cool, I've done that, the package should be now in the NEW queue.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Permission to provide a udeb for libaio

[Guillem Jover]

Hi,

I've been asked to provide a udeb for libaio (#440320), which is
needed by the multipath udeb package. So I'd like to ask if it's fine
to provide such udeb?

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#416911: New DirectFB 1.x releases are available

[Guillem Jover]

Hi,

On Sun, 2007-09-02 at 20:24:14 -0300, Otavio Salvador wrote:
> Davide Viti <[EMAIL PROTECTED]> writes:
> > On Sat, Sep 01, 2007 at 09:57:48PM +0200, Attilio Fiandrotti wrote:
> > > Recently DirectFB version 1.0.1 [1] and 1.1.0 [2] were released: i 
> > > suggest we switch to the most recent DFB version while we're still early 
> > > in Lenny release cycle.
> >
> > yes,
> > most libs  used for the g-i have been updated after Etch was released
> > and it'd be really nice if dfb could be updated as to use newer drivers
> > and bugfixes.

I'm not going to upload 1.1.0, as it can be read from the release
announcment that "not all features are working again". I might later
on upload it to experimental.

> Guillem just confirmated to me at IRC that it's going to be upload
> today to experimental and it'll need to sit on NEW.

As also mentioned on IRC I'd like to move the dfbinfo binary current
provided in the udeb lib into its own package (which didn't happen at
the time due to the release being so close). The new package
(libdirectfb-bin-udeb) would mostly contain that, but other programs
useful for debugging purposes can be added later on if requested.

So I'd like to ask the d-i team for permission to provide this new
udeb.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposal to remove gfxdrivers directory from libdirectfb udeb

[Guillem Jover]

Hi,

On Tue, 2006-09-26 at 15:21:51 +0200, Attilio Fiandrotti wrote:
> Yesterday i posted [1] on directfb-user to get help about crashes we 
> experience with PPC machines, and Claudio Ciccani suggested to remove 
> the gfxdrivers directory to disable device initialization by 
> chip-specific modules.

It would be nice to get that kind of problem as bug reports on the
directfb package as well.

> This not only should give us better reliability, but should also allow 
> us to save ~500KB in the ISO.
> Would it be possible removing the gfxdrivers directory from the udeb and 
> preserving it in the regular deb?

It's enterely possible if it's causing problems right now and if the
d-i team agree with that, but wouls be way better to be able to fix
those crashes instead (you may want to remove the graphic modules
anyway to save space on the udeb, though).

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Not very happy with new directfb upload

[Guillem Jover]

Hi,

On Mon, 2006-07-31 at 03:42:31 +0200, Frans Pop wrote:
> On Monday 31 July 2006 03:20, Steve Langasek wrote:
> > He did request approval for this transition on debian-release earlier
> > in the month, and there were no objections raised:
> > 
> 
> /me kicks himself for missing the implications of that mail (remembering 
> now that he did see it at the time)
> Guillem: my apologies for thinking you had done this without checking with 
> anyone.

No problem. Anyway I'm sorry for the delay, as I left for 4 days or so
and was expecting to have net access. Also I asked for the transition
taking into account d-i, but missed the fact that libcairo was used by
it, and thought that the whole g-i was using the old forked 0.9.22. This
raises the issue that the libcairo udeb probably should not be using the
latest one in sid (until g-i moves back to it), or g-i will end up
linking against two different directfb versions.

> > The binNMUs have all been scheduled now, but the biggest problem looks
> > like it will be that this version of directfb has FTBFS on powerpc. 
> > Guillem, do you know about this?

> Yes, just noticed that too. Hope this can be resolved soon as that will 
> block progress on the d-i release.

Yes I noticed that just before leaving and was expecting to sort it
out sooner. I also told that to Steve on #debian-release on the 27th.
I've uploaded now fixed packages with medium urgency.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New directfb 0.9.24-1 with soname bumped

[Guillem Jover]

On Mon, Apr 10, 2006 at 01:57:23PM +0200, Frans Pop wrote:
> On Monday 10 April 2006 06:14, Guillem Jover wrote:
> > Sure, feel free to upload and change the maintainer if it does not
> > bother you (the udeb bug can be closed with your upload).
> 
> OK. I have prepared the packages and am ready to upload. However, I think 
> you will have to upload first as otherwise I would hijack the udeb and 
> lib (their names are unchanged from current package) which would probably 
> not be allowed.
> So please go ahead with that and I'll upload once your new version is in.

Just uploaded them. They will appear in incoming RSN.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New directfb 0.9.24-1 with soname bumped

[Guillem Jover]

On Mon, Apr 10, 2006 at 12:56:36AM +0200, Frans Pop wrote:
> On Saturday 08 April 2006 19:11, Guillem Jover wrote:
> > I'll be uploading the new directfb after 2006-04-09 dinstall run.
> > As libsysfs2 has migrated to testing already, there should be no
> > problem related to this. In regard to dependent packages, Frans
> > reported that gtk+2.0-directfb does not build anymore, if you think
> > you need more time to fix this, I can delay the upload.

> So our proposal is to rename current directfb to directfb-0.9-22, make 
> those packages that conflict with new directfb and have both in the 
> archive until we can make the transition to all new libraries.

I've talked with Frans on IRC and this seems the most sensible way,
even it it implies duping the package for now...

> I've prepared a patch (attached) that creates directfb-0.9-22 packages. As 
> I expect they will only be used by d-i, will not need maintenance and 
> will never reach stable, I have set d-boot as maintainer (unless Guillem 
> prefers to have them in his name of course).
> 
> Comments on this suggestion and the patch welcome.

Sure, feel free to upload and change the maintainer if it does not
bother you (the udeb bug can be closed with your upload).

I'll be uploading new directfb packages today before dinstall run if
it's fine with you guys.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New directfb 0.9.24-1 with soname bumped

[Guillem Jover]

Hi again,

On Mon, Apr 03, 2006 at 04:33:15AM +0300, Guillem Jover wrote:
> directfb 0.9.24-1 is now in experimental. Please test it and report any
> problems. I will not move it to unstable for at least a week (plus the
> time RMs may need due to other transitions, etc). I'll send another mail
> just 2 days before uploading.

I'll be uploading the new directfb after 2006-04-09 dinstall run.
As libsysfs2 has migrated to testing already, there should be no
problem related to this. In regard to dependent packages, Frans
reported that gtk+2.0-directfb does not build anymore, if you think
you need more time to fix this, I can delay the upload.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

New directfb 0.9.24-1 with soname bumped

[Guillem Jover]

Hi,

directfb 0.9.24-1 is now in experimental. Please test it and report any
problems. I will not move it to unstable for at least a week (plus the
time RMs may need due to other transitions, etc). I'll send another mail
just 2 days before uploading.

For the RMs, when would it be fine with you to move directfb from
experimental to sid? The following lists what's required for this
small "transition".

Packages build-depending on an unversioned directfb (only binNMU
required, which I have successfully built with the new directfb):

  Maintainer: Debian Install System Team 
  Package: libcairo-directfb

  Maintainer: Yann Dirson <[EMAIL PROTECTED]>
  Package: gcompris

  Maintainer: Gürkan Sengün <[EMAIL PROTECTED]>
  Package: links2

  Maintainer: Mesa package maintainers
<[EMAIL PROTECTED]>
  Package: mesa

Packages build-depending on a versioned directfb (sourceful upload
required):

  Maintainer: Guillem Jover <[EMAIL PROTECTED]>
  Package: dfb++, fusionsound

  Maintainer: Ola Lundqvist <[EMAIL PROTECTED]>
  Package: directvnc

  Maintainer: Bas Zoetekouw <[EMAIL PROTECTED]>
  Package: freesci

  Maintainer: Debian Install System Team 
  Package: gtk+2.0-directfb

  Maintainer: Debian SDL packages maintainers
<[EMAIL PROTECTED]>
  Package: libsdl1.2

Packages build-depending on directfb, but not really using it:

  Maintainer: Martin Albert <[EMAIL PROTECTED]>
  Package: libggi

  Maintainer: Torsten Werner <[EMAIL PROTECTED]>
  Package: paintlib

I'll be filing bug reports about these last two ones.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [d-i manual] New Catalan translation

[Guillem Jover]

Hi Frans,

On Sun, Sep 05, 2004 at 12:56:06AM +0200, Frans Pop wrote:
> I have tested that your translation builds OK (and it does, after fixing one 
> small mistake in ca/welcome/about-copyright.xml).

Thanks!

> A mail with the results of a build will be send to the debian-l10n-catalan 
> list. A build is triggered automatically when you commit files to SVN.

Ok cool.

BTW the installer/doc/manual/translations.txt explains how to start a
new translation, but it tells to use cp instead if svn cp, I used the
later as it seemed more logical, and consumes less b/w and less space in
the repo (at least for now :), any reason to use cp and remove the .svn
dirs and svn add?

Would you like me to chnage that in the docu?

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ports-status page

[Guillem Jover]

Hi,

On Sun, Mar 09, 2003 at 12:19:48PM +, Alastair McKinstry wrote:
> I'm trying to track down what work is needed to get debian-installer
> working on the various ports, and to that end have created a page for
> tracking status:
>   http://people.debian.org/~mckinstry/ports-status.html

The login name of Michael Cardenas is mbc instead of mdc.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

autopartkit asprintf conversion

[Guillem Jover]

Hi,

Patch attached.

regards,
guillem

Index: autopartkit.c
===
RCS file: /cvs/debian-boot/debian-installer/tools/autopartkit/autopartkit.c,v
retrieving revision 1.27
diff -u -r1.27 autopartkit.c
--- autopartkit.c   16 Dec 2002 09:11:41 -  1.27
+++ autopartkit.c   19 Dec 2002 18:55:32 -
@@ -768,11 +768,10 @@
 subdev  = minor(statbuf.st_rdev) / maxparts;
 partnum = minor(statbuf.st_rdev) % maxparts;
 
-retval = malloc(strlen(partpath) + 1); /* I hope this is long enough */
 if (0 == partnum)
-  sprintf(retval, devpath, 'a' + subdev);
+  asprintf(&retval, devpath, 'a' + subdev);
 else
-  sprintf(retval, partpath, 'a' + subdev, partnum);
+  asprintf(&retval, partpath, 'a' + subdev, partnum);
 
 return retval;
 }
@@ -789,10 +788,7 @@
 char *retval;
 char *tmp;
 
-/* devlen + numbers + null termination */
-retval = malloc(strlen(dev->path) + 3);
-
-sprintf(retval,"%s%d",dev->path, freepart->num);
+asprintf(&retval, "%s%d", dev->path, freepart->num);
 /* Replace 'disc' with 'part'.  Sucks. */
 if ((tmp = strstr(retval, "disc")))
 {
@@ -900,10 +896,7 @@
fprintf(fstab, "%s\t%s\t%s\tdefaults\t\t0\t%d\n", 
devpath, mountmap[i].mountpoint->mountpoint,
mountmap[i].mountpoint->fstype, fsckpass);
-   tmpmnt = malloc(/* /target */ 7 + 
-   strlen(mountmap[i].mountpoint->mountpoint) + 1 
-   /* terminating null */);
-   sprintf(tmpmnt, "/target%s",mountmap[i].mountpoint->mountpoint);
+   asprintf(&tmpmnt, "/target%s", mountmap[i].mountpoint->mountpoint);
mkdir(tmpmnt, 0755);
mount(mountmap[i].devpath, tmpmnt, mountmap[i].mountpoint->fstype,
  MS_MGC_VAL, NULL);

net-retriever ftp support

[Guillem Jover]

Hi,

Sorry for the delay, here it's the patch.

regards,
guillem

Index: net-retriever.c
===
RCS file: /cvs/debian-boot/debian-installer/retriever/net/net-retriever.c,v
retrieving revision 1.3
diff -u -r1.3 net-retriever.c
--- net-retriever.c 12 Nov 2002 22:53:48 -  1.3
+++ net-retriever.c 19 Dec 2002 03:52:11 -
@@ -8,37 +8,62 @@
 #include 
 #include 
 
-/* Base of the debconf question hierary used by this program. */
+/* Base of the debconf question hierarchy used by this program. */
 #define DEBCONF_BASE "mirror/"
 
+/*
+ * Get a protocol question value from the debconf mirror hierarchy.
+ * Returns the result in the value field of debconfclient.
+ */
+void get_mirror_protocol_value(struct debconfclient *debconf, char *protocol,
+  char *string)
+{
+   char *question;
+
+   asprintf(&question, DEBCONF_BASE "%s/%s", protocol, string);
+   debconf->command(debconf, "GET", question, NULL);
+   free(question);
+}
+
 int main(int argc, char **argv) {
int ret;
char *src;
char *hostname, *directory, *command;
struct debconfclient *debconf = debconfclient_new();
-   
+
if (argc < 2)
exit(1);
if (strcmp(argv[1], "retrieve") == 0) {
+   char *protocol;
+
if (argc < 4)
exit(1);
+
+   debconf->command(debconf, "GET", DEBCONF_BASE "protocol", NULL);
+   protocol = strdup(debconf->value);
+
/* Suck in data from the debconf database, which will be primed
 * with the mirror to use by choose-mirror */
-   // TODO: what about ftp?
-   debconf->command(debconf, "GET", DEBCONF_BASE "http/hostname", NULL);
+   get_mirror_protocol_value(debconf, protocol, "hostname");
hostname = strdup(debconf->value);
-   debconf->command(debconf, "GET", DEBCONF_BASE "http/directory", NULL);
+
+   get_mirror_protocol_value(debconf, protocol, "directory");
directory = strdup(debconf->value);
-   debconf->command(debconf, "GET", DEBCONF_BASE "http/proxy", NULL);
+
+   get_mirror_protocol_value(debconf, protocol, "proxy");
if (debconf->value && strcmp(debconf->value,"") != 0) {
-   if (setenv("http_proxy", debconf->value, 1) == -1)
+   char *env_variable;
+
+   asprintf(&env_variable, "%s_proxy", protocol);
+   if (setenv(env_variable, debconf->value, 1) == -1)
exit(1);
+   free(env_variable);
}
-   src=argv[2];
-   asprintf(&command, "wget -c -q http://%s%s/%s -O %s", hostname,
-   directory, src, argv[3]);
-   fprintf(stderr,"wget: %s\n", command);
-   ret=system(command);
+   src = argv[2];
+   asprintf(&command, "wget -c -q %s://%s%s/%s -O %s", protocol,
+hostname, directory, src, argv[3]);
+   fprintf(stderr, "wget: %s\n", command);
+   ret = system(command);
if (ret == 256)
return 1;
return ret;
@@ -47,3 +72,4 @@
return 1;
}
 }
+

Re: file-retriever

[Guillem Jover]

On Mon, Dec 16, 2002 at 12:33:53AM +0100, Martin Sjögren wrote:
> Thanks for the enthusiasm, both of you. :)

:>

> But I'm pretty sure that file-retriever won't be used as it is, it's
> more of an example of retrievers. The concrete retrievers so far are
> net-retriever, floppy-retriever and cdrom-retriever... Arbitrarily
> symlinking into a 'debs' directory (relative to what? the root of the
> ramdisk? huh?) seems a bit silly.

Yes that was explained in the TODO. I'm working on ftp support in
net-retriever... patch soon.

> Furthermore, it doesn't support the retriever protocol at all, so it's
> kind of useless in that respect! ;)

Mine supports it. :P

> If you want to actively contribute to d-i, I suggest you join
> #debian-boot on OPN, that's where most of the up-to-date discussion
> takes place, the documentation shouldn't really be trusted fully.

Ok, will do.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: file-retriever

[Guillem Jover]

Hi,

On Wed, Dec 11, 2002 at 01:01:39AM +0100, David Weinehall wrote:
> Here is an implementation of file-retriever in C, since its TODO file
> expressed an interest in having one.

Oops, I did this also but forgot to send, patch attached.

What amount of error checking code should be done?
Can we use GNU extension functions as most src is using _GNU_SOURCE anyway?
Is any interest in rewriting all other retrievers in C?

regards,
guillem

diff -Naur file/debian/control file-patched/debian/control
--- file/debian/control 2002-05-09 12:39:15.0 +0200
+++ file-patched/debian/control 2002-12-11 05:02:46.0 +0100
@@ -6,7 +6,7 @@
 Standards-Version: 3.5.2.0
 
 Package: file-retriever
-Architecture: all
+Architecture: any
 Depends: ${shlibs:Depends}
 Provides: retriever
 Description: File retriever
diff -Naur file/debian/rules file-patched/debian/rules
--- file/debian/rules   2000-12-13 05:59:59.0 +0100
+++ file-patched/debian/rules   2002-12-11 05:01:07.0 +0100
@@ -10,19 +10,21 @@
 
 PACKAGE=$(shell dh_listpackages)
 VERSION=$(shell dpkg-parsechangelog | grep ^Version: | cut -d ' ' -f 2)
-ARCH=all
+ARCH=$(shell dpkg --print-architecture)
 FILENAME=$(PACKAGE)_$(VERSION)_$(ARCH).udeb
 PRIORITY=$(shell grep ^Priority: debian/control | cut -d ' ' -f 2)
 
 build: build-stamp
 build-stamp:
dh_testdir
+   $(MAKE) small
touch build-stamp
 
 clean:
dh_testdir
dh_testroot
rm -f build-stamp
+   $(MAKE) clean
dh_clean
 
 install: build
@@ -33,14 +35,14 @@
install file-retriever \
debian/file-retriever/usr/lib/debian-installer/retriever/file-retriever
 
-# Build architecture-dependent files here.
-binary-arch: build install
+# Build architecture-independent files here.
+binary-indep: build install
 # We have nothing to do by default.
 
-# Build architecture-independent files here.
+# Build architecture-dependent files here.
 #
 # Note that this builds a .udeb, which is not policy compliant or anything.
-binary-indep: build install
+binary-arch: build install
dh_testdir
dh_testroot
dh_installdebconf
diff -Naur file/file-retriever file-patched/file-retriever
--- file/file-retriever 2002-12-11 05:21:17.0 +0100
+++ file-patched/file-retriever 1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-#!/bin/sh -e
-ln -sf `pwd`/debs/$1 $2
diff -Naur file/file-retriever.c file-patched/file-retriever.c
--- file/file-retriever.c   1970-01-01 01:00:00.0 +0100
+++ file-patched/file-retriever.c   2002-12-02 06:40:00.0 +0100
@@ -0,0 +1,52 @@
+/*
+ * file-retriever
+ *
+ * Copyright (C) 2002 Guillem Jover <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+int main(int argc, char **argv)
+{
+   if (argc < 2)
+   return 1;
+
+   if (strcmp(argv[1], "retrieve") == 0) {
+   char *oldpath, *newpath, *pwd;
+
+   if (argc < 4)
+   return 1;
+
+   pwd = get_current_dir_name();
+   if (pwd == NULL)
+   return errno;
+
+   asprintf(&oldpath, "%s/debs/%s", pwd, argv[2]);
+   newpath = argv[3];
+   unlink(newpath);
+   symlink(oldpath, newpath);
+   } else {
+   return 1;
+   }
+
+   return 0;
+}
+
diff -Naur file/Makefile file-patched/Makefile
--- file/Makefile   1970-01-01 01:00:00.0 +0100
+++ file-patched/Makefile   2002-12-11 04:57:52.0 +0100
@@ -0,0 +1,25 @@
+# Makefile based on net-retriever's
+
+ARCH=$(shell dpkg --print-architecture)
+CFLAGS=-Wall -g -D_GNU_SOURCE -DARCH=\"$(ARCH)\"
+OBJS=$(subst .c,.o,$(wildcard *.c))
+BIN=file-retriever
+LIBS=
+
+ifdef DEBUG
+CFLAGS:=$(CFLAGS) -DDODEBUG
+endif
+
+all: $(BIN)
+
+$(BIN): $(OBJS)
+   $(CC) -o $(BIN) $(OBJS) $(LIBS)
+
+# Size optimized and stripped binary target.
+small: CFLAGS:=-Os $(CFLAGS) -DSMALL
+small: clean $(BIN)
+   strip --remove-section=.comment --remove-section=.note $(BIN)
+   ls -l $(BIN)
+
+clean:
+   -rm -f $(BIN) $(OBJS) *~

Re: Cross-Installation for Target Machines

[Guillem Jover]

Hi,

On Sun, Sep 29, 2002 at 04:23:33PM +0900, Junichi Uekawa wrote:
> However, if debootstrap creates the chroot by
> extracting the debs only, possibly running the "sid" script to
> only up to "x_feign_install dpkg", and 
> possibly hacking a /sbin/init that has:
> #!/bin/sh
> exec /post-install.sh

maybe the dpkg script used by the Hurd to cross install from a Linux
system could be a good start:



regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: templates cleaning

[Guillem Jover]

On Mon, Aug 19, 2002 at 10:22:00AM +0200, Denis Barbier wrote:
> The question is not whether it is wrong or not; the English text in
> localized templates files *must* be the text on which translation is
> based.

I meant wrong in the sense of doing the change. But anyway thanks for
the correction.

guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: templates cleaning

[Guillem Jover]

On Mon, Aug 19, 2002 at 10:05:14AM +0200, Denis Barbier wrote:
> On Mon, Aug 19, 2002 at 10:00:52AM +0200, Guillem Jover wrote:
> [...]
> > Index: ddetect/debian/templates/ethdetect.templates.nl
> > ===
> > RCS file: 
>/cvs/debian-boot/debian-installer/tools/ddetect/debian/templates/ethdetect.templates.nl,v
> > retrieving revision 1.1
> > diff -u -r1.1 ethdetect.templates.nl
> > --- ddetect/debian/templates/ethdetect.templates.nl 29 Jan 2002 08:00:08 - 
> 1.1
> > +++ ddetect/debian/templates/ethdetect.templates.nl 19 Aug 2002 07:54:55 -
> > @@ -1,6 +1,6 @@
> >  Template: ethdetect/detection_type
> >  Type: select
> > -Choices: passive, none
> > +Choices: passive, full, none
> >  Choices-nl: passief, geen
> [...]
> 
> No!
> Unless you know what you are doing, you must not change English text
> in localized templates files.

Oops, sorry, it seemed wrong but i was misguided by ethdetect.templates

guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

templates cleaning

[Guillem Jover]

Hi,

Can someone delete tools/ddetect/debian/{d,eth}detect.templates
and apply the attached patch, thanks.

regards,
guillem


Index: ddetect/debian/rules
===
RCS file: /cvs/debian-boot/debian-installer/tools/ddetect/debian/rules,v
retrieving revision 1.6
diff -u -r1.6 rules
--- ddetect/debian/rules6 Aug 2002 15:28:49 -   1.6
+++ ddetect/debian/rules19 Aug 2002 07:54:54 -
@@ -32,6 +32,8 @@
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
+   $(foreach PACKAGE, $(PACKAGES), \
+   ( rm -f debian/$$PACKAGE.templates) ; )
 
-$(MAKE) clean
rm -f debian/ethdetect.postinst
@@ -42,7 +44,7 @@
dh_testroot
dh_clean -k
dh_installdirs
-   $(foreach PACKAGE,  $(PACKAGES), \
+   $(foreach PACKAGE, $(PACKAGES), \
( $(MAKE) install PROGS=$(PACKAGE) DESTDIR=`pwd`/debian/$(PACKAGE)) ; )
 
 
@@ -54,6 +56,15 @@
 binary-arch: build install
dh_testdir
dh_testroot
+   
+   $(foreach PACKAGE, $(PACKAGES), \
+   ( TEMPLATES=""; \
+   for TEMPLATE_LL in debian/template/$$PACKAGE.templates.* ; do \
+   TEMPLATES="$$TEMPLATES $$TEMPLATE_LL" ; \
+   done ; \
+   echo "Creating $$PACKAGE.templates -- $$TEMPLATES "; \
+   debconf-mergetemplate $$TEMPLATES > debian/$$PACKAGE.templates ); )
+
dh_installdebconf
$(foreach PACKAGE, $(PACKAGES), \
(cp debian/$(PACKAGE).menutest debian/$(PACKAGE)/DEBIAN/menutest ) ; )
Index: ddetect/debian/templates/ethdetect.templates.da
===
RCS file: 
/cvs/debian-boot/debian-installer/tools/ddetect/debian/templates/ethdetect.templates.da,v
retrieving revision 1.1
diff -u -r1.1 ethdetect.templates.da
--- ddetect/debian/templates/ethdetect.templates.da 8 Feb 2002 14:57:22 -  
 1.1
+++ ddetect/debian/templates/ethdetect.templates.da 19 Aug 2002 07:54:55 -
@@ -2,7 +2,7 @@
 Type: select
 Choices: passive, full, none
 Choices-da: passiv, fuld, ingen
-Default:  passive
+Default: passive
 Default-da: passiv
 Description: What level of hardware detection would you like?
  I can automatically detect some hardware.  If you want me to try to detect
Index: ddetect/debian/templates/ethdetect.templates.en
===
RCS file: 
/cvs/debian-boot/debian-installer/tools/ddetect/debian/templates/ethdetect.templates.en,v
retrieving revision 1.1
diff -u -r1.1 ethdetect.templates.en
--- ddetect/debian/templates/ethdetect.templates.en 29 Jan 2002 08:00:08 - 
 1.1
+++ ddetect/debian/templates/ethdetect.templates.en 19 Aug 2002 07:54:55 -
@@ -1,7 +1,7 @@
 Template: ethdetect/detection_type
 Type: select
 Choices: passive, full, none
-Default:  passive
+Default: passive
 Description: What level of hardware detection would you like?
  I can automatically detect some hardware.  If you want me to try to detect
  your hardware you can choose between full and passive detection.  Full
@@ -17,19 +17,11 @@
  This is a list of modules that I know about.  Choose the module from the list
  that supports your card.  If your card requires a different module, choose
  'other' and you will be prompted for the location of that module.  
-Description-de: Welche Module benötigt Ihre Netzwerkkarte?
- Dies ist die Liste alle verfügbare Module. Wählen Sie das zu
- Ihrer Netzwerkkarte passende Modul aus. Wenn es nicht in der
- Liste aufgeführt ist wählen Sie 'andere'. Sie können dann den
- Pfad zum laden Moduls angeben.
 
 Template: ethdetect/module_prompt
 Type: string
 Description: Where is the module for your ethernet card?
  Please enter the full path to the module for your ethernet card.
-Description-de: Wo ist das Modul für die Netzwerkkarte gespeichert?
- Bitte geben Sie den vollständigen Pfad zum Modul für die
- Netzwerkkarte an.
 
 Template: ethdetect/module_params
 Type: string
@@ -38,11 +30,6 @@
  parameters are often I/O port and IRQ numbers that vary from machine to
  machine and cannot be determined from the hardware. An example string looks 
  something like "IRQ=7 IO=0x220"
-Description-de: Bitte geben Sie zusätzliche Parameter an.
- Manche Module akzeptieren die Angabe zusätzlicher Startparameter,
- wie z.B. die I/O-Adresse oder den IRQ. Diese Angaben sind von
- Rechner zu Rechner unterschiedlich. Eine Parameterangabe kann
- zum Beispiel so aussehen: "IRQ=7 IO=0x220".
 
 Template: ethdetect/load_module
 Type: boolean
@@ -55,8 +42,6 @@
 Type: note
 Description: An error occured.
  Something went wrong. 
-Description-de: Ein Fehler ist aufgetreten.
- Ein Fehler ist aufgetreten.
 
 Template: ethdetect/nothing_detected
 Type: note
Index: ddetect/debian/templates/ethdetect.templates.nl
===
RCS file: 
/cvs/debian-boot/debian-installer/tools/ddetect/debian/templa