=== CarlFK1 is now known as CarlFK [01:39] partman-crypto: cjwatson * r673 ubuntu/ (debian/changelog finish.d/crypto_config): [01:39] partman-crypto: Use UUIDs only if available, fixing key types other than passphrase [01:39] partman-crypto: since only LUKS actually has a UUID (LP: #321732). [01:40] partman-crypto: cjwatson * r674 ubuntu/debian/changelog: releasing version 36ubuntu3 [03:36] I'd like to help get the installer working on my old (old, so old) ThinkPad. I've got Ubuntu Jaunty Alpha installed on a different 'pad. I am installing d-i as on the InstallerDevelopment wiki page. What's a good next step? Install development tools? [03:58] Torgoton1: How old is the ThinkPad? [03:58] Torgoton1: And have you tried the alternate installer CD? [03:59] TheMuso: Too old. No CD drive. I can start a net boot install. It's got 36MB RAM, and a 486 CPU. [04:00] Torgoton1: Well I think you're out of luck. I don't think Ubuntu is trying to aim for that old hardware, you may be better off with debian. [04:00] Maybe. There is a page on the wiki that states 32MB is required for a bare minimum install, and CJ said he might put some effort into getting it to work for 9.04. [04:01] I can help some... capture serial console logs and such... just not sure where to dig in. [04:01] Fair enough. [04:02] also not sure how to even try to get new code onto the thing. Wasn't easy. I used floppies (gasp) to copy over the two netboot files. [04:03] * TheMuso nods. [04:28] later [08:51] cjwatson: FYI, d-i built past ixp4xx after your last change; however it fails to build later on according to Michael [08:54] hey cjwatson [08:59] cjwatson: Ok, given the image doesn't work for NCommander and he doesn't have a serial console please disable ixp4xx and sorry for the noise [08:59] (bug #322217) [08:59] Launchpad bug 322217 in debian-installer "ixp4xx image does not boot" [Undecided,New] https://launchpad.net/bugs/322217 [09:00] cjwatson, I also am filling a sync request for a missing package we need in Ubuntu (micro-evtd) [09:04] disable ixp4xx altogether, or just the nslu2 part? (I'd prefer the latter if that makes sense) [09:04] cjwatson, it builds file [09:04] (ixp4xx) [09:04] THe FTBFS is from onion, due to the missing udeb [09:05] why's the bug on debian-installer rather than linux? [09:05] which missing udeb? [09:05] cjwatson, as far as I know, the ixp4xx kernel is known to boot [09:05] and I assume you mean orion [09:05] orion [09:05] yeah [09:05] * NCommander is not having much luck with spelling today and maybe taking a sign to sleep [09:05] ok, just as long as you know I'm not going to do anything with that bug :) [09:05] cjwatson, micro-evtd is the missing package in Ubuntu [09:06] ok [09:07] cjwatson, the sync request got filed, I'm just waiting for the bug # to pop up [09:07] so which bits of the d-i armel build are the useful bits that you guys *actually* want? :-) [09:07] Well, I personally would like the netboot d-i images built so we can make sure d-i on ARM fully works (although I've heard reports it works on QEMU) [09:08] which subarch? [09:08] netboot is a medium not a subarch [09:08] cjwatson: doko and myself have a thecus n2100 which is an IOP [09:08] cjwatson: I think NSLU2 is rather popular hardware, but I don't have any myself [09:08] I have an ixp4xx, and I'm willing to solder on the serial console to figure out what has gone wrong with d-i on it [09:09] why don't we continue building ixp4xx even though it doesn't work for the moment [09:09] if nothing else, it will make it easier for people to debug it [09:09] cjwatson: In general I'd love to keep any Debian port which we can QA [09:09] * NCommander would agree with that being the source of action [09:10] NCommander: you know that micro-evtd is already in the archive? [09:10] Er, it didn't pop up when I searched for it [09:10] it's one version behind, happy to sync that [09:10] micro-evtd | 3.3.3-6+lenny2 | jaunty/universe | source, armel [09:10] Strange [09:11] It should find it (I enabled universe in the sources.list.udeb ...) [09:11] lool: could you give micro-evtd the once-over for main inclusion, perhaps? [09:12] and somebody should file a bug for the same [09:12] cjwatson, if yo have no objection, I'll do the MIR [09:12] none at all, please do [09:13] I've synced +lenny3 [09:15] Thanks cjwatson [09:16] The package is ok for promotion; the packaging could be cleaned up a little but it's good enough [09:17] qcontrol-udeb is also a needed one [09:18] NCommander: It's in sync and it built on armel [09:19] yup, just grabbed the binary and I chucked it into localudebs [09:19] I guess you want main promotion as well? [09:20] Hmm there's an issue of /tmp usage with micro_evtd [09:21] lool, /tmp usage? [09:21] Yeah, it system(strEventScript); with sprintf(strEventScript, "/%s/micro_evtd/EventScript %c %d %ld %s %s %d %c", (CP_SCRIPT == cmd? "etc" : strTmpPath), ... [09:21] strTmpPath is /tmp [09:22] ugh :-/, thats ugly [09:22] It seems it's only for custom commands [09:24] lool, I'm not used to checking for suig binaries, it does some weird permission things in rules, wanted to make sure I wasn't overlooking things [09:24] ^can you double-check for me that isn't the case [09:26] qcontrol-udeb: Depends: input-modules but it is not installable [09:26] ugh :-/ [09:28] perhaps built in on armel [09:28] find out which module it actually wants and find out if it's =y in our kernel [09:29] Oh, that's a udeb? [09:29] qcontrol has an unsigned int / int mismatch [09:29] e [09:29] *er [09:29] kernel udeb? [09:29] It checks an int against 0x80 [09:29] if so, (a) you can temporarily remove the dependency, (b) medium-term, the corresponding kernel-image udeb should Provides: input-modules [09:29] NCommander: the kernel udebs are conventionally foo-modules-ABI Provides: foo-modules [09:29] ah [09:30] if something is built into the kernel, then the correct behaviour is to have kernel-image-ABI Provides: foo-modules [09:30] the kernel guys may not be doing this accurately though [09:31] Looking at the kernel build, yeah, we're not building input modules [09:31] input-modules conventionally contains several different things, so check qcontrol to find out which individual module it cares about [09:31] (as a udeb) [09:31] right, but we may well be building in the actual drivers it wants [09:34] I'll check as soon as I finish writing up this MIR [09:44] cjwatson, here's my inital draft of the micro-evtd MIR: https://wiki.ubuntu.com/MainInclusionReportMicroEvtd#preview [09:45] (any hints on how to turn off the rampant italtics would be appreciated) [09:48] (well, I would fix it, but you have the page open) [10:32] NCommander: You were missing a ' after UI standards [10:32] I fixed it [10:32] I filed a bug with a "patch" for the qcontrol buffer handling trivia === davmor2 is now known as davmor2-away [11:06] I filed a bug about the micro-evtd security issues, but I'm not too hot on its promotion :6/ [11:10] Ok, my ISP offically hates me [11:10] cjwatson, I missed your comments (if any) on my MIR draft [11:11] I didn't make any [11:11] oh ... [11:12] http://irclogs.ubuntu.com/2009/01/28/%23ubuntu-installer.txt you only missed that I filed a bug about the micro-evtd security issue [11:12] Thanks lool [11:13] lool, I'll amend the MIR, do you see any other issues with it? (I always like to get a second person to look at these thing) [11:14] NCommander: You know I'll have to comment on the MIR bug anyway :-) [11:15] * NCommander falls over [11:15] NCommander: But I wouldn't like promoting the package with the number of problems in the source [11:15] Hrm [11:15] We could probably drop the need for this package [11:15] e.g. no read()/write() return code handling, syslog(LOG_INFO, message) instead of "%s", message etc. [11:15] But that would cause the user to have no visual feedback that d-i is ready for an openssh connection. [11:16] or we could fix the source [11:17] Which to make sure we don't accident break anything requires someone with said hardware to test it. [11:17] Fixing the tmpdir usage is not trivial; also it should be tested on real hardware in the end [11:17] It's using the same vars for plenty of things, and I don't understand all the possible code pathes [11:17] The read()/write()/syslog() issues are indeed trivial to solve [11:18] If someone has one of these beasts, I have no issue working to fix it, but I'm not a fan of randomly making code changes :-) [11:19] cjwatson: I understand that we need to fix main/universe mismatches before the release, but is it ok to leave it in universe for now in the hope that upstream can help fixing the issue? [11:20] (Or in the hope we'll have time + hardware to fix it ourselves, or just dropping this udeb if we don't) [11:25] well, we can't build d-i with it until it's in main [11:25] we can drop it for the time being? [11:26] cjwatson: Please do; I don't see micro-eventd fixed in a very short term [11:29] I'll seed both micro-evtd-udeb and qcontrol-udeb so that they do show up as mismatches [11:29] I'm ok to promote qcontrol [11:29] The only code issue I found doesn't affect arm/armel [11:30] cjwatson: thanks [11:30] debian-installer: cjwatson * r1026 ubuntu/ (2 files in 2 dirs): [11:30] debian-installer: Build orion5x images without micro-evtd for now, as it needs work before [11:30] debian-installer: inclusion in main. [11:31] any MIR or anything for qcontrol? [11:31] NCommander: ^^^? [11:31] Not yet, I still need to figure out what qcontrol needs [11:31] (not going to write an MIR until I can actually install the bugger :-)) [11:32] I'm ok with just a bug for the qcontrol MIR, it's relatively trivial so I wont insist on a wiki page [11:32] NCommander: It only bdeps on liblua5.1-0-dev which is in main [11:33] And it depends on liblua5.1-0 which is obviously in main as well [11:33] udeb depends on libc6-udeb and input-modules [11:33] * NCommander thought MIRs were always required expect in cases where one binary of a source package in main already needed a bump ... [11:34] ^wiki pages [11:34] cjwatson, with orion5x disabled, I should be able to do a full d-i build [11:37] if a member of the ubuntu-mir team says otherwise then a bug is fine [11:37] they have discretion [11:37] WOrks for me [11:43] lool, https://bugs.edge.launchpad.net/ubuntu/+source/qcontrol/+bug/322261 [11:43] Launchpad bug 322261 in qcontrol "Main Inclusion for qcontrol" [Undecided,New] [11:44] localechooser: cjwatson * r143 ubuntu/ (debian/changelog localechooser): merge from Debian 2.09 (the hard way, since that was released from the lenny branch) [11:44] NCommander: It's "Frans" not Francs [11:45] Ok, thats it, no more bugs for me tonight :-P [11:45] (fixed) [11:46] Yeah, I did fix it [11:46] oh [11:46] I think we both edited it at the same time ... [11:47] localechooser: cjwatson * r144 ubuntu/debian/changelog: releasing version 2.09ubuntu1 [11:54] cjwatson, I'll investigate the input-modules mystery, and then get back to you on that tommorow (I need to get some sleep tonight) [11:55] qcontrol promoted [11:56] I haven't promoted the qcontrol binary, only qcontrol-udeb; seed the qcontrol binary if you want it and an archive admin will do it at some point [11:57] Thanks [12:59] evand, cjwatson: are either of you running a jaunty test box? [13:01] how about my laptop? [13:02] cjwatson: do you do daily updates on it? [13:04] I have an issue currently but I'm not sure if it is my box or ubuntu. After a major update you get the restart icon appear in the panel. When clicking on it it seems to log out rather than restart [13:06] not daily [13:07] I think you would get better answers on #ubuntu-bugs or #ubuntu+1 or #ubuntu-desktop or something ... [13:07] I'm not about to restart my laptop right now to find out :) [13:28] davmor2-away: Is that happening all the time? I have seen it sometimes. [13:46] charlie-tca: not sure I've only done 2 updates and it's happen once out of those 2 times [13:47] I do updates daily; working on this system with jaunty installed. It does happen, just not every update. [13:47] Also, yesterday, updates came in about 5 times through update manager. === evand_ is now known as evand === davmor2-away is now known as davmor2 [14:15] cjwatson: I pushed a new qcontrol dropping the dep and filed bug #322311; do you know whether the Provides have the same meaning on all flavours? [14:15] Launchpad bug 322311 in qcontrol "orion5x armel flavour should provide input-modules" [Undecided,New] https://launchpad.net/bugs/322311 [14:15] cjwatson: e.g. does input-modules imply the same modules whatever the flavour? [14:15] not precisely but the same general kind of thing [14:15] but qcontrol is almost certainly looking for particular modules [14:15] It is [14:15] ok, gpio_keys [14:16] it doesn't matter if the exact set of modules varies a bit [14:16] But because this module isn't qnap specific, I can't tell whether all flavours should get the module and provide [14:16] you could compare with Debian's udebs [14:17] That might or might not be conclusive, I'll check thanks [14:28] So it's not the same modules in all the input-modules, and in fact I don't know why I was asking as I know realize there's one input modules per flavour... [14:34] cjwatson: What rule did you use to create the debian/d-i/exclude-modules.armel*? [14:34] trial and error [14:34] Hmm [14:34] I think it was modules that were clearly built into the kernel [14:35] and where it didn't make sense to have a reduced file in modules-armel*/ [14:35] it's a while, though [14:36] Ok, I admit I'm starting to get a bit lost in the amount of things I need to touch and in which order; I had asked to start our armel kernel flavours' configs from Debian, but they obviously don't match or provide the same modules; in particular versatile is very broken in this respect [14:37] I know amitk was working on cleaning up the config after the mess of the last changes, and I'm not confident to fix it myself [15:44] cjwatson: https://help.ubuntu.com/7.04/installation-guide/i386/automatic-install.html is this the most up-to-date docs for kickstart? [15:47] sorry wrong link same but 8.10 not 7.04 [15:53] <_ruben> yes [15:54] cool ta [16:03] yeah, it is [16:33] cjwatson: was that note you posted on the bug for the x64 version? [16:34] it was not architecture-specific [16:34] I tried to tell you it on IRC but you had left [16:40] installing intreprid server under kvm, when you get to the "Installing Additional Components" screen, it starts redrawing the full screen repeatedly. This is very slow in KVM and brings the installer stops making progress [16:40] this didn't happen in hardy though [16:40] has something changed about how that screen is redrawn in interpid? [16:41] not to my knowledge [16:41] if it has, it'll be at a lower level such as newt or slang that I don't typically deal with or know a whole lot about [16:41] or possibly the kernel [16:41] it's as if there's a clearscreen happening every second and then a full redraw [16:42] it only happens with that screen (well, that's as far as I've gotten in the installer) [16:42] that almost sounds like you're running out of memory and the installer is crashing and being restarted [16:43] look at /var/log/syslog (tty4) to confirm [16:43] if you change ttys and it respawns on the current tty, that confirms that the whole installer is crashing [16:43] okay, i'll check that [16:48] ugh, of course i now can't reproduce it [16:48] maybe it's a kvm problem [16:48] i'll dig deeper, thanks [16:53] aliguori: did you forget to pass -m to kvm, perhaps? common mistake [16:54] it defaults to 128MB which is inconveniently small [16:54] cjwatson, 128mb is too small for a server install? [16:54] really? [16:54] cjwatson, no, i never pass -m and it's not been a problem in the past [16:55] probably shouldn't be [16:55] more of a problem for desktop [16:57] when i can reproduce it again, i'll see if it's an OOM. if it is, it's either that 128 is not enough or something is leaking memory [16:57] but it could be a kvm issue. i'm running a second vm now and i can't reproduce it, so i'm suspicious [16:58] ubiquity: evand * r2989 ubiquity/ (d-i/manifest debian/changelog): [16:58] ubiquity: Automatic update of included source packages: grub-installer [16:58] ubiquity: 1.36ubuntu1, localechooser 2.09ubuntu1, user-setup 1.23ubuntu8. [17:00] ubiquity: evand * r2990 ubiquity/debian/po/ (79 files): debconf-updatepo [17:25] cjwatson: so that should fix the x64 problem i was having or? the x86 version works flawlessly without that flag [17:26] DogWater: it does *now* [17:26] DogWater: the kernel from -proposed was only moved into -updates yesterday; once that happened the rules changed :-) [17:26] well that is certainly ominous ;-) [17:27] (a) retry the amd64 installation, if it works be happy (b) if it doesn't work use apt-setup/proposed=true [17:28] if thats all it takes to make me happy what im I paying my therapist for [17:30] cjwatson: still indicates that no kernel modules were found.. etc [17:30] cjwatson: were you actually able to install using that initrd/kernel? [17:32] have you tried apt-setup/proposed=true? [17:32] (if not why not?) [17:32] also, does your mirror contain -proposed? [17:32] yes, i put it in the append initrd line, does it go in the kernel line? in pxelinux [17:32] it goes in the append line [17:33] ah, i didn't yet add intrepid-proposed to the mirror. i'll try installing off of archive.ubuntu.com [17:33] since you are using your own mirror I am guessing that the problem is that it is incomplete [17:33] you can add intrepid-proposed to -d (and I think it is likely that you are also missing intrepid-updates, perhaps more importantly) [17:34] no, i have intrepid updates [17:34] its been downloading source for about 24hr [17:34] its almost done [17:35] mm, yes, almost done is usually not enough to run an installation off ;-) [17:35] debmirror doesn't put the index files in place until it's actually finished [17:35] well, the install works fine without source, though [17:35] it complains but it appears to work [17:35] it doesn't care about source, but if you are using the initrd from -proposed/-updates then you need the binary packages from -proposed/-updates to go with it, or it will break [17:36] ah, yeah i'll add proposed then [17:36] by the way, do the earlier versions such as 8.04 and 7.10 kickstarts work or are they broken as 8.10 was previously? [17:36] they do not contain the bug that broke busybox getopt [17:37] that one was 8.10 only, due to a glitch in a merge from Debian [17:37] well thats good news at least hopefully it will be fairly easy to automate those two [17:39] cjwatson: by having that proposed flag in the pxelinux am i at risk of running some bleeding edge stuff which could be unstable, etc? [17:40] yes [17:40] so try it without first [17:40] once you fix your mirror [17:41] cjwatson: well it couldn't be the mirror, because that line is required when installing with archive.ubuntu.com/ubuntu [17:41] it WAS required before we put the -11 kernel in -updates [17:41] it should not be required now [17:41] oh [17:41] oic u812 [17:41] hrm [17:42] so essentially the reason the x86 version works fine is because for whatever reason that update spread faster? [17:42] or you tested the i386 build after the amd64 build ... [17:43] Hm? No, I only tried the x64 version after getting i386 to work [17:43] x64 is almost an afterthought around here but i need it to work [17:43] perhaps your mirror handles amd64 differently, I don't know. Retest amd64 now and come back to me if it's still broken on archive.ubuntu.com/ubuntu [17:43] (BTW it isn't called "x64") [17:44] (at least not in this part of the world ...) [17:44] sorry i deal with something like 40 different operating systems if you count distributions [17:45] ok [17:45] centos calls it x86-64 you call it amd64, windows calls it x64 [17:45] etc [17:46] I don't really see how the amd64 kernel could somehow propagate any faster; our mirroring methods are rather careful to keep things in sync [17:46] I would need to see logs of the failed installation [17:47] I'm not complaining it just confuses me being who I am to see the i386 version work and the amd64 version not work given everything else being the same [17:49] my mind expects parity [17:51] so does mine, and they *should* be at parity here [17:51] but I don't want to end up trying to investigate a bug in your mirror, and so I'd prefer confirmation that it's still broken on archive.ubuntu.com [17:52] we don't generally release updates out of step across architectures [17:52] if i add the line to the append = in pxelinux and use archive.ubuntu.com it works, if i just use archive.ubuntu.com it doesnt. I don't need that line on i386 no matter what mirror i use. [17:52] thats what im trying to convey [17:53] I would like to see logs of the failure when you do not add apt-setup/proposed=true and use archive.ubuntu.comm [17:54] I cannot easily do an amd64 test at the moment [17:56] maybe i'm totally wrong actually let me test some more ;-) [17:57] maybe my mirror doesnt work, i dunno ;-) [17:57] i have i386,amd64 in the architectures [18:26] cjwatson: damn i hate it when you're right when i switched my debmirror to archives the first thing it downloaded was headers for the new kernel [18:27] and modules [18:27] heh [18:27] good to hear it's sorted [18:27] it will be in 24hr when its done downloading, lol [18:32] anyone knows where is indian support [18:33] i mean channel [18:35] no idea, sorry [18:35] did you try for example googling for "ubuntu indian irc"? [20:26] cjwatson: anecdotally, do you have to wait for an entire run of debmirror to complete before the new stuff it downloaded will be 'available'? [20:41] ubiquity: evand * r2991 ubiquity/debian/changelog: releasing version 1.11.5 [21:54] DogWater: yes [21:55] DogWater: as I said above, it only moves the index files into place at the end, and until that happens nothing will know that the new files are available [23:37] debian-installer: cjwatson * r1027 ubuntu/debian/changelog: releasing version 20081029ubuntu11 [23:45] installation-guide: cjwatson * r443 ubuntu/ (debian/changelog en/appendix/preseed.xml): Document pkgsel/install-recommends.