|
Home > Archive > Debian Developers > August 2005 > More pbuilder use!
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
More pbuilder use!
|
|
| Nathanael Nerode 2005-08-23, 2:49 am |
| Sven Luther wrote:
> All packages should be built by official debian buildds anyway, not on
> developper machines with random cruft and unsecure packages installed, or
even
> possibly experimental or home-modified stuff.
Actually, it's better yet if the packages are built on developer machines
inside a clean pbuilder chroot.
Rather than relying on the buildds, run your own better-than-buildd. ;-)
Nobody should be uploading packages built outside a chroot.
--
Nathanael Nerode <neroden@twcny.rr.com>
[Insert famous quote here]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joe Smith 2005-08-23, 2:49 am |
| Actually perhaps software should be built outside of clean chroots. Why?
Because if there is a possibility that a dirty chroot will cause the package
to fail, there is a bug in some peice of software. It could prevent a user
from recompiling on his own system, which thusly defeats the point of having
the source in the first place.
If a package Fails To Build From Source on a end-user system it is an RC
bug. By bug definitions i would say a minimum of 'serious', but 'critical'
would be better. Why? Simple: If users can make the changes they want, than
Debian is NOT free. If it is not free, it has failed.
--
If Debian is not free, it has failed. - Joe Smith
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roberto C. Sanchez 2005-08-23, 2:49 am |
| On Tue, Aug 23, 2005 at 12:40:18AM -0400, Joe Smith wrote:
> Actually perhaps software should be built outside of clean chroots. Why?
> Because if there is a possibility that a dirty chroot will cause the package to
> fail, there is a bug in some peice of software. It could prevent a user from
> recompiling on his own system, which thusly defeats the point of having the
> source in the first place.
> If a package Fails To Build From Source on a end-user system it is an RC bug.
> By bug definitions i would say a minimum of 'serious', but 'critical' would be
> better. Why? Simple: If users can make the changes they want, than Debianis
> NOT free. If it is not free, it has failed.
So, if I try to compile a random package with icc and it fails, that is
RC? That doesn't really make sense. At some point you need to draw the
line. I think the clean-chroot build policy should be maintained. If
users discover that a package does not build with some strange or
non-standard combination of packages, then they are free to submit
patches. However, the existence of such problems should not be
considered RC since Debian is a binary distro.
Think about it. I could have maintained gcc-2.95 on my system becuase I
like it (or need it/whatever). If tried to build some of the bleeding
edge packages with it, it will likely fail. That does not make it RC
since Debian doesn't even ship 2.95 anymore as the default.
-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~roberto
| |
| Olaf van der Spek 2005-08-23, 2:49 am |
| On 8/23/05, Joe Smith <unknown_kev_cat@hotmail.com> wrote:
> Actually perhaps software should be built outside of clean chroots. Why?
Did someone suggest to disallow that?
Why can't you do both?
| |
| John Hasler 2005-08-23, 5:58 pm |
| Joe Smith writes:
> Actually perhaps software should be built outside of clean chroots. Why?
> Because if there is a possibility that a dirty chroot will cause the
> package to fail, there is a bug in some peice of software.
The probability that the developer has the particular package that will
cause the build to fail installed is small, so the bug will most likely
manifest itself on a user's system anyway. To find these bugs you need to
get your package built on a variety of "real world" installations. Perhaps
users of Unstable should be encouraged to build packages locally whenever
convenient.
--
John Hasler
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Humberto Massa Guimarăes 2005-08-23, 5:58 pm |
| ** Joe Smith ::
> Actually perhaps software should be built outside of clean chroots. Why?
> Because if there is a possibility that a dirty chroot will cause the package
> to fail, there is a bug in some peice of software. It could prevent a user
> from recompiling on his own system, which thusly defeats the point of having
> the source in the first place. If a package Fails To Build From Source on a
> end-user system it is an RC bug. By bug definitions i would say a minimum of
> 'serious', but 'critical' would be better. Why? Simple: If users can make the
> changes they want, than Debian is NOT free. If it is not free, it has failed.
I vehemently disagree. I think exactly the opposite: debbuild and/or
dpkg-buildpackage should *always* build a package inside a clean and
minimal chroot jail. This way, (1) every package will predictably
build from (unchanged) source and (2) every variation that the user
*wants* in his package becomes documented in the debian/* files.
--
HTH,
Massa
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bastian Blank 2005-08-23, 5:58 pm |
| On Tue, Aug 23, 2005 at 12:40:18AM -0400, Joe Smith wrote:
> Actually perhaps software should be built outside of clean chroots. Why?
Do I need to have root on the debian developer machines? I currently use
that machines to build packages for architectures I don't own.
Bastian
--
The best diplomat I know is a fully activated phaser bank.
-- Scotty
| |
| Bastian Blank 2005-08-23, 5:58 pm |
| On Tue, Aug 23, 2005 at 12:06:41PM -0300, Humberto Massa GuimarĂ£es wrote:
> I vehemently disagree. I think exactly the opposite: debbuild and/or
> dpkg-buildpackage should *always* build a package inside a clean and
> minimal chroot jail. This way, (1) every package will predictably
> build from (unchanged) source and (2) every variation that the user
> *wants* in his package becomes documented in the debian/* files.
You have a linux kernel ready, which allows chroot as normal user?
Please share it with us.
Bastian
--
I've already got a female to worry about. Her name is the Enterprise.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0
| |
| Piotr Roszatycki 2005-08-23, 5:58 pm |
| On Tuesday 23 of August 2005 17:28, Bastian Blank wrote:
> On Tue, Aug 23, 2005 at 12:06:41PM -0300, Humberto Massa Guimar=E3es wrot=
e:
>
> You have a linux kernel ready, which allows chroot as normal user?
> Please share it with us.
Use fakechroot. Yes, it is ugly hack, but it allows me to recompile the=20
packages without root privileges.
=2D-=20
.''`. Piotr Roszatycki, Netia SA
: :' : mailto:Piotr_Roszatycki@netia.net.pl
`. `' mailto:dexter@debian.org
`-
| |
| Roger Leigh 2005-08-23, 5:58 pm |
| On Tue, Aug 23, 2005 at 05:28:22PM +0200, Bastian Blank wrote:
> On Tue, Aug 23, 2005 at 12:06:41PM -0300, Humberto Massa Guimarăes wrote:
>
> You have a linux kernel ready, which allows chroot as normal user?
> Please share it with us.
Not a kernel feature, but see
http://packages.debian.org/unstable/admin/schroot
(or check out
http://cvs.alioth.debian.org/cgi-bi...ot=buildd-tools)
I have patches to make sbuild use schroot for building.
http://lists.alioth.debian.org/pipe...uly/000063.html
I have been using sbuild to build all my packages for upload for several
months now. It certainly does avoid "brown paper bag" uploads, and I
definitely think it significantly improves the quality of my packaging
work due to catching other bugs (additional/missing packages installed
on the host system intefering with the build).
Future plans include
- LVM snapshot support (easy)
- Xen support (also using LVM snapshots) (harder--you can't just open
a shell, AFAICS)
which will mean sbuild (and hence buildd) can start with a clean
environment for each build, and at the end, you just throw away the
snapshot.
Regards,
Roger
--
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Humberto Massa GuimarĂ£es 2005-08-23, 5:58 pm |
| ** Bastian Blank ::
> You have a linux kernel ready, which allows chroot as normal user?
> Please share it with us.
It's called QEMU :-)
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Wouter Verhelst 2005-08-23, 5:58 pm |
| On Tue, Aug 23, 2005 at 06:01:24PM +0200, Piotr Roszatycki wrote:
> On Tuesday 23 of August 2005 17:28, Bastian Blank wrote:
>
> Use fakechroot. Yes, it is ugly hack, but it allows me to recompile the
> packages without root privileges.
We all use fakeroot. The question was about the "chroot" system call
which fakeroot does (and can not) not fake.
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Wouter Verhelst 2005-08-23, 5:58 pm |
| On Tue, Aug 23, 2005 at 07:26:25PM +0200, Wouter Verhelst wrote:
> On Tue, Aug 23, 2005 at 06:01:24PM +0200, Piotr Roszatycki wrote:
^^^[vbcol=seagreen]
>
> We all use fakeroot. The question was about the "chroot" system call
^
> which fakeroot does (and can not) not fake.
Ugh. Sorry, need to be more careful next time.
But still.
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roger Leigh 2005-08-23, 5:58 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
"Joe Smith" <unknown_kev_cat@hotmail.com> writes:
> Actually perhaps software should be built outside of clean
> chroots. Why? Because if there is a possibility that a dirty chroot
> will cause the package to fail, there is a bug in some peice of
> software. It could prevent a user from recompiling on his own
> system, which thusly defeats the point of having the source in the
> first place.
This is incorrect. Since the chroot environment is a full Debian
installation in its own right, this is wrong.
At least for me with by sbuild/schroot setup, I have a set of chroots,
currently:
$ schroot --list
default
sarge
sid
stable
unstable
But you can't build with sbuild until you have a .dsc, which means you
first need to build /outside/ the chroot, and then queue it for
building once you have done a successful build on the host system.
Hence your concern is unjustified.
You could do the initial build in the chroot, but because it's a
minimal environment it's not geared for development, just building,
which makes it impractical (no editors, for example).
Bugs in a clean chroot build are generally build dependency issues,
and the same issues are also present on the host system, but are not
always detectable, particularly if configure picks enables some
feature at random because of some random package being present.
Uploading stuff not built in a chroot means the build is not
independently reproducible, and might be different to the autobuilt
version the other 10 architectures got. In this respect, i386 is kind
of a second-class arch WRT the package build quality. Autobuilding
all packages (whether or not we do source only uploads) would remove
this cause of hard-to-find bugs and random breakage.
> If users can make the changes they want, than Debian is NOT free.
I think you got that backwards ;-)
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFDC24RVcFcaSW/ uEgRAqFJAKCMD3VD41IBQXhgKLlP3O14Nn26VgCf
Qf3m
BBDT/v97/gGgTQ7ZukAVOYU=
=bs/I
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bastian Blank 2005-08-23, 5:58 pm |
| On Tue, Aug 23, 2005 at 05:04:57PM +0100, Roger Leigh wrote:
> Not a kernel feature, but see
> http://packages.debian.org/unstable/admin/schroot
Does not help, each chroot needs to be setup by root and you need root
priviledges to install packages in it.
Bastian
--
Madness has no purpose. Or reason. But it may have a goal.
-- Spock, "The Alternative Factor", stardate 3088.7
| |
| Paul TBBle Hampson 2005-08-23, 5:58 pm |
| On Tue, Aug 23, 2005 at 01:52:22PM -0300, Humberto Massa Guimarăes wrote:
> ** Bastian Blank ::
> It's called QEMU :-)
Or pbuilder-uml, once someone gets onto the user-mode-linunx package
(and kernel-patch-uml) and brings them back into shape so that the
pbuilder-uml package can be re-enabled.
(Or at least, that's _my_ understanding of the situation...)
--
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Anu.edu.au
"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"
License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------
| |
| Roger Leigh 2005-08-23, 5:58 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bastian Blank <waldi@debian.org> writes:
> On Tue, Aug 23, 2005 at 05:04:57PM +0100, Roger Leigh wrote:
>
> Does not help, each chroot needs to be setup by root and you need root
> priviledges to install packages in it.
You can give root privs to users just inside the chroot. That's what
root_groups is for in the config file. The user doesn't need full
root access to the host system (like with plain sbuild, which requires
full sudo privs), though obviously it's still possible to subvert, but
not as simple as with sudo. Either way, not something for untrusted
users to have access to, but schroot does at least give you a bit more
safety.
Once it has Xen capability, it will give each user their own personal
Xen instance. This will be created on the fly from e.g. an LVM
snapshot or unionfs, but this can be configurable.
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFDC4NYVcFcaSW/uEgRAnSAAKCKdscIjxyrTl3cOVOEPX/BdI7GlACgg5xo
pYpCULVsUC42xO0rOqcYmA0=
=ObRb
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-08-23, 5:58 pm |
| Nathanael Nerode <neroden@twcny.rr.com> writes:
> Sven Luther wrote:
> even
>
> Actually, it's better yet if the packages are built on developer machines
> inside a clean pbuilder chroot.
>
> Rather than relying on the buildds, run your own better-than-buildd. ;-)
> Nobody should be uploading packages built outside a chroot.
And yet so many many DDs do.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-08-23, 5:58 pm |
| "Roberto C. Sanchez" <roberto@familiasanchez.net> writes:
> On Tue, Aug 23, 2005 at 12:40:18AM -0400, Joe Smith wrote:
>
> So, if I try to compile a random package with icc and it fails, that is
How would it build with icc? icc is neither gcc nor cc. You have to
use clean build scripts with a clean environment. I always suggest
debuild since that cleans up automaticaly before calling
dpkg-buildpackage.
If you replace build-essential apckages with something custom and that
breaks the source that is then obviously your problem. Worth reporting
in case of icc but not with normal FTBFS priority.
> RC? That doesn't really make sense. At some point you need to draw the
> line. I think the clean-chroot build policy should be maintained. If
> users discover that a package does not build with some strange or
> non-standard combination of packages, then they are free to submit
> patches. However, the existence of such problems should not be
> considered RC since Debian is a binary distro.
Build-Depends (and imho that includes Build-Conflicts) were a RC
criterium for sarge and no doubt will be again for etch. Any failure
to build on a system with only debian packages installed is imho a
FTBFS bug with the severity layed out for FTBFS (i.e. RC if it did
build before).
> Think about it. I could have maintained gcc-2.95 on my system becuase I
> like it (or need it/whatever). If tried to build some of the bleeding
> edge packages with it, it will likely fail. That does not make it RC
> since Debian doesn't even ship 2.95 anymore as the default.
No it won't fail. You are required to have a current sid
build-essential package installed which will upgrade gcc and pull in
gcc-4.0. That implicit Build-Depends you have to have. If not then you
are right, it isn't a bug in the package but in the user.
Any installed gcc-2.95 would not be used by the build with a current
build-essential unless it is a bug.
> -Roberto
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-08-23, 5:58 pm |
| Roger Leigh <rleigh@whinlatter.ukfsn.org> writes:
> "Joe Smith" <unknown_kev_cat@hotmail.com> writes:
>
>
> This is incorrect. Since the chroot environment is a full Debian
> installation in its own right, this is wrong.
>
> At least for me with by sbuild/schroot setup, I have a set of chroots,
> currently:
>
> $ schroot --list
> default
> sarge
> sid
> stable
> unstable
>
> But you can't build with sbuild until you have a .dsc, which means you
> first need to build /outside/ the chroot, and then queue it for
> building once you have done a successful build on the host system.
> Hence your concern is unjustified.
debuild -S; sbuild
You can circumvent it easy enough if you try.
I often do "debuild -us -uc -nc" outside the chroot till i get the
package to build and then build just source and dump it into the local
buildd to confirm a full, clean build works too.
> You could do the initial build in the chroot, but because it's a
> minimal environment it's not geared for development, just building,
> which makes it impractical (no editors, for example).
xemacs /mnt/chroot/home/mrvn/pkg/foo.c
Not realy a problem.
> Bugs in a clean chroot build are generally build dependency issues,
> and the same issues are also present on the host system, but are not
> always detectable, particularly if configure picks enables some
> feature at random because of some random package being present.
> Uploading stuff not built in a chroot means the build is not
> independently reproducible, and might be different to the autobuilt
> version the other 10 architectures got. In this respect, i386 is kind
> of a second-class arch WRT the package build quality. Autobuilding
> all packages (whether or not we do source only uploads) would remove
> this cause of hard-to-find bugs and random breakage.
Agreed. I fully support you there.
>
> I think you got that backwards ;-)
>
>
> Regards,
> Roger
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-08-23, 5:58 pm |
| Bastian Blank <waldi@debian.org> writes:
> On Tue, Aug 23, 2005 at 05:04:57PM +0100, Roger Leigh wrote:
>
> Does not help, each chroot needs to be setup by root and you need root
> priviledges to install packages in it.
>
> Bastian
The fakechroot description says it is good enough to bootstrap. So
that is not a problem.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roger Leigh 2005-08-23, 5:58 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
> Roger Leigh <rleigh@whinlatter.ukfsn.org> writes:
> I often do "debuild -us -uc -nc" outside the chroot till i get the
> package to build and then build just source and dump it into the local
> buildd to confirm a full, clean build works too.
I do this also.
>
> xemacs /mnt/chroot/home/mrvn/pkg/foo.c
>
> Not realy a problem.
Sure, editors were just one thing. The point I failed to make was
that for a dedicated sbuild chroot, you won't have the build-deps
installed anyway, so without a lot of manual messing you won't be able
to build in the chroot until you have a properly built package to feed
to sbuild, which will then install and purge the deps for you. The
chroot is not really suitable for anything but exclusive use by sbuild
(otherwise you risk messing it up by installing random stuff so that
it's no better than the host environment...).
You could always use a separate chroot for user access, but I don't
personally have the need (nor the free disk space).
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFDC5ExVcFcaSW/ uEgRAo73AJ9ZRarGSvmkYkNUXQPjM3CPCBXlPACc
DVra
4u4ILxgtcuASU3yR4a7xSXE=
=eDfR
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-08-24, 8:54 pm |
| Roger Leigh <rleigh@whinlatter.ukfsn.org> writes:
> The chroot is not really suitable for anything but exclusive use by
> sbuild (otherwise you risk messing it up by installing random stuff
> so that it's no better than the host environment...).
>
> You could always use a separate chroot for user access, but I don't
> personally have the need (nor the free disk space).
>
>
> Regards,
> Roger
I have debfoster installed automaticaly in all my chroots (as part of
the create a chroot script) and I just run this every now and then:
sudo debfoster -f -o RemoveCmd="apt-get --purge remove -y"
Remember that sbuild does not always clean up properly. Debfoster is
my maid that does serious cleanup while sbuild just tries not to mess
things up too bad.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2005-08-30, 6:01 pm |
| On Wed, 24 Aug 2005 06:15:08 +1000, Paul TBBle Hampson <Paul.Hampson@anu.edu.au> said:
> On Tue, Aug 23, 2005 at 01:52:22PM -0300, Humberto Massa Guimarăes wrote:
[vbcol=seagreen]
[vbcol=seagreen]
> Or pbuilder-uml, once someone gets onto the user-mode-linunx package
> (and kernel-patch-uml) and brings them back into shape so that the
> pbuilder-uml package can be re-enabled.
I build in SELinux UML's. And, since kernel-package now
supports building uml images, there is no need to have a single
user-mode-linux package -- you can have multiple linux-uml packages
of different versions installed.
Someone just needs to change thepbuilder-uml dependencies to
accept kernel-uml packages instead.
manoj
--
America, how can I write a holy litany in your silly mood? Allen
Ginsberg
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|