Re: Snapshot/Rollback using LVM/EVMS

[Matt Zimmerman]

On Mon, Aug 22, 2005 at 11:28:46PM -0700, [EMAIL PROTECTED] wrote:
> Thanks Goswin, this is what I thought.
> Now I need someone help me with EVMS steps.
> How to make a snapshot and rollback.

This mailing list is for development-related discussion; please use
debian-user@lists.debian.org for tech support.

-- 
 - mdz


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

Re: How coldplug works

[Isaac Clerencia]

On Tuesday, 23 August 2005 07:02, Joe Smith wrote:
> Ok, I know just about nothing about this.
> I currently have 2.6 kernel, hotplug, and udev.
>
> If I replace hotplug with coldplug, everything should still work barring
> unexpected bugs?
> (Once the archive is updated of course, so that udev does not require
> hotplug, and coldplug is actually included)
I've just tried it and it has worked really great, except it has not loaded 
mousedev module. Everything else has worked, and it's incredible fast (at 
least, really *faster* than hotplug).

It looks really promising :)

Best regards

-- 
Isaac Clerencia at Warp Networks, http://www.warp.es
Work: <[EMAIL PROTECTED]>   | Debian: <[EMAIL PROTECTED]>


pgpKJnRWAJLEf.pgp
Description: PGP signature

Re: Using buildds only

[Tomas Fasth]

Martin Pitt skrev:
> Hi Wouter!
>
> Wouter Verhelst [2005-08-23  1:26 +0200]:
>
>>So you suggest throwing buildd out of the window and switching to
>>pbuilder, then?
>
>
> Something like this is in fact considered. Probably Ubuntu won't use
> pbuilder itself since it is not the most efficient implementation
> around, but rebuilding the buildd chroots from scratch would help to
> eliminate many FTBFS bugs due to polluted chroots.

I find your statement about pbuilder and efficiency interesting.
Would you care to explain what you mean?

As a side note, I have myself thought about extending pbuilder using
unionfs and overlays to avoid the tarball extraction for each build.

--
Tomas Fasth <[EMAIL PROTECTED]>
GnuPG Fingerprint: DC7B 9453 7F26 1BF9 6B21 9F90 C187 7355 9FE8 D504


signature.asc
Description: OpenPGP digital signature

Re: pvcreate on loopback file with lvm2

[[EMAIL PROTECTED]]

Thanks a lot.


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

Re: Using buildds only (was: Results of the meeting...)

[Martin Pitt]

Hi!

Steve Langasek [2005-08-22 18:09 -0700]:
> On Mon, Aug 22, 2005 at 03:34:16PM +0200, Martin Pitt wrote:
> 
> > W. Borgert [2005-08-22 14:37 +0200]:
> > > Quoting Matthew Palmer <[EMAIL PROTECTED]>:
> > > > I used to think that too.  I took a wander through queue/reject on 
> > > > merkel.
> > > > I don't think that any more.  I'm curious as to how Ubuntu is going to
> > > > sustain source-only uploads, honestly.
> 
> > > Mandatory, signed build and test logs?  I've no idea...
> 
> > Ubuntu does not do anything of that sort. If I merely fix a
> > description or add a Recommends:, I don't need to bother with
> > rebuilding the package locally, and if I fix something bigger, I need
> > to build and test the package anyway.
> 
> > The system of source uploads works well in Ubuntu, so please don't try
> > to invent problems which don't matter in reality.
> 
> So, hmm, what about the anecdotal evidence of some Ubuntu maintainers doing
> 3-4 sequential uploads of a package before finally uploading a version that
> is buildable from source *anywhere*?

This will teach them to do a build before uploading. :-) In most
cases, this is due to forgotten build depends, so this problem is
quite orthogonal to source-only uploads. Such failures happen in
Debian, too (however, not quite as often, since katie runs much more
often in Ubuntu, so it's much more tempting to just throw it at a
buildd and see what happens). 

It doesn't really hurt us right now, so we didn't start to force
building packages in pbuilder. buildd time is cheap compared to
developer time, so introducing mandatory pbuilding would slow down
development quite drastically. 

Martin
-- 
Martin Pitthttp://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org


signature.asc
Description: Digital signature

Re: Will the amd64 port be rejected because of the 98% rule?

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> Hi,
>
> * Goswin von Brederlow ([EMAIL PROTECTED]) [050823 03:32]:
>> Maybe the 98% rule was just a look at
>> http://buildd.debian.org/stats/graph-week-big.png or
>> http://buildd.debian.org/stats/graph2-week-big.png and then picking a
>> number so that the archs they want in are above it. :)
>
> No. 98% ist the number where users usually start crying to the release
> team that there packages are out-of-date and if that can be ignored for
> now.
>
>
> Cheers,
> Andi

And where do you read the % value from? Because the buildd.d.o stats
has pretty much all archs below it all the time and there is no big
public screaming festival about it.

MfG
Goswin



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

Re: vancouver revisited

[Olaf van der Spek]

On 8/23/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > The number of buildds required to keep up with the
> > volume of uploaded packages must not be greater than two.
> > There must be that many buildds, in addition there must also be  a redundant
> > buildd.
> 
> This means 2 or 3?

No, it says at most 2 buildds must be able to keep up by themselves.
And that at least 1 extra buildd must be available.

So it's >= 2.

BTW, please check the net-tools thread. :)

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Olaf van der Spek]

On 8/23/05, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> Roger Leigh <[EMAIL PROTECTED]> writes:
> 
> > Andreas Jochens in particular did a lot of hard work in fixing most of
> > the GCC 4.0 failures and regressions over the last year while porting
> > for amd64.  The fact that many maintainers have not yet applied, or at
> > least carefully reviewed and applied amended patches, is a pity.
> 
> The reason I didn't was that I didn't want to make potentially
> destabilizing changes with sarge in progress.

Sarge was released more than two months ago. Why didn't you do it in
the meantime (just curious and wondering)?

Re: how to fully replace another package

[Marco d'Itri]

On Aug 23, Ben Armstrong <[EMAIL PROTECTED]> wrote:

> > > script, it should be written to exit if the appropriate binary isn't
> > > found.
> > The appropriate binary is a conffile as well.
> Now, that's not strictly true, is it?  /etc/init.d/hotplug
> invokes /sbin/hotplug, which almost entirely consists of conffiles, but
> is not itself a conffile.  Isn't that removed when the package is
Right, it's not used but it's checked.
But then there is still /etc/hotplug.d/default/default.hotplug, which if
present will create all kinds of troubles.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: How coldplug works

[Marco d'Itri]

On Aug 23, Isaac Clerencia <[EMAIL PROTECTED]> wrote:

> I've just tried it and it has worked really great, except it has not loaded 
> mousedev module. Everything else has worked, and it's incredible fast (at 
It's supposed to, do you mind investigating? Do not delete the
generated events, etc. Try manually running the init script a second
time too.
I noticed that on my system the first time it's run the ehci_hcd is not
loaded, but I have not yet found why.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: More pbuilder use!

[Olaf van der Spek]

On 8/23/05, Joe Smith <[EMAIL PROTECTED]> wrote:
> Actually perhaps software should be built outside of clean chroots. Why?

Did someone suggest to disallow that?
Why can't you do both?

WebSVN of svn.debian.org uses wrong encoding

[W. Borgert]

Hi,

I have checked in some files into svn.debian.org.  The files are
in UTF-8 encoding[1], but the web front-end seems to believe in
ISO-8859-1.  Did I do something wrong when checking in files, or
is WebSVN too plain in its assumptions?  How/where can I file a
bug, if the problem is in svn.debian.org?  TIA!

[1] http://svn.debian.org/wsvn/ddp/refcard/trunk/entries-ru.dbk?op=file

(If WebSVN does not know about encodings, UTF-8 might be a more
sensible default than ISO-8859-1 nowadays.)

Cheers,
-- 
W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/


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

Bug#324632: ITP: gausssum -- Scripts which parse the output of Gaussian and GAMESS

[LI Daobing]

Package: wnpp
Severity: wishlist
Owner: LI Daobing <[EMAIL PROTECTED]>

* Package name: gausssum
  Version : 0.9
  Upstream Author : Noel O'Boyle
* URL : http://gausssum.sourceforge.net/
* License : GPL
  Description : Scripts which parse the output of Gaussian and GAMESS

 GaussSum can do the following: (Gau=Gaussian, GAM=GAMESS)
 .
  * display all lines containing a certain phrase (Gau/GAM)
  * follow the progress of the SCF convergence (Gau/GAM)
  * follow the progress of a geometry optimisation (Gau/GAM)
  * extract molecular orbital information, including contributions of
groups of atoms to the molecular orbitals (Gau/GAM)
  * plot the density of states spectrum (and the partial density of
states, in the case of groups of atoms) (Gau/GAM)
  * plot the crystal orbital overlap population (COOP) spectrum, which
gives information on the bonding/anti-bonding nature of an overlap
between atoms/groups (Gau/GAM)
  * extract information on the UV-Vis transitions, including the change
in the charge density of groups of atoms (Gau)
  * plot the UV-Vis spectrum (Gau)
  * automate the creation of electron density difference maps, which
visually show the change in charge density associated with a given
electronic transition (Gau)
  * extract information on IR and Raman vibrations (Gau)
  * plot the IR and Raman spectra, which may be scaled using general or
individual scaling factors (Gau)
  
-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686-smp
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Re: How coldplug works

[Isaac Clerencia]

On Tuesday, 23 August 2005 09:57, Marco d'Itri wrote:
> It's supposed to, do you mind investigating? Do not delete the
> generated events, etc. Try manually running the init script a second
> time too.
> I noticed that on my system the first time it's run the ehci_hcd is not
> loaded, but I have not yet found why.
I will do after work.

Best regards

-- 
Isaac Clerencia at Warp Networks, http://www.warp.es
Work: <[EMAIL PROTECTED]>   | Debian: <[EMAIL PROTECTED]>


pgpjJ4i6ssgho.pgp
Description: PGP signature

Re: How coldplug works

[Luca Capello]

Hi Marco!

On Tue 23 Aug 2005 09:57 +0200, Marco d'Itri wrote:
> On Aug 23, Isaac Clerencia <[EMAIL PROTECTED]> wrote:
>
>> I've just tried it and it has worked really great, except it has not loaded 
>> mousedev module. Everything else has worked, and it's incredible fast (at 
> It's supposed to, do you mind investigating? Do not delete the
> generated events, etc. Try manually running the init script a second
> time too.
> I noticed that on my system the first time it's run the ehci_hcd is not
> loaded, but I have not yet found why.

I just gave coldplug a try.

First of all, my Debian:

- unstable, just upgraded (not dist-upgrade, but a simple upgrade)

- vanilla 2.6.13-rc6 + ACPI patch dated 20050729 (compiled with
  make-kpkg), external modules are ALSA, cdfs, ieee80211, ipw2100,
  pwc, qc-usb and thinkpad

- udev 0.068-1 (and `dpkg --purge --force-all hotplug` ;-) )

- IBM ThinkPad T42p + docking station


And here the results (differences versus hotplug):

- mousedev is correctly loaded, but this is not the case for psmouse
  (so, it automatically starts xdm, but I need to manually load
  psmouse)

- no sound at all (the ALSA modules are not loaded)

- no wired network (I use the e1000 driver), while the ipw2100 module
  is automatically loaded

- otherwise, it seems to work correctly (I tried plugging in an
  external USB drive and scsi_mod, usb_storage and sd_mod are
  correctly and automatically loaded, but not uloaded)


BTW, as you suggested, I tried to manully run the init script
two/three times, but nothing changed.

I'm available for others test if you need (and I'm on Freenode as
gismo).

