[00:00] <xnox> micahg: well base-files was uploaded 2h ago, so we have to respin everything yet =)
[00:04] <doko> micahg, still afternoon on Hawaii
[00:05] <micahg> heh
[00:05] <micahg> doko: hoping to be more available for FTBFS fixes for the LTS cycle
[01:04] <cjwatson> could somebody review my qtwebkit-source arm64 fix?
[01:04] <cjwatson> Daviey: no particular reason AFAIK
[01:05] <cjwatson> should be relatively straightforward although it's a very complex bug and I think I still have a couple of missing pieces (but none that should block processing of those uploads)
[01:08] <cjwatson> xnox: I think micahg's aiksaurus upload is more likely to work for the next port than yours; yours only causes it to update in clean, so it'll update when preparing the source package but not necessarily when building it
[01:14] <micahg> ah, sorry for forgetting to check unapproved
[01:15] <micahg> but I guess the result was good
[01:17] <micahg> cjwatson: should I update the meta as well for arm64 or no since we're not spinning media
[01:18] <cjwatson> micahg: it was already updated, blocked in -proposed
[01:18] <micahg> ah, ok
[01:18] <cjwatson> micahg: I was planning to do another run tonight depending on what looks finishable
[01:19] <micahg> I don't see xubuntu-meta
[01:20] <micahg> aiksaurus finished on arm64
[01:20] <cjwatson> I'd be somewhat surprised if we had enough of xfce
[01:24] <micahg> I can't do much more tonight, I can try to get a few more fixes done tomorrow night, but I think it'll be too late for seeded then
[01:25] <cjwatson> so, the remaining uninstallables in ubuntu-desktop are gnome-session software-properties-gtk ubuntu-release-upgrader-gtk update-manager
[01:26] <cjwatson> root causes are update-notifier, gnome-settings-daemon, ubuntu-drivers-common
[01:26] <cjwatson> update-notifier is waiting for libappindicator, should get that soon
[01:26] <wgrant> g-s-d was too, last I looked
[01:27] <wgrant> and u-d-c was packagekit
[01:27] <wgrant> which will be available in 20 or so
[01:36] <micahg> I've got a bug fix for gmusicbrowser (Xubuntu seeded), would this be ok to slip in or will this be deferred to SRU
[01:45] <rsalveti> anyone around to approve ^? requirement to land the touch multimedia stack fixes
[01:46] <cjwatson> looking
[01:50] <rsalveti> awesome, thanks
[04:30] <darkxst> have the Ubuntu GNOME cron jobs been switched off? if not can we get that done ;)
[07:23] <infinity> micahg: Seeded fixes won't be allowed much longer, no.  Will look at the state of main when I get in to work in ~30m, and make a final decision on that, but I don't want gratuitous respins and to track changes in awkward lists. :P
[07:40] <cjwatson> infinity: Can we afford a last kde4libs change for arm64?
[07:59] <infinity> cjwatson: The one from William?  Mulling it over right now.
[08:13] <xnox> cjwatson: micahg: ok.
[08:50] <tumbleweed> archive admins: ping on lesstif2 removal (bug 1222747)
[08:50] <ubot2> Launchpad bug 1222747 in lesstif2 (Ubuntu) "[FFe] Transition from lesstif2 to Motif in Saucy" [Medium,Triaged] https://launchpad.net/bugs/1222747
[08:55] <infinity> tumbleweed: Ahh, let me look at that again.  Last I looked, a few rdeps were straggling.
[08:55] <tumbleweed> thanks
[09:01] <infinity> tumbleweed: Done.
[09:04] <tumbleweed> thanks again
[09:11] <psivaa> xnox: just curious if you are dealing with all the oem related issues with bug #1231166 ?
[09:11] <ubot2> Launchpad bug 1231166 in ubiquity (Ubuntu Saucy) "oem config user remains the default user after full oem installation" [High,Confirmed] https://launchpad.net/bugs/1231166
[09:12] <xnox> psivaa: yes.
[09:12] <psivaa> xnox: ack, thanks
[11:05] <seb128> infinity, Laney, lool: opinions about https://bugs.launchpad.net/ubuntu/+source/ubuntu-sounds/+bug/1239594 and https://bugs.launchpad.net/ubuntu/+source/ubuntu-sounds/+bug/1239612?
[11:05] <ubot2> Launchpad bug 1239594 in ubuntu-sounds (Ubuntu) "New startup sound for 13.10 desktop" [Undecided,New]
[11:05] <ubot2> Launchpad bug 1239612 in ubuntu-sounds (Ubuntu) "New ringtone and notification sounds for 13.10 mobile" [Undecided,New]
[11:05] <infinity> seb128: New sounds 3 days before release?  Smooooth.
[11:05] <seb128> the first one is a request to change the desktop login sound in saucy (that's one file to replace, we have sound off by default anyway so not making a real difference)
[11:05] <seb128> infinity, yeah, don't tell me :/
[11:06] <seb128> infinity, the second one is a complete new set of sounds for touch
[11:06] <infinity> seb128: If this is being sabdfled, any chance he can comment on the bug instead of having someone else invoke his name in vain?
[11:06] <seb128> infinity, I can make a new source for the touch set if that makes things earlier for release
[11:06] <infinity> seb128: The new sounds for touch thing, I'm fine with if it's completely separate.
[11:06] <lool> seb128: if they are in the same format and it's just swapping a file with another, I feel it's not risky for touch in any way and can still go in; main worry is desktop side
[11:06] <infinity> seb128: It's the changing of desktop stuff for 13.10 that I'd like more than "Mark wants this" from someone who isn't Mark.
[11:07] <cjwatson> Indeed there's a rule that it only counts if Mark says it himself
[11:07] <seb128> infinity, I'm not sure it was sabdfled, Mark gave his +1 on using the sound, I didn't read anyone saying that he said that has to be in saucy
[11:07] <lool> does a recording of mark saying it count?
[11:07] <seb128> let me check with the design guys
[11:07] <seb128> lol
[11:07] <infinity> lool: Hah.  Maybe. :)
[11:07] <lool> "I am Mark Shuttleworth and I approve this notification"
[11:07] <cjwatson> "... and I pronounce Ubuntu Ubuntu"
[11:11] <xnox> seb128: that file is played back by ubiquity isn't it?
[11:12] <seb128> xnox, the login sound?
[11:13] <xnox> seb128: startup-sound / system-ready
[11:13] <seb128> xnox, could be, I didn't know about that... I though we had sound effects muted by default
[11:13] <xnox> seb128: it would be nice to know file-path / sound name that bug 1239594 wants to replace.
[11:14] <ubot2> Launchpad bug 1239594 in ubuntu-sounds (Ubuntu) "New startup sound for 13.10 desktop" [Undecided,New] https://launchpad.net/bugs/1239594
[11:14] <seb128> xnox, to avoid being "the guy who boots his laptop and the library and that everybody is looking at because that's playing some loud sound in that quiet place"
[11:14] <xnox> seb128: a blind person boots the installer, and is notified with the sound when the system is ready to enable a11y by pressing Ctrl+L to start the screen reader.
[11:14] <xnox> so installer always had it.
[11:15] <seb128> xnox, commented on the bug, I guess it's not the same sound
[11:15] <seb128> jounih, hey
[11:16] <jounih> hey
[11:16] <seb128> infinity, jounih, xnox: you guys are all in the office? you should probably just talk between yourself there
[11:16] <jounih> i'm at blue fin
[11:17] <infinity> I'm about to eat lunch, but can discuss when I get back.
[11:17] <Laney> I've never heard the existing service-login sound
[11:17] <Laney> Doesn't ubiquity use system-ready?
[11:17] <Laney> that's the drums
[11:17] <jounih> infinity: sure, same here. 1:30pm good for you?
[11:18] <Laney> (yes, it does)
[11:19] <xnox> jounih: i'm in blue fin as well.
[11:20] <jounih> xnox infinity cool where you guys sitting?
[11:21] <xnox> jounih: row of desks 2nd after the reception, kind of inline with the printer room.
[11:22] <jounih> ok just about to head out for lunch, i'll come say hi on the way out :)
[11:22] <xnox> jounih: cool.
[11:22] <davmor2> xnox: Just stand and wave wildly
[12:27] <infinity> jounih: Sure.  I'm sitting over by HRish people.  Long hair, black t-shirt, grumpy scowl.
[13:11] <didrocks> wgrant: infinity: here we go, all freshly built and automatically tested ^
[13:11] <wgrant> didrocks: Excellent, thanks a lot :)
[13:11] <didrocks> yw ;)
[13:14] <infinity> didrocks: <3
[13:16] <pitti> hello
[13:16] <asac> hi pitti
[13:16] <pitti> latest lintian upload from a few days ago broke aptdaemon's tests as that dropped $LINTIAN_ROOT
[13:16] <pitti> I just committed a fix upstream
[13:16] <pitti> is that something we can still land? (no runtime code changes, just tests)
[13:18] <infinity> pitti: If you're quick. :P
[13:19] <infinity> ScottK: Want to review that plasma-nm upload, since it's all kubuntuish?
[13:22] <infinity> ScottK: Also, we're going to do one last upload of something in kubuntu-live, and then our arm64 porting madness is done and won't touch your packagesets/seeds anymore.
[13:32] <pitti> infinity: uploaded
[13:52] <ScottK> infinity: I have an Kubuntu needed jockey upload I'm preparing.  If no one else got to plasma-nm, I'll look at it.
[13:53] <infinity> ScottK: Happy to review your upload for you.  I'm mostly just deferring uploads that AREN'T from you, so you don't have a sad if we approve something you didn't want. :P
[13:54] <ScottK> OK.
[14:04] <seb128> infinity, lool, didrocks: ^
[14:05] <lool> seb128: Err
[14:05] <lool> seb128: ah
[14:05] <lool> seb128: I was confused
[14:05] <didrocks> seb128: thanks!
[14:05] <seb128> lool, new source/binary for the ringtone/notification sounds
[14:05] <seb128> didrocks, yw!
[14:05] <seb128> that's indeed nicer to have those
[14:05] <didrocks> seb128: is that replacing another packages (the one containing old sounds)
[14:05] <seb128> didrocks, not in the packaging sense
[14:06] <didrocks> different path/name/settings?
[14:06] <seb128> didrocks, but it makes ubuntu-sounds useless on the touch, though I would prefer not removing it due to user config/upgrades
[14:06] <seb128> didrocks, yes, new directories
[14:06] <seb128> didrocks, /usr/share/sounds/ubuntu/{ringtones,notifications}
[14:07] <seb128> didrocks, lool: I've a system-settings mr coming to use the new directories then
[14:07] <didrocks> ok, you changed it in system-settings as well
[14:07] <seb128> ^
[14:07] <seb128> ;-)
[14:07] <didrocks> not sure what's the process, because if I NEW it, we still need the archive admin +1
[14:07] <seb128> didrocks, that and changing default in gsettings-ubuntu-touch-schemas
[14:07] <didrocks> sorry release team +1
[14:08] <seb128> didrocks, infinity said he was ok with a new source earlier
[14:08] <seb128> let him comment still though
[14:08] <seb128> didrocks, I'm thinking changing gsettings-ubuntu-touch-schemas' default then and make it depends on ubuntu-touch-sounds
[14:09] <lool> seb128: ok, so should go together with meta then
[14:10] <seb128> lool, well, I was suggesting ^
[14:10] <seb128> lool, e.g changing the default and make the default package depends on it
[14:10] <seb128> that would lock the depends with the change
[14:10] <didrocks> seb128: makes sense
[14:15] <ScottK> infinity: I've uploaded jockey.  ^^^ Assuming you think that's OK, please accept and then respin Kubuntu once it and plasma-nm are in.  I don't know of any other Kubuntuish changes.
[14:15]  * ScottK vanishes offline for awhile.
[14:16] <infinity> didrocks: If you're okay with it from a NEW/AA perspective, I'm okay with it from a review POV, since it clearly doesn't affect desktop.
[14:33] <didrocks> infinity: seb128: source NEWed
[14:34] <seb128> didrocks, thanks
[14:34] <shadeslayer> infinity: the Kubuntu ISO is almost on the verge of being oversized and for some reason it has l10n for packages on that are not on the ISO ( kdevelop-l10n ), we're trying to get that fixed right now
[14:34] <shadeslayer> infinity: just thought I'd let you know
[14:35] <didrocks> yw
[14:36] <infinity> shadeslayer: Sure.  You're welcome to fix seeds and respin to your heart's content, you have whole DAYS until release, after all. :)
[14:38] <shadeslayer> infinity: please hold our respin for now
[14:56] <shadeslayer> infinity: could you let in about-distro?
[14:56] <infinity> shadeslayer: We're still cronned right now.  I should turn that off soon.
[14:56] <shadeslayer> aha okay
[14:57] <shadeslayer> infinity: I'd also like the release team's opinion on the 2 potential fixes we can do for the Kubuntu ISO
[14:57] <infinity> shadeslayer: I'm all ears.
[14:58] <shadeslayer> 1) language-pack-kde-en currently depends on kdevelop*l10n , a app that we don't ship on the CD
[14:58] <shadeslayer> if we downgrade to recommends we can free up space
[14:58] <infinity> shadeslayer: You install with recommends, downgrading won't remove it from the ISO.
[14:58] <shadeslayer> suggests then
[14:59] <infinity> shadeslayer: Also, the point of langpacks is to actually give language support for all your stuff.  That might not be the best solution.
[14:59] <infinity> shadeslayer: You're not actually oversized right now, what's the concern?
[15:00] <shadeslayer> 2) We have aptdaemon and python3-aptdaemon being pulled in due to ubuntu-drivers-common because the desktop-common seed has it
[15:00] <shadeslayer> we don't actually use ubuntu-drivers-common ( we still have jockey )
[15:00] <shadeslayer> infinity: I'd like to do a kdesudo upload with more translations that might push it over the edge
[15:01] <infinity> We could just raise your size limit a bit.  It's artificial anyway, now that you're not CD sized.
[15:01] <xnox> but jockey doesn't work
[15:01] <infinity> (The drivers-common versus jockey thing is unfortunate)
[15:01] <shadeslayer> ( kdesudo had empty pot's that I fixed on Saturday, but feedback on Sunday said it didn't work, but then testing again today says it works )
[15:01] <xnox> and there is no UI for ubuntu-drivers-common, ubiquity execs it unconditionally
[15:01] <xnox> ok.
[15:02] <infinity> shadeslayer: Anyhow, I'd rather just raise the limit than try to hack things too hard here.
[15:02] <infinity> shadeslayer: And drivers-common sounds like it's necessary for the installer, even if not for the installed system?  Unless the kde frontend does evil things.
[15:03] <shadeslayer> true
[15:03] <shadeslayer> I'm writing the replacement for jockey-kde next cycle
[15:03] <shadeslayer> so it'll be gone for 14.04
[15:03] <ScottK> xnox: just fixed jockey.
[15:04] <xnox> ack.
[15:04] <shadeslayer> infinity: <apachelogger> shadeslayer: that does not have kubuntu council backing right now
[15:04] <apachelogger> yo
[15:04] <xnox> shadeslayer: would it be ubuntu-drivers-common compatible or some such? or something different?
[15:04] <shadeslayer> xnox: ofcourse
[15:04] <xnox> shadeslayer: ah, ok.
[15:05] <shadeslayer> xnox: it'll use the u-d-c python api
[15:06] <apachelogger> I do not think that bumping ISO limit without getting the kubuntu council to agree to that is a good idea
[15:06] <infinity> apachelogger: Do we really need council backing to raise the limit by a few MB? :/
[15:06] <infinity> apachelogger: I'm not sure neutering langpacks is a better plan.
[15:07] <apachelogger> infinity: I am reasonable certain that getting rid of aptdaemon would make twiddling with langpacks unnecessary ;)
[15:09] <shadeslayer> apachelogger: fwiw I still don't see what pulls in aptdaemon
[15:10] <apachelogger> ubuntu-drivers-common recommends pkcompat.aptdaemon which depends aptdaemon
[15:11] <shadeslayer> !info pkcompat.aptdaemon
[15:11] <ubot2> 'maverick' is not a valid distribution:
[15:11] <shadeslayer> !info pkcompat.aptdaemon saucy
[15:11] <ubot2> 'saucy' is not a valid distribution:
[15:11] <shadeslayer> whut
[15:11] <shadeslayer> apachelogger: virtual package?
[15:11] <apachelogger> dude
[15:11] <apachelogger> look at germinate
[15:11] <apachelogger> http://people.canonical.com/~ubuntu-archive/germinate-output/kubuntu.saucy/desktop-common
[15:11] <apachelogger> python3-aptdaemon.pkcompat is the package name
[15:12] <shadeslayer> aha that makes more sense now
[15:13] <apachelogger> infinity: about-distro 1.0.0-0ubuntu2 (Waiting for approval) <- would be good if that got in for the final btw, otherwise there's terrible bugged information in the about-kubuntu dialog
[15:22]  * ScottK can look.
[15:23] <ScottK> apachelogger: Accepted.  Thanks.
[15:23] <apachelogger> thank you
[15:24] <ScottK> apachelogger and shadeslayer: Let's get kdesudo in and then see where we are size wise before we fiddle the language packs too much.
[15:34] <shadeslayer> ScottK: ack
[15:43] <shadeslayer> kdesudo uploaded
[15:59] <ScottK> infinity: Once kdesudo has landed, could we have a pre-emptive respin for kubuntu i386/amd64 so we can see where we are size wise?
[16:00] <shadeslayer> ^^
[16:07] <infinity> ScottK: Yeahp.
[16:08] <ScottK> infinity: Thanks.
[16:53] <infinity>    kdesudo | 3.4.2.4+repack-2ubuntu2 | saucy/universe | source, powerpc
[16:53] <infinity>    kdesudo | 3.4.2.4+repack-2ubuntu2 | saucy-proposed/universe | amd64, armhf, i386
[16:54] <infinity> Dear rmadison, wtf?
[16:57] <lool> so there's a new source coming up, qtpowerd; I got this pre-looked at by didrocks and seb128
[16:57] <lool> it was living in coreapps daily PPA pulled into touch image
[16:57] <lool> (now that it's picked up as a dep by another app in archive, we had to move it out)
[16:59] <cjwatson> infinity: might have opened its caches at slightly different times
[16:59] <lool> infinity: Hey, there's an ubuntu-themes update staged in PPA that tedg just told me we want to replace some touch icons; this is the mp that went in: https://code.launchpad.net/~tiheum/ubuntu-themes/new_icons/+merge/189904
[16:59] <lool> infinity: the lsdiff is all under ubuntu-mobile/ icons
[16:59] <lool> http://paste.ubuntu.com/6236750/ <- bzr diff -c 323 | lsdiff
[16:59] <lool> infinity: would this be ok to upload?
[17:02] <infinity> lool: Yep.
[17:03] <lool> Thanks; just doing a test with it myself in case it screws up our image and then we cant upload to fix it  :-)
[17:05] <infinity> lool: I believe the response to that would be something like "sucks to be you". :)
[17:05] <infinity> lool: So, yes, test away.
[17:17] <infinity> cjwatson: Admit it, you only fixed that build failure because of the package name.
[17:22] <ogra_> hah
[17:23] <ogra_> as long as he doesnt fix libcaca right afterwards
[17:30] <ScottK> infinity: I looks like kdesudo is there now.
[17:30] <infinity> ScottK: I already started your builds, so I hope so. :P
[17:30] <ScottK> Excellent.  Thanks.
[17:44] <lool> cjwatson: hey
[17:44] <lool> cjwatson: I think I need some help unblocking qtpowerd
[17:44] <lool> cjwatson: it's a new source we're trying to push from cu2d, but I guess it's not in the allowed list
[17:44] <lool> cjwatson: didrocks and seb128 had a look; seb128 said he'd NEW it
[17:48] <infinity> lool: Probably needs adding to stacks/saucy/platform.cfg?
[17:48]  * infinity handwaves a bit.
[17:48] <infinity> This isn't intuitive at first glance.
[17:49] <lool> infinity: it's in the sdk.cfg stack actually
[17:49] <lool> dont ask
[17:49] <infinity> Oh, as in it's already been added and I need a bzr pull?
[17:49] <lool> infinity: (hud in unapproved fixes some crashers seen on touch, seeded in desktop)
[17:50] <lool> infinity: Yes
[17:50] <lool> infinity: I dont know what needs to happen to take it though
[17:50] <infinity> Gah, that pulled... A lot.
[17:50] <infinity> I hope that wasn't a very bad idea.
[17:52] <infinity> Anyhow, you might be good to go now?
[17:57] <stgraber> would appreciate it if someone could review my edubuntu-artwork upload.
[17:58] <stgraber> someone unfortunately decided to change the name of the default wallpaper in Edubuntu without dealing with all the possible consequences... that upload adds the required symlink to make this work (didn't feel like reverting the previous change since that'd break anyone who already installed saucy)
[18:02] <infinity> stgraber: I see no symlink in that diff...
[18:02] <infinity> Oh, or is this a debian native package where you literally just put in a symlink and it's copying it.
[18:02] <infinity> Which diff won't even notice.
[18:04] <infinity> Indeed it is.
[18:06]  * infinity goes to find a sandwich and drink before getting back to work.
[18:07] <stgraber> infinity: thanks
[18:07] <lool> infinity: ubuntu-themes above is the one we discussed earlier
[18:07] <lool> infinity: bon appétit
[18:08] <lool> infinity: AH already accepted, thanks
[18:11] <maxb> ls
[18:12] <maxb> oops, sorry
[18:13] <maxb> Hi. I discovered today that anything using python-qscintilla2 in saucy segfaults on startup. However, a no-change rebuild of qscintilla2 seems to fix it. I'm filing a bug now, but should I be telling anyone specifically, given the proximity to release?
[18:22] <ScottK> maxb: What are you using it with?
[18:23] <infinity> maxb: Any explanation as to why a rebuild fixes it?
[18:23] <ScottK> infinity: The likely explanation is sip4 madness.
[18:24] <ScottK> Upstream supports letting you know when the API has changed, but on ABI you win some, you lose some.
[18:24] <ScottK> Mostly win, but still some lose.
[18:25] <infinity> Well, I'm all for said no-change rebuild then, if you want to.  You're the only people with it seeded.
[18:25] <maxb> The app I most care about is tortoisehg
[18:26] <ScottK> sip4 madness might also explain Bug #1221120
[18:26] <ubot2> Launchpad bug 1221120 in calibre (Ubuntu) "calibre crashed with SIGSEGV in PyObject_Call()" [Medium,New] https://launchpad.net/bugs/1221120
[18:27] <ScottK> maxb: OK.  Let's do it then.
[18:27] <maxb> However, whilst the no-change rebuild fixed the trivial test program I was using, I discovered moments from submitting the bug it doesn't fix tortoisehg
[18:27] <ScottK> Oh?
[18:27] <ScottK> What about rebuilding qscintilla2 and then rebuilding tortoisehg?
[18:31] <ScottK> infinity: Actually we don't even care, it's only in the dvd seed and I don't think we build that anymore.
[18:32]  * infinity fails to see how sip4 relates to either of these packages.
[18:32] <maxb> tortoisehg is pure-python, so I don't think that will help. I guess I'll have to look for other libs to rebuild
[18:34] <ScottK> infinity: qscintilla2 uses sip in it's build system and sometimes weird shit happens.
[18:34] <ScottK> No idea though about toroisehg.
[18:34] <infinity> Oh, I see.  Some awful swig-alike.
[18:34] <infinity> Because swig wasn't bad enough.
[18:34] <ScottK> For calibre though, I see bugs in Debian and Ubuntu both right after the current sip version landed.
[18:35] <ScottK> I think it even claims to be inspired by swig.
[18:35] <infinity> Not something you want to brag about.
[18:35] <ScottK> So I plan to rebuild qscintilla2 and calibre.
[18:36]  * infinity takes a break to watch some TV before diving back into installer hacking.
[18:36] <infinity> ScottK: Feel free to self-accept no-change rebuilds, after you verify the queue's diff shows nothing but changelog.
[18:36] <highvoltage> yeah that walking dead isn't going to watch itself
[18:36] <ScottK> OK.  Will do.
[18:38] <maxb> 'hgview' is a qscintilla2 rdepend which *is* fixed by the no-change rebuild
[18:38] <ScottK> OK.
[18:38] <maxb> I assume that tortoisehg must also depend on something else broken
[18:39] <ScottK> I'll take care of rebuilding qscintilla2.
[18:50] <ScottK> stgraber and highvoltage: ^^^ I just messed with a package you've got seeded by accident.  It's a no change rebuild and it should work better for it.  Sorry for not checking first.
[18:50] <ScottK> maxb: ^^^ done.
[18:51] <stgraber> ScottK: no problem, we weren't expecting the current image to be final, so more bugfixes is fine by me
[18:56] <maxb> Thanks
[19:03] <stgraber> infinity: do you have a rough ETA for the next mass rebuild?
[19:04] <stgraber> just want to know whether I should wait for that or kick a rebuild of Edubuntu now to confirm the edubuntu-artwork change didn't mess up anything and that it works properly on upgrades too
[19:04] <maxb> Someone on the internet asserts that python-qt4 also needs a rebuild because of a sip4 update - https://bitbucket.org/tortoisehg/thg/issue/3405/segmentation-fault-with-ubuntu-gnome-1310 - I'm rebuilding it locally to verify
[19:10] <ScottK> maxb: Our python-qt4 was build after the last major sip4 update.
[19:11] <ScottK> maxb: That reference is to Debian where that may not have been true.
[19:12] <ScottK> Also he points to the calibre bug.
[19:12] <lool> I think I'll end up uploading qtpowerd by hand, waiting for cu2d to settle after its every-4h-rebuild is too long
[19:53] <infinity> lool: ^-- What's this one all about?
[19:53] <lool> oh wow that's seeded
[19:53] <lool> infinity: this one adds support for mapping URLs to click apps
[19:53] <infinity> seeded-in-ubuntu(1) is your friend.
[19:54] <lool> infinity: instead of just regular apps
[19:54] <stgraber> yeah, the library is part of the desktop images
[19:54] <lool> infinity: Yeah, seeing that
[19:54] <lool> but the service only runs on touch
[19:54] <infinity> Yeah, but "changes only apply to touch" won't cut it soon.
[19:54] <infinity> Cause any changed source means respins for resulting binaries.
[19:54] <lool> infinity: Yeah
[19:55] <lool> infinity: So I actually didn't foresee this one as being in the desktop image
[19:55] <lool> and it doesn't run there
[19:55] <lool> or I would have given a headsup on it
[19:55] <infinity> S'ok, we have installer spins coming soon anyway, I'll review it.
[19:55] <lool> infinity: so the changes are safe for desktop
[19:55] <stgraber> lool: we don't want any media to be out of date wrt the release pocket so even if the binaries are supposedly identical, that doesn't matter and still means a respin for us
[19:55] <stgraber> but yeah, since we're going to respin the world anyway, not a big deal at this point
[19:55] <lool> stgraber: Oh yes, I know the rule, I tought this one was so special to touch that it was obviously not seeded, but the lib got pulled by comon deps
[19:55] <infinity> Starting Very Soon(tm), though, I'll start rejecting, not reviewing.
[19:57] <lool> infinity: so FYI, for added fun, Mir ABI bump is coming, but tomorrow morning; in terms of seeds it's in supported, it doesn't seem to have anything in images
[19:57] <stgraber> lool: what set of source packages is that?
[19:57] <lool> ah liburl-dispatcher is pulled via the indicators, got it
[19:58] <lool> stgraber: mir
[19:58] <cjwatson> it must be more than just mir for an ABI bump
[19:58] <stgraber> lool: if that's only mir and not any rdepends (which seems unlikely), then that's fine
[19:58] <stgraber> but I believe some of the rdepends are seeded
[19:59] <infinity> lool: A mir ABI bump means a new xorg, doesn't it?
[19:59] <stgraber> mesa also comes to mind
[19:59] <infinity> Oh, unless it's just mirclient.
[19:59] <lool> stgraber: oh sorry, yes, we need to rebuild rdeps; didn't understand the question at first
[20:00] <stgraber> lool: so that's a no go, I don't want a new mesa, xorg, ... uploaded tomorrow
[20:00] <lool> usually this implies platform-api, unity-system-compositor, and another one, probalby unity0mir
[20:00] <infinity> Err, wait.
[20:00] <infinity> lool: Is this just libmirserver?
[20:00] <lool> infinity: I /think/
[20:00] <ScottK> infinity: Here's a fun one for you: currently kde4libs is uninstallable on arm64 due to katepart not being built.  Kate (source for katepart) isn't built because pykde4 isn't built yet.  Pykde4 (and it appears only pykde4 out of the KDE stack) was build-deping on boost 1.49 still (which isn't built yet on arm64), but it internally insists 1.52 is the minimum version, so I don't know how it ever built.  Mixing boost versions on KDE packages is
[20:00] <ScottK> bad, so I think changing pykde4 to use 1.53 is overall more sane and should clear a large stack of arm64 uninstallables.
[20:00] <ScottK> Test building now.
[20:01] <cjwatson> ah, I'd been working throgh kde4libs's deps but hadn't reached that one yet.
[20:01] <infinity> ScottK: Oh, see, I'm building boost1.49 right now for that reason. :P
[20:02] <lool> Hmm can someone help me with a chroot problem on armhf: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5103085
[20:02] <cjwatson> lool: yes
[20:02] <lool> W: GPG error: http://ppa.launchpad.net saucy Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 4551428E52D62F45
[20:02] <lool> W: Failed to fetch bzip2:/var/lib/apt/lists/partial/ftpmaster.internal_ubuntu_dists_saucy_universe_binary-armhf_Packages  Hash Sum mismatch
[20:02] <stgraber> lool: so if it's only libmirserver it may be fine (as in, it looks like it's touch-only), if it also touches libmirclient, then it's a no-go (at least from me)
[20:02] <infinity> lool: Just retry.
[20:03] <lool> stgraber: last time it was mirserver only and I dont see why the changes would require client abi change, but will confirm
[20:03] <infinity> lool: I concur with stgraber on this, a client ABI bump's just plain not happening at this point.
[20:05] <infinity> lool: As for builds that fail with Hash Sum Mismatch, that just means you were unlucky enough to apt-get update and fetch Release and Packages straddling the point when the publisher switches dists trees.  A retry makes it happy.
[20:05] <lool> sounds reasonnably conservative 2.5 days before release  :-)
[20:05] <infinity> I should probably make that an auto-give-back condition.
[20:05] <lool> cjwatson, infinity: Actually dont bother, another source upload is queued for this source
[20:05] <lool> to PPA
[20:08] <lool> infinity, stgraber: Just to confirm, it's libmirserver only
[20:09] <infinity> lool: Alright.  We can let that slide, then.
[20:09] <infinity> lool: I still reserve the right to laugh at them for breaking ABI every 3 days.
[20:09] <ScottK> infinity: Assuming it builds with 1.53, I think we're overall better to update it.
[20:09] <infinity> ScottK: Your call, your packageset.
[20:09] <ScottK> OK.
[20:11]  * infinity opts for a change of scenery from the really nice office network to the really not nice hotel network, because the hotel has a higher chance of alcohol and cozy pillows.
[20:11] <ScottK> Dress code is probably more relaxed too.
[20:12] <infinity> I dunno, it's just elmo and I here, I can probably get away with wearing whatever I want, so long as it's pink.
[20:13] <ScottK> Yes, but at the office, you do have to be wearing something.
[20:13] <infinity> Why?  I'm pink.
[20:13] <doko> is elmo opposed to a more relaxed dress code?
[20:21] <ScottK> infinity: pykde4 uploaded.
[20:22] <infinity> Accepted for the Ghostbusters reference.
[20:22] <infinity> Of course, boost1.49 also just built. :)
[20:22] <infinity> But meh.
[21:06] <rsalveti> can anyone approve ^? adding extra function call so we can better sync the texture id when playing videos with the mediaplayer-app
[21:09] <cjwatson> Sure
[21:10] <rsalveti> awesome, thanks again
[21:11] <cjwatson> Damn, looks like I'm going to be pipped at the post for upload count this release by some busy little so-and-so called "Ubuntu daily release"
[21:12] <lool> cjwatson: so for some reason cu2d is unhappy about pushing qtpowerd (new source); I've given up and have uploaded by hand, but maybe you know what's going on?
[21:13] <cjwatson> I know very little about cu2d
[21:13] <lool> cjwatson: http://10.97.0.1:8080/job/cu2d-sdk-saucy-3.0publish/29/console is the lp error I'm getting
[21:13] <cjwatson> Not even totally sure where to find its logs
[21:13] <lool> bzr: ERROR: Parent not accessible given base "bzr+ssh://bazaar.launchpad.net/+branch/qtpowerd/" and relative path "../../../+branch/qtpowerd/"
[21:14] <lool> I wonder if it's because we moved it across teams earlier
[21:14] <cjwatson> That sounds like it might be a stacking error
[21:15] <infinity> cjwatson: I always seem to hover somewhere around #10, so being beat by a bot isn't hurting my feelings.  I like to pretend that it's a question of quality over quantity.
[21:15] <cjwatson> Did it use to be https://code.launchpad.net/~music-app-dev/qtpowerd/trunk, or is that different?
[21:15] <lool> yes, that's the old one
[21:15] <lool> the new one is ~phablet-team instead
[21:15] <cjwatson> Try "bzr reconfigure --unstacked lp:qtpowerd"
[21:15] <lool> I pushed the old one to new one, but it stacked on the old one
[21:16] <lool> crazy secret runes
[21:16] <lool> :-)
[21:16] <lool> cjwatson: done, let me retry the publish
[21:16] <cjwatson> You'd have needed to unset the development focus branch first I think
[21:16] <cjwatson> Give it a minute
[21:16] <cjwatson> OK, stacked-on has vanished from the UI, so yes, try again now
[21:17] <cjwatson> Still not happy
[21:18] <cjwatson> Do you know or can you guess what "bzr lp-propose" command it's running
[21:18] <cjwatson> ?
[21:18] <lool> hmm
[21:19] <lool>     mergeinstance = subprocess.Popen(["bzr", "lp-propose-merge", parent_branch, "-m", PACKAGING_MERGE_COMMIT_MESSAGE.format(version, tip_rev, branch), "--approve"], stdin=subprocess.PIPE, env=env)
[21:19] <cjwatson> Wonder if I can run bits of it by hand
[21:20] <lool> probably
[21:20] <lool> cjwatson: we could also try after the source package I manually uploaded is in the archive
[21:20] <cjwatson> Wait a minute ...
[21:25] <cjwatson> lool: dusting off my memory of bzr internals
[21:25]  * lool steps back
[21:26] <cjwatson> lool: you're in ~phablet-team, right?
[21:27] <cjwatson> lool: There's almost certainly a better way to do this, but:
[21:27] <cjwatson> sftp bazaar.launchpad.net
[21:27] <cjwatson> cd /~phablet-team/qtpowerd/trunk/.bzr/branch
[21:27] <cjwatson> get branch.conf
[21:28] <cjwatson> Ctrl-z
[21:28] <cjwatson> sed -i '/^parent_location = /d' branch.conf
[21:28] <cjwatson> fg
[21:28] <cjwatson> put branch.conf
[21:29] <cjwatson> lool: Actually, I found the better way :)
[21:29] <cjwatson> lool: bzr config -d lp:qtpowerd --remove parent_location
[21:31] <lool> cjwatson: yes
[21:32] <cjwatson> lool: ok, so please run that bzr config command (and ignore my fumbling before it)
[21:32] <lool> done
[21:32] <lool> the branch.conf run was interesting though  :-)
[21:32] <cjwatson> lool: now try again
[21:33] <cjwatson> Yay, that's happier
[21:33] <lool> passed!
[21:33] <lool> cjwatson: so might end up with two uploads in unapproved
[21:33] <lool> cjwatson: pick one  :-)
[21:34] <lool> I've download the .dsc from PPA and uploaded by hand, so pretty similar except for the changes and some timestamps
[21:34] <cjwatson> I should really be finishing my parted fix instead of reviewing stuff :)
[21:35] <cjwatson> s/my/psusi's and my/
[21:35] <lool> ok
[21:36] <lool> stgraber: You cant possibly be celebrating Columbus day and eating chicken?  :-)  Mind picking one of the two qtpowerd's in New and reviewing it?
[21:36] <skellat> s/Columbus Day/Thanksgiving Day/
[21:36] <lool> ah Canadian Thanksgiving indeed
[21:37] <doko> Shutdown day is missing on this list of bank holidays
[21:37] <lool> erf
[21:38] <stgraber> lool: I may take a look later but I'm busy with some !work activities at the moment
[21:41] <lool> Hmm
[21:41] <lool> that reduces the options
[21:42] <stgraber> well, I'm sure we have some non-US, non-Canada archive admins :)
[21:43] <lool> Laney: still around?
[21:44] <Laney> I'm not an archive admin
[21:44] <lool> ah right, RT
[21:44] <Laney> but in case you wanted to just say hi
[21:44] <Laney> hello ;-)
[21:44] <lool> Laney: Hey!
[21:44] <lool> doko: Hey there, would you mind NEWing qtpowerd?
[21:46] <lool> slangasek: If you're passing by... ^
[21:50] <seb128> lool, NEWed
[21:50] <lool> seb128: ah thanks
[21:50] <seb128> yw
[21:50] <cjwatson> ^- fix for critical bug 1220165.  Very hard to read on its own due to being patch-of-patch and the original patch being a refactoring already; if you want to review the new logic I suggest unpacking the package and running "quilt push -a"
[21:50] <ubot2> Launchpad bug 1220165 in parted (Ubuntu) "Error informing the kernel about modificatons" [Critical,Fix committed] https://launchpad.net/bugs/1220165
[21:52] <cjwatson> Looks like that actually took the copy, fortunately
[21:56] <seb128> cjwatson,
[21:56] <seb128> ups
[21:56] <seb128> cjwatson, if that was about qtpowerd, I accepted the sync first, then I was not sure what to do with the other in the queue
[21:56] <cjwatson> Yeah
[21:57] <cjwatson> Seems to have worked out anyway
[21:57] <seb128> good
[21:57] <seb128> the second one returned an error in the webui saying the files already existed (or something around those lines)
[22:16] <lool> cjwatson: Gah
[22:16] <lool> cjwatson: I've lost another qtpowerd upload; this time, it went out of cu2d successfully
[22:16] <lool> cjwatson: but wasn't picked up by the 5mn cron
[22:17] <lool> packagelist_rsync_sdk-saucy has it:
[22:17] <lool> ubuntu-unity/daily-build        Release saucy   Proposed        saucy   qtpowerd        0.2+13.10.20131014.3-0ubuntu1   0
[22:25] <cjwatson> lool: Sorry, I'm really EOD now, hopefully somebody else can look
[22:25] <lool> Ok
[22:26] <lool> I'll copy the binary packages manually and we'll fix this up tomorrow morning
[23:25] <lool> ah desktop-core packageset
[23:25] <lool> but not seeded-in-ubuntu
[23:25] <lool> stgraber: Would you mind reviewing this one?
[23:25] <lool> or infinity ^
[23:43] <lool> thanks
[23:44] <ScottK> infinity: There's a dependency loop that needs breaking in KDE.  kate is unbuildable because python-kde4 is uninstallable.  Python-kde4 is uninstallable because kde-runtime isn't built yet.  kde-runtime is waiting on libqapt-dev.  qapt (source for libqapt-dev) is waiting for kdelibs-dev to be installable, which needs katepart from kate (see the start of the circle).  Suggestions?
[23:45] <infinity> ScottK: Can probably break that out of archive tomorrow.
[23:45] <ScottK> Cool.
[23:45] <ScottK> Thanks.
[23:47] <ScottK> If you do a local build of kde-runtime with the qapt stuff removed, you can probably use that to get python-kde4 installable and break the chain.
[23:52] <wgrant> ScottK: It's rather simpler than that, actually.
[23:52] <ScottK> OK.  What's your approach?
[23:53] <wgrant> ScottK: Isn't kdelibs5-dev only uninstallable because it hasn't migrated?
[23:53] <ScottK> I don't think so.
[23:53] <wgrant> kde4libs as a whole is stuck in -proposed because kdelibs5-plugins needs kate and katepart
[23:54] <wgrant> qapt is in release
[23:54] <ScottK> We build against -proposed, so it's uninstallable even with -proposed.
[23:54] <wgrant> No, sadly not
[23:54] <wgrant> arm64 violates that rule
[23:54] <ScottK> Oh.
[23:54] <wgrant> Due to some Launchpad oddities, builds ended up in release
[23:54] <wgrant> So we can end up with deadlocks like this
[23:54] <wgrant> (though this is only the third, fortunately)
[23:54] <ScottK> Sigh.
[23:54] <wgrant> There's no loop here; cjwatson/infinity just need to put kde4libs in the bootstrap archive or force its migration
[23:55] <wgrant> And it should work
[23:55] <infinity> Oh, that's all?  I can do that right now.
[23:55] <ScottK> It still won't be installable until kate builds.
[23:56] <wgrant> It also needs debconf-kde, but that's in release and also buildable once kdelibs5-dev is available
[23:57] <infinity> kde5libs-dev is there now.
[23:57]  * ScottK doesn't see it, but OK.  I'm all for throwing it in there and seeing if it sticks.
[23:57] <wgrant> kdelibs5-dev doesn't need katepart at all AFAICT
[23:57] <wgrant> Only kdelibs5-plugins does
[23:57] <wgrant> infinity: Did you put all of kde4libs in?
[23:58] <infinity> wgrant: I did.  Unless there are bits in universe.  Sec.
[23:58] <wgrant> Great
[23:58] <infinity> There.
[23:58] <ScottK> Ah.  The katepart depends in unversioned, so that should actually work.
[23:59] <wgrant> We'll know in a few seconds...