Uploads without the architecture-dependant binary packages.
Submitted by Charles Plessy on Mon, 01/25/2010 - 06:36
Hi all,
I found it interesting that a package like git-core is autobuilt on all ports
since at upload time it only contains the source and architecture-independant
binary packages. I like it. I always feel sorry that no build logs are
available for the architecture I use for upload.
Before I start to do the same when possible, is it a bug or a feature ?
Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
- Login to post comments
Uploads without the architecture-dependant binary packages.
Mike Hommey writes:
> On Mon, Jan 25, 2010 at 06:24:49PM +0100, Goswin von Brederlow wrote:
>> Charles Plessy
writes:
>>
>> > Hi all,
>> >
>> > I found it interesting that a package like git-core is autobuilt on all ports
>> > since at upload time it only contains the source and architecture-independant
>> > binary packages. I like it. I always feel sorry that no build logs are
>> > available for the architecture I use for upload.
>> >
>> > Before I start to do the same when possible, is it a bug or a feature ?
>> >
>> > Cheers,
>>
>> That has always been a feature but recently the DAK has changed to throw
>> away the maintainer build debs (while still requireing them to be
>> uploaded) and running an autobuild on all archs.
>
> No it hasn't changed, yet.
>
> Mike
Still not? damn. It was presented in
http://lists.debian.org/debian-devel-announce/2009/11/msg00001.html
| The current "winning" opinion is to go with the source+throw away
| binaries route. We are close to being able to achieve this, it is
| simply that it has not yet been enabled. Before any version of this
| can be enabled, buildd autosigning needs to be implemented in order
| that dak can differentiate buildd uploads vs maintainer uploads.
and later argued that it would suffice to throw away debs in source
uploads and allow all binary only uploads (from buildds or porters
doesn't really matter). Looks like ftp-master didn't take to that.
Sorry to misinform but there is something to look forward too sometime
this century.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Uploads without the architecture-dependant binary packages.
On Tue, Jan 26, 2010 at 08:14:14AM +0100, Goswin von Brederlow wrote:
> Mike Hommey writes:
>
> > On Mon, Jan 25, 2010 at 06:24:49PM +0100, Goswin von Brederlow wrote:
> >> That has always been a feature but recently the DAK has changed to throw
> >> away the maintainer build debs (while still requireing them to be
> >> uploaded) and running an autobuild on all archs.
> >
> > No it hasn't changed, yet.
> >
> > Mike
>
> Still not? damn. It was presented in
>
> http://lists.debian.org/debian-devel-announce/2009/11/msg00001.html
>
> | The current "winning" opinion is to go with the source+throw away
> | binaries route. We are close to being able to achieve this, it is
> | simply that it has not yet been enabled. Before any version of this
> | can be enabled, buildd autosigning needs to be implemented in order
> | that dak can differentiate buildd uploads vs maintainer uploads.
>
> and later argued that it would suffice to throw away debs in source
> uploads and allow all binary only uploads (from buildds or porters
> doesn't really matter). Looks like ftp-master didn't take to that.
Or they're waiting for other items to be implemented before moving
forward, just like the text you quoted says.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega
Uploads without the architecture-dependant binary packages.
> I found it interesting that a package like git-core is autobuilt on all ports
> since at upload time it only contains the source and architecture-independant
> binary packages. I like it. I always feel sorry that no build logs are
> available for the architecture I use for upload.
> Before I start to do the same when possible, is it a bug or a feature ?
Its a bug if you use it to avoid building/testing your own package, being lazy.
Its a feature for those people who manage to regularly use it but
somehow about never turn out with any autobuilder failing.
Chose yourself. :)
--
bye, Joerg
Deine Größe macht mich klein
<@joerg> doll
du darfst mein Bestrafer sein
(!) Wrecktum was kicked from #german by joerg [ok]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Uploads without the architecture-dependant binary packages.
Le Tue, Jan 26, 2010 at 01:22:38AM +0100, Joerg Jaspert a écrit :
>
> > I found it interesting that a package like git-core is autobuilt on all ports
> > since at upload time it only contains the source and architecture-independant
> > binary packages. I like it. I always feel sorry that no build logs are
> > available for the architecture I use for upload.
> > Before I start to do the same when possible, is it a bug or a feature ?
>
> Its a bug if you use it to avoid building/testing your own package, being lazy.
> Its a feature for those people who manage to regularly use it but
> somehow about never turn out with any autobuilder failing.
Many thanks for the fast answer. I always test the build of my pacakges in
sbuild nowardays, and I include regression tests in the build process as much
as I can, with a pointer to the build logs in README.Debian. I will use that
feature so that we can have logs for all arches.
Have a nice day,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Uploads without the architecture-dependant binary packages.
Le Tue, Jan 26, 2010 at 09:59:45AM +0900, Charles Plessy a écrit :
> Le Tue, Jan 26, 2010 at 01:22:38AM +0100, Joerg Jaspert a écrit :
> >
> > > I found it interesting that a package like git-core is autobuilt on all ports
> > > since at upload time it only contains the source and architecture-independant
> > > binary packages. I like it. I always feel sorry that no build logs are
> > > available for the architecture I use for upload.
> > > Before I start to do the same when possible, is it a bug or a feature ?
> >
> > Its a bug if you use it to avoid building/testing your own package, being lazy.
> > Its a feature for those people who manage to regularly use it but
> > somehow about never turn out with any autobuilder failing.
>
> Many thanks for the fast answer. I always test the build of my pacakges in
> sbuild nowardays, and I include regression tests in the build process as much
> as I can, with a pointer to the build logs in README.Debian. I will use that
> feature so that we can have logs for all arches.
Dear Joerg,
while I managed to trigger autobuilding on all architectures for one package
(velvet) in February, the same approach applied to another another one (emboss)
gives problems: the architecture-dependant packages are built, but they are not
transferred to the archive. In both cases I think I did the same:
- Remove mention of the local build architecture in the Binary field.
- Remove mention of the architecture-dependant packages in the Description and
Checksums fields.
- Upload only the architecture-independant packages using the hand-edited Debian
source control file.
http://packages.qa.debian.org/v/velvet/news/20100220T041711Z.html
http://packages.qa.debian.org/e/emboss/news/20100723T023358Z.html
Was there a change in the meantime that makes the trick impossible ?
Have a nice day,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20100726235408.GA10344@merveille.plessy.net
Uploads without the architecture-dependant binary packages.
On Tue, Jul 27, 2010 at 08:54:08 +0900, Charles Plessy wrote:
> while I managed to trigger autobuilding on all architectures for one package
> (velvet) in February, the same approach applied to another another one (emboss)
> gives problems: the architecture-dependant packages are built, but they are not
> transferred to the archive. In both cases I think I did the same:
>
> - Remove mention of the local build architecture in the Binary field.
> - Remove mention of the architecture-dependant packages in the Description and
> Checksums fields.
> - Upload only the architecture-independant packages using the hand-edited Debian
> source control file.
>
> http://packages.qa.debian.org/v/velvet/news/20100220T041711Z.html
> http://packages.qa.debian.org/e/emboss/news/20100723T023358Z.html
>
> Was there a change in the meantime that makes the trick impossible ?
>
No, you just need to fix your changes file name to not clash with the
buildd.
20100723023339|process-upload|dak|Processing changes file|emboss_6.3.1-2_amd64.changes
20100723023358|process-upload|dak|installing changes|emboss_6.3.1-2_amd64.changes
I assume the above is your upload.
20100723091703|process-upload|dak|Processing changes file|emboss_6.3.1-2_amd64.changes
20100723091705|process-upload|dak|rejected|emboss_6.3.1-2_amd64.changes
And this is the buildd trying to upload a file with the same name.
See also /srv/ftp.debian.org/queue/reject/emboss_6.3.1-2_amd64.reason
Cheers,
Julien
Uploads without the architecture-dependant binary packages.
Le Tue, Jul 27, 2010 at 05:35:21PM +0200, Julien Cristau a écrit :
>
> 20100723023339|process-upload|dak|Processing changes file|emboss_6.3.1-2_amd64.changes
> 20100723023358|process-upload|dak|installing changes|emboss_6.3.1-2_amd64.changes
>
> I assume the above is your upload.
>
> 20100723091703|process-upload|dak|Processing changes file|emboss_6.3.1-2_amd64.changes
> 20100723091705|process-upload|dak|rejected|emboss_6.3.1-2_amd64.changes
>
> And this is the buildd trying to upload a file with the same name.
Very interseting !
I uploaded emboss_6.3.1-3_hopla.changes, containing only
architecture-independant packages, and it worked. Now the buildd web page shows
the amd64 packages as installed.
Unfortunately, no binary package shows up on packages.debian.org. There must be
something else broken in the changelog file I uploaded…
Have a nice day,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20100729145829.GC20050@merveille.plessy.net
Uploads without the architecture-dependant binary packages.
On Thu, Jul 29, 2010 at 23:58:29 +0900, Charles Plessy wrote:
> Unfortunately, no binary package shows up on packages.debian.org. There must be
> something else broken in the changelog file I uploaded…
>
packages.debian.org is not where packages show up.
$ lftp -c 'open ftp.debian.org; cd debian/pool/main/e/emboss; ls *_6.3.1-3_*.deb'
-rw-rw-r-- 1 1176 1176 870670 Jul 28 15:17 emboss-data_6.3.1-3_all.deb
-rw-rw-r-- 1 1176 1176 5443642 Jul 28 15:17 emboss-doc_6.3.1-3_all.deb
-rw-rw-r-- 1 1176 1176 562952 Jul 28 23:17 emboss-lib_6.3.1-3_alpha.deb
-rw-rw-r-- 1 1176 1176 431912 Jul 28 23:17 emboss-lib_6.3.1-3_amd64.deb
-rw-rw-r-- 1 1176 1176 459534 Jul 28 20:32 emboss-lib_6.3.1-3_armel.deb
-rw-rw-r-- 1 1176 1176 415662 Jul 28 23:17 emboss-lib_6.3.1-3_i386.deb
-rw-rw-r-- 1 1176 1176 627392 Jul 28 22:32 emboss-lib_6.3.1-3_ia64.deb
-rw-rw-r-- 1 1176 1176 430486 Jul 28 19:47 emboss-lib_6.3.1-3_mips.deb
-rw-rw-r-- 1 1176 1176 440542 Jul 28 22:33 emboss-lib_6.3.1-3_mipsel.deb
-rw-rw-r-- 1 1176 1176 454444 Jul 28 20:32 emboss-lib_6.3.1-3_powerpc.deb
-rw-rw-r-- 1 1176 1176 459720 Jul 29 10:02 emboss-lib_6.3.1-3_s390.deb
-rw-rw-r-- 1 1176 1176 5848884 Jul 28 15:17 emboss-test_6.3.1-3_all.deb
-rw-rw-r-- 1 1176 1176 1083960 Jul 28 23:17 emboss_6.3.1-3_alpha.deb
-rw-rw-r-- 1 1176 1176 1003214 Jul 28 23:17 emboss_6.3.1-3_amd64.deb
-rw-rw-r-- 1 1176 1176 1063368 Jul 28 20:32 emboss_6.3.1-3_armel.deb
-rw-rw-r-- 1 1176 1176 971568 Jul 28 23:17 emboss_6.3.1-3_i386.deb
-rw-rw-r-- 1 1176 1176 1214176 Jul 28 22:32 emboss_6.3.1-3_ia64.deb
-rw-rw-r-- 1 1176 1176 989738 Jul 28 19:47 emboss_6.3.1-3_mips.deb
-rw-rw-r-- 1 1176 1176 994356 Jul 28 22:33 emboss_6.3.1-3_mipsel.deb
-rw-rw-r-- 1 1176 1176 1029044 Jul 28 20:32 emboss_6.3.1-3_powerpc.deb
-rw-rw-r-- 1 1176 1176 1064614 Jul 29 10:02 emboss_6.3.1-3_s390.deb
-rw-rw-r-- 1 1176 1176 4104072 Jul 28 15:17 jemboss_6.3.1-3_all.deb
-rw-rw-r-- 1 1176 1176 2077596 Jul 28 23:17 libajax6-dev_6.3.1-3_alpha.deb
-rw-rw-r-- 1 1176 1176 1465122 Jul 28 23:17 libajax6-dev_6.3.1-3_amd64.deb
-rw-rw-r-- 1 1176 1176 1374264 Jul 28 20:32 libajax6-dev_6.3.1-3_armel.deb
-rw-rw-r-- 1 1176 1176 1333364 Jul 28 23:17 libajax6-dev_6.3.1-3_i386.deb
-rw-rw-r-- 1 1176 1176 2013060 Jul 28 22:32 libajax6-dev_6.3.1-3_ia64.deb
-rw-rw-r-- 1 1176 1176 1686040 Jul 28 19:47 libajax6-dev_6.3.1-3_mips.deb
-rw-rw-r-- 1 1176 1176 1666272 Jul 28 22:33 libajax6-dev_6.3.1-3_mipsel.deb
-rw-rw-r-- 1 1176 1176 1519950 Jul 28 20:32 libajax6-dev_6.3.1-3_powerpc.deb
-rw-rw-r-- 1 1176 1176 1459788 Jul 29 10:02 libajax6-dev_6.3.1-3_s390.deb
-rw-rw-r-- 1 1176 1176 1407918 Jul 28 23:17 libajax6_6.3.1-3_alpha.deb
-rw-rw-r-- 1 1176 1176 1342902 Jul 28 23:17 libajax6_6.3.1-3_amd64.deb
-rw-rw-r-- 1 1176 1176 1207100 Jul 28 20:32 libajax6_6.3.1-3_armel.deb
-rw-rw-r-- 1 1176 1176 1209842 Jul 28 23:17 libajax6_6.3.1-3_i386.deb
-rw-rw-r-- 1 1176 1176 1660928 Jul 28 22:32 libajax6_6.3.1-3_ia64.deb
-rw-rw-r-- 1 1176 1176 1061868 Jul 28 19:47 libajax6_6.3.1-3_mips.deb
-rw-rw-r-- 1 1176 1176 1084206 Jul 28 22:33 libajax6_6.3.1-3_mipsel.deb
-rw-rw-r-- 1 1176 1176 1293148 Jul 28 20:32 libajax6_6.3.1-3_powerpc.deb
-rw-rw-r-- 1 1176 1176 1323766 Jul 29 10:02 libajax6_6.3.1-3_s390.deb
-rw-rw-r-- 1 1176 1176 316822 Jul 28 23:17 libnucleus6-dev_6.3.1-3_alpha.deb
-rw-rw-r-- 1 1176 1176 246754 Jul 28 23:17 libnucleus6-dev_6.3.1-3_amd64.deb
-rw-rw-r-- 1 1176 1176 234162 Jul 28 20:32 libnucleus6-dev_6.3.1-3_armel.deb
-rw-rw-r-- 1 1176 1176 230924 Jul 28 23:17 libnucleus6-dev_6.3.1-3_i386.deb
-rw-rw-r-- 1 1176 1176 318660 Jul 28 22:32 libnucleus6-dev_6.3.1-3_ia64.deb
-rw-rw-r-- 1 1176 1176 270712 Jul 28 19:47 libnucleus6-dev_6.3.1-3_mips.deb
-rw-rw-r-- 1 1176 1176 268530 Jul 28 22:33 libnucleus6-dev_6.3.1-3_mipsel.deb
-rw-rw-r-- 1 1176 1176 258178 Jul 28 20:32 libnucleus6-dev_6.3.1-3_powerpc.deb
-rw-rw-r-- 1 1176 1176 240920 Jul 29 10:02 libnucleus6-dev_6.3.1-3_s390.deb
-rw-rw-r-- 1 1176 1176 247788 Jul 28 23:17 libnucleus6_6.3.1-3_alpha.deb
-rw-rw-r-- 1 1176 1176 231022 Jul 28 23:17 libnucleus6_6.3.1-3_amd64.deb
-rw-rw-r-- 1 1176 1176 222092 Jul 28 20:32 libnucleus6_6.3.1-3_armel.deb
-rw-rw-r-- 1 1176 1176 216726 Jul 28 23:17 libnucleus6_6.3.1-3_i386.deb
-rw-rw-r-- 1 1176 1176 279644 Jul 28 22:32 libnucleus6_6.3.1-3_ia64.deb
-rw-rw-r-- 1 1176 1176 212816 Jul 28 19:47 libnucleus6_6.3.1-3_mips.deb
-rw-rw-r-- 1 1176 1176 214102 Jul 28 22:33 libnucleus6_6.3.1-3_mipsel.deb
-rw-rw-r-- 1 1176 1176 233666 Jul 28 20:32 libnucleus6_6.3.1-3_powerpc.deb
-rw-rw-r-- 1 1176 1176 229932 Jul 29 10:02 libnucleus6_6.3.1-3_s390.deb
$
Maybe you could check yourself next time...
Cheers,
Julien
Uploads without the architecture-dependant binary packages.
Le Thu, Jul 29, 2010 at 05:10:57PM +0200, Julien Cristau a écrit :
> On Thu, Jul 29, 2010 at 23:58:29 +0900, Charles Plessy wrote:
>
> > Unfortunately, no binary package shows up on packages.debian.org. There must be
> > something else broken in the changelog file I uploaded…
> >
> packages.debian.org is not where packages show up.
>
> $ lftp -c 'open ftp.debian.org; cd debian/pool/main/e/emboss; ls *_6.3.1-3_*.deb'
> -rw-rw-r-- 1 1176 1176 870670 Jul 28 15:17 emboss-data_6.3.1-3_all.deb
> -rw-rw-r-- 1 1176 1176 5443642 Jul 28 15:17 emboss-doc_6.3.1-3_all.deb
>
> Maybe you could check yourself next time...
Yes, it is quite shameful ;) I have posted too quicky and though that a ~24
hour delay would be groosso-modo enough that packages.d.o would be a good
approximation of what we have on our mirrors.
Actually, I remembered a post about ftp.debian.org saying “In the future, it
may get services reduced, or shut down, or converted into a globally
load-balanced name, or whatever. Please don't use it.”
http://lists.debian.org/msgid-search/E1IzHKi-0007AN-MH@keid.carnet.hr
Is “/org/ftp.debian.org” on merkel.debian.org the same as ftp.debian.org, or is
it a more canonical location ? /org/ftp-master.debian.org is a symbolic link to
/org/ftp.debian.org, and /org/ftp.debian.org/ftp is a symbolic link to
/org/ftp.root/debian, which itself is a symbolic link to
/org/mirrors/ftp.debian.org/ftp, and at this point I admit I do not know if I
am looking at a mirror of ftp.debian.org or a mirror of the master FTP site, which
according to the above email, is not ftp.debian.org…
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20100730001804.GA3948@merveille.plessy.net
Uploads without the architecture-dependant binary packages.
Charles Plessy
writes:
> Le Thu, Jul 29, 2010 at 05:10:57PM +0200, Julien Cristau a écrit :
>> On Thu, Jul 29, 2010 at 23:58:29 +0900, Charles Plessy wrote:
>>
>> > Unfortunately, no binary package shows up on packages.debian.org. There must be
>> > something else broken in the changelog file I uploadedâ¦
>> >
>> packages.debian.org is not where packages show up.
>>
>> $ lftp -c 'open ftp.debian.org; cd debian/pool/main/e/emboss; ls *_6.3.1-3_*.deb'
I prefer "rmadison emboss".
emboss | 6.3.1-3 | unstable | source, alpha, amd64, armel, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/87mxt9e3lm.fsf@frosties.localdomain
Uploads without the architecture-dependant binary packages.
Julien Cristau writes:
> On Tue, Jul 27, 2010 at 08:54:08 +0900, Charles Plessy wrote:
>
>> while I managed to trigger autobuilding on all architectures for one package
>> (velvet) in February, the same approach applied to another another one (emboss)
>> gives problems: the architecture-dependant packages are built, but they are not
>> transferred to the archive. In both cases I think I did the same:
>>
>> - Remove mention of the local build architecture in the Binary field.
>> - Remove mention of the architecture-dependant packages in the Description and
>> Checksums fields.
>> - Upload only the architecture-independant packages using the hand-edited Debian
>> source control file.
>>
>> http://packages.qa.debian.org/v/velvet/news/20100220T041711Z.html
>> http://packages.qa.debian.org/e/emboss/news/20100723T023358Z.html
>>
>> Was there a change in the meantime that makes the trick impossible ?
>>
> No, you just need to fix your changes file name to not clash with the
> buildd.
>
> 20100723023339|process-upload|dak|Processing changes file|emboss_6.3.1-2_amd64.changes
> 20100723023358|process-upload|dak|installing changes|emboss_6.3.1-2_amd64.changes
>
> I assume the above is your upload.
>
> 20100723091703|process-upload|dak|Processing changes file|emboss_6.3.1-2_amd64.changes
> 20100723091705|process-upload|dak|rejected|emboss_6.3.1-2_amd64.changes
>
> And this is the buildd trying to upload a file with the same name.
>
> See also /srv/ftp.debian.org/queue/reject/emboss_6.3.1-2_amd64.reason
>
> Cheers,
> Julien
Maybe there should be a tool (small wrapper script) to edit the changes
file the right way. There are probably more people that would like to do
this and a lot more people that would like to see it being used.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/87sk33wv0v.fsf@frosties.localdomain
Uploads without the architecture-dependant binary packages.
Charles Plessy
writes:
> Hi all,
>
> I found it interesting that a package like git-core is autobuilt on all ports
> since at upload time it only contains the source and architecture-independant
> binary packages. I like it. I always feel sorry that no build logs are
> available for the architecture I use for upload.
>
> Before I start to do the same when possible, is it a bug or a feature ?
>
> Cheers,
That has always been a feature but recently the DAK has changed to throw
away the maintainer build debs (while still requireing them to be
uploaded) and running an autobuild on all archs.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Uploads without the architecture-dependant binary packages.
>> Before I start to do the same when possible, is it a bug or a feature ?
Both.
> That has always been a feature but recently the DAK has changed to throw
> away the maintainer build debs (while still requireing them to be
> uploaded) and running an autobuild on all archs.
Oh, when did that happen? How good that I learn of it now. I thought I
knew what happens to DAK, but obviously I missed something there...
(No, its not doing that yet)
--
ein jahr ist ein bisschen zu optimistisch,bye, Joerg
[ New Maintainer Prozess ]
<_rene_> panthera: kommt auf den NM/AM an.
/* _rene_ ist pantheras AM und lässt sich mit pantheras
package check schon ein wenig Zeit ;) */
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org