[02:06] <CIA-52> apt-setup: cjwatson * r144 apt-setup/ (debian/changelog generators/50mirror.ubuntu):
[02:06] <CIA-52> apt-setup: Fix description of universe in generated sources.list: packages there
[02:06] <CIA-52> apt-setup: are expected to be under a free licence.
[02:16] <evand> cjwatson: Is it generally acceptable to use purge-old-images to get rid of bad DVD builds, or should I generally just let than run on its own?
[02:17] <evand> The last DVD build I ran was a bust, and I'm planning on starting another soon as I believe I've resolved the issue.
[02:19] <evand> hrm, I probably should have asked that in -release.  Moving the conversation there
[02:27] <cjwatson> just rm -rf them if you want
[02:27] <evand> ah, ok
[02:27] <StevenK> And sync-mirrors if you want them to actually disappear
[02:29] <evand> thanks
[03:07] <CIA-52> ubiquity: evand * r2883 ubiquity/ (configure configure.ac): Bump to 1.10.5
[03:11] <CIA-52> ubiquity: evand * r2884 ubiquity/debian/ (changelog rules ubiquity.install-any):
[03:11] <CIA-52> ubiquity: Filter out the net subsystem when calling update-dev to prevent the
[03:11] <CIA-52> ubiquity: network connection from resetting (LP: #276383).
[04:41] <yannickm> Hi, anyone on ?
[04:45] <yannickm> I have a weird problem. I've had to recreate the Packages for the udebs in order to customize an installer CD (so by running
[04:45] <yannickm> apt-ftparchive -c $APTCONF generate /opt/apt-ftparchive/apt-ftparchive-udeb.conf). The problem is that the Packages file that is generated comes in a different order than the one on the CD, and that's strangely breaking the installer by making it try to use PPPOE when it shouldn't (!?). I wrote a small script that re-orders the file in the same order than the original one, and that fixes the problem. Any idea what's going on ?
[04:45] <yannickm>  
[04:45] <yannickm>  
[05:01] <evand> cjwatson: I've provided a new patch for bug 276656 that I think addresses your and superm1's concerns.  Can you give it a look over?
[05:18] <yannickm> hi cjwatson are you still here ?
[06:34] <TheMuso> cjwatson: For asking the user about dmraid arrays to work, changes have to be amde in hw-detect and partman-base. I dare say the question could be better phrased, but this is what I came up with at the time.
[06:34] <TheMuso> cjwatson: http://pastebin.ubuntu.com/55523/ <- hw-detect
[06:35] <TheMuso> cjwatson: http://pastebin.ubuntu.com/55524/ <- partman-base
[09:24] <cjwatson> TheMuso: I think that's fine, although your partman-base diff only has the changelog change
[09:25] <cjwatson> TheMuso: perhaps 'mkdir -p /var/lib/disk-detect; touch /var/lib/disk-detect/activate_dmraid' rather than touching /tmp/activate_dmraid, to future-proof for ubiquity
[09:30] <TheMuso> cjwatson: heh right, I forgot to include the parman-base change in the diff. :) It was basically checking for the existance of that file before skipping the physical drives as part of the array.
[09:57] <cjwatson> yeah
[09:58] <cjwatson> TheMuso: what's responsible for calling 'apt-install dmraid'?
[10:30] <persia> I'm seeing some oddities in ${partman-depends} and ${bootloader-depends} in ubiquity 1.10.4.  At least none of i386, amd64, or lpia seem to depend on ntfsprogs, and lpia doesn't seem to depend on grub.  I'm not going to look at it for a few hours, in case someone else is interested.
[10:35] <cjwatson> persia: I'm not sure about lpia/grub but spot the typo for ntfsprogs: http://paste.ubuntu.com/55553/
[10:35] <xivulon> does 278873 ring any bell? the chap cannot boot when usplash is on
[10:38] <persia> cjwatson, Cool.  That at least makes it only me again :)  Nice catch.
[10:48]  * StevenK can't spot the typo
[10:48] <StevenK> Ah, got it
[10:48] <StevenK> Nicely subtly
[10:48] <StevenK> Sigh. Subtle
[11:02] <CIA-52> ubiquity: cjwatson * r2885 ubiquity/debian/ (changelog rules): Fix typo in architecture detection for ntfsprogs dependency.
[11:14] <cjwatson> persia: I'm confused about the other one, since amd64 and i386 are working fine. Does 'dpkg-architecture -qDEB_HOST_ARCH_CPU' not output lpia on lpia or something?
[11:15] <cjwatson> <cjwatson@sarantium ~>$ sudo chroot /chroot/intrepid-lpia
[11:15] <cjwatson> [sudo] password for cjwatson:
[11:15] <cjwatson> root@sarantium:/# dpkg-architecture -qDEB_HOST_ARCH_CPU
[11:15] <cjwatson> i686
[11:15] <cjwatson> oww, surely that's a bug
[11:15] <cjwatson> (old chroot, though)
[11:15] <persia> Hrm.  Interesting.  That's probably a bug somewhere else though.
[11:15] <cjwatson> in dpkg :-/
[11:15] <persia> No, I get the same in my chroot.
[11:16]  * persia tries on hardware
[11:19] <cjwatson> looks like lpia is just weird and needs to be handled separate
[11:19] <cjwatson> ly
[11:19] <cjwatson> I'll just check DEB_HOST_ARCH for that
[11:20] <cjwatson> I don't think changing the CPU name is a good idea
[11:20] <persia> Not a good idea at all, or not a good idea for intrepid?
[11:21] <cjwatson> I'm not sure ...
[11:21] <TheMuso> cjwatson: Do you mean when setting things up for partitioning, or once partitioning is done and the installation is under way?
[11:21] <cjwatson> dpkg's architecture detection always gives me a headache, and we can definitely assume that there's lots of stuff relying on it
[11:22] <cjwatson> TheMuso: it doesn't matter when it's called; apt-install will queue the package until it's possible to install it in /target
[11:22] <cjwatson> TheMuso: but it surely has to be called somewhere or else /target won't get dmraid
[11:22] <persia> Ah, good point, and it being wrong this long probably means the entire archive would need a rebuild to fix it.
[11:22] <TheMuso> cjwatson: RIght, I am not sure, since that was already working when I did the extra support work.
[11:22] <TheMuso> So I didn't see a need to chase that up.
[11:22] <cjwatson> TheMuso: see, I thought partman-dmraid did it ;-)
[11:23] <cjwatson> although apparently not
[11:23] <TheMuso> No, it wasn't.
[11:25] <CIA-52> ubiquity: cjwatson * r2886 ubiquity/debian/ (changelog rules): Work around lpia having DEB_HOST_ARCH_CPU=i686 (!).
[11:27] <TheMuso> cjwatson: I'll have the dmraid activation question ready for upload tomorrow morning. I assume ubuntu-release is responsible for UI freeze exceptions?
[11:31] <cjwatson> yeah
[11:31] <cjwatson> thanks
[11:35] <persia> cjwatson, I even get i686 on hardware.  Thanks for thinking of that, and fixing it.
[13:29] <yannickm1>  I have a weird problem. I've had to recreate the Packages for the udebs  in order to customize an installer CD (so by running apt-ftparchive -c $APTCONF generate  /opt/apt-ftparchive/apt-ftparchive-udeb.conf). The problem is that the  Packages file that is generated comes in a different order than the one  on the CD, and that's strangely breaking the installer by making it try  to use PPPOE when it shouldn't (!?). I wrote a
[13:32] <yannickm1> i'm using http://archive.ubuntu.com/ubuntu/indices/override.hardy.main.debian-installer btw
[14:53] <CIA-52> apt-setup: cjwatson * r145 apt-setup/debian/ (apt-setup-udeb.postinst changelog):
[14:53] <CIA-52> apt-setup: Run 'apt-get update', without downloading package lists or cleaning up
[14:53] <CIA-52> apt-setup: old files, after moving the sources.list generated during base system
[14:53] <CIA-52> apt-setup: installation back into place (LP: #267884).
[14:54] <CIA-52> pkgsel: cjwatson * r120 ubuntu/debian/ (changelog postinst):
[14:54] <CIA-52> pkgsel: Don't download package lists again after moving the final sources.list
[14:54] <CIA-52> pkgsel: into place (LP: #267884).
[14:56] <CIA-52> apt-setup: cjwatson * r146 apt-setup/debian/changelog: releasing version 1:0.37ubuntu5
[14:57] <CIA-52> pkgsel: cjwatson * r121 ubuntu/debian/changelog: releasing version 0.20ubuntu8
[15:24]  * evand sighs at the archive still being broken
[15:28] <evand> oh, it looks like the DVD build just got caught between compiz uploads.  I retract my former statement.
[16:04] <cjwatson> evand: could you act on bug 234185, please? it should just be a matter of adding a boot parameter for alternate/server CDs
[16:09] <evand> will do
[16:15] <cjwatson> thanks
[16:41] <kirkland> cjwatson: hi, i'm trying to digest the conversation between you and soren in bug #257739
[16:42] <kirkland> cjwatson: and moreover to determine how long ago, or recently that was
[16:42] <cjwatson> 25th Sep
[16:42] <kirkland> cjwatson: okay, and has any of the module juggling been enacted?
[16:43] <cjwatson> not to my knowledge; I asked Soren to take it up with the kernel team
[16:43] <kirkland> cjwatson: rick has asked me to take over that bug and fix it immediately, he's making it release critical
[16:51] <kirkland> cjwatson: for posterity, where are you checking the location of these modules?
[16:51] <cjwatson> dpkg -c /mirror/ubuntu/pool/main/l/linux/foo.udeb
[16:51] <kirkland> cjwatson: oh
[16:51] <kirkland> cjwatson: okay, thanks.
[16:51] <cjwatson> local mirror++
[20:31] <evand> Should the UUIDs go in the groot option in menu.lst, or should they go into their own guuid option that overrides the groot if set?
[20:31] <evand> I'm leaning towards the latter, but suggestions welcome.
[20:32] <evand> (this is for setting the GRUB root device by UUID rather than GRUB device name)
[20:32] <cjwatson> what's the benefit to them being separate?
[20:34] <evand> None, I just have to take special care to not write uuid /dev/sda1 it's set as such, but that's obviously easy.
[20:34] <evand> Well none that I can think of
[20:35] <cjwatson> oh, did cking introduce a new command for it rather than have root able to handle UUIDs?
[20:35] <cjwatson> I don't much mind either way, just try to keep the upgrade logic simple at this point
[20:40] <evand> indeed, he used uuid
[20:40] <evand> noted though
[21:09] <evand> cjwatson: I'm assuming then that you mean it should try to upgrade grub device names to UUIDs, where possible?
[21:09] <evand> (the simple case of writing UUIDs the first time out is working, by the way)
[21:15] <cjwatson> hmm, I'm not sure about that much
[21:15] <cjwatson> at least not this late in the intrepid game; that's risky
[21:16] <cjwatson> my comment was much vaguer than that, I just meant making sure that all that logic in update-grub to fish values out of menu.lst and write them back is simple enough to be easily verifiable
[21:16] <cjwatson> or at least that the diff to it is simple
[21:21] <kirkland> cjwatson: curious behavior I'm seeing ...
[21:24] <kirkland> cjwatson: / on RAID1, the installer correctly prompts for BOOT_DEGRADED
[21:25] <kirkland> cjwatson: but if /boot is on RAID1, the question isn't presented
[21:25] <kirkland> cjwatson: IIUC, the question is presented by the installation of the mdadm udeb, right?
[21:26] <evand> cjwatson: noted
[21:28] <cjwatson> kirkland: that's what I thought
[21:28] <cjwatson> but it's your code :)
[21:28] <kirkland> cjwatson: yeah, this is bothering me :-)
[21:28] <cjwatson> is mdadm getting installed in /target?
[21:28] <kirkland> cjwatson: yeah, absolutely
[21:28] <kirkland> cjwatson: and it operates correctly, post install, etc.
[21:28] <cjwatson> oh, no, it's not presented by installing mdadm
[21:28] <cjwatson> that only asks at priority medium
[21:29] <kirkland> cjwatson: right, there was some trick we used to get it to be presented post partman-base
[21:29] <cjwatson> yeah, I've completely forgotten where you put it
[21:29] <kirkland> cjwatson: :-)  me too, let me dig....
[21:30] <kirkland> cjwatson: i thought it was in the mdadm udeb
[21:30] <cjwatson> oh yes, mdadm ships a check.d script
[21:30] <kirkland> cjwatson: aha!
[21:30] <kirkland> cjwatson: faulty logic in there
[21:30] <cjwatson> kirkland: are both / and /boot on RAID1?
[21:30] <kirkland>                                 if [ "$mp" = "/" ] || [ "$mp" = "/boot" ]; then
[21:31] <cjwatson> that seems perfectly reasonable
[21:31] <kirkland> cjwatson: yeah...
[21:31] <kirkland> cjwatson: oh
[21:31] <cjwatson> you need:
[21:31] <cjwatson> -done
[21:31] <cjwatson> +done | head -n1
[21:31] <kirkland> cjwatson: i thin ki need to break
[21:31] <cjwatson> or you could break
[21:31] <kirkland> cjwatson: yup, that's it
[21:31] <kirkland> cjwatson: patch forthcoming ;-)
[21:32] <cjwatson> stick it on pastebin, I'll apply it forthwith
[21:32] <kirkland> you want the one liner, or a whole debdiff in pastebin?
[21:32] <cjwatson> one-liner is fine
[21:33] <cjwatson> and a suggested changelog message since I'm tired
[21:33] <kirkland> no prob
[21:35] <kirkland> cjwatson: http://pastebin.com/f3b0691e1
[21:36] <cjwatson> kirkland: uploaded, thanks
[21:37] <kirkland> cjwatson: hey, thank you for the sanity check ;-)
[21:38] <kirkland> cjwatson: the request for getting all, or some, of the RAID fixes ported back to hardy are starting to mount
[21:38] <kirkland> cjwatson: i was going to wait until Intrepid releases
[21:38] <kirkland> cjwatson: and perhaps put together a list of what I think would need to be backported, see how important it is to rick/nick
[21:38] <kirkland> cjwatson: and get your take on it, of course
[21:39] <kirkland> cjwatson: i think we could do a couple of fairly straightforward fixes, without getting too deep into the installer
[21:39] <kirkland> cjwatson: fix it for running systems only
[21:40] <cjwatson> ok, happy to think about it after 30 Oct :-)
[21:40] <cjwatson> we should do a bit of a push for 8.04.2 anyway
[21:40] <kirkland> cjwatson: sounds perfectly reasonable
[21:40] <kirkland> cjwatson: thanks for considering