Thx, bye,
Gismo / Luca


pgpEviYSyNVfd.pgp
Description: PGP signature

Re: Using buildds only

[Martin Pitt]

Hi Tomas!

Tomas Fasth [2005-08-23  9:31 +0200]:
> >>So you suggest throwing buildd out of the window and switching to
> >>pbuilder, then?
> >
> >
> > Something like this is in fact considered. Probably Ubuntu won't use
> > pbuilder itself since it is not the most efficient implementation
> > around, but rebuilding the buildd chroots from scratch would help to
> > eliminate many FTBFS bugs due to polluted chroots.
> 
> I find your statement about pbuilder and efficiency interesting.
> Would you care to explain what you mean?
> 
> As a side note, I have myself thought about extending pbuilder using
> unionfs and overlays to avoid the tarball extraction for each build.

Indeed I referred to the overhead of tarball extraction and the like.
unionfs is a great idea, do you plan to integrate this into the
main pbuilder package? This would really rock. :)

Thanks,

Martin

-- 
Martin Pitthttp://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org


signature.asc
Description: Digital signature

Re: Using buildds only (was: Results of the meeting...)

[Marc Haber]

On Tue, 23 Aug 2005 01:42:18 +0200, Martin Pitt <[EMAIL PROTECTED]>
wrote:
>Something like this is in fact considered. Probably Ubuntu won't use
>pbuilder itself since it is not the most efficient implementation
>around, but rebuilding the buildd chroots from scratch would help to
>eliminate many FTBFS bugs due to polluted chroots.

Surely you are aware how much time it takes to rebuild a chroot on
slower architectures. Some technology able to restore a large
directory tree to a static default in short time should be used here.

I am not sure whether LVM (have a LV with the master chroot image,
make a snapshot, build inside the snapshot, remove the snapshot) could
help here.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: WebSVN of svn.debian.org uses wrong encoding

[Frans Pop]

On Tuesday 23 August 2005 10:20, W. Borgert wrote:
> I have checked in some files into svn.debian.org.  The files are
> in UTF-8 encoding[1], but the web front-end seems to believe in
> ISO-8859-1.  Did I do something wrong when checking in files, or
> is WebSVN too plain in its assumptions?  How/where can I file a
> bug, if the problem is in svn.debian.org?  TIA!
>
> [1] http://svn.debian.org/wsvn/ddp/refcard/trunk/entries-ru.dbk?op=file

WebSVN does not know about the contents of files in the repository period. 
As it is just a frontend to svn, you cannot expect it to know about every 
weird file format and encoding around.
IMO, the main purpose of websvn is to be able to view diffs in _code_ and 
maybe download individual files.
For everything else, use svn itself and work with its files in their 
proper environment.

If you really want to file a bug about it, the Tech Support Tracking 
System for project alioth on alioth is probably your best bet, but I 
doubt that is really useful.

> (If WebSVN does not know about encodings, UTF-8 might be a more
> sensible default than ISO-8859-1 nowadays.)

Maybe, maybe not. Depends what part of the world you're from.
Food for endless flames^Wdiscussions.


pgp7sRUDHDzP3.pgp
Description: PGP signature

Re: How coldplug works

[Marco d'Itri]

On Aug 23, Luca Capello <[EMAIL PROTECTED]> wrote:

> And here the results (differences versus hotplug):
As Luca just discovered, it will not work unless you have the
/sbin/udevinitsend binary. Get it from the udev build directory or
install http://incoming.debian.org/udev_0.068-2_i386.deb .

> - otherwise, it seems to work correctly (I tried plugging in an
>   external USB drive and scsi_mod, usb_storage and sd_mod are
>   correctly and automatically loaded, but not uloaded)
Modules will not be unloaded.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Marc Haber]

On Mon, 22 Aug 2005 14:51:52 -0700, Steve Langasek <[EMAIL PROTECTED]>
wrote:
>On Mon, Aug 22, 2005 at 06:22:11PM +, W. Borgert wrote:
>> On Mon, Aug 22, 2005 at 07:29:31PM +0200, Adrian von Bidder wrote:
>> > really matters:  can we (the Debian project) maintain the port?  Thus I 
>> > propose we only limit on the number of developers:  are there people who 
>> > are willing and competent to maintain kernel, boot loader, platform 
>> > specific installer bits, libc and toolchain?
>
>> That sounds sensible.
>
>It ignores the fact that every port is a drain on centralized project
>resources, whether it has users or not.

Even a userless port is a service to the community. I have, for
example, a package whose upstream is a keen reader of our buildd logs
to improve on his package's portability.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: vancouver revisited

[Wouter Verhelst]

On Tue, Aug 23, 2005 at 09:16:47AM +0200, Olaf van der Spek wrote:
> On 8/23/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]> you wrote:
> > > The number of buildds required to keep up with the
> > > volume of uploaded packages must not be greater than two.
> > > There must be that many buildds, in addition there must also be  a 
> > > redundant
> > > buildd.
> > 
> > This means 2 or 3?
> 
> No, it says at most 2 buildds must be able to keep up by themselves.
> And that at least 1 extra buildd must be available.

No, it says exactly one extra.

I'd much rather have seen that point go, but that didn't happen.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: Using buildds only (was: Results of the meeting...)

[Wouter Verhelst]

On Tue, Aug 23, 2005 at 09:32:33AM +0200, Martin Pitt wrote:
> It doesn't really hurt us right now, so we didn't start to force
> building packages in pbuilder. buildd time is cheap compared to
> developer time, so introducing mandatory pbuilding would slow down
> development quite drastically. 

I guess this is where Debian and Ubuntu differ. Granted, buildd time is
cheaper than developer time, but then we don't have the hardware to
rebuild all of our archive in a few days, like you guys do :-)

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: Using buildds only (was: Results of the meeting...)

[Peter 'p2' De Schrijver]

On Tue, Aug 23, 2005 at 11:25:41AM +0200, Marc Haber wrote:
> On Tue, 23 Aug 2005 01:42:18 +0200, Martin Pitt <[EMAIL PROTECTED]>
> wrote:
> >Something like this is in fact considered. Probably Ubuntu won't use
> >pbuilder itself since it is not the most efficient implementation
> >around, but rebuilding the buildd chroots from scratch would help to
> >eliminate many FTBFS bugs due to polluted chroots.
> 
> Surely you are aware how much time it takes to rebuild a chroot on
> slower architectures. Some technology able to restore a large
> directory tree to a static default in short time should be used here.
> 
> I am not sure whether LVM (have a LV with the master chroot image,
> make a snapshot, build inside the snapshot, remove the snapshot) could
> help here.

Or only rebuild the chroot when a build failure is detected (or better
when a build failure is detected which could be caused by a broken
chroot).

Cheers,

Peter (p2).


signature.asc
Description: Digital signature

Re: vancouver revisited

[Steve Langasek]

On Tue, Aug 23, 2005 at 11:21:00AM +0200, Wouter Verhelst wrote:
> On Tue, Aug 23, 2005 at 09:16:47AM +0200, Olaf van der Spek wrote:
> > On 8/23/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> > > In article <[EMAIL PROTECTED]> you wrote:
> > > > The number of buildds required to keep up with the
> > > > volume of uploaded packages must not be greater than two.
> > > > There must be that many buildds, in addition there must also be  a 
> > > > redundant
> > > > buildd.

> > > This means 2 or 3?

> > No, it says at most 2 buildds must be able to keep up by themselves.
> > And that at least 1 extra buildd must be available.

> No, it says exactly one extra.

I don't personally have any reason to say a port *can't* have more than one
buildd, though of course there may be reasons (resource issues) why the w-b
maintainers would object to having too many buildds connecting.

> I'd much rather have seen that point go, but that didn't happen.

Meaning you would have preferred that there not be a requirement of buildd
redundancy, or you would have preferred that there not be a limit on the
number of buildds needed to keep up?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Steve Langasek]

On Tue, Aug 23, 2005 at 11:12:09AM +0200, Marc Haber wrote:
> On Mon, 22 Aug 2005 14:51:52 -0700, Steve Langasek <[EMAIL PROTECTED]>
> wrote:
> >On Mon, Aug 22, 2005 at 06:22:11PM +, W. Borgert wrote:
> >> On Mon, Aug 22, 2005 at 07:29:31PM +0200, Adrian von Bidder wrote:
> >> > really matters:  can we (the Debian project) maintain the port?  Thus I 
> >> > propose we only limit on the number of developers:  are there people who 
> >> > are willing and competent to maintain kernel, boot loader, platform 
> >> > specific installer bits, libc and toolchain?

> >> That sounds sensible.

> >It ignores the fact that every port is a drain on centralized project
> >resources, whether it has users or not.

> Even a userless port is a service to the community. I have, for
> example, a package whose upstream is a keen reader of our buildd logs
> to improve on his package's portability.

So we should spend 4-5GB of disk space per architecture on ftp-master.d.o
for ports with no users, just so upstreams can see how portable their code
is to architectures that have no users?

No thanks.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Steve Langasek]

On Mon, Aug 22, 2005 at 11:42:50AM -0400, David Nusinow wrote:
> On Mon, Aug 22, 2005 at 12:22:47AM -0700, Steve Langasek wrote:
> > There was discussion in Vancouver about requiring ports to have an
> > "upstream" kernel maintainer, FSO "upstream"; perhaps we should be
> > considering requiring there to be a glibc/gcc/binutils upstream for each
> > port, so that we don't get the first sign of these bugs when the
> > packages hit unstable.

> What sort of q&a would upstream be doing that would help us out here?

Ideally, for each port there would be someone tracking glibc/gcc/binutils
upstream who's in a position to recognize when a change may cause
regressions for that port, and testing accordingly.

Next best is to have people who are making heavy use of updated versions of
these packages before they reach unstable; this should generally be fairly
straightforward, e.g. both gcc-4.0 and glibc 2.3.5 were in experimental for
a while before being uploaded to unstable, but the buildds are still doing a
lot of the work of catching regressions once they hit unstable, and by that
point the damage is done.

> Can the port teams do this kind of work themselves prior to packages
> hitting unstable?

Absolutely.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: WebSVN of svn.debian.org uses wrong encoding

