Re: Bug#403979: ITP: gpe-gallery -- GPE image gallery and viewer, with slideshow support

[Neil Williams]

On Thu, 21 Dec 2006 07:22:50 +0100 (CET)
Andreas Tille <[EMAIL PROTECTED]> wrote:

> On Thu, 21 Dec 2006, Neil Williams wrote:
>
> >  Description : GPE image gallery and viewer, with slideshow support
> > A small application for viewing images in GPE. Intended to show
> > small and medium sized images and is able to display a slide
> > show and to perform several simple operations with the images.

Description: GPE image gallery and viewer with slideshow support
An image viewer for the GPE Palmtop Environment. Intended to show small
and medium sized images as icons or as a slideshow, gpe-gallery also
performs some simple operations with the images.

> Sorry, what is GPE?
> Yes, I'm sure Google would be my friend for this question but package
> descriptions should not require other resources to be understandable
> for the user.

Agreed. Hope the above replacement is clearer.

--


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpxgVOi5EVmb.pgp
Description: PGP signature

Re: block device served over network connections

[Warren Turkal]

On Wednesday 20 December 2006 17:29, Ron Johnson wrote:
> Roll a custom kernel that either statically links the modules, or
> loads them in your preferred order?

I don't see how this helps me bring up the network at the right time. I guess 
you are suggesting this in addition to shuffling around init scripts.

I have a working solution that doesn't require building modules statically 
into the kernel. I would like to see a mechanism to support this type of use 
case (network hosted block level storage) in a more generic way so that I 
(and others) don't have to reinvent the wheel when doing this. If that wheel 
has not been invented, I would like to help do so.

wt
-- 
Warren Turkal, Research Associate III/Systems Administrator
Colorado State University, Dept. of Atmospheric Science


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

Re: Bug#403979: ITP: gpe-gallery -- GPE image gallery and viewer, with slideshow support

[Andreas Tille]

On Thu, 21 Dec 2006, Neil Williams wrote:


 Description : GPE image gallery and viewer, with slideshow support
A small application for viewing images in GPE. Intended to show
small and medium sized images and is able to display a slide
show and to perform several simple operations with the images.


Sorry, what is GPE?
Yes, I'm sure Google would be my friend for this question but package
descriptions should not require other resources to be understandable
for the user.

Kind regards

  Andreas.

--
http://fam-tille.de


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

Re: restricted sourceless ARM uploads

[Russ Allbery]

Aurelien Jarno <[EMAIL PROTECTED]> writes:

> * Also those package (and they are plenty others), could be tagged
>   not-for-us. This would spare some build daemon time, and would ease to
>   see which packages have really failed to build or not.
[...]
>openafs_1.4.2-4

As the OpenAFS co-maintainer, I can confirm that would be the correct
action to take.  OpenAFS tries to fail its build fairly quickly with a
clear error message, but it really should just be tagged not-for-us on arm
(and on mips and mipsel).  I tried contacting the Packages-arch-specific
maintainers a few times about this a while back without a response.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Is Ryuichi Arafune MIA?

[Gunnar Wolf]

Hi,

I just prepared a NMU for toolbar-fancy [1], a package maintained by
Ryuichi Arafune. Now, I usually check the QA page for maintainers for
which I do NMUs. Now, Ryuichi's QA page [2] shows he has been quite
inactive in the project - His latest upload AFAICT was in 2006-03-30
for imagemagick [3]. This package is quite popular (popcon 9174), and
has seen 13 NMUs since.

It seems Ryuichi is MIA. Possibly this is not the best way to check
for activity or to ask QA to take over his packages (QA, is
it?). Anyway, Ryuichi: Are you reading this? What's your status
regarding Debian? Do you plan to go back to activity, or should your
packages be taken over by someone else? 

Thank you very much,

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=403935

[2] http://qa.debian.org/[EMAIL PROTECTED]

[3] http://packages.qa.debian.org/l/lookup-el.html

[4] http://packages.qa.debian.org/i/imagemagick.html

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


signature.asc
Description: Digital signature

Bug#403979: ITP: gpe-gallery -- GPE image gallery and viewer, with slideshow support

[Neil Williams]

Package: wnpp
Severity: wishlist
Owner: Neil Williams <[EMAIL PROTECTED]>

* Package name: gpe-gallery
  Version : 0.97
  Upstream Author : Damien Tanner <[EMAIL PROTECTED]>
* URL : http://gpe.linuxtogo.org/projects/gpe-gallery.shtml
* License : GPL
  Programming Lang: C
  Description : GPE image gallery and viewer, with slideshow support
 A small application for viewing images in GPE. Intended to show 
 small and medium sized images and is able to display a slide 
 show and to perform several simple operations with the images.



-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-amd64-k8
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)


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

Re: Bits from the debian-cd team; more CD/DVDs being built regularly

[Joey Hess]

Joey Hess wrote:
> I checked the log, the current muti dvd doesn't seem to have any desktop
> packages on it, not even gnome-desktop-environment.

Wrong log as it turns out. The gnome task is there, in full, as are
almost all other tasks, except for a few of the last language tasks. The
kde task didn't make it on, being currently forced in priority lower
than all of these. Probably room for improvement in the ordering here.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bits from the debian-cd team; more CD/DVDs being built regularly

[Steve Langasek]

On Wed, Dec 20, 2006 at 03:43:55PM -0500, Joey Hess wrote:
> > I'm sure they're, so can't we go for a new multiarch containing hppa
> > and ia64 only or even i386, hppa and ia64 ?

> Hmm, keeping i386 on it is an interesting idea. Or it could have alpha,
> hppa, and ia64, for the big/old/weird/64 bit iron multiarch cd. :-)

I was just thinking that alpha/hppa/ia64 would be an interesting "HP-themed"
multiarch CD.  Sounds like this would be fun to work on. :)  I have no idea
if the CD booting for these archs can coexist naturally, though.

(Does weird iron contain strange quarks in its nuclei?)

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


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

