 Second install of MAAS on amd64 seems to fail
[00:49] <hggdh> skaet, plars: http://launchpad.net/bugs/1066421 utter failure on MAAS install, AMD64, server
[00:49] <ubot2> Launchpad bug 1066421 in maas "fresh MAAS install from ISO fails when opening the MAAS URL" [Undecided,New]
[00:55] <slangasek> ScottK: mmh, cjwatson managed to extract the codename from him but we're apparently still waiting for the announcement
[00:55] <slangasek> stgraber: ok; it would be helpful if you could test the server install under SB since I'm not able to, but if you can't you can't
[00:55] <slangasek> stgraber: thanks for the bug report
[00:59] <slangasek> skaet, stgraber: so I've targeted the grub bug to quantal, because we should fix it for 12.10; the question is whether it should be post-release or not.  I'm having a look now at whether this impacts the installer's grub.cfg - it may well not
[01:03] <slangasek> stgraber, skaet, infinity: this bug doesn't affect the media, only the grub.cfg generated by update-grub; so I agree this is release-notable and have targeted to quantal-updates.  Will accept debian-installer now.
[01:09] <slangasek> skaet: I believe the grub2 -> debian-installer -> debian-cd dependencies related to boot mean that we should be respinning all our bootable images to make sure they're up-to-date.  Should we do that sooner rather than later?
[01:10] <skaet> slangasek, sooner rather than later would definitely be the preference.
[01:10] <slangasek> ok.  should I queue up the builds then?
[01:10]  * slangasek checks the pad for other targets of opportunity
[01:11] <skaet> slangasek, update the pad, and go ahead.    I'll update the tracker.
[01:17] <slangasek> skaet: pad updated, build triggers set
[01:19] <skaet> slangasek, iso tracker has everything except cloud images and wubi now marked for rebuilding.
[01:19] <slangasek> skaet: you targeted bug #1065686 to quantal-updates but it's still on the pad as an "opportunity target" - do we know where PS is with this?
[01:19] <ubot2> Launchpad bug 1065686 in unity-scope-video-remote "remote video scope doesn't full switch off traffic when privacy option switched on" [High,In progress] https://launchpad.net/bugs/1065686
[01:19] <skaet> go ahdead and start it off if you've got it up.
[01:19] <slangasek> skaet: wubi is being rebuilt.  core is not.
[01:19]  * skaet fixes core to indicate as such
[01:19] <slangasek> oh, let me think; maybe wubi doesn't need a rebuild either
[01:20] <skaet> slangasek, won't wubi need the rebuild once we get the certificates sorted
[01:20] <slangasek> yes
[01:20] <skaet> so, doesn't seem much point in spinning it now.
[01:20] <slangasek> but I need to see how it gets its bootloader and whether it's affected by this d-i change
[01:20] <skaet> ok
[01:21] <slangasek> hmmm, I don't think wubi is affected; dropping it from my respin pipeline
[01:21] <skaet> ok
[01:22] <skaet> re: PS,  they've got a fix, but its probably tied in with other ones which we don't really want to pick up.
[01:23] <skaet> go ahead without it,  but leave that one on the pad as an opportunity target if we can get a cherry picked update from them.
[01:23] <plars> skaet: I added https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1066376 - keyboard doesn't work to enter password with panda and encrypted partitions under the investigation section, I believe infinity is looking into it but it could be worked around with serial
[01:23] <ubot2> Launchpad bug 1066376 in initramfs-tools "keyboard doesn't work to enter password with panda and encrypted partitions" [Undecided,New]
[01:23] <slangasek> skaet: well, unless we're specifically pressing them for a cherry-picked update, I don't imagine we'll see one
[01:23] <slangasek> anyway - pipelines are all queued up and I'm heading out for the evening
[01:24] <slangasek> skaet, infinity: if something comes up before the pipes kick off (in ~1h) and you need to cancel them, it's 'killall -9 wait-for-package' on nusakan
[01:24] <skaet> slangasek,  agreed.   kick'em off
[01:24] <skaet> why the delay?
[01:25]  * skaet figures PS is unlikely to be ready in next hour.
[01:25] <skaet> slangasek,  my understanding is that infinity is traveling now,  so won't be online for a while.
[01:31] <slangasek> oh, it is about that time, isn't it
[01:32] <slangasek> skaet: the delay is because we can't rebuild images for the updated d-i until the updated d-i is published...
[01:32] <skaet> slangasek,  gotcha.
[01:33] <skaet> plars, ok.  we'll release note it if necessary.
[02:02] <skaet> :)
[02:06] <len-dt> skaet, would it be possible to get a ubuntustudio respin?
[02:07] <len-dt> (after the above is approved..
[02:15] <skaet> len-dt
[02:15] <len-dt> ay
[02:15] <skaet> there's a respin queue'd up now.
[02:15] <skaet> I'll go in and review the ubuntustudio-meta,  and hopefully it will make it in time.
[02:15] <len-dt> ok, will the meta package above make it in?
[02:15] <micahg> skaet: respin is useless without the new meta
[02:16] <skaet> micahg,  slangasek already queued up the respin,  its started now
[02:16] <skaet> it may need another to pick up the ubuntustudio-meta though due to timing,  that's all
[02:17] <len-dt> OK.
[02:17] <skaet> len-dt, micahg - package looks ok.  it's approved
[02:18] <skaet> not sure if it will build in time or not for the respin.
[02:19] <skaet> if its not included in the next set of images, ping on this channel and one of the release team will kick off the respin to pick it up.
[02:19] <len-dt> will do, I'll test it tonight (PDT -700)
[02:19] <skaet> thanks
[02:19] <len-dt> NP
[05:23] <slangasek> hmm, why has the debian-installer publication not made it out to nusakan yet :P
[05:23] <slangasek> so the builds haven't started yet, because the trigger has thus far failed
[05:23] <slangasek> so good news for ubuntustudio, I guess
[05:24] <slangasek> because there was a stale lock file, sigh
[05:25] <slangasek> ok, image builds starting now
[05:37] <ScottK> I guess that answers the question about if I should stay up and wait for a fresh build to do more testing tonight.
[05:37] <slangasek> apparently
[05:37] <slangasek> sorry :/
[05:42] <ScottK> No problem.  Sleep is for the best anyway.
[08:10] <stgraber> slangasek: ok, I'll figure some way of doing a server install on that laptop later today or (more likely) tomorrow.
[08:19] <xnox> slangasek: maybe we do have a couple ubiquity bugs: bug 1066347 bug 1066302 bug 1065502
[08:19] <ubot2> Launchpad bug 1066347 in ubiquity ""Reinstall Ubuntu" failed - apt-clone crashes with: KeyError: "filename './etc/apt/sources.list' not found" line 1886 in getmember in tarfile.py" [High,Confirmed] https://launchpad.net/bugs/1066347
[08:19] <ubot2> Launchpad bug 1066302 in ubiquity "'update this installer' link on the welcome page shows no response to a mouse click" [High,Confirmed] https://launchpad.net/bugs/1066302
[08:19] <ubot2> Launchpad bug 1065502 in ubiquity "Ubiquity failed to proceed to partman, fails at replace recipe now..." [High,Confirmed] https://launchpad.net/bugs/1065502
[08:21] <xnox> the middle one is funny... as the update this installer shouldn't be shown at all, because we did not trigger 0day ubiquity update.
[08:33] <cjwatson> slangasek: keystatus and loadenv are simple and should be fine - adding those now.  I'm less sanguine about tftp; would rather do that at a bit more leisure.
[08:39] <cjwatson> ^- cloud fix + secure boot fix.  The former at least needs a quick regression-test on real BIOS as well
[08:46] <jibel> slangasek, there are 2 bugs that are important when installing over an existing installation bug 1065502 and bug 1066347
[08:46] <ubot2> Launchpad bug 1065502 in ubiquity "Ubiquity failed to proceed to partman, fails at replace recipe now..." [High,Confirmed] https://launchpad.net/bugs/1065502
[08:46] <ubot2> Launchpad bug 1066347 in ubiquity ""Reinstall Ubuntu" failed - apt-clone crashes with: KeyError: "filename './etc/apt/sources.list' not found" line 1886 in getmember in tarfile.py" [High,Confirmed] https://launchpad.net/bugs/1066347
[08:47] <jibel> first one hangs the installer, second breaks the 'reinstall' functionality
[12:30] <xnox> cjwatson: doesn't loadenv -> reads & loads stuff from hard-drive & hence could be altered while machine is off leading to possibly doing something to bypass secure-boot or inject something?!
[12:35] <jibel> I reproduced bug 1066445 - fresh desktop installation with latest amd64 image
[12:35] <ubot2> Launchpad bug 1066445 in apt "Crashes doing update or upgrade operations" [Critical,Confirmed] https://launchpad.net/bugs/1066445
[12:53] <ScottK> The massif-visualizer uploadis mine, so I can't accept it.  Should be an easy one for someone to review.
[14:53] <cjwatson> xnox: It reads environment variable settings, but that shouldn't let you execute arbitrary code before ExitBootServices.
[14:54] <cjwatson> doko: Your cairo-5c sync FTBFS ...
[14:56] <cjwatson> ScottK: Accepted.  You can close bug 935294, I think.
[14:56] <ubot2> Launchpad bug 935294 in massif-visualizer "massif-visualizer version 0.3-0ubuntu1 FTBFS on armhf in precise" [High,Confirmed] https://launchpad.net/bugs/935294
[15:00] <cjwatson> xnox: Also, note that "arbitrary code" in this context specifically excludes being able to run arbitrary GRUB commands; we already know you can do that and the system is structured so that that should not be a problem.  It would only be a problem if you could somehow arrange to run arbitrary code which is not already exposed as commands.
[15:00] <cjwatson> xnox: Remember that we *already* load /boot/grub/grub.cfg from the hard disk.
[15:19] <skaet> cjwatson,  would you mind turning off image erasing?   we're starting to stradle multiple days now and the historical ones may be useful.
[15:19] <skaet> (testing against at any rate)
[15:19] <cjwatson> done
[15:19] <hggdh> anyone confirmedhttps://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1066480 ?
[15:19] <ubot2> Launchpad bug 1066480 in ubiquity "12.10 installer don't show encrypted partitions" [Undecided,New]
[15:19] <cjwatson> (not available for most of rest of today)
[15:21] <skaet> thanks cjwatson
[16:02] <ScottK> cjwatson: Thanks.  Forgot about the bug.
[16:03] <hggdh> why is 'ubuntu' considered a weak password for an user, and a fair password for disk encryption?
[16:27] <skaet> ScottK, stgraber, slangasek, infinity -  can one of you take a look at https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1066445?   we may need to revert that last apt upload.
[16:27] <ubot2> Launchpad bug 1066445 in apt "apt-get crashed with SIGSEGV in pkgCacheGenerator::ListParser::NewProvides()" [Critical,Confirmed]
[16:29] <hggdh> skaet: is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1066480 important enough?
[16:29] <ubot2> Launchpad bug 1066480 in ubiquity "12.10 installer don't show encrypted partitions" [Undecided,Confirmed]
[16:32] <skaet> hggdh,  ugh.   not recognizing there's data there isn't good.  :P
[16:32] <hggdh> my thought also... adding to the pad
[16:33] <skaet> am marking it critical for now.   slangasek may modify that - but want it looked at as soon as possible.
[16:34] <hggdh> pad-added
[16:37] <hggdh> skaet: I cannot reproduce 1066445, and I do have main, universe, multiverse, partners in the source.list
[16:41] <skaet> hggdh,  interesting.    update from fresh install of precise?
[16:41] <skaet> what did you start from?
[16:54] <hggdh> skaet: I was already on quantal. I think this may be the difference
[16:55] <hggdh> I can try from precise
[17:00] <doko> cjwatson, known (as it was ftbfs before too), this was just for cleaning up the source package.
[17:04] <jibel> skaet, it is not reproducible on every system. I haven't found a pattern yet but got it on hardware and VM, fresh installation, all amd64
[17:04] <jibel> (re. 1066445)
[17:06] <hggdh> jibel: were you upgrading?
[17:10] <jibel> hggdh, no, right after a fresh installation
[17:14] <hggdh> ok so I am without a failure indeed
[17:20] <infinity> cjwatson: Accepted grub2, and uploaded a grub2-signed to go with it.
[17:20] <infinity> (If anyone else wants to let the -signed through...)
[17:21] <xnox> hggdh: actually both passwords use the same algo, so actually passwords should be reported as "the same strengthness"
[17:21] <hggdh> xnox: somehow they are still shown as fair and weak. So... bug on it
[17:22] <xnox> cjwatson: ok, thanks for explanation.
[17:25] <xnox> about bug 1066480. There is currently no UI to activate encrypted partitions (but partman can do it) but the other thing is that there is no ui nor partman functionality to de-activate encrypted partitions, which maybe desired for wipe & reinstall. Maybe we need to release note it.
[17:25] <ubot2> Launchpad bug 1066480 in ubiquity "12.10 installer don't show encrypted partitions" [Critical,Confirmed] https://launchpad.net/bugs/1066480
[17:32] <hggdh> xnox: and, on a server install, both passwords are shown as 'weak'
[17:32] <xnox> hggdh: yes file bug. ubiquity != server cd. Ubiquity and debian-installer use different algorithms.
[17:33] <hggdh> ack
[17:33] <hggdh> will repeat to capture the data (original install is long gone)
[17:39] <phillw> infinity: could you take a look at bug 1066435 thanks
[17:39] <ubot2> Launchpad bug 1066435 in debian-installer "Debian-installer powerpc recursive fault" [Undecided,Confirmed] https://launchpad.net/bugs/1066435
[17:43] <skaet> infinity, accepted grub2-signed
[17:58] <skaet> lamont,  jibel saw the failure on hardware and VM,  fresh installation,  all amd64.  hggdh hasn't been able to see it though.   what are the specifics of the system you saw 1066445 on?
[18:01] <lamont> skaet: I'd have to dig a bit, but I'm pretty sure this was an install from this year, call it precise, amd64, real hw.  do-release-upgraded to quantal at beta(1?), and dist-upgraded pretty much daily since then.  has quantal{,-{security,updates}} {main,universe,multiverse} (I should add restricted...sigh), as well as a ppa or 2
[18:01] <lamont> and a local arhcive
[18:01] <lamont> the mirror I hit is synced from us.archive at :50 each hour
[18:02] <skaet> thanks lamont, can you add that to the bug, so we see if we can get the pattern figured out?
[18:02] <lamont> sure
[18:02] <skaet> hggdh - can you add the details of the configurations you've tried that work to it as well?   would like to get as much of the data summarized in one place as possible.
[18:02] <skaet> thanks lamont
[18:07] <lamont> posted, with spell checking, even
[18:12] <skaet> :)
[18:29] <hggdh> skaet: added. I do get it with main, universe enabled
[18:29] <skaet> thanks hggdh
[18:35] <slangasek> cjwatson: tftp> ack :)
[18:35] <slangasek> cjwatson: there's no hurry, I'm still trying to prove to myself that I can actually get a working system using tftp
[18:37] <lamont> slangasek: working how?
[18:37] <slangasek> xnox: I was asking specifically about the bug that jibel said was still present after you fixed it... was that bug #1065502?
[18:37] <ubot2> Launchpad bug 1065502 in ubiquity "Ubiquity failed to proceed to partman, fails at replace recipe now..." [High,Confirmed] https://launchpad.net/bugs/1065502
[18:37] <slangasek> lamont: grub2 efi tftp
[18:37] <lamont> ah
[18:37] <lamont> that fails on my caring-scale
[18:37] <slangasek> lamont: with grub.cfg and kernel all loaded via tftp from grub, not bundled in a memdisk
[18:38] <lamont> at least for the moment
[18:38] <xnox> slangasek: it's a newly introduced bug, but has similar symptoms.
[18:38] <slangasek> xnox: hmm, ok
[18:38] <xnox> slangasek: the root cause is unclean unmounting of the /target resulting with "journal replay required" on first mount.
[18:39] <xnox> slangasek: which is cleared if you at least boot your system once, but not fine if you don't.
[18:39] <slangasek> xnox: ah; so this is only a problem for people who are serial installers?
[18:39] <xnox> it needs to be digged into why we are leaving the filesystem dirty at the end.
[18:39] <xnox> =)))))))
[18:39] <xnox> yes.
[18:40] <xnox> or force power-cycle shutdowners.
[18:40] <slangasek> xnox: then that shouldn't justify a respin on its own if that's the worst of the symptoms.  Unclean unmounting is obviously not good though, so please chase it up
[18:40] <xnox> ack. ok.
[18:47] <slangasek> skaet: the latest upload of apt only pulls in translation updates.  whatever this bug is, there's nothing to suggest it's tied to the latest upload (and therefore there's nothing to revert), nor evidence that it's widespread.
[18:48] <slangasek> skaet: well, modulo the fact that jibel and lamont both mention in scrollback that they're seeing it.
[18:49] <slangasek> skaet: anyway, the fact that a revert doesn't help still stands
[19:10] <jibel> slangasek, I have an easy test case for the apt bug: default install with free software enabled. Then all apps that depends on libapt will crash.
[19:10] <slangasek> jibel: except hggdh says he couldn't reproduce it?
[19:12] <jibel> slangasek, he said he did in comments 13 and 14
[19:12] <slangasek> ah, ok
[19:13] <slangasek> jibel: could you attach the sources.list (+sources.list.d) from this system?  may help to reproduce it more quickly
[19:13] <slangasek> also, the /var/cache/apt/pkgcache.bin that I asked for in the last comment
[19:20] <jibel> slangasek, it's uploading
[19:23] <jibel> removing the cache files does just make apt crash later when it recreates them.
[19:31] <skaet> slangasek,   that was my understanding too, however the timing does seem a bit suspect.
[19:32] <skaet> however,  finding root cause is the key at this point.
[19:32] <jibel> slangasek, done uploading, it's enough to copy the sources.list file attached to the bug report to an existing system to reproduce the crash.
[19:58] <hggdh> skaet: bug 1066556 should be either looked at, or release-noted. Which one?
[19:58] <ubot2> Launchpad bug 1066556 in debian-installer "MAAS install via d-i/tasksel fails whe opening the browser to /MAAS" [Undecided,New] https://launchpad.net/bugs/1066556
[20:38] <cjwatson> server team should look at that
[20:39] <cjwatson> skaet: if the timing of the apt upload is relevant, then since there are no source changes other than translations, it must be because *any* upload (and hence recompile) would have broken it; and therefore a revert won't help
[20:39] <cjwatson> but it could be something to do with the content of the Packages/Sources files
[20:41] <cjwatson> infinity: Thanks.  I was going to fiddle with grub2-signed to make sure it fetches binaries from -proposed - I suspect it might fail to build until grub2 hits release (which it probably shouldn't)
[20:41] <cjwatson> I'll sort that out tomorrow morning if nobody else has
[20:58] <cjwatson> Yeah, I can reproduce this with jibel's sources.list, though not with what I had in my sbuild chroots
[21:00] <skaet> cjwatson,  understand.
[21:01]  * cjwatson attempts a debug build
[21:15] <cjwatson> oh, for crying out loud, goes away when I try to debug it
[21:16] <cjwatson> I suppose that's to be expected for something introduced by a no-relevant-changes upload
[21:18] <cjwatson> oh, I forgot to put the relevant sources.list in place, whoops
[21:24] <cjwatson> OK, reproduced with a debug build now, which'll help
[21:28] <cjwatson> And under valgrind
[21:28] <cjwatson> (But not desperately helpfully)
[21:30] <cjwatson> God I hate C++
[21:38] <cjwatson> And it's all tied up in the cacheiterators stuff which I've never really understood at the best of times
[21:38] <cjwatson> Overly-clever Jason C++
[22:14] <cjwatson> Ah - well, it'll take me a bit longer to actually fix it, but I've tracked it down to excruciatingly unlucky timing of cache remapping in a function unequipped to handle it
[22:15] <cjwatson> So yeah, pretty sure reverting apt will make no difference worth mentioning
[22:16] <cjwatson> Unfortunately there may be a hard-to-resolve upgrade problem with old versions of apt; don't know what we can do about that short of (a) randomly permute size of cache by continuing normal development (b) SRU whatever fix we come up with
[22:16] <cjwatson> And possibly (c) release-note instructions for manually installing new apt
[22:33]  * cjwatson gets a feel for the pattern of working code now
[22:35] <skaet> cjwatson,  thanks for tracking that down.   Release noting is probably prudent based on the scenario you describe.
[22:37] <cjwatson> Fairly sure http://paste.ubuntu.com/1280162/ is the fix, or something very like it
[22:38] <cjwatson> The problem was that Prv->ProvideVersion was evaluated before the function assigning to it, which, in some very rare cases, changes Prv
[22:39] <cjwatson> skaet: would you mind setting up a release notes task on that bug?  I haven't kept track of the current method for doing that
[22:43] <skaet> cjwatson, will do.
[22:44] <cjwatson> thanks
[23:09] <skaet> cjwatson, release note task added, and have gone ahead and put bug and instructions on doing the manual update in the CommonInfrastructure  known issues section.
[23:10] <cjwatson> apt fix on its way to -proposed now - please review.  Sorry for the giant po/ diff but I believe it's all just trivial line number changes and other similar rearrangements.  The previous uploader mustn't have used 'bzr bd -S', I guess.
[23:11] <cjwatson> skaet: Yeah, that won't work :)
[23:11] <cjwatson> If 'apt-get install apt' worked this wouldn't be hard
[23:12] <skaet> cjwatson,  ah well, I hoped.   Adjust as needed.
[23:12] <cjwatson> reverted to an XXX comment for now
[23:13] <skaet> k
[23:16] <cjwatson> Oh, thinking about it, I bet fiddling with APT::Cache-Start would work around it
[23:16] <cjwatson> Too tired to write coherent release notes at the moment but let me quickly test that before bed while the problem is still reproducible
[23:26] <cjwatson> Right, yeah, that worked fine.  Workaround in the bug now.


[00:22] <k1l> i am quite sure its the same guy from last time.
[17:01] <genii> Myrtti: You seem to be talking to yourself in -unregged ;)
[17:01] <Myrtti> genii: nope, you're just not op
[17:01] <genii> Sorry, fix_your_connection
[17:01] <Myrtti> so you can't see the other side of the discussion
[17:01] <genii> Aaaaaah
[17:02] <genii> Neat


[02:10] <Mooncairn> Turns out I don't really need a new SSD, for space reasons at least. Maybe for age and longevity issues.
[02:11] <Mooncairn> Buying a 2 TB SSD right now is probably overkill. ;-)
[02:16] <Mooncairn> How old is too old for SSD?
[02:45] <cmaloney> Depends on the manufacturer
[02:49] <Mooncairn> Samsung EVO
[02:52] <Mooncairn> Samsung claims 5 years or 600 TBW. I'm wondering if that is anywhere close to reality.
[12:57] <jrwren> SSD at this point is really all about the speed IMO. or well... SATA SSD is old tech and higher speed nvme is where it is at.
[13:05] <jrwren> need that sweet sweet 7000MB/s nvme ;)
[13:17] <jrwren> I wonder if Kinetic will have anything new and interesting or if it is a minor release


