[00:20] ev: what are the known reasons that ubiquity might fail to offer to install side-by-side on a system with Windows 7, using Windows 7 loader, that has 45GB free? [02:10] stgraber, lamont: edubuntu builds still failing with the same error, what's outstanding here? [09:28] slangasek: what does ntfsresize --info say? === doko__ is now known as doko [14:49] slangasek, pitti: any news for the feature freeze exception for computer-janitors dbus branch? bug #541990 [14:49] Launchpad bug 541990 in computer-janitor "[FFe] Upgrade Computer Janitor to 2.0 (dbus edition)" [Undecided,New] https://launchpad.net/bugs/541990 [15:26] mvo: hm, this seems to be a "damned if you do, damned if you don't" kind of thing [15:27] c-j was pretty brittle in the past and caused lots of grief; I'm really nervous with having a complete rewrite at this point.. [15:28] That could also be an argument for the rewrite. [15:29] pitti: i do think it's much more stable, and i already have another use case for the dbus backend :) [15:29] ScottK: except that we know that the current version at least by and large works and doesn't wreak havoc [15:30] pitti: yeah, its tricky, however I think the benefits are worth the risk, the current threading issues are really hard to fix and dbus makes it all go away nicely [15:31] pitti: btw, most of the core logic is essentially unchanged. all the plugings, cruft model, cleanup actions have just been moved into a dbus service. not saying there aren't bugs of course, but that stuff hasn't been really rewritten (cleaned up, refactored, tested, yes :) [15:32] but i understand the concern, being here at b1 [16:00] ev: dunno - will have to check next time I'm in getting a haircut [16:00] :-) [16:01] * ev raises an eyebrow [16:01] clearly I missed some context :) [16:01] my barber was interested in trying it, so I gave him a CD, and it won't auto-resize his Windows 7 :( [16:03] if I can ever get this damn machine to my right working, I'll test it [16:03] I have too many bugs to be able to spend time on hardware maint [16:09] it doesn't fail /generally/, only on his machine [16:32] besides, my pilots licence quite clearly states STAY CLEAR OF CLOUD [16:32] slangasek: sigh. let me go figure it out. do you need terranova anytime soonish? (next hour or 2) [16:33] lamont: not urgently [16:33] Keybuk: [16:34] Keybuk: clearly you need to go for instrument rating [16:34] for the privilege of flying blind in the cloud? [16:35] slangasek: yeah, you need an IR to be legally allowed to enter cloud (or in the UK, even fly above it) [16:35] yes, I know [16:35] I was just stretching out the word game :) [17:42] slangasek, kees: do either of you know for certain if derivative distributions (specifically, Xubuntu) can use the LTS designation? [17:42] That is, do we cover everything they ship with security updates for 5 years? [17:43] afaik, they have not in the past [17:43] eg, kubuntu in hardy was not LTS [17:43] 3 for desktops, I think. 5 for servers [17:43] Canonical already doesn't do security updates for Xubuntu [17:43] but to be clear, Kubuntu definitely is this time, right? [17:44] ev: yes. [17:44] okay [17:44] I thought Xubuntu was all in universe these days? [17:44] maybe I am misremembering... [17:44] jdstrand: That's why I said Canonical didn't do security updates for it. [17:44] ah indeed, xfce4-panel at least is [17:44] okay [17:45] ev: To be even more specific, Kubuntu (desktop) is LTS, Kubuntu Netbook Remix is not. [17:45] so it's not an LTS then [17:45] * jdstrand thanks ScottK for helping him remember, before he thought to wonder if he forgot [17:45] ScottK: ah, thanks for that clarification, I hadn't thought to consider the netbook editions [17:45] ev: modulo UNE not actually being an LTS: https://wiki.ubuntu.com/LucidLynx/ReleaseManifest [17:45] slangasek: ah, I forgot about that page [17:45] thanks a bunch! [17:46] as did I [17:46] slangasek: I replied to bug 546933, and I'm mildly in favor, but would like to get more opinions on that one [17:46] Launchpad bug 546933 in xorg-server "FFE: xorg.conf.d/inputclass backport" [Wishlist,New] https://launchpad.net/bugs/546933 [17:47] slangasek: One thing to consider for LTS/non-LTS is new ISOs for point releases. I think it'd be very confusing for Kubuntu/KNR or Ubuntu/UNE to have different package versions in their current ISO. I think it would make sense to respin those at least for .1. [17:48] ScottK: confusing perhaps, but we already don't have a policy of respinning all ISOs for the point releases; 8.04.1 DVD, for instance, was only respun because of the ssh security issue [17:48] pitti: will look at it this morning [17:48] True. [17:49] You just end up in the odd position of after 3 months the easiest way (if you have poor bandwidth) to install KNR would be to download Kubuntu 10.04.1 and then switch it. [17:50] hum [17:50] it would be nice if the SRU delta were not so great as to make that true [17:51] * kees still wishes ReleaseManifest had seeds listed [17:51] it's something to think about, anyway; though the practical limiting factor is usually our ability to validate the ISOs for point releases [17:51] kees: weren't we waiting for you to tell us what the seeds were? [17:56] slangasek: me? no, that's up to what defines the release [17:56] ok, then I guess I need to check with mvo/barry on this [17:57] slangasek: i.e. "Ubuntu Server" is server-ship. so when Jos says "this is 5 year", mvo's tool marks that seed [17:57] but right now, we have to guess at the seed based on the product/image in the ReleaseManifest [17:57] who does? [17:58] is it security team guessing, or mvo, or? [17:58] I'm saying "one" guesses. for lucid, we (security and mvo) understand 5 year support to be server-support + server-ship. [17:59] then that's what I'm going to write there [17:59] heh [18:00] I find ReleaseManifest confusing because the "Maint commit" column does not map to anything direct. (i.e. no mention of main vs universe, seeds, etc) [18:00] kees: my understanding was that you and mvo were in the process of *defining* that mapping, since it was done slipshod previously [18:04] ev: btw, "is it an LTS" is a subtly different question from "is it supported for 3 years", because LTS is a product definition which might or might not be applied to Xubuntu even if the community decided to provide 3y of security support [18:04] slangasek: that strikes me as being very confusing to end users [18:04] if that's the case, what does LTS convey [18:05] it conveys that Canonical is standing behind its status as a long-term-supported product [18:05] which would not *automatically* the case for Xubuntu with a community security committment [18:05] slangasek: mostly it was the mechanisms, and adjusting seeds to match expectations. it's always been defined as "server-supported" and "server-ship". we just tweak those contents and add things to a blacklist in rarer cases === seb128_ is now known as seb128 [18:07] slangasek: so really it's now "supported-server" + "server-ship" - explicit blacklist [18:09] kees: ok, where is the list of mappings that mvo's tool uses? [18:11] slangasek: afaiu, it's done somewhere in launchpad via cron.germinate and maintenance-check.py [18:11] slangasek: the blacklist is lp:~ubuntu-core-dev/ubuntu-seeds/platform.lucid/ SUPPORTED_HINTS [18:12] slangasek: right now, it is pending a change to add server-ship which was missed in the first version. [18:12] slangasek: at which point the commented out bits in SUPPORTED_HINTS will be added, and then I'll re-check the lists to see what's creeped in since the sprint. [18:17] slangasek, lamont: Any clue on what's happening with Edubuntu ? [18:18] I'm waiting for lamont's analysis [18:18] Could not create destination file: No such file or directory [18:18] that's new ... [18:18] might be something broken in my mksquashfs cmdline though it's based on what ltsp-build-client calls ... [18:19] * stgraber make a note to add some debug next time he proposes a patch for that script ... would be useful to know what commands are started [18:24] doh, I guess I found the problem ... [18:25] seems like mksquashfs doesn't like creating an image in a non-existing directory [18:25] http://pastebin.com/anpmac7s [18:25] lamont: ^ [18:42] stgraber: heh [18:45] stgraber: testing [18:47] afk for a few while the build runs [19:09] slangasek: Hello. [19:10] ScottK: heya [19:10] so I have http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi, which AIUI I can rely on to start with as the list of failing packages [19:11] Right. [19:11] for this spec, I should filter those down to packages that have the same binary versions in karmic and lucid, right? [19:11] That's a different way to look at it than I did initially. [19:11] * ScottK ponders. [19:12] what was your way? that's what I'm having a hard time remembering [19:12] My way was to take a list of the rebuild failures just after the toolchain upload (which I've mailed you) and then remove the ones that built after that. [19:13] So it'd be that initial list less the ones with a different binary version that aren't also still failing to build. [19:13] ok - I'm actually not sure I ever received that email from you [19:13] X - (Y-z) [19:13] * ScottK looks for it. [19:15] Sent in January 31, 2010 at 00:35 my time. [19:15] misplaced on my end then, sorry [19:16] No problem. Resent. [19:16] The X - (Y -Z) bit was only the first part of the question. [19:17] That gives us a good list for i386 and amd64. [19:17] The next question was ports. [19:17] sorry - I knew you had intended to send that mail, but when I failed to find it in my inbox folks directed me to lucas's later rebuild mails instead, which is where I started floundering because AFAIK those weren't being done with the snapshot from the original plan [19:17] Right. No problem. [19:18] right, the ports part I remember - remove the ports binaries IFF i386 or amd64 FTBFS and is up-to-date in the archive [19:18] For ports, we wanted to assume anything that failed amd64 or i386 would fail on ports and remove those too, except for port specific packages (e.g. silo). [19:18] Yes. [19:18] (in fact, that's documented clearly in the spec :) [19:18] Ah, good. [19:19] Is it clear now then? [19:19] yes, thanks [19:19] though I still don't have that email from you [19:19] getting wedged/filtered somewhere, I fear [19:19] Let me post the files somewhere then. [19:20] ok [19:22] slangasek: http://kitterman.com/kubuntu/ [19:24] great, thanks! [19:24] nbs.i386only is empty on purpose [19:25] ScottK: right, I should follow through on this while I have the state in my brain - if you're around later, I'd like to tackle the python syncs question as well [19:26] OK. I'll be around off and on from here on out today. [19:32] gotta love the speed of that edubuntu-dvd build [19:33] heh, it's just a huge squashfs and a smaller one ;) [19:34] so livefs takes a lot of time (especially on i386 as it build ltsp as well) but the DVD build process should then be quite fast ;) [19:48] heh [19:48] yeah - it [19:48] s currently squashing the dvd image [19:48] and then we get to see if the other fixed it. [20:23] stgraber: fail [20:23] + mksquashfs /build/buildd/ltsp-live /build/buildd/images/ltsp-live.img -noF -noD -noI -no-exports -e cdrom [20:23] Could not create destination file: No such file or directory [20:25] gar [20:54] lamont: and I assume /build/buildd/images exists ? [20:55] that's what that mkdir was supposed to do [21:03] stgraber: nope. [21:03] and you created the source directory... :-p [21:03] fixed and running again already [21:03] argh, seems like my mind wanted to create the destination but my fingers went with the source instead ... [21:04] yeah. and I had faith in your fingers. [21:04] sorry for having you have to trigger another rebuild :( [21:04] I read the manpage right after pasting the error above, and went "doh" [21:04] OTOH, if this works, they can burn ISOs, since it's a genuine run [21:05] slangasek: still have the lock, but only because BuildLiveCD is acutally running - it's back to normal otherwise. kthx [21:10] lamont: cheers [21:11] slangasek: and totally cowboyed - I'll upload after I confirm it works