Re: block device served over network connections

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/20/06 18:16, Warren Turkal wrote:
> On Wednesday 20 December 2006 02:59, Wouter Verhelst wrote:
>> Just rearrange the initscripts so that mdadm is ran _after_ aoetools.
> 
> If it were only that easy, I would do that. However, there is much more to 
> it. 
> For instance, the mdadm and lvm and evms run in the initramfs. Also the 
> ethernet card receiving the AOE data needs to be up to talk to the devices, 
> and thus needs to be up. An IP is not neccesarily needed for AOE (think "ip 
> link set eth1 up") unlike ISCSI. I wish there were a way to make the aoetools 
> script work, but it is fundamentally broken. I would like to work with the 
> maintainer, but he has been pretty unresponsive to this use case.

Roll a custom kernel that either statically links the modules, or
loads them in your preferred order?

> I have now added the scripts to make it work from initramfs and to make sure 
> the network is up during shutdown at the right time to let the lvm subsystem 
> properly shut down. I also disabled the aoetools scripts. I have posted the 
> required scripts at [1]. Granted, they are a total hack, but they work. I 
> wish someone smarter than me about this stuff would take a look. As one 
> improvement, I could probably use the /etc/default/aoetools in the initramfs 
> script.
> 
> wt
> 
> [1]http://penguintechs.org/debian/aoe_stuff/aoe-block.tar


- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFidVzS9HxQb37XmcRAh1oAJ9kzSvFqATGPdJa8ZFGpCujzVxQPwCgz88s
mZRvGSwuBrywRXcdrryxx6U=
=dNzb
-END PGP SIGNATURE-


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

Re: block device served over network connections

[Warren Turkal]

On Wednesday 20 December 2006 02:59, Wouter Verhelst wrote:
> Just rearrange the initscripts so that mdadm is ran _after_ aoetools.

If it were only that easy, I would do that. However, there is much more to it. 
For instance, the mdadm and lvm and evms run in the initramfs. Also the 
ethernet card receiving the AOE data needs to be up to talk to the devices, 
and thus needs to be up. An IP is not neccesarily needed for AOE (think "ip 
link set eth1 up") unlike ISCSI. I wish there were a way to make the aoetools 
script work, but it is fundamentally broken. I would like to work with the 
maintainer, but he has been pretty unresponsive to this use case.

I have now added the scripts to make it work from initramfs and to make sure 
the network is up during shutdown at the right time to let the lvm subsystem 
properly shut down. I also disabled the aoetools scripts. I have posted the 
required scripts at [1]. Granted, they are a total hack, but they work. I 
wish someone smarter than me about this stuff would take a look. As one 
improvement, I could probably use the /etc/default/aoetools in the initramfs 
script.

wt

[1]http://penguintechs.org/debian/aoe_stuff/aoe-block.tar
-- 
Warren Turkal, Research Associate III/Systems Administrator
Colorado State University, Dept. of Atmospheric Science


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

Re: Bits from the debian-cd team; more CD/DVDs being built regularly

[Josselin Mouette]

Le mercredi 20 décembre 2006 à 16:27 -0500, Joey Hess a écrit :
> Josselin Mouette wrote:
> > It's somewhat a shame not to have gnome-office, or at least gimp,
> > inkscape and gnumeric, which are by many points superior to other
> > alternatives.
> 
> We do have gimp in the desktop task. I'm willing to consider gnumeric
> and inkscape. Actually I wouldn't really mind revisiting the dropping of
> gnome-office, it was only done for space reasons at the time and because
> OOo is included in the desktop task already.

If space is not a problem any more, that would be nice. Planner and dia
may not be useful enough to justify inclusion - we should even move them
to Suggests, IMHO - but other applications are nice to have, even with
OOo already installed.

Thanks,
-- 
Josselin Mouette/\./\

"Do you have any more insane proposals for me?"


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: cpufire-applet_1.2-2_arm.changes REJECTED

[Aurelien Jarno]

Torsten Werner a écrit :
> HI Aurelien,
> 
> On 12/20/06, Debian Installer <[EMAIL PROTECTED]> wrote:
>> Rejected: cpufire-applet_1.2-2_arm.changes: not signed by authorised uploader
> 
> did you manage to build cpufire-applet on arm? Can I help with
> uploading the package?

Yes, this package builds fine on arm. The problem you observed on the
build log are due to recurrent problem of the build daemon on which this
package as been built.

I don't have the right to upload binary arm packages anymore [1], so I
am sorry, but I can't help you.

Aurelien

[1] http://lists.debian.org/debian-devel/2006/12/msg00546.html

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: gcc-h8300-hms_4.1.1-3_arm.changes REJECTED

[Aurelien Jarno]

Michael Tautschnig a écrit :
> [...]
>>> - I've requested rescheduling the package on ARM as it should now build
>>>   successfully, but I haven't seen any reply on this one.
>>>
>> If you have written to [EMAIL PROTECTED], this is the right place. I
>> wish you good luck, as it is roughly an alias to /dev/null.
>>
> [...]
> 
> Hmm, what did you point at by "this" - [EMAIL PROTECTED] or anything else
> like the CC list?

I mean [EMAIL PROTECTED] is the right place.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: gcc-h8300-hms_4.1.1-3_arm.changes REJECTED

[Michael Tautschnig]

[...]
> 
> > - I've requested rescheduling the package on ARM as it should now build
> >   successfully, but I haven't seen any reply on this one.
> > 
> 
> If you have written to [EMAIL PROTECTED], this is the right place. I
> wish you good luck, as it is roughly an alias to /dev/null.
>
[...]

Hmm, what did you point at by "this" - [EMAIL PROTECTED] or anything else
like the CC list?

Anyway, let's hope that your thread on debian-devel has some positive impact on
the packages you confirmed that they build fine...

Thanks,
Michael




pgpWDq9Sw06fo.pgp
Description: PGP signature

Re: Bits from the debian-cd team; more CD/DVDs being built regularly

[Joey Hess]

Josselin Mouette wrote:
> It's somewhat a shame not to have gnome-office, or at least gimp,
> inkscape and gnumeric, which are by many points superior to other
> alternatives.

We do have gimp in the desktop task. I'm willing to consider gnumeric
and inkscape. Actually I wouldn't really mind revisiting the dropping of
gnome-office, it was only done for space reasons at the time and because
OOo is included in the desktop task already.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bits from the debian-cd team; more CD/DVDs being built regularly

[Josselin Mouette]

Le mercredi 20 décembre 2006 à 16:03 -0500, Joey Hess a écrit :
> > Not having "gnome" on a single CD is understandable given how much we've
> > bloated this metapackage.
> 
> Actually, we don't even include the gnome metapackage in the full
> gnome-desktop task. gnome-office, gdm-themes and gnome-games-extra-data
> are dependencies of gnome that are not included in that task (the rest
> of its deps are listed).

It's somewhat a shame not to have gnome-office, or at least gimp,
inkscape and gnumeric, which are by many points superior to other
alternatives.
-- 
Josselin Mouette/\./\

"Do you have any more insane proposals for me?"


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Bits from the debian-cd team; more CD/DVDs being built regularly

[Joey Hess]

Josselin Mouette wrote:
> Are you talking of gnome-core or gnome-desktop-environment? gnome-core
> is indeed really basic, but g-d-e already includes a complete desktop.

gnome-desktop-environment is the sole key package in the gnome-desktop
task, and nearly the only one from that task that currently fits on the
first CD (the key packages for the laptop, web-server, and most other
tasks except for kde and xfce also fit on the CD).

> Not having "gnome" on a single CD is understandable given how much we've
> bloated this metapackage.

Actually, we don't even include the gnome metapackage in the full
gnome-desktop task. gnome-office, gdm-themes and gnome-games-extra-data
are dependencies of gnome that are not included in that task (the rest
of its deps are listed).

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bits from the debian-cd team; more CD/DVDs being built regularly

[Josselin Mouette]

Le mercredi 20 décembre 2006 à 14:21 -0500, Joey Hess a écrit :
> Gustavo Franco wrote:
> > Unfortunately, even the GNOME desktop environment doesn't fit on the
> > CD#1.
> 
> True, but enough does fit to have a basically useable gnome desktop.

Are you talking of gnome-core or gnome-desktop-environment? gnome-core
is indeed really basic, but g-d-e already includes a complete desktop.
Not having "gnome" on a single CD is understandable given how much we've
bloated this metapackage.

-- 
Josselin Mouette/\./\

"Do you have any more insane proposals for me?"


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Bits from the debian-cd team; more CD/DVDs being built regularly

[Joey Hess]

Gustavo Franco wrote:
> Do you know what's broken in Xfce cd? Is it tasksel related? I hope not.

Missing task file, it should be fixed in the next build.

> Sounds great, could you give me a link with the log or check it in the
> next build please?

I checked the log, the current muti dvd doesn't seem to have any desktop
packages on it, not even gnome-desktop-environment.

> I'm sure they're, so can't we go for a new multiarch containing hppa
> and ia64 only or even i386, hppa and ia64 ?

Hmm, keeping i386 on it is an interesting idea. Or it could have alpha,
hppa, and ia64, for the big/old/weird/64 bit iron multiarch cd. :-)

-- 
see shy jo


signature.asc
Description: Digital signature

Re: restricted sourceless ARM uploads

[Aurelien Jarno]

Mirco Bauer a écrit :
> Hi Aurelien,
> 
> I can give some details about the Mono related packages that failed to
> build before but worked for you. I reply inline.
> 
> On Wed, 2006-12-20 at 17:39 +0100, Aurelien Jarno wrote:
>> * Packages that now build fine:
>>blam_1.8.3-2 (for 40 days)

Oops, there is a mistake (copy & paste abuse), this should have been 9
days, as other mono related packages.

> blam failed because of a runtime bug (which is specific to the arm port)
> in Mono, which can be indentified by throwing random
> System.IO.FileNotFoundException, which was fixed in Mono 1.2.2.1 (see
> #394418), so a simple rebuild solves this kind of FTBFS on ARM for Mono
> based software. Though there are remaining problems still with Mono and
> netwinder, which is why the bug isn't closed yet.

When you say "netwinder", could you reproduce it on others netwinder
machines than the build daemon called that way?

FYI this build daemon seems to have some problems (missing files).

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: gcc-h8300-hms_4.1.1-3_arm.changes REJECTED

[Aurelien Jarno]

Michael Tautschnig a écrit :
> --Qxx1br4bt0+wmkIi
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
>> =20
>> Rejected: gcc-h8300-hms_4.1.1-3_arm.changes: not signed by authorised upl=
> oader
>> =20
>> =20
>> =3D=3D=3D
>> =20
>> If you don't understand why your files were rejected, or if the
>> override file requires editing, reply to this email.
>>
> 
> I'm indeed not understanding this one as
> 
> - the buildd logs don't show a successful build on ARM
>   (http://buildd.debian.org/pkg.cgi?pkg=3Dgcc-h8300-hms)

I have build it on one of my emulated machines [1], and then uploaded
it. It has been decided that all these uploads should be rejected, hence
the email you received.

> - I've requested rescheduling the package on ARM as it should now build
>   successfully, but I haven't seen any reply on this one.
> 

If you have written to [EMAIL PROTECTED], this is the right place. I
wish you good luck, as it is roughly an alias to /dev/null.

Bye,
Aurelien


[1] http://lists.debian.org/debian-devel/2006/12/msg00546.html

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: Bits from the debian-cd team; more CD/DVDs being built regularly

[Gustavo Franco]

On 12/20/06, Steve McIntyre <[EMAIL PROTECTED]> wrote:

On Wed, Dec 20, 2006 at 05:04:28PM -0200, Gustavo Franco wrote:
(...)
>>In case it's not obvious, the 3 arches picked for these discs are
>>simply the most common end-user systems out there. There is scope for
>>producing more multi-arch discs, but the possible combinations are
>>*massive* :-).
>
>I would like to suggest 'split' the 9 archs left in 3, something like:
>- arm, mips, mipsel
>- hppa, ia64, s390
>- sparc, m68k, alpha
>
>Is it possible? Do you think it will fit ? If yes, i can prepare
>patches for debian-cd once i figure out all that pile of changes.

There is a problem that I didn't mention here specifically yet: many
of the arches clash in terms of how to make a CD bootable. Many expect
to find their own special metadata in sector 0 of the CD, and most of
them are completely incompatible. :-( We're actually quite lucky that
the common 3 arches are compatible.


I thought about that but since you've not cited the technical limitation
i asked anyway. ;)


The other thing is that the number of CD/DVD-bootable machines in the
other arches is really quite small, probably small enough not to be
worth bothering with the extra effort here for the multi-arch discs.


No problem.


>> (...)
>>I'm still expecting to add Live CDs to the list here before we
>>release. Otherwise, I think we're about set. If there's anything else
>>you'd like us to do or anything you'd like to ask about, please reply
>>to this mail - note the Reply-To to the debian-cd list.
>
>Do you plan to use the live-package to build the live cds or some new
>code into debian-cd ? If you're going to pick live-package i submitted
>a patch to Daniel that would permit use a tasksel based approach to
>select packages, and not the fixed list as they actually do. I have no
>feedback about that until now. It seems they were going to do a major
>change in the code.

Yep, I'm expecting to use live-package. I need to get playing with
that soon...


Sounds good. Please, let us be sure that the during a GNOME, KDE or
XFCE 'live session' the user will have the same or similar as possible
set of packages as installed by d-i (tasksel), as i told you, over the
current codebase there's a patch i submitted that is a step on this
direction. We just need to tweak it a bit and build at least a set
with 3 live desktop cd's (one for each desktop environment and i386),
IMHO. Thoughts?

The possibility of give to the users during a event the DVD#1
containing the 3 desktop environments and 1 live-cd containing the one
he prefers to use (if any) to play with the stuff and test the
hardware compatibility before install is exciting.

regards,
-- stratus


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

Re: Bits from the debian-cd team; more CD/DVDs being built regularly

[Steve McIntyre]

On Wed, Dec 20, 2006 at 05:04:28PM -0200, Gustavo Franco wrote:
>
>Let me thanks the debian-desktop, debian-installer and tasksel team
>too. Without them, that stuff would be useless.

Yup, of course. :-)

>I would like to clarify that debian-desktop (alioth, svn, mailing
>list) is now a unit composed by pkg-gnome, pkg-kde and pkg-xfce and
>tasksel members. Joey Hess (d-i and debian-cd) give us all the support
>to make stuff happen.
>
>Unfortunately, even the GNOME desktop environment doesn't fit on the
>CD#1. You will need broadband connection to fetch some more packages
>or use the full DVD#1 for your architecture. The bonus is that KDE
>will be there too (full DVD #1). I'm not sure about the latest
>statistics on KDE and XFCE alternative desktop CD#1. Joey, could you
>give us that information? Btw, i would like to suggest add it
>somewhere in the release notes "where's what" in terms of medias. I
>can submit patches, after you feed me with info.

As Joey suggests, the key task packages from Gnome and KDE should each
fit on their respective versions of CD#1.

>>There is also a combined amd64/i386/powerpc/source DVD which should
>>contain most of what people will commonly want to install on each of
>>those 3 arches, roughly equivalent to the contents of the first 3-4
>>CDs or so each. Binary-all package overlaps mean that there is space
>>on this disc for more packages than might be expected. Plus, sources
>>for all the binaries on the DVD will be included too. This DVD is
>>therefore probably the ideal choice of disc to sell or give away at
>>Expos.
>
>Does it contains desktop, kde-desktop, gnome-desktop and xfce-desktop?
>I guess not, but who knows. ;)

I would hope so, yes. It'll also depend on popcon ordering as to
exactly what gets there.

>>In case it's not obvious, the 3 arches picked for these discs are
>>simply the most common end-user systems out there. There is scope for
>>producing more multi-arch discs, but the possible combinations are
>>*massive* :-).
>
>I would like to suggest 'split' the 9 archs left in 3, something like:
>- arm, mips, mipsel
>- hppa, ia64, s390
>- sparc, m68k, alpha
>
>Is it possible? Do you think it will fit ? If yes, i can prepare
>patches for debian-cd once i figure out all that pile of changes.