[04:20]  * elky also recommends against entertaining trolls by having such discussions right in front of them.
[04:23]  * elky tends to find that telling people the script used to engineer them reduces the effectiveness of the script tenfold.
[04:34] <maco> elky: hmmm?
[04:36] <elky> maco, the spiel given to markdude in front of the 'hello ladies' guy
[04:36] <maco> spiel? umm ... do you mean the catalyst link?
[04:37] <elky> Yep
[04:37] <elky> and the rest, but the link specifically.
[04:42] <rww> would be more of a problem if they'd demonstrated the ability to read hyperlinks. but point taken.
[04:44] <maco> ha
[05:01] <valorie> I dunno, if I'm somewhere and being treated at as a troll because of my ignorance
[05:02] <valorie> I would read the script and gain some understanding
[05:02] <valorie> but then.... I'm not usually a troll
[05:02] <valorie> and I'm still unsure whether or not Austin was a troll


[09:06] <kraut> moin
[09:06] <Zic> @schedule
[09:06] <ubotu> Schedule for Etc/UTC: 04 Sep 15:00: Kernel Team | 05 Sep 12:00: Edubuntu | 08 Sep 00:00: MOTU Team | 08 Sep 17:00: Xubuntu Developers | 10 Sep 19:00: Screencast Team | 11 Sep 15:00: Server Team meeting
[09:20] <pkern> @now
[09:20] <ubotu> Current time in Etc/UTC: September 04 2007, 07:20:35 - Next meeting: Kernel Team in 7 hours 39 minutes
[10:10] <ziroday> @now
[10:10] <ubotu> Current time in Etc/UTC: September 04 2007, 08:10:14 - Next meeting: Kernel Team in 6 hours 49 minutes
[01:44] <Hobbsee> @schedule sydney
[01:44] <ubotu> Schedule for Australia/Sydney: 05 Sep 01:00: Kernel Team | 05 Sep 22:00: Edubuntu | 08 Sep 10:00: MOTU Team | 09 Sep 03:00: Xubuntu Developers | 11 Sep 05:00: Screencast Team | 12 Sep 01:00: Server Team meeting
[02:32] <pkern> @now
[02:32] <ubotu> Current time in Etc/UTC: September 04 2007, 12:32:47 - Next meeting: Kernel Team in 2 hours 27 minutes
[03:34] <zul> @schedule montreal
[03:34] <ubotu> Schedule for America/Montreal: 04 Sep 11:00: Kernel Team | 05 Sep 08:00: Edubuntu | 07 Sep 20:00: MOTU Team | 08 Sep 13:00: Xubuntu Developers | 10 Sep 15:00: Screencast Team | 11 Sep 11:00: Server Team meeting
[03:34] <sanguinarius> @now
[03:34] <ubotu> Current time in Etc/UTC: September 04 2007, 13:34:53 - Next meeting: Kernel Team in 1 hour 25 minutes
[03:50] <sanguinarius> @now
[03:51] <ubotu> Current time in Etc/UTC: September 04 2007, 13:51:02 - Next meeting: Kernel Team in 1 hour 8 minutes
[04:10] <pkern> @now
[04:10] <ubotu> Current time in Etc/UTC: September 04 2007, 14:10:37 - Next meeting: Kernel Team in 49 minutes
[04:53] <zul> morning
[04:53] <sanguinarius_> @now
[04:53] <ubotu> Current time in Etc/UTC: September 04 2007, 14:53:43 - Current meeting: Kernel Team
[05:01] <zul> umm..
[05:01] <BenC> I'm trying to retrieve the rest of the team :)
[05:03] <zul> ok
[05:03] <Hobbsee> BenC: offer coffee
[05:04] <BenC> might take beer
[05:05] <Hobbsee> BenC: or beer.  beer is good too, it seems.
[05:05] <elkbuntu> add pizza to the offer and you're likely to have a winner
[05:05] <Hobbsee> mmm...pizza...
[05:05] <Hobbsee> BAD ELKBUNTU!
[05:06] <BenC> Well I know rtg isn't going to be here
[05:06] <elkbuntu> caffeinated beer (surely america has this, right?) and pizza
[05:06] <BenC> kyle left ottowa for cambridge last night
[05:06] <BenC> so just waiting on amitk
[05:07] <BenC> I, nm, he's here :)
[05:07] <amitk> Sorry..i am already here
[05:07] <elkbuntu> i win!
[05:07] <amitk> a few minutes late
[05:07] <BenC> Ok, welcome to the kernel team meeting
[05:07] <BenC> Meeting info (past and present) is at https://wiki.ubuntu.com/KernelTeam/Meeting
[05:08] <BenC> We'll start of with team status
[05:08] <BenC> pkl_: You're first up in reverse alpha order
[05:10] <BenC> pkl_: What's your current work load right now?
[05:10] <pkl_> working on some kernel flavours for Gutsy.
[05:10] <pkl_> some bug work and that's more or less been it.
[05:11] <BenC> pkl_: Do you know the status of ntfs-write-support for userspace side?
[05:12] <pkl_> No, I believe it should be in place now.
[05:12] <pkl_> but that's a guess.
[05:12] <BenC> Ok, can you check up on it, just to make sure someone isn't secretly blocking on some unknown issue
[05:12] <pkl_> Yeah, I'll check with Colin,
[05:13] <BenC> ok, thanks
[05:13] <BenC> what's your expected work for the next couple of weeks, other than the normal bugs+fixes?
[05:14] <pkl_> Um, bug fixing is probably going to be the main focus.
[05:14] <pkl_> I anticipate putting AUFS into the kernel, and testing Unionfs 2.1 (that Kyle added) with liveCDS
[05:14] <BenC> yeah...the unionfs seems to be high prio
[05:15] <amitk> pkl_: what is AUFS used for?
[05:15] <pkl_> AUFS = Alternative Unionfs File System.
[05:16] <pkl_> It is basically a re-implemented Unionfs by a third-party, which is commonly believed not to have as many bugs or issues than Unionfs
[05:16] <BenC> is AUFS something you just want to add for people who want to use it...not for livecd this late in the cycle, right?
[05:16] <pkl_> It would probably be useful to have in the Gutsy kernel, especially as a fall back for people having problems with Unionfs.
[05:17] <pkl_> It's probably too risky for the livecd now :)
[05:17] <BenC> ok...so the unionfs 2.1 is in lum now, expected to be included and used with this next upload?
[05:17] <pkl_> I think so, yes.
[05:18] <BenC> then yeah, testing livecd with that needs to be done asap
[05:18] <pkl_> Kyle was having some problems with the apparmor patches and Unionfs.  But that should be resolved.
[05:19] <BenC> sounds like you've got plenty to work on :)
[05:19] <pkl_> hopefully...
[05:20] <BenC> amitk: so how's things been going in the mobile team?
[05:21] <amitk> mainly changes to the build system to decouple UME patches from core Gutsy
[05:21] <BenC> are all the patches for lpia/ume included now?
[05:21] <amitk> Far from it
[05:22] <BenC> what's left to include
[05:23] <amitk> Let me rephrase it - All that is available is included now. But there are many things that are WIP e.g. the new upstream MMC stack to support SD/SDIO, ACPI thermal optimisations, peripheral drivers, etc.
[05:24] <BenC> Ah, ok
[05:24] <amitk> Last couple of weeks, after changing the build system, I have committed the thermal optimisation patches to UME. All a GPL driver for Marvell SD8686 SDIO WLAN chip was committed to LUM
[05:24] <BenC> earlier you had mentioned getting lpia arch/flavour building using the same patches, moving it to a custom-binary target
[05:24] <amitk> s/All/also
[05:25] <amitk> that is a next step yes - Moving LPIA to use the same configuration for UME custom builds
[05:25] <BenC> either we need to rename one of those flavours to match the other, or add another capability to the build system to use the ume custom-binary patches so we don't have duplicated in debian/binary-custom.d/{ume,lpia}/patchset/*
[05:27] <amitk> BenC: agreed. I would prefer dropping UME in favour of LPIA, but since we don't yet have a complete set of packages for LPIA, I will hold back until that happens
[05:29] <BenC> amitk: ok...does ubuntu-mobile expect for ume flavour to become obsolete by gutsy release?
[05:29] <BenC> if so, perhaps it isn't too important, knowing we'll just be ditching it in the end
[05:31] <amitk> BenC: yes, with a caveat - LPIA should be equivalent to current UME
[05:31] <BenC> userspace wise, or kernel wise?
[05:32] <amitk> package repository-wise
[05:32] <BenC> ok, that's what I figured
[05:32] <BenC> Ok...anything new and exciting in the power side for general desktop users?
[05:33] <BenC> I imagine you haven't had much time to look at that
[05:33] <amitk> not yet. However there isn't much on the UME side this week. So I hope to go over the powertop recommendations to make sure Gutsy already support them.
[05:34] <BenC> excellent, I've been looking forward to that
[05:35] <amitk> that is all from my side
[05:36] <BenC> everything's moving along it seems
[05:36] <BenC> amitk: thanks
[05:37] <BenC> Now we need to go over the canonical-qa bugs real quick...see if we can get some resolution on them
[05:37] <Mithrandir> amitk: hopefully, you'll be able to drop UME in a week or two.
[05:37] <BenC> link is on the agenda
[05:37] <BenC> Mithrandir: ah, good to know, thanks
[05:37] <amitk> Mithrandir: \o/
[05:37] <BenC> one less build on i386 is always a plus
[05:38] <Mithrandir> that's pending us having working lpia images by then, but it's on my plan for next week, so.
[05:39] <BenC> Damn, I'm not sure which of the bugs are hidden from public view...
[05:39] <BenC> bug #130804
[05:39] <ubotu> Launchpad bug 130804 in linux-source-2.6.22 "[Ubuntu Tribe3]  Cannot install by LiveCD (weybridge)" [High,Confirmed]  https://launchpad.net/bugs/130804
[05:40] <BenC> That one looks like a failure to detect IDE on the weybridge
[05:40] <BenC> amitk: this reminds me, I have to send you a weybridge...
[05:41] <BenC> ACTION: Ben to test livecd on weybridge
[05:41] <amitk> BenC: if that would spare my laptop from compiling our kernels, it would be much appreciated :)
[05:42] <BenC> amitk: I'll get it out this week :)
[05:43] <BenC> bug #131626
[05:43] <ubotu> Launchpad bug 131626 in linux-source-2.6.22 "Sleep wakes up but screen is blank" [Medium,Triaged]  https://launchpad.net/bugs/131626
[05:46] <BenC> that seems to be a nv bug
[05:46] <BenC> wonder if nvidia proprietary driver fixes it
[05:47] <BenC> bug #131661
[05:47] <ubotu> Launchpad bug 131661 in linux-source-2.6.22 "Hibernate button on keyboard doesn't work on System76 Z62F" [Medium,Incomplete]  https://launchpad.net/bugs/131661
[05:47] <BenC> that one doesn't really sound like a kernel bug
[05:52] <pkern> At least fglrx suspend-to-RAM breaks with SLUB allocator activated. Which is why I am here and waiting for open discussion. ;o) Maybe that could be switched back to SLAB at least until ATI fixes that issue.
[05:52] <BenC> pkern: doubtful, slub fixes more things :)
[05:53] <BenC> ATI just needs to fix their driver
[05:53] <pkern> BenC: It was the only option I switched to make it work again with 2.6.22.
[05:53] <pkern> BenC: Of course, but in the meantime we break suspend-to-RAM with fglrx for all users of Gutsy.
[05:54] <BenC> pkern: but that's not a fault of ours
[05:54] <BenC> slub fixed way too many things to make fglrx an exception for switching
[05:55] <BenC> but we can definitely look into
[05:55] <pkern> BenC: What did it fix? I thought it's only a speed advantage.
[05:55] <BenC> I wont say there's no chance of us switching back...just that it's very unlikely
[05:55] <BenC> pkern: turning it on exposed so many bugs that were hard to find with slab
[05:56] <BenC> slub has better error checking
[05:56] <BenC> and the speedup and reduced fragmentation is a huge advantage
[05:56] <BenC> we should talk with some folks at AMD/ATI to see about fixing this properly, instead of disabling slub just to accomodate it
[05:57] <pkern> BenC: I guess there can't be another flavour, right? There was a thread on LKML about it some time ago and all agree that it's ATI's fault, but so far there was no response. (It's listed in their inofficial bug tracker, but then I don't know who reads it.)
[05:58] <BenC> we don't do separate flavours just to work around a broken proprietary driver
[05:58] <BenC> sets a bad precedent :)
[05:59] <pkern> It would be really nice to see this fixed in fglrx, of course. But I don't know if suspend-to-RAM should be broken if SLUB mainly helps finding bugs easier. (Which I agree with for a development version.)
[05:59] <BenC> ACTION: Ben to get in touch with AMD/ATI to see about resolving the fglrx+slub+hibernate bug
[05:59] <pkern> BenC: Thanks (:
[05:59] <BenC> any other open items?
[05:59] <zul> yep just sponsorship for uds
[06:00] <BenC> pkern: thanks for bringing it up, I'll definitely see about getting it resolved
[06:00] <zul> since i have an expired passport ;)
[06:00] <BenC> zul: we're in the process of looking at who will be sponsored
[06:00] <zul> ok
[06:01] <BenC> kernel related sponsors have been submitted, but it's upper management that has final say
[06:01] <zul> other than that none from me
[06:01] <pkern> BenC: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/121653/comments/15
[06:01] <ubotu> Launchpad bug 121653 in linux-source-2.6.22 "[gutsy]  Suspend to Ram does not work on Z61m" [Undecided,Confirmed]
[06:01] <BenC> pkern: thanks
[06:02] <BenC> Speaking of UDS, this is a good time to remind everyone that now's when you should start submitting blueprints for UDS
[06:02] <BenC> not the day UDS starts :)
[06:03] <BenC> So if there are any features you would like to see for gutsy+1, get to crackin
[06:03] <BenC> And I think that ends the meeting
[06:04] <BenC> Thanks everyone, and have a good week
[08:01] <sanguinarius> @now
[08:01] <ubotu> Current time in Etc/UTC: September 04 2007, 18:01:56 - Next meeting: Edubuntu in 17 hours 58 minutes
[12:33] <nealmcb> @now
[12:33] <ubotu> Current time in Etc/UTC: September 04 2007, 22:33:43 - Next meeting: Edubuntu in 13 hours 26 minutes


