[01:14] <RAOF> apachelogger: Yo!
[01:14] <RAOF> apachelogger: Would you kindly re-upload muon to saucy-proposed, with both changelog entries in the .changes file? Thanks.
[01:48] <infinity> cjwatson: Okay, seed shuffling done to remove kernel ABIs.
[01:48] <infinity> cjwatson: In the end, the diff between old and new looks like so: http://paste.ubuntu.com/6876424/
[01:49] <infinity> cjwatson: That will put two tiny < 1k packages on the CD, I suppose, but otherwise, looks harmless and generally correct, so I'm happy with it.
[01:49] <infinity> cjwatson: (To be clear, that's a diff of germinate output, not the seeds)
[01:50] <dupingping> how to contigure window reponse timeout?
[01:50] <infinity> dupingping: This isn't a support channel, you want #ubuntu
[01:52] <dupingping> yes
[03:04] <YokoZar> infinity: I intended wine-mono to be multiverse alongside wine-gecko
[03:04] <YokoZar> cjwatson: and I believe that note is already there
[03:05] <YokoZar> The debian equivalent would be contrib (free software with a nonfree build dependency/build step, in this case the step on windows)
[03:06] <infinity> YokoZar: Kay.  I'll re-review with that in mind, then.
[03:08] <infinity> YokoZar: (would have helped if you had multiverse or non-free in debian/control, so the queue would have sent it there instead of universe by default, but I'll override)
[03:09] <YokoZar> I didn't know the control file could contain that metadata
[03:09] <YokoZar> sorry about that
[03:10] <infinity> YokoZar: "Section: non-free/otherosfs" would be the Debian way (and out queue automatically does s/non-free/multiverse/) or, of course, "Section: multiverse/otherosfs" if it's just for Ubuntu.
[03:10] <infinity> s/out/our/
[03:11] <infinity> But no big deal for me to override it.  Would have just been nice to have the hint of intent. :)
[03:17] <infinity> YokoZar: Do I want to know why the debian directories in these are almost as large as the orig?
[03:18] <infinity> YokoZar: Or is that where the prebuild .msi lives?
[03:18] <infinity> s/build/built/
[03:18]  * infinity is still downloading... Having bandwidth issues tonight.
[03:19] <StevenK> infinity: Did you move back to Australia and not notice?
[03:19] <infinity> StevenK: I sure hope not.
[03:30] <YokoZar> infinity: unless I accidently left stale files around again...
[03:32] <YokoZar> infinity: but yes the prebuilt .msi file is in the debian changes
[03:36] <infinity> YokoZar: Kay, that accounts for the hugeness, thanks.
[04:32] <cjwatson> mhall119: I never understood the sense behind doing anything else in the first place :-)
[04:32] <mhall119> thanks cjwatson
[04:32] <cjwatson> infinity: yay, cute
[05:25] <pitti> Good morning
[07:48] <apachelogger> RAOF: muon with both entries uploiad to saucy-proposed
[08:09] <pitti> Searching for GRUB installation directory ... found: /boot/grub
[08:09] <pitti> /etc/default/grub: line 1: syntax error near unexpected token `('
[08:09] <pitti> run-parts: /etc/kernel/postinst.d/x-grub-legacy-ec2 exited with return code 2
[08:09] <pitti> cjwatson: ^ is that known?
[08:09] <pitti> that happens on our i386 trusty VMs since yesterday, and breaks a number of tests
[08:10] <pitti> e. g. https://jenkins.qa.ubuntu.com/job/trusty-adt-ubiquity/164/ARCH=i386,label=adt/console
[08:10] <cjwatson> not known
[08:10] <cjwatson> what's in that file?
[08:11] <cjwatson> also grub2 hasn't changed for about a week
[08:11] <pitti> ok, if you didn't see it yet then this might be local to our VMs/cloud-init; I'll check
[08:12] <cjwatson> certainly possible
[08:12] <cjwatson> that seems like an unlikely kind of general problem
[08:13] <pitti> /etc/default/grub is binary garbage in that VM
[08:13] <pitti> ok, that certainly looks like a weird qemu/sun rays/whatever issue
[08:14]  * pitti rebuilds that VM
[08:14] <pitti> cjwatson: ok, sorry for the noise
[08:14] <cjwatson> no problem
[08:37] <asac> cjwatson: hi ... slangaseks protobuf upload broke the ABI accidentially i think
[08:37] <asac> cjwatson: http://ci.ubuntu.com/smokeng/trusty/touch/mako/164:20140205:20140115.1/6457/dialer-app-autopilot/735638/
[08:37] <asac> cjwatson: see once.h change here: https://launchpadlibrarian.net/164839352/protobuf_2.5.0-5ubuntu2_2.5.0-7ubuntu1.diff.gz
[08:37] <asac> seems a sneaky ConstructorImpl through inline function exposure
[08:37] <asac> oversight
[08:37] <cjwatson> asac: I saw the scrollback in #ubuntu-ci-eng, but I kind of ought to be focusing on 12.04.4 today, so I'm not sure I have the bandwidth to come up to speed on a C++ library
[08:37] <smoser> xnox, were you able to get anything functional for overlayroot
[08:38] <cjwatson> perhaps somebody else could be found?
[08:38] <asac> cjwatson: yeah. just looking for someone to confirm that this was a SONAME bump oversight and help to back it out :)
[08:38] <asac> so we can refactor this or bump SONAME
[08:39] <cjwatson> backing out will be very complex as it had to go in together with a bunch of other things
[08:39] <cjwatson> at least I think that was that upload
[08:39] <asac> cjwatson: hmm. whatelse?
[08:39] <cjwatson> don't remember
[08:39] <cjwatson> give me a few minutes
[08:39] <asac> thanks. just check if there is a quick way out... otherwise let me know who I could ask :)
[08:41] <cjwatson> oh, 2.4.1-3ubuntu4 -> 2.5.0-5ubuntu2 was the complex soname-bumping one
[08:41] <cjwatson> we shouldn't bump soname without careful thought as this is used by rather more than just touch
[08:42] <smoser> xnox, this is what i tried, but didn't seem to work: http://paste.ubuntu.com/6877895/
[08:46] <cjwatson> asac: so now would be a great time for the suggestion I made of having a PPA used by touch which is allowed to be deliberately behind the primary archive for short periods of time, so we could copy the old version into it to get touch moving again while we diagnose the issue in the primary archive
[08:46] <cjwatson> asac: which I don't suppose anyone's implemented :)
[08:52] <cjwatson> it ought to be possible to stitch some kind of compatibility arrangement back in while still respecting the intent of the changes made for Debian #736801 (and maybe make sure symbols files cope with this, while we're there), but my C++ really isn't up to it
[08:52] <cjwatson> perhaps xnox might have time to take a look?
[08:52] <cjwatson> or we could sort out a touch-specific reverting PPA real quick and punt the problem to the Debian maintainer
[08:52] <asac> xnox: like some C++ magic hackery in the morning? :)
[08:52] <cjwatson> since we should have such a thing anyway
[08:53] <asac> we can talk about that in todays meeting
[08:53] <cjwatson> I don't think I can make today's, I got three hours of sleep and I still have a bunch of stuff to do for 12.04.4
[08:53] <cjwatson> also we've talked about it in previous meetings.  why more meetings?
[08:54] <asac> cjwatson: are we sure that this problem is really touch confined? i sense we might have breakage all over the archive now
[08:54] <asac> just that we see it here clearly
[08:55] <cjwatson> I'm upgrading to see if mumble is affected, since it's a reverse-dep
[08:56] <cjwatson> ah yeah, mumble fails to start
[08:56] <asac> dont worry about the meeting. and dont worry about this problem if you are doing allnighters...
[08:56] <cjwatson> as does ccsm
[08:57] <asac> i just think the backout is the problem we should solve :) ... e.g. figure a way to find whatelse got uploaded alongside so we can just get all that car wreck off the autobahn while we investigate how to fix the protobuf patch
[08:57] <cjwatson> ok, let me see if I can just back this out with a reupload; it wasn't a new upstream or anything
[08:57] <cjwatson> there was nothing else alongside, that was my mistaken memory
[08:57] <asac> right
[08:58] <asac> i think it wasnt a SONAME bumop
[08:58] <asac> so only what was built after or alongside could be affected
[08:58] <cjwatson> indeed not
[08:59] <cjwatson> xnox: (stand down, I'll deal with this until slangasek gets back)
[08:59] <asac> we have invested heavily in getting folks out of ppas... its very hard for me to get a ppa back and then figure reasonable black and white rules that will ensure we use this ppa only exactly for the right cases
[08:59] <cjwatson> you didn't raise that point in the last meeting when we talked about this :-(
[08:59] <cjwatson> "may only be used to copy old versions from the primary archive pending better fixes" seems pretty clear
[08:59] <asac> yeah sorry. not sure when we last talkeda bout it though
[09:00] <cjwatson> couple of months ago I think
[09:00] <asac> cjwatson: that sounds better. let me think about that
[09:00] <cjwatson> after saucy, at least
[09:00] <xnox> smoser: was busy uploading message-less shutdown, will look into overlayroot more today.
[09:01]  * xnox read the rest of scrollback.
[09:02] <cjwatson> the change in nm -C -D output (with the addresses removed) is http://paste.ubuntu.com/6877972/
[09:02] <cjwatson> so I don't think we risk converse breakage by backing out the change
[09:03] <asac> cjwatson: we should check all reverse build deps that got uploaded afterwards i guess
[09:03] <asac> but beyond that it looks safe to me (but then i am very out of this)
[09:04] <asac> wonder why we have a + AND -
[09:04] <cjwatson> asac: well, if there are no new symbols (other than weak copies of libc stuff) we aren't going to break things by going back
[09:04] <cjwatson> and that appears to be the case
[09:04] <cjwatson> s/weak copies of/references to/
[09:05] <cjwatson> the only + is a reference to pthread_once - that's not something libprotobuf *exports*, it's something it *imports*
[09:05] <asac> yeah you are right
[09:05] <asac> guess not bumping with - is generally scary as seen through the inline header leakage here ... this protobuf should really hide symbols that are Impl/Internal :)
[09:06] <cjwatson> yeah, no doubt, too late now for this soname though
[09:07] <cjwatson> ha, there's already a 2.5.0-8 in experimental which I think backs this out
[09:08] <cjwatson> bacon sandwich then I'll check that
[09:08] <asac> cjwatson: can we backout anyway? believe its better if steve can look at that with fresh eyes? :)
[09:08] <xnox> cjwatson: i wonder if protobuf breakage transitively leaked into libmirprotobuf0 as well.
[09:08] <asac> but your call
[09:08] <asac> cjwatson: was that uploaded after?
[09:08] <asac> err
[09:08] <xnox> cjwatson: which is not easy to check, since mir is not using .symbol files =(
[09:08] <asac> xnox: ^^
[09:08] <asac> xnox: i can have someone try
[09:08] <asac> :)
[09:09] <asac> see if tests still pass etc. after downgrading
[09:09] <asac> i think tvoss was on that task
[09:09] <xnox> right.
[09:09] <cjwatson> asac: 2.5.0-8 *is* the backout, might as well just mereg it
[09:09] <cjwatson> *merge
[09:09] <asac> cjwatson: righty
[09:10] <cjwatson> http://paste.ubuntu.com/6877999/
[09:10] <cjwatson> xnox: I'll poke it with nm in a bit
[09:10] <asac> ok if the rest of the changes are safe (which we dont know)
[09:10] <asac> but whatever is good :)
[09:11] <cjwatson> they're safe.  our gcc is already 4.8
[09:11] <asac> so yeah
[09:15] <cjwatson> I bet the dialer-app tests don't work usefully in the emulator or on grouper
[09:17] <cjwatson> xnox: mir was uploaded before the latest protobuf, so it should be fine
[09:18] <pitti> (FTR, I tested the dialer-app tests on mako and in a trusty amd64 live environment, they ought to work)
[09:18] <xnox> ack.
[09:18] <asac> cjwatson: all other AP tests also fail
[09:18] <asac> except the unity8 one
[09:18] <asac> cjwatson: http://ci.ubuntu.com/smokeng/trusty/touch/mako/164:20140205:20140115.1/6457/
[09:18] <asac> cjwatson: pick whatever works on emulatoor
[09:18] <asac> xnox: ?
[09:19] <xnox> cjwatson: weather_app is known to have been fully passing on the emulator.
[09:19] <didrocks> asac: http://people.canonical.com/~ogra/touch-image-stats/20140205.changes
[09:20] <asac> xnox: gallary?
[09:20] <asac> http://ci.ubuntu.com/smokeng/trusty/touch/mako/164:20140205:20140115.1/6457/gallery-app-autopilot/
[09:20] <didrocks> I don't know if location-service is getting worse than in 163
[09:20] <asac> didrocks: saw my mail?
[09:20] <didrocks> asac: yeah
[09:20] <didrocks> but it's not protobuf, I guess, is it?
[09:20] <asac> didrocks: tvoss is having a one line fix to get rid of the systemsettle part
[09:20] <didrocks> ok
[09:20] <asac> didrocks: thats in a mail from yesterday
[09:20] <asac> didrocks: we just didnt know how to allocate a silo fo rhim
[09:20] <ogra_> hmm
[09:20] <asac> didrocks: ping him
[09:20] <didrocks> asac: tvoos isn't around
[09:20] <didrocks> tvoss*
[09:21] <asac> didrocks: he is ... guess he dropped off freenode
[09:21] <didrocks> ah
[09:21] <didrocks> ok
[09:21] <asac> err
[09:21] <asac> he is indeed gone :)
[09:21] <asac> talked to him a minute ago
[09:21] <asac> no he is online
[09:21] <asac> on canoni
[09:21] <didrocks> yeah, I didn't see him on chans when joining
[09:21] <ogra_> curious, the first protobuf update worked fine
[09:21] <didrocks> pinged him
[09:22] <didrocks> ogra_: right, what I answered
[09:22] <asac> ogra_: protobuf broke abi
[09:22] <asac> ogra_: withotu SONAME bump
[09:22] <didrocks> but what's the diff between 163 and 64?
[09:22] <didrocks> 164*
[09:22] <asac> ogra_: is a sneaky symbol leak through inline header
[09:22] <didrocks> we know location-service broke 163
[09:22] <didrocks> not sure what broke 164 even more
[09:22] <asac> didrocks: protobuf broke all the stuff
[09:22] <ogra_> asac, protobuf bumped its api on monday
[09:22] <asac> didrocks: http://ci.ubuntu.com/smokeng/trusty/touch/mako/164:20140205:20140115.1/6457/gallery-app-autopilot/735187/
[09:22] <cjwatson> ogra_: different
[09:22] <asac> didrocks: /usr/bin/gallery-app: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libmirprotobuf.so.0: undefined symbol:
[09:22] <asac> _ZN6google8protobuf18GoogleOnceInitImplEPiPNS0_7ClosureE
[09:22] <ogra_> cjwatson, k
[09:23] <didrocks> asac: ok, not at that level yet
[09:23] <didrocks> hum
[09:23] <knome> seb128, hey, you around? what's up with xubuntu-docs; apparently 12.04.1 is not uploaded to precise? :/
[09:23] <didrocks> so something built against the new protobuf
[09:23] <cjwatson> can we stop talking about protobuf now?
[09:23] <asac> didrocks: no..
[09:23] <ogra_> there was a new Mir
[09:23] <asac> didrocks: the new protobuf dropped symbols by accident
[09:23] <ogra_> and new xorg
[09:23] <cjwatson> I'm working on it and it's distracting to have to try to follow everyone catching up
[09:23] <asac> right
[09:23] <ogra_> (see backlog in -relkease)
[09:23] <asac> didrocks: leave it to cjwats :)
[09:23] <didrocks> ok ok
[09:23] <ogra_> i dont get why i see neither of them on -changes
[09:23] <didrocks> looking at location-service
[09:23] <asac> didrocks: you might want to wade through the other failures that dont have the same symbol error in log
[09:24] <asac> didrocks: and help tvoss land location-service
[09:24] <asac> so tvoss confirmed that the AP test for addressbook at least starts if going back on protobuf
[09:24] <didrocks> asac: wait, I'm trying to get back people on shape first
[09:24] <didrocks> I can't do all analysis
[09:25] <asac> didrocks: sure, read the backlog on irclogs to catch up if you want. otherwise we are working on the parts that we understand
[09:25] <asac> (which probably is all)
[09:25]  * ogra_ still wonders where the new mir went
[09:25] <asac> didrocks: so i am going through all the failed tests... so far all bail out on this symbol
[09:26] <didrocks> asac: thanks
[09:26] <asac> didrocks: location is breaking systemsettle only (we saw that last night)
[09:26] <asac> 163 has only ss
[09:26] <didrocks> ogra_: don't even start on that one, another discussion… :p
[09:26] <asac> lol
[09:26] <ogra_> didrocks, well who would have guessed that xorg just gets updated in the middle of the landing
[09:27] <seb128> knome, https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=xubuntu-docs
[09:27] <didrocks> ogra_: I did, I pinged people to coordinate
[09:27] <seb128> knome, somebody from the SRU team needs to approve it
[09:27] <didrocks> ogra_: *before the landing*
[09:27] <ogra_> didrocks, on the day the landing happened ... this should have been planned weeks ahead on both sides
[09:27] <didrocks> ogra_: yeah, but it was read apparently and ignored
[09:28] <ogra_> we lack a communication path for such things it seems
[09:28] <didrocks> and lack of willness to fix things it seems, but anyway, I tried, I passed the messages between both parties
[09:28] <ogra_> well, by the looks of it it all went fine in the end
[09:28] <didrocks> anyway, moving on, we "just" loose a day for Mir
[09:28] <ogra_> but sadly the packages didnt actually make it into the archive
[09:28] <knome> cjwatson, any way you could approve the xubuntu-docs SRU?
[09:29] <didrocks> ogra_: no, Mir is still not published
[09:29] <ogra_> didrocks, right
[09:29] <asac> didrocks: so i discussed this yesterday... what we need is communicating transitions in prep so folks know and can either wait or join the silo
[09:29] <ogra_> is there still a MIR missing for some xorg deps ?
[09:30] <asac> didrocks: and of course improve tools to auto bump stuff we pulled into silo for a transition
[09:30] <asac> but that invalidates testing
[09:30] <asac> so best coordinate/communicate
[09:30] <tjaalton> ogra_: no, but all the drivers need to be rebuilt
[09:30] <cjwatson> knome: for 12.04.4?
[09:30] <knome> cjwatson, yes, i know it's late...
[09:30] <cjwatson> knome: does it need to be on your images?
[09:30] <ogra_> tjaalton, ugh, why didnt that happen in a PPA
[09:31] <cjwatson> rather, is that package on your images?
[09:31] <ogra_> so you can release the whole chunk
[09:31] <knome> cjwatson, the .1 release is a regression fix for .0 SRU
[09:31] <knome> cjwatson, yep
[09:31] <cjwatson> knome: let me finish this protobuf thing first, then I'll look at it.  I guess you'll want a respin then
[09:31] <tjaalton> ogra_: it did, but with version numbers not fit for the archive
[09:32] <didrocks> asac: we can't autobump
[09:32] <asac> so weather test failure doenst show this symbol thing http://ci.ubuntu.com/smokeng/trusty/touch/mako/164:20140205:20140115.1/6457/ubuntu-weather-app-autopilot/
[09:32] <didrocks> asac: or we will revert the work done in distro
[09:32] <asac> didrocks: I think we can ... lets talk about that later though :)
[09:32] <didrocks> asac: the check is there on purpose
[09:33] <knome> cjwatson, sure, thanks
[09:33] <asac> remind me when we talk next time; i think i know what to do to be able to do that
[09:43] <seb128> didrocks, asac, cjwatson: btw that protobuf issue is making compiz fails to start in trusty
[09:43] <cjwatson> seb128: I'm dealing with it
[09:44] <seb128> cjwatson, thanks
[09:55] <asac> guess defcon 4 :)
[09:56] <ogra_> unity8 still starts fine ... time that desktop switches :P
[09:56] <cjwatson> War Games has rendered me irrevocably confused about which order defcon levels go in
[09:57] <ogra_> cjwatson, asac uses the real numbering, not the movie one
[09:57] <asac> i think 5 is nuclear war :)
[09:57] <cjwatson> right, but knowing about the movie confusion means I can't remember which is which :)
[09:57] <ogra_> (i still wonder why they reversed it ... obstruction by confusion ? )
[09:57] <asac> yeah me too
[09:57] <asac> http://en.wikipedia.org/wiki/DEFCON
[09:57] <asac> so i was wrong
[09:57] <asac> 1 is nuclear war
[09:57] <ogra_> lol
[09:59] <ogra_> "Movies and popular culture often misuse the DEFCON system by "going to DEFCON 5" when a nuclear war is imminent."
[09:59] <ogra_> hmm, but nobody says *why*
[09:59] <asac> so war games might have teached us wrongly?
[09:59] <jpds> ogra_: Do you need an excuse?
[10:00] <ogra_> jpds, well, i would love to know why that seems to be done in *all* movies and tv series this way
[10:00] <ogra_> (seems thats the case)
[10:00] <ogra_> i.e. if some authority ordered it like that to confuse the enemy or some such :)
[10:01] <jpds> Well, noone used the old British one: https://en.wikipedia.org/wiki/BIKINI_state
[10:01]  * ogra_ bets there is a funny story behind it that just never leaked
[10:03] <doko> zyga, brendand: you seem to be checkboxuploaders ... there are at least 7 MIR's missing
[10:03] <doko> you guys really need to better prepare such uploads
[10:06] <brendand> doko, i guess this might relate to the branch roadmr prepared
[10:06] <brendand> doko, is there a branch/bug specifically you're talking about?
[10:06] <doko> brendand, before you start guessing, have a look at http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg ;p
[10:07] <brendand> doko, oh i see
[10:07] <brendand> doko, yes one of our binary packages depends on some sdk packages
[10:08] <spineau> doko: Not sure if it's related but I filled two MIR for checkbox future deps, #1276164 and #1276183
[10:08] <brendand> doko, i don't think we actually need to depend on cordova-ubuntu if that's the issue
[10:08] <brendand> doko, we can look to remove that dependency
[10:08] <doko> bug 1276164, bug 1276183
[10:09] <doko> brendand, sure, that's an option
[10:10] <brendand> doko, but can you help us with which source branch is being used which is generating those errors?
[10:10] <brendand> doko, is it lp:ubuntu/checkbox?
[10:10] <doko> brendand, spineau: is checkbox running with python3?
[10:10] <pitti> seb128: speaking of MIR, could indicator-datetime stop recommending indicator-applet?
[10:10] <brendand> doko, yeah
[10:10] <seb128> pitti, it doesn't
[10:10] <pitti> Recommends: indicator-applet | indicator-renderer
[10:10] <doko> brendand, no branch, it is the package which was uploaded to the archive
[10:10] <pitti> seb128: it does :)
[10:10] <seb128> pitti, indicators recommend and indicator-renderer, with unity being our default option
[10:11] <brendand> doko, yeah roadmr probably did that from lp:ubuntu/checkbox
[10:11] <pitti> seb128: ah, so perhaps this should either become just "indicator-renderer" or "unity | indicator-applet | indicator-renderer"?
[10:11] <seb128> pitti, unity provides indicator-renderer so it should be fine
[10:11] <seb128> pitti, only a virtual is wrong, unity | would be right
[10:11] <seb128> pitti, the issue atm if you look at component-mismatch is that unity didn't build yet on ppc64el
[10:12] <seb128> pitti, so it resolves to indicator-applet
[10:12] <pitti> seb128: ah, I understand
[10:12] <pitti> seb128: thanks for pointin gout
[10:12] <seb128> pitti, yw
[10:12] <doko> spineau, looks like these two MIRs are just about code re-organization. so shouldn't be an issue
[10:13] <tsdgeos> hmmm, something weird is happening with all qt4 bsed programs since today
[10:13] <tsdgeos> i get
[10:13] <doko> brendand, spineau: please make sure that checkbox runs with python3.4 , and that the tests pass
[10:13] <tsdgeos> Compiled for arch: ::Vc::AVXImpl
[10:13] <tsdgeos> Features supported:
[10:13] <tsdgeos>          "SSE2"         ---      yes
[10:13] <tsdgeos>          "SSSE3"        ---      yes
[10:13] <tsdgeos>          "SSE4.1"       ---      yes
[10:13] <tsdgeos>          "AVX "         ---      yes
[10:13] <tsdgeos> any idea?
[10:13] <tsdgeos> what is bringing that to my shell?
[10:13] <brendand> doko, we were actually wondering that - thanks
[10:13] <spineau> doko: ok, thanks. but after looking at the svg map the problem is elsewhere. we'll check what to do with this cordova package
[10:14] <cjwatson> /wg 39
[10:14] <cjwatson> sorry
[10:15] <robert_ancell> bdmurray, hi, do you plan on doing a mass "wont fix" marking of bugs on https://bugs.launchpad.net/ubuntu/raring? Laney / seb128 suggested you'd do that
[10:15] <zyga> doko: thanks, we'll look into this
[10:15] <zyga> doko: I think we had a misunderstanding about how MIRs work and we dind't propose MIRs for recommends at all
[10:16] <zyga> doko: we are working on those now
[10:16] <brendand> zyga, well the problem packages are not ours
[10:16] <brendand> zyga, they're sdk packages
[10:16] <brendand> zyga, anyway we don't need to depend on it
[10:16] <zyga> brendand: that's our problem if we're MIRing something that needs them
[10:16] <zyga> brendand: we just need to figoure out what we need to depend on and what needs to be in main
[10:20] <mitya57> tsdgeos: *All* Qt programs? That looks like calligra output.
[10:20] <tsdgeos> mitya57: yes, even bzr qlog does output that
[10:21] <mlankhorst> how often is the check running when doing dput uploads to ubuntu?
[10:22] <cjwatson> every minute
[10:22] <cjwatson> but LP was just doing a master database switch in preparation for a machine upgrade, so it might be slow just now
[10:22] <mlankhorst> ah
[10:23] <mitya57> tsdgeos: Hm, for some reason I still think it's caused by yesterday's Calligra update
[10:23] <tsdgeos> may be
[10:23] <mlankhorst> ok xorg 1.15 transition should be complete then when it switches over
[10:24] <mlankhorst> if the tegra drivers are still in the archive they should probably be deleted, I haven't had much luck with getting my tegra working on saucy, let alone trusty..
[10:36] <doko> rbasak, jamespage: with your server/puppet hat on, could you have a look at the ~200 php build failures in the test rebuild? http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140127-trusty.html
[10:43] <mitya57> tsdgeos: indeed, http://sources.debian.net/src/calligra/1:2.7.5-1/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp?hl=98#L98
[10:44] <mitya57> I think you should poke Riddell about the bug
[10:44] <tsdgeos> ohh qdebugs in code
[10:44] <tsdgeos> sigh
[10:44] <tsdgeos> and i wonder why is that getting everywhere
[10:48] <mitya57> Note that the code above is older version.
[10:50] <Sweet5hark> Heeere's Jooohny!
[10:54] <mlankhorst> well it's building but still acting funny, stuck on 'uploading build' for a lot of packages ,even though the builder is obviously building something else now. :P
[10:55] <xnox> mlankhorst: it takes a long time to upload a build, sometimes. Was it big?
[10:55] <cjwatson> which suggests that alphecca's cron jobs might not be running
[10:55] <cjwatson> mlankhorst: package name?
[10:55] <mlankhorst> cjwatson: xserver-xorg-video-ati
[10:57] <Riddell> tsdgeos: question is why a calligra lib causes debug output on starting e.g. dolphin
[10:58] <tsdgeos> Riddell: that is a good question
[11:04] <cjwatson> mlankhorst: looks like it's catching up now.  #launchpad-ops thinks it's because of backlog + temporarily on slow master db
[11:04] <mlankhorst> ah
[11:04] <mlankhorst> yeah
[11:08] <mlankhorst> it's between 26 minutes and 13 minutes behind now O:-)
[11:13] <mlankhorst> 19 minutes
[11:25] <wgrant> mlankhorst: It's caught up now.
[11:26] <mlankhorst> yeah :)
[11:28] <mlankhorst> s
[11:28] <mlankhorst> oops
[11:47] <mlankhorst> ogra_: ping
[11:47] <ogra_> yo
[11:47] <mlankhorst> can we drop nvidia-graphics-drivers-tegra(,3) from the archive?
[11:48] <ogra_> dunno, havent done anything with it in 1.5 years
[11:48] <ogra_> you could mail the ac100 ML ... they are the main consumers of it
[11:48] <mlankhorst> it's blocking the xorg 1.15 update, and I haven't had any luck getting saucy to work on mine
[11:49] <Sweet5hark> ricotz: around?
[11:49] <ogra_> (or ask in the #ac100 channel)
[11:49] <mlankhorst> k
[11:52]  * apw suspects compiz is borked in trusty, no longer connected to the x display and no windows displayed
[11:53] <ogra_> apw, it is
[11:53] <ricotz> Sweet5hark, yes
[11:53] <ogra_> apw, new libprotobuf should hit the archive soon (it is in proposed)
[11:53] <apw> DQAW
[11:54] <ricotz> Sweet5hark, did you receive my messages?
[11:54] <Sweet5hark> ricotz: unlikely, Im travelling right now.
[11:55] <ricotz> Sweet5hark, regarding the missing translation files
[11:55] <Sweet5hark> ricotz: The l10n package is broken, a fix is currently building ...
[11:55] <ricotz> Sweet5hark, all translations ..., alright
[11:55] <ricotz> Sweet5hark, precise users already complained :\
[11:56] <Sweet5hark> ricotz: https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-staging/+builds?build_state=building
[11:56] <ricotz> Sweet5hark, http://people.ubuntu.com/~ricotz/libreoffice/4.2-l10n.diff
[11:57] <Sweet5hark> ricotz: someone zipped l10n files after the beta release, this broke the l10n packaging (upstream, but only us are using it right now)
[11:58] <Sweet5hark> ricotz: I also got private mails about it, but no bug reports on launchpad or fdo. When will people ever learn ...
[11:59] <ricotz> Sweet5hark, alright, i hope this fixes it ;)
[12:00] <ricotz> Sweet5hark, be aware you need to change the version while you changed the tarball content
[12:01] <Sweet5hark> ricotz: huh, I did not regenerate the tarballs yet, so they dont need a new version?
[12:01] <ricotz> this can't be uploaded
[12:01] <ricotz> hmm, the diff indicate a lot of zips changed
[12:02] <ricotz> Sweet5hark, you had two different tarball versions!
[12:02] <Sweet5hark> ricotz: Ill do a 4.2.0 final for trusty archive anyway ...
[12:02] <ricotz> the prerelease ones and the archive ones
[12:03] <ricotz> ok
[12:04] <ogra_> Mirv, so i got some new scripts for rootstock that actually allow to build proper system-image images from ppas ... not 100% done yet, but i should be able to give you something tonight
[12:05] <ricotz> Sweet5hark, btw what is the reason not using sytem's libcmis?
[12:07] <ricotz> Sweet5hark, ah forgot about 0.4.1-3
[12:07] <Sweet5hark> ricotz: getting to the list of non-system libs just now. first getting out a release at all was priority.
[12:08] <ricotz> Sweet5hark, right
[12:08] <ricotz> Sweet5hark, not sure if things can get automatically demoted to universe again ;)
[12:09] <ricotz> if there are no consumers in main
[12:11] <ricotz> Sweet5hark, you might want to create a 4-2 ppa soon
[12:12] <Sweet5hark> ricotz: right
[12:18] <cjwatson> knome: xubuntu-docs is ready for a quick test now
[12:24] <davmor2> tseliot: :(  this morning lp tells me I got hit by bug #1231689
[12:25] <davmor2> tseliot: purging nvidia-331 and nvidia-prime have me at a working lightdm but no unity :(
[12:26] <tseliot> davmor2: in trusty?
[12:26] <davmor2> tseliot: yeap
[12:26] <tseliot> davmor2: also, what does "no unity" mean?
[12:27] <cjwatson> davmor2: the protobuf ABI regression took out compiz, hence no unity.  fix in -proposed now, in trusty shortly
[12:27] <davmor2> tseliot: I log into lightdm I get the desktop background but no unity.  So I can hit ctrl+alt+t and then get a terminal but no shell
[12:28] <davmor2> ah cjwatson awesome
[12:28] <davmor2> tseliot: could the nvidia issue be based on that too then?
[12:29] <cjwatson> hmm, ubuntuone-storage-protocol autopkgtest failure
[12:29] <cjwatson> looks like that may have already been forced somehow though
[12:30] <tseliot> davmor2: I have no idea about the protobuf ABI regression cjwatson mentioned, but usually when I get stuck and only get the background and no unity, I type "dconf reset -f /org/compiz/" and restart lightdm, and things work.
[12:33] <cjwatson> ok, this ubuntuone-storage-protocol autopkgtest failure seems to indicate a real bug
[12:33] <davmor2> tseliot: well I'll wait for the fix to land and keep an eye on things and let you know
[12:33] <cjwatson> though one that was also in 2.5.0-7ubuntu1
[12:33] <cjwatson> so I think given that this is critical I should force it through anyway, but I'll try to fix it
[12:33] <tseliot> davmor2: ok
[12:36] <asac> will gcc 4.7 be "supported" in trusty? or do we only support 4.8?
[12:36] <asac> doko: ?
[12:37] <doko> asac, I assume so, but it is for the android stack only. xnox should know better
[12:37] <cjwatson> it's still there at least until such time as nothing we ship requires it to build
[12:37] <cjwatson> and I haven't yet switched our default boot loader to 4.8 ...
[12:38] <cjwatson> I bet there are various other odds and ends too
[12:38] <asac> doko: seems we have some troubles with libstdc++ compatibilty bewteen 4.7 and 4.8 or something ...
[12:38] <asac> doko: can you check with tvoss about his troubles there?
[12:39] <asac> hi tvoss :)
[12:39] <tvoss> asac, o/
[12:39] <asac> 13:38 < asac> doko: seems we have some troubles with libstdc++ compatibilty bewteen 4.7 and 4.8 or something ...
[12:39] <asac> 13:38 < asac> doko: can you check with tvoss about his troubles there?
[12:39] <doko> asac, he should not mix ...
[12:39] <tvoss> doko, that's what I'm working on right now
[12:39] <asac> doko: its not really clear how to not mix i think... e.g. where do we draw the line
[12:39] <asac> tvoss: do we have a clear line?
[12:39] <tvoss> asac, don't mix in c++ world
[12:40] <tvoss> asac, C is fine (mostly)
[12:40] <asac> tvoss: so do we have a layer that protects us? is that platform api? e.g. everything below is 4.7, everything above is 4.8?
[12:40] <cjwatson> ubuntuone-storage-protocol> oh, never mind, it's explicitly running tests under PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp
[12:41] <cjwatson> so not really a protobuf regression in the sense I was thinking
[12:41] <tvoss> asac, yup
[12:41] <tvoss> asac, although we should really pull platform api to gcc 4.8
[12:41] <asac> tvoss: so should we systematically go to 4.7 for everything below platform API that is C++ what about MIR? isnt that below and above?
[12:42]  * asac scared that we infect the world :)
[12:42] <cjwatson> dobey: would it make sense to drop the PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp run from ubuntuone-storage-protocol/run-tests?  looks like protobuf doesn't support that any more
[12:42] <asac> tvoss: whats the prob with platform api and 4.8?
[12:42] <asac> just not building?
[12:43] <tvoss> asac, there are two things as far as I understand it: make sure that toolchains across the libc boundary match, and then make sure that the floating point conversion works/is not required anymore by transporting floats in structs
[12:45] <asac> tvoss: thats what blocks platapi on 4.8? or thats what causing 4.7/4.8 mixing havoc?
[12:45] <asac> anyway, do what you need to do :)
[12:45] <tvoss> asac, that's what blocks papi on 4.8
[12:46] <tvoss> @havoc: still figuring that out
[12:46] <udevbot> Error: "havoc:" is not a valid command.
[12:47] <knome> seb128, the image files are still not updated, even if they are marked as changed in the debdiff. how can we fix this?
[12:47] <seb128> knome, I don't know
[12:48] <knome> seb128, is that a known problem of debdiffs?
[12:48] <cjwatson> debdiffs don't represent binary files
[12:48] <seb128> knome, binary changes can't go in diff
[12:49] <seb128> if that's what you are asking
[12:49] <knome> seb128, no, i understand that
[12:49] <cjwatson> knome: does this pertain to xubuntu-docs/precise-proposed?
[12:49] <seb128> if images are svg that's text formatted and can go in diffs
[12:49] <knome> how do we propose a SRU that changes binary files?
[12:49] <knome> cjwatson, yep; the looks is now fine, but image files are still not there
[12:49] <cjwatson> attach the actual source files not a debdiff
[12:49] <cjwatson> .dsc and .tar.gz in this case
[12:50] <cjwatson> also, you had eight days to check this in the queue :-(
[12:50] <knome> yes, i'm very sorry
[12:50] <knome> it's not a huge catastrophe if the SRU goes as it is now
[12:50] <knome> but i'd of course rather fix the images as well
[12:51] <knome> and yes, i know we had time, i'm very sorry
[12:51] <knome> hmm, i said that already. well i am sorry! :)
[12:51] <cjwatson> let's push it round again, we just about have time
[12:51] <knome> sure, i'll try to catch the right people ASAP
[13:02] <knome> cjwatson, added the files to the bug report; unfortunately, the version is 12.04.0 as this is how i got the files from somebody who knows better than me; i will not touch them to not break anything :)
[13:03] <knome> cjwatson, i'll be around to verify that it works, just ping me
[13:04] <eLpm> Hello, is there someone in here?
[13:05] <eLpm> I would like some help with lp #1276562
[13:05] <cjwatson> knome: ok, ideally it'd be some sponsor other than me so that I can legitimately do the SRU shuffling
[13:05] <mlankhorst> eLpm: erm did you have -proposed enabled by any chance?
[13:05] <eLpm> The bug is not necessarily about the meta package (sorry if this is the wrong channel)
[13:06] <eLpm> Yes :D
[13:06] <eLpm> mlankhorst, Yes
[13:06] <mlankhorst> well there you go
[13:06] <eLpm> XD
[13:06] <mlankhorst> it broke and now you get to keep the pieces :-)
[13:06] <eLpm> And do you know the possible causes already?
[13:06] <cjwatson> of course the compiz failure was probably due to protobuf which was in trusty
[13:07] <cjwatson> we're publishing a fix for that at the moment
[13:07] <ogra_> eLpm, never ever enable -proposed on a devel release ... it isnt what you might think it is
[13:07] <eLpm> cjwatson, Awesome I'll wait patiently :-)
[13:08] <eLpm> ogra_, It's OK I wanted to help testing. I am dual booting currently, so no problem.
[13:08] <cjwatson> please don't enable -proposed to help testing
[13:08] <cjwatson> it doesn't help
[13:08] <cjwatson> (in the development release, that is)
[13:09] <ogra_> eLpm, -proposed is not for testing in dev treleases
[13:09] <ogra_> -t
[13:09] <cjwatson> it actively hinders us by creating noise from people running into problems that machines would have caught
[13:09] <cjwatson> I understand you mean well, but please disable it, it will be better for us
[13:09] <eLpm> Oh, I didn't know. I'll disable it then.
[13:09] <ogra_> in dev releases -proposed is part of the automated infrastructure ...
[13:09] <eLpm> And thanks.
[13:10] <ogra_> in actual releases you can use it for testing possibly broken packages
[13:10] <eLpm> ogra_, OK :-)
[13:10] <cjwatson> at some point maybe it'll be worth creating a separate pocket for it, it's just that new pockets are painful to create
[13:10] <cjwatson> they're all very very hardcoded
[13:11] <Laney> We should make it NotAutomatic :P
[13:11] <cjwatson> using -proposed meant that I could make the system work in days rather than weeks or months
[13:11] <mlankhorst> well -proposed was always used for that, even before the automatation was put in place :P
[13:12] <cjwatson> not very much
[13:12] <cjwatson> the odd hack around release time
[13:15] <knome> seb128, would you do yet another favor to get the docs SRU in as it should?
[13:16] <seb128> knome, is the bug updated?
[13:16] <knome> seb128, yep, i attached .dsc and .tar.gz files (with the same shortcoming as the last time; the version is .0)
[13:17] <seb128> knome, ok, can do once launchpad is back to working
[13:17] <seb128> it's oopsing
[13:17] <knome> seb128, yeah, was for me too :/ but thanks again, and my humble sorrys for bothering you with this constantly
[13:18] <seb128> knome, no worry, mistakes happen
[13:18]  * knome makes sure it's people who understand packaging/related stuff do the work next time... grumble :)
[13:38] <mpt> Is anyone familiar with “Section: oldlibs”, so they can answer my last questions in bug 1166230? Thanks.
[14:04] <knome> cjwatson, i assume the .2 version should land in -proposed any minute now, right? or do you still need to push a button?
[14:04] <cjwatson> I already did
[14:04] <knome> as i imagined, thanks
[14:04] <cjwatson> it should publish once the cron jobs are re-enabled following the LP database server switch
[14:04] <cjwatson> in the meantime I'm having lunch :)
[14:05] <knome> bon appetit!
[14:08] <dobey> cjwatson: did it fail again? it ran fine for the last protobuf build from slangasek
[14:18] <davmor2> tseliot: with protobuf fix in place nvidia && prime seem to be behaving again \o/ cjwatson I now have unity again too so the fix worked :)
[14:18] <cjwatson> dobey: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-ubuntuone-storage-protocol/ARCH=amd64,label=adt/14/console - seems fairly expected given what it's running
[14:18] <cjwatson> davmor2: cool
[14:18] <tseliot> davmor2: excellent. What package/version is that?
[14:19] <cjwatson> dobey: I mean, run-tests is explicitly asking for the cpp backend, which protobuf no longer ships
[14:19] <dobey> cjwatson: that's a bug in protobuf (the _pb2.py are generated by protobuf-compiler)
[14:19] <davmor2> tseliot: for what sorry? Nvidia or the protobuf?
[14:20] <tseliot> davmor2: protobuf
[14:20] <cjwatson> dobey: how is it a bug in protobuf that ubuntuone-storage-protocol explicitly runs PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp u1trial tests ?
[14:20] <davmor2> tseliot: 1 second
[14:20] <dobey> cjwatson: it's a bug in protobuf because the protobuf generated code is trying to import something that is no longer there because slangasek removed the module from the package
[14:21] <cjwatson> dobey: and AFAICT the correct answer is not to attempt to run the tests with PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp any more, because that implementation is no longer available
[14:21] <dobey> cjwatson: running the tests with that environment variable set shouldn't cause a failure, especially if there is no cpp support
[14:21] <cjwatson> well, I guess slangasek can adjudicate, I was only doing a drive-by anyway *shrug*
[14:22] <dobey> cjwatson: i think we should run it, because it exposes bugs in protobuf that are a result of upstream removing a feature half-assedly :)
[14:23] <davmor2> tseliot: libprotobuf7 == 2.4.1-3ubuntu4 libprotobut8 == 2.5.0-8ubuntu1 python-protobuf == 2.5.0-8ubuntu1
[14:23] <tseliot> davmor2: ok, thanks
[14:27] <shadeslayer> pitti: ping ping
[14:28] <shadeslayer> pitti: can you map kcm-driver-manager.pot to the kubuntu-driver-manager package?
[14:28] <pitti> hey shadeslayer, how are you?
[14:28] <shadeslayer> or atleast that's what https://wiki.kubuntu.org/Kubuntu/l10n asks me to do
[14:29] <shadeslayer> pitti: recovering from FOSDEM ;)
[14:29] <pitti> shadeslayer: err, I can't do that kind of mapping -- the source should just build such a .pot file
[14:29] <shadeslayer> oh ... hm, documentation needs updating then
[14:29] <pitti> (the mapping is built in LP translations on import)
[14:30] <shadeslayer> I see
[14:30] <pitti> shadeslayer: oh, actually it seems I ca
[14:30] <pitti> n
[14:30] <shadeslayer> heh :D
[14:30] <pitti> shadeslayer: but that's really a workaround in LP; doesn't the package build a .pot?
[14:30] <shadeslayer> pitti: it does
[14:31] <shadeslayer> so if I just build a pot, it'll all work?
[14:31] <pitti> I thought that workaround was for the LP bug that exports don't contain universe
[14:31] <pitti> shadeslayer: do you see it in translations.lp.net?
[14:32] <pitti> bug 1048556
[14:32]  * shadeslayer is looking
[14:32] <pitti> that's why I have a locally patched hack on macquarie (the langpack building host)
[14:33]  * pitti taps foot, that bug is slow to load..
[14:33] <shadeslayer> all of launchpad is slow today :)
[14:33] <pitti> but it supposedly got fixed in LP, so it shouldn't be necessary any more
[14:34] <shadeslayer> pitti: so basically, I just upload my package to the archive, it'll have the pot, and then then Launchpad does the translation work and stuffs it into the package?
[14:34] <pitti> https://launchpad.net/ubuntu/trusty/+source/kubuntu-driver-manager
[14:34] <pitti> shadeslayer: it seems that doesn't even exist yet?
[14:34] <pitti> shadeslayer: yes, that's the usual workflow
[14:34] <shadeslayer> pitti: yep, I'm about to upload it
[14:34] <shadeslayer> last checks
[14:34] <pitti> ah
[14:35] <pitti> it should then appear on https://translations.launchpad.net/ubuntu/trusty/+source/kubuntu-driver-manager
[14:35] <pitti> (might take a few days, AFAIK new templates still need to be manually approved in LP)
[14:35] <shadeslayer> okay
[14:35] <shadeslayer> thanks for explaining that ;)
[14:35] <pitti> shadeslayer: yw
[14:45] <jdstrand> tkamppeter: hey, I just filed bug #1276630
[14:45] <jdstrand> tkamppeter: I attached a patch. I'm happy to upload the fix if you want
[14:45] <roadmr> doko: hello! hey, sorry about the screwup with checkbox's build-deps :( I'm adding brendand's fix now
[14:46] <roadmr> doko: a question though, since this applies only to ubuntu-specific packaging, would it be reasonable to version this as 0.17.4ubuntu1? (the bad version was 0.17.4)
[14:55] <cjwatson> knome: publisher's taking annoyingly long, very cold caches I think
[14:55] <knome> cjwatson, no problem, i have time :)
[14:56] <cjwatson> knome: mind you I think for this purpose I'd be fine with you just fishing it out of LP.  Let me score up the build so that it actually happens ...
[14:57] <cjwatson> competing with KDE it seems
[14:57] <knome> cjwatson, i can fish it out of LP as well and test
[14:58] <cjwatson> it's just building now
[14:58] <knome> okay, that works as well ;)
[14:59] <xnox> jdstrand: doing it old-school, or is the "apparmor load usr.sbin.cups-browsed" not good enough?
[14:59] <xnox> jdstrand: i guess precise's upstart will reject that job and a reboot would be required... so i'll schedule switching away from profile-load post-trusty?
[15:00] <jdstrand> xnox: precise' upstart does not know about the apparmor stanza
[15:01] <jdstrand> xnox: so if it is important to have the backwards compatibility in the upstart job, then should do it old school
[15:01] <xnox> jdstrand: right. ok.
[15:04] <cjwatson> knome: https://launchpad.net/ubuntu/+source/xubuntu-docs/12.04.2/+build/5556954 built
[15:06] <knome> getting.
[15:08] <knome> cjwatson, works for me. shall i mark the bug verification-done?
[15:08] <doko> roadmr, sure, you can do this
[15:09] <knome> cjwatson, also, will there be a respin for other things anyway before the release?
[15:09] <roadmr> doko: cool, perfect! ok, so I'll upload the fixed version. Again, sorry for the mess-up
[15:09] <slangasek> dobey: I don't think you should be running with PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp when that implementation is no longer included; as far as I can see that's an XFAIL
[15:09] <cjwatson> knome: yes please; hadn't planned anything else but I'm OK with respinning just for this, esp since you folks are well ahead of everyone else on testing
[15:10] <knome> cjwatson, okay, thanks again
[15:10] <dobey> slangasek: and i don't think protobuf should be shipping internally broken code, either
[15:10] <knome> cjwatson, marked as verification-done.
[15:11] <cjwatson> thanks
[15:11] <dobey> slangasek: transitions shouldn't generally break things like that by having internal regressions
[15:12] <knome> cjwatson, will you request the respin when it's landed on the archive?
[15:13] <cjwatson> yes, well, I'll *do* the respin
[15:13] <cjwatson> but either way
[15:13] <knome> heh, yeah, ta :)
[15:13] <cjwatson> though I guess I should use the shiny webby tools
[15:13] <knome> mhm, always!
[15:14] <knome> you can even ping me once again when the respin is done and i'll make sure somebody other than me looks at the respun image as well
[15:15] <tkamppeter> jdstrand, thank you very much. As Debian is also using AppArmor now, I asked the Debian maintainer to upload it so that it gets into our synced package.
[15:16] <pitti> tkamppeter: oh, it does? nice!
[15:17] <cjwatson> hmm, kubuntu alternate is busted
[15:17] <cjwatson> amd64 anyway
[15:18] <Riddell> cjwatson: for 12.04?
[15:18] <cjwatson> yeah, complaining about lack of kernel modules
[15:18] <cjwatson> chasing now
[15:19] <cjwatson> it's just an out-of-date abi for some reason
[15:19] <Riddell> thanks for chasing, I'm starting on testing the live images now
[15:20] <cjwatson> Xubuntu alternate broken in the same way, not that it's on the tracker
[15:21] <cjwatson> which is odd given that we released it with 12.04.3
[15:22] <cjwatson> oh, bah, I see, more seeds than I remembered
[15:23] <knome> cjwatson, probably just a mistake that.
[15:23] <cjwatson> no, it was necessary due
[15:23] <cjwatson> to the enablement stack differences
[15:23] <cjwatson> pretty sure I perpetrated it
[15:23] <knome> okay
[15:24] <cjwatson> knome: oh, wait, you mean it not being on the tracker?
[15:25] <knome> yep, that
[15:25] <cjwatson> yeah, I'll look into it once I've fixed the seeds
[15:26] <knome> oki
[15:31] <cjwatson> ok, hopefully that's Xubuntu alternate * active again
[15:31] <knome> cjwatson, in terms of the tracker or something else?
[15:32] <cjwatson> rebuilding Kubuntu and Xubuntu alternate
[15:32] <cjwatson> the tracker
[15:32] <denisw> is there a vUDS scheduled for this month? if there is one every 3 months as originally announced, it would be time again, but haven't found anything about it when Googling
[15:32] <cjwatson> (actually I may need to do Xubuntu alternate a second time, forgot to wait for -docs)
[15:32] <knome> cjwatson, i can't see alternate enabled
[15:33] <cjwatson> it's active, there just aren't builds filed for it yet
[15:33] <knome> ah, right, that makes it invisible. magic!
[15:53] <hallyn> ok, so guidance on when -sa needs to be passed to debuild.  is that only when the .orig.tar.gz changes?
[15:53] <davmor2> tseliot: hmm suspend works great, resume not so much :D
[15:54] <tseliot> davmor2: you might want to file a bug report and to debug it a bit to see what's going on
[15:55] <cjwatson> hallyn: if the .orig.tar.gz changes but the top and second-from-top changelog entry have the same upstream version
[15:55] <hallyn> ok - so never if .orig.tar.gz doesn't change
[15:55] <cjwatson> typically happens when merging
[15:56] <cjwatson> right
[15:56] <davmor2> tseliot: sure ubuntu-bug xorg or something more specific?
[15:56] <hallyn> got it, thanks
[15:56] <tseliot> davmor2: maybe ubuntu-bug nvidia-331 or nvidia-331-updates if you're running the nvidia driver
[15:57] <davmor2> tseliot: will do
[15:57] <tseliot> good
[16:09] <cjwatson> knome: ok, that's in, respinning all the xubuntu images now
[16:10] <cjwatson> knome: (I'm not going to be extra-strict about testing given that it's just this change, but a quick smoke-test of each one would be good)
[16:11] <davmor2> tseliot: bug #1276674  I'll grab an image and attach it now if I can.
[16:13] <davmor2> tseliot: oh interesting logging in via tty has enabled me to get logged in again however the desktop is now checkerboard
[16:14] <marga> slangasek, I'd like to discuss a network manager bug with you, could you let me know when you are around?
[16:14] <tseliot> davmor2: did resume use to work with nvidia?
[16:15] <tseliot> also grr at ubuntu-bug for not attaching useful data...
[16:16] <davmor2> tseliot: no idea a friend pointed me at it, I don't normally suspend on or off for me :)  It does work on intel though
[16:17] <tseliot> davmor2: can you reproduce the problem and generate an nvidia-bug-report file please?
[16:17] <davmor2> tseliot: yeap give me 5 minutes
[16:23] <tseliot> davmor2: sure
[16:24] <cjwatson> knome: argh, sorry, that respin didn't work because the mirror was locked, I'll retry in a bit
[16:26] <davmor2> tseliot: that should be added now
[16:27] <davmor2> along with an image
[16:28] <knome> cjwatson, okay
[16:30] <tedg> stgraber, Is there a way that I could run "make test" in a cgroup that had like a tenth of a CPU to emulate running on Jenkins?
[16:32] <jdstrand> tkamppeter: cool, thanks!
[16:34] <stgraber> tedg: yes, create a new cpu cgroup, echo your shell's PID in it, set cpu.shares to whatever value you want and run your test
[16:34] <stgraber> tedg: you'd have to go read the documentation for the cpu cgroup though as I'm not entirely sure of what happens on a system that's not under heavy load (as in, does the kernel grant you extra resources or not)
[16:35] <tedg> stgraber, I read that as "you need to play more counter-strike at work"  ;-)
[16:35] <tedg> stgraber, Thanks for the pointers
[16:36] <tseliot> davmor2: it's actually the intel kernel module that fails when suspending
[16:36] <davmor2> tseliot: Yay
[16:36] <tseliot> davmor2: so a kernel issue. Let me update the bug report.
[16:37] <davmor2> tseliot: thanks dude
[16:39] <davmor2> tseliot: hmm I also wonder if it is because I changed the mode in nvidia-settings to powersaving  I'll try it on performance and see if I get the same result
[16:39] <davmor2> I'm assuming I will
[16:40] <tseliot> ok
[16:45] <cjwatson> knome: ok, I think I've finished rebuilding now
[16:45] <cjwatson> cdimage@nusakan:~$ zgrep xubuntu-docs cdimage/www/full/xubuntu/precise/*/current/*.{list,manifest}
[16:45] <cjwatson> cdimage/www/full/xubuntu/precise/daily/current/precise-alternate-amd64.list:/pool/universe/x/xubuntu-docs/xubuntu-docs_12.04.2_all.deb
[16:45] <cjwatson> cdimage/www/full/xubuntu/precise/daily/current/precise-alternate-i386.list:/pool/universe/x/xubuntu-docs/xubuntu-docs_12.04.2_all.deb
[16:45] <cjwatson> cdimage/www/full/xubuntu/precise/daily-live/current/precise-desktop-amd64.manifest:xubuntu-docs 12.04.2
[16:45] <cjwatson> cdimage/www/full/xubuntu/precise/daily-live/current/precise-desktop-i386.manifest:xubuntu-docs  12.04.2
[16:45] <knome> cjwatson, yep, already confirmed the images are fine
[16:45] <cjwatson> just need to wait for the public mirrors to catch up with that
[16:47] <davmor2> tseliot: yeap it's the same :)
[16:48] <tseliot> davmor2: did you get a second nvidia-bug-report file?
[16:48] <davmor2> tseliot: no but I can easily enough
[16:49] <tseliot> davmor2: please do, and explain what you changed when you attach it
[16:54] <davmor2> tseliot: done
[16:57] <psusi> we didn't decide to support upgrading directly from 12.10 to 13.10 since 13.04 went eol first did we?
[16:57] <tseliot> davmor2: both reports seem to suggest that you were using the discrete card. I see no evidence of intel being used
[16:57] <pitti> psusi: that should work now; update-manager etc. have been updated recently for that
[16:58] <infinity> psusi: We did, yes.
[16:58] <davmor2> tseliot: hmmm let me try again then on intel
[16:58] <psusi> oh boy....
[16:58] <infinity> psusi: In theory, it should all go perfectly, since we have to support 12.04->14.04, so all the right upgrade code is in place already.  Right?  Right?  *cough*
[16:59] <davmor2> tseliot: it could just be the nvidia settings app lying ;)
[16:59] <tseliot> davmor2: I was referring to both dmesg and the X log, which usually don't lie ;)
[17:00] <davmor2> tseliot: hence saying that maybe the nvidia-setting app was :)
[17:02] <tseliot> davmor2: ah, to you then :). But did you log out to switch between cards?
[17:02] <davmor2> tseliot: ah now it seems to be on intel correctly and isn't doing the checkerboard effect
[17:02] <psusi> sigh... I was looking at bug #1276669 and wondering why it was skipping a release in the upgrade.. unfortunately there doesn't seem to be a damn thing in the logs that gives any indication *why* the upgrade failed
[17:03] <davmor2> tseliot: is it worth grabbing another nvidia-bug-report.sh?
[17:03] <tseliot> davmor2: after reproducing the problem, yes
[17:03] <davmor2> tseliot: I've gone through the steps but the problem isn't happening now
[17:04] <tseliot> davmor2: then you can only reproduce it when the discrete card is enabled. You might want to update the bug report about this
[17:06] <infinity> psusi: Could be update-grub losing its mind?
[17:06] <infinity> psusi: Not that that's terribly helpful as to why...
[17:11] <xnox> psusi: infinity: i'd say that /boot is full.
[17:11] <xnox> psusi: infinity: given the earliear:
[17:11] <xnox> Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.11.0-15-generic.postinst line 1010.
[17:11] <xnox> dpkg: error processing linux-image-3.11.0-15-generic (--configure):
[17:15] <infinity> xnox: kernel/postinst.d also calls update-grub ...
[17:15] <davmor2> tseliot: thanks for the help and the bug is updated
[17:15] <tseliot> davmor2: thanks
[17:16] <infinity> Setting up grub-pc (2.00-7ubuntu11) ...
[17:16] <infinity> Installing new version of config file /etc/kernel/postinst.d/zz-update-grub ...
[17:16] <infinity> Installing new version of config file /etc/kernel/postrm.d/zz-update-grub ...
[17:16] <infinity> Installation finished. No error reported.
[17:16] <infinity> Generating grub.cfg ...
[17:16] <infinity> dpkg: error processing grub-pc (--configure):
[17:16] <infinity> xnox, psusi: It's pretty clearly update-grub failing on that machine.  But, like I said, that doesn't answer why.
[18:03] <Nafallo> hrm. is click supposed to be running constantly on trusty desktop?
[18:03] <Nafallo> with running I mean being in cpustate running.
[18:11] <doko> mterry, https://launchpad.net/ubuntu/+archive/test-rebuild-20140127/+build/5512647 (you touched it last)
[18:12] <mterry> doko, curious.  Can put it on my todo
[18:13] <doko> thanks
[18:15] <psusi> infinity, xnox, right, but there is no output logged from update grub to indicate why...
[18:17] <xnox> psusi: yeah, a syslog would be helpful. (e.g. if it was out of disk space)
[18:19] <psusi> xnox: or just the output from running update-grub
[18:20] <psusi> I wonder why that isn't logged in the aptterminallog
[18:21] <Riddell> cjwatson: meh kubuntu still broken for encrypted install http://people.ubuntu.com/~jr/tmp/d-i.png
[18:21] <Riddell> unencrypted is fine
[18:57] <seb128> infinity, cjwatson: Laney would like to join ~ubuntu-archive to help there, should he email the team list for that or...?
[20:00] <doko> roaksoax, any progress on bug #1268915 ?
[20:01] <doko> jamespage, zul: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg tells me that paste recommends mochikit
[20:01] <zul> doko: ill have a look
[20:02] <doko> zul, and please bug #1270831 too
[20:02] <zul> yeah ill probably get to it tonight
[20:21] <stgraber> @pilot in
[20:23] <Noskcaj> stgraber, Could you look at lp:~noskcaj/+junk/gnome-weather ? It needs uploading for ubuntu-gnome
[20:24] <Noskcaj> Can't be uploaded to debian due to use of the CC-BY-2.0 license
[20:24] <Logan_> ahem
[20:25] <Noskcaj> ?
[20:25] <Logan_> one moment
[20:28]  * Noskcaj leaves to get food
[20:30] <roaksoax> doko: i'll take care of it right now! Thank you! but if you are reviewing MIR's, crochet is there waiting for review :)
[20:30] <stgraber> Noskcaj: well, for starters this branch contains a copy of libgd which I wouldn't be happy at all to let enter the archive when we already have a packaged version of it, you also forgot to mention said library in debian/copyright
[20:32] <Logan_> Noskcaj: uscan warning: In /tmp/tmpkKu6RI no matching hrefs for version 3.10.1 in watch line
[20:32] <Logan_>   http://download.gnome.org/sources/gnome-weather/([0-9.]+)/gnome-weather-([0-9.]+)\.tar\.xz
[20:32] <Logan_> also 3.11.5 is available upstream
[20:34] <Logan_> stgraber: yeah, that should probably be stripped from the tar ball
[20:34] <Logan_> tarball
[20:34] <Noskcaj> ok
[20:43] <Noskcaj> Logan_, bzr pull then debian/rules get-orig-source
[20:44] <Logan_> there's no get-prig-source target
[20:44] <Logan_> orig
[20:45] <Noskcaj> I just pushed the fix, bzr might not have processed it yet
[20:45] <Noskcaj> now to try and remove libgd
[20:50] <doko> chrisccoulson, https://launchpadlibrarian.net/165084902/buildlog_ubuntu-trusty-amd64.icedtea-web_1.4.2-1ubuntu1_FAILEDTOBUILD.txt.gz issue with a firefox header?
[21:04] <Noskcaj> stgraber, I've deleted the libgd/ directory, still builds fine. Do i need to add a README.source or something?
[21:07] <stgraber> Noskcaj: so if it's entirely unused, it's probably not a big problem keeping it in the orig tarball, I don't think it's worth repacking the upstream tarball for that. However a note in README.source or similar that libgd/ isn't used at all is a good idea, so it doesn't freak out archive admins and security people.
[21:07] <roaksoax> doko: bug #1268915 is done!
[21:08] <roaksoax> Noskcaj: what is it that you wanted me to take care from testdrive?
[21:09] <Noskcaj> stgraber, ok.
[21:09] <Noskcaj> roaksoax, release 3.25, gtk3 port, python3 port
[21:09] <roaksoax> Noskcaj: are these merged?
[21:10] <roaksoax> Noskcaj: 3.26 is released
[21:10] <Noskcaj> ok
[21:10] <Noskcaj> roaksoax, danchapman and i have both tryed to do the gtk3 port, both of us failed.
[21:11] <Noskcaj> and python3 needs the gtk3 port i think
[21:11] <roaksoax> Noskcaj: there's a port to gtk3 that needs improvement already: https://code.launchpad.net/~jbicha/testdrive/port-to-gtk3/+merge/72369
[21:12] <Noskcaj> yeah, so there's three of them then
[21:13] <Noskcaj> lp:~noskcaj/testdrive/gtk3 should have all the python side of things done, i just couldn't get glade to work
[21:14] <roaksoax> Noskcaj: ok, i;ll try to take a look at it later today
[21:14] <Noskcaj> thanks
[21:15] <Noskcaj> stgraber, Should be all fixed. I think a libgd-dev bdep is enough
[21:32] <doko> jtaylor, pycxx tests still don't succeed :-/ what did I do wrong?
[21:34] <jtaylor> doko: looks fine? https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-pycxx/
[21:34] <doko> ohh
[21:35] <doko> ok, maybe I did look too early
[21:50] <ari-tczew> stgraber: got time to sponsor?
[22:05] <cjwatson> Riddell: it would help to get the installer syslog in such cases, especially with limited time left to reproduce anything ...
[22:05] <cjwatson> Nafallo: no, it's not, it's meant to run briefly to run any necessary hooks and then go away
[22:06] <cjwatson> Riddell: (I have to go to bed soon before I just fall over)
[23:48] <stgraber> @pilot out