There is a problem that I didn't mention here specifically yet: many
of the arches clash in terms of how to make a CD bootable. Many expect
to find their own special metadata in sector 0 of the CD, and most of
them are completely incompatible. :-( We're actually quite lucky that
the common 3 arches are compatible.

The other thing is that the number of CD/DVD-bootable machines in the
other arches is really quite small, probably small enough not to be
worth bothering with the extra effort here for the multi-arch discs.

>>To do
>>=
>>
>>I'm still expecting to add Live CDs to the list here before we
>>release. Otherwise, I think we're about set. If there's anything else
>>you'd like us to do or anything you'd like to ask about, please reply
>>to this mail - note the Reply-To to the debian-cd list.
>
>Do you plan to use the live-package to build the live cds or some new
>code into debian-cd ? If you're going to pick live-package i submitted
>a patch to Daniel that would permit use a tasksel based approach to
>select packages, and not the fixed list as they actually do. I have no
>feedback about that until now. It seems they were going to do a major
>change in the code.

Yep, I'm expecting to use live-package. I need to get playing with
that soon...

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"C++ ate my sanity" -- Jon Rabone


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

Re: restricted sourceless ARM uploads

[Mirco Bauer]

Hi Aurelien,

I can give some details about the Mono related packages that failed to
build before but worked for you. I reply inline.

On Wed, 2006-12-20 at 17:39 +0100, Aurelien Jarno wrote:
> * Packages that now build fine:
>blam_1.8.3-2 (for 40 days)
blam failed because of a runtime bug (which is specific to the arm port)
in Mono, which can be indentified by throwing random
System.IO.FileNotFoundException, which was fixed in Mono 1.2.2.1 (see
#394418), so a simple rebuild solves this kind of FTBFS on ARM for Mono
based software. Though there are remaining problems still with Mono and
netwinder, which is why the bug isn't closed yet.

>evolution-sharp_0.11.1-3 (for 9 days)
Same thing here as for blam

>gcc-h8300-hms_4.1.1-3 (for 7 days)
>hdbc-odbc_1.0.1.1 (for 40 days) 
>hdbc-missingh_1.0.1.1 (for 40 days)
>njb-sharp_0.3.0-1 (for 9 days)
Same thing as for blam

>muine_0.8.5-1.1 (for 9 days)
This one seems to fail trying to generate some WDSL stuff, that tries to
use the internet, which is not always available on some buildds, but was
on your machine seems like.

Can't say anything about the other packages.

-- 
Regards,

Mirco 'meebey' Bauer

PGP-Key:
http://keyserver.noreply.org/pks/lookup?op=get&search=0xEEF946C8

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d s-:+ a-- C++ UL$ P L++$>+++$ E- W+++$ N o? K- w++>! O M-
V? PS
PE+ Y- PGP++ t 5+ X++ R tv+ b+ DI? D+ G>++ e h! r->++ y?
--END GEEK CODE BLOCK--


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

Re: Bits from the debian-cd team; more CD/DVDs being built regularly

[Gustavo Franco]

On 12/20/06, Joey Hess <[EMAIL PROTECTED]> wrote:

Gustavo Franco wrote:
> Unfortunately, even the GNOME desktop environment doesn't fit on the
> CD#1.

True, but enough does fit to have a basically useable gnome desktop.


Right, but we need to make it clear for the users and the first line
of them are subscribed to -devel. ;)


> You will need broadband connection to fetch some more packages
> or use the full DVD#1 for your architecture. The bonus is that KDE
> will be there too (full DVD #1). I'm not sure about the latest
> statistics on KDE and XFCE alternative desktop CD#1. Joey, could you
> give us that information?

All of kde doesn't fit on the kde CD, the key packages for the task do.
I expect that all of xfce will fit on its CD, but as its CD is currently
apparently broken and doesn't include much of anything, I'm not yet
sure.


Do you know what's broken in Xfce cd? Is it tasksel related? I hope not.


> >those 3 arches, roughly equivalent to the contents of the first 3-4
> >CDs or so each. Binary-all package overlaps mean that there is space
> >on this disc for more packages than might be expected. Plus, sources
> >for all the binaries on the DVD will be included too. This DVD is
> >therefore probably the ideal choice of disc to sell or give away at
> >Expos.
>
> Does it contains desktop, kde-desktop, gnome-desktop and xfce-desktop?
> I guess not, but who knows. ;)

I don't know yet, it might since IIRC kde starts around CD 3 or 4 of the
regular CD set.


Sounds great, could you give me a link with the log or check it in the
next build please?


> I would like to suggest 'split' the 9 archs left in 3, something like:
> - arm, mips, mipsel

Not enough machines for these arches with CD drives to be useful, I think.


You've a point.


> - hppa, ia64, s390

AFAIK the use cases for s390 CDs are very limited and don't include
booting, so it's not needed.


I'm sure they're, so can't we go for a new multiarch containing hppa
and ia64 only or even i386, hppa and ia64 ?


regards,
-- stratus


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

Re: Bits from the debian-cd team; more CD/DVDs being built regularly

[Joey Hess]

Gustavo Franco wrote:
> Unfortunately, even the GNOME desktop environment doesn't fit on the
> CD#1.

True, but enough does fit to have a basically useable gnome desktop.

> You will need broadband connection to fetch some more packages
> or use the full DVD#1 for your architecture. The bonus is that KDE
> will be there too (full DVD #1). I'm not sure about the latest
> statistics on KDE and XFCE alternative desktop CD#1. Joey, could you
> give us that information?

All of kde doesn't fit on the kde CD, the key packages for the task do.
I expect that all of xfce will fit on its CD, but as its CD is currently
apparently broken and doesn't include much of anything, I'm not yet
sure.

> >those 3 arches, roughly equivalent to the contents of the first 3-4
> >CDs or so each. Binary-all package overlaps mean that there is space
> >on this disc for more packages than might be expected. Plus, sources
> >for all the binaries on the DVD will be included too. This DVD is
> >therefore probably the ideal choice of disc to sell or give away at
> >Expos.
> 
> Does it contains desktop, kde-desktop, gnome-desktop and xfce-desktop?
> I guess not, but who knows. ;)

I don't know yet, it might since IIRC kde starts around CD 3 or 4 of the
regular CD set.

> I would like to suggest 'split' the 9 archs left in 3, something like:
> - arm, mips, mipsel

Not enough machines for these arches with CD drives to be useful, I think.

> - hppa, ia64, s390

AFAIK the use cases for s390 CDs are very limited and don't include
booting, so it's not needed.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: restricted sourceless ARM uploads

[Bill Allombert]

On Wed, Dec 20, 2006 at 12:32:25PM -0600, Bill Gatliff wrote:
> 
> Could you try those packages on hedges?  (You can get developer access 
> from Wookey if you need it).  Hedges has 512MB real and 1.5GB swap.  And 
> unlike leisner, the netwinders, or nslu2s, it's expandable if needed.

No use, this will simply thrash the box to no end. Try to build openvrml
for example. It failed on europa after 1000 minutes of inactivity:



> But on that point, I've never had any issues with either 
> distcc+crossgcc--- which I've tested extensively--- or QEMU.  But 

Neither I have (I use distcc+crossgcc on top of aranym quite
extensively) so I don't see any reason not to use that if that help
the port to be releasable.

> forcing the use of real hardware wherever possible means (a) you know 
> for sure, and (b) you have to keep your real hardware maintained.  Those 
> seem like good things.

They are sure good thing but not at the price of the port not
being released which is the issue here.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large blue swirl here. 


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

Re: Bits from the debian-cd team; more CD/DVDs being built regularly

[Philip Payne]

I hope its not too inappropriate to post this message on this group,  I 
am not a developer but I subscribed to this group a long time ago just 
to keep in touch with what was happening with Debian
I just want to say thank you so much for this fantastic system : 
Etch/Testing It works so fine on my 64bit system its just simply a 
dream, best  operating system I have ever had since I started with 
computers!

What can I say, thanks?..
:-)