[00:00] <godbyk> dsmythies: I agree completely.
[00:00] <dsmythies> godbyk: It actually doesn't seem to be unmatched "section", as I checked every signal paring.
[00:00] <godbyk> dsmythies: And it'd be nice to log the output and only print errors to the console during compilation.
[00:01] <godbyk> Get all the irrelevant status messages out of the way, too.
[00:01] <godbyk> dsmythies: Ugh.. the xml-related warnings/errors I get are a complete pain to track down because they never seem to complain about the actual problem.
[00:02] <godbyk> dsmythies: They just complain in the vicinity of the problem.
[00:02] <dsmythies> godbyk: Yes, I agree. I am working on html compile right now. The other language .page compile will be a saga for another day.
[00:02] <godbyk> dsmythies: Sounds good.
[00:03] <dsmythies> godby: Yes, validation errors are the worst, as you say the actual error is only somewhere nearby.
[00:03] <godbyk> dsmythies: On another matter, what's your take on the hibernate bug+merge proposal?
[00:03] <godbyk> We have a couple options:
[00:04] <godbyk> 1. Accept the MP so the instructions are up to date and valid, or
[00:04] <godbyk> 2. Remove the instructions completely.
[00:04] <godbyk> Right now there are existing 'how to re-enable hibernate' instructions that don't work properly.
[00:05] <dsmythies> godbyk: I have been in total agrement with you throughout. But I have not reviewed that other link, the meeting minutes or whatever.
[00:05] <dsmythies> godbyk: since I do not like 2, I guess 1.
[00:05] <godbyk> From what I've read in the thread on the tech board mailing list, it appears that hibernation was disabled because it would fail on a lot of systems for a variety of reasons.
[00:06] <dsmythies> godbyk: That is waht KI7MT was saying also.
[00:06] <godbyk> And it seems that while some slight progress may have been made, no one is eager to re-enable the hibernate menu option because the feature still has lots of unresolved issues.
[00:06] <godbyk> I think (1) is the simplest thing to do for now,
[00:06] <godbyk> though (2) is tempting.
[00:07] <godbyk> I don't feel like I have enough info to really make a good call on (2), though. I don't know how common the problems are.
[00:07] <godbyk> (I want to ensure the docs aren't blamed for getting someone into trouble. So if there isn't already a rather hefty disclaimer on that page, I'll probably add one.)
[00:08] <dsmythies> godbyk: If you want more definate input from me, I will have to go off and study. It just isn't something that I have to deal with.
[00:08] <KI7MT> godbyk, dsmythies Just FYI .. the newest branch of gnome-docs already has this mod written up .. System Settings >> Battery & Power I think it's under.
[00:09] <godbyk> KI7MT: Thanks. I'll take a look at that!
[00:10] <dsmythies> KI7MT: is that the GNOME help I have on my 14.04 DeskTop, or some other GNOME help?
[00:11] <KI7MT> I pulled the latest branch, it's in there, let me look on  my laptop.
[00:12] <KI7MT> 12.04 doesn't have it in Gnome3 help .. not sure about Gnome3 on 14.04 .. but the dev branch defiantly has it.
[00:14] <dsmythies> KI7MT: Yes, it appears to be there on my 14.04 DeskTop. With a disclaimer.
[00:15] <dsmythies> KI7MT: I am actually running Unity at the moment, but just open the GNOME help manually.
[00:16] <dsmythies> KI7MT: For other reasons (e-mail from earlier today), I would like to look at the dev branch. Where did you get it?
[00:20] <KI7MT> dsmythies, It's on Git .. let me go get the link
[00:22] <KI7MT> dsmythies, https://wiki.gnome.org/Git
[00:23] <dsmythies> KI7MT: Thanks. I'll try ti figure out the proper "git clone bla"
[00:25] <KI7MT> here's the pull: git clone git://git.gnome.org/gnome-user-docs
[00:26] <dsmythies> KI7MT: Thanks.
[00:58] <dsmythies> godbyk: KI7MT: re: hibernate: The GNOME page and the Unity page are currently identical. The merge proposal and bug report in debate makes an additional change to the unity page.
[00:58] <dsmythies> godbyk: I say do option 1.
[00:59] <godbyk> dsmythies: That's what I'm leaning toward, currently.
[00:59] <dsmythies> godbyk: I think the current disclaimer is good enough.
[00:59] <godbyk> dsmythies: I'll take a look at it soon. Thanks!
[01:03] <KI7MT> dsmythies, I didn't pull them both up  .. maybe had he wrong page up in Unity
[01:03] <KI7MT> *had the
[01:05] <KI7MT> dsmythies, by Gnome page, are you pages pulled from Git and Unity and Unity on 14.04?
[01:06] <KI7MT> *talking about pages pull
[01:07] <KI7MT> let me try that again, are you referring to the Gnome Git pull and Unity on 14.04
[01:08] <dsmythies> KI7MT: I only have got on my server, so my git clone is there. So no, I pulled up on my DeskTop 14.04 VM both pages (GNOME and Unity) side by side.
[01:08] <dsmythies> KI7MT: I only have git on my server, so my git clone is there. So no, I pulled up on my DeskTop 14.04 VM both pages (GNOME and Unity) side by side.
[01:09] <KI7MT> Ok., I've not looked at the MP, need to look at that an see the diffs.
[01:09] <dsmythies> KI7MT: i'll look at the git pull version for any further changes.
[01:10] <dsmythies> KI7MT: as for my other reasons for looking at the git clone version, they are still not up to date with reality.
[01:11] <KI7MT> dsmythies, I have Gnome3 on my laptop here, 12.04 .. so will look Git pull and what's on here.
[01:14] <dsmythies> KI7MT: while the two GNOME files (power-hibernate.page from git and from 14.04) differ by a few bytes, the content appears the same.
[01:17] <KI7MT> I had to pull gnome-docs .. still downloading
[01:27] <KI7MT> dsmythies, yeah, the patch is definitely updating the gnome Git pull too  .. the MP would be adding to that allso.
[01:31] <dsmythies> KI7MT: I do not understand. The MP is only for ubuntu-docs. It appears as though the same change could be applied upstream also, though.
[01:48] <KI7MT> dsmythies, The original file was probably form the gnomes docs  .. donesn't matter really, main thing is the ub-docs gets the MP update. The Gnome folks wold have to test ti against Gnome3 anyway.
[16:37] <dsmythies> godbyk: Are you around?
[17:02] <dsmythies> godbyk: I'll just go ahead and ask my question, and maybe see a reply later today or whenever:
[17:03] <dsmythies> godbyk: I have finally isolated the source of the two html compile errors "Unmatched block element: section".
[17:03] <dsmythies> godbyk: to display-dual-monitors.page and the basic root issue is if:choose stuff, yet again. It appears to be confusing xsltproc
[17:03] <dsmythies> godbyk: Note: I am using the upstream yelp-tools that shaunm_ pointed me to the other day.
[17:03] <dsmythies> godbyK: It took me many many hours to isolate the file, but the final trick was to edit yelp build and add the --load-trace switch to the related xsltproc call.
[17:03] <dsmythies> godbyk: Anyway, rather than attempt to figure out a away to make it work, I want to just nuke the if:choose stuff.
[17:03] <dsmythies> godbyK: We have been hoovering around this suggestion both here on IRC and on the doc team e-mail list for awhile now.
[17:03] <dsmythies> godbyk: This particular file is completely different than the GNOME version already anyhow, so I think there isn't really an issue.
[17:03] <dsmythies> godbyk: What do you think?
[20:52] <godbyk> dsmythies: For our needs, it appears that the conditionals (<if:choose>, etc.) aren't necessary since we use different sets of .page files for Unity and GNOME Shell.
[20:53] <godbyk> dsmythies: Given that, I don't think there's any need to maintain the conditions if they're getting in our way.
[21:15] <dsmythies> godbyk: I agree. I will proceed with display-dual-monitors.page modifications later today.
[21:18] <dsmythies> godbyk: I think at one time Jermey was trying to make it so that one set of .page files could be used for both Unity and GNOME. That effort has now been abandoned, and I think that was confirmed by shaunm_ here on IRC a few days ago.
[21:22] <godbyk> dsmythies: Makes sense.
[21:22] <godbyk> dsmythies: The conditionals would be useful if we shared one set of files for both platforms and if we had our work committed upstream.  Sorry.
[21:25] <dsmythies> godbyk: In an ideal world, we would sort out GNOME upstream first, then unity downstream. However, there are only so amny hours in a day. Although I will feel bad not upstreaming edits that could apply to both.
[21:25] <godbyk> dsmythies: Agreed. Once we get our docs up to speed, we can look into submitting patches upstream. I don't mind doing that.
[21:27]  * dsmythies leaves for nephew's soccer game....
[21:28] <godbyk> Have fun!