[W. Borgert]

Quoting Frans Pop <[EMAIL PROTECTED]>:
> WebSVN does not know about the contents of files in the repository period.

OK.

> As it is just a frontend to svn, you cannot expect it to know about every
> weird file format and encoding around.

OK.

> IMO, the main purpose of websvn is to be able to view diffs in _code_ and
> maybe download individual files.

I handle documentation like code :-)

> For everything else, use svn itself and work with its files in their
> proper environment.

Not all of "my" translators are easy with svn command line.  WebSVN
would be helpful, so they see, whether I did my homework and checked
in their latest changes correctly.  Could be useful for d-i, too.

> If you really want to file a bug about it, the Tech Support Tracking
> System for project alioth on alioth is probably your best bet, but I
> doubt that is really useful.

I did this anyway :-)

> Food for endless flames^Wdiscussions.

As nearly everything :-(

Cheers, WB


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

Re: WebSVN of svn.debian.org uses wrong encoding

[Frans Pop]

On Tuesday 23 August 2005 12:45, W. Borgert wrote:
> Not all of "my" translators are easy with svn command line.  WebSVN
> would be helpful, so they see, whether I did my homework and checked
> in their latest changes correctly.  Could be useful for d-i, too.

In my experience some kind of revision tracking is more useful for that.
The most simple system has a comment in translations stating which version 
of the English original it is based on.

For that you should enable the svn keyword "Id" (using 'svn propset 
svn:keywords Id') and add a comment in your English files containing 
"$Id:".

Thus:

Which on commits will automatically expand to, for example:


Then translators can add something like:



pgpiIGOdOtINd.pgp
Description: PGP signature

Re: Using buildds only (was: Results of the meeting...)

[Mark Brown]

On Tue, Aug 23, 2005 at 01:42:18AM +0200, Martin Pitt wrote:

> one day (as the buildds do) is certainly acceptable. OTOH, lagging
> behind for several weeks (which is not unreasonable for folks without
> a phat pipe) is certainly not, especially if you are in a period of
> massive transitions.

During larger transitions if you're not using i386 it's often hard to
keep relatively up to date at all - using PowerPC I tend to find that 
GNOME transitions and similar cause dist-upgrade and aptitude to fail
for extended periods of time, requiring manual intervention to keep
large parts of the archive at all up to date.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Unnecessary "Conflicts" with imap-server packages

[Edward]

Hi there,

Is it necessary for the following packages to "Conflict" with the
virtual package "imap-server":

  bincimap-run
  courier-imap
  cyrus-imapd(*)
  cyrus21-imapd  (*)
  dovecot-imapd
  mailutils-imap4d   (*)
  uw-imapd   (*)

For example, I recently moved from "uw-imapd" to "dovecot-imapd", but
found it difficult to setup a testing environment where both IMAP
daemons were installed, as uw-imapd conflicted with imap-server, which
was provided by dovecot-imapd.

Such testing is obviously necessary and it would be good if there was a
way in which it could be more easily supported!

In the case of packages that launch their imap daemons via inetd (marked
with "*" above), there may be a Debian Policy justification[1] for both
providing and conflicting with 'imap-server'.

However, if a piece of software cannot be immediately functional upon
installation it doesn't mean that one shouldn't be able to install it at
all!  :)

My humbly proposed fix: remove the "Conflicts: imap-server" from these
packages, and make the postinst / init scripts more robust to the
failure mode where an imap-server is already running / listed in
inetd.conf.

Ed

p.s. thanks to Fabio Tranchitella for his help in this matter with
respect to the dovecot-imapd package, and relevant Debian Policy, in bug
324480.


[1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts


signature.asc
Description: Digital signature

Re: WebSVN of svn.debian.org uses wrong encoding

[W. Borgert]

Quoting Frans Pop <[EMAIL PROTECTED]>:
> For that you should enable the svn keyword "Id" (using 'svn propset
> svn:keywords Id') and add a comment in your English files containing
> "$Id:".

I will do that, thanks for the hint!
(However, my original plea for using UTF-8 in WebSVN remains.)

Cheers, WB


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

Re: Unnecessary "Conflicts" with imap-server packages

[Ondrej Sury]

On Tue, 2005-08-23 at 12:32 +0100, Edward wrote:
> My humbly proposed fix: remove the "Conflicts: imap-server" from these
> packages, and make the postinst / init scripts more robust to the
> failure mode where an imap-server is already running / listed in
> inetd.conf.

Why not do dpkg -i --force-depends .deb for short time before
transition is finished?  (P.S.: I know that it *breaks* apt)

O.
-- 
Ondrej Sury <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: Using buildds only (was: Results of the meeting...)

[Wouter Verhelst]

On Tue, Aug 23, 2005 at 11:25:41AM +0200, Marc Haber wrote:
> On Tue, 23 Aug 2005 01:42:18 +0200, Martin Pitt <[EMAIL PROTECTED]>
> wrote:
> >Something like this is in fact considered. Probably Ubuntu won't use
> >pbuilder itself since it is not the most efficient implementation
> >around, but rebuilding the buildd chroots from scratch would help to
> >eliminate many FTBFS bugs due to polluted chroots.
> 
> Surely you are aware how much time it takes to rebuild a chroot on
> slower architectures. Some technology able to restore a large
> directory tree to a static default in short time should be used here.
> 
> I am not sure whether LVM (have a LV with the master chroot image,
> make a snapshot, build inside the snapshot, remove the snapshot) could
> help here.

Then you'd have to keep the master chroot image up-to-date. If you don't
do that, after a while the master image will digress too much from the
actual Debian archive, and you end up with spending loads of cpu time
upgrading the same packages over and over again after each build.

I've been told the amd64 people have implemented something similar in
the past, but I'm not sure I like that approach.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

update of (several) config files

[Tomas Davidek]

Hello,
 I am trying to set up a tool for easy update of several computers in 
our institute. For example, I would like to create a package that 
updates several config files, e.g. /etc/apt/sources.list etc.

What is the best way of doing that ?

So far I think about an package that only contains a pre-install, 
post-install, pre-remove and post-remove scripts. These scripts would 
then add/remove certain lines from the config files and run updates. Is 
this the right way or is there better way how to proceed ?


Thanks a lot,

best regards

  Tomas

E-mail : [EMAIL PROTECTED],
  [EMAIL PROTECTED]


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

Re: Team have veto rights, because they can just refuse the work anyway?

[Gustavo Noronha Silva]

Em Seg, 2005-08-22 às 10:07 -0500, Manoj Srivastava escreveu:
> On Sun, 21 Aug 2005 23:29:51 +0200, Petter Reinholdtsen <[EMAIL PROTECTED]> 
> said: 
> The constitution states that no developer can have "democratic
>  control" imposed on them at all. Indeed, I reject any such control
>  over anything I do for Debian. Feel free to ask me to be replaced.

The constitution also states that no developer can work actively against
the implementation of such a decision made by the project[0]. Not doing
the work and not letting anyone else do it would constitute 'working
actively againt'.

I don't think that's a reason to ask that you be replaced; you haven't
done such a thing. I do reject such a control over what I do for Debian,
also, btw.

See ya,

[0]: Nothing in this constitution imposes an obligation on anyone to do
work for the Project. A person who does not want to do a task which has
been delegated or assigned to them does not need to do it. However, they
must not actively work against these rules and decisions properly made
under them. -- http://www.nl.debian.org/devel/constitution.en.html

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:    *  



signature.asc
Description: This is a digitally signed message part

Re: Unnecessary "Conflicts" with imap-server packages

[Gerrit Pape]

On Tue, Aug 23, 2005 at 12:32:15PM +0100, Edward wrote:
> Is it necessary for the following packages to "Conflict" with the
> virtual package "imap-server":
> 
>   bincimap-run
>   courier-imap
>   cyrus-imapd(*)
>   cyrus21-imapd  (*)
>   dovecot-imapd
>   mailutils-imap4d   (*)
>   uw-imapd   (*)
> 
> For example, I recently moved from "uw-imapd" to "dovecot-imapd", but
> found it difficult to setup a testing environment where both IMAP
> daemons were installed, as uw-imapd conflicted with imap-server, which
> was provided by dovecot-imapd.
> 
> Such testing is obviously necessary and it would be good if there was a
> way in which it could be more easily supported!

$ sed -ne '19,$p' , Fri, 17 Oct 2003 07:45:52 +
$ 

Regards, Gerrit.


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

Re: vancouver revisited

[Wouter Verhelst]

On Tue, Aug 23, 2005 at 02:48:58AM -0700, Steve Langasek wrote:
> On Tue, Aug 23, 2005 at 11:21:00AM +0200, Wouter Verhelst wrote:
> > I'd much rather have seen that point go, but that didn't happen.
> 
> Meaning you would have preferred that there not be a requirement of buildd
> redundancy, or you would have preferred that there not be a limit on the
> number of buildds needed to keep up?

The latter.

As said, there was a lot of discussion about this very point at our
meeting. While I understand the arguments that were given against having
more build daemons (and cannot say that they were entirely invalid), I
still think this requirement isn't necessary.

But, well.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: vancouver revisited

[Riku Voipio]

Hi Joey,

Your response was very much what I needed to hear. I'll have to retract
most of my worries.

On Mon, Aug 22, 2005 at 07:20:07PM -0400, Joey Hess wrote:
>  - A personal interest shared by me, tbm, and taggart is to get Debian
>working on the various types of cheap mips wireless access points that
>are now available in the < $100 price range, many of which now sport a
>usb interface, so should be able to run a real Debian system. I imagine
>it will be useful to have preinstalled images to load into the flash
>and/or a USB drive, but that users will also find it useful to install
>Debian on these from scratch using an installer they are comfortable
>with from installing their PCs.

I've tired using Debian on nfsroot/nbd on a Linksys wap54g. Unfortunatly 
I ran out of ram often, and swapping over nfs patches have disappeared 
into the time, while swapping over NBD gained some serious lockups.. 
An usb-slot seems to be necessary with current memory requirements of
a fully featured distribution.

As for using d-i, how do you envision it to happen in practice? Even
getting a serial port requires soldering.. One way I see would be
using fully automatic installs. A more nice way would be to be able to
"cross-install" into creating preinstallable images on a faster host
systems.

> For what it's worth, when I look at the set of issues[1] that are blocking
> us from releasing a new version of the installer right now, I see lots
> to suggest that d-i will not be releasing again with support for all
> Debian architectures anytime soon. Most of the issues are in the areas
> of kernel, toolchain, and other basic tools, and many of them would cause
> problems for anyone attempting the sort of debootstrapping you are
> advocating.

Unfortunatly debian wiki isn't talking to me atm, so I can't see what
issues you are referring to :-/ Toolchain issues are important, as they
affect everyone using the target, kernels are mor tricky.. Many vendors
are happy when they have one working kernel for their stuff, and then
never update it to match latest kernels.. 

Personally I would like to help on the arm stuff in debian generally, 
but I dont have arm systems here where debian-installer makes much sense
for users..

Cheers,
Riku


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

Re: More pbuilder use!

[John Hasler]

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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Unnecessary "Conflicts" with imap-server packages

[Thijs Kinkhorst]

On Tue, August 23, 2005 14:14, Gerrit Pape wrote:
> $ sed -ne '19,$p'  The bincimap-run package provides the virtual package ``imap-server'' and
> conflicts with other packages providing ``imap-server''.  This ensures
> that
> bincimap is the only service that listens on the address 0.0.0.0:993 on a
> system, and also satisfies packages that depend on a running imap service.
> The bincimap package without the bincimap-run package can be installed
> alongside other imap-server packages on a system, e.g. to provide
> different
> imap or imaps services on different addresses simultaneously.
>
>  -- Gerrit Pape <[EMAIL PROTECTED]>, Fri, 17 Oct 2003 07:45:52 +
> $

Following this paragraph, the only reason for conflicting with another
IMAP server is to make sure no conflicts occur while listening on port
993. Isn't there another way to resolve this relatively small problem
other than just disallowing multiple IMAP servers?

I'm also interested in installing multiple IMAP servers on different ports
in order to evaluate an IMAP client.


Thijs


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

Re: update of (several) config files

[W. Borgert]

Hello Tomas,

this question should better go to [EMAIL PROTECTED]

Quoting Tomas Davidek <[EMAIL PROTECTED]>:
>   I am trying to set up a tool for easy update of several computers in
> our institute. For example, I would like to create a package that
> updates several config files, e.g. /etc/apt/sources.list etc.
> What is the best way of doing that ?

It depends very much on your needs.  For simple cases look into
cfengine/cfengine2 (I do not like cfengine, but there is no
alternative).  For really cool stuff look at FAI (fully
automatic install), which has some system update features.  At
the list mentioned above you will get better information.

Cheers, WB


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

Re: update of (several) config files

[martin f krafft]

also sprach Tomas Davidek <[EMAIL PROTECTED]> [2005.08.23.1401 +0200]:
>  I am trying to set up a tool for easy update of several computers in 
> our institute. For example, I would like to create a package that 
> updates several config files, e.g. /etc/apt/sources.list etc.
> What is the best way of doing that ?

It's a notoriously bad idea, but check dpsyco. Or cfengine2,
especially with respect to Steve's recent docs:

  http://blog.steve.org.uk/index.php/archives/2005/08/23/cfengine-explained/

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"prisons are built with stones of law,
 brothels with bricks of religion."
  -- william blake


signature.asc
Description: Digital signature (GPG/PGP)

Re: Snapshot/Rollback using LVM/EVMS

[Pavel Orehov]

Sorry


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

Re: Using buildds only (was: Results of the meeting...)

[Stephen Frost]

* Wouter Verhelst ([EMAIL PROTECTED]) wrote:
> On Tue, Aug 23, 2005 at 09:32:33AM +0200, Martin Pitt wrote:
> > It doesn't really hurt us right now, so we didn't start to force
> > building packages in pbuilder. buildd time is cheap compared to
> > developer time, so introducing mandatory pbuilding would slow down
> > development quite drastically. 
> 
> I guess this is where Debian and Ubuntu differ. Granted, buildd time is
> cheaper than developer time, but then we don't have the hardware to
> rebuild all of our archive in a few days, like you guys do :-)

Sure we do, for certain ports (ie: amd64).  Really, this just means it'd
be better to implement a system along the lines of:

source upload
fastest/preferred buildd type (i386, amd64, whatever) attempts build
 --> Success
Other buildds attempt to build
 --> Fail
Package kicked back to maintainer

Enjoy,

Stephen


signature.asc
Description: Digital signature

Bug#324677: ITP: fruit -- Fruit is an UCI-only chess engine.

[Oliver Korff]

Package: wnpp
Severity: wishlist
Owner: Oliver Korff <[EMAIL PROTECTED]>


* Package name: fruit
  Version : 2.1 
  Upstream Author : Fabien Letouzey 
* URL : http://wbec-ridderkerk.nl/
* License : (GPL)
  Description : Fruit is an UCI-only chess engine.

Description: Fruit is an UCI-only chess engine. Fruit is a UCI-only chess 
engine.  This distribution comes up with an opening book and 
platform-independent source code. You will need a frontend like knights toplay 
against it.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7
Locale: LANG=de, LC_CTYPE=de (charmap=locale: Cannot set LC_CTYPE to default 
locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)


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

Re: Bug#324677: ITP: fruit -- Fruit is an UCI-only chess engine.

[Ondrej Sury]

On Tue, 2005-08-23 at 14:49 +0200, Oliver Korff wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Oliver Korff <[EMAIL PROTECTED]>
> 
> 
> * Package name: fruit
>   Version : 2.1 
>   Upstream Author : Fabien Letouzey 
> * URL : http://wbec-ridderkerk.nl/
> * License : (GPL)
>   Description : Fruit is an UCI-only chess engine.
> Description: Fruit is an UCI-only chess engine. Fruit is a UCI-only
> chess engine.  This distribution comes up with an opening book and
> platform-independent source code. You will need a frontend like
> knights toplay against it.

Sorry, but could you try to be more descriptive about what it does and
what it is good for?  You can explain what UCI-only mean.

Also short description should not contain name of program.

And since 'fruit' is very common, I would recommend renaming it to
fruit-chess-engine (I think it would be more accurate).
-- 
Ondrej Sury <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: Bug#324677: ITP: fruit -- Fruit is an UCI-only chess engine.

[Laurent Fousse]

Hi,

* Oliver Korff [Tue, Aug 23, 2005 at 02:49:34PM +0200]:
> Package: wnpp
> Severity: wishlist
> Owner: Oliver Korff <[EMAIL PROTECTED]>
> 
> 
> * Package name: fruit
>   Version : 2.1 
>   Upstream Author : Fabien Letouzey 
> * URL : http://wbec-ridderkerk.nl/
> * License : (GPL)
>   Description : Fruit is an UCI-only chess engine.

UCI-only chess engine would be a better short synopsis, according the
developer reference.

> Description: Fruit is an UCI-only chess engine. Fruit is a UCI-only
> chess engine.  This distribution comes up with an opening book and
> platform-independent source code. You will need a frontend like
> knights toplay against it.

The fact it is platform-independent is quite irrelevant in the long
description.

Cheers,

Laurent.


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

Re: Using buildds only (was: Results of the meeting...)

[Wouter Verhelst]

On Tue, Aug 23, 2005 at 09:14:28AM -0400, Stephen Frost wrote:
> * Wouter Verhelst ([EMAIL PROTECTED]) wrote:
> > On Tue, Aug 23, 2005 at 09:32:33AM +0200, Martin Pitt wrote:
> > > It doesn't really hurt us right now, so we didn't start to force
> > > building packages in pbuilder. buildd time is cheap compared to
> > > developer time, so introducing mandatory pbuilding would slow down
> > > development quite drastically. 
> > 
> > I guess this is where Debian and Ubuntu differ. Granted, buildd time is
> > cheaper than developer time, but then we don't have the hardware to
> > rebuild all of our archive in a few days, like you guys do :-)
> 
> Sure we do, for certain ports (ie: amd64).  Really, this just means it'd
> be better to implement a system along the lines of:
> 
> source upload
> fastest/preferred buildd type (i386, amd64, whatever) attempts build
>  --> Success
> Other buildds attempt to build

That would introduce some delay which, though generally probably not
even noticeable, would become a problem if there's an issue with the
"preferred" buildd (such as things being broken and the maintainer on a
day trip, which isn't all that uncommon)

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: Using buildds only (was: Results of the meeting...)

[Stephen Frost]

* Wouter Verhelst ([EMAIL PROTECTED]) wrote:
> On Tue, Aug 23, 2005 at 09:14:28AM -0400, Stephen Frost wrote:
> > Sure we do, for certain ports (ie: amd64).  Really, this just means it'd
> > be better to implement a system along the lines of:
> > 
> > source upload
> > fastest/preferred buildd type (i386, amd64, whatever) attempts build
> >  --> Success
> > Other buildds attempt to build
> 
> That would introduce some delay which, though generally probably not
> even noticeable, would become a problem if there's an issue with the
> "preferred" buildd (such as things being broken and the maintainer on a
> day trip, which isn't all that uncommon)

I wasn't thinking a specific/single buildd, but a "preferred"
architecture, which would have multiple buildds to hopefully alliviate
problems with one going down.  An interesting alternative would be to
have two sets of archs- tier-1 and tier-2, say, where tier-1's build
right away and tier-2's don't try unless some tier-1 succeeded (or
perhaps require that they all succeeded, but that might be excessive).

The delay argument just doesn't fly with me, honestly.  We still only
push out to mirrors once a day anyway, no?  Not to mention that it's
unstable, yadda, yadda.

Stephen


signature.asc
Description: Digital signature

Re: Bug#324677: ITP: fruit -- Fruit is an UCI-only chess engine.

[Steinar H. Gunderson]

On Tue, Aug 23, 2005 at 02:49:34PM +0200, Oliver Korff wrote:
> * URL : http://wbec-ridderkerk.nl/

This URL does not mention anything about “fruit” at all; it seems to be a
chess tournament for computers or something along those lines.

>   Description : Fruit is an UCI-only chess engine.

What does UCI-only mean?

> Description: Fruit is an UCI-only chess engine. Fruit is a UCI-only chess 
> engine.

Why the repetition?

> This distribution comes up with an opening book and platform-independent
> source code. You will need a frontend like knights toplay against it.

What sets it apart from other chess engines in Debian, such as gnuchess or
phalanx? (Or crafty, for that matter, but crafty is in non-free.)

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: Unnecessary "Conflicts" with imap-server packages

[Hamish Moffatt]

On Tue, Aug 23, 2005 at 12:14:33PM +, Gerrit Pape wrote:
> $ sed -ne '19,$p'  The bincimap-run package provides the virtual package ``imap-server'' and
> conflicts with other packages providing ``imap-server''.  This ensures that
> bincimap is the only service that listens on the address 0.0.0.0:993 on a
> system, and also satisfies packages that depend on a running imap service.

There aren't any packages that depend on imap-server (in main),
which is not surprising because any such package should be able to use
a remote server. (A few packages do suggest it though.)

> The bincimap package without the bincimap-run package can be installed
> alongside other imap-server packages on a system, e.g. to provide different
> imap or imaps services on different addresses simultaneously.

There must be a better way; apache doesn't conflict with other httpds!


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: Bug#323855: ITP: opencvs -- OpenBSD CVS implementation withspecialemphasis in security

[Gunnar Wolf]

Thomas Bushnell BSG dijo [Mon, Aug 22, 2005 at 10:02:18PM -0700]:
> > The OBSD crowd have reimplemented many important subsystems because
> > they do not consider GPL-like licenses to be free enough. Yes, also
> > because of technical reasons, but in this case it seems to be about
> > (their version of) freedom.
> 
> This would be an explanation if they had an ongoing project to
> reimplement all the tools which do not meet their licensing
> standards.  Do they have such a project?

They do - They have replaced important parts of their system which
were GPLed or under other non-BSD licenses (the first and most obvious
example is OpenSSH, but there are many others, as simple as their own
implementation of compress/gzip). Take a look at the
OBSD policies [1] - I quote a bit:

   The GNU Public License and licenses modeled on it impose the
   restriction that source code must be distributed or made available
   for all works that are derivatives of the GNU copyrighted code.

   While this may be a noble strategy in terms of software sharing, it
   is a condition that is typically unacceptable for commercial use of
   software. As a consequence, software bound by the GPL terms can not
   be included in the kernel or "runtime" of OpenBSD, though software
   subject to GPL terms may be included as development tools or as
   part of the system that are "optional" as long as such use does not
   result in OpenBSD as a whole becoming subject to the GPL terms. 

> And why should Debian be concerned one way or the other?

If they provide any added value, any better code, we should import it
into Debian. If they just provide the same but in a different way, why
bother? 

> Anyhow, if something comes of this project, Debian will probably need
> to include the package, but we will also have to make sure it doesn't
> get called "cvs" (since it is going to have a different interface),
> and we'll have to do extra integration work.  Joy.

Completely AOL.

Greeetings,

[1] http://www.openbsd.org/policy.html

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Re: More pbuilder use!

[Bastian Blank]

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


signature.asc
Description: Digital signature

Re: More pbuilder use!

[Humberto Massa Guimarães]

** 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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#324677: ITP: fruit -- Fruit is an UCI-only chess engine.

[Oliver Korff]

Thanks for all the good advice, I will be more descriptive with the "short" 
and "long" description, as I see that this is really necessary. 

And I will be more careful while using reportbug, because I don't want to 
bother people with ""Fruit is ..., Fruit is ..., Fruit is..." -- sorry

Where I don't agree is changing the package name.  fruit is the name of the 
original package and I don't  see the point in changing that. We have 
"orange, plum and apple2" in debian and nobody complains, because fruits ;) 
are not to be mixed up with real fruits in computer language.

Thanks again for taking care,

oliver

P.S.: knights is in sid, and I have a package ready for polyglot, which you 
can use to connect xboard and scid
-- 
-
credativ GmbH   Tel.:  +49 (2461) 69071-0
Karl-Heinz-Beckurts-Str. 13 Fax:   +49 (2461) 69071-1
D-52428 Jülich www:   http://www.credativ.de
-   -
"Step 9: Print a few more Pages to see if the problem correct
itself" HP9000 Users Manual
-

Re: More pbuilder use!

[Bastian Blank]

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


signature.asc
Description: Digital signature

Re: WebSVN of svn.debian.org uses wrong encoding

[Bastian Blank]

On Tue, Aug 23, 2005 at 11:29:10AM +0200, Frans Pop wrote:
> WebSVN does not know about the contents of files in the repository period. 
> As it is just a frontend to svn, you cannot expect it to know about every 
> weird file format and encoding around.

Subversion is encoding-clean, the frontend just provides it in the
encoding the user requests.

Bastian

-- 
... bacteriological warfare ... hard to believe we were once foolish
enough to play around with that.
-- McCoy, "The Omega Glory", stardate unknown


signature.asc
Description: Digital signature

Re: Will the amd64 port be rejected because of the 98% rule?

[Joe Smith]

"Pierre Habouzit" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]



Human error, or poluted chroot/compilation env is more likely to happen
on the developper machine than in a buildd. Maybe this has already been
discussed once, but I think that binary uploaded packages (except the
binary NMU's which are quite an exception) should be tagged as
"uploaded" (in opposition with "build by buildd" aka "built"), and
should be queued in the buildd's with a very low prioirity so that it
won't hurt the current flow of packages, but would detect some FTBFS
early.


I planned to offer a very similar proposal.
My suggestion was to allow Source-only, but have it revokable per-user to 
cover cases of abuse (developer keeps uploading broken packages, especially 
if they are libraries).
Have the prefered method of upload be source+1 uploaded binary. The uploaded 
build ensures that the package is available immediately (for at least one 
arch).
all uploaded binaries would be placed in the buildd queue at a very low 
priority, probably the lowest priority. This would ensure that the backage 
does build correctly on a clean system. IFF the build on the buildd succedes 
the binary package coukl perhaps be replaced with the one from the buildd. 
(This is likely one of the more controversial points, so I leave it up to 
discussion should anybody even consider implementing this.) 




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

Re: More pbuilder use!

[Roger Leigh]

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:
> > 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.

Not a kernel feature, but see

  http://packages.debian.org/unstable/admin/schroot

(or check out

  http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/schroot/?cvsroot=buildd-tools)

I have patches to make sbuild use schroot for building.

  
http://lists.alioth.debian.org/pipermail/buildd-tools-devel/2005-July/63.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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: More pbuilder use!

[Piotr Roszatycki]

On Tuesday 23 of August 2005 17:28, Bastian Blank wrote:
> 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.

Use fakechroot. Yes, it is ugly hack, but it allows me to recompile the 
packages without root privileges.

-- 
 .''`.Piotr Roszatycki, Netia SA
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
  `-

Re: Team have veto rights, because they can just refuse the work anyway?

[Thomas Bushnell BSG]

Gustavo Noronha Silva <[EMAIL PROTECTED]> writes:

> The constitution also states that no developer can work actively against
> the implementation of such a decision made by the project[0]. Not doing
> the work and not letting anyone else do it would constitute 'working
> actively againt'.

Quite the contrary; it seems to me that this is to work *passively*
against something.


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

Re: Team have veto rights, because they can just refuse the work anyway?

[Petter Reinholdtsen]

[Thomas Bushnell]
> Quite the contrary; it seems to me that this is to work *passively*
> against something.

Not doing the work is working passively against it, while prohibiting
others from doing the work is working actively against it.  If you do
both, you are working actively against it.


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

Re: More pbuilder use!

[Humberto Massa Guimarães]

** 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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Team have veto rights, because they can just refuse the work anyway?

[Thomas Bushnell BSG]

Petter Reinholdtsen <[EMAIL PROTECTED]> writes:

> [Thomas Bushnell]
>> Quite the contrary; it seems to me that this is to work *passively*
>> against something.
>
> Not doing the work is working passively against it, while prohibiting
> others from doing the work is working actively against it.  If you do
> both, you are working actively against it.

I don't know how you can prohibit others from doing the work.  The DPL
simply gives them the bits, and they can simply start doing it.

Thomas


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

Re: vancouver revisited

[Gustavo Noronha Silva]

Em Seg, 2005-08-22 às 00:34 +0300, Riku Voipio escreveu:
> jffs2 image,  which is then flashed to a pile of devices. Walking 
> through d-i every time would be very clumsy, so there is no use
> for a working installer for those systems.

There's no use for a full-blown stable release for such things, most of
the times, either.

See ya,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:    *  



signature.asc
Description: This is a digitally signed message part

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Thomas Bushnell BSG]

Olaf van der Spek <[EMAIL PROTECTED]> writes:

> On 8/23/05, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>> Roger Leigh <[EMAIL PROTECTED]> writes:
>> 
>> > Andreas Jochens in particular did a lot of hard work in fixing most of
>> > the GCC 4.0 failures and regressions over the last year while porting
>> > for amd64.  The fact that many maintainers have not yet applied, or at
>> > least carefully reviewed and applied amended patches, is a pity.
>> 
>> The reason I didn't was that I didn't want to make potentially
>> destabilizing changes with sarge in progress.
>
> Sarge was released more than two months ago. Why didn't you do it in
> the meantime (just curious and wondering)?

Because I started teaching in earnest; this is a very busy time for me
until late September.


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

Re: how to fully replace another package

[Gustavo Noronha Silva]

Em Seg, 2005-08-22 às 01:32 +0200, Marco d'Itri escreveu:
> The (still not uploaded) coldplug package conflicts+depends+provides
> hotplug. The issue is that since all the important parts of hotplug are
> conffiles they are not deleted when the package is removed, and this
> is bad (as in "the system will probably not boot" bad).

I can't understand why that would be the case; could you please
elaborate?

> Does a way to force purging the package exist?
> Is there anything else I can do, other than deleting the files in the
> hotplug postinst?

I think you should simply not be going that way; the conffiles are to
remain, you should not be touching them. I think I'd go for a 'move them
aside to some kind of backup place and warn the admin by email (debconf
note)'.

Understanding why you need to do this would be very important on trying
to give you advice on what to do, anyway, I think.

See ya,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:    *  



signature.asc
Description: This is a digitally signed message part

Re: Is dpkg --compare-versions canonical?

[martin f krafft]

also sprach Russ Allbery <[EMAIL PROTECTED]> [2005.08.23.1908 +0200]:
> case, I wanted to double-check and be sure that dpkg --compare-versions is
> the canonical ordering for version numbers.  I'm pretty sure it is, but
> better safe than sorry to check.

Yes.

> Is there a document anywhere outside of the dpkg source that explains the
> algorithm for how version numbers are ordered by the archive software?

http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
micro$oft: "you've got questions? we've got dancing paperclips."


signature.asc
Description: Digital signature (GPG/PGP)

Re: how to fully replace another package

[Marco d'Itri]

On Aug 23, Gustavo Noronha Silva <[EMAIL PROTECTED]> wrote:

> > The (still not uploaded) coldplug package conflicts+depends+provides
> > hotplug. The issue is that since all the important parts of hotplug are
> > conffiles they are not deleted when the package is removed, and this
> > is bad (as in "the system will probably not boot" bad).
> I can't understand why that would be the case; could you please
> elaborate?
Think "hotplug events loop".

> I think you should simply not be going that way; the conffiles are to
> remain, you should not be touching them. I think I'd go for a 'move them
> aside to some kind of backup place and warn the admin by email (debconf
> note)'.
No way, this is a waste of admins' time and most of the times would have
the effect of leaving orphaned files on systems.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: vancouver revisited

[Gustavo Noronha Silva]

Em Seg, 2005-08-22 às 19:45 +0200, Adrian von Bidder escreveu:
> On Monday 22 August 2005 11.25, Peter 'p2' De Schrijver wrote:
> 
> [ the 'must have a working installer' requirement ]
> 
> > > > Trivial. debootstrap does that.
> > >
> > > Debootstrap is not an installer, in very much the same way that tar
> > > isn't, either.
> >
> > They both are. They can install debian, so it's an installer.
> 
> This is getting silly.  I think nobody debates the fact that some CPUs never 
> had any PC-style machines made and are targetted at the embedded market - 
> yet a Debian port may still make sense.

Getting silly for sure, since the beginning. I think people should stop
acting passionately as if someone was trying to get their arches removed
from Debian and think a little bit.

We're trying to get our release process sane and that's all. Do we
really need a full release arch to support someone using a very small
subset of packages on a tar-installed not-PC-style machine targeted at
whatever market?

Can't we just decide that "this port is useful for these uses but it
makes no sense to bother the release team and increase the complexity of
the release process; the porters are in the best position to decide and
implement whatever 'release' they think is possible and useful"?

Now, stop thinking of this discussion as 'we have to support someone
wanting to install Debian on a matchbox and we need an official release
for that' or as 'someone is trying to remove my arch from Debian'.

Stop and think. Let's all try to get positive and helpful comments in;
or is everyone ok with having a release cycle just like this last one
(sarge) for etch?

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:    *  



signature.asc
Description: This is a digitally signed message part

Re: how to fully replace another package

[Ben Armstrong]

On Tue, 2005-08-23 at 19:15 +0200, Marco d'Itri wrote:
> Think "hotplug events loop".

So, a hotplug event could load and run code (which happen to be in conf
files, and therefore cannot be diverted) in the old hotplug package.
The problem you're facing, it seems, is that while code should be
divertable, conf files aren't, but hotplug doesn't separate these out,
so the usual mechanisms don't work.  Am I on the right track?

Of course, init files are code and conf files, but they have a built-in
mechanism for preventing them from running, which is to look for the
binary the init file runs, and if it isn't there, don't do anything.  It
seems you don't have any such protection built into the hotplug
conffiles-that-are-also-executables, or else you wouldn't be in this
mess.

Ben


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

Re: More pbuilder use!

[Wouter Verhelst]

On Tue, Aug 23, 2005 at 06:01:24PM +0200, Piotr Roszatycki wrote:
> On Tuesday 23 of August 2005 17:28, Bastian Blank wrote:
> > 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.
> 
> 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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: More pbuilder use!

[Wouter Verhelst]

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:
> > 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.

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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Is dpkg --compare-versions canonical?

[Russ Allbery]

dpkg --compare-versions provides exactly the ordering that I want, namely
that 1.4rc1 < 1.4.0 so by omitting the final patch number in the RC
revision I can use the correct upstream version without using epochs or
strange-looking version numbers.  However, since this is a bit of an edge
case, I wanted to double-check and be sure that dpkg --compare-versions is
the canonical ordering for version numbers.  I'm pretty sure it is, but
better safe than sorry to check.

Is there a document anywhere outside of the dpkg source that explains the
algorithm for how version numbers are ordered by the archive software?

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: How coldplug works

[Isaac Clerencia]

On Tuesday, 23 August 2005 09:57, Marco d'Itri wrote:
> On Aug 23, Isaac Clerencia <[EMAIL PROTECTED]> wrote:
> > I've just tried it and it has worked really great, except it has not
> > loaded mousedev module. Everything else has worked, and it's incredible
> > fast (at
>
> It's supposed to, do you mind investigating? Do not delete the
> generated events, etc. Try manually running the init script a second
> time too.
> I noticed that on my system the first time it's run the ehci_hcd is not
> loaded, but I have not yet found why.

Running the script manually for a second time didn't worked.
The system runs Debian Sid with coldplug 0.0, udev 0.068-2 and kernel 
2.6.12-1-686 from Sid. It's a Thinkpad T42 laptop, with a Touchpad (which 
uses psmouse module), an USB mouse (which uses mousedev) and a Radeon card.

I attach the list of modules loaded with coldplug and hotplug, and a diff 
between the ordered lists.

The main differences are that coldplug enables de framebuffer by loading 
"radeonfb" while hotplug only uses "radeon", and that coldplug doesn't load 
neither psmouse nor mousedev. Both load successfully the e1000 driver 
(ethernet card) and ipw2200 driver (wireless card).

Best regards

-- 
Isaac Clerencia at Warp Networks, http://www.warp.es
Work: <[EMAIL PROTECTED]>   | Debian: <[EMAIL PROTECTED]>


pgpMpq0IV2Xy1.pgp
Description: PGP signature
Module  Size  Used by
radeon 80576  0 
drm68340  1 radeon
rfcomm 41052  3 
l2cap  25604  5 rfcomm
bluetooth  50148  4 rfcomm,l2cap
ipv6  262880  12 
parport_pc 36772  1 
lp 12228  0 
parport37128  2 parport_pc,lp
thermal13288  0 
fan 4580  0 
button  6480  0 
processor  22100  1 thermal
ac  4676  0 
battery 9412  0 
pcmcia 27176  4 
usbhid 36576  0 
af_packet  22248  0 
shpchp 99716  0 
pci_hotplug28628  1 shpchp
tpm_atmel   4864  0 
intel_agp  24156  1 
agpgart35688  2 drm,intel_agp
snd_intel8x0m  19588  0 
snd_ac97_codec 84120  1 snd_intel8x0m
snd_pcm93608  2 snd_intel8x0m,snd_ac97_codec
i2c_i8018780  0 
radeonfb   94208  1 
snd_timer  24676  1 snd_pcm
snd56580  4 snd_intel8x0m,snd_ac97_codec,snd_pcm,snd_timer
snd_page_alloc  9956  2 snd_intel8x0m,snd_pcm
i2c_algo_bit9640  1 radeonfb
i2c_core   21840  3 i2c_i801,radeonfb,i2c_algo_bit
tpm_nsc 6656  0 
tpm10496  2 tpm_atmel,tpm_nsc
yenta_socket   23592  2 
rsrc_nonstatic 13792  1 yenta_socket
pcmcia_core52084  3 pcmcia,yenta_socket,rsrc_nonstatic
ehci_hcd   35432  0 
uhci_hcd   32208  0 
usbcore   122588  4 usbhid,ehci_hcd,uhci_hcd
i810_audio 37076  0 
ac97_codec 20172  1 i810_audio
soundcore   9760  2 snd,i810_audio
ipw2200   186984  0 
firmware_class 10208  1 ipw2200
ieee80211  52100  1 ipw2200
ieee80211_crypt 5988  2 ipw2200,ieee80211
e1000 106740  0 
dm_mod 60796  0 
ide_cd 43236  0 
cdrom  40672  1 ide_cd
ext3  142120  7 
jbd56984  1 ext3
mbcache 9316  1 ext3
ide_disk   18752  9 
ide_generic 1216  0 [permanent]
via82cxxx  13884  0 [permanent]
trm290  4260  0 [permanent]
triflex 3712  0 [permanent]
slc90e665728  0 [permanent]
sis551316552  0 [permanent]
siimage12480  0 [permanent]
serverworks 9096  0 [permanent]
sc1200  7360  0 [permanent]
rz1000  2464  0 [permanent]
piix   10372  0 [permanent]
pdc202xx_old   11232  0 [permanent]
opti621 4388  0 [permanent]
ns87415 4296  0 [permanent]
hpt366 20448  0 [permanent]
hpt34x  5184  0 [permanent]
generic 3840  0 [permanent]
cy82c6934740  0 [permanent]
cs5530  5376  0 [permanent]
cs5520  4608  0 [permanent]
cmd64x 11964  0 [permanent]
atiixp  5936  0 [permanent]
amd74xx14428  0 [permanent]
alim15x3   12332  0 [permanent]
aec62xx 7392  0 [permanent]
pdc202xx_new9312  0 [permanent]
ide_core  130708  28 
ide_cd,ide_disk,ide_generic,via82cxxx,trm290,triflex,slc90e66,sis5513,siimage,serverworks,sc1200,rz1000,piix,pdc202xx_old,opti621,ns87415,hpt366,hpt34x,generic,cy82c693,cs5530,cs5520,cmd6

Bug#324730: ITP: libperldoc-search-perl -- Index and search local Perl documentation

[Florian Ragwitz]

Package: wnpp
Severity: wishlist
Owner: Florian Ragwitz <[EMAIL PROTECTED]>

* Package name: libperldoc-search-perl
  Version : 0.01
  Upstream Author : Mike Schilli <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~mschilli/Perldoc-Search/
* License : Perl (GPL/Artistic)
  Description : Index and search local Perl documentation

Perldoc::Search uses the swish-e engine to index the local Perl
documentation. It provides both the command line utility perldig and an
API to perform searches on the index. It uses SWISH::API::Common as the
indexing and search engine.
.
This package also contains the command line utility perldig, to dig up
keywords in the local Perl documentation

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Bug#324732: ITP: libswish-api-common-perl -- Perl interface to the Swish index engine

[Florian Ragwitz]

Package: wnpp
Severity: wishlist
Owner: Florian Ragwitz <[EMAIL PROTECTED]>

* Package name: libswish-api-common-perl
  Version : 0.03
  Upstream Author : Mike Schilli <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~mschilli/SWISH-API-Common/
* License : Perl (GPL/Artistic)
  Description : Perl interface to the Swish index engine

SWISH::API::Common offers an easy interface to the Swish index engine.
While SWISH::API offers a complete API, SWISH::API::Common focusses on
ease of use.
.
Currently, SWISH::API::Common just allows for indexing documents in a
single directory and any of its subdirectories. Also, don't run index()
and search() in parallel yet.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: Is dpkg --compare-versions canonical?

[Russ Allbery]

Thanks for the confirmation!

martin f krafft <[EMAIL PROTECTED]> writes:
> also sprach Russ Allbery <[EMAIL PROTECTED]> [2005.08.23.1908 +0200]:

>> Is there a document anywhere outside of the dpkg source that explains
>> the algorithm for how version numbers are ordered by the archive
>> software?

> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

*sigh*.  I'm sorry about that; I've read that several times but thought
something more complex was going on under the hood, since it didn't seem
to explain this case.  I completely missed the following sentence:

| The lexical comparison is a comparison of ASCII values modified so that
| all the letters sort earlier than all the non-letters.

which does indeed entirely explain why "rc" sorts before ".".

Thank you for the kick in the right direction!

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Will the amd64 port be rejected because of the 98% rule?

[Adrian von Bidder]

On Tuesday 23 August 2005 06.44, Joe Smith wrote:
> > By the way, i386 does not make the cut according to the vancouver
> > prospect due to the number of buildds required. So are we left with 0
> > archs in etch? :) That will certainly speed up the release.
>
> LOL.
>
> Release NOW! Release now, damnit!
> I think it will be our fastest and smoothest release ever.

I'm sure somebody will manage to botch the release notes or there will be 
some leftover non-empty Packages file lying around in some directory...

-- vbi



-- 
Available for key signing in Zürich and Basel, Switzerland
(what's this? Look at http://fortytwo.ch/gpg/intro)


pgpXE3WgPZWJd.pgp
Description: PGP signature

Bug#324739: ITP: libsysadm-install-perl -- Perl module to simplify typical installation tasks for system administrators

[Florian Ragwitz]

Package: wnpp
Severity: wishlist
Owner: Florian Ragwitz <[EMAIL PROTECTED]>

* Package name: libsysadm-install-perl
  Version : 0.20
  Upstream Author : Mike Schilli <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~mschilli/Sysadm-Install/
* License : Perl (GPL/Artistic)
  Description : Perl module to simplify typical installation tasks for 
system administrators

Have you ever wished for your installation shell scripts to run
reproducably, without much programming fuzz, and even with optional
logging enabled? Then give up shell programming, use Perl.
.
Sysadm::Install executes shell-like commands performing typical
installation tasks: Copying files, extracting tarballs, calling make. It
has a fail once and die policy, meticulously checking the result of
every operation and calling die() immeditatly if anything fails.
.
Sysadm::Install also supports a dry_run mode, in which it logs
everything, but suppresses any write actions.
.
Sysadm::Install is fully Log4perl-enabled. To start logging, just
initialize Log::Log4perl. Sysadm::Install acts as a wrapper class,
meaning that file names and line numbers are reported from the calling
program's point of view.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Bug#324737: ITP: libshell-posix-select-perl -- The POSIX Shell's "select" loop for Perl

[Florian Ragwitz]

Package: wnpp
Severity: wishlist
Owner: Florian Ragwitz <[EMAIL PROTECTED]>

* Package name: libshell-posix-select-perl
  Version : 0.05
  Upstream Author : Timothy F. Maher <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~yumpy/Shell-POSIX-Select-0.05/
* License : Perl (GPL/Artistic
  Description : The POSIX Shell's "select" loop for Perl

This module implements the select loop of the "POSIX" shells (Bash, Korn,
and derivatives) for Perl. That loop is unique in two ways: it's by far
the friendliest feature of any UNIX shell, and it's the only UNIX shell
loop that's missing from the Perl language. Until now!
.
What's so great about this loop? It automates the generation of a
numbered menu of choices, prompts for a choice, proofreads that choice
and complains if it's invalid (at least in this enhanced
implementation), and executes a code-block with a variable set to the
chosen value. That saves a lot of coding for interactive programs --
especially if the menu consists of many values!
.
The benefit of bringing this loop to Perl is that it obviates the need
for future programmers to reinvent the Choose-From-A-Menu wheel.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: how to fully replace another package

[Steve Langasek]

On Tue, Aug 23, 2005 at 02:09:48PM -0300, Gustavo Noronha Silva wrote:
> Em Seg, 2005-08-22 às 01:32 +0200, Marco d'Itri escreveu:
> > The (still not uploaded) coldplug package conflicts+depends+provides
> > hotplug. The issue is that since all the important parts of hotplug are
> > conffiles they are not deleted when the package is removed, and this
> > is bad (as in "the system will probably not boot" bad).

> I can't understand why that would be the case; could you please
> elaborate?

> > Does a way to force purging the package exist?
> > Is there anything else I can do, other than deleting the files in the
> > hotplug postinst?

> I think you should simply not be going that way; the conffiles are to
> remain, you should not be touching them. I think I'd go for a 'move them
> aside to some kind of backup place and warn the admin by email (debconf
> note)'.

If you do that, how do you ensure that these two cases are both handled
sanely?:

- after installing the coldplug package, the admin purges the hotplug
  package, and later reinstalls it (removing coldplug)
- after installing the coldplug package, the admin reinstalls hotplug
  (removing coldplug), expecting this to give a hotplug package with a
  working config

Since the principal reason for preserving these unmodified conffiles would
surely be so that they could be restored later, both scenarios seem
relevant.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: how to fully replace another package

[Marco d'Itri]

On Aug 23, Ben Armstrong <[EMAIL PROTECTED]> wrote:

> So, a hotplug event could load and run code (which happen to be in conf
> files, and therefore cannot be diverted) in the old hotplug package.
> The problem you're facing, it seems, is that while code should be
> divertable, conf files aren't, but hotplug doesn't separate these out,
> so the usual mechanisms don't work.  Am I on the right track?
Yes.

> Of course, init files are code and conf files, but they have a built-in
> mechanism for preventing them from running, which is to look for the
> binary the init file runs, and if it isn't there, don't do anything.  It
> seems you don't have any such protection built into the hotplug
> conffiles-that-are-also-executables, or else you wouldn't be in this
> mess.
The init file does, but /etc/hotplug.d/default/default.hotplug does not.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Adrian von Bidder]

On Monday 22 August 2005 23.51, Steve Langasek wrote:
> On Mon, Aug 22, 2005 at 06:22:11PM +, W. Borgert wrote:
> > On Mon, Aug 22, 2005 at 07:29:31PM +0200, Adrian von Bidder wrote:
> > > really matters:  can we (the Debian project) maintain the port?  Thus
> > > I propose we only limit on the number of developers:  are there
> > > people who are willing and competent to maintain kernel, boot loader,
> > > platform specific installer bits, libc and toolchain?
> >
> > That sounds sensible.
>
> It ignores the fact that every port is a drain on centralized project
> resources, whether it has users or not.

How so?

(I mean, how does my proposal to drop the 'has users' requirement in favor 
of 'do we have developers' ignore the resource usage.  I certainly do not 
dispute that a port uses resources.)

And even if:  would a userless port have the developers?  For one thing, the 
develoeprs are users themselves, and for another thing, even 'doorstop 
architectures' where 90% of the users are seriously computer infected, only 
a few of those are likely to be competent enough to maintain kernel and 
toolchain.  So I'd claim the (difficult to define) 'has users' requirement 
is not so much different from a (IMHO easier to define) 'has developers' 
requirement.

cheers
-- vbi

-- 
Beware of the FUD - know your enemies. This week
* The Alexis de Toqueville Institue *
http://fortytwo.ch/opinion/adti


pgpzaYRHf0ZFu.pgp
Description: PGP signature

Re: how to fully replace another package

[Ben Armstrong]

On Tue, 2005-08-23 at 19:50 +0200, Marco d'Itri wrote:
> The init file does, but /etc/hotplug.d/default/default.hotplug does not.

Why is this file a conffile?  I didn't see any obviously configurable
parts in it.  If it were either wholly be moved elsewhere (/sbin) or the
guts of it moved elsewhere, and only a trivial shell that calls it were
left here, would your problem be solved?  (Well, I suppose this problem
would remain: how would you guarantee upgrades were only made from fixed
versions of hotplug -> coldplug, and not older ones?)

Ben


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

Re: Team have veto rights, because they can just refuse the work anyway? (Was: Results of the meeting in Helsinki about the Vancouver proposal)

[Emanuele Rocca]

Hello David,

* David Nusinow <[EMAIL PROTECTED]>, [2005-08-21 19:44 -0400]:
>  On Sun, Aug 21, 2005 at 11:29:51PM +0200, Petter Reinholdtsen wrote:
>  > [Wouter Verhelst]
>  > >b) the three beforementioned teams could already refuse to
>  > >support a port anyhow, simply by not doing the work.
>  > 
>  > This is not really a valid argument.  If a team in debian refuses to
>  > accept decisions made by a majority of debian developers, or rejects
>  > democratic control, this team will just have to be replaced by the DPL.
>  
>  I think the reality of this situation is that a team would refuse to do the
>  work due to valid reasons. The easy ones I can imagine are the ones we've
>  heard already, such as "We don't have the people to do this" or "We don't
>  have enough time". 

I think that Petter was speaking about intentional boycott by a group of
DDs for some specific reasons. Lack of people or time is something which
is not malicious and that don't require the intervention of the DPL, but
only more contributors.

ciao,
ema


signature.asc
Description: Digital signature

Results of the meeting in Helsinki about the Vancouver proposal

[Walter Landry]

Wouter Verhelst wrote:
> "Vancouver" has gotten a very specific meaning in the Debian
> community: one of a visionary proposal[1] that received quite its
> share of flames from many Debian contributors, including
> myself. Since it appeared to many of us that the intentional result
> of this proposal would have been to essentially kill off many of our
> architectures, many of us weren't too happy with the proposal.

How about we completely scrap the proposal, and instead let the
decision be made by the DPL?  The DPL can use whatever criteria they
like to decide, although presumably they would be guided by documents
such as the Vancouver proposal.  The DPL would talk to the various
teams to get their input on whether an architecture should be
supported by Debian, but the DPL would have the final say.

The nice thing about this is that the DPL is an elected officer, and
so is directly accountable to the rest of Debian.  This tends to make
them better communicators.

Cheers,
Walter


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

Re: how to fully replace another package

[Marco d'Itri]

On Aug 23, Ben Armstrong <[EMAIL PROTECTED]> wrote:

> On Tue, 2005-08-23 at 19:50 +0200, Marco d'Itri wrote:
> > The init file does, but /etc/hotplug.d/default/default.hotplug does not.
> Why is this file a conffile?  I didn't see any obviously configurable
Historical reasons? It does not really matter, the hotplug.d/ interface
will have to be supported by udev+coldplug until udev will become
mandatory.
(When writing coldplug I moved everything to /lib/hotplug/ just in
case...)

> parts in it.  If it were either wholly be moved elsewhere (/sbin) or the
> guts of it moved elsewhere, and only a trivial shell that calls it were
> left here, would your problem be solved?  (Well, I suppose this problem
> would remain: how would you guarantee upgrades were only made from fixed
> versions of hotplug -> coldplug, and not older ones?)
Right.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: More pbuilder use!

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

"Joe Smith" <[EMAIL PROTECTED]> 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/Linuxhttp://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 

iD8DBQFDC24RVcFcaSW/uEgRAqFJAKCMD3VD41IBQXhgKLlP3O14Nn26VgCfQf3m
BBDT/v97/gGgTQ7ZukAVOYU=
=bs/I
-END PGP SIGNATURE-


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

Re: More pbuilder use!

[Bastian Blank]

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


signature.asc
Description: Digital signature

Re: Using buildds only

[Goswin von Brederlow]

Martin Pitt <[EMAIL PROTECTED]> writes:

> Hi Wouter!
>
> Wouter Verhelst [2005-08-23  1:26 +0200]:
>> On Mon, Aug 22, 2005 at 04:08:37PM +0200, Martin Pitt wrote:
>> > Hamish Moffatt [2005-08-22 23:47 +1000]:
>> > > There is the possibility that developer builds get extra features
>> > > enabled due to other installed libraries etc. This could be checked for
>> > > by analysing the packages files for different architectures or similar.
>> > 
>> > The clean way to ensure this is to build them in a clean-room
>> > environment in the first place. It would be an unnecessary effort to
>> > implement more sanity checking in katie, and it is computationally
>> > impossible to check for additional/missing features in libary code.
>> 
>> So you suggest throwing buildd out of the window and switching to
>> pbuilder, then?
>
> Something like this is in fact considered. Probably Ubuntu won't use
> pbuilder itself since it is not the most efficient implementation
> around, but rebuilding the buildd chroots from scratch would help to
> eliminate many FTBFS bugs due to polluted chroots.

What do polluted _developer_ builds have to do with any buildd
implementation?

Sure the buildds sometimes mess up their chroot and people have been
saying this for years, including me. Still the same people haven't
provided patches to make it better, including me. One big reason for
this is the extra time required to do proper cleanup and rebuild of
the chroot on slower arch.

But that has nothing to do with the initial point of polluted
_developer_ builds.

>> (in case you wonder, buildd (which Ubuntu also uses) does /not/
>> guarantee either up-to-dateness or clean chroots)
>
> For the latter, see above. For the former, lagging behind by at most
> one day (as the buildds do) is certainly acceptable. OTOH, lagging
> behind for several weeks (which is not unreasonable for folks without
> a phat pipe) is certainly not, especially if you are in a period of
> massive transitions.

Buildd never updates unless Build-Depends require it. That means the
build-essential packages will stay at their current version as long as
nothing needs newer ones specificaly. Also any left over packages stay
at their current version. Only the Build-Depends not already installed
on a buildd get installed in their current version (to within 15-30m
delay after upload, not one day) and are removed after the build
(unless that fails and leaves them).

That is usualy a good thing since it prevents buildds from installing
the latest and possibly very broken toolchain packages untill the
buildd admin decides it is save to upgrade.

> Martin

MfG
Goswin


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

Re: Using buildds only

[Tomas Fasth]

Martin Pitt skrev:
> Hi Tomas!
>
> Tomas Fasth [2005-08-23  9:31 +0200]:
>
>>As a side note, I have myself thought about extending pbuilder using
>>unionfs and overlays to avoid the tarball extraction for each build.
>
>
> Indeed I referred to the overhead of tarball extraction and the like.
> unionfs is a great idea, do you plan to integrate this into the
> main pbuilder package? This would really rock. :)

The idea came to me just recently. I have no written code or patch
for pbuilder yet, and I have barely started to familiarize myself
with unionfs in general. I would definitely like to have such a
feature in pbuilder, so yes, integration is the preferred way to go.
If I manage to produce some working code I will post a patch for
pbuilder through BTS.

--
Tomas Fasth <[EMAIL PROTECTED]>
GnuPG Fingerprint: DC7B 9453 7F26 1BF9 6B21 9F90 C187 7355 9FE8 D504



signature.asc
Description: OpenPGP digital signature

Re: Using buildds only

[Goswin von Brederlow]

Martin Pitt <[EMAIL PROTECTED]> writes:

> Hi Tomas!
>
> Tomas Fasth [2005-08-23  9:31 +0200]:
>> >>So you suggest throwing buildd out of the window and switching to
>> >>pbuilder, then?
>> >
>> >
>> > Something like this is in fact considered. Probably Ubuntu won't use
>> > pbuilder itself since it is not the most efficient implementation
>> > around, but rebuilding the buildd chroots from scratch would help to
>> > eliminate many FTBFS bugs due to polluted chroots.
>> 
>> I find your statement about pbuilder and efficiency interesting.
>> Would you care to explain what you mean?
>> 
>> As a side note, I have myself thought about extending pbuilder using
>> unionfs and overlays to avoid the tarball extraction for each build.
>
> Indeed I referred to the overhead of tarball extraction and the like.
> unionfs is a great idea, do you plan to integrate this into the
> main pbuilder package? This would really rock. :)
>
> Thanks,
>
> Martin

