Bug#779616: debian-cd: broken debian-testing-$arch-netinst.iso generation?
Steve McIntyre (2015-03-08): > On Fri, Mar 06, 2015 at 06:51:46PM +0100, Cyril Brulebois wrote: > > Thinking a bit more about this: I think having weekly testing with > > everything from testing makes the most sense. > > OK... Are we going to do more frequent d-i uploads to make sure that > works, though? I can't promise anything. Mraw, KiBi. signature.asc Description: Digital signature
Bug#779616: debian-cd: broken debian-testing-$arch-netinst.iso generation?
On Fri, Mar 06, 2015 at 06:51:46PM +0100, Cyril Brulebois wrote: >Ian Campbell (2015-03-05): >> >> I think the ABI only guarantees you can load old modules into a newer >> vmlinuz. In particular I think it doesn't guarantee that you can load >> newer modules into an older vmlinuz (even if the ABI is the same). >> >> The ABI is there to stop your existing modules from breaking when you >> update the kernel. >> >> IOW it is permissible for a module to gain a dependency on a new symbol >> provided by a newer vmlinuz. Right, that helps explain. Thanks Ian! >> This is why local netboot pxe infra sometimes breaks -- they have a >> vmlinuz downloaded locally but are pulling udebs off the network, which >> might therefore be newer. >> >> Please reread my caveat now though ;-) > >Why do I forget about this all the time? :( > >Thinking a bit more about this: I think having weekly testing with >everything from testing makes the most sense. OK... Are we going to do more frequent d-i uploads to make sure that works, though? It looks like the changes for (daily) builds are going to force quite a lot of work on us here. I'm quite prepared to help with that when I'm back (and have more time!) in a week or so... >We could have a separate, not-labelled-testing but rather “daily” or >bleeding-edge or something in that spirit (but neither experimental nor >sid) that picks d-i on d-i.d.o and udebs from sid. I'm not sure it would >be reasonable to expect such a build on a daily basis (maybe by reducing >the generated images to the bare minimum?), but then we would have a >clear winner as far as the name goes… Right. -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150308135605.gp6...@einval.com
Bug#779616: debian-cd: broken debian-testing-$arch-netinst.iso generation?
On Thu, Mar 05, 2015 at 12:25:50PM +0100, Cyril Brulebois wrote: >Steve McIntyre (2015-03-05): >> >> We've had this discussion befire, surely? On pettersson we rsync >> things (over ssh) directly from d-i.d.o (dillon), so we don't depend >> on http or git. Or am I missing something new? (I can't see #746967 >> atm...) There's also an explicit warning in debian-cd if you grab >> things via plain http or ftp: >> >> echo "WARNING WARNING WARNING WARNING WARNING WARNING" >> echo "$0: insecure download for d-i build: $DI_WWW_HOME" >> echo "WARNING WARNING WARNING WARNING WARNING WARNING" > >The rsync part covers the former, but there's still a broken trust chain >because of the latter. Right, I've just had a chance to look at that now. Ugh... :-( >> OK. Assuming amd64 is working OK, I should check the rsync has not >> broken - that seems to be the most likely cause right now. Thinking: >> it would also be lovely to verify the versions of vmlinuz and the >> kernel udebs in debian-cd at build time, and (optionally?) abort the >> build if we know we're going to be making broken images. What do you >> think? > >There's no way for us to know a breakage is going to happen. In this >particular case the ABI is the same, say 3.16.0-4-amd64; the ABI is >embedded in kernel udeb package names, so if the ABI matches, udebs are >supposed to be compatible with the kernel. I'm not sure why that is not >the case here (maybe the ABI doesn't cover or not completely udebs?). We >really shouldn't enforce using the very same revision for kernel and >module udebs, IMHO. ACK, I see your logic. >> In the past, we had the two different sets of daily images: >> >> * use the most recent testing version of d-i in tha archive >> * use the daily d-i builds from d-i.d.o (and other hosts before that) >> >> and then we'd switch the weekly images from one source to the other >> depending on how working/broken we thought each source was likely to >> be. Since the kernel team got much more active a few years back and >> kernel ABI changes have been much more common during the life of >> testing, using the most recent d-i release from the archive has had a >> much shorter working life than we used to have. Hence, we switched >> over to using the daily d-i builds as a base. >> >> This can be YA argument for more regular d-i uploads to the archive to >> fix that problem, of course. But we know how much work that >> involves. At the moment I feel what we have is just about the best >> thing we can get without that massive additional effort. It normally >> works for people, modulo the odd breakage from time to time like we've >> seen here. > >I guess we could stick to this once the trust issue is resolved. Daily >builds will have to be changed one way or another anyway since it can't >be implemented as done previously starting with jessie hosts… Right, yes. Anyone have any bright ideas yet on how to do that? -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150308134848.go6...@einval.com
Bug#779616: debian-cd: broken debian-testing-$arch-netinst.iso generation?
Ian Campbell (2015-03-05): > On Thu, 2015-03-05 at 12:25 +0100, Cyril Brulebois wrote: > > > OK. Assuming amd64 is working OK, I should check the rsync has not > > > broken - that seems to be the most likely cause right now. Thinking: > > > it would also be lovely to verify the versions of vmlinuz and the > > > kernel udebs in debian-cd at build time, and (optionally?) abort the > > > build if we know we're going to be making broken images. What do you > > > think? > > > > There's no way for us to know a breakage is going to happen. In this > > particular case the ABI is the same, say 3.16.0-4-amd64; the ABI is > > embedded in kernel udeb package names, so if the ABI matches, udebs are > > supposed to be compatible with the kernel. I'm not sure why that is not > > the case here (maybe the ABI doesn't cover or not completely udebs?). We > > really shouldn't enforce using the very same revision for kernel and > > module udebs, IMHO. > > Caveat: I might be talking out my a**e here... > > I think the ABI only guarantees you can load old modules into a newer > vmlinuz. In particular I think it doesn't guarantee that you can load > newer modules into an older vmlinuz (even if the ABI is the same). > > The ABI is there to stop your existing modules from breaking when you > update the kernel. > > IOW it is permissible for a module to gain a dependency on a new symbol > provided by a newer vmlinuz. > > This is why local netboot pxe infra sometimes breaks -- they have a > vmlinuz downloaded locally but are pulling udebs off the network, which > might therefore be newer. > > Please reread my caveat now though ;-) Why do I forget about this all the time? :( Thinking a bit more about this: I think having weekly testing with everything from testing makes the most sense. We could have a separate, not-labelled-testing but rather “daily” or bleeding-edge or something in that spirit (but neither experimental nor sid) that picks d-i on d-i.d.o and udebs from sid. I'm not sure it would be reasonable to expect such a build on a daily basis (maybe by reducing the generated images to the bare minimum?), but then we would have a clear winner as far as the name goes… Mraw, KiBi. signature.asc Description: Digital signature
Bug#779616: debian-cd: broken debian-testing-$arch-netinst.iso generation?
On Thu, 2015-03-05 at 12:25 +0100, Cyril Brulebois wrote: > > OK. Assuming amd64 is working OK, I should check the rsync has not > > broken - that seems to be the most likely cause right now. Thinking: > > it would also be lovely to verify the versions of vmlinuz and the > > kernel udebs in debian-cd at build time, and (optionally?) abort the > > build if we know we're going to be making broken images. What do you > > think? > > There's no way for us to know a breakage is going to happen. In this > particular case the ABI is the same, say 3.16.0-4-amd64; the ABI is > embedded in kernel udeb package names, so if the ABI matches, udebs are > supposed to be compatible with the kernel. I'm not sure why that is not > the case here (maybe the ABI doesn't cover or not completely udebs?). We > really shouldn't enforce using the very same revision for kernel and > module udebs, IMHO. Caveat: I might be talking out my a**e here... I think the ABI only guarantees you can load old modules into a newer vmlinuz. In particular I think it doesn't guarantee that you can load newer modules into an older vmlinuz (even if the ABI is the same). The ABI is there to stop your existing modules from breaking when you update the kernel. IOW it is permissible for a module to gain a dependency on a new symbol provided by a newer vmlinuz. This is why local netboot pxe infra sometimes breaks -- they have a vmlinuz downloaded locally but are pulling udebs off the network, which might therefore be newer. Please reread my caveat now though ;-) Ian. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1425568787.25940.233.ca...@debian.org
Bug#779616: debian-cd: broken debian-testing-$arch-netinst.iso generation?
Steve McIntyre (2015-03-05): > [ Writing this off-line again while travelling so I can't check things > directly on pettersson etc. ] ACK. > On Tue, Mar 03, 2015 at 03:47:12PM +0100, Cyril Brulebois wrote: > >Steve McIntyre (2015-03-03): > >> Hmmm. That's very odd. The weekly builds are currently set up to use > >> daily d-i builds rather than what's in the archive, and they've been > >> that way for a long time. > > > >I don't think that's a good idea. For one thing, there's no trust chain > >here (from d-i.d.o because http; and from git, because #746967). > > We've had this discussion befire, surely? On pettersson we rsync > things (over ssh) directly from d-i.d.o (dillon), so we don't depend > on http or git. Or am I missing something new? (I can't see #746967 > atm...) There's also an explicit warning in debian-cd if you grab > things via plain http or ftp: > > echo "WARNING WARNING WARNING WARNING WARNING WARNING" > echo "$0: insecure download for d-i build: $DI_WWW_HOME" > echo "WARNING WARNING WARNING WARNING WARNING WARNING" The rsync part covers the former, but there's still a broken trust chain because of the latter. > >> We've been using the daily d-i builds for a long time, to guard > >> against exactly this kind of breakage with kernel version > >> mismatches. Has something changed? > > > >Some archs are missing daily builds, because autobuilding in jessie is > >broken, but AFAICT missing builds are only: > > - arm64 > > - ppc64el > > - sparc > > > >(See http://d-i.debian.org/daily-images/daily-build-overview.html) > > OK. Assuming amd64 is working OK, I should check the rsync has not > broken - that seems to be the most likely cause right now. Thinking: > it would also be lovely to verify the versions of vmlinuz and the > kernel udebs in debian-cd at build time, and (optionally?) abort the > build if we know we're going to be making broken images. What do you > think? There's no way for us to know a breakage is going to happen. In this particular case the ABI is the same, say 3.16.0-4-amd64; the ABI is embedded in kernel udeb package names, so if the ABI matches, udebs are supposed to be compatible with the kernel. I'm not sure why that is not the case here (maybe the ABI doesn't cover or not completely udebs?). We really shouldn't enforce using the very same revision for kernel and module udebs, IMHO. > >We probably should start by figuring out what d-i we want to embed (see > >first paragraph). Having (some, maybe not the whole set of) images with > >a daily d-i (if we can fix the trust chain) would be nice. But that > >really shouldn't be labelled “official testing images” as currently > >done. > > I'm definitely open to suggestions on what else we should be > providing. I'm not 100% sure the best way to go, though... > > In the past, we had the two different sets of daily images: > > * use the most recent testing version of d-i in tha archive > * use the daily d-i builds from d-i.d.o (and other hosts before that) > > and then we'd switch the weekly images from one source to the other > depending on how working/broken we thought each source was likely to > be. Since the kernel team got much more active a few years back and > kernel ABI changes have been much more common during the life of > testing, using the most recent d-i release from the archive has had a > much shorter working life than we used to have. Hence, we switched > over to using the daily d-i builds as a base. > > This can be YA argument for more regular d-i uploads to the archive to > fix that problem, of course. But we know how much work that > involves. At the moment I feel what we have is just about the best > thing we can get without that massive additional effort. It normally > works for people, modulo the odd breakage from time to time like we've > seen here. I guess we could stick to this once the trust issue is resolved. Daily builds will have to be changed one way or another anyway since it can't be implemented as done previously starting with jessie hosts… > >Being able to spin some weekly build (possibly manually) with what's in > >*sid* (i.e. not dailies) is nice to figure out whether we're going to > >end up with breakages if/when d-i/sid migrates to testing, before we > >build official release images. Not sure it gains us much compared to > >first migrating d-i/sid to testing and building images, though. > > Yeah :-/ We've done that in the past, and it's not that difficult to > configure debian-cd to do this. But IIRC it never really gave us much. OK… Mraw, KiBi. signature.asc Description: Digital signature
Bug#779616: debian-cd: broken debian-testing-$arch-netinst.iso generation?
[ Writing this off-line again while travelling so I can't check things directly on pettersson etc. ] Hi KiBi, On Tue, Mar 03, 2015 at 03:47:12PM +0100, Cyril Brulebois wrote: >Steve McIntyre (2015-03-03): >> Hmmm. That's very odd. The weekly builds are currently set up to use >> daily d-i builds rather than what's in the archive, and they've been >> that way for a long time. > >I don't think that's a good idea. For one thing, there's no trust chain >here (from d-i.d.o because http; and from git, because #746967). We've had this discussion befire, surely? On pettersson we rsync things (over ssh) directly from d-i.d.o (dillon), so we don't depend on http or git. Or am I missing something new? (I can't see #746967 atm...) There's also an explicit warning in debian-cd if you grab things via plain http or ftp: echo "WARNING WARNING WARNING WARNING WARNING WARNING" echo "$0: insecure download for d-i build: $DI_WWW_HOME" echo "WARNING WARNING WARNING WARNING WARNING WARNING" >> As such, we also use sid udebs for debian-installer, as that should >> match what we'll be getting from the daily d-i builds which are built >> using sid. Are you sure that the kernel there is old? If so, that's >> the bug I think. It's difficult for me to check exactly right now what >> that kernel version is. > >I extracted the kernel from the iso, and looked at its version string. >The guy who reported that issue to me also mentioned that (even if non >publicly, and I still haven't seen him open a proper bug report). OK, thanks for checking that. >> We've been using the daily d-i builds for a long time, to guard >> against exactly this kind of breakage with kernel version >> mismatches. Has something changed? > >Some archs are missing daily builds, because autobuilding in jessie is >broken, but AFAICT missing builds are only: > - arm64 > - ppc64el > - sparc > >(See http://d-i.debian.org/daily-images/daily-build-overview.html) OK. Assuming amd64 is working OK, I should check the rsync has not broken - that seems to be the most likely cause right now. Thinking: it would also be lovely to verify the versions of vmlinuz and the kernel udebs in debian-cd at build time, and (optionally?) abort the build if we know we're going to be making broken images. What do you think? >I certainly didn't touch anything on pettersson, or anything remotely >involving debian-cd as far as I can remember. Yup. >> ACK. That's old wording, and has always been confusing. Given we don't >> tend to upload to the archive like normal packages anyway, it's best >> to just remove the "sid" mention altogether I think. Ditto the >> mentions of sid etc. in the daily-builds area coule do with fixing up >> I think? > >We probably should start by figuring out what d-i we want to embed (see >first paragraph). Having (some, maybe not the whole set of) images with >a daily d-i (if we can fix the trust chain) would be nice. But that >really shouldn't be labelled “official testing images” as currently >done. I'm definitely open to suggestions on what else we should be providing. I'm not 100% sure the best way to go, though... In the past, we had the two different sets of daily images: * use the most recent testing version of d-i in tha archive * use the daily d-i builds from d-i.d.o (and other hosts before that) and then we'd switch the weekly images from one source to the other depending on how working/broken we thought each source was likely to be. Since the kernel team got much more active a few years back and kernel ABI changes have been much more common during the life of testing, using the most recent d-i release from the archive has had a much shorter working life than we used to have. Hence, we switched over to using the daily d-i builds as a base. This can be YA argument for more regular d-i uploads to the archive to fix that problem, of course. But we know how much work that involves. At the moment I feel what we have is just about the best thing we can get without that massive additional effort. It normally works for people, modulo the odd breakage from time to time like we've seen here. >Being able to spin some weekly build (possibly manually) with what's in >*sid* (i.e. not dailies) is nice to figure out whether we're going to >end up with breakages if/when d-i/sid migrates to testing, before we >build official release images. Not sure it gains us much compared to >first migrating d-i/sid to testing and building images, though. Yeah :-/ We've done that in the past, and it's not that difficult to configure debian-cd to do this. But IIRC it never really gave us much. -- Steve McIntyre, Cambridge, UK.st...@einval.com "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150305090550.gc6...@einval.co
Bug#779616: debian-cd: broken debian-testing-$arch-netinst.iso generation?
Hi, Steve McIntyre (2015-03-03): > Hmmm. That's very odd. The weekly builds are currently set up to use > daily d-i builds rather than what's in the archive, and they've been > that way for a long time. I don't think that's a good idea. For one thing, there's no trust chain here (from d-i.d.o because http; and from git, because #746967). > As such, we also use sid udebs for debian-installer, as that should > match what we'll be getting from the daily d-i builds which are built > using sid. Are you sure that the kernel there is old? If so, that's > the bug I think. It's difficult for me to check exactly right now what > that kernel version is. I extracted the kernel from the iso, and looked at its version string. The guy who reported that issue to me also mentioned that (even if non publicly, and I still haven't seen him open a proper bug report). > We've been using the daily d-i builds for a long time, to guard > against exactly this kind of breakage with kernel version > mismatches. Has something changed? Some archs are missing daily builds, because autobuilding in jessie is broken, but AFAICT missing builds are only: - arm64 - ppc64el - sparc (See http://d-i.debian.org/daily-images/daily-build-overview.html) I certainly didn't touch anything on pettersson, or anything remotely involving debian-cd as far as I can remember. > >I find the doc in the parent directory[3] quite confusing anyway: > >| These images are produced every week, normally on a Monday, but this may > >| vary. They include: > >| * The latest debian-installer build (currently the "sid" daily builds of > >the installer) > > > > 3. http://cdimage.debian.org/cdimage/weekly-builds/ > > > >It's either a daily build (from d-i.debian.org), or d-i from sid. > > ACK. That's old wording, and has always been confusing. Given we don't > tend to upload to the archive like normal packages anyway, it's best > to just remove the "sid" mention altogether I think. Ditto the > mentions of sid etc. in the daily-builds area coule do with fixing up > I think? We probably should start by figuring out what d-i we want to embed (see first paragraph). Having (some, maybe not the whole set of) images with a daily d-i (if we can fix the trust chain) would be nice. But that really shouldn't be labelled “official testing images” as currently done. Being able to spin some weekly build (possibly manually) with what's in *sid* (i.e. not dailies) is nice to figure out whether we're going to end up with breakages if/when d-i/sid migrates to testing, before we build official release images. Not sure it gains us much compared to first migrating d-i/sid to testing and building images, though. Mraw, KiBi. signature.asc Description: Digital signature
Bug#779616: debian-cd: broken debian-testing-$arch-netinst.iso generation?
Hi KiBi, On Tue, Mar 03, 2015 at 05:25:11AM +0100, Cyril Brulebois wrote: >Package: debian-cd >Severity: important > >Hi, > >it's been reported to me that debian-testing-amd64-netinst.iso[1] was >broken, in that it features d-i using an “old” kernel (3.16.7-ckt4-3), >but kernel udebs apparently from sid, as can be seen in the list >file[2]: they're at version 3.16.7-ckt7-1. > > 1. > http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso > 2. > http://cdimage.debian.org/cdimage/weekly-builds/amd64/list-cd/debian-testing-amd64-netinst.list.gz > >Given the kernel ABI hadn't been bumped, one might argue that the udebs >should still work and not break due to some unknown symbols, but that's >another topic. I really don't expect us to fetch bits from unstable in >testing images. Hmmm. That's very odd. The weekly builds are currently set up to use daily d-i builds rather than what's in the archive, and they've been that way for a long time. As such, we also use sid udebs for debian-installer, as that should match what we'll be getting from the daily d-i builds which are built using sid. Are you sure that the kernel there is old? If so, that's the bug I think. It's difficult for me to check exactly right now what that kernel version is. We've been using the daily d-i builds for a long time, to guard against exactly this kind of breakage with kernel version mismatches. Has something changed? >I find the doc in the parent directory[3] quite confusing anyway: >| These images are produced every week, normally on a Monday, but this may >| vary. They include: >| * The latest debian-installer build (currently the "sid" daily builds of >the installer) > > 3. http://cdimage.debian.org/cdimage/weekly-builds/ > >It's either a daily build (from d-i.debian.org), or d-i from sid. ACK. That's old wording, and has always been confusing. Given we don't tend to upload to the archive like normal packages anyway, it's best to just remove the "sid" mention altogether I think. Ditto the mentions of sid etc. in the daily-builds area coule do with fixing up I think? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast." Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150303133547.gx6...@einval.com
Bug#779616: debian-cd: broken debian-testing-$arch-netinst.iso generation?
Package: debian-cd Severity: important Hi, it's been reported to me that debian-testing-amd64-netinst.iso[1] was broken, in that it features d-i using an “old” kernel (3.16.7-ckt4-3), but kernel udebs apparently from sid, as can be seen in the list file[2]: they're at version 3.16.7-ckt7-1. 1. http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso 2. http://cdimage.debian.org/cdimage/weekly-builds/amd64/list-cd/debian-testing-amd64-netinst.list.gz Given the kernel ABI hadn't been bumped, one might argue that the udebs should still work and not break due to some unknown symbols, but that's another topic. I really don't expect us to fetch bits from unstable in testing images. I find the doc in the parent directory[3] quite confusing anyway: | These images are produced every week, normally on a Monday, but this may | vary. They include: | * The latest debian-installer build (currently the "sid" daily builds of the installer) 3. http://cdimage.debian.org/cdimage/weekly-builds/ It's either a daily build (from d-i.debian.org), or d-i from sid. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150303042511.5742.77863.report...@arya.home.mraw.org
Bug#569632: marked as done (debian-cd: broken isolinux configuration)
Your message dated Sun, 21 Feb 2010 23:04:47 + with message-id <20100221230447.gw1...@einval.com> and subject line Re: Bug#569632: debian-cd: broken isolinux configuration has caused the Debian Bug report #569632, regarding debian-cd: broken isolinux configuration to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 569632: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569632 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: debian-cd Version: 3.1.2 Severity: important when generating a squeeze CD, the isolinux configuration still contains templates so that the boot prompt line contains things such as: /%install%/vmlinuz ... desktop=%desktop% ... initrd=/%install%/initrd.gz ... with the debian-cd version in svn, this works fine. please consider uploading a new version of debian-cd to the archive. thanks! live well, vagrant --- End Message --- --- Begin Message --- On Fri, Feb 12, 2010 at 02:50:16PM -0800, Vagrant Cascadian wrote: >Package: debian-cd >Version: 3.1.2 >Severity: important > >when generating a squeeze CD, the isolinux configuration still contains >templates so that the boot prompt line contains things such as: > >/%install%/vmlinuz ... desktop=%desktop% ... initrd=/%install%/initrd.gz ... > >with the debian-cd version in svn, this works fine. please consider uploading a >new version of debian-cd to the archive. New upload in incoming right now... -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me --- End Message ---
Bug#569632: debian-cd: broken isolinux configuration
> when generating a squeeze CD, the isolinux configuration still > contains > templates so that the boot prompt line contains things such as: > /%install%/vmlinuz ... desktop=%desktop% ... initrd=/%install%/initrd.gz ... +1 This problem with debian-cd persists for amd configuration as well.. -- With luv n cheers., Prema
Bug#569632: debian-cd: broken isolinux configuration
Package: debian-cd Version: 3.1.2 Severity: important when generating a squeeze CD, the isolinux configuration still contains templates so that the boot prompt line contains things such as: /%install%/vmlinuz ... desktop=%desktop% ... initrd=/%install%/initrd.gz ... with the debian-cd version in svn, this works fine. please consider uploading a new version of debian-cd to the archive. thanks! live well, vagrant -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debian-cd broken?
Jan Kesten <[EMAIL PROTECTED]> writes: > I tried seems very good - thanks again! Good. > Was there anything changed recently at this point, because it worked a > long time? I've included the possibility to pre-process the exclude file like was did in task. So, you exclude can include another files, have #ifdefs and so on. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - "Microsoft gives you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-cd broken?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jan Kesten wrote: >I changed it already. Please can you and Jan check if works now? I tried seems very good - thanks again! Was there anything changed recently at this point, because it worked a long time? Cheers, Jan - -- GPG-KeyID: 82201FC4 Available at my public sks keyserver sks.nerdcamp.net Please report any problems using sks.nerdcamp.net! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAon/gvvmCkIIgH8QRAjTcAKDPQrciN0+IPDOBJUVs8FjmeTIspwCgzYnt ewlPowtv3VjMklIEKLOgL6Y= =ekhp -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-cd broken?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Otavio Salvador wrote: > I changed it already. Please can you and Jan check if works now? I tried to change this here too, and it seems to work now - if the run completes I'll let you know. Thank you for looking! Cheers, Jan - -- GPG-KeyID: 82201FC4 Available at my public sks keyserver sks.nerdcamp.net Please report any problems using sks.nerdcamp.net! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAonOAvvmCkIIgH8QRAo+ZAKCmfI2UshGxtrTkFNfTnupPrlH30ACcDrzD BYxARrDrRrjzkIBQEKHRS54= =JHol -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-cd broken?
Raphael Hertzog <[EMAIL PROTECTED]> writes: > otavio is responsible for that change, maybe he can sort it out ? :) > I bet that we could replace -n with -e and have a better test. Or we > should at least add quotes around $(EXCLUDE) in the test itself. I changed it already. Please can you and Jan check if works now? Thanks, Otavio -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - "Microsoft gives you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-cd broken?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Raphael Hertzog wrote: Hi Raphael! > Can you show the CONF.sh file that you're using ? Of course, I attached it :-) > It looks like there's a problem with your EXCLUDE variable ... in the As I remeber I didn't set one at all - perhaps this is the problem at the perl call. Was there any change I didn't notice? I've been using this CONF quite a time now, and it worked till yesterday? Cheers, Jan - -- GPG-KeyID: 82201FC4 Available at my public sks keyserver sks.nerdcamp.net Please report any problems using sks.nerdcamp.net! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAol7vvvmCkIIgH8QRArNHAJ9eSVhQdxxevxlVnROq20JB8ctjDwCfes6f dP5mztNSQb8WyqGAIno1+pw= =lZkX -END PGP SIGNATURE- # # This file will have to be sourced where needed # # Unset all optional variables first to start from a clean state unset NONUS || true unset FORCENONUSONCD1 || true unset NONFREE || true unset CONTRIB || true unset EXTRANONFREE || true unset LOCAL || true unset LOCALDEBS || true unset SECURED || true unset SECURITY || true unset BOOTDIR || true unset BOOTDISKS || true unset SYMLINK || true unset COPYLINK || true unset MKISOFS || true unset MKISOFS_OPTS || true unset ISOLINUX || true unset EXCLUDE || true unset SRCEXCLUDE|| true unset NORECOMMENDS || true unset NOSUGGESTS|| true unset DOJIGDO || true unset JIGDOCMD || true unset JIGDOTEMPLATEURL || true unset JIGDOFALLBACKURLS || true unset JIGDOINCLUDEURLS || true unset JIGDOSCRIPT || true unset DEFBINSIZE|| true unset DEFSRCSIZE|| true unset FASTSUMS || true unset PUBLISH_URL || true unset PUBLISH_NONUS_URL || true unset PUBLISH_PATH || true unset UDEB_INCLUDE || true unset UDEB_EXCLUDE || true unset BASE_INCLUDE || true unset BASE_EXCLUDE || true unset INSTALLER_CD || true unset DI_CODENAME || true # The debian-cd dir # Where I am (hoping I'm in the debian-cd dir) export BASEDIR=`pwd` # Building woody cd set ... export CODENAME=sarge # By default use Debian installer packages from $CODENAME if [ ! "$DI_CODENAME" ] then export DI_CODENAME=$CODENAME fi # Version number, "2.2 r0", "2.2 r1" etc. export DEBVERSION="testing" # Official or non-official set. # NOTE: THE "OFFICIAL" DESIGNATION IS ONLY ALLOWED FOR IMAGES AVAILABLE # ON THE OFFICIAL DEBIAN CD WEBSITE http://cdimage.debian.org export OFFICIAL="Unofficial" #export OFFICIAL="Official" #export OFFICIAL="Official Beta" # ... for arch export ARCH=i386 # IMPORTANT : The 4 following paths must be on the same partition/device. # If they aren't then you must set COPYLINK below to 1. This # takes a lot of extra room to create the sandbox for the ISO # images, however. Also, if you are using an NFS partition for # some part of this, you must use this option. # Paths to the mirrors export MIRROR=/ftp/debian # Comment the following line if you don't have/want non-US #export NONUS=/ftp/debian-non-US # And this option will make you 2 copies of CD1 - one with all the # non-US packages on it, one with none. Useful if you're likely to # need both. #export FORCENONUSONCD1=1 # Path of the temporary directory export TDIR=/ftp/tmp # Path where the images will be written export OUT=/ftp/debian-cd # Where we keep the temporary apt stuff. # This cannot reside on an NFS mount. export APTTMP=/ftp/tmp/apt # Do I want to have NONFREE merged in the CD set export NONFREE=1 # Do I want to have CONTRIB merged in the CD set export CONTRIB=1 # Do I want to have NONFREE on a separate CD (the last CD of the CD set) # WARNING: Don't use NONFREE and EXTRANONFREE at the same time ! # export EXTRANONFREE=1 # If you have a $MIRROR/dists/$CODENAME/local/binary-$ARCH dir with # local packages that you want to put on the CD set then # uncomment the following line # export LOCAL=1 # If your local packages are not under $MIRROR, but somewhere else, # you can uncomment this line and edit to to point to a directory # containing dists/$CODENAME/local/binary-$ARCH # export LOCALDEBS=/home/joey/debian/va/debian # If you want a -secured tree with a copy of the signed # Release.gpg and files listed by this Release file, then # uncomment this line # export SECURED=1 # Where to find the security patches. This directory should be the # top directory of a security.debian.org mirror. #export SECURITY="$TOPDIR"/debian/debian-security # Sparc only : bootdir (location of cd.b and second.b) # export BOOTDIR=/boot # Symlink farmers should uncomment this line : # export SYMLINK=1 # Use this to force copying the files instead of symlinking or hardlinking # them. This is useful if your destination directories are on a different # part
Re: debian-cd broken?
Quoting Jan Kesten: > I had problems building sarge cd images from my local mirror > yesterday and today. I didn't change anything and used the latest > cvs version of debian-cd. Can you show the CONF.sh file that you're using ? It looks like there's a problem with your EXCLUDE variable ... in the target $(BDIR)/rawlist-exclude the test doesn't fail and the perl command is launched without a parameter when it needs one and so stays blocked waiting on standard input : > if [ -n ]; then \ > perl -npe 's/[EMAIL PROTECTED]@/i386/g' | \ > cpp -nostdinc -nostdinc++ -P -undef -D ARCH=i386 -D ARCH_i386 \ > -U i386 -U i386 -U linux -U unix \ > -DFORCENONUSONCD1=0 \ > -I /mirror2/debian-cd/tasks -I /mirror2/tmp/sarge-i386 - - > >> /mirror2/tmp/sarge-i386/rawlist-exclude; \ > fi > make: *** Deleting file `/mirror2/tmp/sarge-i386/rawlist-exclude' > make: *** [/mirror2/tmp/sarge-i386/rawlist-exclude] Interrupt otavio is responsible for that change, maybe he can sort it out ? :) I bet that we could replace -n with -e and have a better test. Or we should at least add quotes around $(EXCLUDE) in the test itself. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
debian-cd broken?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all!
I had problems building sarge cd images from my local mirror
yesterday and today. I didn't change anything and used the latest
cvs version of debian-cd.
Both
make distclean
make mirror_check
are running normal without any messages. But when I start to build
the lists with
make list COMPLETE=1 TASK=tasks/Debian_sarge
I get the following output and make hangs (I didn't turn my computer
off during the night and after 10 hours now it still didn't finish).
I attached the output, when links are wrapped it may be more
difficult to read.
When I finally press CTRL+C these are the last two lines:
make: *** Deleting file `/mirror2/tmp/sarge-i386/rawlist-exclude'
make: *** [/mirror2/tmp/sarge-i386/rawlist-exclude] Interrupt
Any ideas?
Cheers,
Jan
- --
GPG-KeyID: 82201FC4
Available at my public sks keyserver sks.nerdcamp.net
Please report any problems using sks.nerdcamp.net!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFAocLAvvmCkIIgH8QRAlSnAJ9EaBC9tswBtWM3+/C7QLsL6vnlCQCgkb2B
YfJZE1xXepYjOvpJk4bVIN8=
=z/ct
-END PGP SIGNATURE-
teefix:/mirror2/debian-cd# make list COMPLETE=1 TASK=tasks/Debian_sarge
Apt-get is updating his files ...
/mirror2/debian-cd/tools/apt-selection update
Ign file: sarge/main/debian-installer Release
Reading Package Lists...
/bin/echo -e "mawk\nexim4-daemon-light\nunifont" >>/mirror2/tmp/sarge-i386/rawlist
if [ -x "/usr/sbin/debootstrap" -a _ != _1 ]; then \
/usr/sbin/debootstrap --arch i386 --print-debs sarge \
| tr ' ' '\n' >>/mirror2/tmp/sarge-i386/rawlist; \
fi
perl -npe 's/[EMAIL PROTECTED]@/i386/g' tasks/Debian_sarge | \
cpp -nostdinc -nostdinc++ -P -undef -D ARCH=i386 -D ARCH_i386 \
-U i386 -U i386 -U linux -U unix \
-DFORCENONUSONCD1=0 \
-I /mirror2/debian-cd/tasks -I /mirror2/tmp/sarge-i386 - - >>
/mirror2/tmp/sarge-i386/rawlist
In file included from :12:
/mirror2/debian-cd/tasks/debian-installer:318:17: warning: extra tokens at end of
#ifdef directive
Generating the complete list of packages to be included ...
perl -ne 'chomp; next if /^\s*$/; \
print "$_\n" if not $seen{$_}; $seen{$_}++;' \
/mirror2/tmp/sarge-i386/rawlist \
> /mirror2/tmp/sarge-i386/list
if [ -n ]; then \
perl -npe 's/[EMAIL PROTECTED]@/i386/g' | \
cpp -nostdinc -nostdinc++ -P -undef -D ARCH=i386 -D ARCH_i386 \
-U i386 -U i386 -U linux -U unix \
-DFORCENONUSONCD1=0 \
-I /mirror2/debian-cd/tasks -I /mirror2/tmp/sarge-i386 - - >>
/mirror2/tmp/sarge-i386/rawlist-exclude; \
fi
make: *** Deleting file `/mirror2/tmp/sarge-i386/rawlist-exclude'
make: *** [/mirror2/tmp/sarge-i386/rawlist-exclude] Interrupt
