Bug#514237: debian-cd: Support non-i386 mirrors, and support D-I modules in non-main
On Thursday 05 February 2009, Frans Pop wrote: > We currently use the Packages file from i386 to expand a task to a s/currently use/currently always use/ > package list. Essentially this is broken because different arches can > have different dependencies! And also - probably more importantly - because some packages that belong to a task may not be available for all architectures. This means that for example if a task lists a powerpc- or sparc-specific package, it will currently not get included on the CD (unless it gets included for other reasons of course). This won't affect installs where a mirror is used, but can affect installs from CD/DVD only. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514237: debian-cd: Support non-i386 mirrors, and support D-I modules in non-main
On Thursday 05 February 2009, Jonathan Hall wrote: > Frans Pop wrote: > > Wouldn't it make much more sense for which_deb to just try the > > current arch(es) (the one(s) for which we're building the image) > > instead of trying arches randomly? Or at least to try relevant arches > > first? > > This works fine, except when building a source-only CD Then I'm > back to looking through all possible arches, unless someone can think > of a more reasonable thing to do in that case..? For the calls from boot-* it does not matter as those scripts won't be called for source only CDs. So we're left with the call from update_tasks. There we really have another, more fundamental issue that has to be considered. We currently use the Packages file from i386 to expand a task to a package list. Essentially this is broken because different arches can have different dependencies! In practice this problem is quite limited, but it _is_ important that we don't use one of the more obscure arches to build the list as that is *a lot* more likely to result in a broken expanded package list than when we use i386 or amd64. So IMO: * ideally we should run update_tasks for every architecture separately, using the Packages file for that arch; for source-only CDs we should use i386 with fallback to amd64, and fail otherwise * but as long as we do not do that - for binary or binary/source CDs: prefer i386, with fallback to: 1) amd64 2) arches listed in $ARCHES - for source-only CDs: use i386, with fallback to amd64, and fail otherwise IMO it's reasonable to fail if someone wants to build source only but does not have a full mirror, or at least has the most common arches. Other cases will be extremely rare, and if someone really wants to he can just modify the script. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Meeting(s) at FOSDEM
This one time, at band camp, Mark Hymers said: > On Thu, 05, Feb, 2009 at 12:30:46PM +, Steve McIntyre spoke thus.. > > >>Apologies for the massive cross-posting, but I'm trying to arrange > > >>some discussions between the various teams, or at least those members > > >>who will be at FOSDEM. Topics I'd like us to talk about include: > > >> > > >> 1. how the d-i daily builds are done and distributed > > >> 2. how the needs of the kernel d-i teams can better be reconciled > > >> > > >>I'm guessing that quite a number of people may be interested in these, > > >>and in other topics. Is there anything else I'm missing that you would > > >>like to discuss? > > >> > > >>Then: when and where would be a good time to meet up? > > > > Hello? Anyone? > > Hi, > > I agree that it'd be a good idea to meet up and I'll make sure I'm there > wearing my ftpteam hat (note, not ftpmaster so I can't finally agree to > anything, but I'm willing to put any work in on the ftp side which is > needed). > > I'm around all weekend up until Sunday afternoon at about 3, so whatever > works for everyone else will be fine by me. I'll be around from ~1800 on Friday until midafteroon on Sunday, and think a meetup would be a good thing. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#514237: debian-cd: Support non-i386 mirrors, and support D-I modules in non-main
Frans Pop wrote: Wouldn't it make much more sense for which_deb to just try the current arch(es) (the one(s) for which we're building the image) instead of trying arches randomly? Or at least to try relevant arches first? This works fine, except when building a source-only CD Then I'm back to looking through all possible arches, unless someone can think of a more reasonable thing to do in that case..? -- Jonathan -- Inbound and outbound email scanned for spam and viruses by the DoubleCheck Email Manager: http://www.doublecheckemail.com -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Meeting(s) at FOSDEM
Hi, On Thu Feb 05, 2009 at 12:30:46 +, Steve McIntyre wrote: > >On Sun, Feb 01, 2009 at 02:53:58PM +, Steve McIntyre wrote: > >>Hi folks, > >> > >>Apologies for the massive cross-posting, but I'm trying to arrange > >>some discussions between the various teams, or at least those members > >>who will be at FOSDEM. Topics I'd like us to talk about include: > >> > >> 1. how the d-i daily builds are done and distributed > >> 2. how the needs of the kernel d-i teams can better be reconciled > >> > >>I'm guessing that quite a number of people may be interested in these, > >>and in other topics. Is there anything else I'm missing that you would > >>like to discuss? > >> > >>Then: when and where would be a good time to meet up? > > Hello? Anyone? not sure if i am going to fosdem at all. MAYBE i will go on sunday, but that is not carved in stone yet. Greetings Martin -- Martin Zobel-Helas | Debian System Administrator Debian & GNU/Linux Developer | Debian Listmaster Public key http://zobel.ftbfs.de/5d64f870.asc - KeyID: 5D64 F870 GPG Fingerprint: 5DB3 1301 375A A50F 07E7 302F 493E FB8E 5D64 F870 -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Environment variables vs. command-line arguments
Do you prefer to have cleanup patches submitted to the list, or as wishlist bugs? Patches / suggestions welcome to start cleaning things up, although obviously major changes will have to be post-lenny now.. -- Inbound and outbound email scanned for spam and viruses by the DoubleCheck Email Manager: http://www.doublecheckemail.com -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Meeting(s) at FOSDEM
Steve McIntyre writes: >>>Then: when and where would be a good time to meet up? > > Hello? Anyone? I won't be at FOSDEM :( -- O T A V I OS A L V A D O R - E-mail: ota...@debian.org UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Environment variables vs. command-line arguments
I'm on the list. I agree. MIRROR should definitely not be passed in as an argument as "local" can have a different mirror path (LOCALDEBS) from the main mirror (MIRROR). which_deb should support that. That's exactly what I was running into... trying to expand to support "other" components, I realized I can't easily support MIRROR, LOCAL, and OTHER using command-line arguments. P.S. Are you subscribed to the list or should we continue to CC you? I am on the list. -- Inbound and outbound email scanned for spam and viruses by the DoubleCheck Email Manager: http://www.doublecheckemail.com -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Environment variables vs. command-line arguments
On Thursday 05 February 2009, Jonathan Hall wrote: > It seems there is quite a hodge-podge of calling conventions for > passing config variables to the scripts in the tools/ directory. > Several scripts take command line arguments; others use environment > variables. Some use both. > > Is there a method to this madness? > > It seems to me that it would be easier to use the environment for > standard config variables (such as MIRROR, NONFREE, etc, etc) > > which_deb, for instance, takes the config variables of MIRROR and > CODENAME as its first two arguments, followed by a package name and > output format (which I believe should be arguments). I agree. MIRROR should definitely not be passed in as an argument as "local" can have a different mirror path (LOCALDEBS) from the main mirror (MIRROR). which_deb should support that. P.S. Are you subscribed to the list or should we continue to CC you? signature.asc Description: This is a digitally signed message part.
Bug#514237: debian-cd: Support non-i386 mirrors, and support D-I modules in non-main
On Thu, Feb 05, 2009 at 04:52:57PM +0100, Frans Pop wrote: >On Thursday 05 February 2009, Jonathan Hall wrote: >> Index: debian-cd/tools/update_tasks >> === >> --- debian-cd/tools/update_tasks (revision 7407) >> +++ debian-cd/tools/update_tasks (revision 7487) >> @@ -1,5 +1,6 @@ >> #!/bin/sh >> set -e >> +ARCHES="alpha arm armel hppa hurd-i386 i386 ia64 mips mipsel powerpc >> s390 sparc amd64" >[...] >> -# We need to gunzip a copy of the appropriate Packages.gz file >> -# Assume i386, use the $CODENAME main Packages file >> +# We need to gunzip a copy of the appropriate Packages.gz file(s) >> +# Find an arch that exists in our mirror... >> +for arch in $ARCHES; do >> +if [ -e $MIRROR/dists/$CODENAME/main/binary-$arch ]; then break; >> fi >> +done > >Wouldn't it be much simpler to use tools/which_deb instead? >That would also avoid having arch lists (which will need to be updated!) >all over the place. Yup, sounds better. I'm hoping to reduce the number of places with arch lists as we move forwards... >> --- debian-cd/tools/which_deb (revision 7407) >> +++ debian-cd/tools/which_deb (revision 7487) > >Wouldn't it make much more sense for which_deb to just try the current >arch(es) (the one(s) for which we're building the image) instead of >trying arches randomly? Or at least to try relevant arches first? > >This will limit the use of the script a bit, but as it is currently only >called from boot-* scripts it isn't a problem. > >If it is also called from update_tasks it should still not be a problem, >though in that case ARCH will not yet be set and you'd have to take >ARCHES. > >Maybe ARCH/ARCHES should be passed as a parameter instead of being >hardcoded. That might work, yes. With a fallback for each of the things we're looking for; in some cases you just want to find *one* of the debs. Simply pass in a list of acceptable arches and tell the code in which_deb work it out from there? -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Dasmohapatra -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Environment variables vs. command-line arguments
Hi Jonathan, On Thu, Feb 05, 2009 at 09:57:31AM -0600, Jonathan Hall wrote: > It seems there is quite a hodge-podge of calling conventions for passing > config variables to the scripts in the tools/ directory. Several > scripts take command line arguments; others use environment variables. > Some use both. > > Is there a method to this madness? > > It seems to me that it would be easier to use the environment for > standard config variables (such as MIRROR, NONFREE, etc, etc) > > which_deb, for instance, takes the config variables of MIRROR and > CODENAME as its first two arguments, followed by a package name and > output format (which I believe should be arguments). Is there a reason > this couldn't be read from the environment? (Thus making it more > consistent with other scripts, as well as more expandable, IMO) It's basically historical accident in a few cases, I'll admit. Some of the scripts have been written by different people at different times, with differing ideas about how to do things. Some of the scripts may also be called in different contexts where we may or may not have the environment set up appropriately. Patches / suggestions welcome to start cleaning things up, although obviously major changes will have to be post-lenny now.. -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Environment variables vs. command-line arguments
It seems there is quite a hodge-podge of calling conventions for passing config variables to the scripts in the tools/ directory. Several scripts take command line arguments; others use environment variables. Some use both. Is there a method to this madness? It seems to me that it would be easier to use the environment for standard config variables (such as MIRROR, NONFREE, etc, etc) which_deb, for instance, takes the config variables of MIRROR and CODENAME as its first two arguments, followed by a package name and output format (which I believe should be arguments). Is there a reason this couldn't be read from the environment? (Thus making it more consistent with other scripts, as well as more expandable, IMO) -- Jonathan -- Inbound and outbound email scanned for spam and viruses by the DoubleCheck Email Manager: http://www.doublecheckemail.com -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514237: debian-cd: Support non-i386 mirrors, and support D-I modules in non-main
On Thursday 05 February 2009, Jonathan Hall wrote: > Index: debian-cd/tools/update_tasks > === > --- debian-cd/tools/update_tasks (revision 7407) > +++ debian-cd/tools/update_tasks (revision 7487) > @@ -1,5 +1,6 @@ > #!/bin/sh > set -e > +ARCHES="alpha arm armel hppa hurd-i386 i386 ia64 mips mipsel powerpc > s390 sparc amd64" [...] > -# We need to gunzip a copy of the appropriate Packages.gz file > -# Assume i386, use the $CODENAME main Packages file > +# We need to gunzip a copy of the appropriate Packages.gz file(s) > +# Find an arch that exists in our mirror... > +for arch in $ARCHES; do > +if [ -e $MIRROR/dists/$CODENAME/main/binary-$arch ]; then break; > fi > +done Wouldn't it be much simpler to use tools/which_deb instead? That would also avoid having arch lists (which will need to be updated!) all over the place. > --- debian-cd/tools/which_deb (revision 7407) > +++ debian-cd/tools/which_deb (revision 7487) Wouldn't it make much more sense for which_deb to just try the current arch(es) (the one(s) for which we're building the image) instead of trying arches randomly? Or at least to try relevant arches first? This will limit the use of the script a bit, but as it is currently only called from boot-* scripts it isn't a problem. If it is also called from update_tasks it should still not be a problem, though in that case ARCH will not yet be set and you'd have to take ARCHES. Maybe ARCH/ARCHES should be passed as a parameter instead of being hardcoded. signature.asc Description: This is a digitally signed message part.
Bug#514237: Patch closes two other bugs
Pardon my indiligence... I didn't notice that in the last week two bugs had already been filed that I should have submitted my patch against. At any rate, this patch should close #513497 and #513498. So perhaps some bug merging should take place. -- Jonathan -- Inbound and outbound email scanned for spam and viruses by the DoubleCheck Email Manager: http://www.doublecheckemail.com -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514237: debian-cd: Support non-i386 mirrors, and support D-I modules in non-main
Package: debian-cd
Version: 3.1.0-nymgy1
Severity: wishlist
Tags: patch
This patch adds two features to debian-cd, filed as a single bug/patch, per
Steve McIntyre's suggestion on the mailing list:
1) It no longer requires the existence of the i386 architecture in the
mirror to build non-i386 CD images.
2) It no longer requires that all D-I modules (udebs) exist in the 'main'
component
I have tested this patch to work when building the following combinations of
CDs from a mirror with binary-i386, binary-amd64, and source archs:
binary-i386
binary-i386 + source
binary-amd64
binary-amd64 + source
binary-i386 + binary-amd64
binary-i386 + binary-amd64 + source
source
I have also tested it to build the following CDs from a mirror with only
binary-amd64 and source archs:
binary-amd64
binary-amd64 + source
source
I have not tested with any other architectures, or CD combinations but I
beleive this patch should work with any architecture(s).
*** /home/jonhall/non-i386.patch
Index: debian-cd/tools/update_tasks
===
--- debian-cd/tools/update_tasks(revision 7407)
+++ debian-cd/tools/update_tasks(revision 7487)
@@ -1,5 +1,6 @@
#!/bin/sh
set -e
+ARCHES="alpha arm armel hppa hurd-i386 i386 ia64 mips mipsel powerpc s390
sparc amd64"
if [ -z "$CODENAME" ]; then
echo "update_tasks: codename not specified" >&2
@@ -149,10 +150,14 @@
}' | sort -s -n -k1 | cut -d: -f2 >> $file
}
-# We need to gunzip a copy of the appropriate Packages.gz file
-# Assume i386, use the $CODENAME main Packages file
+# We need to gunzip a copy of the appropriate Packages.gz file(s)
+# Find an arch that exists in our mirror...
+for arch in $ARCHES; do
+if [ -e $MIRROR/dists/$CODENAME/main/binary-$arch ]; then break; fi
+done
TMP_PKG=$TDIR/Packages
-zcat $MIRROR/dists/$CODENAME/main/binary-i386/Packages.gz > $TMP_PKG
+zcat $MIRROR/dists/$CODENAME/main/binary-$arch/Packages.gz > $TMP_PKG
+[ -n "$LOCAL" ] && zcat $MIRROR/dists/$CODENAME/local/binary-$arch/Packages.gz
>> $TMP_PKG
# Now grab the appropriate tasksel package
TASKSEL_DEB=$MIRROR/`mawk '
Index: debian-cd/tools/make_disc_trees.pl
===
--- debian-cd/tools/make_disc_trees.pl (revision 7407)
+++ debian-cd/tools/make_disc_trees.pl (revision 7487)
@@ -735,7 +735,7 @@
}
$pdir = "$dir/dists/$codename/$dist";
-if ($section eq "debian-installer") {
+if ($section and $section eq "debian-installer") {
$pdir = "$dir/dists/$codename/$dist/debian-installer";
}
return $pdir;
Index: debian-cd/tools/generate_di_list
===
--- debian-cd/tools/generate_di_list(revision 7407)
+++ debian-cd/tools/generate_di_list(revision 7487)
@@ -24,32 +24,38 @@
EOF
my @common_excludes = read_exclude("exclude-udebs");
-
+my $mirror_path = "$ENV{MIRROR}/dists/$ENV{DI_CODENAME}";
+opendir COMP, $mirror_path;
+my @components = grep { -d "$mirror_path/$_" and $_ !~ /^\./ } readdir COMP;
+close COMP;
foreach my $arch (@ARCHES) {
- my
$packagefile="$ENV{MIRROR}/dists/$ENV{DI_CODENAME}/main/debian-installer/binary-$arch/Packages.gz";
- unless (-f $packagefile) {
- print "Missing package file for arch $arch.\n";
- next;
- }
(my $cpparch = $arch) =~ s/-/_/g;
- print OUT "#ifdef ARCH_$cpparch\n";
- my @exclude = @common_excludes;
- push @exclude, read_exclude("exclude-udebs-$arch")
- if -e exclude_path("exclude-udebs-$arch");
-UDEB: foreach my $udeb (map { chomp; $_ } `zcat $packagefile | awk
'/^Package:/ {print \$2}'`) {
- foreach my $pattern (@exclude) {
- if ($udeb =~ /^$pattern$/) {
- next UDEB;
- }
+ my $output = '';
+ for my $component ( @components ) {
+ my
$packagefile="$mirror_path/$component/debian-installer/binary-$arch/Packages.gz";
+ unless ( -f $packagefile ) {
+ print "Missing package file for $component/$arch.\n";
+ next;
}
- print OUT "$udeb\n";
+ my @exclude = @common_excludes;
+ push @exclude, read_exclude("exclude-udebs-$arch")
+ if -e exclude_path("exclude-udebs-$arch");
+ foreach my $udeb (map { chomp; $_ } `zcat $packagefile | awk
'/^Package:/ {print \$2}'`) {
+ $output .= "$udeb\n" unless grep { $udeb =~ /^${_}$/ }
@exclude;
+ }
}
+ next unless $output;
+ print OUT "#ifdef ARCH_$cpparch\n";
+ print OUT $output;
print OUT "#endif /* ARCH_$cpparch */\n";
}
sub read_exclude {
my $file=exclude_path(shift);
- open (IN, "<$file") || warn "failed to read exclude file $file";
+ un
Re: Meeting(s) at FOSDEM
On Thu, Feb 05, 2009 at 12:30:46PM +, Steve McIntyre wrote: > >On Sun, Feb 01, 2009 at 02:53:58PM +, Steve McIntyre wrote: > >>Hi folks, > >> > >>Apologies for the massive cross-posting, but I'm trying to arrange > >>some discussions between the various teams, or at least those members > >>who will be at FOSDEM. Topics I'd like us to talk about include: > >> > >> 1. how the d-i daily builds are done and distributed > >> 2. how the needs of the kernel d-i teams can better be reconciled > >> > >>I'm guessing that quite a number of people may be interested in these, > >>and in other topics. Is there anything else I'm missing that you would > >>like to discuss? > >> > >>Then: when and where would be a good time to meet up? > > Hello? Anyone? Friday or Saturday evening in the centre, or perhaps lunch-time in/near ULB. Ben. -- Ben Hutchings Logic doesn't apply to the real world. - Marvin Minsky -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Meeting(s) at FOSDEM
On Thu, 2009-02-05 at 12:30 +, Steve McIntyre wrote: > >>Then: when and where would be a good time to meet up? Given we all tend to arrive in dribs-and-drabs on Friday night, I'd suggest Saturday some time. Perhaps either have a "working lunch" or, if the group is likely to be too large, perhaps take over the back room of that bar with the black and white sign near the Atlas hotel in the evening on Saturday? Ultimately so long as it's after about 9pm Friday night, and before about 3pm Sunday afternoon, I'll happy :-) D. -- Daniel Silverstonehttp://www.debian.org/ PGP mail accepted and encouraged.Key Id: 2BC8 4016 2068 7895 signature.asc Description: This is a digitally signed message part
Re: Meeting(s) at FOSDEM
On Thursday 05 February 2009, Steve McIntyre wrote: > >On Sun, Feb 01, 2009 at 02:53:58PM +, Steve McIntyre wrote: > >>Hi folks, > >> > >>Apologies for the massive cross-posting, but I'm trying to arrange > >>some discussions between the various teams, or at least those members > >>who will be at FOSDEM. Topics I'd like us to talk about include: > >> > >> 1. how the d-i daily builds are done and distributed > >> 2. how the needs of the kernel d-i teams can better be reconciled > >> > >>I'm guessing that quite a number of people may be interested in > >> these, and in other topics. Is there anything else I'm missing that > >> you would like to discuss? > >> > >>Then: when and where would be a good time to meet up? > > Hello? Anyone? As I've already made my opinion clear by mail on the first issue I don't see much point in a meeting unless others show an interest in it. For the second issue I doubt that FOSDEM is the right venue. I'll be at FOSDEM and if there is a meeting I'm willing to attend. I can explain some of the technical issues involved and explain why IMO triggering daily builds by uploads is a very bad idea. signature.asc Description: This is a digitally signed message part.
Re: Meeting(s) at FOSDEM
On Thu, 05, Feb, 2009 at 12:30:46PM +, Steve McIntyre spoke thus.. > >>Apologies for the massive cross-posting, but I'm trying to arrange > >>some discussions between the various teams, or at least those members > >>who will be at FOSDEM. Topics I'd like us to talk about include: > >> > >> 1. how the d-i daily builds are done and distributed > >> 2. how the needs of the kernel d-i teams can better be reconciled > >> > >>I'm guessing that quite a number of people may be interested in these, > >>and in other topics. Is there anything else I'm missing that you would > >>like to discuss? > >> > >>Then: when and where would be a good time to meet up? > > Hello? Anyone? Hi, I agree that it'd be a good idea to meet up and I'll make sure I'm there wearing my ftpteam hat (note, not ftpmaster so I can't finally agree to anything, but I'm willing to put any work in on the ftp side which is needed). I'm around all weekend up until Sunday afternoon at about 3, so whatever works for everyone else will be fine by me. Cheers, Mark -- Mark Hymers "'I regret nothing?' That's not a song, that's an idiots charter." Andy Hamilton, Old Harry's Game signature.asc Description: Digital signature
Re: Meeting(s) at FOSDEM
Hi, On Donnerstag, 5. Februar 2009, Steve McIntyre wrote: > >>Then: when and where would be a good time to meet up? > Hello? Anyone? Looking at http://wiki.debian.org/FosdemVideo2009 I'd suggest either Saturday from 17:30-18:15 (right before your talk, Steve) or sunday between 10 and 13. Or saturday evening for dinner, but I'm quite sure that wont work out. regards, Holger signature.asc Description: This is a digitally signed message part.
Re: Meeting(s) at FOSDEM
>On Sun, Feb 01, 2009 at 02:53:58PM +, Steve McIntyre wrote: >>Hi folks, >> >>Apologies for the massive cross-posting, but I'm trying to arrange >>some discussions between the various teams, or at least those members >>who will be at FOSDEM. Topics I'd like us to talk about include: >> >> 1. how the d-i daily builds are done and distributed >> 2. how the needs of the kernel d-i teams can better be reconciled >> >>I'm guessing that quite a number of people may be interested in these, >>and in other topics. Is there anything else I'm missing that you would >>like to discuss? >> >>Then: when and where would be a good time to meet up? Hello? Anyone? -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