Steve McIntyre a écrit :

We now have *lots* of CD and DVD types being built regularly, so maybe
a quick summary is in order:

Daily builds


 * "etch" businesscard for each arch *except* s390 (small image, no
   packages - just contains d-i)
 * "etch" netinst for each arch *except* s390 (slightly larger image,
   d-i and the base system only)
 * "sid" businesscard (as above)
 * "sid" netinst (as above)

The "etch" and "sid" versions determine the version of d-i used in
each case. "etch" uses the last known-good d-i image from the archive
(aka etch RC1 at the moment). "sid" uses the latest build from the
porters for each architecture. Both sets are built often, triggered by
the mirror pulse (currently twice daily). Total build time for all of
these is approximately 45 minutes for 44 CDs.

Weekly builds
=

 * full CD sets for each arch and source
 * full DVD sets for each arch and source
 * (NEW) a KDE version of CD#1 for each arch
 * (NEW) an XFCE version of CD#1 for each arch
 * (NEW) a 3-arch netinst (amd64/i386/powerpc)
 * (NEW) a 3-arch + source DVD#1 (amd64/i386/powerpc/source)

These builds are normally triggered by the first mirror pulse on a
Monday, UTC timezone. This build takes much longer, due to the sheer
size of the data sets involved, (approximately 15 hours for 293 CDs
and 41 DVDs in the last build). There is now quite some overlap
between these discs, too, which leads me on to:

Gnome vs. KDE vs. XFCE
==

The KDE and XFCE variants of CD#1 are now being produced to give more
choice to people for initial installation. By default, CD#1 has always
meant to be enough to install a fully-functioning system, including a
desktop. On sarge, we (just about) managed to make all that fit,
including a choice of KDE or Gnome. However, since the sarge release
the size of the set of packages needed to cover each desktop *and* the
rest of the base system has grown substantially. We're now at the
point where that's just not possible any more. The default CD#1 will
now install a Gnome desktop, and there are replacement CDs that will
install KDE or XFCE instead. Download your own choice. Thanks to Joey
Hess for the work to make these happen.

Multi-arch
==

Quick warning to avoid possible confusion: this is nothing to do with
the multi-arch binary support that people are working on. The new
multi-arch discs are designed to be convenient for people who
need/want to be able to install Debian onto multiple different types
of machine from a single disc.

To that end, there is now a combined amd64/i386/powerpc netinst that
is basically an amalgamation of the contents of the individual
netinsts for those arches. This is based on the "etch" d-i version as
described above.