Lvm snapshots work very well for this.

MfG
Goswin


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

Re: Using buildds only

[Goswin von Brederlow]

Peter 'p2' De Schrijver <[EMAIL PROTECTED]> writes:

> On Tue, Aug 23, 2005 at 11:25:41AM +0200, Marc Haber wrote:
>> On Tue, 23 Aug 2005 01:42:18 +0200, Martin Pitt <[EMAIL PROTECTED]>
>> wrote:
>> >Something like this is in fact considered. Probably Ubuntu won't use
>> >pbuilder itself since it is not the most efficient implementation
>> >around, but rebuilding the buildd chroots from scratch would help to
>> >eliminate many FTBFS bugs due to polluted chroots.
>> 
>> Surely you are aware how much time it takes to rebuild a chroot on
>> slower architectures. Some technology able to restore a large
>> directory tree to a static default in short time should be used here.
>> 
>> I am not sure whether LVM (have a LV with the master chroot image,
>> make a snapshot, build inside the snapshot, remove the snapshot) could
>> help here.
>
> Or only rebuild the chroot when a build failure is detected (or better
> when a build failure is detected which could be caused by a broken
> chroot).
>
> Cheers,
>
> Peter (p2).

You probably mean when removing build-depends stops with a failure.
At that point the chroot won't be clean anymore and often is very
broken on subsequent builds.

