[00:19] <infinity> Oh, thank god, I was worried we might go a whole month without a poppler ABI bump.
[00:20] <infinity> I wonder if maybe we should rename PlusOneMaint to PopplerAndEDSMaint.
[00:22] <doko> just staff two people from -desktop for the team, there's not much to do for -foundations
[00:23] <infinity> I dunno, we had a nasty poppler API transition earlier this cycle, where the best porting work was done by a member of the kernel team.
[00:23] <infinity> Clearly, we need more kernel people.
=== henrix_ is now known as henrix
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
[08:46] <psivaa> Just in case it has not been noticed, the report.html for quantal server contains 9 packages, though they are not affecting our daily automated tests
[08:50] <xnox> psivaa: I am curious which report do you mean. Can you please give a full link?
[08:50] <psivaa> xnox, http://cdimage.ubuntu.com/ubuntu-server/daily/current/report.html
[08:51] <xnox> I see. cool thanks.
[08:51] <psivaa> xnox, just for the information though
=== mmrazik is now known as mmrazik|lunch
[09:25] <cjwatson> psivaa: yep.  they're all listed on http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html, so it isn't an image build problem.
[09:26] <cjwatson> psivaa: I suspect that http://people.canonical.com/~ubuntu-archive/component-mismatches.txt explains a fair few of them
[09:27] <cjwatson> Probably ignorable for now.
[09:31] <Laney> infinity: doko_: Is it unreasonable to expect the uploader to care about transitions they start?
[09:35] <Laney> He did do some, actually.
[09:39] <psivaa> cjwatson, i see the connection now, thanks, will check them as well in the future.
=== doko_ is now known as doko
=== mmrazik|lunch is now known as mmrazik
[11:38] <sil2100> Hello!
[11:38] <sil2100> I have a new UIFe proposition
[11:39] <sil2100> https://bugs.launchpad.net/unity-asset-pool/+bug/1049594 <- would be grateful if someone could check it out in their free time :)
[11:39] <ubot2> Launchpad bug 1049594 in unity-asset-pool "[UIFe] Unity lens category icons need update" [Undecided,New]
[11:39] <sil2100> Thanks!
[12:24] <knome> cjwatson, i hear indicator-sound is still stuck in NEW (re: bug 1048217). any specific reason?
[12:24] <ubot2> Launchpad bug 1048217 in ubuntu "[FFe] Re-introduce indicator-sound-gtk2/ido-gtk2" [Undecided,Triaged] https://launchpad.net/bugs/1048217
[12:24] <jbicha> any idea what this "undefined video mode" error is, it shows up after the isolinux press any key screen but before plymouth starts http://imgbin.org/index.php?page=image&id=9478
[12:25] <jbicha> I started seeing it in images I was building last night, and it's in the daily images today
[12:25] <xnox> jbicha: nope. seen the same thing. File a bug? but not sure which package though.....
[12:26] <cjwatson> knome: not got round to it
[12:26] <cjwatson> I'll sort it out today
[12:26] <knome> cjwatson, ok, cool. just checking :)
[12:26] <cjwatson> jbicha: That message is from the kernel
[12:26] <cjwatson> arch/x86/boot/video.c:332:              printf("Undefined video mode number: %x\n", mode);
[12:28] <cjwatson> knome: currently quite confused in branch hell, https://twitter.com/colmmacuait/status/245834286735974400
[12:28] <knome> cjwatson, strength and honour with that :)
[12:38] <knome> any release team member: can we have an ACK for a UIFe for bug 1043170 (we have our old wallpaper on plymouth, and we're uploading a new wallpaper without tiny dots in the bottom-right corner, since lightdm nor plymouth scales them well)
[12:38] <ubot2> Launchpad bug 1043170 in xubuntu-default-settings "Update Xubuntu wallpaper for Quantal" [High,Fix released] https://launchpad.net/bugs/1043170
[12:41] <knome> correction: plymouth has the new wallpaper too, only-ubiquity doesn't. so we need to change the wall on lightdm and plymouth to dotless, and replace the only-ubiquity with a new one.
[12:42] <knome> we'll take care of any screenshots that might have slipped in official docs or so, but i hardly think that has happened :)
[12:46] <cjwatson> knome: Ack.
[12:46] <knome> cjwatson, thanks
[12:52] <knome> ok, we need another UIFe to upload our installer slideshow; we've dropped gnumeric from our default seed and we need to change our "office" slide: bug 1049658
[12:52] <ubot2> Launchpad bug 1049658 in ubiquity-slideshow-ubuntu "[Xubuntu] Office slide needs to be updated" [Undecided,New] https://launchpad.net/bugs/1049658
[12:53] <Laney> knome: you should be subscribing the release team
[12:54] <Laney> pinging on IRC isn't the most efficient method
[12:54] <knome> subscribed
[12:54]  * Laney blinks at the amount of Unity exception requests
[12:55]  * knome is happy xubuntu doesn't have loads (this time)
[12:55] <knome> (maybe)
[12:55] <knome> :P
[12:55] <knome> well, that should be it really
[12:56] <knome> post-beta1 cleanup
[12:56] <knome> while we didn't even have beta1 ;)
[12:56] <Laney> do you have working images now?
[12:56] <knome> i'm told we have, but i haven't had time/been able to confirm that myself
[12:56] <Laney> cool
[12:57] <knome> yeah, there's still some hope...
[13:50] <skaet> SpamapS,  looks like precise-proposed just got flooded with translations.   Could you see if you can get it sane?
[14:13] <mvo> could someone from the release team please look at #1035207 ? its a FFe and its open for some days already and it would be great to get feedback on it
[14:13] <stgraber> bug 1035207
[14:13] <ubot2> Launchpad bug 1035207 in aptdaemon "[FFe] passwordless install of webapps (based on repo whitelist)" [High,In progress] https://launchpad.net/bugs/1035207
[14:18] <stgraber> mvo: when would this be uploaded?
[14:19] <mvo> stgraber: once I get a approval :)
[14:19] <stgraber> mvo: ok, and all of mdeslaur's concern are addressed by what you're planning on uploading?
[14:22] <mvo> stgraber: I think so,  I can double check with him
[14:22] <mvo> stgraber: or you can mandate that he approves in addition whatever is easier
[14:24] <stgraber> mvo: gave a conditional +1
[14:35] <mdeslaur> stgraber, mvo: I've commented in the bug, the aptdaemon part is fine, as it doesn't contain the whitelist file itself
[14:36] <mvo> mdeslaur: \o/
[14:36] <mvo> thanks
[14:36] <mdeslaur> np
=== ken__ is now known as kenvandine
[15:29] <mterry> Hello!  John Lea requested a few UI changes to the greeter for 12.10.  It's 4 changes, you can see them linked from bug 1049231.  I've got a test package in a PPA (linked from that bug too).
[15:29] <ubot2> Launchpad bug 1049231 in unity-greeter "[UIFe] The gap between the user name and password entry is too large in the greeter" [Undecided,New] https://launchpad.net/bugs/1049231
[15:30] <ogra_> i guess by that time you should talk to the doc team too ... screenshots etc
[15:32] <mterry> ogra_, shouldn't I get UIFe approval first, before bothering them?
[15:32] <ogra_> well, doesnt UIFe involve talking to them ?
[15:32]  * ogra_ isnt sure
[15:32] <mterry> jbicha, ^ any comment on the above 4 greeter changes linked to that bug
[15:32] <Laney> yes, you should mail them first
[15:33] <mterry> Laney, ah first...  I thought after
[15:33] <dobey> infinity: have attached new package files to https://bugs.launchpad.net/ubuntu/+bug/1047606
[15:33] <ubot2> Launchpad bug 1047606 in Ubuntu Quantal "[needs-packaging] [FFe] [UIFe] ubuntuone-client-data" [Wishlist,New]
[15:33]  * ogra_ thought at the same time :)
[15:33] <Laney> https://wiki.ubuntu.com/FreezeExceptionProcess#UserInterfaceFreeze_Exceptions
[15:33]  * Laney eyes the number of unity changes
[15:34] <Laney> s/changes/exceptions/
[15:34] <infinity> dobey: Just go ahead and upgrade it, I can review it from the NEW queue.
[15:34] <infinity> dobey: s/upgrade/upload/
[15:34]  * infinity needs coffee.
[15:34]  * TheLordOfTime gives infinity coffee
[15:34] <TheLordOfTime> :p
[15:34] <dobey> infinity: i am not motu, so i can't upload it?
[15:35] <infinity> dobey: Oh, derp.  Okay, I'll have a look at it and sponsor it if it looks sane.
[15:35] <dobey> infinity: great, thanks
[15:47] <mterry> Laney, ogra_: OK, ubuntu-doc posting linked to in main UIFe bug
[15:48] <ogra_> :)
[17:14] <infinity> stgraber: queuebot appears to be having a hissy fit parsing the queue again, while I'm accepting a mess of things.
[17:14] <infinity> stgraber: (I'm accepting langpacks, it's flipping out about.. Everything else)
[17:15] <infinity> I got all excited that maybe someone had reviewed and accepted eglibc. :P
[17:16] <stgraber> infinity: killed for now
[17:17] <stgraber> infinity: that's really weird, I'm not getting any traceback on queubot's side, so it looks like it's just getting partial data from Launchpad when the queue changes while it contains a lot of entry
=== dpm is now known as dpm-afk
[17:18] <infinity> stgraber: Yeah, I wasn't implying that it was necessarily queuebot's "fault", it may well be the API giving you lousy results.
[17:23] <infinity> stgraber: All done, you can let it back in.
[17:34] <skaet> infinity,  re: we'll need to double check with dpm-afk on those translations before they are moved from precise-proposed to -updates.   From discussions I had with him earlier today,  he was surprised that they were there,  and was investigating.
[17:35] <skaet> SpamapS ^
[17:35] <infinity> skaet: We require some sort of manual verification before they move to -updates anyway, so this isn't new.
[17:36] <infinity> skaet: But if the whole upload was a mistake in general, we can also just remove them from -proposed.
[17:36] <skaet> infinity,  yup.   just wanted it visible in the channel that there was some questions about them.
[17:36] <SpamapS> ACK
[17:36] <skaet> :)
=== henrix is now known as henrix_
[18:15] <plars> Daviey: ping
[18:16] <Daviey> plars: HELLO!
[18:16] <plars> Daviey: ubuntu-server doesn't seem to be installable with 128M currently, lots of ooms, trying 256M now which seems to get further, but hitting unmet deps when trying to install the kernel headers so it doesn't finish
[18:16] <Daviey> that is less than cool.
[18:17] <Daviey> ah
[18:17] <plars> I can do some bisection to find a number in the middle if you think it's worth it
[18:17] <Daviey> I suspect 12.10 has higher requirements than 12.04 had, due to the squashfs changes.. but I haven't tested.
[18:18] <Daviey> plars: Well, currently I have no data on what to recommend for 12.10.. so that would be helpful.
[18:19] <Daviey> plars: what image failed to install due to headers?
[18:19] <plars> Daviey: 20120912
[18:19] <plars> current
[18:19] <Daviey> damn
[18:20] <plars> Daviey: with 128 it seems to get stuck around running partman
[18:20] <Daviey> I'm concerned that it workjed in Jenkins
[18:20] <Daviey> https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-server-amd64_default/
[18:20] <Daviey> Oh!  This only happens with lowmem?
[18:21] <plars> Daviey: yes, was about to say... I was running with 256 when I hit that
[18:21] <plars> but there was no oom
[18:21] <Daviey> plars: can you automate testing different values?
[18:22] <Daviey> or rather, script it?  It would be good to add to Jenkins long term, when we have a settled figure
[18:22] <plars> Daviey: not easily at the moment, mostly due to my own unfamiliarity with the automation at the moment, but it's not hard to try
[18:22] <Daviey> plars: Have you toyed with UTAH?
[18:22] <plars> Daviey: what I'm working on at the moment is a test for the minimum supported system requirement
[18:23] <plars> Daviey: so that's the end goal, but my branch of ubuntu-server-iso-testing with a couple of changes in place to do that with 128m seemed to be getting stuck so I tried it locally
[18:23] <xnox> plars: Daviey: did you set lowmem bootime option to the debian-installer?
[18:23] <plars> Daviey: I thought what you were requesting was an ad-hoc script to go test with 1M increments or something
[18:23] <xnox> ... although 128MB doesn't sound that lowmem to me...
[18:23] <plars> xnox: I'm just booting with kvm -m ### at the moment
[18:24] <Daviey> plars: there is a kernel command line option called lowmem
[18:25] <plars> hmm.. hadn't heard of it, I found https://help.ubuntu.com/community/Installation/LowMemorySystems but oddly it doesn't seem to mention it
[18:25] <Daviey> I don't think it will change anything TBH
[18:26] <Daviey> jamespage: do you have thoughts on using UTAH for automated min memory spec testing?
[18:26]  * xnox has no clue what it actually does. I was just poking installer boot options once I found it
[18:27] <plars> Daviey: I'll be looking into that too, but I haven't really had a chance to look into utah much yet, and we aren't converting to it in the lab until after quantal is done
[18:28] <jamespage> Daviey: possible definately
[18:28] <jamespage> if it can be preseeded then I think we can use a minimal KVM configuration to test it
[18:28] <plars> Daviey: at the moment, my bigger concern is making sure that we have 1. correct values for minimum system requirements, and 2. that we test them with current infrastructure, then that we get it working with utah so that we are ready for next cycle
[18:28] <Daviey> jamespage: certainly indefinitely ?
[18:28] <plars> that's exactly what I'm doing right now with ubuntu-server-iso-testing
[18:29] <jamespage> my only concern would be that squeezing the utah stuff into a minimum spec KVM might be to much
[18:29]  * Daviey has NFI ;)
[18:30] <plars> Daviey: TBH, that's a concern for tomorrow, for today I'd rather stick to - should 128 really be the minimum? or should it be extended?
[18:30] <Daviey> plars: Yah
[18:32] <plars> Daviey: and skaet sent me to ask you on that
[18:34]  * skaet nods
[18:34] <TheLordOfTime> where do i ask questions about the SRU docs?
[18:35] <Daviey> TheLordOfTime: here would often be ok, depending on traffic
[18:35] <Daviey> otherwise #ubuntu-deverl
[18:35] <Daviey> err, -devel
[18:35] <Daviey> plars: I think 192MB would be a more reasonable minimal TBH
[18:36] <TheLordOfTime> https://wiki.ubuntu.com/StableReleaseUpdates#sun-java.2A  <-- isn't this incorrect?  i thought sun-java* were removed after 11.04 (it says the binaries are still shipped in multiverse)
[18:36] <plars> Daviey: that was going to be the next thing I would try :)
[18:37] <Daviey> plars: In Lucid timeframe, we decided to switch the cloud images smallest option from 128 to 192, due to issues (bug 544292).. But that was for a running machine, rather than the installer - which i'd expect to be more intensive TBH
[18:37] <ubot2> Launchpad bug 544292 in eucalyptus "Increase m1.small memory to 192 MB" [Wishlist,Fix released] https://launchpad.net/bugs/544292
[18:37] <plars> Daviey: unless you said "no, 128 is it, file a bug if it ooms with 128M"
[18:37] <plars> Daviey: yeah, it couldn't be serving *too* much if di was the most intense thing it ever ran
[18:38] <Daviey> TheLordOfTime: i believe you to be correct.
[18:39] <Daviey> plars: well, from my experience, a high proportion of servers sit near idel.. The 'expensive' time is install & boot, as it's actually being hammered.
[18:39] <TheLordOfTime> Daviey:  iirc my 11.04, that was the last version to ship a sun java 6 version, but i may be wrong on that.  it was somewhere around there that occurred
[18:40] <Daviey> jamespage / doko: You are more familiar with this i suspect.. ( TheLordOfTime's issue )
[18:40] <TheLordOfTime> its more of a documentation issue, rather than package issues, but hey, i notice random things like this ;)
[18:40] <micahg> 8.04 is the only repo left with java in multiverse
[18:41] <TheLordOfTime> micahg:  then the documentation on SRU special cases needs changing, it says 9.04 and later have binaries in multiverse
[18:41] <micahg> the wiki is correct though for WIW
[18:41] <TheLordOfTime> it is?
[18:41] <micahg> 8.04 doesn't have desktop support any more thugh
[18:41] <micahg> *though
[18:42] <TheLordOfTime> so when 8.04 goes EOL, then the docs will probably need revising, I assume.
[18:42] <micahg> yeah
[18:42] <micahg> TheLordOfTime: it says before 9.04 had them in multiverse
[18:43] <TheLordOfTime> micahg:  ah, i see, i misread.
[18:43] <micahg> well, technically they were in multiverse until 9.10
[18:43] <micahg> what it says is the ones in multiverse before 9.04 were the only ones
[18:44] <TheLordOfTime> I see, I misread.
[18:44] <TheLordOfTime> thanks for clearing that one up :P
[18:45] <plars> Daviey: oh, I see the reason for the headers failing... it's not an unmet dep... looking further up, it ran out of space with 1G, though to be fair let it do a swap partition.  Let me redo that
[18:45] <plars> no swap on this one, and I'll make sure that goes in the preseed
[18:45] <TheLordOfTime> unrelated, but what's the general turnaround time for getting an SRU from -proposed to -updates when verification-done is tagged on the bug(s) that'd be fixed by the SRU?
[18:46] <micahg> TheLordOfTime: after ~7 days of being in -proposed
[18:47] <Daviey> TheLordOfTime: is there a particular one annoying you?
[18:47] <TheLordOfTime> Daviey:  not annoying me per se, might be annoying some people, but its not high-priority
[18:47] <TheLordOfTime> so no need to poke it up, was curious about the general turnaround time is all
[18:47] <TheLordOfTime> :)
[18:48] <SpamapS> hrm.. what happened to grub2 1.99-21ubuntu3.2 ?
[18:48] <SpamapS> Just accepted 3.3 but now noticing 3.2 is not in -updates or -proposed
[18:49] <micahg> Deleted in precise-proposed on 2012-06-06 (Reason: wrong solution to #1009294)
[18:49] <SpamapS> Ok, so the next upload should be based on 3.1 not 3.2?
[18:50]  * SpamapS notes that UDD should be banished from -updates and -proposed as its likely what caused this
[18:50] <micahg> well, I would think reverting 3.2 and then adding on top
[18:50] <SpamapS> I hit accept before thinking about what was between 3.1 and 3.3 ... now I'm thinking that should be rejected..
[18:51]  * micahg defers to SRU people like infinity
[18:51] <SpamapS> I think I need to also delete this one from -proposed, and ask the users to base off -updates and fix lp:ubuntu/precise-proposed/grub2
[18:52] <micahg> I wouldn't manually "fix" the UDD branch
[18:52] <Daviey> I don't think it's a big deal, based on 3.1 OR 3.2+reversed-patch->&changelog explaining reversal.. Really either way comes down to a changelog message.  Providing it doesn't include something that clearly sucked.
[18:52] <SpamapS> Daviey: 3.3 includes 3.2
[18:52]  * micahg would think you now need a 3.4 which includes the reversion of 3.2 and -v on what's in updates
[18:52] <SpamapS> actually I like that solution better
[18:53] <SpamapS> "fail forward" :)
=== dpm-afk is now known as dpm
[18:53] <Daviey> SpamapS: Have you accepted the binaries or just the sourcE?
[18:53] <Daviey> uhh
[18:53] <SpamapS> Daviey: there's no accepting of binaries AFAIK .. unless you mean moving to -updates. I just accepted the source into -proposed.
[18:54] <Daviey> yeah, iw as being daft. Sorry.
[18:55] <SpamapS> I'll just upload a reverted 3.2, 3.4, myself
[18:55] <micahg> yeah, if you hurry, it'll supersede the amd64 and powerpc builds
[18:56] <micahg> hurry ~= 15-20 min :)
[19:00] <dobey> infinity: i guess you didn't find anything to complain about with ubutnuone-client-data? :)
[19:01] <infinity> dobey: No, it's just been a busy morning.  I'll get to complaining (or uploading) later.
[19:05] <TheLordOfTime> infinity:  mind a privmsg?
[19:06] <infinity> TheLordOfTime: No need to ask.
[19:26] <balloons> njin found this bug -- not sure how many images are affected by it just yet. But the daily images just flat out are not booting
[19:26] <balloons> https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1050006
[19:26] <ubot2> Launchpad bug 1050006 in casper "Undefined video mode number: 0" [Undecided,Confirmed]
[19:33] <jbicha> balloons: yeah, I reported bug 1049650 earlier today
[19:33] <ubot2> Launchpad bug 1049650 in linux "Regression: "Undefined video mode" with 3.5.0-14.16" [Medium,Incomplete] https://launchpad.net/bugs/1049650
[19:33] <jbicha> after the 30 second wait, the image did seem to boot for me
[19:34] <kanliot> If there is no documentation for mode 0, how do you know it is a bug?
[19:38] <balloons> jbicha, ok, let me see
[19:40] <balloons> ahh.. new background ;-)
[19:51] <SpamapS> would appreciate it if somebody else on the SRU/release team sanity checked my grub2 upload to precise-proposed
[19:56] <infinity> SpamapS: Wait, that's a revert of a revert?
[19:56] <infinity> SpamapS: My head hurts.
[19:57] <TheLordOfTime> heh
[20:00] <infinity> Or... A revert of a revert of a revert.. I think.
[20:02] <SpamapS> infinity: mine too
[20:03] <SpamapS> http://www.youtube.com/watch?v=VW27kyh7PVM
[20:03] <infinity> SpamapS: Diffing from 3.1 to 3.4 makes it obviously correct, accepted.
[20:03] <SpamapS> infinity: ty
=== medberry is now known as med_
[22:50] <cjwatson> Daviey,plars: the installer includes a "lowmem" package which has experimentally-determined values for memory limits at various stages; tweaking those will change the behaviour
[22:50] <cjwatson> so you shouldn't assume that current memory behaviour in d-i is immutable
[22:50] <cjwatson> There's specific advice in lowmem/README on how to update those levels
[22:50] <cjwatson> And the hacks that are currently performed in lowmem situations
[22:52] <cjwatson> I would also say that a failure at 128M represents a significant change only over about two years well in excess of my expectations of natural drift, so deserves investigation in its own right
[23:06] <Daviey> cjwatson: wait, it's in limits of your expectations of natural expansion ?
[23:08] <infinity> Daviey: That's not how I'd read "well in excess of my expectations of natural drift".
[23:11] <cjwatson> Daviey: I am surprised that d-i fails at 128M, and think that's worth investigating in itself.
[23:11] <Daviey> ok, thanks. wanted to check.
[23:12] <cjwatson> I don't think squashfs is necessarily all that directly related, since the high-water-mark for d-i memory use is supposed to be immediately before swap is enabled.
[23:12] <cjwatson> Which is before we mount the squashfs and start trying to copy files off it.
[23:13] <Daviey> well, i'll see what plars results are.. but also might try to gauge the entire process.
[23:14] <cjwatson> As I say, the README file in the lowmem source package has specific advice on measuring this, which is likely to be better than what you or I or plars would come up with off the top of our heads.
[23:14] <cjwatson> Because it's advising on the particular points that affect the behavioural changes in lowmem.
[23:16] <plars> Daviey, cjwatson: from my initial 10 sec skim of a checkout of lowmem, the readme seems to suggest that low memory conditions should be detected automatically, so thee shouldn't be anything for me to adjust for enabling this right?
[23:16] <plars> I'm booting in a VM with 128M
[23:16] <plars> Daviey: oh, also I did some experiments in jenkins earlier and even with 196M, I was getting lots of OOMs during installation, with 256M too
[23:17] <plars> need to look into that a bit more still, will try to do that later this evening if I have time
[23:18] <cjwatson> plars: Indeed, normally.  The point of the lowmem= option is to find out easily whether the additional optimisations carried out by lowmem would help in a particular case.
[23:19] <Daviey> plars: is this a heavily loaded host, where the VM is running ?
[23:19] <plars> Daviey: not that I'm aware of, but I would have to check with retoaded to be sure
[23:19] <Daviey> plars: would be interesting to see that
[23:20] <Daviey> plars: do you know what machine it's running on?
[23:20] <cjwatson> lowmem=1 and lowmem=2 enable progressively more low-memory optimisations.
[23:21] <cjwatson> (These are also automatically enabled below certain hardcoded thresholds.)
[23:21] <plars> Daviey: wazn
[23:22] <plars> Daviey: my job was the only thing running at the time as far as jenkins is concerned, but I can't speak to what else might be going on with that system
[23:23]  * plars has to go afk for a bit, will try to look into it a bit more later