There is also a combined amd64/i386/powerpc/source DVD which should
contain most of what people will commonly want to install on each of
those 3 arches, roughly equivalent to the contents of the first 3-4
CDs or so each. Binary-all package overlaps mean that there is space
on this disc for more packages than might be expected. Plus, sources
for all the binaries on the DVD will be included too. This DVD is
therefore probably the ideal choice of disc to sell or give away at
Expos.

In case it's not obvious, the 3 arches picked for these discs are
simply the most common end-user systems out there. There is scope for
producing more multi-arch discs, but the possible combinations are
*massive* :-).

To do
=

I'm still expecting to add Live CDs to the list here before we
release. Otherwise, I think we're about set. If there's anything else
you'd like us to do or anything you'd like to ask about, please reply
to this mail - note the Reply-To to the debian-cd list.

Otherwise, please help us TEST these, especially the variants marked
as NEW above. Downloads are available in multiple formats (iso image,
jigdo, bittorrent) - look at

  http://cdimage.debian.org/cdimage/daily-builds/
  http://cdimage.debian.org/cdimage/weekly-builds/

for all your testing CD/DVD needs.

Cheers,
  



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

Re: Bits from the debian-cd team; more CD/DVDs being built regularly

[Gustavo Franco]

On 12/20/06, Steve McIntyre <[EMAIL PROTECTED]> wrote:

(...)

Gnome vs. KDE vs. XFCE
==

The KDE and XFCE variants of CD#1 are now being produced to give more
choice to people for initial installation. By default, CD#1 has always
meant to be enough to install a fully-functioning system, including a
desktop. On sarge, we (just about) managed to make all that fit,
including a choice of KDE or Gnome. However, since the sarge release
the size of the set of packages needed to cover each desktop *and* the
rest of the base system has grown substantially. We're now at the
point where that's just not possible any more. The default CD#1 will
now install a Gnome desktop, and there are replacement CDs that will
install KDE or XFCE instead. Download your own choice. Thanks to Joey
Hess for the work to make these happen.


Let me thanks the debian-desktop, debian-installer and tasksel team
too. Without them, that stuff would be useless.

I would like to clarify that debian-desktop (alioth, svn, mailing
list) is now a unit composed by pkg-gnome, pkg-kde and pkg-xfce and
tasksel members. Joey Hess (d-i and debian-cd) give us all the support
to make stuff happen.

Unfortunately, even the GNOME desktop environment doesn't fit on the
CD#1. You will need broadband connection to fetch some more packages
or use the full DVD#1 for your architecture. The bonus is that KDE
will be there too (full DVD #1). I'm not sure about the latest
statistics on KDE and XFCE alternative desktop CD#1. Joey, could you
give us that information? Btw, i would like to suggest add it
somewhere in the release notes "where's what" in terms of medias. I
can submit patches, after you feed me with info.


Multi-arch
==

Quick warning to avoid possible confusion: this is nothing to do with
the multi-arch binary support that people are working on. The new
multi-arch discs are designed to be convenient for people who
need/want to be able to install Debian onto multiple different types
of machine from a single disc.

To that end, there is now a combined amd64/i386/powerpc netinst that
is basically an amalgamation of the contents of the individual
netinsts for those arches. This is based on the "etch" d-i version as
described above.

There is also a combined amd64/i386/powerpc/source DVD which should
contain most of what people will commonly want to install on each of
those 3 arches, roughly equivalent to the contents of the first 3-4
CDs or so each. Binary-all package overlaps mean that there is space
on this disc for more packages than might be expected. Plus, sources
for all the binaries on the DVD will be included too. This DVD is
therefore probably the ideal choice of disc to sell or give away at
Expos.


Does it contains desktop, kde-desktop, gnome-desktop and xfce-desktop?
I guess not, but who knows. ;)


In case it's not obvious, the 3 arches picked for these discs are
simply the most common end-user systems out there. There is scope for
producing more multi-arch discs, but the possible combinations are
*massive* :-).


I would like to suggest 'split' the 9 archs left in 3, something like:
- arm, mips, mipsel
- hppa, ia64, s390
- sparc, m68k, alpha

Is it possible? Do you think it will fit ? If yes, i can prepare
patches for debian-cd once i figure out all that pile of changes.


To do
=

I'm still expecting to add Live CDs to the list here before we
release. Otherwise, I think we're about set. If there's anything else
you'd like us to do or anything you'd like to ask about, please reply
to this mail - note the Reply-To to the debian-cd list.


Do you plan to use the live-package to build the live cds or some new
code into debian-cd ? If you're going to pick live-package i submitted
a patch to Daniel that would permit use a tasksel based approach to
select packages, and not the fixed list as they actually do. I have no
feedback about that until now. It seems they were going to do a major
change in the code.


(...)


regards,
-- stratus


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

Re: restricted sourceless ARM uploads

[Bill Gatliff]

Bill:



A very basic reason is that some packages require 1GB of RAM to build
in finite time and there are no arm and m68k buildd with that amount of
RAM.
 



Could you try those packages on hedges?  (You can get developer access 
from Wookey if you need it).  Hedges has 512MB real and 1.5GB swap.  And 
unlike leisner, the netwinders, or nslu2s, it's expandable if needed.



An alternative is to use distcc+crosscc to a distccd server with 1GB of RAM.
 



I've done this before (rebuilt X that way, just as a test!), but it has 
similar concerns to the QEMU approach.


But on that point, I've never had any issues with either 
distcc+crossgcc--- which I've tested extensively--- or QEMU.  But 
forcing the use of real hardware wherever possible means (a) you know 
for sure, and (b) you have to keep your real hardware maintained.  Those 
seem like good things.




b.g.

--
Bill Gatliff
[EMAIL PROTECTED]


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

Re: restricted sourceless ARM uploads

[Aurelien Jarno]

Aurelien Jarno a écrit :
> * Packages that failed to build because the build daemon netwinder is
>   fucked for weeks wrt to /usr/lib/libtasn1.so.3.0.6
>cpufire-applet_1.2-2 
>gnome-session_2.14.3-4 

The situation is actually worse than what I expected. This build daemon
seems to loose files from its chroot. I don't have access to it, but
from the build logs I can say that /sbin/MAKEDEV [1] and
/usr/lib/libtasn1.so.3.0.6 [2] are missing.

Other files may be missing. Given that a lot of packages are using
autoconf to detect available libraries, some packages built by this
build daemon may have some disable functionalities.

Bye,
Aurelien

[1]
http://buildd.debian.org/build.php?pkg=kdebase&arch=arm&ver=4:3.5.5a.dfsg.1-4

[2]
http://buildd.debian.org/fetch.cgi?&pkg=gnome-session&ver=2.14.3-4&arch=arm&stamp=1166563605&file=log

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: restricted sourceless ARM uploads

[Sam Hocevar]

On Wed, Dec 20, 2006, Bill Gatliff wrote:

> For the faster arches, i.e. the ARM9 machines and above, I'm thinking 
> that we should stick with real hardware so there's no question that the 
> binaries will run properly.

   Pardon me sir, but can that claim that binaries built on so-called
"real hardware" will unquestionably run (as opposed to, if I understand
correcly, binaries built on an emulated platform) be backed up by any
facts, examples, experimentation results or scientific publication?

Kindest regards,
-- 
Sam.


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

Re: restricted sourceless ARM uploads

[Bill Allombert]

On Wed, Dec 20, 2006 at 05:05:21PM +, Wookey wrote:
> On 2006-12-20 17:39 +0100, Aurelien Jarno wrote:
> > Hi,
> > 
> > For those who don't know, I have setup 8 emulated ARM build daemons and
> > started to upload packages. To know why and for more information, see
> > [1].
> 
> Very impressive piece of work aurelien! We ought to discuss if there
> is any significant reason not to use qemu 'machines' instead of actual
> hardware for slower arches.

A very basic reason is that some packages require 1GB of RAM to build
in finite time and there are no arm and m68k buildd with that amount of
RAM.

An alternative is to use distcc+crosscc to a distccd server with 1GB of
RAM.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: restricted sourceless ARM uploads

[Aurelien Jarno]