MfG
Goswin


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

Re: Using buildds only

[Goswin von Brederlow]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Tue, Aug 23, 2005 at 11:25:41AM +0200, Marc Haber wrote:
>> On Tue, 23 Aug 2005 01:42:18 +0200, Martin Pitt <[EMAIL PROTECTED]>
>> wrote:
>> >Something like this is in fact considered. Probably Ubuntu won't use
>> >pbuilder itself since it is not the most efficient implementation
>> >around, but rebuilding the buildd chroots from scratch would help to
>> >eliminate many FTBFS bugs due to polluted chroots.
>> 
>> Surely you are aware how much time it takes to rebuild a chroot on
>> slower architectures. Some technology able to restore a large
>> directory tree to a static default in short time should be used here.
>> 
>> I am not sure whether LVM (have a LV with the master chroot image,
>> make a snapshot, build inside the snapshot, remove the snapshot) could
>> help here.
>
> Then you'd have to keep the master chroot image up-to-date. If you don't
> do that, after a while the master image will digress too much from the
> actual Debian archive, and you end up with spending loads of cpu time
> upgrading the same packages over and over again after each build.

You have to keep the chroot up-to-date manualy anyway as sbuild does
not upgrade unless a Build-Depends requires a newer version
specificaly.

> I've been told the amd64 people have implemented something similar in
> the past, but I'm not sure I like that approach.

