[00:20] <slangasek> 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] <slangasek> stgraber, lamont: edubuntu builds still failing with the same error, what's outstanding here?
[09:28] <ev> slangasek: what does ntfsresize --info say?
[14:49] <mvo> slangasek, pitti: any news for the feature freeze exception for computer-janitors dbus branch? bug #541990
[15:26] <pitti> mvo: hm, this seems to be a "damned if you do, damned if you don't" kind of thing
[15:27] <pitti> 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] <ScottK> That could also be an argument for the rewrite.
[15:29] <barry> pitti: i do think it's much more stable, and i already have another use case for the dbus backend :)
[15:29] <pitti> ScottK: except that we know that the current version at least by and large works and doesn't wreak havoc
[15:30] <mvo> 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] <barry> 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] <barry> but i understand the concern, being here at b1
[16:00] <slangasek> ev: dunno - will have to check next time I'm in getting a haircut
[16:00] <slangasek> :-)
[16:01]  * ev raises an eyebrow
[16:01] <ev> clearly I missed some context :)
[16:01] <slangasek> my barber was interested in trying it, so I gave him a CD, and it won't auto-resize his Windows 7 :(
[16:03] <cjwatson> if I can ever get this damn machine to my right working, I'll test it
[16:03] <cjwatson> I have too many bugs to be able to spend time on hardware maint
[16:09] <slangasek> it doesn't fail /generally/, only on his machine
[16:32] <Keybuk> besides, my pilots licence quite clearly states STAY CLEAR OF CLOUD
[16:32] <lamont> slangasek: sigh.  let me go figure it out.  do you need terranova anytime soonish? (next hour or 2)
[16:33] <slangasek> lamont: not urgently
[16:33] <slangasek> Keybuk: <snort>
[16:34] <lamont> Keybuk: clearly you need to go for instrument rating
[16:34] <slangasek> for the privilege of flying blind in the cloud?
[16:35] <Keybuk> slangasek: yeah, you need an IR to be legally allowed to enter cloud (or in the UK, even fly above it)
[16:35] <slangasek> yes, I know
[16:35] <slangasek> I was just stretching out the word game :)
[17:42] <ev> slangasek, kees: do either of you know for certain if derivative distributions (specifically, Xubuntu) can use the LTS designation?
[17:42] <ev> That is, do we cover everything they ship with security updates for 5 years?
[17:43] <jdstrand> afaik, they have not in the past
[17:43] <jdstrand> eg, kubuntu in hardy was not LTS
[17:43] <charlie-tca> 3 for desktops, I think. 5 for servers
[17:43] <ScottK> Canonical already doesn't do security updates for Xubuntu
[17:43] <ev> but to be clear, Kubuntu definitely is this time, right?
[17:44] <ScottK> ev: yes.
[17:44] <ev> okay
[17:44] <jdstrand> I thought Xubuntu was all in universe these days?
[17:44] <jdstrand> maybe I am misremembering...
[17:44] <ScottK> jdstrand: That's why I said Canonical didn't do security updates for it.
[17:44] <ev> ah indeed, xfce4-panel at least is
[17:44] <ev> okay
[17:45] <ScottK> ev: To be even more specific, Kubuntu (desktop) is LTS, Kubuntu Netbook Remix is not.
[17:45] <ev> 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] <ev> ScottK: ah, thanks for that clarification, I hadn't thought to consider the netbook editions
[17:45] <slangasek> ev: modulo UNE not actually being an LTS: https://wiki.ubuntu.com/LucidLynx/ReleaseManifest
[17:45] <ev> slangasek: ah, I forgot about that page
[17:45] <ev> thanks a bunch!
[17:46] <jdstrand> as did I
[17:46] <pitti> slangasek: I replied to bug 546933, and I'm mildly in favor, but would like to get more opinions on that one
[17:47] <ScottK> 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] <slangasek> 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] <slangasek> pitti: will look at it this morning
[17:48] <ScottK> True.
[17:49] <ScottK> 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] <slangasek> hum
[17:50] <slangasek> 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] <slangasek> 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] <slangasek> kees: weren't we waiting for you to tell us what the seeds were?
[17:56] <kees> slangasek: me? no, that's up to what defines the release
[17:56] <slangasek> ok, then I guess I need to check with mvo/barry on this
[17:57] <kees> slangasek: i.e. "Ubuntu Server" is server-ship. so when Jos says "this is 5 year", mvo's tool marks that seed
[17:57] <kees> but right now, we have to guess at the seed based on the product/image in the ReleaseManifest
[17:57] <slangasek> who does?
[17:58] <slangasek> is it security team guessing, or mvo, or?
[17:58] <kees> I'm saying "one" guesses.  for lucid, we (security and mvo) understand 5 year support to be server-support + server-ship.
[17:59] <slangasek> then that's what I'm going to write there
[17:59] <kees> heh
[18:00] <kees> 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] <slangasek> kees: my understanding was that you and mvo were in the process of *defining* that mapping, since it was done slipshod previously
[18:04] <slangasek> 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] <ev> slangasek: that strikes me as being very confusing to end users
[18:04] <ev> if that's the case, what does LTS convey
[18:05] <slangasek> it conveys that Canonical is standing behind its status as a long-term-supported product
[18:05] <slangasek> which would not *automatically* the case for Xubuntu with a community security committment
[18:05] <kees> 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
[18:07] <kees> slangasek: so really it's now "supported-server" + "server-ship" - explicit blacklist
[18:09] <slangasek> kees: ok, where is the list of mappings that mvo's tool uses?
[18:11] <kees> slangasek: afaiu, it's done somewhere in launchpad via cron.germinate and maintenance-check.py
[18:11] <kees> slangasek: the blacklist is lp:~ubuntu-core-dev/ubuntu-seeds/platform.lucid/ SUPPORTED_HINTS
[18:12] <kees> slangasek: right now, it is pending a change to add server-ship which was missed in the first version.
[18:12] <kees> 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] <stgraber> slangasek, lamont: Any clue on what's happening with Edubuntu ?
[18:18] <slangasek> I'm waiting for lamont's analysis
[18:18] <stgraber> Could not create destination file: No such file or directory
[18:18] <stgraber> that's new ...
[18:18] <stgraber> 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] <stgraber> doh, I guess I found the problem ...
[18:25] <stgraber> seems like mksquashfs doesn't like creating an image in a non-existing directory
[18:25] <stgraber> http://pastebin.com/anpmac7s
[18:25] <stgraber> lamont: ^
[18:42] <lamont> stgraber: heh
[18:45] <lamont> stgraber: testing
[18:47] <lamont> afk for a few while the build runs
[19:09] <ScottK> slangasek: Hello.
[19:10] <slangasek> ScottK: heya
[19:10] <slangasek> 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] <ScottK> Right.
[19:11] <slangasek> for this spec, I should filter those down to packages that have the same binary versions in karmic and lucid, right?
[19:11] <ScottK> That's a different way to look at it than I did initially.
[19:11]  * ScottK ponders.
[19:12] <slangasek> what was your way?  that's what I'm having a hard time remembering
[19:12] <ScottK> 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] <ScottK> 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] <slangasek> ok - I'm actually not sure I ever received that email from you
[19:13] <ScottK> X - (Y-z)
[19:13]  * ScottK looks for it.
[19:15] <ScottK> Sent in January 31, 2010 at 00:35 my time.
[19:15] <slangasek> misplaced on my end then, sorry
[19:16] <ScottK> No problem.  Resent.
[19:16] <ScottK> The X - (Y -Z) bit was only the first part of the question.
[19:17] <ScottK> That gives us a good list for i386 and amd64.
[19:17] <ScottK> The next question was ports.
[19:17] <slangasek> 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] <ScottK> Right.  No problem.
[19:18] <slangasek> 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] <ScottK> 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] <ScottK> Yes.
[19:18] <slangasek> (in fact, that's documented clearly in the spec :)
[19:18] <ScottK> Ah, good.
[19:19] <ScottK> Is it clear now then?
[19:19] <slangasek> yes, thanks
[19:19] <slangasek> though I still don't have that email from you
[19:19] <slangasek> getting wedged/filtered somewhere, I fear
[19:19] <ScottK> Let me post the files somewhere then.
[19:20] <slangasek> ok
[19:22] <ScottK> slangasek: http://kitterman.com/kubuntu/
[19:24] <slangasek> great, thanks!
[19:24] <ScottK> nbs.i386only is empty on purpose
[19:25] <slangasek> 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] <ScottK> OK.  I'll be around off and on from here on out today.
[19:32] <lamont> gotta love the speed of that edubuntu-dvd build
[19:33] <stgraber> heh, it's just a huge squashfs and a smaller one ;)
[19:34] <stgraber> 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] <lamont> heh
[19:48] <lamont> yeah - it
[19:48] <lamont> s currently squashing the dvd image
[19:48] <lamont> and then we get to see if the other fixed it.
[20:23] <lamont> stgraber: fail
[20:23] <lamont> + mksquashfs /build/buildd/ltsp-live /build/buildd/images/ltsp-live.img -noF -noD -noI -no-exports -e cdrom
[20:23] <lamont> Could not create destination file: No such file or directory
[20:25] <lamont> gar
[20:54] <stgraber> lamont: and I assume /build/buildd/images exists ?
[20:55] <stgraber> that's what that mkdir was supposed to do
[21:03] <lamont> stgraber: nope.
[21:03] <lamont> and you created the source directory... :-p
[21:03] <lamont> fixed and running again already
[21:03] <stgraber> argh, seems like my mind wanted to create the destination but my fingers went with the source instead ...
[21:04] <lamont> yeah.  and I had faith in your fingers.
[21:04] <stgraber> sorry for having you have to trigger another rebuild :(
[21:04] <lamont> I read the manpage right after pasting the error above, and went "doh"
[21:04] <lamont> OTOH, if this works, they can burn ISOs, since it's a genuine run
[21:05] <lamont> slangasek: still have the lock, but only because BuildLiveCD is acutally running - it's back to normal otherwise.  kthx
[21:10] <slangasek> lamont: cheers
[21:11] <lamont> slangasek: and totally cowboyed - I'll upload after I confirm it works