Wookey a écrit :
> On 2006-12-20 17:39 +0100, Aurelien Jarno wrote:
>> Hi,
>>
>> For those who don't know, I have setup 8 emulated ARM build daemons and
>> started to upload packages. To know why and for more information, see
>> [1].
> 
> Very impressive piece of work aurelien! We ought to discuss if there
> is any significant reason not to use qemu 'machines' instead of actual
> hardware for slower arches.
> 

BTW, I don't think ARM needs emulated build machines. It's just that
it's the fastest ARM machine I found. My two NSLU2 won't have been enough.

Also it seems the current ARM build machines altogether are fast enough
to build all the packages (except for building big packages like the
kernel). But a faster machine would mean that the Vancouver requirements
are satisfied, and also less machines to handle, so less work for the
ARM build daemon maintainer.

What I wanted to demonstrate, is that the percentage of package built by
an architecture does depends on the speed of the build machines, but
also on how they are administrated.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: restricted sourceless ARM uploads

[Bill Gatliff]

Wookey wrote:


On 2006-12-20 17:39 +0100, Aurelien Jarno wrote:
 


Hi,

For those who don't know, I have setup 8 emulated ARM build daemons and
started to upload packages. To know why and for more information, see
[1].
   



Very impressive piece of work aurelien! We ought to discuss if there
is any significant reason not to use qemu 'machines' instead of actual
hardware for slower arches.
 



As long as there's the occasional test on actual hardware, I don't have 
a problem with it.


For the faster arches, i.e. the ARM9 machines and above, I'm thinking 
that we should stick with real hardware so there's no question that the 
binaries will run properly.



How fast is each of your build machines in comparison to existing
buildds?

The offered Hedges machine is more than twice as fast as existing
buildds and really ought to be brought into the network - it has been
offered for about 2 months now. I will mail DSA again to see if anyone
will tell what needs to be done next, by whom, and when. It is very
rude to people making such offers to give no response at all for such
a long time. Fortunately bill seems very tolerant of Debian's foibles,
 



What choice do I have? I'm not a DD, so it isn't like I have any 
authority to do otherwise. :)




and we can at least use it as a private developer-access machine in
the meantime.
 



Indeed.



b.g.

--
Bill Gatliff
[EMAIL PROTECTED]


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

Re: restricted sourceless ARM uploads

[Aurelien Jarno]

Wookey a écrit :
> On 2006-12-20 17:39 +0100, Aurelien Jarno wrote:
>> Hi,
>>
>> For those who don't know, I have setup 8 emulated ARM build daemons and
>> started to upload packages. To know why and for more information, see
>> [1].
> 
> Very impressive piece of work aurelien! We ought to discuss if there
> is any significant reason not to use qemu 'machines' instead of actual
> hardware for slower arches.

I think we should include Paul Brook in the discussion, as he written a
lot of parts of the ARM emulation, and is also active in the Debian ARM
port.

Anyway I will say that if we can have fast machine (and there are fast
ARM machines), it is better than a few not to slow emulated ARM machine.
But that machine should be accepted by the DSA. And here is the problem.

> How fast is each of your build machines in comparison to existing
> buildds?

For what I saw they are a bit faster than the Debian build machines. You
can expect to have a ARM v5 running at around 350 MHz. And with plenty
of RAM (256 MB in my case), so that make a huge difference on some packages.

> The offered Hedges machine is more than twice as fast as existing
> buildds and really ought to be brought into the network - it has been
> offered for about 2 months now. I will mail DSA again to see if anyone
> will tell what needs to be done next, by whom, and when. It is very
> rude to people making such offers to give no response at all for such
> a long time. Fortunately bill seems very tolerant of Debian's foibles,
> and we can at least use it as a private developer-access machine in
> the meantime.
> 
>> Note that I would have been happy to not start those build daemons, but
>> given the way the arm build daemons are administrated, something had to 
>> be done.
> 
> Perhaps you are right. Let us all try to keep this discussion
> constructive. 
>  
>> Anyway, I have been able to fix a few packages that were not built
>> successfully. For the others, I have extracted from wanna-build a list
>> of package that build successfully, but have failed to build for 
>> various reasons. 
> 
> 
> 
> Can you update the armbuildd wiki page with this? (I expect you are going to
> anyway).

Yes, I will do that later today.

Bye,
Aurelien

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: Explications needed...

[Aurelien Jarno]

Luk Claes a écrit :
> How did Aurelien get wanna-build access for his buildd without 
> explaining to the respective team how the buildd was maintained in the 
> first place or did he not ask for it...
> 

I have setup a wanna-build database (I am the one running the
wanna-build database for hurd-i386, kfreebsd-i386 and kfreebsd-amd64).
Then I wrote a few scripts to extract the information from various
places at http://buildd.debian.org


-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: restricted sourceless ARM uploads

[Wookey]

On 2006-12-20 17:39 +0100, Aurelien Jarno wrote:
> Hi,
> 
> For those who don't know, I have setup 8 emulated ARM build daemons and
> started to upload packages. To know why and for more information, see
> [1].

Very impressive piece of work aurelien! We ought to discuss if there
is any significant reason not to use qemu 'machines' instead of actual
hardware for slower arches.

How fast is each of your build machines in comparison to existing
buildds?

The offered Hedges machine is more than twice as fast as existing
buildds and really ought to be brought into the network - it has been
offered for about 2 months now. I will mail DSA again to see if anyone
will tell what needs to be done next, by whom, and when. It is very
rude to people making such offers to give no response at all for such
a long time. Fortunately bill seems very tolerant of Debian's foibles,
and we can at least use it as a private developer-access machine in
the meantime.

> Note that I would have been happy to not start those build daemons, but
> given the way the arm build daemons are administrated, something had to 
> be done.

Perhaps you are right. Let us all try to keep this discussion
constructive. 
 
> Anyway, I have been able to fix a few packages that were not built
> successfully. For the others, I have extracted from wanna-build a list
> of package that build successfully, but have failed to build for 
> various reasons. 



Can you update the armbuildd wiki page with this? (I expect you are going to
anyway).

Thanx you for your efforts on the arm port over the last few months -
they have been extremely helpful.

Can we make aurel32 an arm buildd maintainer? I think he has shown
both competence and dedication this year. I'm sure having more than
one maintainer would be helpful. Aurel - do you want to commit to this
task?

Wookey
-- 
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK  Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/ play: http://wookware.org/


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

Re: Explications needed...

[Michael Banck]

[this discussion is off-topic on -devel, please follow-up on -project]

On Wed, Dec 20, 2006 at 05:51:55PM +0100, Luk Claes wrote:
> How did Aurelien get wanna-build access for his buildd

He didn't, it's a rogue autobuilder.  Which is the reason it got
blacklisted.

> or did he not ask for it...

He did apparently, but did not get a response and decided to act anyway.

Did somebody from the release team say that the arm autobuilder is
causing trouble to the release, and that buildd maintenance needs to get
addressed?


Michael


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

Re: Explications needed...

[Luk Claes]

Pierre Habouzit wrote:

  I happened to have had access to the internet during my vacation, and
I happened to read a backlog on #debian-release that frightens me:

15:52 aj | "# unilateral action to run an emulated buildd -- all arm changes 
sidelined until fixed."
15:52aba | oh, where?
15:52 aj | cron.unchecked, -> queue/delayed
[...]
15:58aba | (and btw, I would expect that ftp-master send someone who runs 
such buildds mail to please stop it ...)
[...]
16:18 aj | and now aurel32 will presumably fly off the handle
16:22aba | aj: I don't think that is a good idea either if the porters do 
uploads - i.e. blacklisting is probably better than whitelisting
16:23aba | aj: and please let e.g. people upload to non-free and 
experimental, e.g. tbm or kmuto
16:28 aj | aba: not at this time

  Aurelien mailed debian-arm, went to #debian-arm, had no response. He
then warn about his intention [1] to run qemu-based autobuilders to fill
the gap due to broken arm buildds. He did that on the open, and got ...
zero answers.

  I must say I'm shocked to see he has not been contacted yet, to kindly
ask him to stop. This looks like a petty personnal war, whereas aurelien
did a wonderful work.

  So, why :
  * does aurelien initiative causes troubles ?
  * aurelien hasn't been contacted by the ftp-master team first ?
aurelien is really easy to contact, so there is no excuse to this
completely inadequate behavior.
  * do someone found the time to blacklist everybody except elmo,
