[00:02] <phillw> oooh, yaboot?!
[00:12] <hyperair> hmm? i thought banshee was going to wait until next week to be approved?
[00:13] <cjwatson> Urgh, who accepted banshee?
[00:13] <cjwatson> Thanks for wasting my time.
[00:16] <cjwatson> hyperair: Unfortunately there's no way to leave notes in the queue for people who don't read IRC before processing it.
[00:28] <phillw> cjwatson: thanks for the email, I have replied.
[08:02] <iulian> olli: OK, I will try that fix later on today (I have to leave quite soon). You can check on LP to see if libunity-webapps had an upgrade or something (or #ubuntu-unity, they should know).
[08:03] <Laney> hmm
[08:03] <iulian> olli: And regarding the version of bamfdaemon - I've got 0.3.0-0ubuntu2 installed.
[08:03] <Laney> should we decron and do a full image set to b2?
[09:04] <jamespage> all node related syncs are for the switch from /usr/bin/node -> /usr/bin/nodejs in Debian
[09:05] <jamespage> (I'll get that added to release notes as well)
[09:22] <psivaa> there are two OVERSIZED entries in cdimage.u.c for quntal amd64 and amd64+mac, i guess this is not so alarming since there is no cd support?
[09:23] <xnox> psivaa: depends, i thought the OVERSIZED check has been adjusted for the new target size.... therefore it can be alarming
[09:24]  * xnox now ponders about MB MiB units....
[09:25] <psivaa> xnox, both are 764 and 765 M's , but i suppose for quantal 800M is allowed?
[09:25] <xnox> psivaa: the text of the warning is miss leading. See that i386 751MB doesn't have warning.
[09:26] <xnox> psivaa: yeah 8000 but base 2 or base 10?
[09:26] <xnox> psivaa: yeah 800MB but base 2 or base 10?
[09:27] <Laney> http://www.wolframalpha.com/input/?i=800+MB+in+MiB
[09:27] <Laney> seems likely
[09:27] <psivaa> xnox, the size is less than 800M base 2
[09:28] <tumbleweed> psivaa: otherwise known as 800MiB
[09:28] <xnox> Laney: I like that link! Didn't know WOlfram did that!
[09:28] <Laney> wolfram does all
[09:28] <tumbleweed> or jsut use GNU units
[09:29] <xnox> Laney: so the text of the warning should be modified to say "above target size %s" and ideally substitute that value.
[09:30] <xnox> or just leave at above target size.
[09:30] <xnox> and it does look like amd64 is oversized =(
[09:31] <psivaa> tumbleweed, i see :)
[09:31] <psivaa> xnox, i guess so there will be something done to trim it?
[09:31]  * xnox is  not on release team =)))))
[09:31] <ogra_> xnox, just take a look at debian-cd :)
[09:32] <ogra_> it has (($foo * 1024 *1024)) everywheer
[09:33] <xnox> ogra_: I like $foo =)
[09:33] <ogra_> heh
[09:33] <psivaa> lol
[09:33] <xnox> bytes is so unambigious.
[09:45] <psivaa> ogra_, i am just wondering if those two oversized images will be rebuilt soon, will they :)?
[10:26] <jamespage> Daviey, I have a new upstream bugfix release prepped for ceph - OK to upload now or would you prefer if I waited until after beta-2?
[10:26] <jamespage> its seeded but does not ship
[10:26] <ogra_> psivaa, no idea
[10:27] <psivaa> ogra_, ok, thanks
[10:27] <psivaa>  size change may not affect our test results too much, but just wanted to confirm, we are continuing the testing on those images
[10:28] <ogra_> i would assume so, but for respins better wait for someone from the release team
[10:29] <cjwatson> psivaa: the oversized warning is wrong; for now, ignore it
[10:29] <cjwatson> haven't got round to adjusting those limits
[10:29] <Daviey> jamespage: please upload, that will be fine.
[10:30] <cjwatson> it won't fit on a CD, but that was what was agreed for 12.10
[10:30] <ogra_> it was 1G now, wasnt it ?
[10:30] <cjwatson> 800M
[10:30] <ogra_> oh, k
[10:31]  * jamespage was wondering where nodejs had got to
[10:31] <jamespage> Daviey, ack - ta
[10:37] <psivaa> cjwatson, ok thanks,that helps
[10:40] <Daviey> jamespage: why the Architecture s/linux-any/any/ ?
[10:40] <xnox> cjwatson: "Sep 04 20:59:28 <stgraber>	plars: the limit was already changed by slangasek" no other sources. Note that amd64[+mac] have oversize markers, but i386 does not. Although all three are >>705MB but i386 is below the magical 762.9MiB (as per Laney's link above)
[10:40] <cjwatson> xnox: the code is authoritative :-)
[10:40] <xnox> the warning text is misleading though =)
[10:41] <cjwatson> xnox: sod the warning text, the limit is wrong
[10:41] <xnox> cjwatson: well, I either have no access or don't know where it is =)
[10:41] <cjwatson> lp:ubuntu-cdimage
[10:41] <xnox> ah, ok.
[10:42]  * ogra_ still hasnt got his head arund all that python stuff :)
[10:42] <xnox> "This branch may be out of date, because Launchpad has not been able to access it since 2012-08-17."
[10:42] <cjwatson> lib/cdimage/tree.py:DailyTreePublisher.size_limit in this case
[10:42] <cjwatson> oh damn
[10:42] <cjwatson> well you're out of luck until I switch it to fully hosted, sorry
[10:42] <cjwatson> take my word for it for the moment :)
[10:43] <jamespage> Daviey, actually hold fire - its in the queue twice - I think SpamapS may have already done this
[10:43] <xnox> cjwatson: the code is authoritative :-)
[10:43] <ogra_> lol
[10:43]  * xnox "a wise man taught me that"
[10:43] <cjwatson> http://paste.ubuntu.com/1224250/ then
[10:44] <cjwatson> I mean, it has 800000000 there
[10:44] <cjwatson> but that obviously isn't working
[10:44] <ogra_> nah, you could just have made that up in pastebin *g*
[10:44] <Daviey> jamespage: SpamapS's seem to include an additional fix?
[10:44] <cjwatson> I'll look at it when I have a chance ...
[10:44] <cjwatson> oh, wait
[10:45] <cjwatson> my apologies, I'm completely wrong, I was misled by the units on cdimage.ubuntu.com
[10:45] <cjwatson> ok, yeah, in that case we *do* need to do something about the oversizedness and you're right it's just the warning text
[10:45] <cjwatson> sigh.  coffee.
[10:45] <Laney> what did we decide the limit was?
[10:46] <cjwatson> 800MB (decimal)
[10:46] <Laney> then yeah
[10:46] <cjwatson> though I wonder if that should be 800 * 1024 * 1000 * 1000
[10:46] <cjwatson> err, 800 * 1024 * 1000
[10:46] <jamespage> Daviey, yes he did - but he also did not do the python-ceph linux-any -> all change
[10:46] <cjwatson> since that's what "decimal" MB usually means
[10:46]  * jamespage scratches his head
[10:46] <Laney> You have: 800 MB
[10:46] <Laney> You want: bytes * 8e+08
[10:46] <Laney> that pasted well
[10:47] <cjwatson> But decimal MB per disk manufacturers usually means 1000s of KiB
[10:47] <cjwatson> Because the world sucks
[10:47] <Daviey> jamespage: but why did you do that change?
[10:47] <jamespage> Daviey, didrocks and I discussed it after the last set of MIR actions
[10:47] <cjwatson> slangasek: ^- should we bump the size limit to 800 * 1000 * 1024, do you think?
[10:47] <xnox> we agreed on a number 800 but not the units.... *sigh*
[10:47] <Daviey> jamespage: did he say why
[10:48] <Daviey> jamespage: It seems an odd request..
[10:48] <jamespage> Daviey, the package has no specific architecture requirements in Ubuntu
[10:48] <cjwatson> hmm, https://en.wikipedia.org/wiki/Megabyte alleges that disks are actually pure powers of 10
[10:48] <cjwatson> not sure that matches my experience but maybe I can't be bothered to check now
[10:49] <xnox> cjwatson: I'm guessing what matters is that we fit on the common 1GB usb-sticks when unpacked using usb-creator.
[10:49] <jamespage> Daviey, suggest that you reject my upload and I'll catchup with SpamapS when he starts later today
[10:49] <Daviey> jamespage: considering we only release linux.. linux-any == any.. So i'm suprised it was made a fuss.
[10:49] <xnox> cjwatson: as we target typical media sizes, not numbers.
[10:49] <jamespage> Daviey, it was not 'fuss' - it was a suggestion for when it was next uploaded...
[10:50] <Daviey> jamespage: ah, ok.
[10:50] <Daviey> Did someone else just reject that?
[10:50] <cjwatson> xnox: not that simple because the 800MB was known to be an artificial target for the purposes of controlling the rate of bloat
[10:50] <cjwatson> Anyway, easy fix is drop a langpack from amd64
[10:50] <cjwatson> I'm doing that now
[10:51] <Daviey> who did that? ^
[10:51] <xnox> cjwatson: yeah, cause "disk manufacturers" 1GB gives me 953.6 MB
[10:51] <cjwatson> Daviey: a phantom queuebot bug - it's still in unapproved
[10:51] <Daviey> cjwatson: no, it was uploaded twice
[10:51] <cjwatson> oh
[10:52] <Daviey> cjwatson: I just tried to reject, and was told it was already rejected by LP.
[10:53]  * cjwatson accepts alsa-tools to give the publisher something to do along with his seed change
[10:54] <xnox> cjwatson: \0/
[12:23] <xnox> when do we start milestone images publishing?
[12:23] <xnox> Today or Tuesday?
[12:23] <Laney> when we get a Conrad
[12:24] <xnox> Laney: I see.
[12:24]  * xnox off to do a quick ubiquity upload then.....
[12:24] <Laney> ...
[12:25]  * xnox is only trying to annoy Laney =)
[12:25] <Laney> it's all good fun eh
[12:25] <xnox> Laney: it's to fix top errors.ubuntu.com crasher
[12:26] <xnox> bug 1027648
[12:26] <ubot2> Launchpad bug 1027648 in ubiquity "ubiquity crashed with ValueError in command(): I/O operation on closed file." [High,Confirmed] https://launchpad.net/bugs/1027648
[12:27] <Laney> great
[12:27] <Laney> let's see it!
[12:27] <xnox> https://code.launchpad.net/~xnox/ubiquity/fix-value-errors/+merge/123727
[12:27] <Laney> I mean in the queue :P
[12:28]  * xnox mutters something incomprehensible in Russian and mentions Laney three times
[12:28]  * Laney assumes that they are nice words
[12:28] <cjwatson> any chance we could get the yaboot-installer fix in the queue, if we're respinning for ubiquity anyway?
[12:29] <cjwatson> not mandatory but might help the powerpc folks
[12:29]  * xnox waits
[12:29] <Laney> I'll look after lunch
[12:29] <Laney> at both
[12:29] <Laney> unless someone else gets there first
[12:29] <xnox> Laney: cause yaboot needs to be included in the ubiquity upload.....
[12:29] <Laney> oh, like that is it?
[12:29] <xnox> Laney: due to the funny way we repackage udebs in ubiquity.
[12:30] <Laney> fine, sessioninstaller can wait
[12:30] <cjwatson> well, yaboot-installer does, not yaboot
[12:31] <cjwatson> xnox: I tried having the udeb-producing source packages also spit out debs, and it was indescribably painful to maintain so I stopped :-)
[12:31] <cjwatson> believe me this sucks less
[12:31] <ogra_> ls ../
[12:31] <ogra_> bah
[12:31] <xnox> cjwatson: I totally agree. And Build-using: X is also path to fail.
[12:32] <cjwatson> Build-Using is only useful if you can get the binaries in a useful way
[12:34] <xnox> cjwatson: Build-Using should get you `apt-get source $pkgs` unpacked as tarball components. And auto-substitute the version numbers in the control file. Otherwise it's just dfsg metadata hack on top of the real problem: cannot build-dep on a source package instead of binary package.
[12:34] <xnox> which totally makes sense for all the toolchains and compilers we have in the archive.
[12:36] <cjwatson> I don't agree
[12:36] <cjwatson> It's useful to have a way to tell the archive "don't garbage-collect this source"
[12:36] <Laney> accepted, to lunch
[12:36] <cjwatson> Build-deps wouldn't help for that
[12:37] <xnox> Laney: thanks.
[12:37] <xnox> cjwatson: ok. I only think with "i want to bootstrap a new arch" hat, cause I don't have "archive admin" hat yet ;-)
[13:07] <jamespage> ^^ buddycloud-server was (hopefully) the last sync with Debian due to the node -> nodejs binary name migration
[13:37] <mterry> ^ that's the last bit of the webapps feature story
[13:39] <jbicha> so even when we get webapps working for quantal, it'll just be fancy bookmarks since we're not doing any chromeless mode?
[13:41] <mterry> jbicha, fancy bookmarks, sure.  That can tell when they are open
[13:42] <mterry> I did not want to advocate for them squeezing in more features  :)
[13:43] <jbicha> it just doesn't seem very useful yet, especially since we have the shopping integration in the dash home & the music lens
[13:43] <Laney> so, one of these packages is the one that gives us the new launcher webapp icons?
[13:44] <jbicha> & the feature still has the disappearing/duplicate icons problem
[13:44] <mterry> Laney, new launcher webapp icons are in unity-webapps-common.  They are added to launcher by default by unity, if they are present.  The recent ubuntu-meta update just puts the packages in the image
[13:44] <mterry> jbicha, U1 is still a server side fix coming
[13:44] <jbicha> mterry: are the 2 Amazon launchers & 2 U1MusicStore launchers in the dash known yet
[13:45] <mterry> jbicha, amazon should only have one icon at a time, but it does hide and reappear
[13:45] <mterry> jbicha, they are working on a fix for that
[13:45] <mterry> jbicha, and U1 team is working on theirs
[13:45] <mterry> jbicha, but yeah, for a feature that will cause more commercialization concerns, I wish it at least worked flawlessly  :-/
[13:46] <stgraber> cjwatson: jbicha just noticed that gcompris somehow got into the ubuntu-desktop packageset when it's a universe package only seeded in edubuntu and was in the edubuntu packageset for 12.04. Any idea of what happened there?
[13:50] <cjwatson> good question ...
[13:51] <ogra_> it moved secretly to restricted ? :P
[13:51] <ogra_> ah, no, that would have just ignored it
[13:51] <cjwatson> hmm, probably something to do with the weirdness around Edubuntu DVD seeding
[13:51] <cjwatson> Let me see if that can go away nowadays
[14:06] <xnox> Laney: ubiquity ^^^ =) to go with yaboot and webapps stuff
[14:06] <Laney> great
[14:07] <cjwatson> I'd like to do the accept on that if you don't mind
[14:07] <cjwatson> as a test case for process-accepted-bugs-job
[14:11] <Laney> go for it
[14:19] <skaet> olli, mterry, popey - what is the status with the fix to libunity-webapps?    Is there anything ready to be tried?
[14:20] <mterry> skaet, no.  Are you talking about the Amazon launcher?
[14:21] <olli> skaet, the bamf/window management issues seems to be resolved
[14:21] <skaet> mterry,  no window management/missing appmenu function.
[14:22] <skaet> olli,  great.   has something been uploaded?   if so, details please.
[14:22] <Laney> err
[14:22] <Laney> those launchers are literally just opening tabs in my browser
[14:22] <cjwatson> process-accepted-bugs-job: hooray, glorious success
[14:22] <Laney> is that right?
[14:22] <mterry> Laney, the chromeless mode got dropped for time reasons
[14:22] <Laney> I was under the impression it would still be a separate firefox window
[14:23] <mterry> Laney, so yeah, they open tabs, and are supposed to reflect the open/closed status of the tab
[14:23] <cjwatson> bug 745799 should no longer be an issue through this freeze; assuming that holds, I'll remove all the obsolete code and close that bug on Friday
[14:23] <ubot2> Launchpad bug 745799 in launchpad "DistroSeries:+queue Timeout accepting packages (bug structural subscriptions)" [Critical,In progress] https://launchpad.net/bugs/745799
[14:23] <cjwatson> or thereabouts
[14:23] <mterry> Laney, that was the grand vision, and will be in 13.04
[14:23] <Laney> OK I could "quit" it
[14:24] <olli> skaet, I don't know what resolved it, asked here yday - I have libunity-webapps0-2.3.8-0ubuntu2 which provides the missing *so.0, but the changelog doesn't hint at any update
[14:24] <olli> I was not able to verify what happened
[14:24] <Laney> ... would it be controversial to suggest delaying installing this by default?
[14:24] <olli> happened as in what fixed what I was seeing (I did an update/upgrade)
[14:25] <skaet> olli,  would like make sure we've got fix firmly identified, so we don't get "surprised" later.   I'll update my broken system and let you know what I find.
[14:28] <Laney> hmm.
[14:29] <olli> skaet, willcooke will get in touch with you
[14:30] <Laney> cjwatson: nice one
[14:32] <skaet> olli,  have applied the latest updates,  rebooted machine.   No change in behaviour,  still no menus.
[14:36]  * skaet working with willcooke now
[14:42] <popey> skaet, does a "sudo apt-get install ubuntu-desktop^" (with the hat) pull any missing bits in?
[14:45] <skaet> popey,  yes.   libunity-webapps0 is in that set (with some others)
[14:46] <popey> thats the issue then, something didn't come in or something was removed previously
[14:49] <jbicha> Laney: I'd prefer it wait for 13.04 but I'm of course not RT
[14:49] <plars> mvo: psivaa was just asking me about https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1052605 - is this a problem that really needs to be fixed in precise, for upgrade purposes, or is it strictly quantal?
[14:49] <ubot2> Launchpad bug 1052605 in update-manager "ERROR:root:getListFromFile: no '/usr/share/update-manager/removal_blacklist.cfg' found: exception during Precise to Quantal upgrade on amd64+mac" [High,Confirmed]
[14:50] <xnox> jbicha: http://www.flickr.com/photos/diegoe/4843409030/
[14:50] <xnox> http://blogs.gnome.org/diegoe/2010/07/30/annual-gnome-soviets-meeting/
[14:52] <mvo> plars: quantal is fine I think, but I will double check - in a meeting right now
[14:53] <cjwatson> plars: FWIW the way it works is that we can fix a lot of upgrade bugs of this type just in quantal, because the release upgrader downloads a tarball of upgrade code from quantal as one of the early things it doe
[14:53] <cjwatson> *does
[14:54] <skaet> popey, applied, reboot has menus and proper behaviour again.   Thanks.
[14:55] <skaet> iulian ^ if your system is also still affected....
[14:56] <plars> cjwatson: interesting, do you consider this one critical enough to make a target of opportunity? If it's not a regression, I would think the answer is normally "no", correct?
[14:56] <popey> skaet, yay.. cc: olli ^^
[14:57] <cjwatson> the question of regressions makes less sense for upgrades
[14:57] <cjwatson> and I thought I already made it a target of opportunity by accepting the rls-q-incoming nomination :)
[14:58] <Laney> didrocks: I don't see any sign of the upstream changes in overlay-scrollbar?
[14:59] <didrocks> Laney: really? the previous upload was a native upload, which was wrong, I did a tarball of it and merge-upstream it, let me check
[14:59] <Laney> didrocks: https://launchpadlibrarian.net/117169400/overlay-scrollbar_0.2.16%2Br353-0ubuntu2_0.2.16%2Br356-0ubuntu1.diff.gz
[15:00] <Laney> I see the same when diffing the unpacked source packages manually, just to be sure
[15:01] <didrocks> Laney: but, the upstream changes are in 0.2.16+r356 tarball normally
[15:01] <didrocks> Laney: let me check
[15:01] <didrocks> Laney: maybe the +rev353 naming was wrong
[15:02] <didrocks> Laney: yeah, so they were backported, confirmed in -0ubuntu2
[15:02] <jdstrand> skaet: hey, so what is the status of getting a bug fix into beta2 right now? I have a fix for ufw (would affect all images). It probably isn't worthy of a respin on its own, but would be nice to have fixed since it contains a fix for a bug found during iso testing
[15:02] <didrocks> Laney: but at least, now, we have a real package with an upstream tarball and packaging change separated
[15:02] <jdstrand> (iso testing from last time)
[15:02] <didrocks> Laney: which wasn't the case before
[15:02] <Laney> didrocks: OK, fair enough, thanks for looking
[15:02] <didrocks> Laney: thanks for checking :)
[15:02] <Laney> we should have it for the Qt fix anyhow
[15:02] <didrocks> Laney: yeah, not sure if you want it for beta2 proper
[15:03] <didrocks> Laney: or just upgrade it afterwards
[15:03] <skaet> jdstrand,  we haven't started spinning the images yet,  so if its safe,  put it on the pad as an opportunity target and go ahead with upload.
[15:03] <jdstrand> skaet: it is low regression potential and passes QRT
[15:03] <didrocks> confirming it's fixing/workarounding the issue
[15:03] <Laney> i'll take it into proposed
[15:03] <didrocks> sounds the safest :)
[15:03] <jdstrand> skaet: ok. where is the pad?
[15:04] <jdstrand> skaet: should this target quantal-proposed or just quantal? (it is a python package with only one build)
[15:04] <skaet> http://pad.ubuntu.com/ubuntu-release
[15:07] <jdstrand> skaet: thanks. added
[15:08] <slangasek> cjwatson, xnox: we did agree on the units, we said 800MB. :)  There was a discussion on list where pitti found that the USB sticks he tested were pure decimal.
[15:08] <cjwatson> OK
[15:09] <slangasek> cjwatson: if we want to fudge to make powerpc fit though, it's not the end of the world
[15:12] <xnox> slangasek: yes, 800MB apart from MB is ambiguous. Are we using "disk-manifacturer's" MB (aka decimal / base 10) or the computer science MB (aka base 2).
[15:12] <xnox> slangasek: in other words can we define the sizes in bytes please =)
[15:12] <slangasek> xnox: it's not ambiguous, we have a Units Policy. :)
[15:13] <xnox> slangasek: yeah, thanks for reminding me about it.
[15:14] <xnox> slangasek: cdimages.ubuntu.com does not compile with the Units Policy.
[15:14] <xnox> slangasek: it uses M when it means Mi and it uses K which doesn't exist (should use Ki)
[15:15] <xnox> ... or I got all of it backwards.
[15:15] <xnox> http://cdimages.ubuntu.com/daily-live/current/
[15:16] <cjwatson> slangasek: powerpc isn't currently oversized
[15:16] <cjwatson> xnox: that's apache's fault and I haven't found a way to do anything about it
[15:17] <cjwatson> P.S. the official hostname is cdimage.ubuntu.com
[15:17]  * xnox blames chromium's auto remembering host names
[15:19] <Laney> iulian: shotwell ^^^ is for you
[15:36] <highvoltage> stgraber: unity is reaaaaly slow on edubuntu on kvm, is that normal and if so, something that should be release noted?
[15:36] <stgraber> highvoltage: slower than on beta1?
[15:36] <tumbleweed> highvoltage: does it at least work?
[15:37] <highvoltage> stgraber, tumbleweed: yes
[15:38] <stgraber> highvoltage: what's your screen resolution in the VM?
[15:38] <stgraber> here it's pretty slow by default but that's because kvm is being weird and sets up the screen at 2360x1770 :)
[15:39] <highvoltage> stgraber: 1024x768
[15:39] <stgraber> hmm, weird. it's reasonably fast here once I get the resolution down to 1280x800
[15:39] <highvoltage> I rebooted into installer only and that's at least a lot better
[15:40] <stgraber> highvoltage: what video driver are you using in kvm and how much memory do you have allocated to the vm?
[15:41] <stgraber> (but yeah, I think Ubuntu should issue a generic, Unity completely sucks in VMs, please use something else kind of warning)
[15:41] <highvoltage> stgraber: cirrus 9mb with 1500MB RAM
[15:41] <highvoltage> (I guess the 9mb video ram is the reason why I don't get a massive default resolution)
[15:41] <stgraber> highvoltage: ok. I'm using vmvga 9MB, also with 1.5GB of RAM
[15:41] <kenvandine> that unity-lens-photos upload is a trivial fix to a crasher that affects 103 people
[15:42]  * xnox ... and me.
[15:42] <Laney> exactly 103!
[15:42] <Laney> :P /me looks
[15:42] <Laney> skaet: Do you fancy considering the seed change?
[15:44] <skaet> Laney,  fancy - no,  but if its fixing crashers, and is safe,  yeah,  rather it in now before we spin images.   Just don't want things to get worse though....
[15:44] <Laney> It's not to fix crashers, it's to seed the packages which bring the webapp launchers in
[15:46] <skaet> Laney,  ok,  yes.
[15:50] <Laney> up to The Public to decide whether this makes things get worse :P
[15:50] <Laney> done
[15:50] <Laney> kenvandine: and yours, thanks for that
[15:51] <kenvandine> thx
[15:51] <Laney> there will be some promoting from -proposed to do before spinning
[15:53] <Saviq> hey, re https://bugs.launchpad.net/ubuntu/+source/ubuntu-font-family-sources/+bug/1048600
[15:53] <ubot2> Launchpad bug 1048600 in ayatana-design "[FFe] Restore "Ubuntu Medium" weights in Ubuntu's binary .deb" [High,Fix committed]
[15:53] <Saviq> I've tracked the Qt bug down and worked around it https://bugs.launchpad.net/ubuntu-font-family/+bug/744812/comments/53
[15:53] <ubot2> Launchpad bug 744812 in ubuntu-font-family-sources "FontConfig/Qt stack choke on Ubuntu Medium font meta-data (No medium in Inkscape and too bold in Qt apps)" [High,Confirmed]
[15:54] <Saviq> it's not a proper fix, 'cause that would break API, and requires work across backends and platforms
[15:54] <Saviq> here's the patch https://launchpadlibrarian.net/117079074/fix_medium_font.diff
[15:55] <Saviq> and packages are built in the mentioned PPA to test the impact
[16:14] <stgraber> skaet: We might have a late edubuntu-live and edubuntu-netboot upload to change our default session on LTSP from Unity to gnome-classic (with fallback to gnome-fallback).
[16:14] <cjwatson> I think I'm going to need to upload for bug 1054323 once I figure out what the problem is
[16:14] <ubot2> Launchpad bug 1054323 in grub-installer "Installer fails at 'grub install dummy' on PowerEdge Hardware in EFI mode" [High,New] https://launchpad.net/bugs/1054323
[16:14] <cjwatson> Quite possibly grub2 rather than grub-installer
[16:14] <Laney> we should probably switch to making images for b2 ...
[16:14] <stgraber> skaet: waiting to hear from highvoltage but considering how little progress the unity team has done on making it working in VMs, it doesn't seem likely we'll be able to ship with it in quantal
[16:15] <skaet> stgraber, ack.
[16:15] <Laney> stgraber: I'll proxy skaet and tell you to put it on the pad :P
[16:15]  * skaet chuckles.   Thanks Laney ;)
[16:16] <stgraber> Laney: yeah, will put a "no need to rebuild for now" note until we know what we'll be doing
[16:16] <skaet> stgraber, is arm going to be available for edubuntu for beta2?
[16:17] <stgraber> skaet: nope, ARM is staying daily-only for 12.10, we won't release it
[16:17] <xnox> stgraber: to be honest all you need to do, is change blur effect to static & disable fade-in / fade-out. And all of those are just compiz settings.
[16:17] <xnox> stgraber: I did that on my machine it's flying fast now.
[16:17] <stgraber> xnox: well, unity doesn't start at all on LTSP, so no
[16:17] <xnox> stgraber: ah
[16:17] <stgraber> and unity explodes in interesting ways when using 16bit color depth
[16:17] <tumbleweed> :)
[16:18] <Laney> skaet: Shall we go ahead and change default_milestone and decron now?
[16:18] <xnox> stgraber: i'd expected to expload in a rather dull way when using 16bit color depth
[16:20] <stgraber> xnox: on 16bit: https://launchpadlibrarian.net/114128260/unity-16bit-quantal.png. It gets worse when you try to actually do something with it (like open a window) :)
[16:20] <ogra_> use the door then :P
[16:21] <ogra_> wow, modern art
[16:23] <skaet> Laney,   please
[16:24] <skaet> (and thanks!)
[16:24] <Laney> skaet: it's alright, I've spotted infinity now :-)
[16:24] <skaet> :)
[16:46] <ogra_> cjwatson, is it normal that there is an amd64.squashfs file at http://cdimage.ubuntu.com/ubuntu-server/daily/current/ ?
[16:47] <njin> bug 1048361
[16:47] <ubot2> Launchpad bug 1048361 in ubiquity "installer stuck in download packages even if not connected or download not selected" [Undecided,Confirmed] https://launchpad.net/bugs/1048361
[16:53] <cjwatson> ogra_: mm, I think probably a weird leftover - removed, thanks
[16:54] <ogra_> cjwatson, so hggdh seems to still see bug 1054143
[16:54] <ubot2> Launchpad bug 1054143 in debian-installer "armhf-omap4: Beta 20120924 server image fails to install with "no kernels found"" [High,New] https://launchpad.net/bugs/1054143
[16:54] <ogra_> and comparing the .list files beween x86 and arm server images i dont see a pool on the arm side
[16:54] <plars> xnox: regarding adding encrypted volumes at install time from ubiquity...
[16:55] <plars> xnox: shouldn't I be able to do something with it after creating it?
[16:56] <plars> xnox: oh, I see, I have to change it after creating it, and add the mountpoint then
[16:57] <infinity> Laney: Did someone take my name in vain?
[16:57] <hggdh> ogra_: and I confirmed it on bamboo-feeder and on a manual install
[16:58] <ogra_> hggdh, yeah, something is weird with the images ...
[16:58] <Laney> infinity: We wouldn't dare.
[16:58] <ogra_> or infinity messed up d-i completely when bumping the ABIs :P
[16:58] <Laney> I was going to do some nusakan twiddling, but then you showed up.
[16:58] <infinity> ogra_: Seems unlikely.
[16:59] <xnox> plars: if you are a casual user of debian-installer (netinst / alternate / server cds), you will find the current implementation very intuitive. As in, it's a tad disorientating.
[16:59] <ogra_> thus the :P
[16:59] <infinity> Laney: Feel free to twiddle what you were going to twiddle, if you were halfway there.
[16:59] <Laney> no, I was 0%
[16:59] <plars> xnox: heh
[16:59] <infinity> Laney: Oh.  Well, thpt.
[16:59] <xnox> plars: and somehow you should now upfront, that you are meant to create a separate /boot partition before creating the encrypted volume.
[16:59] <xnox> s/now/know/
[16:59] <plars> xnox: btw, I just got an error 141 from ubi-partman trying to remove an encrypted volume I had just created
[17:00] <xnox> plars: hmmm.... =( shouldn't get 141, it should not let you do that in the first place. At least I did add guards against it. Please file a bug with steps to do it.
[17:00] <Laney> infinity: I'll do it. It's just disabling cron and other similar things.
[17:00] <plars> xnox: yes, doing that now... waiting on apport at the moment
[17:00] <infinity> Laney: Sure, please do.  I'm tearing through queues and such.
[17:01] <xnox> plars: what did you try to remove? The underlying partition, the ecrypted "disk" or the final filesystem?
[17:01] <plars> xnox: the underlying partition
[17:01] <xnox> plars: not good.
[17:02] <xnox> plars: there are all sorts of guards missing, same as seen on panda boards with the sd-card. The installation medium is not properly guarded. The encrypted volumes / lvm make the discovery of unguarded partitions easier.
[17:03] <Laney> there
[17:03] <Laney> I'll not do any spins or such fun until the promotions are done
[17:07] <infinity> So, I'm going to let the evolution 3.6.0 final stuff through, since it would be nice to see it heavily tested.
[17:09] <Laney> sigh
[17:09] <Laney> can we get overlay-scrollbar yanked from proposed please?
[17:09] <Laney> it slays thunderbird
[17:09] <infinity> Lovely.
[17:09] <infinity> And can do.
[17:09] <ogra_> ogra@anubis:~/Desktop/images$ mount-image-partition quantal-server-armhf+omap4.img 2 /mnt
[17:09] <ogra_> ogra@anubis:~/Desktop/images$ find /mnt -name *kernel-image*
[17:09] <ogra_> ogra@anubis:~/Desktop/images$
[17:09] <infinity> Have you filed a bug and/or poked the appropriate people?
[17:09] <ogra_> cjwatson, am i assuming right that this is wrong ?
[17:09] <Laney> someone else commented on the bug
[17:09] <Laney> I'll poke now
[17:10] <ogra_> (i.e. there should be a kernel-image udevb in the pool, or not ?)
[17:10] <ogra_> *udeb
[17:10] <plars> xnox: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1055640
[17:10] <ubot2> Launchpad bug 1055640 in ubiquity "ubi-partman error 141 when removing encrypted partition" [Undecided,New]
[17:10] <highvoltage> ogra_: where is mount-image-partition from!?
[17:10] <ogra_> highvoltage, my own script
[17:11] <cjwatson> ogra_: I'm on a call
[17:11] <ogra_> i have a bunch of image fiddling tools here
[17:11] <cjwatson> I'll get back to you
[17:11] <ogra_> thx
[17:11] <skaet> infinity,  we may get a reverted kernel,  discussing with kernel team now.
[17:12] <infinity> Laney: Removed.
[17:12] <ogra_> highvoltage, http://paste.ubuntu.com/1224895/
[17:12] <Laney> infinity: cheers
[17:12] <highvoltage> thanks, ogra_!
[17:13] <infinity> skaet: Kay.  Then I don't have to feel bad about letting in some userspace bits. :P
[17:14] <cjwatson> ogra_: that test is certainly wrong though; I wouldn't normally expect to see *kernel-image* on images
[17:14] <ogra_> cjwatson, hmm, where should i look for it then ? i thought it is in pool
[17:14] <cjwatson> kernel-image is only for use when building d-i
[17:14] <ogra_> oh, k
[17:15] <cjwatson> no point in shipping the kernel-image udeb when we have a perfectly good kernel we booted with
[17:15] <cjwatson> the bug as described there looks more like debconf template misplacement
[17:15] <cjwatson> hm, no
[17:16] <plars> xnox: is there a bug open already that you are aware of for the fact that the mount point dropdown is available, but greyed out on the create partition screen for that feature?
[17:16] <ogra_> argh
[17:16] <ogra_> http://paste.ubuntu.com/1224904/
[17:16] <ogra_> not necessarily related, but definitely a bug as well
[17:17] <cjwatson> well, maybe a bit excessive, but at least it has the kernel we want
[17:17] <cjwatson> germinate has no subarch handling (and no obvious way to have it) so this kind of thing does tend to happen
[17:17] <infinity> Ugh.  Why does gtkhtml have such restrictive shlibs? :/
[17:19] <ogra_> well, in live-build we remove the supefluous headers as well, i guess debian-cd would need a similar hack to clean that up
[17:19] <cjwatson> never mind for now though :)
[17:19] <ogra_> nah, it wont fix my problem for sure :)
[17:19] <cjwatson> any way to boot this under emulation?  I'd like to play around a little
[17:20] <ogra_> only omap3
[17:20] <cjwatson> alternatively if somebody could stick 'set -x' near the top of /var/lib/dpkg/info/live-installer.postinst for me and get a log ...
[17:20] <hggdh> heh
[17:21] <cjwatson> 'cos it looks as though arch_get_kernel_flavour isn't working right
[17:21] <cjwatson> Oh, I'm an idiot
[17:21] <cjwatson> Never mind
[17:21] <cjwatson> I forgot to set SUBARCH
[17:22] <cjwatson> Because I was clever and thought it wasn't needed
[17:23] <ogra_> cjwatson, http://paste.ubuntu.com/1224911/ in case you want to play with omap3
[17:23] <cjwatson> No need for now, but thanks
[17:25] <infinity> SpamapS: Is your ancient lucid mysql SRU still wanted?  If so, can you and tumbleweed get together to make the queue have both SRU fixes in it?
[17:26] <ogra_> cjwatson, geez, you are fast !
[17:26] <cjwatson> Obvious once I saw it
[17:27] <cjwatson> Would be nice if somebody fixed the lying .list files on ARM, mind
[17:27] <ogra_> heh
[17:27] <ogra_> yeah, added to my TODO already
[17:27] <cjwatson> ta
[17:27] <ogra_> it picks the wrong partiton
[17:27] <xnox> plars: when you select "physical volume for encryption" the mount point should correctly become insensitive.
[17:27] <xnox> plars: possibly I should hide it completely to avoid any daubt.
[17:28] <cjwatson> as I think I said before I don't think we should hide it - that creates different confusion ("where did that disk space go?")
[17:28] <cjwatson> not to say there aren't other UI possibilities
[17:28] <xnox> plars: I couldn't quite implement the dialog as per design doc. In the design you can select all options in one go, including the mountpoint / fs for the encrypted fs.
[17:28] <xnox> plars: but it didn't seem safe, that late in the cycle. Maybe next cycle.
[17:30] <plars> xnox, skaet: sure, we need to make sure it's release noted though I think right?
[17:32] <xnox> plars: release noted - what?
[17:32] <SpamapS> infinity: yes I believe its still wanted. I'll check the status.. not sure why its been sitting so long
[17:32] <cjwatson> ^- live-installer critical for arm server
[17:32] <infinity> cjwatson: Yeah, looking already.
[17:32] <xnox> plars: once the encrypted partition is setup there is no way to remove it. So as per your bug, I should fix and make sure it's not possible to remove that disk / partition.
[17:33] <infinity> cjwatson: Hard to review the shell cut in there without knowing what archdetect returns, which I've entirely forgotten. :P
[17:33] <xnox> plars: there are plenty of places where: ubiquity implementation != design doc.
[17:33] <plars> xnox: I'm talking about the other issue - that the selection of mountpoint from the create an encrypted volume screen is unimplemented
[17:33] <cjwatson> infinity: Those lines are copied from bootstrap-base.postinst, if that helps.
[17:33] <cjwatson> It'll return things like armhf/omap4.
[17:33] <infinity> cjwatson: Heh.
[17:34] <infinity> cjwatson: Right, accepted then.
[17:34] <plars> xnox: the option is there on the screen though, which is a bit confusing.  We can see what skaet thinks though
[17:34] <infinity> (Based on the cut, not on the cargo-culting)
[17:35] <cjwatson> Ta
[17:35] <ogra_> hggdh, ^^^ your fix
[17:35] <infinity> Tempted to reject gtkhtml, not because there's anything wrong with it, but because the moment someone accepts it, all its rdeps need to be rebuilt. :/
[17:36] <Laney> Why /are/ the shlibs like that?
[17:37] <infinity> Laney: I honestly don't know.  Perhaps to allow them to experiment with adding/dropping (especially the latter) symbols during a devel cycle?
[17:37] <infinity> Laney: Since 4.5 is unstable and all.
[17:37] <infinity> Laney: That's the only explanation I can come up with for the << part.
[17:37] <Laney> Dunno. Reject it and speak to Robert
[17:38] <infinity> Laney: Well, it can't be retroactively fixed.  A new upstream will break all the old packages regardless.
[17:38] <Laney> there aren't very many rdeps anyway, if it turns out to be necessary
[17:38] <infinity> Laney: The rebuild is necessary no matter what he does to the new shlibs.
[17:38] <seb128> Laney, what package?
[17:38] <Laney> gtkhtml4.0
[17:38] <infinity> seb128: gtkhtml4.0
[17:38] <infinity> seb128: The shlibs have a >> and <<, rather than just a >>
[17:38] <Laney> I meant speak to him to find out if it's really necessary
[17:39] <seb128> some GNOME components are like that
[17:39] <seb128> did robert_ancell add those?
[17:39] <infinity> seb128: He's just cargo-culting from previous versions, I suspect, so it's hard to tell who, if anyone, knows the rationale. :P
[17:40] <infinity> -libgtkhtml-editor-4.0 0 libgtkhtml-editor-4.0-0 (>= 4.5), libgtkhtml-editor-4.0-0 (<< 4.6)
[17:40] <infinity> +libgtkhtml-editor-4.0 0 libgtkhtml-editor-4.0-0 (>= 4.6), libgtkhtml-editor-4.0-0 (<< 4.8)
[17:40] <infinity> Etc.
[17:40] <infinity> Anyhow, the rdep list is tiny, if the buildds clear up a bit, I'll just accept gtkhtml and rebuild the few rdeps.
[17:40] <plars> xnox: I also get an unusual warning when creating the encrypted partition, saying that no modifications can be made because it's in use as a physical volume for an encrypted volume (I didn't try to change anything though, I was just waiting for it to get created)
[17:41] <infinity> But perhaps I'll reject it for now, and accept it from rejected later. :P
[17:41] <seb128> Laney, infinity: my guess is that Debian did it because usually evo and gtkhtml need to be on a same serie
[17:42] <infinity> seb128: That doesn't seem like a sane rationale from broken shlibs.
[17:42] <infinity> s/from/for/
[17:42] <infinity> seb128: Anyhow, it's also no huge deal, since almost nothing links to it.  We'll just do the rebuilds in a bit.
[17:43] <seb128> where almost nothing is only evolution?
[17:43] <infinity> I wish I'd noticed when I was processing the evo queue entries, though.
[17:43] <infinity> Cause I could have done gtkhtml first. :/
[17:43] <Laney> and "xiphos", whatever that is
[17:43] <infinity> If evo had, I dunno, versioned build-deps, that would totally work.
[17:43] <cjwatson> It's an operating system composed entirely of ogg codecs
[17:43] <ogra_> LOL
[17:44] <Laney> That sounds nice
[17:44] <seb128> Laney, infinity: the shlibs is this way since added in Debian: http://anonscm.debian.org/viewvc/pkg-evolution?view=revision&revision=1192
[17:44] <ogra_> but its a bible browser it seems
[17:44] <cjwatson> ah, gnomesword as was
[17:45] <seb128> Laney, infinity: I think it's because gtkhtml is no used out of evo and they handle it as a semi private lib, not bothering changing soname on abi changes
[17:45] <seb128> they = upstream
[17:45] <Laney> evo itself only appears to have a >= dep
[17:45] <seb128> right
[17:45] <infinity> Laney: ?
[17:46] <Laney> in its autotooling
[17:46] <seb128> the idea is to prevent updating gtkhtml to new_serie without updating evo
[17:46] <Laney> It only asks for gtkhtml >= 4.5.2
[17:46] <Laney> well, gtkhtml-4.0
[17:46] <infinity> Laney: Oh, I thought you meant the package. :P
[17:46] <infinity> (The binary package)
[17:46] <Laney> Nein.
[17:47] <Laney> And now, I'm going to purchase some delicious food for dinner
[17:47] <Laney> tata
[17:47] <infinity> seb128: It seems like a pretty annoying abuse of shlibs, but it's a big "I don't really care" given the rdep list is tiny.
[17:47] <seb128> k
[17:47] <seb128> Laney, enjoy, you made me hungry, I should think about dinner as well! ;-)
[17:48] <infinity> seb128: That said, evo uploads could have versioned build-deps on gtkhtml, which would prevent what just happened.
[17:48] <infinity> seb128: (Which is that evo uploaded and built against the old version JUST before the new version was considered)
[17:48] <seb128> infinity, yeah, that looks like an error
[17:49] <infinity> seb128: Well, they were *uploaded* in the right order, but upload and build aren't a guaranteed FIFO, unless you actually wait for the builds to be done and published. :P
[17:49] <infinity> (And versioned build-deps would be entirely correct, if the intent is to keep them in lockstep)
[17:50] <seb128> yeah, as said looks like a packaging overlook (the build-dep should have been bumped)
[17:50] <infinity> Check.  Stopping talking now.  Not important enough to waste time on.
[17:51] <seb128> (done)
[17:51] <infinity> seb128: Maybe a new set up uploads with a versioned build-dep would be nice, so I can blat those through the queue when I decide to let gtkhtml4.0 out.
[17:51] <infinity> s/set up/set of/
[17:51] <infinity> I think I might need a big pot of Monday coffee.
[17:51] <seb128> infinity, where uploads = evo with versionned build-dep?
[17:52] <infinity> seb128: Yeahp.  And I think there might be a plugin too.
[17:52] <infinity> evolution, evolution-rss, xiphos
[17:52] <seb128> ok
[17:52] <infinity> Those would be the three r-build-deps.
[17:53] <seb128> I will get that uploaded for quantal-proposed
[17:53] <seb128> so you can ack them when you feel like doing it
[17:53] <infinity> Many thanks.
[17:53] <infinity> You're me second favourite French developer.
[17:53] <infinity> s/me/my/
[17:53] <infinity> I also can't type.
[17:55] <xnox> plars: it's unusual.... simply because there was no ecryptfs support in ubiquity before. It's a standard warning shown by d-i. And it is meant to tell you that you won't be able to modify the partitions.
[17:56] <seb128> infinity, who is the first one?
[17:56] <cjwatson> xnox: erm, I think you may mean no luks support?
[17:56] <xnox> Laney: what about xiphos? =)))) xiphos is good.
[17:56] <infinity> seb128: benh gives me free wine, you can't compete.
[17:56] <cjwatson> we've had ecryptfs support for yonks
[17:56] <xnox> cjwatson: yes, I do.
[17:56] <seb128> infinity, I see, that's because I didn't bring you some smelling cheese at UDS
[17:56] <infinity> seb128: :)
[17:57] <cjwatson> I'm not convinced that that warning is usual, though.  Sounds like something being done out of order.  It's only supposed to happen if you try to modify the partition underlying an existing encrypted volume.
[17:57] <cjwatson> But plars said he saw it when creating a new volume.
[17:58] <xnox> cjwatson: d-i shows it when you activate encrypted volumes. always.
[17:58] <xnox> cjwatson: I can silence it, and the fact that "remove/change" buttons are insensitive, should give the clue that you can't change these any more....
[17:59] <cjwatson> Oh, is this partman-crypto/confirm?
[17:59]  * cjwatson wishes people wouldn't paraphrase error messages, because it means I can't grep for them and have to guess.
[17:59] <cjwatson> Or, well, messages.
[18:00] <cjwatson> I thought you asked me whether to silence partman-crypto/confirm some days ago, and I said if and only if partman/confirm is silenced, and you said it was; so I assumed you had done that already.
[18:00] <xnox> cjwatson: partman-crypto/confirm_nochanges
[18:01] <cjwatson> Yeah, you asked about that too.
[18:01] <cjwatson> 13:11 <xnox> cjwatson: partman-lvm|crypto|md like showing /confirm /confirm_nochanges /confirm_nooverwrite, should those warning be shown in manual partitioning or not?
[18:01] <xnox> cjwatson: that is what I did. bug partman-*/confirm_nochanges where not silenced =)
[18:01] <cjwatson> 13:15 <cjwatson> if and only if the corresponding ones for plain block devices are shown
[18:01] <cjwatson> 13:20 <xnox> they are not.
[18:01] <cjwatson> 13:20 <xnox> thanks.
[18:01]  * xnox doh
[18:01] <xnox> the confirm & confirm_nooverwrite are silenced across the board.
[18:02] <xnox> the confirm_nochanges where not.
[18:02] <xnox> and still are not. But maybe they should be, as part of crypt, lvm (upcomming) and raid.
[18:02] <xnox> as these are the places where nochanges are used, and well the installation medium is the same as the disk.
[18:03]  * xnox will think about it, and maybe reuse the warning on the top for these.
[18:06] <plars> xnox: so, one of the things I'm trying to sort out here, and still struggling with, is how to create an encrypted swapspace. Would I need to create 2 separated encrypted volumes to do that? (one for swap, one for root)
[18:07] <plars> If I try to create a normal swap area, then as soon as I create the encrypted volume I get an "Unsafe swap space detected" (Title not paraphrased) dialog box
[18:09] <cjwatson> Bug 1054323 is beta-2-critical.  I'll fix it after dinner.  Doesn't require a ubiquity upload as ubiquity takes care of that bind-mount itself.
[18:09] <xnox> plars: LUKS doesn't support partitions. So yes, you need to create two encrypted volumes.
[18:09] <ubot2> Launchpad bug 1054323 in grub-installer "Server Installer fails at 'grub install dummy' in EFI mode" [High,In progress] https://launchpad.net/bugs/1054323
[18:09] <plars> xnox: ok
[18:10] <xnox> plars: this is until we have adv-lvm, cause then you will be able to create VG in the encrypted partition & create as many LVs as you need.
[18:10] <plars> xnox: got it
[18:12] <stgraber> skaet, infinity: 3 packages getting to the queue now for edubunty. edubuntu-live and edubuntu-netboot for bug 1055635 and arkose for bug 1055677 (nice to have that I just noticed and fixed)
[18:12] <ubot2> Launchpad bug 1055635 in edubuntu-live "Enable gnome-fallback by default for LTSP Setups" [High,Confirmed] https://launchpad.net/bugs/1055635
[18:12] <ubot2> Launchpad bug 1055677 in arkose "arkose crashes when uid 1000 doesn't exist" [Undecided,New] https://launchpad.net/bugs/1055677
[18:12] <stgraber> I'll update the pad and approved the FFe for the gnome-fallback change
[18:12] <stgraber> *approve
[18:17]  * skaet --> lunch
[18:18] <stgraber> cjwatson: hmm, looks like we have one more packageset weirdness ;) edubuntu-live should be in the edubuntu packageset, not ubuntu-desktop :)
[18:18] <stgraber> cjwatson: and it looks like your refresh earlier dropped gcompris from ubuntu-desktop but didn't add it to edubuntu (that or I refreshed my report at the wrong time and it got fixed since)
[18:20]  * infinity decides he might need some sort of breakfast or lunch or something.
[18:21] <stgraber> would be great if someone could check the diffs for arkose, edubuntu-live and edubuntu-netboot. They should all be pretty trivial to review, except maybe for edubuntu-live that bundles a langpack refresh (easy enough to ignore though).
[18:22] <infinity> stgraber: I'll get to them shortly.  None of it's wildly urgent (as far as images go), as we're waiting on a kernel now. :P
[18:23] <stgraber> infinity: right
[18:23] <stgraber> infinity: well, actually, I'd like to get edubuntu-live fairly soon to see if pkgbinarymangler (or whaterver strips the locales) does the right thing now as having a langpack installer that's not translated kind of sucks :)
[18:24] <stgraber> and I'm not completely sure I did the right magic on LP to avoid the striping part of the process (and can't really test ...)
[18:27] <infinity> stgraber: Did you actually change something?  The changelog claims that you're hoping LP won't strip.  Hope isn't actually enough to make it work. :P
[18:28] <stgraber> infinity: yeah, I changed a setting in the LP template the "do not include in langpack" bit was set, I unset it
[18:28] <stgraber> "include in langpack" I mean...
[18:28] <stgraber> now I'm hoping that not being included in langpacks mean it won't strip it, that's the bit I'm not 100% sure about ;)
[18:29] <infinity> Yeah, no.  Doesn't relate at all.
[18:29] <infinity> It'll get stripped because the source is in main.
[18:29] <infinity> Unless pitti's made pkgstriptranslations WAY smarter than it used to be.
[18:29] <infinity> We could also blacklist it.
[18:29] <stgraber> oh, why is that source in main?
[18:30] <stgraber> bug 788671 apparently, checking
[18:30] <ubot2> Launchpad bug 788671 in edubuntu-live "[MIR] edubuntu-live" [High,Fix released] https://launchpad.net/bugs/788671
[18:31] <stgraber> ah, that bug in LP was fixed, I can easily get universe packages included in langpacks nowadays. I'll drop it from the seeds...
[18:32] <infinity> Kay.  If you drop it from the seeds, I'll mangle the archive to demote it to universe.
[18:32] <infinity> Which is less hassle than adding it to blakclists.
[18:33] <stgraber> infinity: seed updated
[18:33] <infinity> stgraber: Source demoted.
[18:33]  * infinity wonders if he made the publisher cycle...
[18:33] <stgraber> cjwatson: I guess that also explains why your script put it in the ubuntu-desktop packageset instead of the edubuntu one
[18:34] <infinity> stgraber: I'm going to go find breakfast, and revisit this when I get back, assuming the archive's settled.
[18:34] <highvoltage> I wish I could live in infinity's timezone for a bit.
[18:35] <stgraber> infinity: ok, thanks
[18:36]  * stgraber needs a "review all edubuntu hacks and replace them by something reasonable" work item for next cycle... remembering all these seeds/LP/cdimage/... hacks is getting difficult
[18:36] <infinity> stgraber: Well, we just got rid of one. :P
[18:36] <infinity> stgraber: You could just have a standing WI that's "every time you see crack, replace it with a better drug."
[18:37] <highvoltage> stgraber: well they should be seperate work items for each hack, imho
[18:37] <highvoltage> stgraber: I also want a work item to actually make work items for all my todo list items (and I guess yours too) so that we can actually try to get other people to do them
[18:37] <stgraber> I guess 90% of them can be covered by "make the seeds reasonable and update cdimage to stop pretending edubuntu-dvd and edubuntu are different things"
[18:38] <stgraber> that'd cure most of my edubuntu-related headaches
[18:39] <highvoltage> stgraber: do we still get the unity-lens-shopping package in edubuntu? I think it should probably be removed if it's still there due to https://bugs.launchpad.net/ubuntu/+source/unity-lens-shopping/+bug/1054282
[18:39] <ubot2> Launchpad bug 1054282 in unity-lens-shopping "No obvious way to restrict shopping suggestions from displaying adult products" [Undecided,Confirmed]
[18:43] <stgraber> highvoltage: yes, we still inherit it from ubuntu-desktop and can't easily get rid of it for the same reason
[18:43] <highvoltage> stgraber: I was afraid you'd say that
[18:44] <stgraber> highvoltage: we can use our usual trick of adding a conflict on edubuntu-live, though that's one of those "hacks" I was talking about that we really should avoid (as it's making our live image different from a netboot/debootstrap image)
[18:48] <stgraber> highvoltage: if you want me to kill that lens, please file a bug against edubuntu-live. I don't mind doing it but it needs to be documented and we really need to design a cleaner way of dealing with those packages starting with 13.04
[18:49] <highvoltage> stgraber: yep
[18:49] <stgraber> introducing a new edubuntu-desktop-blacklist package conflicting against these packages we don't want and being itself a recommend (not depend) of edubuntu-desktop, should do the trick. (As in, it'll prevent these packages from being installed on any edubuntu system but won't prevent the user from installing them later on)
[18:50] <jbicha> ooh, that's an interesting trick
[18:51] <highvoltage> jbicha: yeah, it doesn't do the trick completely though since it won't remove unwanted packages in the case where someone does a netinstall and chooses the Edubuntu task, or if somoene installs it from a minimal system
[18:51] <stgraber> yeah, we're getting good at these ;) so far we're putting them all in edubuntu-live, that's a package only installed in the live environment so that lets us remove some packages without actually causing any post-install side effect, though that nice trick doesn't work with netboot/debootstrapped systems and so qualifies as a "ugly hack" :)
[18:52] <stgraber> highvoltage: nope, the trick I proposed above will work with these cases. It's only our current implementation that doesn't.
[18:54] <highvoltage> stgraber: https://bugs.launchpad.net/ubuntu/+source/edubuntu-live/+bug/1055705
[18:54] <ubot2> Launchpad bug 1055705 in edubuntu-live "[UIFe] Please remove unity-lens-shopping package from Edubuntu installation" [Critical,Confirmed]
[18:55] <stgraber> thanks
[18:55] <stgraber> I'll reject my edubuntu-live upload then and re-upload with that one added
[18:56] <highvoltage> stgraber: great
[18:56] <seb128> highvoltage, Ubuntu hater ;-)
[19:03] <stgraber> infinity: uploaded a new edubuntu-live including the conflict with unity-lens-shopping that was discussed earlier
[19:21] <iulian> Laney: I cannot see shotwell in the queue. Did somebody accept it?
[19:21] <hallyn> hi - qemu-kvm FTBFS in quantal on powerpc.  Should I upload the fix to quantal-proposed?  Or just wait until release?
[19:23] <stgraber> hallyn: go ahead with the upload
[19:23] <iulian> Laney: Apparently somebody already did that.
[19:23] <hallyn> stgraber: to -proposed?
[19:24] <iulian> Too bad that irclogs.u.c doesn't log the notices as well. It would've been easier to just grep the notices from queuebot.
[19:26] <Laney> iulian: looks like it
[19:26] <Laney> my money would be on infinity
[19:28] <stgraber> hallyn: is qemu-kvm one of these packages that can create archive skew?
[19:29] <stgraber> hallyn: I had a very quick look and saw a -common arch all package, so I assumed -proposed might make sense (didn't look at the exact dependencies though)
[19:30] <hallyn> Daviey: bug 1054329, ping ?
[19:30] <ubot2> Launchpad bug 1054329 in augeas "[FFE] Sync augeas 0.10.0-1 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1054329
[19:31] <hallyn> Daviey: i ask bc if that'll be ack'd i'd rather push the fix for the other bug from friday (split lines in modprobe) just once against it :)
[19:31] <hallyn> stgraber: ok, will push to -proposed, thanks.
[19:32] <stgraber> hallyn: for bug 1054329, I'm interpreting Laney's comment as a +1 (no FFe needed, just bugfix, go ahead, but do a fakesync)
[19:32] <ubot2> Launchpad bug 1054329 in augeas "[FFE] Sync augeas 0.10.0-1 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1054329
[19:34]  * hallyn googles fakesync
[19:35] <tumbleweed> hallyn: syncpackage can do it
[19:36] <hallyn> tumbleweed: thanks, was just seeing https://wiki.edubuntu.org/fakesync which claims that as well.
[19:36] <hallyn> but so what do i do about pushing it to -proposed?
[19:36] <hallyn> oh, -d quantal-proposed?
[19:37] <tumbleweed> syncpackge probably doesn't knwo how to do that
[19:37] <hallyn> zounds
[19:37] <tumbleweed> but it can produce the source package that you would upload, then you can change it :)
[19:38] <hallyn> so use --no-lp (which manpage suggests might be done automatically)
[19:38] <hallyn> thanks, trying
[19:40] <Laney> it's easy to do manually too
[19:40] <Laney> it's the debian .debian.tar.gz/.diff.gz/whatever, the Ubuntu .orig.tar.whatever and a fakesync changelog entry
[19:41] <hallyn> makes sense.  i'm a bit afjeered though :)
[19:41] <hallyn> syncpackage way seemed to work...
[19:41] <Laney> yeah, but it's good to know what it does in my opinion
[19:41] <hallyn> Laney: so (you commented) RT approval for FFE not needed for the augeas sync, but do i need a separate approval to push to quantal-proposed?
[19:41] <Laney> no
[19:42] <hallyn> Laney: agreed, and thanks, your descriptoin makes sense
[19:42] <hallyn> cool, thanks.
[19:42] <Laney> nps
[19:42] <cjwatson> stgraber: I didn't notice my change earlier changing gcompris at all - it was just a refresh so that I had a consistent baseline
[19:42] <cjwatson> or at least that's all I meant to do
[19:43] <cjwatson> stgraber: main/universe shouldn't make any difference for ubuntu-desktop vs. edubuntu packagesets FWIW
[19:44] <stgraber> cjwatson: my bad, was looking at desktop-core instead of ubuntu-desktop. gcompris indeed didn't move from there.
[19:47] <seb128> ^ that one would be good to approve, the bug it fixes is a segfault with quite some duplicates coming daily
[19:58] <stgraber> infinity: thanks! (assuming that ^ was you)
[19:58] <infinity> It was.
[20:00]  * infinity eyeballs that cups-pk-helper upload, and wonders if maybe there might be a missing include somewhere.
[20:26] <Daviey> ogasawara: Is that kernel intended for Beta 2?
[20:27] <ogasawara> Daviey: yes, we'd discussed with skaet and infinity earlier but in #ubuntu-kernel
[20:28]  * skaet nods
[20:29] <Daviey> There is nothing which suggests this is a respin trigger
[20:29] <Daviey> But presumably all flavours will need a respin for this?
[20:29] <skaet> yes.
[20:30]  * cjwatson rushes to finish testing grub-installer
[20:30] <Laney> there's no first spins yet :-)
[20:30] <skaet> exactly ;)
[20:30] <cjwatson> though I guess I have time while linux builds
[20:30] <Daviey> Oh!
[20:30] <Daviey> I thought i saw one.
[20:30] <skaet> milestone's been set up,  but cron shouldn't be running ...
[20:33] <cjwatson> quantal builds are indeed disabled in cron
[20:34] <Daviey> ogasawara: I am right in saying this isn't an ABI toucher?
[20:36] <ogasawara> Daviey: right, no ABI bump
[20:36] <Daviey> superduper
[20:37] <cjwatson> Does it need a d-i rebuild so that the new kernel is used in the installer?
[20:38] <cjwatson> Hmm, looks like probably not
[20:39] <Daviey> it's all graphics related.
[20:39] <cjwatson> Well, it affects the console, but I don't think the installer has the i915 drm bits in it.
[20:40] <cjwatson> So should be OK.
[20:43] <cjwatson> ^- grub-installer critical for b2 server (UEFI), please review
[20:47] <infinity> cjwatson: I'll review in a sec.
[20:48] <cjwatson> ta
[21:03] <skaet>  stgraber,  is there going to be an arm edubuntu image this time around?   if not,  can we remove it from the default path (so don't slow down on it during builds)
[21:06] <stgraber> 16:16 < skaet> stgraber, is arm going to be available for edubuntu for beta2?
[21:06] <stgraber> 16:17 < stgraber> skaet: nope, ARM is staying daily-only for 12.10, we won't release it
[21:06] <stgraber> so yeah, can be removed from the build commands
[21:07] <skaet> thanks stgraber,  sorry,  missed it in the backscroll.
[21:07] <skaet> infinity, ^
[21:10] <phillw> stgraber: are the ARM guys thinking that there will be a lubuntu release? (Just so I can let my boss know :P )
[21:12] <stgraber> phillw: The choice to build for a specific architecture or not is up to the flavour leads, though at this point, if lubuntu never had an arm release, it's too late to make one for 12.10.
[21:13] <phillw> stgraber: just that is has sat there on the daily bullds ever since they asked permission to have one.
[21:14] <stgraber> looks like lubuntu had a temporary ac100 image built, probably because ubuntu wasn't quite working on it at the time
[21:14] <skaet> infinity, can you score up the linux build so we know it goes into the next armel and powerpc slots?
[21:14] <stgraber> but it hasn't been built for the past 3 weeks
[21:14] <stgraber> ogra_: can you comment on lubuntu armhf ac100 desktop pre-install? is that still useful/built or can I flush it from the tracker?
[21:15] <phillw> afaik, they have confirmed it as installing, but whilst julien (gilir) did give permission, it is up to the ARM guys to test. They needed a low RAM system for some kit & chose lubuntu.
[21:16] <stgraber> yeah, that was a temporary thing for the ac100 IIRC, as it wasn't built recently, my guess is that it's no longer needed, but ogra should be able to confirm that
[21:16] <phillw> we are happy to have them, after all, lubuntu is for low-resource machines.
[21:17] <phillw> well, if you can check. We have no objections.
[21:18] <slangasek> stgraber: Ubuntu is not and will not be working on ac100; I don't know why the lubuntu image build has been stopped
[21:18] <slangasek> Ubuntu desktop works on armhf only if we have binary drivers, and AFAIK there are none in the archive for ac100
[21:19] <infinity> stgraber: We switched ac100 from ubuntu *to* lubuntu, nothing temporary about it.
[21:20] <stgraber> slangasek: ok, that makes sense. That's unfortunate that we still don't have a tegra2 blob packaged (or that we can distribute, not sure which is the issue)
[21:20] <stgraber> infinity: ok, so someone should look into fixing the build or maybe just tweak default-arches so that it actually builds (haven't looked into it besides reading phillw's comment above)
[21:20] <infinity> stgraber: We occasionally have them, and occasionaly not, but we can't rely on having one that work at any given point.
[21:20] <infinity> s/work/works/
[21:21] <infinity> stgraber: It's in default-arches.  It might not be in cron...
[21:21] <infinity> Oh, no, there it is.
[21:21] <cjwatson> Shouldn't need to be in cron if it's in default-arches ...
[21:21] <infinity> #35 1 * * *	buildlive lubuntu daily-preinstalled && for-project lubuntu cron.daily-preinstalled
[21:21] <cjwatson> Well, the whole flavour does, sure
[21:21] <infinity> Yeah. :P
[21:22] <stgraber> hmm, then maybe it's just the cdimage => tracker magic that needs tweaking
[21:22]  * stgraber has a look
[21:22] <infinity> Given that said subarch is the only thing that builds for that flavour.
[21:22] <phillw> guys, please do not shoot the messenger, lubuntu were asked to hold a low RAM version or ARM. The last thing i want is for a fight :'(
[21:22] <infinity> phillw: There's no fighting.
[21:22] <stgraber> No iso.qa.ubuntu.com product found for lubuntu/daily-preinstalled/quantal-preinstalled-desktop-armhf+ac100; skipping.
[21:22] <infinity> stgraber: http://cdimage.ubuntu.com/lubuntu/daily-preinstalled/ <-- Implies it's been building recently, so it could just be the tracker magic.
[21:22] <stgraber> so post-qa doesn't know what to do, that's the problem
[21:23]  * stgraber fixes
[21:23] <cjwatson> phillw: Please don't confuse debate about why it isn't working with fighting!
[21:24] <cjwatson> Yeah, looks like just tracker integration
[21:24] <phillw> cjwatson: as a guy who does not have a ppc machine, I'm getting used to that area of releasing / maintaining different archs :D
[21:25] <phillw> infinity: just by the way, did you manage to find the time to put the lubuntu iso's onto a diet?
[21:25] <stgraber> ok, post-qa has been updated, next build should be posted properly
[21:25] <infinity> phillw: Nope, can do a bit of that this afternoovening.
[21:25]  * stgraber greps to check if anything else needs fixing
[21:27] <stgraber> according to grep, the lubuntu ac100 image was the only one failing to post to the tracker, so looks like we're all good now (assuming my fix worked)
[21:27] <phillw> infinity: as lubuntu is for low spec machines, having isos' at CD size really would help us.
[21:27] <phillw> I'll take the flack off Julien (gilir) in his abscence.
[21:33] <phillw> infinity: can you trip in just Lubuntu-PPC builds after your work? I'm hoping cjwatson has gotten the yaboot fix in via the ubiquity rebuild? Or am I really way off in my thoughts?
[21:33] <cjwatson> yaboot-installer, not yaboot, but yeah, that fix was in ubiquity 2.12.3.
[21:33] <cjwatson> Which has built everywhere.
[21:34] <cjwatson> However since earlier conversation indicated there aren't any candidates yet, there's no point worrying about single-architecture respins right now.
[21:34] <infinity> phillw: The whole world's getting rebuilt for shiny new kernels sometime anyway, probably no rush just yet to be doing one-offs, unless someone really wanted to test the yaboot thing RIGHT NOW.
[21:34] <cjwatson> It'll get caught up in the rebuild of everything.
[21:34] <infinity> cjwatson: Jinx, I guess I was being too verbose.
[21:35] <phillw> infinity: I do actually pay attention :) I know you are awaiting a new kernel.
[21:36] <phillw> cjwatson: is the ppc release at http://iso.qa.ubuntu.com/qatracker/milestones/238/builds of any use, or should I tell them not to waste time testing?
[21:37] <Laney> not if you want that fix
[21:37]  * Laney presses a butan
[21:37] <phillw> Laney: can you or stgraber remove that suite, please?
[21:38] <phillw> I will send an email out, but not all testers are on the mailing list.
[21:38] <phillw> Laney: thanks :)
[21:39] <Laney> dear old queuebot
[21:40] <phillw> Well, 21:00 UTC has passed, do you guys have an ETA for the QA release of Beta 2?
[21:42] <phillw> "Whenever", is not the answer :P QA are used to shortened test times. Any crumbs to tell the QA guys?
[21:44] <infinity> phillw: After all the kernels are built and no one has another other last-minute critical bits that hold us up for another hour or three.
[21:45] <infinity> phillw: Also, depends on people being around to press buttons (I have plans tonight, so I won't be)
[21:46] <phillw> infinity: In the absence of skaet, can I reasonably ask testers to look at beta 2 in 12 hours time, or is that a time stamp still not being able to be confirmed?
[21:47] <skaet> phillw,  yes,  that should be about right.
[21:47] <infinity> phillw: Instead of saying "test something in 12 hours", you're better off just saying "test the next image".
[21:48]  * skaet likes that better
[21:48] <phillw> I know you guys on -release work to that last minute, but when can we ask to testers to come crawl over everything?
[21:48] <infinity> Deadlines we can't meet just make everyone grumpy.
[21:48] <phillw> infinity: I love the wooshing sound that deadlines make as they pass my ear :)
[21:51] <phillw> you guys release the QA-Beta 2 when you are ready. and for that side of thinking... you will just have to trust me. The testers would rather hold back & then blast the QA release that piddle along with the dailies. You guys & Gals? Just make it work. And you always do.
[22:06] <Laney> dpkg is so hideous on this machine
[22:06] <Laney> I think I need to join team SSD
[23:10] <xnox> plars: thanks a lot for your bug reports. Very useful. I will see how many I can fix.
[23:10] <xnox> keep them comming ;-)
[23:16] <skaet> infinity,  why did you accept the gst-* set?
[23:16]  * skaet assumes it was you
[23:17] <skaet> never mind
[23:17] <skaet> seeing they're universe now.
[23:18] <skaet> infinity,  the new build linux kernel (amd64) updated and loaded fine on my laptop.    We should be good to go when armel/armhf/powerpc finish building.
[23:18]  * skaet --> dinner
[23:18] <infinity> skaet: I know.
[23:19] <skaet> k
[23:34] <phillw> skaet: may I have a PM?
[23:36]  * smartboyhw is also wondering what last-minute kernels can disrupt beta 2 build..
[23:37] <cjwatson> smartboyhw: https://launchpad.net/ubuntu/+source/linux/3.5.0-15.23 has the bug references