I've even gone so far to automate upgrading the master image by first
upgrading a snapshot, then testbuilding a smaller package and only on
success do the same to the master.

A simple "touch UPGRADE-MASTER" will perform this automaticaly after
the current build finishes. Very helpfull thing.

MfG
Goswin


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

Re: Using buildds only

[Goswin von Brederlow]

Marc Haber <[EMAIL PROTECTED]> writes:

> On Tue, 23 Aug 2005 01:42:18 +0200, Martin Pitt <[EMAIL PROTECTED]>
> wrote:
>>Something like this is in fact considered. Probably Ubuntu won't use
>>pbuilder itself since it is not the most efficient implementation
>>around, but rebuilding the buildd chroots from scratch would help to
>>eliminate many FTBFS bugs due to polluted chroots.
>
> Surely you are aware how much time it takes to rebuild a chroot on
> slower architectures. Some technology able to restore a large
> directory tree to a static default in short time should be used here.
>
> I am not sure whether LVM (have a LV with the master chroot image,
> make a snapshot, build inside the snapshot, remove the snapshot) could
> help here.
>
> Greetings
> Marc

LVM helps a lot in that it saves the time to 'rm -rf chroot; tar -xjf
chroot.tar.bz2'.

The biggest problem is in removing any processes left after a build so
the snapshot can be umounted and removed. As long as there is no fork
bomb running one can simply go through /proc/*/root and to find them
all.


An even bigger advantage is leaving build snapshots around on a FTBFS
so someone can take a look at them without interfering with subsequent
builds. I name each snapshot by the package that will be build. On
failure I can chroot into the snapshot and meddle around while the
buildd can hapily build the next package in its own snapshot. No
packages getting installed or removed randomly by the buildd while you
investigate.

MfG
Goswin


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

Re: Using buildds only

[Goswin von Brederlow]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Tue, Aug 23, 2005 at 09:14:28AM -0400, Stephen Frost wrote:
>> source upload
>> fastest/preferred buildd type (i386, amd64, whatever) attempts build
>>  --> Success
>> Other buildds attempt to build
>
> That would introduce some delay which, though generally probably not
> even noticeable, would become a problem if there's an issue with the
> "preferred" buildd (such as things being broken and the maintainer on a
> day trip, which isn't all that uncommon)

source upload

all wanna-build pick it up

fast buildds build and fail

wanna-build updates, sees 3 build failures, moves the package to the
end of the build queue

slow buildds come around to request a new package but won't get the
broken one (unless idle)


I said it in the past, the number of build failures accross all archs
should be considered in the queue order. Prioritize on packages that
do build.

MfG
Goswin


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

Re: More pbuilder use!

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bastian Blank <[EMAIL PROTECTED]> writes:

> 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.

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/Linuxhttp://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 

iD8DBQFDC4NYVcFcaSW/uEgRAnSAAKCKdscIjxyrTl3cOVOEPX/BdI7GlACgg5xo
pYpCULVsUC42xO0rOqcYmA0=
=ObRb
-END PGP SIGNATURE-


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

Re: More pbuilder use!

[Paul TBBle Hampson]

On Tue, Aug 23, 2005 at 01:52:22PM -0300, Humberto Massa Guimarães wrote:
> ** Bastian Blank ::

>> You have a linux kernel ready, which allows chroot as normal user?
>> Please share it with us.
> 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)
[EMAIL PROTECTED]

"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/
---


pgpilvcCxIN5h.pgp
Description: PGP signature

Re: Will the amd64 port be rejected because of the 98% rule?

[Goswin von Brederlow]

"Joe Smith" <[EMAIL PROTECTED]> writes:

> "Pierre Habouzit" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>>Human error, or poluted chroot/compilation env is more likely to happen
>>on the developper machine than in a buildd. Maybe this has already been

Also for each upload we have 10 archs with the risk of buildd polluted
packages and one without? How does that help at all?

You reduce one risk by eliminating it from <10% of the uploads and
introduce a completly new and different risk on those 10%. No matter
how you look at it that is just silly.

>>discussed once, but I think that binary uploaded packages (except the
>>binary NMU's which are quite an exception) should be tagged as
>>"uploaded" (in opposition with "build by buildd" aka "built"), and
>>should be queued in the buildd's with a very low prioirity so that it
>>won't hurt the current flow of packages, but would detect some FTBFS
>>early.
>
> I planned to offer a very similar proposal.
> My suggestion was to allow Source-only, but have it revokable per-user
> to cover cases of abuse (developer keeps uploading broken packages,
> especially if they are libraries).
> Have the prefered method of upload be source+1 uploaded binary. The
> uploaded build ensures that the package is available immediately (for
> at least one arch).
> all uploaded binaries would be placed in the buildd queue at a very
> low priority, probably the lowest priority. This would ensure that the
> backage does build correctly on a clean system. IFF the build on the
> buildd succedes the binary package coukl perhaps be replaced with the
> one from the buildd. (This is likely one of the more controversial
> points, so I leave it up to discussion should anybody even consider
> implementing this.)

If you replace the debs then the uploaded changes file (which gets
send out to the ML and is the only one publicaly archived by debian)
don't match the debs in the archive.

If you want to go the way of rebuilding debs then require seperate
changes files.

MfG
Goswin


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