whereas no one found the time to fix the arm build daemons ?


  I also noted that now that only elmo can upload arm packages, the
whole arch:any packages migration to testing can be stuck by a single
man, I really really ask the DPL that took this decision to (1)
reconsider, (2) explain himself about that.


Full quote as Aurelien was not Cc-ed...

First I don't think the DPL took that decision...

How did Aurelien get wanna-build access for his buildd without 
explaining to the respective team how the buildd was maintained in the 
first place or did he not ask for it...


Cheers

Luk


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

restricted sourceless ARM uploads

[Aurelien Jarno]

Hi,

For those who don't know, I have setup 8 emulated ARM build daemons and
started to upload packages. To know why and for more information, see
[1].

These afternoon I saw on #debian-release:

 15:52:11  aj | "# unilateral action to run an emulated buildd -- all arm 
changes sidelined until fixed."
 16:18:59  aj | and now aurel32 will presumably fly off the handle
 16:22:37 aba | aj: I don't think that is a good idea either if the porters do 
uploads - i.e. blacklisting is probably better than whitelisting
 16:23:14 aba | aj: and please let e.g. people upload to non-free and 
experimental, e.g. tbm or kmuto
 16:28:16  aj | aba: not at this time
 16:28:28 aba | aj: at which time then?

First I am not very happy to learn that from IRC, I would have prefer to
get a mail. However I am very happy to see a reaction on the ARM build
daemons side, and this time really fast.

Usually, you have to wait that a user detect a problem and warns the
build daemon maintainer [2] [3]. And then wait again.

Note that I would have been happy to not start those build daemons, but
given the way the arm build daemons are administrated, something had to 
be done.

Anyway, I have been able to fix a few packages that were not built
successfully. For the others, I have extracted from wanna-build a list
of package that build successfully, but have failed to build for 
various reasons. I would like an explanation from the arm build daemon
maintainer why they are still on this state:

* Packages that now build fine:
   blam_1.8.3-2 (for 40 days)
   evolution-sharp_0.11.1-3 (for 9 days)
   gcc-h8300-hms_4.1.1-3 (for 7 days)
   hdbc-odbc_1.0.1.1 (for 40 days) 
   hdbc-missingh_1.0.1.1 (for 40 days)
   njb-sharp_0.3.0-1 (for 9 days)
   muine_0.8.5-1.1 (for 9 days)
  
* Packages lost from elara (not uploaded for more than 5 days). Note
  that it is obvious using [4] to see there is a problem:
   complearn-gui_0.9.7-1 
   grhino_0.15.2-1 
   iwatch_0.0.12-3 
   libdiscid_0.1.0-1 
   libvorbisidec_1.0.2+svn12153-1 
   lush_1.2.1-3 
   nec2c_0.6-1 
   nmap_4.20-1 
   units-filter_2.6-1 
   xmms2_0.2DrHouse-3 
  
* Packages that failed to build because the build daemon netwinder is
  fucked for weeks wrt to /usr/lib/libtasn1.so.3.0.6
   cpufire-applet_1.2-2 
   gnome-session_2.14.3-4 

* Package that is wrongly waiting for kaffe-jthreads for more than a 
  year:
   libgconf-java_2.12.3-1 
  
* Package that failed to build because it build depends on a package
  not uploaded fast enough. It has never been requeued.
   python-gnome_1.4.5-8 
  
* Also those package (and they are plenty others), could be tagged
  not-for-us. This would spare some build daemon time, and would ease to
  see which packages have really failed to build or not.
   cryopid_0.5.9.1-2
   dfsbuild_0.99.2
   dphys-kernel-packages_20061027-2
   gcc-4.0_4.0.3ds1-8
   gnat-4.1_4.1.1-19
   hs-plugins_0.9.10-3.4
   lcdproc_0.5.1-3
   libflorist_2006-1
   libopenspc_0.3.99a-2
   libpfm3-3.2_3.2.060926-2
   libx86_0.99-1
   linux-modules-di-mips-2.6_1.00
   linux-uvc_0.1.0.svn54-4
   mit-scheme_7.7.90+20060906-3
   openafs_1.4.2-4
   pdns-recursor_3.1.4-1
   xmms-openspc_0.0.4-2
   xen-3.0_3.0.3-0-2
   xen-unstable_3.0-unstable+hg11561-1

Also why the packages ctypes and kbedic are in state building for more
than 17 days, without any action from the build daemon maintainer?

Bye,
Aurelien

[1] http://blog.aurel32.net/?p=33
[2] http://lists.debian.org/debian-arm/2006/11/msg00052.html
[3] http://lists.debian.org/debian-arm/2006/12/msg00027.html
[4] http://buildd.debian.org/~jeroen/status/architecture.php?a=arm

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


signature.asc
Description: Digital signature

Re: Explications needed...

[Michael Banck]

On Wed, Dec 20, 2006 at 05:03:35PM +0100, Pierre Habouzit wrote:
>   Aurelien mailed debian-arm, went to #debian-arm, had no response. He
> then warn about his intention [1] to run qemu-based autobuilders to fill
> the gap due to broken arm buildds. He did that on the open, and got ...
> zero answers.

He wrote in his blog about setting up an emulated arm buildd, but didn't
explicitely say he'd upload .debs with it (though one could maybe read
that between the lines).

I have just written about this on -project (Subject: Rogue autobuilders
(was: Re: New ARM autobuilders)), I suggest we move the discussion over
there as it is not related to package development but a
distribution-wide issue.


cheers,

Michael


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

Re: Explanations needed...

[Pierre Habouzit]

On Wed, Dec 20, 2006 at 05:03:35PM +0100, Pierre Habouzit wrote:
>   I happened to have had access to the internet during my vacation, and
> I happened to read a backlog on #debian-release that frightens me:
> 
> [...]
>
>   So, why :
>   * does aurelien initiative causes troubles ?

  especially since the same is done with aranym for m68k, and it's
  going to save this port, according to [2]

>   * aurelien hasn't been contacted by the ftp-master team first ?
> aurelien is really easy to contact, so there is no excuse to this
> completely inadequate behavior.
>   * do someone found the time to blacklist everybody except elmo,
> whereas no one found the time to fix the arm build daemons ?
> 
> 
>   I also noted that now that only elmo can upload arm packages, the
> whole arch:any packages migration to testing can be stuck by a single
> man, I really really ask the DPL that took this decision to (1)
> reconsider, (2) explain himself about that.
> 
> 
> Kindly,
> 
>   [1] http://blog.aurel32.net/?p=33
[2] http://buildd.debian.org/stats/graph-quarter-big.png
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpchj4imZIWk.pgp
Description: PGP signature

Explications needed...

[Pierre Habouzit]

  I happened to have had access to the internet during my vacation, and
I happened to read a backlog on #debian-release that frightens me:

15:52 aj | "# unilateral action to run an emulated buildd -- all arm 
changes sidelined until fixed."
15:52aba | oh, where?
15:52 aj | cron.unchecked, -> queue/delayed
[...]
15:58aba | (and btw, I would expect that ftp-master send someone who runs 
such buildds mail to please stop it ...)
[...]
16:18 aj | and now aurel32 will presumably fly off the handle
16:22aba | aj: I don't think that is a good idea either if the porters do 
uploads - i.e. blacklisting is probably better than whitelisting
16:23aba | aj: and please let e.g. people upload to non-free and 
experimental, e.g. tbm or kmuto
16:28 aj | aba: not at this time

  Aurelien mailed debian-arm, went to #debian-arm, had no response. He
then warn about his intention [1] to run qemu-based autobuilders to fill
the gap due to broken arm buildds. He did that on the open, and got ...
zero answers.

  I must say I'm shocked to see he has not been contacted yet, to kindly
ask him to stop. This looks like a petty personnal war, whereas aurelien
did a wonderful work.

  So, why :
  * does aurelien initiative causes troubles ?
  * aurelien hasn't been contacted by the ftp-master team first ?
aurelien is really easy to contact, so there is no excuse to this
completely inadequate behavior.
  * do someone found the time to blacklist everybody except elmo,
whereas no one found the time to fix the arm build daemons ?


  I also noted that now that only elmo can upload arm packages, the
