Bug#590993: installation-reports: netboot install report broken mirror if installation CD is used as mirror
tags 590993 patch thanks It would be better if debian-cd was modified to only include the symlink for the suite actually specified in the Release file. The attached patch (tested) implements this. diff --git a/tools/start_new_disc b/tools/start_new_disc index cf00344..779f242 100755 --- a/tools/start_new_disc +++ b/tools/start_new_disc @@ -66,9 +66,6 @@ fi if [ ! -d $CDDIR/dists/$CODENAME ] ; then mkdir -p $CDDIR/dists/$CODENAME -for name in stable unstable frozen testing; do - ln -sf $CODENAME $CDDIR/dists/$name -done fi # Commodity link for tools which want local in dists/local/local ... @@ -336,6 +333,12 @@ if [ -e $MIRROR/dists/$CODENAME/Release ] ; then sed -i -e s/^Suite: .*$/Suite: stable/ dists/$CODENAME/Release sed -i -e s/^Description: .*$/Description: Debian $DEBVERSION Released $RDATE/ dists/$CODENAME/Release fi + + # Create the suite symlink + SUITE=$(sed -n /^Suite:/ s/.*: //p dists/$CODENAME/Release) + if [ -n $SUITE ] [ x$SUITE != x$CODENAME ]; then + ln -sf $CODENAME dists/$SUITE + fi else echo ERROR: Release file ($MIRROR/dists/$CODENAME/Release) is missing ! exit 1
Re: Bug#590993: installation-reports: netboot install report broken mirror if installation CD is used as mirror
reassign 590993 debian-cd severity 590993 normal thanks Since you are trying something that's not really supported, this is certainly *not* a grave issue. After all, a CD image is not a mirror even if both contain a repository. It is correct that the error occurs because CD images have symlinks for all suites to the release (codename) included on the CD. This is mostly for historic reasons and no longer has any purpose (since current versions of the installer select by codename instead of suite). In a bit more detail. The latest versions of choose-mirror (including the current Etch and Lenny versions) perform validity checks on the Release files and will reject a mirror as broken if the Release file under a suite symlink lists a different suite inside the Release file. It would be better if debian-cd was modified to only include the symlink for the suite actually specified in the Release file. Reassigning accordingly. Looks like my whole attempt to use the ISO image as netboot installation source is futile, as the files are not signed on the CD, so netinst gives up in the next step. This can be worked around by telling the installer to ignore the signatures. See the installation guide for details. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007302307.13388.elen...@planet.nl
Re: Multi-arch netinst getting too big
On Friday 09 July 2010, Steve McIntyre wrote: True. Any better suggestions? No. Not without doing substantial work on this, which I've already indicated I'm not going to do this release. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007091624.50160.elen...@planet.nl
Re: Multi-arch netinst getting too big
On Friday 09 July 2010, Ian Campbell wrote: In light of Frans' concern perhaps consider dropping 686 instead of 486? I think that will result in 686-bigmem being installed on systems which would have previously got 686 (I can confirm if necessary). This isn't necessarily a bad thing -- it enables NX support for one thing which is generally desirable. Last I know is that -bigmem is significantly slower on a lot of hardware than the plain 686 kernel. Also, in most cases the 64-bit -amd64 flavor is a *lot* better choice for most i386 users that have systems that have large memory or want NX support. We've had this discussion before! Multiple times. FWIW RHEL 6 (the beta at least) ships with only a PAE (aka 686-bigmem) kernel, I guess things are heading that way generally. I don't really care that much what RH does TBH. And I don't believe it's true anyway: things are moving towards 64-bit, not 32-bit with NX. Isn't perl going to be dropping from the netinsts now and won't that be sufficient? -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007091807.16732.elen...@planet.nl
Re: Multi-arch netinst getting too big
On Wednesday 16 June 2010, Steve McIntyre wrote: I'm afraid I don't have any good ideas. Is this particular image supposed to contain a complete base system or just enough to fetch the remainder of the base system from the net? The netinsts are meant to have the base system, yes. I can't see anything obvious myself that we can drop. Maybe time to give up on powerpc on that image, like we've done on the m-a DVD. Shame, but there's only so much stuff we can accommodate here. Anybody else have an opinion here? Frans/Joey? The i386 netinst has also grown substantially. The base system probably needs cleaning as part of the final preparations for Squeeze. I suspect ATM 2 versions of Python get installed for example, and probably some (old) libs have a too high priority. But partly it's normal growth: the G-I initrds are still larger than for Lenny due to the switch to X.Org. The kernel packages are undoubtedly bigger again and the addition of firmware packages will not have helped either. Someone will have to do a detailed comparison between Lenny and Squeeze images to see where the changes are and whether some cleanup is possible. Possibly some udebs and/or packages can be excluded. All inclusion/exclusion lists should be reviewed in general. Beside the netinsts, all first CD and DVD images will need careful review of contents as well: are desktops installable using first images only (at least for i386 and amd64)? One option may be to drop PDF and text versions of the manual. But space will have to be reserved for the Release Notes. I will not be doing any work on any of this myself this release. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201006162006.24570.elen...@planet.nl
Re: No daily image builds since March 22nd
On Friday 23 April 2010, Steve McIntyre wrote: On Fri, Apr 23, 2010 at 01:11:54PM +0100, Steve McIntyre wrote: On Fri, Apr 23, 2010 at 01:58:45AM +0200, Frans Pop wrote: On Monday 19 April 2010, Steve McIntyre wrote: BTW, we also need a new location for the log files. The old location [1] no longer works. [1] http://farbror.acc.umu.se/cdimage-log/ Of course, yes. I'll get that sorted too. Any progress? I notice that cdbuilder.d.o does have a webserver running, so I suspect this should be trivial. Sorry, forgot about this for a few days while I was doing other stuff. I've asked the DSA folks to add this now, hopefully should show up soon as http://cdbuilder.debian.org/cdimage-log/ Done already, in fact. Quick responses from Zobel... :-) Yep. Stats are now back on the D-I builds overview page. Thanks. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004231648.56678.elen...@planet.nl
Re: No daily image builds since March 22nd
On Monday 19 April 2010, Steve McIntyre wrote: BTW, we also need a new location for the log files. The old location [1] no longer works. [1] http://farbror.acc.umu.se/cdimage-log/ Of course, yes. I'll get that sorted too. Any progress? I notice that cdbuilder.d.o does have a webserver running, so I suspect this should be trivial. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004230158.46405.elen...@planet.nl
Re: No daily image builds since March 22nd
On Saturday 17 April 2010, Jurij Smakov wrote: It looks like the daily image builds stopped on March 22nd due problems with ftpmaster machine, but were not resumed after they were fixed, see, for example http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/sparc/iso-cd/ Are there any plans to start building the daily images again, or am I simply looking in the wrong place? It may also have to do with the new CD buildd. Steve? -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004171942.56400.elen...@planet.nl
Re: No daily image builds since March 22nd
On Saturday 17 April 2010, Frans Pop wrote: On Saturday 17 April 2010, Jurij Smakov wrote: It looks like the daily image builds stopped on March 22nd due problems with ftpmaster machine, but were not resumed after they were fixed, see, for example http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/sparc/ iso-cd/ Are there any plans to start building the daily images again, or am I simply looking in the wrong place? It may also have to do with the new CD buildd. Steve? BTW, we also need a new location for the log files. The old location [1] no longer works. [1] http://farbror.acc.umu.se/cdimage-log/ -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004171956.32699.elen...@planet.nl
Re: Unable to access downloads
On Friday 16 April 2010, Diana Allen wrote: SOLUTION: I need a site address where I can download the non-free packages for transfer to CD. I can't seem to find this on the Debian site. You're looking for http://packages.debian.org: http://packages.debian.org/search?keywords=sl-modem Cheers, FJP P.S. The best place to ask this question would have been the debian-user list. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004162133.50730.elen...@planet.nl
Re: Error while running CD built using Debian-CD: No kernel modules found....
On Thursday 15 April 2010, vikram wrote: When i run the CD i get the following error: No kernel modules found. This probably is due to a mismatch between the kernel used by this version of the installer and the kernel available in the archive. Please read the documentation. In this case especially the section D-I images and components in README.easy-build. The error is yours, not in the tools: *you* are creating an inconsistent image. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004151620.31708.elen...@planet.nl
Re: Error while trying to make Lenny CD iso image using debian-cd
On Thursday 15 April 2010, vikram wrote: The problem is i get the following error when i run easybuild.sh: dpkg-deb: error reading version number from file /home/user/Mirror/: Is a directory make: *** [/home/user/Mirrir/tmp/lenny/debootstrap] Error 2 No idea. But the cause of the problem is that either your mirror or your setup is incorrect. The tools work. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004151622.27423.elen...@planet.nl
Re: New cdbuilder server improves Debian infrastructure
On Thursday 01 April 2010, Raphael Hertzog wrote: On Thu, 01 Apr 2010, Frans Pop wrote: [1] I saw your request to add me to a group, but that's all I know. I tried 'ssh cdimage.debian.org', but that does not work. Try ssh cdbuilder.debian.org, I can log there. Thanks Rafael. That worked. I've moved my personal stuff over. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004010848.30684.elen...@planet.nl
Re: New cdbuilder server improves Debian infrastructure
On Tuesday 16 March 2010, Alexander Reichle-Schmehl wrote: Today, the Debian project administrators are activating a new cdbuilder server. Steve, Could you provide some practical info about this for the rest of the team? I still have access to farbror, but I assume that is is not going to last forever and there are some things on that I'd like to move over. What is the name of the new server? How do I log in [1]? Are there any changes in how builds are done? TIA, FJP [1] I saw your request to add me to a group, but that's all I know. I tried 'ssh cdimage.debian.org', but that does not work. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004010539.04278.elen...@planet.nl
Re: Bug#572605: still present -- installation-reports: Sid d-i on PowerPC can not find driver for network interface
On Wednesday 24 March 2010, Rick Thomas wrote: So how do we get this fixed? If it really is a problem on the buildd, who *can* fix it? Is there a list somewhere of who is responsible for which buildd? I've already provided that info a few times. For the centralized D-I buildds (which includes powerpc) Luk Claes and Otavio Salvador are the persons who set up the buildds and who are AFAIK the only people who currently have the access required to maintain the buildds. I have seen no mails from them on the d-boot list requesting help with that, so I can only assume they're still willing to maintain them (although the evidence seems to indicate otherwise). If it doesn't get fixed, there's not much point in claiming that Debian supports PowerPC architecture... Bullshit. I agree that it's a huge nuisance for testing and that the daily builds really should be available, but the alpha1 release works just fine (except for the known issues) and a next release will also not have this issue. For testing the current development status of the installer you could always build your own images. It's not that hard. Your point about not supporting powerpc is a gross exaggeration and to be honest I'm getting pretty tired of your repeating that any time *volunteers* don't jump quickly enough to your liking. So far I've also not seen that much actual help with arch-specific D-I development from the Debian powerpc community, despite repeated calls for help from our side. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003242125.01048.elen...@planet.nl
Re: where is now reiserfs in Debian-testing netinstall?
(Setting Reply-to to the debian-boot list which is more appropriate.) On Tuesday 23 March 2010, dimas wrote: earlier i've installed Debian testing several times from bussinesscard images (28M) and all was fine. but now i was really surprised when i tried to do this and haven't found Reiserfs in installer's partitioning menu. Because reiserfs is no longer actively maintained upstream and because there are now good alternatives, we have made support for reiserfs optional instead of standard. To use reiserfs with daily images you need to either: - boot in expert mode and select 'partman-reiserfs' as optional component - boot the installer with the option 'modules?=partman-reiserfs' I will send a general announcement of this change soon. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003231802.26077.elen...@planet.nl
Re: Getting d-i to find firmware on the CD generated by debian-cd
On Tuesday 16 March 2010, Holger Levsen wrote: On Dienstag, 16. März 2010, Frans Pop wrote: An additional issue with non-free firmware is that including it in the way you propose would (I think) mean it will get loaded without any prompting of the user, which may in some cases violate licence terms. i thought the same at first, but actually that's not the case. The user is still asked (by the package) if she wants to accept the licence. (As no preseeding takes place.) But that's only at the point where the package gets installed in the target system. And at that point the firmware is already in use. IMO a proper solution would ensure the licence dialog gets displayed before the firmware first gets loaded by the installer. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003161350.45073.elen...@planet.nl
Re: Getting d-i to find firmware on the CD generated by debian-cd
On Tuesday 16 March 2010, Petter Reinholdtsen wrote: Actually, something causes main-menu to crash if I adjust mountmedia to return CD devices too, so I suspect it is better to adjust check-missing-firmware to also look in /cdrom/firmware/ for debs. Probably because the CD is already mounted and in use and mountmedia messes that up? -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003161352.30877.elen...@planet.nl
Bug#573791: Installer fails due to invalid signatures
reassign 573791 installation-reports tag 573791 unreproducible needinfo thanks On Tuesday 16 March 2010, steve clark wrote: I sent a report to the debian bug reporting system (bug number 573791) but it seems to not have been taken serious, being shuffled between responsible owners. I see it differently: you have an installation problem that nobody else is having and have not quite found the correct way to report it. The reason your bug report was reassigned is that the original report had an incorrect syntax. So it is *not* being shuffled around; someone was merely trying to correct your incorrect initial reporting. And please understand that reporting an issue incorrectly drastically increases the chance that it will be missed! Happens with other lives debian based systems (e.g. ubuntu 9.10 server) too. Please report issues with Ubuntu installs to Ubuntu. I'm a novice Debian user (4 months), but have over 25 years across multiple systems and am a professional developer, so think I can recognise a must look at problem when I see one :) In that case I would also expect you to recognize when a problem is so completely unlikely to escape the attention of the project publishing the software that it may well by an issue that's solely due to the inexperience of the user? I can assure you that, if Lenny really was not installable, we would be flooded with reports. Fortunately that has not happened. The fact that you consistently see the issue could also be explained by the fact that you're doing something consistently wrong maybe. !! I have just tried an install using the 5.04 netinst and using the !! ftp.uk.debian.org mirror without any problems. There may have been a temporary problem with that particular mirror. If there was it appears to be solved now. Did you try different mirrors? I would further suggest that as it prevents any new installations of Debian since at least 11th March 2010, its serverity is a little higher than normal. *If* the issue is confirmed to be a real issue *and* really affects all installations and not simply one isolated mirror, then yes. Until then a much more appropriate categorization is unreproducible, needs additional info. Now, to try to solve your problem, assuming that you can still reproduce it, we will need additional information. Please send us the syslog of a failed installation. You should be able to save it using the Save debug logs option in the main menu of the installer. Please gzip the syslog before sending it and send your reply _only_ to 573...@bugs.debian.org. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003161438.13783.elen...@planet.nl
Re: Getting d-i to find firmware on the CD generated by debian-cd
On Monday 15 March 2010, Petter Reinholdtsen wrote: That source package does not contain all available firmware, FWIW. You're missing at least zd1211-firmware and atmel-firmware. debian-cd has a list in tasks/firmware. Btw, tasks/firmware refer to the non-existing package firmware-ipw3945. Did it change name, go away or is it planned introduced in the future? The answer to that question is simple enough to find with either a quick look at packages.d.o, or simply: $ rmadison firmware-ipw3945 firmware-ipw3945 |0.4 | etch-m68k/non-free | all firmware-ipw3945 | 0.4+etchnhalf.1 | oldstable/non-free | all The firmware task should probably be made release-specific... -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003150834.41461.elen...@planet.nl
Re: testing firmware image out of date
On Tuesday 09 March 2010, Joey Hess wrote: The firmware bundle at http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/testing/c urrent/ contains firmware files from lenny. I'm fairly sure that testing did not have such old versions of when the file was built in February, so is it building against stable? No, the build is correct. Just the symlink for testing needed updating from lenny to squeeze. Done. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003092201.45797.elen...@planet.nl
Re: Bug#572382: cdimage.debian.org: 5.0.4 CD/DVD missing for arch not amd64/i386
On Wednesday 03 March 2010, Simon Paillard wrote: On Tue, Mar 02, 2010 at 11:03:26AM +0700, Chatchai Jantaraprim wrote: Does the contents there up-to-date? For example http://cdimage.debian.org/debian-cd/5.0.4/i386/iso-bd/ All the missing images are not included *as ISOs* on purpose. Simply because they are very seldomly used and together would take up huge amounts of space on the mirrors. For all missing images jigdo files are provided instead. Using the jigdo files is not a workaround, it is the only supported method for downloading these images. If you don't want to download them using jigdo, you can check if a CD vendor sells them. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003032235.11868.elen...@planet.nl
Re: mirror-sync and build_all.sh (debian-cd)
On Monday 22 February 2010, mancyb...@gmail.com wrote: ./easy-build.sh NETINST cp: cannot stat `/media/mike2/srv/mirror/debian/dists/lenny/main/installer-i386/current/images/cdrom/initrd.gz': No such file or directory FAILED: error 1 Failed to start disc 1, error 256 You don't have the Debian Installer images included on your mirror. You can either add them (you'll need debmirror from testing for that), or you can configure easy-build.sh to load the D-I images from an external mirror. For the last, see the comments in the easy-build.sh script. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100131.35006.elen...@planet.nl
Re: mirror-sync and build_all.sh (debian-cd)
On Monday 22 February 2010, mancyb...@gmail.com wrote: note the '--section=main,main/debian-installer' That includes the *udebs* for the installer, but not the *images*. Just look at the file name from the error message and check your mirror; you'll see that it's imply not there. To also mirror the images, you need the --di-dist and/or --di-arch options. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100229.20839.elen...@planet.nl
Re: mirror-sync and build_all.sh (debian-cd)
On Monday 22 February 2010, Frans Pop wrote: On Monday 22 February 2010, mancyb...@gmail.com wrote: note the '--section=main,main/debian-installer' That includes the *udebs* for the installer, but not the *images*. Just look at the file name from the error message and check your mirror; you'll see that it's imply not there. ^--- simply To also mirror the images, you need the --di-dist and/or --di-arch options. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100257.37558.elen...@planet.nl
Bug#570770: Debian Edu squeeze images
On Sunday 21 February 2010, Holger Levsen wrote: What VCS are you using, are you using one? ;) Isn't that hard to find: http://packages.qa.debian.org/d/debian-cd.html -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201002211329.52172.elen...@planet.nl
Re: [ANNOUNCE] Alpha1 images, last tests and announce on friday
On Thursday 18 February 2010, Otavio Salvador wrote: We can't use the daily images for testing in many arches (mips, mipsel, powerpc, ...). Nonsense. You're failing to distinguish between daily *D-I* builds and daily *CD* builds. Sure, the daily *D-I* builds for mips are failing, but that has nothing at all to do with the squeeze_d-i daily CD builds. The squeeze_d-i daily CD builds are based on the version of D-I you uploaded, not on the failing daily D-I builds! The daily D-I builds only affect the sid_d-i daily CD builds. Steve, can you do that for us? No, there is no need. The squeeze_d-i CD builds should be fine for *all* arches! Cheers, FJP P.S. I hope the weekly builds have now been switched back to using the D-I version from testing rather than daily D-I builds? -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201002181545.28724.elen...@planet.nl
Re: [ANNOUNCE] Alpha1 images, last tests and announce on friday
On Wednesday 17 February 2010, Otavio Salvador wrote: I've contacted Debian CD Team to look at it. What exactly do you think is wrong here Otavio? * netinst and businesscard images are built daily as squeeze_d-i [1] * the mini.iso images are part of the D-I builds, not debian-cd builds [2] * so it's completely correct that the above link only lists full CDs and DVDs So the only problem here is that your mail asking people to test is incomplete as it points to only one class of images instead of telling people where to find all the different relevant images. Once upon a time we would even ask Steve to (temporarily!) change the daily symlink from sid_d-i to squeeze_d-i to facilitate pre-release testing... For powerpc: [1]http://cdimage.debian.org/cdimage/daily-builds/squeeze_d-i/current/powerpc/ [2]http://ftp.nl.debian.org/debian/dists/squeeze/main/installer-powerpc/current/images/ -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201002172242.35546.elen...@planet.nl
Re: [ANNOUNCE] Alpha1 images, last tests and announce on friday
On Wednesday 17 February 2010, Frans Pop wrote: On Wednesday 17 February 2010, Otavio Salvador wrote: I've contacted Debian CD Team to look at it. What exactly do you think is wrong here Otavio? * netinst and businesscard images are built daily as squeeze_d-i * so it's completely correct that the above link only lists full CDs and DVDs And of course these two (small and full CD images) have always been combined into a single directory only after the final CD build for for a release, i.e. after the OK for release from the D-I release manager. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201002172314.23362.elen...@planet.nl
Bug#569719: cdrom: sparc testing 20100208 will not boot after CD install, stuck at openboot.
reassign 569719 linux-kernel-di-sparc-2.6 1.49 severity 569719 important thanks On Saturday 13 February 2010, James Boughton wrote: Installation from the three CD's for the Feb 8, 2010 build of sparc testing seems to go without a hitch. The problem is that the system will not then boot from the hard disk (IDE). This is a known issue caused by a bug in the 2.6.30 kernel the installer is currently using. It will be fixed once we switch to the 2.6.32 kernel for the installer. Please see http://bugs.debian.org/565639 for details. It also mentions a way to fix the issue manually. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201002141854.20376.elen...@planet.nl
Re: Where can download debian 4.0?
On Wednesday 20 January 2010, Zou,Jichao wrote: I'm an employee of iSoftStone Information Technology ( Group ) Co., Ltd. Where can I download debian 4.0? Debain 4.0 ISO wasn't in http://cdimage.debian.org/debian-cd/project/build/4.0_r4a/i386; Could you give a valid suit to me? http://cdimage.debian.org/cdimage/archive/4.0_r8/ -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
About ignoring problems instead of fixing them
From farbror (CD build server): --- tools/boot/squeeze/boot-x86 (revision 1964) +++ tools/boot/squeeze/boot-x86 (working copy) @@ -230,7 +230,8 @@ boot$N/isolinux/win32-loader.ini boot$N/ fi - if [ -e boot$N/isolinux/f3.txt.withgtk ]; then + + if [ 0 = 1 ] -e boot$N/isolinux/f3.txt.withgtk ]; then extra_image gtk/initrd.gz mv boot$N/isolinux/f3.txt.withgtk boot$N/isolinux/f3.txt mv boot$N/isolinux/f4.txt.withgtk boot$N/isolinux/f4.txt Wow, so now the build does not fail. Is it really better to ignore errors and create broken images [1] than to actually solve the error? That really sucks. It would have been so much nicer if, when you don't know the cause of a problem or how to solve it, to write a mail and discuss it on the relevant lists so that others could have been given an opportunity to help or comment. I've already committed a proper fix in D-I for this a bit earlier [2] and therefore reverted this nonsense. After testing if my fix is correct I'll also upload D-I again as otherwise 'alpha1' images would also be broken. In despair at how problems appear to be solved nowadays, FJP [1] Apparently nobody has even bothered to test a daily built image recently because if they had it would have been obvious that it includes syslinux options for the graphical installer that don't work. And I've even *said* that this should be tested when we discussed disabling the graphical installer on d-boot. [2] And then did a local test build which failed and then wondered why daily builds were not failing. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About ignoring problems instead of fixing them
On Thursday 24 December 2009, you wrote: I saw that the graphical images weren't available any more so I disabled them. Problem is that you did not disable them. You only silently ignored a failure, with the result that you were creating broken images. If I had not accidentally caught that now, we would have had a release with broken images. I would not have minded if you'd ignored the failure and at the same time informed people of the problem so that it could be looked into and solved properly. From the last discussion I saw fly past, it looks like the lack of graphical images is a known feature. Yes. They have been disabled on purpose. But the system is supposed to be flexible enough to *see* whether or not D-I is building graphical images [1] and then excluding those options from the isolinux menu. But because we've never had that situation before, this was not actually implemented 100% on the D-I side. debian-cd uses the file f3.txt.withgtk to test do we have graphical or not, so D-I should not be including that file if graphical is disabled. I'm getting dozens of complaints every time the weekly builds fail these days, so with no further information to go on and no warning from the d-i folks I took this choice. There was no warning because it was supposed to work. That means that we need a main or bug report to inform us of breakage. Without that there's no trigger to fix the problem. So now we need an extra upload of D-I to fix the problem instead of having had the problem fixed shortly after Otavio committed the change to disable the graphical images. It's getting painful using the daily-built d-i images for the weekly testing CDs, as the number of broken builds is very high. True. Weekly builds are supposed to be built from released D-I images instead of daily images. Unfortunately the D-I release manager has been unable to get a release out so far. I would really *really* like to see d-i properly integrated into the archive and uploaded periodically so it can migrate to testing, as we've discussed in the past many times. The current situation is a train wreck. This broken record argument from you will not help *at all* (as I've tried to explain several times in the past). Do you really think that when people are unable to get a release going in almost a year that periodic uploads magically are going to be correct? If daily builds fail then builds integrated in the archive will fail just as hard. One solution could be to change the upload script for D-I daily images to not upload anything except the log files if a daily build fails. The real problem is that nobody is monitoring builds, doing any testing or fixing any issues on any frequent basis. Not like Joey and I used to do in the past. I currently do not consider myself as the person who monitors things, so I only react to concrete reported problems. Even so if I do still seem to end up catching and fixing most issues. BTW, I thought that d-cd simply kept the old images if a build failed for an arch, or is that only implemented for daily builds? Cheers, FJP [1] There is a difference between a graphical images failing and being disabled. The case of graphical images failing while normal images do build is not handled, but that is fairly exceptional. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About ignoring problems instead of fixing them
On Thursday 24 December 2009, Frans Pop wrote: I would really *really* like to see d-i properly integrated into the archive and uploaded periodically so it can migrate to testing, as we've discussed in the past many times. The current situation is a train wreck. And you simply cannot use periodic uploads for daily CD images. Why? Because the udebs used in D-I images must match the udebs loaded from CD later in the installation. If you'd use periodic D-I uploads as a basis for daily CD builds (or network based installs), you will still end up with images that don't work because the two will slowly diverge due to uploads to sid. So: daily CD builds *must* use daily built D-I images. Some occasional and mostly temporary breakage is unavoidable. In a lot of cases (sid just being sid) a problem will resolve itself within a day or two. If a problem persists it simply needs to be traced and solved. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About ignoring problems instead of fixing them
On Thursday 24 December 2009, Frans Pop wrote: I've already committed a proper fix in D-I for this a bit earlier [2] and therefore reverted this nonsense. After testing if my fix is correct I'll also upload D-I again as otherwise 'alpha1' images would also be broken. The last CD build failed because it was still using old D-I images, but I've just done a local CD build using Joey's current images and that looks perfect: no build errors and a correct syslinux menu without graphical installer options. So the next daily CD builds should also be OK again. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Suggestion: Change the link names on http://www.debian.org/releases/stable/debian-installer/
On Thursday 26 November 2009, Matthew Wilcox wrote: On Thu, Nov 26, 2009 at 11:17:07PM +0100, Frans Pop wrote: Do you really think that having AMD64, Intel x86 and Intel IA-64 instead of amd64, i386, ia64 will make people magically choose AMD64 if they're looking for 64-bit Intel support? I hadn't realised that Simon had made this change. That was the whole _point_. Put the popular architectures first, and call them something meaningful, ie: [x86 32-bit] [x86 64-bit] [PowerPC] Changing things this way still does not make it fit in the current layout of the page and will still reduce readability (IMO). Also, making this change *only* for the image links is IMO not a good idea because it just introduces yet another identification for architectures. We already use too many different names and descriptions in different places. Why should users have to learn what Debian's internal name for their architecture is? Because that is what they see/need when they look at the sources.list or package names? I have no objection to changing the layout. I would prefer a full redesign over just changing the layout. The current pages are problematic exactly because they try to fit everything on a single page and thus allow little room for explanation. But OTOH that's also their great strength for users who *do* know what they want, so solving the issue by linking to separate page(s) that add a good explanation of what's what is still an option too. An alternative could be to have a single page per release per architecture. Such pages would allow for much more information about the architecture (including links to related architectures) and more information about the different images. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Ridiculously large packages
On Friday 20 November 2009, Steve McIntyre wrote:
If you ever want this to be available on Debian CDs, you're going to
have to do something about the size. For now, I'm going to blacklist
this package altogether.
Even though they do technically still fit on a CD, you may want to consider
excluding the following packages as well, as including them essentially
means having roughly 4 CD images dedicated to 9 packages.
53450 vtk-doc_5.2.1-11_all.deb
395642608 root-system-doc_5.24.00-1_all.deb
357422076 sauerbraten-data_0.0.20090504-1_all.deb
306308472 openarena-data_0.8.1-2_all.deb
250166552 fgfs-base_1.9.0-1_all.deb
235440078 kwwidgets-doc_1.0.0~cvs20090825-2_all.deb
220393788 alien-arena-data_7.0-1_all.deb
211831974 fgfs-base_1.0.0-2_all.deb
206728944 ember-media_0.5.7-1_all.deb
The selection was size 2 from:
.../debian/pool$ ls -lR | grep \.deb$ | awk '{print $5 $8}' | \
sort -rn | head -n 25
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Ridiculously large packages
On Friday 20 November 2009, Steve McIntyre wrote: For now, I've added a cutoff of 300,000,000 bytes as a maximum package size for adding to CDs. That means that the following 3 packages will be dropped from the squeeze CD builds: 306308472 pool/main/o/openarena-data/openarena-data_0.8.1-2_all.deb 53450 pool/main/v/vtk/vtk-doc_5.2.1-11_all.deb 793400238 pool/main/n/nexuiz-data/nexuiz-data_2.5.2-1_all.deb The debian-cd code will automatically pick up on dependencies too, so any packages that *depend* on these will also be dropped. Would it be possible to generate a list of excluded packages and add that as a README on CD1? -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: build a CD from varous repositories
On Saturday 07 November 2009, Geronimo Ma. Hernandez wrote: Is there a (documented?) way to create partial mirrors from various repositories, so the building of the CD can succeed? Try 'debmirror' (or one of the similar packages). See also: http://alioth.debian.org/~fjp/log/tags/debmirror.html Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: build a CD from varous repositories
On Saturday 07 November 2009, Geronimo Ma. Hernandez wrote: Hello and thank you for your support. Try 'debmirror' (or one of the similar packages). I already used your script (mirror-sync) which wrappes debmirror. The point is, that (from my understanding) debmirror only works with blacklists (--exclude). ... and so far, I don't know, what I should exclude. That's why I added the second link. See my last post there. It has some examples of what could be excluded. I would like to use that file to create my local partial mirror - cause I'm only interested in that packages plus their dependencies - no matter how many CD-images I'll have to create. That's very extreme... I don't think you could still call that a useful mirror. Debmirror is not the tool for that. Don't know of any alternatives. Can the apt-get environment be used to create a local mirror that is usable to build a CD(-set)? Or can I combine various tools to solve that? I don't fear about writing scripts - the point is, I don't know, how I could solve the problem. Can't help you there. Sorry. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#551959: netboot: fails to set user and passwords on installation
On Saturday 24 October 2009, Christian Perrier wrote: CD team, this bug apparently confirms that weekly builds of Debian testing images are broken (maybe some of them only, I'm not sure). You guys probably know more than me about this, but isn't there something we could do to redirect our users to the D-I home page if they want to install testing? This was about a *netboot* image, which has *NOTHING* at all to do with CD images. It has been known for ages that the D-I testing images are broken. They got broken by all the ABI changes after the Lenny release that were (rightly) allowed to migrate to testing. They get more and more broken with every udeb migration to testing. The only way to fix them is by doing timely releases. And then ensuring that they stay working by tightly regulating what udebs migrate to testing. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Netinst for testing?
On Saturday 24 October 2009, Dennis Wicks wrote: I thought that I had previously gotten net install CD iso for what was then the testing release of Debian. Links to current images are available from: http://www.debian.org/devel/debian-installer/ Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: PowerPC daily install CDs? [Was: Re: Netinst for testing?]
On Sunday 25 October 2009, Rick Thomas wrote: On Oct 24, 2009, at 10:03 PM, Frans Pop wrote: Links to current images are available from: http://www.debian.org/devel/debian-installer/ Cheers, FJP Hmmm... If I follow that link, then click on • netinst ... and businesscard ... CD images ... [powerpc] I get taken to a directory that claims This build finished at Thu Oct 1 23:28:01 UTC 2009. Is it possible that PowerPC CD builds have been down for over three weeks and nobody noticed? That's very likely the case. Looks to me that the general state of builds is rather pathetic ATM: http://people.debian.org/~joeyh/d-i/build-logs.html Hard to see how people expect to be able to do a D-I release (as mentioned in the logs from the last team meeting) given that fact (amongst others). -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: PowerPC daily install CDs? [Was: Re: Netinst for testing?]
Looks to me that the general state of builds is rather pathetic ATM: Sorry. I should have just written Looks like there are quite a few problems with builds ATM. Does not change the facts or the likelyhood of a successful upload/release any time soon though. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian 4.x for sun sparcstation 20 ?
On Tuesday 06 October 2009, Thorsten Moeller wrote: i have a old sun sparcstation 20 without a OS.. and i want to install debian.. debian 5 works only on sparc64.. where i can download via http, ftp oder torrent the CD-version of debian 4 ?? Etch (Debian 4.0) was the last release to support sparc32. The archive of the last Etch CD images can be found here: http://cdimage.debian.org/cdimage/archive/4.0_r8/sparc/ There still seem to be ISO images, but if that does not work, you'll have to use jidgo. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian cd image download website
On Wednesday 16 September 2009, Maximilian Haeussler wrote: Please read the installation guide before you are doing installation. [1] http://www.debian.org/releases/stable/installmanual No. It is the other way round: One has to SELECT your architecture to read an installation guide. Users who do not know their architecture do not know which installation guide they should read. They will definitely look into AMD if they bought Intel. This architecture problem is bugging me since the introduction of IA64. The installation guide _does_ mention this though. It can be seen both in the architecture table http://www.debian.org/releases/stable/i386/ch02s01.html.en#id2756248 and in the section on CPU support just below that: http://www.debian.org/releases/stable/i386/ch02s01.html.en#id2756691 I've just added an explicit caution in the version for IA64. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#542241: simple-cdd: Deal better with non-official codenames
On Monday 14 September 2009, Raphael Hertzog wrote: Well, as a debian-cd co-maintainer, I thought about this too, but I didn't like the idea very much. It would mean 2 supplementary variables that should be used instead of $CODENAME or $DI_CODENAME in various places and that should default to $CODENAME $DI_CODENAME. Ccing debian-cd@lists.debian.org to get the input of Steve (and maybe Frans) but for now I think that simple-cdd is a good place to implement this. I consider the fact that we can put supplementary directories in those places as a relatively official interface of debian-cd. It seems a bit strange to me to have a derived distribution as CD release that's not backed up by it's own archive, and thus mirrors. I'd say that if you want to use different codenames, you should start by creating an archive that has those codenames. If you do not have a separate archive, I fail to see the rationale for changing the Debian codename. Are users not allowed to install additional packages or get (security) updates from the Debian repositories for some reason? If you have such an archive, it also seems trivial to me to create the needed configuration files (if you like as symlinks to files/dirs for Debian codenames) needed for Debian CD. (I'd recommend using git-svn and creating a branch for the derived distribution.) So, IMO debian-cd already has all the functionality needed to support derived distributions using different codenames. Or am I missing something? Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#542241: simple-cdd: Deal better with non-official codenames
On Wednesday 16 September 2009, Raphael Hertzog wrote: Now, the alternative is to not create the symlinks and have a way to tell debian-cd “well CODENAME is foo, but for boot-enabling scripts, please use those of lenny”. I agree that as simple-cdd is the wrapper here that has the goal of making things easier for the user it should take care of such things itself. Especially as I can well imagine taking this one logical step further: use these files by default, but drop in that custom file. That would have to be managed by simple-cdd. I see no need to complicate d-cd for this. Just my private opinion. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
***UNCHECKED*** Your signed PGP key 0x7C3B797088C7C1F7
signedkey.msg Description: application/pgp-encrypted msg.asc Description: Binary data
Bug#544400: s390 Debian Installer panic bug # 536354
reassign 544400 debian-installer forcemerge 536375 544400 thanks This is my first install of debian on s390. I downloaded your images, booted and got a kernel panic. This looks like problem # 536354. Correct. The kernel is now fixed, but the installer still needs to be updated, which will happen with the next stable point release (which should happen fairly soon now). In the mean time the only other option is to install Etch and upgrade to Lenny later. Please see the following mail (bottom part) for details: http://lists.debian.org/debian-s390/2009/07/msg3.html Cheers, FJP P.S. The CD images for s/390 are only of limited value. You can just as well use the generic images available under other images from: http://www.debian.org/releases/lenny/debian-installer/ or for etch from: http://www.debian.org/releases/etch/debian-installer/ -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#543256: tasksel maintainer's perspective
On Thursday 27 August 2009, Joey Hess wrote: So, that change was made in tasksel three months ago, near to the start what was, AFAIK at the time, a 1.5 year release cycle. This was done in full knowledge that enabling recommends would take some time to sort So why did you not inform the d-cd team of that change then? And you also know that historically such issues have in general not been sorted out by d-cd maintainers proper, but more by people like you and me who's primary concern was D-I. out, including getting debian-cd to disable NORECOMMENDS and maybe handle recommends more intelligently; dealing with demotion of unnecessary recommends; and dealing with any size increase issues. If the current release timeframe[1] is not long enough to sort these issues out, perhaps the release team should be told about that. Or perhaps someone will want to revert this -- but you get to own all the issues of the installer not installing recommends while maintainers assume it will. Right, so basically you're saying that you no longer want to explicitly list desired Recommends in tasksel and have decided to do that by simply dumping the problem on another team, while actively working to increase the problem. IMO tasksel is a much more logical place for it. Oddly it didn't seem to be treated as a big deal by a lot of people when it happened to stable CD1. :-/ Agreed. I've been very disappointed with the very long time it took to fix that simple issue. You'll have noticed that I jumped in straight away to help resolve the issue after you filed the BR as I do feel CD1 is important. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#543256: tasksel maintainer's perspective
On Wednesday 26 August 2009, Frans Pop wrote: I also worry what the change will mean for the total size of the various desktop installs. Is the 3GB check still enough? Somehow I doubt it. Installing GNOME desktop currently requires 3.2GB. That's including the package cache. After 'aptitude clean, 2.4GB remains used. For comparison, the same numbers for Lenny are 2.5GB and 1.8GB. I had recommends disabled, and at first I thought maybe tasksel was overriding that option. But I checked and that 's not the case. So I really shudder to think what the installed size would have been if I'd not disabled Recommends (with packages like gnome-office still missing). /me is not at all amused -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ups english ... Netinstall ia64
On Tuesday 25 August 2009, Tobias Schön wrote: it's an INTEL Atom 330 with iA64 could it be the BlueRay Drive via USB2.0 ? Are you 100% sure that Intel Atom is an *Itanium* processor? As far as I know it is a normal 64-bits Intel processor that requires an x86_64 Linux kernel (and thus the Debian amd64 architecture) and *not* an ia64 kernel (which is the Debian ia64 architecture). They really are very different animals! Don't let the name amd64 confuse you. Did you actually read the link I provided? If you are correct and it is an IA64 system, then I'm afraid I have no idea. And that would increase the chance that the problem is with the image itself as I have no idea how widely tested booting from CD is for IA64. You may have more luck getting help diagnose the issue on the debian-ia64 list as there should be more people familiar with the architecture there. I doubt there are (m)any reading this list. But please check that you really do have the correct image first! If you do find a problem then please let us know on this list as we do of course want to provide working images. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ups english ... Netinstall ia64
On Monday 24 August 2009, Tobias Schön wrote: could it be, that the Netinstall 502a-ia64 ist not bootable Unlikely. More likely you have the wrong image for your system. Try the amd64 images instead. http://www.debian.org/CD/faq/#which-cd Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Build error in current svn
On Sunday 23 August 2009, Ian Campbell wrote: I'm seeing with current svn trunk cc1: warning: command line option -nostdinc++ is valid for C++/ObjC++ but not for C stdin:25:3: error: invalid preprocessing directive #Used stdin:31:3: error: invalid preprocessing directive #Used cc1: warning: command line option -nostdinc++ is valid for C++/ObjC++ but not for C make: *** [/storage/mirror/tmp/squeeze/rawlist] Error 1 Looks like the cause is r1947. Although this is a shell script the here end up in the output which gets fed to cpp and are not valid comments as far as cpp is concerned. Use C style comments instead. Sorry about those. The commit was done somewhat in anger as apparently nobody else is still taking care of such issues and are even unwilling to do the most basic analysis of where problems that users report originate. Unfortunately that increases the risk of sloppiness. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Install from ISO for Xen guest
On Friday 07 August 2009, Ian Campbell wrote: On Fri, 2009-08-07 at 07:39 +0100, Ian Campbell wrote: I will follow up shortly with[...]a patch to the nightly cron jobs which enables this variant for the i386+amd64+powerpc multiarch netinst image. Here it is. Committed. Is this sufficient to ensure this variant is enabled in the actual official images come release time? Or should I be patching somewhere else as well? AFAIK this should be sufficient. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Install from ISO for Xen guest
On Friday 07 August 2009, Ian Campbell wrote: diff --git a/installer/build/boot/x86/xen/xm-debian.cfg b/installer/build/boot/x86/xen/xm-debian.cfg index d1d78e7..7c3ff51 100644 --- a/installer/build/boot/x86/xen/xm-debian.cfg +++ b/installer/build/boot/x86/xen/xm-debian.cfg The patch for this file introduces trailing whitespace in several places. diff --git a/installer/build/config/amd64/cdrom-xen.cfg b/installer/build/config/amd64/cdrom-xen.cfg new file mode 100644 index 000..3f03e74 --- /dev/null +++ b/installer/build/config/amd64/cdrom-xen.cfg @@ -0,0 +1,13 @@ +TYPE=cdrom/gtk + +EXTRANAME=cdrom/xen/ + +MANIFEST-KERNEL = kernel image for installing under Xen +MANIFEST-INITRD = initrd for installing under Xen +MANIFEST-XENCFG = example Xen configuration + +TARGET = $(KERNEL) $(INITRD) xen_config +SYMLINK_KERNEL = ../vmlinuz +SYMLINK_INITRD = ../gtk/initrd.gz + +EXTRATARGETS = build_cdrom-gtk This should be 'EXTRATARGETS = build_cdrom_gtk' (underscore, not hyphen). I've been wondering if the cdrom-xen target should be built automatically with the cdrom_isolinux target, but I guess that has both advantages and disadvantages. In the end I'm OK with having it as a separate top-level variant. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Install from ISO for Xen guest
On Friday 07 August 2009, Ian Campbell wrote: I will follow up shortly with a short series of patches which introduces image variants to debian-cd and adds the Xen variant as an option for i386 and amd64 and a patch to the nightly cron jobs which enables this variant for the i386+amd64+powerpc multiarch netinst image. I've committed the debian-cd changes with a few very minor (style) corrections. The implementation is IMO quite nice and clean. The size increase from enabling the Xen variant for the m-a netinst is 55MB (main changes are ~20MB from the extra bigmem kernel image and ~30MB from added D-I kernels and initrds). This is a fairly big increase, but the multi-arch netinst can handle it. Ian: feel free to commit the changes for D-I (after the corrections) and when that's done I'll enable the Xen variant for the CD builds. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Fix error message from tools/sort_deps
On Friday 07 August 2009, Ian Campbell wrote: It seems that apt-cache depends recently (as of 0.7.22) started including Enhances lines in its output. Leading to: Generating dependency tree with apt-cache depends... UNEXPECTED: Line ` Enhances: kvm ' while parsing end of deptree from 'kvm-source' [etc] Ignore these lines. Committed. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Install from ISO for Xen guest
On Friday 07 August 2009, Ian Campbell wrote: Below is a patch for debian-installer to build cdrom-xen variants for i386 and amd64. If nobody objects I would like to commit this to the d-i repository. I'd like to test it first. The fan of my notebook needs replacing, so that may take a few days. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: boot powerpc and x86 fixes
On Friday 07 August 2009, Ian Campbell wrote: First the powerpc prep variant seems to have been disabled in d-i for ages (since r50159 in Nov 2007) and isn't part of http://d-i.debian.org/daily-images/powerpc/daily/ so don't try and fetch it. Secondly a recent change by Frans to boot-x86 left us with: if [ blah ] ; then # nothing but # comments fi which caused a syntax error. I usually just drop a : in there but perhaps just removing the whole if block makes sense if we never expect either of those comment out thing to return. Both fixed. Thanks. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [PATCH 1/4] boot-x86: move creation of install.bat out of extra_image
On Friday 07 August 2009, Ian Campbell wrote:
There is currently only a single caller but soon I will be adding
another which does not want install.bat created.
---
tools/boot/squeeze/boot-x86 |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/tools/boot/squeeze/boot-x86 b/tools/boot/squeeze/boot-x86
index 29f5566..0892ed7 100644
--- a/tools/boot/squeeze/boot-x86
+++ b/tools/boot/squeeze/boot-x86
@@ -145,9 +145,6 @@ extra_image () {
else
wget $DI_WWW_HOME/cdrom/$image -O
$CDDIR/$INSTALLDIR/$image
fi
- kernel_param=
- [ $dir = gtk ] kernel_param=video=vesa:ywrap,mtrr vga=788
- echo \\tools\\loadlin.exe \\$INSTALLDIR\\vmlinuz
initrd=initrd.gz
$kernel_param | todos $CDDIR/$INSTALLDIR/$dir/install.bat fi
}
@@ -236,6 +233,8 @@ if [ $THISTYPE = isolinux ]; then
if [ -e boot$N/isolinux/isolinux.cfg.withgtk ]; then
mv boot$N/isolinux/isolinux.cfg.withgtk
boot$N/isolinux/isolinux.cfg fi
+ echo \\tools\\loadlin.exe \\$INSTALLDIR\\vmlinuz
initrd=initrd.gz
video=vesa:ywrap,mtrr vga=788 | todos
$CDDIR/$INSTALLDIR/gtk/install.bat +
fi
rm -f boot$N/isolinux/isolinux.cfg.with*
Why was $kernel_param (which was conditional on regular versus gtk)
replaced with a hardcoded video=vesa:ywrap,mtrr vga=788?
--
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [PATCH 2/4] easy-build.sh: use getopts instead of rolling our own option parsing.
On Friday 07 August 2009, Ian Campbell wrote: +while getopts d:h OPT ; do Is getopts also supported in dash? + case $OPT in + d) + case $OPTARG in + # Note: gnome is the special gnome task, not the generic task + gnome|kde|lxde|xfce|light|all) + desktop=$2 + ;; + *) + show_usage + exit 1 + ;; + esac ;; + h) show_usage; exit 1;; Please put the commands for the h option on separate lines (as is done for the others). AFAIK a plain 'show_usage', if not displayed as the result of an error, should have an 'exit 0'. The -h option should be listed in the usage output. Maybe it would be good to also support --help if -h is added.
Re: [PATCH 3/4] Add support for producing disks with (optional) extra variants.
(No need to CC me on replies.)
On Friday 07 August 2009, Ian Campbell wrote:
show_usage() {
- echo Usage: $(basename $0) [-d gnome|kde|lxde|xfce|light|all]
BC|NETINST|CD|DVD [ARCH ...]
+ echo Usage: $(basename $0) [-d gnome|kde|lxde|xfce|light|all] [-v
VARIANTS] BC|NETINST|CD|DVD [ARCH ...] }
This line is getting too long now. Suggest changing it to:
echo Usage: $(basename $0) [OPTIONS] BC|NETINST|CD|DVD [ARCH ...]
echo Options:
echo -d gnome|kde|lxde|xfce|light|all : desktop variant (task) to use
echo -v variant : ...
echo -h help
@@ -25,7 +25,8 @@ if [ $# -eq 0 ]; then
fi
desktop=
-while getopts d:h OPT ; do
+VARIANTS=
+while getopts d:hV: OPT ; do
Why capital V instead of lower case v as shown in usage?
case $OPT in
d)
case $OPTARG in
@@ -38,11 +39,13 @@ while getopts d:h OPT ; do
exit 1
;;
esac ;;
+ V) VARIANTS=$VARIANTS $OPTARG ;;
Idem.
Re: [PATCH 3/4] Add support for producing disks with (optional) extra variants.
On Friday 07 August 2009, Ian Campbell wrote: This patch just adds the generic support code: * CONF.sh: Add $(VARIANTS) configuration variable. * eash-build.sh: Add command line parameter to enable variants. * Makefile: Define VARIANT_xxx when preprocessing package list. * boot/?/common.sh: Add a function for checking if a variant is enabled. * generate_di_list: Allow variant overrides in udeb exclusion list. It would be nice to have the variants functionality documented a bit, especially as it adds syntax extentions in various existing files. Given the already fragmented state of the documentation, a separate document in the docs directory probably makes most sense. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [PATCH 3/4] Add support for producing disks with (optional) extra variants.
On Friday 07 August 2009, Ian Campbell wrote: On Fri, 2009-08-07 at 16:13 +0200, Frans Pop wrote: On Friday 07 August 2009, Ian Campbell wrote: This patch just adds the generic support code: * CONF.sh: Add $(VARIANTS) configuration variable. * eash-build.sh: Add command line parameter to enable variants. * Makefile: Define VARIANT_xxx when preprocessing package list. * boot/?/common.sh: Add a function for checking if a variant is enabled. * generate_di_list: Allow variant overrides in udeb exclusion list. It would be nice to have the variants functionality documented a bit, especially as it adds syntax extentions in various existing files. Sure. Given the already fragmented state of the documentation, a separate document in the docs directory probably makes most sense. Do I need to html it up and wire it into the existing documents? Looks like that stuff is very incomplete, a bunch of the links are dead and a variants chapter doesn't really seem to fit in anywhere in the existing narrative (such as it is), would a simple standalone text document to acceptable? Eh, that's why I wrote a separate document in the docs directory :-) I'd suggest a simple 'README.variants' text document. I'd also suggest adding a reference to that doc in the CONF.sh instead of the example, and documenting the supported variants in the README. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Fix error message from tools/sort_deps
On Friday 07 August 2009, Ian Campbell wrote: So it's not quite as simple as I thought, this patch just leads to other error messages later on. Suggest you compare commit r1911 which did the same for Breaks. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540023: cdrom: netinst installation might freeze with out-of-date keyring
severity 540023 wishlist reassign 540023 debian-installer thanks On Wednesday 05 August 2009, Patrick Vervoorn wrote: Digging deeper, finally the output shown in the output from the underlying installation scripts (Alt-F4), showed what had happened: the PGP-keyring was out of date, and the big 'apt-get install loads-of-packages' command was waiting for input from the user, to confirm to continue with an untrusted PGP key. Unfortunately it is technically rather difficult to catch this situation inside the installer. It would be wise to fix this, especially if the same can happen with the current installation (5.x/lenny). At the very least, the installing user should be made aware he/she is installing a rather out-of-date system, and whether to reconsider. It would probably also be handy if a user who knows what they're doing, could push through this install, and install anyway. That is possible by using the debian-installer/allow_unauthenticated=true boot option as documented in the Installation Guide. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Suggestions for the installer
On Friday 08 May 2009, Hans-J. Ullrich wrote: yesterday I tested the last installation-cd of Debian Lenny. I tried to take the view for an unexprienced user and tested the autoinstall routine for kde. As I own a 64-bit cpu, I chose 64-bit. There were some things, I noticed, if they were discussed before, please apologize. A better way to communicate such thoughts would be to file an installation report [1]. The debian-cd list does not really cover the installer itself. 1. As I am German, I chose German. At some points, the translation seems not always been to German. Especially at the point, were you have to decide, which partition type you want (full harddrive, .with lvm..., with enncrypted lvm, you know what I mean). Maybe you should add a suggestion for unexperienced users (I chose the first one). Translation issues are best discussed directly with the translators on the debian-l10n-german mailing list [2]. 2. As everything else was working fine, I could start at last into kde. BTW: The whole installation process lasted 30 minutes!!! Very fast!!! Amazing!!! (A Vista installation on the same system with basic + notebook-drivers lasted 3 hours.) Yes, it is fast isn't it? :-) Anyway, I remarked, that kde is still in English. It shouldn't be. The installer will load localization packages for KDE *if* they are available. Start aptitude and under tasks/localization look for the German KDE desktop task. That task should get selected and installed automatically. All at all I liked the new install process, it is really fast, easy to handle and seem to work well. Ah, and I used the multiboot-dvd, maybe this is important to know. It could explain the missing translation if you chose to use only the CD during installation and did not also select a mirror. Cheers, FJP [1] http://www.debian.org/devel/debian-installer/report-template [2] http://lists.debian.org/debian-l10n-german/ -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537841: debian-cd copies vmlinuz to /install.386 whereas isolinux is configured to fetch it in /install
On Tuesday 21 July 2009, Alexis Bezverkhyy wrote: debian-cd/tools/boot/lenny/boot-x86 states at line 59 INSTALLDIR_i386=install.386 but isolinux (dists/lenny/main/installer-i386/current/images/cdrom/debian-cd_info.ta r.gz) is set up to boot the kernel from /install, so the generated CD can't boot. Replacing install.386 by install solved this issue for me. This is wrong. The script also takes care of creating the install.386 directory _and_ to change the isolinux config appropriately [1]. If it does not in your case, then the script is failing somewhere and you should trace where and why it is failing. The script normally creates working images, so the problem is with your use of it. [1] The reason it does this is to support multi-arch images containing both i386 and amd64 which each have their own install.arch directory. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536312: task overrides for stable appear to be updated when unstable changes - no network-manager etc in default debian 5.0r2 install
Here's an (untested) patch that should avoid this issue for the future.
It determines the codename for testing from the testing symlink.
A manual cleanup for the current incorrect override files (for both lenny
and squeeze) will still be needed of course.
Cheers,
FJP
--- mk-extra-overrides.sh.orig 2009-07-10 08:34:29.0 +
+++ mk-extra-overrides.sh 2009-07-10 08:51:53.0 +
@@ -5,8 +5,23 @@
x=build-essential tag task
opath=/org/ftp.debian.org/scripts/override
+apath=/org/ftp.debian.org/ftp/dists
-for s in lenny sid; do
+if [ ! -d $apath ]; then
+ echo $0: invalid path to archive 2
+ exit 1
+elif [ ! -L $apath/testing ]; then
+ echo $0: symlink for testing suite does not exist 2
+ exit 1
+fi
+
+codename_testing=$(basename $(readlink $apath/testing))
+if [ -z $codename_testing ] || [ ! -d $apath/$codename_testing ];
then
+ echo $0: invalid codename for testing suite ('$codename_testing') 2
+ exit 1
+fi
+
+for s in $codename_testing sid; do
for c in main contrib non-free; do
echo Making $opath/override.$s.extra.$c
if [ $c = main ]; then
--
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#536312: task overrides for stable appear to be updated when unstable changes - no network-manager etc in default debian 5.0r2 install
On Friday 10 July 2009, Frans Pop wrote: Here's an (untested) patch that should avoid this issue for the future. It determines the codename for testing from the testing symlink. As the script is maybe not under version control, attached the full new version. mk-extra-overrides.sh Description: application/shellscript
Re: Bug#536312: task overrides for stable appear to be updated when unstable changes - no network-manager etc in default debian 5.0r2 install
On Thursday 09 July 2009, Joey Hess wrote: Ftpmasters: Task override updating is handled by an autobyhand script fjp wrote, /srv/ftp.debian.org/dak/scripts/debian/byhand-task. I don't have access to look at what's on ftpmaster, AFAIK everything can also be found on merkel though. but looking at the patches fjp posted about this, it seems to update /srv/ftp.debian.org/scripts/external-overrides/task with the file from tasksel, and then run mk-extra-overrides.sh in the same directory. Perhaps the issue of keeping differing overrides for stable and unstable separate was entirely overlooked? Although IIRC ftpmaster had a different set of task override files for stable. I doubt that that is the cause as I do remember considering that aspect when we made the change. For that reason my patches also still force a real by-hand for uploads of tasksel to stable. /me looks on merkel... Hmmm, mk-extra-overrides.sh has this: for s in lenny sid; do for c in main contrib non-free; do echo Making $opath/override.$s.extra.$c So it looks like the problem is that that script should have been updated to 'for s in squeeze sid; do' when lenny was released, but that this was forgotten. Perhaps the releases to act on should not be hardcoded but instead taken from some configuration file? Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Bug#532515: handling of Recommends (was: on making decisions vs letting things happen)
On Monday 06 July 2009, Colin Watson wrote: So does that mean you feel that the policy manual's description of Recommends is wrong, or that Debian installations should be unusual by default? I don't think policy for Recommends is wrong, but I do feel it results to a hell of a lot of packages getting installed that are not actually needed/wanted in practice. IMO the special handling of Recommends in D-I so far was justified, especially as we did consciously compensate for not installing Recommends by default by adding them to the task definitions in cases where they were really needed/wanted. Realistically, either (a) the Recommends were correct or (b) nobody was going to bother fixing them until they started being installed by default as policy says they should be. I feel that the change could have been discussed more before being implemented in tasksel, possibly with some coordinated effort to check the impact on _all_ tasks instead of just the Gnome desktop task and maybe filing bugs to fix the most problematic Recommends. At the very least the impact on or consequences for debian-cd should have been discussed *before* the change was made. It's one thing to say that something is premature, but the previous situation was just a deadlock. There have been improvements of the use of Recommends during Lenny. Maybe not as many as needed, but still. debootstrap is a slightly odd case (because it's also used to construct explicitly minimal systems, in which case the rules seem different) and I've long been unsure about how it should behave. Maybe it just needs an option for it. I can agree to some extend with debootstrap although you could also argue that we should be consistent, maybe with an expert option to _consistently_ ignore Recommends for those who want a bare minimal install. IMO there is no justification to treat packages installed by base-installer or other components using apt-install differently from those installed by tasksel. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#532515: on making decisions vs letting things happen
(Adding d-cd to CCs.) On Sunday 05 July 2009, Josselin Mouette wrote: Le samedi 04 juillet 2009 à 16:46 -0400, Joey Hess a écrit : * After stable was released, many more maintainers began assuming recommends would be installed by default. These recommends had to be manually noticed and tracked in tasksel. IIRC there was a case where the omission of a recommended package could have potentially left X nearly unusable. (Don't remember the details.) [...] At this point it became clear to me that it was time to make tasksel install recommends by default, since manually tracking them in tasks wasn't feasable going forward[2]. * At that point, I reviewed packages that were only in task lists due to being recommended, and removed them. This had a nice benefit in simplifying the gnome-desktop task[1]. [...] I agree that feedback from the CD team would be nice. I’ll ask them to do a simulation once the GNOME 2.26 metapackages are ready. Anyway fitting all of this on the first CD is out of question. The primary package still being gnome-desktop-environment, I guess we should focus the size efforts on this one and ensure it can still fit on one CD. The first full DVD needs to be considered too. It's supposed to support installing all four desktop environments without the use of a mirror. In general debian-cd may need to be modified as AFAIK currently it does not consider Recommends at all when deciding which packages to include on which CD. It might be an option to extend d-cds functionality in such a way that Recommends do get considered, but only _after_ dependencies for all tasks relevant for a CD/DVD set. I must say that I'm not at all sure that the change to include Recommends wasn't done prematurely or too lightly. It is quite likely to also affect the server tasks in quite a big way and could have a major impact on the contents of CD images if not handled correctly. I also wonder what impact it will have on the total installed size of the different desktop environments and server tasks as documented in the manual. Quite likely testing task installs in emulators will be a bigger pain than it already is and the available space check in tasksel for the desktop task will probably need adjustment (4GB instead of the current 3GB?). One option could of course be to not change d-cds functionality at all and only install Recommends if available (either from additional CDs or a mirror), which does seem to fit its purpose. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#532515: on making decisions vs letting things happen
On Sunday 05 July 2009, Frans Pop wrote: I must say that I'm not at all sure that the change to include Recommends wasn't done prematurely or too lightly. It is quite likely to also affect the server tasks in quite a big way and could have a major impact on the contents of CD images if not handled correctly. I also feel it is rather inconsistent to have tasksel install Recommends while debootstrap and base-installer do not. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Which kernels to include on ISOs? (Was: Re: Netboot Xen images for amd64)
On Thursday 04 June 2009, Ian Campbell wrote: On Thu, 2009-06-04 at 01:10 +0200, Frans Pop wrote: [...snipped a bunch of good points which I won't contest...] :-) But there is one image that might exactly fit the bill: the i386/amd64/ppc multi-arch netinst CD. Current size (Lenny): 488MB. For that it does not matter if it would grow a bit, and it's targeted exactly at your users: (semi-)professional sysadmins. That sounds ideal, thanks for the suggestion. Am I right in thinking that a netinst CD includes the base system but not any of the other stuff? (as opposed to just including the installer itself) Correct. But if you implement it correctly, building a Xen businesscard image (multi-arch or not) should automatically be supported too. Only problem is that implementing adding Xen to just that image will require a fair few changes in debian-cd. In configuration, but I think also in code (you'll need to introduce a concept of variants within arches for D-I tasks). It'll not be trivial to implement that cleanly, though it should certainly be possible. Do you have any specific guidance regarding the direction you'd like to see me take with this or shall I just dive in and see what I come up with? Initially from the debian-cd end I'm thinking along the lines of adding -DMULTIARCH=1 (where appropriate) to the preprocessor when generating the package lists. That sounds wrong. The condition is not am I building multiarch?. It should be please build a multi-arch image, but add Xen variations. I.e, building a normal m-a image should still be possible and should be default. The challenge is to find a way to specify that _optionally_ the bits needed for Xen should be added on top of the normal image. There are three things you need to accomplish: 1) include the kernel udebs for 686-bigmem on the image 2) include the 686-bigmem kernel-image deb (+ maybe headers packages?) 3) support it in build scripts on farbror (d-cd buildd) and possibly the easybuild script (recommended for testing!) For 1) you need to somehow ensure the 686-bigmem udebs do *not get excluded* for only (!) the m-a netinst CD (see tools/generate_di_list and data/squeeze/exclude-udebs-i386), but not for other images. Similar challenge for 2). Kernel packages get included through the script ools/generate_di+k_list, which currently does not allow for variations within an architecture. Ignore the tasks directory: that is only used for full CD and DVD images, not for netinst and businesscard. For 3) you can find the current build scripts used on farbror at [1]. The please add Xen support option should be set in the cronjob.daily script in the bit starting with: for arch in $ARCHES; do echo Building $arch: if [ $arch = multi-arch ] ; then echo i386/amd64/ppc sid netinst [...] echo i386/amd64/ppc squeeze netinst IMO it should be something like adding 'VARIANT=xen', which should automatically only result in changes for arches that support the variant (the m-a CD also includes powerpc, which does not support Xen, and thus should build without any differences with or without the VARIANT option passed). Bonus points if it can be implemented in such a way that 'VARIANT=foo,bar,baz' would be supported too (but that might be tricky with the exclude-udeb files; maybe those need a different implementation anyway?). Such a variant option could be included in the default CONF.sh (commented out by default) and could also be added in the easybuild.sh script (either commented out by default or activated with a new parameter). All the above is subject to comments from Steve McIntyre. Please check your planned solution with him (by mailing d-cd list). Cheers, FJP [1] http://svn.debian.org/wsvn/debian-cd/setup/#_setup_ -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Which kernels to include on ISOs? (Was: Re: Netboot Xen images for amd64)
On Thursday 04 June 2009, Frans Pop wrote: There are three things you need to accomplish: 1) include the kernel udebs for 686-bigmem on the image 2) include the 686-bigmem kernel-image deb (+ maybe headers packages?) 3) support it in build scripts on farbror (d-cd buildd) and possibly the easybuild script (recommended for testing!) Ah, and you need to actually include the correct D-I initrd and kernel on the CD of course. And you'll need to modify the syslinux boot menu so that an install Xen option gets added. Both of those mean changes in the boot-x86 and x86-desktop.sh scripts in tools/boot/sqeeze/ [1]. A regular install should remain the default of course. Cheers, FJP [1] I committed some fairly heavy changes in both D-I and d-cd early this week for that. You may want to look at both the old and new version as the old version shows how you could manipulate the syslinux config to add the options in d-cd. I don't think the base syslinux config in d-i should need to be changed for this. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Which kernels to include on ISOs? (Was: Re: Netboot Xen images for amd64)
On Friday 22 May 2009, Ian Campbell wrote: On Sat, 2009-04-18 at 12:49 +0200, Frans Pop wrote: Also note that adding the 686-bigmem kernel to CD images still has a rather high impact (as you'd need to add both the kernel udeb _and_ the regular kernel-image deb), which is rather undesirable for both the netinst CD and the regular CD1. In the first case because of the size increase it would cause [1], in the second case because it would push packages important for the desktop task off CD1. Even the DVD1 image is getting tight as we currently support installation of _all_ desktop environments from it. The margin for businesscard images depends mainly on the capacity of actual businesscard sized media. I've been thinking about this some more and I wonder if 486 + 686 is still the best option for DVD1 -- as opposed to 486 + 686-bigmem. Yes, I'm very sure it is. IMHO the set of machines which benefit from a 686 kernel but are unable to run a 686-bigmem kernel is already small and getting smaller. I reckon those machine would be fine with a 486 kernel anyway, the 686 optimisations don't buy you that much and SMP-but-non-PAE machine are an even smaller set (if such a thing even exists, I'm not sure). I'm afraid I quite strongly disagree with you on this. 1) 686-bigmem has a significant performance penalty for systems that don't need it (otherwise it would be a non-issue as the option would just be enabled in the generic -686 kernel). 2) I guestimate that 90% of systems that really need a -686 kernel have less memory than the limit supported by the generic -686 kernel. Random sample: I have three desktops and a laptop running 686, and none of them comes even close to that limit. 3) IIRC there are fairly significant differences between -486 and -686 performance on normal Pentiums and AMD boxes. 4) According to Linus, anybody who fits huge amounts of memory in normal Pentium systems is insane as the lowmem/highmem distinction will always continue to hurt you. 5) I would think that the set of machines you're aiming at is mostly 64-bit capable (the 32-bit segment can hardly be said to be growing). In that case they really should be running either the amd64 arch, or, if they really want a 32-bit userland, i386, but with the -amd64 kernel [0]! I expect that last would support Xen as well. IMO your argumentation is strongly colored by your own goals here. New machines these days already have 1-2G as a pretty basic minimum and And are 64-bit capable and thus shouldn't be using -686 at all! I predict that when squeeze arrives getting on for 4G will be a common default. A PAE kernel starts to become necessary around 3.5G anyway due to the PCI hole and even for machines with 3.5G of RAM you get things like NX support thrown in. The 686 kernel is still just an aptitude run away. *shrug* so is the -bigmem kernel [1]. A more important issue for me is that we should make sure to install the correct *generic* kernel for regular users and leave specialized kernels to experts. And now something slightly more constructive. Personally I would say that full CD and DVD are not even very interesting for Xen installs: their content is desktop oriented, so why download a lot of shite you're not going to be using anyway? Netinst and businesscard are much more relevant, but as explained earlier those have space restrictions. But there is one image that might exactly fit the bill: the i386/amd64/ppc multi-arch netinst CD. Current size (Lenny): 488MB. For that it does not matter if it would grow a bit, and it's targeted exactly at your users: (semi-)professional sysadmins. Only problem is that implementing adding Xen to just that image will require a fair few changes in debian-cd. In configuration, but I think also in code (you'll need to introduce a concept of variants within arches for D-I tasks). It'll not be trivial to implement that cleanly, though it should certainly be possible. I'm afraid that I have no real affinity with Xen (the current discussion on lkml rather amuses me TBH), so I don't think I'd work on that [2]. Cheers, FJP [0] Supporting automatic selection of the -amd64 flavor in D-I for i386 has never really been discussed. It would be interesting, but again the space limitations would have to be carefully considered. [1] Yes, I know, that doesn't work if you want to install Xen. [2] Though I would consider doing it for a suitable bounty. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: question
On Tuesday 26 May 2009, mi...@pocomail.de wrote: hi and thank you for that answer, but shouldn?t etch be found here ? http://archive.debian.org/debian/dists/ i don?t see it, may you give me the full path to it ? Oh, sorry. I made a mistake. Etch is not on archive.debian.org yet. It *should* still be on the normal mirrors as oldstable, see for example [1]. If your current mirror does not have that, it is incomplete and you should switch to a different mirror. Etch will only be archived after security support for it is stopped. Sorry for the confusion. I was confused by your statement that etch no longer was on the regular mirrors. It really is still there, or at least should be on most of them and especially on all so called primary mirrors. [1] http://ftp.nl.debian.org/debian/dists/ -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: question
(No need to CC me, I get the mail on the list.) On Tuesday 26 May 2009, mi...@pocomail.de wrote: do you have any advise for me creating my own private mirror at home ? are there any howtos you can prefer ? Here's how I do it: http://alioth.debian.org/~fjp/debmirror/ But please make sure you really DO need a local mirror before setting one up. You may be better served with just using something like approx or apt-proxy(-v2). -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: question
On Monday 25 May 2009, mi...@pocomail.de wrote: hope you can help me. if i want to install etch today, which mirrors do i have to use ??? it seems like the old one (since lenny is out) are no longer working. http://archive.debian.org/ Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lenny 501 and presseding
On Tuesday 12 May 2009, Frédéric DONNAT wrote: I could get ride of my problem with a mount: d-i preseed/late_command string mount -o bind /cdrom /target/cdrom; in-target ..etc.. In fact, the cdrom is mounted on the install system but it seems that when we chroot this bind is missing... ;( Ah, yes. That is correct. For Lenny the cd is only mounted in the /target environment on demand by apt-cdrom in order to be able to support CD changing during the installation of packages. Make sure you unmount the CD again at the end of your script or things might blow up (although that's somewhat unlikely to happen at the late stage preseed/late is executed). -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lenny 501 and presseding
On Thursday 07 May 2009, Frédéric DONNAT wrote: I could not successfully pressed some questions while partionning: - Partition disks + First Question: + Second Question: Check the *lenny version* of the installantion guide for the correct way to preseed this. There've been some changes since Etch. - Launching late command Here is my late_command (works fine under etch): d-i preseed/late_command string in-target /cdrom/mailinblack/install.sh I get an error: Failed to run pressed command Execution of preseeded command in-target /cdrom/mailinblack/install.sh failed with exit code 1 In the Alt+F4 screen I get: in-target: chroot: cannot execute /cdrom/mailinblack/install.sh: No such file or directory At that point it seems that the cdrom is not mounted when I chroot, so AFAIK it should still be mounted at that point (late command is run at 07 in finish-install, while the CD is only unmounted at 15). Possibly something else went wrong earlier in the installation. Cheers, FJP P.S. This is not the best list to report this. If you have any additional questions then please mail the debian-boot list and add the syslog from your install. P.P.S. Only the installation guide is really reliable as documentation for preseeding. The other documents you used may be outdated or simply incorrect. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Probable increase in size of installation guide on Lenny CDs
I'm currently preparing an update of the Installation Guide for stable. With that release I hope to re-enable the Vietnamese translation which was not updated in time for Lenny, but has been updated since. This will mean that with the next point release the manual may take an additional 1.3 to 1.5 MB per architecture on CD1, possibly pushing a few packages off the end. Other changes are minor and should have only a very small size impact. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: where are all Debian SPARC install CDs/DVDs?
On Saturday 18 April 2009, Marcello Di Marino Azevedo wrote: Hello, I'm not sure this is the correct list to ask this but I was askedto install Debian on a Sparc machine but not all CDs/DVDs are available to download under main download server. Looking at: http://cdimage.debian.org/debian-cd/5.0.1/sparc/iso-cd/ and http://cdimage.debian.org/debian-cd/5.0.1/sparc/iso-dvd/ If you open MD5SUMS or SHA1SUMS you will notice that there are 5 regular DVDs listed but only 1 DVD iso image available to download. Similar thing for CDs, 30 regular CDs but only 3 available to download. For the less popular architectures only the first few images are available for download as ISO images, the rest can only be downloaded using jigdo. Reason is to reduce the disk space required for mirrors. See http://cdimage.debian.org/debian-cd/5.0.1/sparc/jigdo-cd/. This is something that is probably not yet sufficiently documented on the website. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523444: debian-cd: Should allow for new Breaks: field in Packages files
Package: debian-cd Version: 3.1.1 Severity: minor Running sort_deps to sort packages for i386: Generating dependency tree with apt-cache depends... UNEXPECTED: Line ` Breaks: docutils-writer-manpage ' while parsing end of deptree from 'python-docutils' UNEXPECTED: Line ` Breaks: python-odtwriter ' while parsing end of deptree from 'python-docutils' UNEXPECTED: Line ` Breaks: gnome-system-tools ' while parsing end of deptree from 'system-tools-backends' UNEXPECTED: Line ` Breaks: libavcodec51 ' while parsing end of deptree from 'libavformat52' UNEXPECTED: Line ` Breaks: gnome-themes-extras ' while parsing end of deptree from 'gtk2-engines' -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523017: debian-cd: Doesn't support local udebs if using a repo that requires section: local/debian-installer for local udebs
On Tuesday 07 April 2009, Daniel Dickinson wrote:
I'm using reprepro and in order to get packages stored in the local
dist I have to use Section: local/section (therefore
local/debian-installer for custom debian-installer udebs). debian-cd
doesn't create Packages{.gz} files for local/debian-installer. This
patch fixes that.
Looks OK in principle, but please always submit patches as a unified diff
(i.e. using the '-u' option). Also, the patch does not include the diff
header which shows what file it is against. Without that it cannot be
applied using the 'patch' command.
Finally, why are some of the added lines commented out? If they are not
needed, they should not be included in the patch; if they are, they
should obviously not be commented out.
Can you resend a cleaned up patch please?
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Live 5.0.0 i386 is maybe not i386
On Sunday 15 March 2009, Richard Atterer wrote: Even if this had not been done, installation might still have failed on that machine because the Debian installer needs quite a bit of RAM. http://www.debian.org/releases/stable/i386/ch02s05.html.en claims 44 MB, but again I think the figure is actually higher today. No, that figure is still correct. You can even install on systems with as little as 24MB using the regular installer if you know what you're doing. But the *live CD* is NOT Debian Installer!!! The live CD does need a *lot* more memory than the regular installer and may also be using a different kernel. You may have better luck trying the regular installer. Note also that the live CD is (currently) not covered at all by the installation guide. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: creating a bootable CD ...
On Monday 09 March 2009, nanoinve...@web.de wrote: ich can't create a bootable CD from the debian-500-ia64-netinst.iso or debian-500-ia64-businesscard.iso. Also the debian-500-ia64-DVD-1.iso doesn't boot. I'm not a novice so it is embarrassing, somewhere I made a stupid mistake. You've selected the incorrect architecture. IA64 is for Intel Itanium processors, not regular 64-bit PC processors. You want a CD for the amd64 architecture. This is documented in quite a few places as unfortunately it's a mistake that is made fairly often. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518145: Missing dependencies on official Lenny installation CDs
severity 518145 minor thanks On Wednesday 04 March 2009, Julian Andres Klode wrote: The package gnome depends on gnome-app-install. gnome is located on CD1, gnome-app-install on CD2. This is more a feature than a bug. I.e, it's just a consequence of how packages are added to images and does not cause any problems during installation. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518145: Missing dependencies on official Lenny installation CDs
On Wednesday 04 March 2009, Julian Andres Klode wrote: I would say if you only have CD1, gnome is not installable, because some of its dependencies are missing. That's very simply not true. The gnome meta package is not required to install the gnome desktop environment. The key package for the gnome desktop task is gnome-desktop-environment, not gnome. (It is of course true for the meta package gnome itself, but that's not a very important issue.) And this is not good, because at least in my opinion, any package on any disk should be installable by using only the previous disks and the disk it is located on. Sure, that would be nice. But it's not a hard requirement. For debian-cd it is mostly true, except that near the end of a CD it is possible that a package makes it onto CDx while some dependencies end up on CDx+1. For packages with huge dependency trees such as gnome the risk that this happens is larger than for most. -- 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 Wednesday 11 February 2009, Steve McIntyre wrote: In fact, I'd say the simplest answer would be to pick the first named arch. If we're doing source-only then don't run update_tasks at all. How does that sound? Bad IMO. It means: - m-a image may be different when built with i386 amd64 than when built with amd64 i386; this is even more true for i386 powerpc versus powerpc i386; IMO the order in which arches are listed should not change the resulting image - source only set will have packages in in a completely different order from the corresponding binary set -- 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 Wednesday 11 February 2009, Steve McIntyre wrote: Bad IMO. It means: - m-a image may be different when built with i386 amd64 than when built with amd64 i386; this is even more true for i386 powerpc versus powerpc i386; IMO the order in which arches are listed should not change the resulting image It's always likely to, though: imagine if we don't have the space for the two different-arch versions of the last package in the image. The order that we add things is likely going to affect which one is missed out. That's an edge case. I'm talking about packages going missing completely because they are e.g. available for i386, but not for powerpc. Which means that if you run update_tasks based on powerpc the packages just won't be there on the early CDs. As I've mentioned before in this thread the only correct solution is to somehow run update_tasks for each arch and merge them. But that will only result in a really stable list if the merge is effectively done line-by-line (a package that is listed 5th for a task for the second arch should not end up below a package that is listed 200th for the same task for the first arch, or even worse after the packages for all tasks for the first arch). The problem is not trivially solvable and because of that I'd prefer to use a logic that is at least predictable and gives the best result for our primary architectures. -- 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 Wednesday 11 February 2009, Steve McIntyre wrote: In fact, simply looking at the lenny RC2 images you can see that sources are in alphabetical order. We may as well simply not do anything in the $(TASKDIR): target for a source-only build and save the processing time. Agreed? I don't know. I'd have to check in detail why tasks get ignored (for which I'm not motivated) and IMO this is the wrong time to be making such changes anyway. You're not going to get any real testing or feedback anymore before the release. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Udeb migrations (was: Meeting(s) at FOSDEM)
As requested during the meeting here are two links that explain udeb migration. The first also has a proposal how to improve udeb support in britney. Please ignore the introductory comment about the python implementation of britney. Note that the proposal is not a perfect solution. For that we would need to change the dependency handling for udebs which requires changes in various build tools and D-I. http://lists.debian.org/debian-release/2007/05/msg00086.html http://lists.debian.org/debian-boot/2008/04/msg00132.html Cheers, FJP 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 Thursday 05 February 2009, Frans Pop wrote: On Thursday 05 February 2009, Jonathan Hall wrote: --- debian-cd/tools/update_tasks(revision 7407) +++ debian-cd/tools/update_tasks(revision 7487) 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. This is not going to work as we don't only need the tasksel package, but also the Packages file for a specific arch as that is our basis for the task expansion. So, although which_deb could be used to get tasksel, it would not solve the whole problem. So the following really has to be implemented in update_tasks itself. On Thursday 05 February 2009, Frans Pop wrote: 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 But, given the reasons I gave in [1], we could also do this a bit differently and as a bonus improve the task expansion: * if ARCHES contains a single arch OR a single arch + source, then use that arch * if ARCHES contains multiple arches or is source-only, then use i386 with a fallback to the arches listed in ARCHES This means in most cases we'll do exactly the right thing. Except for multi-arch images, and for those we use the most generic default we have, which at least ensures consistency (amd64 i386 powerpc will give the same result as powerpc amd64 i386). [1] http://bugs.debian.org/514237#40 -- 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 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.
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.
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.
