[00:01] <mwhudson> i am now trying not to sign up for my isp's 130/10 package
[00:19]  * RAOF will (hopefully) be shortly signing up for Internode's 100/40 package. And resisting the temptation to go for the 1000/400 package.
[06:08] <spec4d> I successfully managed to patch an USC bug, and test it on my local machine but I have no idea how to submit it......
[08:06] <steveire> Who knows how this bug needs to be re-sectioned? https://bugs.launchpad.net/ubuntu/+bug/1275506
[08:21] <darkxst> steveire, ubuntu-website project, however I am not sure that is a valid bug, codenames are used after release pretty much everywhere
[08:27] <pitti> Good morning
[08:54] <steveire> darkxst: Thanks. How do I change it?
[08:54] <steveire> I think I got it.
[10:24] <cyphermox_> ev: what thinkpad model do you have? is it a X230?
[10:30] <ev> cyphermox_: x61
[10:30] <ev> 2007
[10:30] <cyphermox_> ok, so totally not the same device I have
[10:31] <cyphermox_> I can't reproduce the issue here; could you bring your laptop over tomorrow so we can look at it?
[12:27] <cjwatson> tseliot1: Thanks for the fglrx/nvidia verifications.  I've promoted everything now, with the exception of nvidia-settings-experimental-{304,310} which I believe are obsolete (bug 1076414) and nvidia-graphics-drivers-319-updates which has a v-failed bug according to http://people.canonical.com/~ubuntu-archive/pending-sru.html (bug 1222670, which looks familiar ...).  Let me know if I still need to do anything here before 12.04.4.
[13:12] <tseliot1> cjwatson: that's correct, as we now use nvidia-settings for all the drivers. Thanks!
[13:13] <cjwatson> tseliot1: Which is correct - you mean that those packages don't need to be moved to -updates for 12.04.4
[13:13] <cjwatson> ?
[13:13] <cjwatson> (Just trying to be clear as we're running out of time.)
[13:23] <tseliot1> cjwatson: what I meant to say is that nvidia-settings-experimental-$VER have been replaced by the nvidia-settings package (i.e. they should be transitional packages now)
[13:32] <cjwatson> tseliot1: Right.  nvidia-graphics-drivers-319-updates was the other part of my comment
[13:35] <tseliot1> cjwatson: same as above. nvidia-319-updates is also a transitional package for nvidia-331-updates
[13:36] <cjwatson> OK
[13:36]  * cjwatson scratches off another set of blockers
[13:44] <kirkland> hmm, I'm trying 'sudo do-release-upgrade -d' on 13.10, and getting:
[13:44] <kirkland> Checking for a new Ubuntu release
[13:44] <kirkland> No new release found
[13:48] <dholbach> didrocks, salut mon ami - comment ça va? in the last comment of https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1237045 it says "Package build configuration needs to be changed to use trunk." - do you know who could do that?
[13:50] <robert_ancell_> seiflotfy__, is anyone maintaining lp:activity-log-manager?
[13:51] <robert_ancell_> ev, ^ you perhaps? I have some MPs
[14:31] <seb128> @pilot in
[14:46] <didrocks> dholbach: hey! it's just abot releasing ubuntu-ui-toolkit trunk, that upstream needs to request, test and so on…
[14:52] <dholbach> didrocks, cjohnston said that he'd chase it from the CI side
[14:52] <didrocks> dholbach: yeah, it's really up to upstream to ask for a release and drive this
[14:56] <ev> robert_ancell__: it's been a very long time since I've looked at it
[14:56] <ev> I'd volunteer to review, but with the sprint last week and being on holiday tomorrow, I'm afraid I just don't have time
[14:59] <robert_ancell__> ev, np. I think it's mostly abandoned so I'll look at getting permissions and updating it directly
[15:02]  * ev nods
[15:51] <pitti> dobey: does the weird failure in https://jenkins.qa.ubuntu.com/job/trusty-adt-ubuntuone-storage-protocol/11/ARCH=i386,label=adt/console tell anything to you?
[15:51] <pitti> dobey: "ImportError: cannot import name _net_proto2___python" from trying to import "from google.protobuf.internal import _net_proto2___python"
[15:51] <dobey> pitti: was there a new google protobuf upload?
[15:51] <pitti> dobey: that looks like our protobuf might have gotten broken?
[15:52] <dobey> pitti: yes
[15:52] <pitti> dobey: yes, https://launchpad.net/ubuntu/+source/protobuf/2.5.0-5ubuntu1
[15:52] <pitti> dobey: it's still stuck in -proposed
[15:52] <dobey> pitti: ah, well it least it didn't get magically promoted despite the failure :)
[15:53] <dobey> like twisted did
[15:53] <dobey> pitti: so, looks like a regression in protobuf
[15:54] <pitti> yeah, the new version makes a ton of packages uninstallable (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt)
[15:54] <pitti> dobey: ack, so this failure looks legit; thanks
[15:54] <pitti> run-adt-test -sU ubuntuone-storage-protocol
[15:55] <pitti> that still succeeds (that's not using -proposed)
[15:55] <dobey> pitti: it seems to just be the cpp implementation that broke though
[15:55] <pitti> slangasek: ^ FYI
[15:56] <dobey> pitti: we run the tests with the cpp protobuf python module as well, as we use that on the server side.
[15:56] <dobey> pitti: the python tests passed, and then the attempt to run them with the cpp module failed
[15:56] <pitti> dobey: ah, so perhaps this merely needs a rebuild against the new version, like https://launchpad.net/ubuntu/+source/protobuf-c/0.15-1build1
[15:57] <dobey> pitti: what needs a rebuild?
[15:57] <pitti> ah no, python-ubuntuone-storageprotocol is arch: all
[15:57] <dobey> right
[15:57] <pitti> I thought you meant that there were some compiled protobufs in there
[15:58] <dobey> no, the protobufs get rebuilt every time with protobuf-compiler, but protobuf has multiple ways of using protobuf in python
[15:58] <dobey> you can use the pure python modules, or the cpp module which is supposed to be faster
[15:59] <dobey> it looks like something broke the cpp module compatibility
[15:59] <dobey> internally in protobuf
[16:16] <slangasek> pitti, dobey: "the cpp module" - that seems to have been dropped upstream in favor of the pure python one?
[16:19] <dobey> slangasek: then the python-protobuf package is a bit busted, as it keeps the cpp_messgage.py but doesn't modify that to maintain compatibility by simply using the pure python version instead
[16:19] <dobey> and it should if that is the intent
[16:20] <dobey> and probably issue a DeprecationWarning
[16:21] <slangasek> dobey: ok, can you file a bug about this and assign it to me for follow-up?
[16:22] <dobey> slangasek: i'm curious, did you get an e-mail about ubuntuone-storage-protocol autopilot failing due to your protobuf upload?
[16:23] <pitti> no, our jenkins machinery isn't that clever yet
[16:23] <pitti> it sends it to the last uploader of the package that fails
[16:23] <dobey> oh
[16:23] <dobey> very non-clever
[16:24] <pitti> and to me and jibel, so ATM we poke/ask people on failures like that
[16:25] <seiflotfy__> hi robert_ancell__
[16:25] <seiflotfy__> currently no one is maintaining activity log manager
[16:28] <robert_ancell__> seiflotfy__, ok
[16:28] <seiflotfy__> robert_ancell__: i can give you access rights if you want
[16:28] <robert_ancell__> seiflotfy__, awesome, thanks
[16:28] <seiflotfy__> you can take over and merge your stuff
[16:28] <seiflotfy__> I am releasing the new zeitgeist later today btw :D
[16:29] <robert_ancell__> nice
[16:31] <dobey> slangasek: https://bugs.launchpad.net/ubuntu/+source/protobuf/+bug/1275826
[16:34]  * dinh_nguyen 
[17:01] <ScottK> Does anyone know what #define __NR_fanotify_init    and #define __NR_fanotify_mark values should be for arm64? https://launchpadlibrarian.net/164564783/buildlog_ubuntu-trusty-arm64.clamav_0.98.1%2Bdfsg-1ubuntu2_FAILEDTOBUILD.txt.gz Upstream only provides x86 values.  In Debian we added values for the Debian archs, but arm64 isn't currently one of them.
[17:04] <slangasek> ScottK: why do you need to shadow these definitions at all? these should come from standard kernel headers
[17:06] <ScottK> I'm not sure why upstream started using them.  It's in a file that's new this release.
[17:06] <slangasek> ScottK: so syscall number definitions should all come from the kernel headers
[17:07] <stgraber> slangasek: that's a nice theory which unfortunately isn't always true... we had to do the same kind of trick (ifdef __NR_... + arch-specific defines) in LXC because of some RedHat based distros and Android where some of the newer syscalls are misisng the __NR_ defines...
[17:08] <ScottK> clamav-0.98.1+dfsg/clamd/fan-syscalllib.h is where the code lives.
[17:08] <ScottK> (trusty-proposed ATM)
[17:08] <slangasek> stgraber: it's fine for an upstream to provide compat definitions for building on older releases, but our kernel headers are right and the upstream should only worry about defining it if not already defined
[17:09] <ScottK> I also didn't find them defined in the Ubuntu arm64 kernel.
[17:10] <slangasek> ScottK: I find them defined in /usr/include/asm-generic/unistd.h from linux-libc-dev on arm64
[17:10] <slangasek> #define __NR_fanotify_init 262
[17:10] <slangasek> #define __NR_fanotify_mark 263
[17:11] <ScottK> OK.  Thanks.
[17:11] <ScottK> I must have looked the wrong place in git.
[17:11] <stgraber> that's odd, because the upstream .h is including unistd.h so they should have been defined then...
[17:11] <ScottK> So the bug is they don't check if it was already defined.
[17:12] <stgraber> oh, doh, misread the upstream code, yeah, they should ifdef the __NR_ then if not defined, ifdef the architecture and define them
[17:12] <stgraber> s/ifdef the architecture/check the architecture/
[17:13] <ScottK> I think I can fix that.  Thanks.
[17:14] <Laney> hey you guys, cross building is pretty good
[17:16] <seb128> Riddell, hey, do you have any news about the calligra trusty build?
[17:17] <seb128> Riddell, if that's still blocked, what do you think about removing the current proposed version, upload a no change rebuild of the old one to complete the poppler transition?
[17:20] <pitti> adam_g`: did you notice that your recent python-troveclient is still stuck in -proposed? its autopkgtest fails as the new version doesn't have an /usr/bin/trove-cli any more
[17:20] <pitti> adam_g`: just /usr/bin/trove now; is that the "new" -cli, or something else?
[17:21] <pitti> adam_g`: ah sorry, that was zul
[17:32] <Riddell> seb128: fosdem got in the way, tomorrow I promise
[17:32] <seb128> Riddell, thanks
[18:05] <asac> any IRC OP around?
[18:06] <asac> ubuntu-touch gets spammed
[18:06] <asac> cjwatson: slangasek: ?
[18:06] <xnox> asac: #ubuntu-irc for irc ops.
[18:07] <cjwatson> ops are channel-specific
[18:07] <cjwatson> /msg chanserv access #ubuntu-touch list
[18:07] <asac> kk
[18:07] <asac> the guy just wanted attention it seems
[18:27] <seb128> @pilot out
[18:40]  * dholbach hugs seb128
[18:40]  * seb128 hugs dholbach back
[19:15] <slangasek> cjwatson: hmm, so grub-install has been rewritten in C?
[19:17] <slangasek> cjwatson: fwiw grub-install --uefi-secure-boot seems to not be working right for me in 2.02~beta2... switched my disk to UEFI when installing in my new laptop (yay), but shim isn't getting installed
[19:28] <dobey> has anyone else noticed that Xorg is leaking memory like crazy in trusty?
[19:29] <slangasek> dobey: not here
[19:29] <dobey> slangasek: what video driver?
[19:29] <dobey> i'm on intel here
[19:30] <dobey> maybe it's a bug in the driver.
[19:32] <slangasek> dobey: intel
[19:33] <dobey> hmm
[19:33] <dobey>  4210 root      20   0 1580884 1.042g 281312 S   0.7  7.1  48:59.29 Xorg
[19:36] <dobey> slangasek: do you use firefox, or chromium?
[19:38] <slangasek> dobey: firefox
[19:38] <dobey> slangasek: does it sometimes go crazy and use up 300% of your cpu and refuse to exit, too?
[19:38] <slangasek> dobey: no
[19:39] <slangasek> rather, I've seen something like that in the past, but I think that was during the saucy dev cycle
[19:39] <dobey> it's been happening quite a lot for me on trusty :(
[19:40] <beuno> dobey, I'm getting constant freezes in FF
[19:40] <beuno> it blames gmail's gtalk javascript
[19:40] <dobey> and i'm not sure how to describe the issues exactly in a bug report, since i don't know how to force the problem to happen
[19:40] <beuno> not sure if that's cause or symptom
[19:41] <beuno> need to restart FF several times a day
[19:41] <beuno> (has only started happening this last week)
[19:41] <dobey> beuno: probably a symptom. at least, i don't actually use the gmail web interface, so i'm pretty sure that's not causing the problem for me, at least
[19:42] <dobey> beuno: i've been having this since i upgraded to trusty. i have to pkill -9 firefox every time i quit it, or sometimes it'll stick around, eat up all my cpu, and complain it's already running when i try to run it again
[19:49] <dobey> maybe compacting all the sqlite in the profile will help…
[20:22] <slangasek> dobey: protobuf 2.5.0-5ubuntu2 uploaded.  Does ubuntuone-storageprotocol need any other changes to adapt, or just a retry?
[20:24] <dobey> slangasek: if it makes the cpp_message.py just use the pure python, i'd think it just needs a retry, which the new upload should trigger.
[20:26] <slangasek> dobey: hum, rather I dropped the cpp_message.py ... since the filename implied it was specific to the cpp module
[20:31] <dobey> slangasek: oh :(
[20:32] <dobey> slangasek: i suspect a lot of packages will need changes then, as pitti said the protobuf upload was causing a lot of build failures
[20:33] <dobey> although the list in the proposed-migration output is a bit weird
[20:34] <dobey> and ironically, ubuntuone-storage-protocol isn't even in that list
[20:39] <slangasek> dobey: no, pitti said that the protobuf causes uninstallability issues in trusty - because it's an in-progress transition
[20:40] <slangasek> dobey: and ubuntuone-storage-protocol isn't in the list because python-protobuf's package name hasn't changed.  If you like, I can have python-protobuf declare a versioned Breaks: on the old ubuntuone-storage-protocol
[20:41] <dobey> slangasek: are we certain that nothing else in the archive is using the cpp module?
[20:49] <slangasek> dobey: the only revdeps of the package in the archive are python-protobuf.socketrpc and python-ubuntuone-storageprotocol
[20:50] <dobey> slangasek: i'll remove the usage in u1 and do an upload for it
[20:51] <slangasek> dobey: sounds good, thanks
[20:53] <dobey> oh maybe i won't have to
[20:54] <dobey> it handles ImportError already where it tries to import cpp_message
[20:54] <dobey> so it should just work with the new upload
[21:01] <infinity> kees, pitti, slangasek, stgraber: TB?
[21:05] <jtaylor> hm should I be worried that I picked up a linux 3.11.0-17.30 during upgrades but it doesn't show up in launchpad?
[21:08] <sarnold> jtaylor: did you subscribe to this ppa? https://launchpad.net/~canonical-kernel-team/+archive/ppa
[21:08] <jtaylor> no
[21:09] <jtaylor> I upgraded to that linux on two machines I use
[21:10] <jtaylor> just noticed because I wanted to run perf but linux-tools for 17 doesn'T exist
[21:10] <jtaylor> no ppas that provide kernels activated, but I do have proposed on
[21:10] <sarnold> ah
[21:11] <sarnold> an emergency kernel update last week superceeded a kernel from -proposed, I believe it was deleted to simplify matters
[21:11] <jtaylor> hm ok, so I better remove the 17 version?
[21:11] <sarnold> jtaylor: see e.g. http://www.ubuntu.com/usn/usn-2096-1/ -- you may wish to install that kernel manually to patch the hole
[21:11] <sarnold> jtaylor: yeah
[21:15] <slangasek> dobey: do you want a Breaks: from python-protobuf?  Otherwise, I'm going to work on getting mir rebuilt and the library transition done
[21:16] <dobey> slangasek: no, i don't think it is necessary
[21:16] <slangasek> dobey: ok
[21:17] <dobey> slangasek: and it looks like the autopkgtest just finished and passed, for ubuntuone-storage-protocol
[21:17] <slangasek> dobey: awesomesauce
[21:18] <dobey> and compacting the sqlite didn't help firefox :(
[21:18] <slangasek> so that should get us the new protobuf in, just as soon as we manage to find the publisher again
[21:25] <roaksoax> slangasek: howdy! are you on archive admin duty today?
[21:26] <roaksoax> slangasek: can you please process crochet and maas-test from the trusty NEW queue, if you  are?
[21:26] <slangasek> roaksoax: ah, we've more or less stopped having archive days, but I can have a look
[21:26] <slangasek> roaksoax: (basically, you can ping any AA if you need NEW help)
[21:27] <roaksoax> slangasek: I see! Cool! And thank you!
[21:49] <slangasek> roaksoax: maas-test doesn't include the text of the license; for AGPL-3 you have to include the whole license text, it's not one of the licenses in common-licenses
[21:49] <roaksoax> slangasek: ok, thanks for pointing that out. I'll get that fix!
[21:49] <slangasek> roaksoax: also, please use compat level 9, not the (ancient) 7
[21:50] <slangasek> (with corresponding fix to the versioned build-dep0
[21:50] <slangasek> )
[21:51] <slangasek> roaksoax: if this is all new code, why is it python2 instead of python3?
[21:51] <roaksoax> slangasek: so copyright should include all this document? http://www.gnu.org/licenses/agpl-3.0.txt
[21:51] <roaksoax> slangasek: cause MAAS is still python2 and this is only to test MAAS
[21:52] <roaksoax> slangasek: it will support python3 once MAAS does too
[21:53] <slangasek> ah, it imports apiclient, ok
[21:53] <slangasek> roaksoax: and yeah, that's the correct license to be included
[22:10] <roaksoax> slangasek: ok uploaded a new maas-test package
[22:13] <slangasek> hrm, why is someone changing the moderator password for the techboard list?
[22:13] <sarnold> slangasek: mistake, see #is
[22:14] <slangasek> ah, k
[23:04] <slangasek> roaksoax: minor bug, not a blocker for new, crochet debian/copyright lists a wrong copyright; Gavin wouldn't be a copyright holder here, certainly not with an @canonical.com contact address :)
[23:05] <roaksoax> slangasek: ok :). Thanks for taking care of it though! :)
[23:21] <hallyn> hm, i have a cgmanager.8, and debian/cgmanager.manpages contains "cgmanager.8".  So why does it get installed as cgmanager.1?
[23:23] <infinity> hallyn: What does the header in the manpage itself say?
[23:24] <stgraber> hallyn: pass -s 8 to help2man
[23:24] <hallyn> infinity: oh heh, thanks
[23:24] <hallyn> stgraber: yup, thanks.
[23:39] <shadeslayer> Could somene look at the arm64 and ppc64el errors on https://launchpad.net/ubuntu/+source/gcl/2.6.10-1