whole arch:any packages migration to testing can be stuck by a single
man, I really really ask the DPL that took this decision to (1)
reconsider, (2) explain himself about that.


Kindly,

  [1] http://blog.aurel32.net/?p=33
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp0e7FVPoKzu.pgp
Description: PGP signature

Bug#403897: ITP: libwps -- Works text file format import filter library

[Rene Engelhard]

Package: wnpp
Severity: wishlist
Owner: Rene Engelhard <[EMAIL PROTECTED]>

* Package name: libwps
  Version : no release yet
  Upstream Author : Andrew Ziem <[EMAIL PROTECTED]>
* URL : http://libwps.sf.net
* License : LGPL
  Programming Lang: C++
  Description : Works text file format import filter library

 libwps is a library (for use by word procesors, for example) for importing the
 Microsoft Works word processor file format. As of November 2006, the project
 is new, but it imports Works format versions 2, 3, 4, and 8 with some
 formatting. Support for Works formats version 2000 (aka 5) is coming soon.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-powerpc
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


signature.asc
Description: Digital signature

Re: libesd0 v libesd-alsa0

[Josselin Mouette]

Le mercredi 20 décembre 2006 à 13:29 +, Sam Morris a écrit :
> > In all cases, as esound is buggy and unmaintained in Debian, it is
> > deactivated by default at least in all GNOME software. The default for
> > gstreamer, vlc, xine and others is to use direct ALSA output, which, as
> > you explained, has software mixing enabled by default.
> 
> This doesn't seem to be the case. I noticed this problem because I have
> had to help a couple of newbies on IRC get their sound working over the
> last couple of days. In both cases the culprit was esd which was holding
> open the sound device. Installing libesd-alsa0 and killing esd made
> everything work again.
> 
> Perhaps it was something they did to their systems themselves after
> installing Etch?

ESD shouldn't be started unless you check the appropriate box in the
GNOME sound preferences.

-- 
Josselin Mouette/\./\

"Do you have any more insane proposals for me?"

Re: Bug#403862: ITP: pdfcube -- PDF presentation programm with eyecandy 3D effects

[Alexander Wirt]

Joachim Breitner schrieb am Mittwoch, den 20. Dezember 2006:

*snip*

> Interesting. It seems to be similar to keyjnote. Does it support
> clicking on internal links of the pdf document, or is it just rendering
> the pdf as ???dumb images??? on the screen?
It looks like that they are just rendered as images, but pdfcube is in a very
early stage, so hopefully this will change. 

> Maybe there should be a shared library of 3D transitions effects that
> can be used by pdfcube, keyjnote, xscreensaver, compiz...
Interesting idea, this should improve the quality of all 3D transitions used
by them...

Alex


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

Re: libesd0 v libesd-alsa0

[Sam Morris]

On Wed, 20 Dec 2006 13:55:03 +0100, Josselin Mouette wrote:

> Le mercredi 20 décembre 2006 à 11:33 +, Sam Morris a écrit :
>> On Wed, 20 Dec 2006 10:15:47 +0300, Vladimir Kozlov wrote:
>> > Somehow I had libesd0 installed while I have alsa as well, and this
>> > prevents alsa from working properly - I had to do alsaconf after each
>> > reboot.
>> > Shouldn't the libesd-alsa0 be automatically installed with alsa instead
>> > the libesd0?
>> > 
>> > Please CC me as I'm not in the debian-devel list.
>> 
>> It is a shame that libesd0 is instaled by default instead of libesd-alsa0
>> but AFAIK it's too late in the release cycle to do anything about it. :(
>> 
>> I think the best way would be to change the shlibs information for
>> libesd0 so that packages that use it end up depending on "libesd-alsa0 |
>> libesd0". However that would require a rebuild of all depending packages.
>> 
>> Perhaps the installer could be hacked to install libesd-alsa0 by default
>> or something. It would be great if we didn't have to go through _another_
>> release where users will have to put up with programs hogging their sound
>> cards, especially since alsa-lib now has software mixing configured by
>> default.
> 
> Last time I tried, libesd-alsa0 was corrupting sound in a horrible way.
> 
> In all cases, as esound is buggy and unmaintained in Debian, it is
> deactivated by default at least in all GNOME software. The default for
> gstreamer, vlc, xine and others is to use direct ALSA output, which, as
> you explained, has software mixing enabled by default.

This doesn't seem to be the case. I noticed this problem because I have
had to help a couple of newbies on IRC get their sound working over the
last couple of days. In both cases the culprit was esd which was holding
open the sound device. Installing libesd-alsa0 and killing esd made
everything work again.

Perhaps it was something they did to their systems themselves after
installing Etch?

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078


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

Re: libesd0 v libesd-alsa0

[Josselin Mouette]

Le mercredi 20 décembre 2006 à 11:33 +, Sam Morris a écrit :
> On Wed, 20 Dec 2006 10:15:47 +0300, Vladimir Kozlov wrote:
> > Somehow I had libesd0 installed while I have alsa as well, and this
> > prevents alsa from working properly - I had to do alsaconf after each
> > reboot.
> > Shouldn't the libesd-alsa0 be automatically installed with alsa instead
> > the libesd0?
> > 
> > Please CC me as I'm not in the debian-devel list.
> 
> It is a shame that libesd0 is instaled by default instead of libesd-alsa0
> but AFAIK it's too late in the release cycle to do anything about it. :(
> 
> I think the best way would be to change the shlibs information for
> libesd0 so that packages that use it end up depending on "libesd-alsa0 |
> libesd0". However that would require a rebuild of all depending packages.
> 
> Perhaps the installer could be hacked to install libesd-alsa0 by default
> or something. It would be great if we didn't have to go through _another_
> release where users will have to put up with programs hogging their sound
> cards, especially since alsa-lib now has software mixing configured by
> default.

Last time I tried, libesd-alsa0 was corrupting sound in a horrible way.

In all cases, as esound is buggy and unmaintained in Debian, it is
deactivated by default at least in all GNOME software. The default for
gstreamer, vlc, xine and others is to use direct ALSA output, which, as
you explained, has software mixing enabled by default.

-- 
Josselin Mouette/\./\

"Do you have any more insane proposals for me?"

Re: libesd0 v libesd-alsa0

[Sam Morris]

On Wed, 20 Dec 2006 10:15:47 +0300, Vladimir Kozlov wrote:
> Somehow I had libesd0 installed while I have alsa as well, and this
> prevents alsa from working properly - I had to do alsaconf after each
> reboot.
> Shouldn't the libesd-alsa0 be automatically installed with alsa instead
> the libesd0?
> 
> Please CC me as I'm not in the debian-devel list.

It is a shame that libesd0 is instaled by default instead of libesd-alsa0
but AFAIK it's too late in the release cycle to do anything about it. :(

I think the best way would be to change the shlibs information for
libesd0 so that packages that use it end up depending on "libesd-alsa0 |
libesd0". However that would require a rebuild of all depending packages.

Perhaps the installer could be hacked to install libesd-alsa0 by default
or something. It would be great if we didn't have to go through _another_
release where users will have to put up with programs hogging their sound
cards, especially since alsa-lib now has software mixing configured by
default.

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078


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

Re: block device served over network connections

[Wouter Verhelst]

On Mon, Dec 18, 2006 at 02:26:14AM -0700, Warren Turkal wrote:
> DDs,
> 
> I am looking for some info on this subject. I have looked at both the 
> aoetools 
> and open-iscsi for a solution to the following problem.
> 
> I have a block device that is served over aoe. Basically, I would like to 
> take 
> two of these devices (e0.0 and e1.0) and create a raid1 with software RAID. 
> However, I am not really sure how to solve this one. I am emailing here 
> because I think the infrastructure to do such a thing may not exist in 
> Debian.
> 
> The basic problem is the network devices that receive info related to the 
> block device must be up early enough that the mdadm discovery has not 
> happened. It would be fairly easy to right a script that simply 
> does "ifconfig eth0 up" and performs discovery (additionally 
> disabling /etc/rcS.d/S41aoetools and essentially doing my own thing), but I 
> would like to know if there is official Debian infrastructure for this sort 
> of thing.

Just rearrange the initscripts so that mdadm is ran _after_ aoetools.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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