[06:06] <pitti> Good morning
[06:08] <ricotz> good morning
[06:08] <ricotz> this one needs some attention https://launchpad.net/ubuntu/+source/libreoffice/1:5.1.3-0ubuntu1/+build/9771317
[06:21] <seb128> doko, hey, I noticed your merged packagekit 1.0 again ;-) ... do you plan to port/fix aptdaemon?
[06:22] <pitti> wasn't the bigger blocker click?
[06:22] <seb128> doko, also it breaks click still
[06:23] <seb128> pitti, we sort of agreed that it would be ok to break them for a while because they don't plan to base any product on y
[06:23] <pitti> ah, ok
[06:23] <seb128> but we should sync up again with them to make sure it's still ok
[06:23] <pitti> and moving to snaps at some point, I figure
[06:23] <seb128> yes
[06:24] <seb128> wth
[06:24] <seb128> why is autopkgtest for aptdaemon 1.1.1+bzr982-0ubuntu14: amd64: Ignored failure,
[06:24] <doko> seb128, hrm, thought it would be safe after the lts ...
[06:24] <seb128> that failure should absolutly not be ignored
[06:24] <seb128> it's an abi break that makes it fail to import packagekit
[06:25] <pitti> aptdaemon's tests have been failing for a long time in xenial already
[06:26] <seb128> well in that case they rightly fail
[06:26] <pitti> would be good to fix them indeed, so that they become useful again to detect regressions
[06:26] <pitti> i. e. to succeed in yakkety-release
[06:26] <seb128> right
[06:26] <pitti> (or even xenial)
[06:26] <seb128> meanwhile can we make sure it's blocked in proposed?
[06:27] <pitti> seb128: easiest is to have a bug against packagekit and tag it block-proposed
[06:28] <pitti> I don't want to remove the force-badtest, as this would hold up a lot of unrelated stuff then
[06:28] <doko> hmm, click has an older version in -proposed than in -release?
[06:29] <seb128> weird
[06:30] <seb128> doko, pitti, anyway, https://errors.ubuntu.com/problem/0cbdb94861b90a2bf18c183fb3031ed81f6bb5a7 is one of the issues with aptdaemon/new packagekit
[06:30] <seb128>   File "/usr/lib/python3/dist-packages/aptdaemon/worker/pkworker.py", line 175, in __init__
[06:30] <seb128>     pk.RoleEnum.GET_DEPENDS,
[06:30] <seb128> AttributeError: type object 'PkRoleEnum' has no attribute 'GET_DEPENDS'
[06:32] <seb128> pitti, ^ I've tagged bug #1496292 as block-proposed
[06:32] <seb128> is that enough for making sure it sticks there?
[06:33] <pitti> seb128: it needs a packagekit task
[06:34] <seb128> pitti, oh right, thanks, done
[07:02] <seb128> slangasek, infinity, could you maybe have a look to https://launchpadlibrarian.net/259212950/lsb_9.20160110_9.20160110ubuntu1.debdiff from bug #1536353
[07:10] <Saviq> pitti, morning, could you please expedite https://launchpad.net/ubuntu/yakkety/+queue?queue_text=mir into yakkety? thank you
[07:15]  * seb128 wonders why Saviq wants pitti only to look at that, but ok
[07:16] <Saviq> seb128, because I missed you on this list https://launchpad.net/~ubuntu-archive/+members ;)
[07:16] <Saviq> and Mirv told me to choose the friendliest member ;D
[07:16] <seb128> Saviq, well, usually better to just ask on the channel first
[07:16] <seb128> you can nag individual when nobody replies
[07:16] <seb128> lol
[07:16] <pitti> Saviq: is it really necessary to micro-split the packages that way?
[07:16] <Saviq> sry, first time /me doing this
[07:17] <pitti> they seem to have similar dependencies and each new package just ships a single new driver
[07:18] <Saviq> pitti, I'm afraid I can't answer that, but they've been split up more and more as they went, I'm sure there were some reasons for that
[07:18] <doko> seb128, mvo attached a patch
[07:18] <Saviq> RAOF, if still here, can you comment on why mir is split up into so many packages?
[07:19] <pitti> anyway, debs look okayish, accepted
[07:19] <Saviq> pitti, thank you
[07:19] <seb128> doko, nice, I wonder how you manage to bribe him to spend time out of snappy :p
[07:20] <seb128> doko, can you test/upload the patch?
[07:20] <mvo> seb128: s/bribe/threatened/
[07:20] <seb128> I've no yakkety system and no plan to start y work before a while, too much lts/snappy work
[07:20]  * seb128 hugs mvo
[07:20]  * mvo hugs seb128
[07:22] <Saviq> this is a nice channel
[07:22] <Saviq> snuggly!
[07:22]  * pitti introduces seb128 to the magic of lxd
[07:22] <seb128> doko, mvo, that enum issue was the reports we get from the time the new version was in proposed, I'm not sure those are the only uncompatible change in pkgkit1 that might bite aptdaemon
[07:22]  * seb128 introduces pitti to the limitation of his 80G ssd
[07:22] <pitti> seb128: "lxc launch images:ubuntu/yakkety/amd64" :)
[07:23] <seb128> ENOSPACE
[07:23] <seb128> I'm fighting constently with 1G free space
[07:23]  * seb128 needs to laptop refresh
[07:23] <pitti> oh, wow
[07:23] <seb128> my config is 6 years old
[07:24] <RAOF> Saviq: So many packages?
[07:25] <Saviq> RAOF, <pitti> Saviq: is it really necessary to micro-split the packages that way? (that's re: mir)
[07:25] <pitti> ok, armhf autopkgtests are now limping along on 4 lxd slaves in scalingstack, but they commit suicide every hour or so
[07:26] <pitti> I might have to disable armhf autopkgtests until the CI lab comes back
[07:27] <RAOF> pitti: Oh, you were referring to the new graphics-mesa-kms9 vs graphics-mesa-x9?
[07:28] <pitti> RAOF: and -android9
[07:30] <RAOF> -android9 pulls in android dependencies?
[07:31] <RAOF> Merging -kms9 and -x9 would be painless; *technically* they have different dependencies, but in practise libGL pulls in X anyway...
[07:33] <pitti> RAOF: do -android{5,8,9} have different deps?
[07:33] <RAOF> pitti: No, but they're all superceded.
[07:34] <pitti> RAOF: ah, so those will be NBS? good
[07:35] <RAOF> Or, rather, we've got 2 ABIs in play - client platform ABI and server platform ABI; there'll be exactly one mir-platform-graphics-* for each platform, and exactly one mir-client-platform-* for each platform.
[07:35] <RAOF> All the old ones will be NBS, and removable.
[07:36] <mvo> seb128: you could simply change the ssd and keep the laptop ;) ?
[07:37] <pitti> seb128: purging stuff like ~/.launchpadlib or .local/share/ubuntuimages also works wonders, I freed like 10 G the other day
[07:45] <Saviq> uh oh
[07:45] <Saviq> Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-i386/Packages  503  OUT OF DISK SPACE
[07:46] <Saviq> that's not a local error is it?
[07:46] <pitti> where do you see this?
[07:46] <Saviq> pitti, apt-get update
[07:47] <Saviq> and unless zfs went awry, I've 80G free locally
[07:48] <Saviq> hmm wait
[07:48] <Saviq> this could be apt-cacher-ng
[07:48] <Saviq> that definitely makes more sense
[07:48] <Saviq> pitti, my fault
[08:09] <seb128> mvo, I guess I could, but the laptop is a bit bulky and old and 4G ram, time for a proper refresh ;-)
[08:10] <seb128> pitti, right, I do a proper round of cruft cleaning every now and then and go back to 10G, then download some isos, do some pbuilding etc and I'm back to needing to watch free space ... just need a bigger disk, it's about time ;-)
[08:11] <pitti> happy shopping then :)
[08:20] <mvo> seb128: :) sure, it was only half serious
[08:22] <seb128> but that was a side discussion anyway, it's just that I don't feel like that I've the bandwith to do xenial+yakkety+snappy+... work, and yakkety is at the bottom of my priority list atm, so please don't count on me for the packagekit/aptdaemon thing
[08:22] <Laney> we did plan on doing it at some point this cycle
[08:22] <Laney> but thanks to doko for taking it on :)
[08:23] <seb128> yeah :-)
[08:23] <Saviq> pitti, any idea why the mir you accepted isn't available in proposed still?
[08:24] <seb128> Saviq, you are using an outdated mirror?
[08:24] <Saviq> archive.ubuntu.com ;?
[08:24] <Saviq> and so do silos?
[08:24] <pitti> Saviq: rmadison says it's there
[08:24] <seb128> maybe the publisher is not done yet?
[08:24] <Saviq> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-058/+packages
[08:24] <pitti> mir-platform-graphics-mesa-x9    | 0.22.1+16.04.20160516.2-0ubuntu2 | yakkety-proposed          | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
[08:25] <seb128> Saviq, retry your build?
[08:25] <jtaylor> hmm appstreamcli in xenial blocks apt update and eats 100% cpu for apparently ever since today
[08:26] <jtaylor> known issue?
[08:26] <Laney> https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/1579712
[08:26] <jtaylor> ah
[08:26] <jtaylor> oh its much older, weird I only see it today
[08:27] <Saviq> seb128, can you retry https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-058/+build/9776460 please - that one doesn't have a direct dep so not a dep wait, but fails because of a dep chain
[08:28] <seb128> Saviq, done
[08:40] <Saviq> seb128, ok seems I complained just when it got published
[08:41] <seb128> Saviq, rmadison is your friend ;-)
[08:46]  * mgedmin would appreciate some attention for https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1548425
[09:07] <seb128> mgedmin, it's just a warning right? I can't reproduce here...
[09:08] <seb128> mgedmin, maybe you can get mvo interested in reviewing the patch though
[09:24] <seb128> mgedmin, but weird, "python3 -c "from gi.repository import Gtk; text=Gtk.TextView(); print(text.get_iter_at_location(0,0))"" returns
[09:24] <seb128> <Gtk.TextIter object at 0xb539465c (GtkTextIter at 0x8e836e0)>
[09:24] <seb128> here
[09:24] <seb128> not a tuple
[09:31] <mvo> seb128, mgedmin: looks fine, if it works +1, the GI api changes are a bit annyoing :/
[09:31] <seb128> mvo, mgedmin, well as said I can't confirm the bug and ^ returns an iter for me
[09:34] <seb128> mvo, mgedmin, OH
[09:34] <seb128> libgtk-3-0 3.19.9-0ubuntu1~xenial2 [origin: LP-PPA-gnome3-team-gnome3-staging]
[09:34] <seb128> so I guess the api changed with gtk 3.19
[09:34] <seb128> *great*
[09:35] <seb128> that explains it
[09:35] <seb128> Laney, ^ more fun when we update gtk
[09:35] <Unit193> s/when/if/ by the sounds of it.
[09:36] <doko> sil2100, https://launchpad.net/ubuntu/+source/click looks like you copied old versions
[09:37] <sil2100> doko: hey, yeah... cjwatson noticed that already, looks like this package somehow went through my checks
[09:37] <sil2100> Ah, I know why
[09:37] <sil2100> Since the xenial-overlay actually had a lower version than xenial itself, which is what I didn't expect :|
[09:37] <sil2100> doko: could you drop it from proposed?
[09:40] <sil2100> I actually expected it to just get rejected, since it's a lower version
[09:58] <pitti> xnox: upstart autopkgtest times out after "ok 25 - with single-line script that writes 1 line to stdout" on the infra and also in local qemu; this is new from the y-proposed version
[10:06] <mgedmin> gah!
[10:06] <xnox> pitti, what about xenial-proposed -> does that one hang too, or no?
[10:06] <mgedmin> yeah, I'm on ubuntu-gnome with the staging ppa :/
[10:07] <pitti> xnox: no, that seems fine; and y-release apparently too
[10:07] <xnox> pitti, ok.
[10:07] <pitti> xnox: well, it failed of course, but didn't hang that way
[10:09] <pitti> cyphermox: ok to steal your sysvinit merge?
[10:49] <doko> sil2100, done
[10:56] <pitti> caribou: when sponsoring things like bug 1390061, can you please insist on the reporter forwarding the fix to Debian too? (or do it yourself)
[10:56] <pitti> having to drag these fixes in Ubuntu is annoying, and it's relevant for Debian too
[10:56] <pitti> caribou: stealing the bash-completion merge FYI, as it's blocking sysvinit and util-linux merges
[10:58] <sil2100> doko: thank you
[11:12] <doko> nacc, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg  dh-php wants to pull in xml2. either a MIR is needed or the dependency removed
[11:47] <doko> seb128, Laney: suitesparse gained a dependency on metis (needs a MIR, or suitesparse needs again building with the internal metis)
[11:47] <seb128> doko, doesn't seem something that has to do with desktop
[11:47] <seb128> unsure what suiteparse is
[11:47] <seb128> never touched it
[11:49] <doko> seb128, suitesparse is owned by desktop packages
[11:49] <Laney> used by libreoffice
[11:50] <seb128> k, well as said earlier I've no slot of y-work at the moment
[11:50] <seb128> so feel free to find somebody else interested
[12:23] <caribou> pitti: ok ,will do. sorry for that
[12:31] <stokachu> @pilot in
[12:32] <caribou> pitti: you didn't forward the bug to debian ? 'cause I'll ask seyeong to do it
[12:33] <ChrisTownsend> pitti: Hey, I have some britney runs for silo-031 that seem like they are stuck (or missing): https://requests.ci-train.ubuntu.com/#/ticket/1425
[12:34] <ChrisTownsend> pitti: I was told to ping you for investigation.
[12:50] <pitti> ChrisTownsend: prodded, running now: http://autopkgtest.ubuntu.com/running.shtml#pkg-content-hub
[12:51] <ChrisTownsend> pitti: Thanks.  And the yakkety one's are just in the queue waiting, right?
[13:01] <seb128> xnox, https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu24/+build/9737266 ... build is ongoing since yesterday, is that stucked?
[13:02] <xnox> seb128, yes. will retry.
[13:02] <seb128> xnox, I guess it's bug #1576914
[13:02] <seb128> ?
[13:16] <xnox> pitti, https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1583563
[13:16] <xnox> looks very fishy =(
[14:00] <Saviq> pitti, this seems stuck, doesn't it http://autopkgtest.ubuntu.com/running.shtml#pkg-unity8 ?
[14:01] <Saviq> "Running for:	3 h 4 min 13 s"
[14:02] <smoser> pitti, around ?
[14:09] <cyphermox> pitti: yeah, have fun!
[14:10] <cyphermox> sorry, I had some internet troubles
[14:21] <nacc> doko: ack, will investigate, must be a new dep in dh-php in debian
[14:49] <pitti> smoser: hello
[14:49] <pitti> Saviq: there was an outage of lcy01, so it had to retry a few times
[14:52] <pitti> Laney: meh, lcy01 and bos01 now both dieing? what's that, a strike?
[14:52] <smoser> ah.great.
[14:52] <smoser> pitti, so i was looking at Odd_Bloke 's cloud-image slow boot from yesterday
[14:53] <smoser> i modified cloud-init-local.service to have this
[14:53] <smoser>  http://paste.ubuntu.com/16522550/
[14:54] <smoser> and then after boot
[14:54] <smoser> $ grep . /run/cloud-init/pre-local*
[14:54] <smoser>  /run/cloud-init/pre-local:4.73 1.23
[14:54] <smoser>  /run/cloud-init/pre-local-python:27.13 22.84
[14:55] <smoser> so the 'python3 -c' line took 24 seconds to start up, and copy /proc/uptime to /run/cloud-init/
[14:58] <pitti> smoser: ooh, I know
[14:58] <pitti> smoser: that's yakkety, right?
[14:58] <smoser> yes
[14:58] <pitti> smoser: debian bug 822431
[14:58] <pitti> smoser: this bit me in autopkgtest as well
[14:58] <pitti> smoser: use this workaround: http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=abfc34e2a0f
[14:59] <pitti> smoser: i. e. call it with PYTHONHASHSEED=0
[14:59] <pitti> smoser: and it'll be blazing fast again
[14:59] <pitti> this issue is an utter nuisance
[14:59] <pitti> basically every python3 during early boot blocks for ages
[15:00] <pitti> I don't understand why hashes need to be cryptographically randomized
[15:01] <pitti> and python would block on that
[15:01] <pitti> in pretty much every language dictionaries are even predictable (although their "order" might change between compilers and versions of course)
[15:02] <smoser> pitti, ok. i'm trying that. by changing /usr/bin/cloud-init's #! to be
[15:02] <smoser>  /usr/bin/env PYTHONHASHSEED=0 python3
[15:02] <pitti> you can use #!/usr/bin/env .. that
[15:04] <pitti> at least there's a lot of discussion in the upstream python bug, so hopefully this gets fixed after all and the debian bug "wontfix" will be dropped
[15:06] <Odd_Bloke> Great bug, 10/10.
[15:06] <Odd_Bloke> Would encounter again.
[15:08] <pitti> Odd_Bloke: sorry, can't parse that
[15:08] <smoser> huh. why doesnt that work above ?
[15:09] <smoser> cat >my.py<<EOF
[15:09] <smoser> #!/usr/bin/env PYTHONHASHSEED=0 python3
[15:09] <smoser> print("hello python 3")
[15:09] <smoser> EOF
[15:09] <smoser> chmod 755 ./my.py
[15:09] <pitti> Odd_Bloke: but yes, I spent an entire afternoon tracking this down; in retrospect it should have been much faster, but after the fact everythign is obvious :)
[15:09] <Odd_Bloke> pitti: (https://xkcd.com/325/)
[15:10] <smoser> a++++ would read provided link again
[15:10] <Odd_Bloke> pitti: Yeah, I probably didn't help by planting the networking seed in your mind. :p
[15:11] <pitti> smoser: hmm, indeed, hashbangs don't work like that; perhaps just add Environment=PYTHONHASH=0 to the uit?
[15:11] <pitti> unit too
[15:11] <smoser> yeah. have to add it to each though
[15:12] <smoser> what am i missing .. why dont sheang work like that. and what is it trying to do
[15:12] <JanC> pitti: IIRC that was added after somebody illustrated a DDoS against Python's hashtables?
[15:12] <smoser> oh. it endlessly loops env
[15:12] <pitti> smoser: sounds like the rest of the file gets fed to env, not python3 or so
[15:13] <smoser> yeah. i'll modify the Environment
[15:13] <smoser> but i didnt' want to have to touch all of them.
[15:14] <pitti> it's hopefully not a permanent change
[15:14] <pitti> if upstream adds the NONBLOCK flag back to the getrandom() call, the world should be a brighter place again
[15:16] <JanC> I suppose it's mostly useful where Python has to handle arbitrary data from untrusted users, e.g. in some internet services/apps
[15:17] <pitti> JanC: that sounds curious; happen to have a link?
[15:17] <pitti> I can't imagine how an unreliable hash order would be a security feature
[15:17] <pitti> "unpredicable"
[15:18] <Odd_Bloke> pitti: http://bugs.python.org/issue13703
[15:18] <Odd_Bloke> pitti: Which points to https://mail.python.org/pipermail/python-dev/2011-December/115116.html
[15:19] <JanC> pitti: if you can predict the hashes, you can submit data that computes to the same hash, I suppose...
[15:19]  * pitti stashes that for later reading, thanks!
[15:20] <smoser> pitti, what did i do wrong: http://paste.ubuntu.com/16523164/
[15:20] <JanC> which of course makes hashtable lookups very slow
[15:21] <pitti> smoser: PYTHONHASHSEED (sorry, typoed in my last reply)
[15:22] <herrkin> hello, I have a problem with a modem that wont switch to modem mode
[15:22] <herrkin> I have several modems to test but there is one that is very stupid, some times it just stays in mass storage mode and wont switch
[15:22] <Odd_Bloke> herrkin: This channel is for development of Ubuntu itself; you probably want #ubuntu or #ubuntu-server. :)
[15:22] <herrkin> is this the correct place to discuss abut it?
[15:23] <herrkin> Odd_Bloke, the problem is with usb_modeswitch I think
[15:23] <herrkin> its part of ubuntu
[15:26] <Odd_Bloke> herrkin: Sure, but the venue for questions about _using_ Ubuntu belong in #ubuntu or #ubuntu-server.  There will be more people in those channels who may have run across the issues you are seeing, so you have a better chance of finding help. :)
[15:26] <herrkin> ok let me see.
[15:26] <herrkin> thanks
[15:41] <pitti> xnox: I have a change to procps to make; should I steal your merge while I'm at it, or are you already at it?
[15:42] <pitti> apw: do you know if /etc/init.d/ondemand is still a thing that we need with current kernels?
[15:42] <pitti> apw: it's the only thing that's left from initscripts that we actually use; I'm working on dropping deps to initscripts so that we stop installing it by default, and wonder if I should put an equivalent unit into systemd or not
[15:43] <smoser> pitti, something else is at play here.
[15:43] <apw> pitti, we use that to boot in performance and drop back to something less batter sucking ... and the kenrel is still in performance by default
[15:43] <smoser> $ pastebinit /lib/systemd/system/cloud-init-local.service
[15:43] <smoser> http://paste.ubuntu.com/16523968/
[15:44] <pitti> apw: I had assumed the kernel would drive the CPU to full steam while it's actualy busy doing something (like on boot)
[15:44] <smoser> $ tail -n 10 /usr/bin/cloud-init | pastebinit
[15:44] <smoser> http://paste.ubuntu.com/16523984/
[15:44] <pitti> apw: i. e. I wonder why we are the only distro doing somethign like that
[15:45] <apw> pitti, it was something that keybuk drove in, and it has never been revisited since
[15:45] <pitti> apw: anyway, it's simple to port; I'll probably use a Type=idle so that it goes to ondemand as soon as boot is done, istead of a static "1 minute", I just wondered if the kernel still needs that kind of help
[15:45] <smoser>  http://paste.ubuntu.com/16524007/
[15:45] <xnox> pitti, please steal
[15:46] <smoser> so i suspect that something in the cloud-init's imports is messing up the PYTHONHASH or something so it goes back to slow.
[15:46] <apw> pitti, yeah it is pretty unclear for sure, would you file a bug on linux to review that and let me know, i will find someone to think about it
[15:46] <apw> pitti, but in the short term, making it an idle systemd unit sounds much better anyhow
[15:47] <apw> a i know it makes my lappy hot during boot :/
[15:49] <pitti> apw: ok, so port to a unit in the short-term, and revisit if defaulting to "ondemand" works better now (after all, some 10 years have passed..)
[15:49] <pitti> maybe 8
[15:50] <apw> indeed
[15:50] <Odd_Bloke> smoser: If you want to test the imports, you could (probably) move them all in to that if statement after the startup time is written out.
[15:51] <smoser> yeah
[15:52] <pitti> apw: bug 1584124 -- does that have enough context/
[15:53] <pitti> ?
[16:00] <pitti> xnox: procps> ugh, a 100 kB Ubuntu diff? fun; well, I asked for it, I got it :)
[16:40] <Odd_Bloke> pitti: doko: Is there an Ubuntu bug open anywhere for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822431?  This is really serious for cloud images, because they all use Python 3 near the start of boot (via cloud-init).
[16:41] <Odd_Bloke> (I've seen a 7 minute hang as a result of it on an OpenStack cloud)
[16:53] <cpaelzer> Hi, I know there are always all kind of super-skilled people around - for those of you who love gcc/ld to its darkest depth - you might take a look at http://stackoverflow.com/questions/37351699/how-to-create-both-so-files-for-two-circular-depending-libraries - there seem to be no good answer to that out there yet so I asked it openly
[16:53] <cpaelzer> I'm giving up on it for now and let the weekend try to distract me from it :-)
[17:02] <smoser> pitti, just for a summary of above using PYTHONHASH does not seem to affect all things.
[17:02] <smoser> for example, 'import tempfile' does
[17:02] <smoser>  from random import Random as _Random
[17:03] <smoser> and that seems hits the same first boot hang even with PYTHONHASH set.
[17:05] <Odd_Bloke> smoser: What do you see without that set at all?
[17:06] <smoser> ?
[17:06] <Odd_Bloke> smoser: Because I suspect you are working around the Python _startup_ issue, and then hitting a separate (but very much related) random module issue.
[17:06] <smoser> yeah. i think so too
[17:06] <smoser> i can take out the Environment and see
[17:12] <Odd_Bloke> smoser: I've filed https://bugs.launchpad.net/cloud-images/+bug/1584147 (which also affects cloud-init).
[17:13] <smoser> Odd_Bloke, so setting PYTHONHASH *does* help.
[17:13] <smoser> at least in a single test here
[17:13] <smoser> but clearly doesnt make it all magic
[17:15] <Odd_Bloke> smoser: I've added a comment with a high-level summary of what you've discovered; please feel free to flesh out with details. :)
[19:31] <TJ-> Why would "Failed to connect to Mir: Failed to connect to server socket: No such file or directory" be reported when executing an X application from the terminal, launched by another (sudo) user, with e.g. "sudo /usr/bin/env DISPLAY=:0 XAUTHORITY=/home/<user>/.Xauthority xclock" - do we need to copy more of the target users' native environment? any in particular? presumably this is some kind of fallback
[19:31] <TJ-> if the X session isn't found?
[19:32] <dobey> where are you trying to do that?
[19:33] <TJ-> from a VT. On my system (Ubuntu+Unity) it works fine. On another system using, I think, Lubuntu, it gets that error. Obviously Mir isn't installed, but it feels like a fallback if the X server/session for the target user cannot be located
[19:35] <dobey> well i'm pretty sure xclock doesn't link to libmir
[19:35] <sarnold> TJ-: I got that same error message trying to run evince via ssh -X https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1573300
[19:35] <TJ-> no, it's something in the underlying libraries obviously. I've not pulled the sources of the libraries as yet to search for the string
[19:35] <sarnold> TJ-: I never got around to debugging this thing :/
[19:36] <dobey> well, xclock is a pure x app
[19:36] <TJ-> sarnold: right; I've seen some similar reports but no bug reports as yet.
[19:36] <dobey> it doesn't link to gtk+ or qt, and the X libs don't link to mir
[19:36] <sarnold> xclock is a genius test case :) pretty simple, no churn
[19:36] <TJ-> dobey: xclock is just an example
[19:36] <TJ-> this is about the session-level env I think
[19:37] <dobey> TJ-: sure, i'm just trying to figure out what could possibly cause something that does link to mir, to be run in that case
[19:37] <dobey> and i just don't see anything
[19:37] <TJ-> I suspect its the XDG_* vars
[19:38] <dobey> eh?
[19:39] <TJ-> looks like bug 1463263
[19:39] <dobey> TJ-: why not strace and follow the forks/threads to see what else gets run?
[19:39] <TJ-> dobey: I suspect the failing Lubuntu system doesn't have those XDG_ vars that this Ubuntu has in each user's session
[19:39] <TJ-> dobey: I don't have direct access to the failing system right now
[19:40] <dobey> i don't understand what's failing exactly. you ssh to a remote system and then try to run something on that remote system's own local display?
[19:40] <TJ-> interesting that bug has the quote "The "gdk_mir_display_open" error is just GDK/GTK trying to use Mir because it found no X11 server ($DISPLAY is blank)."
[19:40] <TJ-> dobey: No, ssh is sarnold's issue :)
[19:41] <dobey> *shrug* ssh -X works fine here
[19:42] <TJ-> dobey: 2 completely unrelated separate systems here, trying to use the same mechanism to cause a (yad) window to be displayed in "user1" X session, triggered by "user2" non-GUI script doing "sudo /usr/bin/env DISPLAY=:0 XAUTHORITY=/home/user2/.Xauthority yad ...args..." ... I use xclock just to test it
[19:43] <TJ-> user2 has sudoers NOPASSWD rights to /usr/bin/env so no user prompting is required
[19:43] <sarnold> TJ-: are perms on /home /home/user2/ and /home/user2/.Xauthority all correct?
[19:44] <TJ-> the background to this is some automated scripts the bring up a public Internet connection (wifi) and then a secure VPN, and inform the user whats' going on and, if the public internet is detected to have a captive portal, uses that mechanism with xdg-open http://some.domain/ to cause "user1" to see the captive portal login page
[19:45] <TJ-> sarnold: yes, totally separate, and thatts why 'sudo' is being used, to ensure access to the files
[19:45] <TJ-> I'll be in front of the Lubuntu system on Sunday, but hopefully I can get some background on this before then
[19:48] <dobey> TJ-: and the user was definitely logged in on the remote machine?
[19:49] <TJ-> interesting  bug 1433165 suggests it could be triggered by an apparmor profile
[19:51] <TJ-> dobey: yes, it's complicated, but user1 is the UID 1000 default user account ... user2 is a 2nd account used to contain the scripts and execute them such that user1 cannot mess them up. user2 has certain sudoers NOPASSWD permissions to run a few system commands via sudo with no need of user interaction
[19:52] <TJ-> As I said, this looks to be partially due to the failing system being Lubuntu, so potentially a few things are different in the session env
[19:54] <dobey> TJ-: as i said, i think you should strace to see where the actual failure happens. xclock and sudo don't link to libmirclient, so they can't possibly be trying to open a mir socket (unless of course the xclock is actually a link to some other app, which does link to libmirclient).
[20:00] <TJ-> it'll be the gtk/gdk libraries I presume
[20:00] <stokachu> @pilot out
[20:03] <TJ-> aahhhh gdk/mir/gdkmirdisplay.c
[20:04] <dobey> well yes, obviously gtk+ has support for mir
[20:04] <dobey> but that doesn't explain your issue with xclock
[20:04] <dobey> xclock does not use gtk+
[20:04] <dobey> or gdk
[20:06] <sarnold> there is a surprising number of libraries there though http://paste.ubuntu.com/16534039/
[20:06] <sarnold> my guesses, libfreetype, libfontconfig
[20:07] <sarnold> also why xclock needs a bloody xml parser .. *sigh*
[20:08] <TJ-> ignore xclock, that is misleading. The first of several real commands that fails is xdg-open (synaptic is another one) ... xdg-open is a shell script that runs different programs based on the DE. for LXDE it used pcmanfm which is linked to gtk
[20:08] <dobey> sarnold: apt-cache rdepends libmirclient9 doesn't show fontconfig or freetype as needing it
[20:08] <sarnold> dobey: ldd
[20:08] <sarnold> oh I see, read too fast
[20:08] <sarnold> or rather, read too poorly :)
[20:09] <dobey> TJ-: well if it's misleading, that's your fault. you said it didn't work and gave you that mir error. if that's not true, why did you say it? :)
[20:09] <TJ-> that explains the error message, but it'll take some time to work backwards to figure out what is missing in the environment that caused the code to fall through to the mir code
[20:10] <dobey> well, it couldn't connect to the X display
[20:11] <TJ-> dobey: I gave it as an example of a quick test we tried to minimize the externals. But, the actual scripts use xdg-open yad and others, so tracing xdg-open now I know where the error is coming from, will actually help us find a workaround
[20:19] <Saviq> who has access to snakefruit and could follow https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests to re-run the unity8 tests with --all-proposed? it's trying to build old unity8 with new unity-api and that won't work
[20:19] <Saviq> the unity8 tests for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api I meant
[20:19] <Saviq> as we're in a chicken'n'egg situation
[20:20] <sarnold> Saviq: just curious does that mean one of the packages is missing a version dependency of some sort?
[20:22] <Saviq> sarnold, we never came up with the right way to encode those dependencies, we have a unity8 B-D: unity-api-dev >> $version
[20:23] <Saviq> and a new unity-api-dev can break unity8 build
[20:23] <lpotter> well... my update to xenial went better than the last time I tried...
[20:24] <dobey> Saviq: it's only an issue becasue autopkgtests rebuild unity8 right?
[20:24] <Saviq> dobey, bits of it still, yes
[20:24] <Saviq> we're thinking how to avoid that
[20:24] <Saviq> now that I think of it if we build-depended on a virtual package provided by unity-api-dev (is it even supported to B-D on a virtual package?), it would make it better
[20:25] <Saviq> because a "breaking" unity-api-dev wouldn't Provide that any more
[20:25] <dobey> hmm, well, unity8 seems to be flagged as always failing on yakkety, at least in my pay-service silo: https://requests.ci-train.ubuntu.com/static/britney/yakkety/landing-056/excuses.html
[20:26] <Saviq> dobey, yeah but it's uninstallable
[20:26] <Saviq> because of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api
[20:26] <dobey> but http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html doesn't show that any more
[20:26] <dobey> err
[20:26] <dobey> s/more/where/
[20:26] <Saviq> i.e. https://requests.ci-train.ubuntu.com/static/britney/yakkety/landing-058/excuses.html
[20:27] <Saviq> unity8-common/amd64 unsatisfiable Depends: unity-scopes-impl-12
[20:27] <Saviq> and that is provided by unity-scope-shell, depending on the above unity-scopes-api, which regressed unity8... you know the drill...
[20:28] <Saviq> *unity-scopes-shell
[20:28] <Saviq> https://launchpad.net/ubuntu/+source/unity-scopes-shell/0.5.7+16.04.20160505-0ubuntu2
[20:49] <Logan> hmm, any core devs around who want to trigger a no-change rebuild on portaudio19?
[20:49] <Logan> see: https://launchpad.net/ubuntu/+source/espeakup/1:0.71-27/+build/9779375
[20:49] <Logan> (it needs to be rebuilt against the pie-by-default compiler)
[21:19] <Logan> slangasek, maybe?
[21:19]  * slangasek tries to look busy
[21:19] <Logan> :P :P
[21:21] <slangasek> sbeattie: ^^ shouldn't portaudio19 have turned up in your list of libs for PIE no-change rebuilding?
[21:23] <Logan> tsk tsk
[21:25] <slangasek> Logan: portaudio19 uploaded
[21:25] <Logan> cheers!
[23:46] <rlaager> stgraber: Can you test the proposed fix in: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1567558
[23:53] <sarnold> rlaager: cool :D


[03:35] <lifeless> win 24
[05:19] <csilk> so why is lp going so slow?
[06:31] <poolie> it looks like soyuz no longer sends mail when packages complete building or are published?
[06:31] <Hobbsee> poolie: er...did it ever do that?
[06:32] <poolie> i thought it did
[06:32] <poolie> for PPAs i mean
[06:32] <poolie> i remember people complaining about it :)
[06:32] <Hobbsee> poolie: don't think so - mails are sent for packages being accepted (or rejected), and for build failures.
[06:32] <poolie> ah, maybe it was only for failure
[06:33] <Hobbsee> may well have been
[06:33] <poolie> that seems strange but maybe it's just me
[06:33] <Hobbsee> well, wouldn't you normally find out when you updated your system again?
[09:53] <wgrant> Who let tdflanders onto launchpad-users!?
[12:15] <tobydox> hi
[12:15] <tobydox> is there any possibility to reset my PPA to start all over?
[12:16] <persia> tobydox, Not really.  You could delete everything, but the record of the uploads would still remain, so you'd have to use larger version numbers when starting over.
[12:17] <tobydox> :-/
[12:17] <tobydox> I mean someone of the admins can't just reset it?
[12:18] <tobydox> persia: the problem is: I can't delete superseeded packages
[12:19] <persia> tobydox, Why would you need to do that?
[12:19] <tobydox> because those buggy builds are still in the archives
[12:19] <wgrant> Superseded packages will be deleted automatically.
[12:20] <tobydox> hm but seems to take much longer
[12:20] <persia> Well, deleted from the archive.  LP will still have them for recovery/comparison if required.
[12:32] <EricIsGood> I'm trying to view http://bazaar.launchpad.net/~mysql/mysql-server/mysql-5.0/files but keep getting "please try agian"
[12:33] <wgrant> EricIsGood: The MySQL branches are huge... normally if you try a few times or perhaps wait a few minutes it will cache enough that it will work and continue to work.
[12:35] <EricIsGood> thanks... I'm trying to find the mysql source for Rand... any idea where it is in there repository?
[12:35] <wgrant> I don't know much about MySQL's code.
[12:36] <EricIsGood> does launchhpad have a source search function?
[12:47] <beuno> mdke, restarting the codebrowse server
[12:47] <beuno> you should be able to access the page in a few minutes
[12:50] <wgrant> beuno: Working for me now. Thanks.
[12:51] <beuno> :)
[12:52] <wgrant> EricIsGood: It seems to work now.
[12:55] <mwhudson> new record rss size for codebrowse!!
[12:55] <wgrant> mwhudson: How huge?
[12:55] <wgrant> And why does it leak so much?
[12:55] <mwhudson> wgrant: if we knew, we'd fix it
[12:57] <wgrant> Hmm.
[12:57] <NCommander> morning beuno
[13:10] <beuno> mornin NCommander
[13:10] <NCommander> beuno, care to look at a question on LP for me?
[13:11] <beuno> NCommander, sure
[13:11] <beuno> I'm off to lunch
[13:11] <beuno> but I'll get to it in an hour
[13:11] <beuno> paste it
[13:11] <beuno> \I'll read when I get back  :)
[13:11] <NCommander> ah
[13:48] <sgornick> How does one report "inappropriate content"?  I came across comment spam:  https://answers.launchpad.net/launchpad-answers/+question/14154
[13:49] <persia> sgornick, Generally asking a question asking the offensive content to be removed.
[13:52] <sgornick> persia, thanks for your reply.  Meaning, asking a question via e-mail to someone on the helprotation list?  Or here in #launchpad,  or ... other method?
[13:52] <persia> On answers.launchpad.net
[13:53] <persia> Even when there is a help contact available, it's nice to have it for review/audit purposes.
[13:54] <sgornick> persia, I see ... similar to this one: https://answers.launchpad.net/malone/+question/45120
[13:55] <persia> Well, my browser doesn't seem to be opening any pages right now, but I suspect so.
[13:58] <beuno> NCommander, back!
[13:59] <NCommander> wb
[14:04] <beuno> NCommander, so, did I miss your question?
[14:04] <NCommander> beuno, oops
[14:04] <NCommander> beuno, https://answers.edge.launchpad.net/launchpad/+question/48531
[14:09] <beuno> NCommander, I'll get cprov or bigjools to take a peak at it between sessions
[14:09] <edsu> can someone help a noob understand how to push some code to https://launchpad.net/pymarc ?
[14:10] <beuno> edsu, have you seen https://help.launchpad.net/BzrHowto ?
[14:12] <edsu> beuno: not yet, thank you, i will read
[14:12] <beuno> edsu, feel free to ask if you still can't push
[14:19] <edsu> so in ~launchpad_user_or_team/project_name/branch can i leave off 'branch' to push to the trunk?
[14:19] <beuno> edsu, if you define a development focus for that project
[14:20] <beuno> you can just do:    bzr push lp:projectname
[14:24] <edsu> how do i defined the development focus?
[14:24] <edsu> s/defined/define/
[14:25] <edsu> i get an error like this when I try to push lp:pymarc ; bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Evcs-imports/pymarc/trunk/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
[14:27] <beuno> edsu, you didn't do:  bzr launchpad-login <username>
[14:27] <edsu> nope, but that wasn't in that howto either
[14:27]  * edsu tries
[14:28] <beuno> edsu, it isn't
[14:28] <beuno> it should  :)
[14:28]  * beuno looks
[14:32] <edsu> ok, i logged in ok (added my key to lp)
[14:32] <edsu> but now i get this: bzr: ERROR: Cannot lock LockDir(lp-46042832:///~vcs-imports/pymarc/trunk/.bzr/repositorylock): Transport operation not possible: readonly transport
[14:32] <edsu> note: i didn't set up pymarc initially, a lp admin did apparently, they took the code from my private repo and put it in lp, and i'd like to update it
[14:33] <beuno> edsu, ah
[14:33] <edsu> i imagine i might have to ask someone for permission to do that?
[14:33] <beuno> you can't push to vcimports...
[14:33] <beuno> hm
[14:34] <beuno> edsu, was that a one time import?
[14:34] <kiko-zzz> edsu, you should create a new branch now!
[14:34] <beuno> because if it's continuos, then you can't really push to it
[14:34] <edsu> here's what i'm looking at: https://launchpad.net/pymarc
[14:34] <edsu> so does it automatically pull?
[14:34] <beuno> edsu, imports do, yes
[14:35] <beuno> *but*, you probably want the project in launchpad/bzr, right?
[14:35] <beuno> you can always merge from the import
[14:35] <edsu> well i'm ok with it being elsewhere, as long as it updates
[14:35] <edsu> as long as lp updates i mean
[14:35] <beuno> edsu, so you'll push elsewhere?
[14:35] <beuno> it'll be slower though
[14:36] <beuno> because it has to import n' stuff
[14:36] <edsu> how much slower? is it known how often lp pulls?
[14:36] <beuno> it varies
[14:36] <cjwatson> it sounds like you actually want to push to ~edsu/pymarc/trunk (or whatever your LP username is, or ~team)
[14:36] <beuno> so *much* slower
[14:36] <cjwatson> and then set that as the development focus
[14:36] <cjwatson> and regard ~vcs-imports as obsolete
[14:36] <beuno> I think cjwatson is right  :)
[14:36] <edsu> cjwatson: ahh :)
[14:36] <edsu> how do i set the development focus again?
[14:36] <beuno> edsu, edit the branch
[14:37] <beuno> when you upload a new branch
[14:37] <beuno> you'll see an edit icon next to the title
[14:37] <mwhudson> https://code.edge.launchpad.net/~vcs-imports/pymarc/trunk
[14:37] <mwhudson> what?
[14:37] <mwhudson> how did that end up like that?
[14:37] <mwhudson> it's a mirrored branch, but owned by vcs-imports
[14:40] <cjwatson> edsu: if you decide you want to do the mirrored branch thing (pulls every few hours, IME) then you can set that up from https://code.launchpad.net/pymarc/+addbranch
[14:40] <cjwatson> I do that for man-db
[14:40] <cjwatson> which is a situation where the initial branch was created by ~vcs-imports by importing a CVS repository, but that's now obsolete
[14:42]  * edsu pushes
[14:49] <edsu> i guess if want to update the url that https://code.edge.launchpad.net/~vcs-imports/pymarc/trunk is pulling from i'd have to talk to Tim Penhey?
[14:50] <beuno> edsu, why do you want to update the URL?
[14:50] <beuno> you can just push a new branch to LP
[14:50] <beuno> or do you still want to commit remotely?
[14:52] <edsu> well it would fix the problem of the url not being correct anymore
[14:53] <thumper> edsu: you can ask a question on launchpad-bazaar and someone will get to it
[14:53] <edsu> i did just push, but i don't see anywhere how to set the development focus at https://code.edge.launchpad.net/pymarc
[14:54] <beuno> edsu, https://code.edge.launchpad.net/~ehs-pobox/pymarc/trunk
[14:54] <beuno> you should see an edit icon next to the title
[14:54] <thumper> edsu: did you want me to delete the vcs-import branch?
[14:55] <thumper> edsu: is this your project?
[14:55] <thumper> edsu: if it is we can change the project maintainer to you rather than the registry admin team
[14:55] <edsu> it is my project yeah
[14:56] <thumper> edsu: once you are the maintainer, you can set the dev focus
[14:56] <edsu> so i set the radio button to 'Development'?
[14:56] <thumper> edsu: that doesn't make it the dev focus
[14:57] <thumper> kiko: can we give edsu the pymarc project?
[14:57] <edsu> ahh ok, how do i become the maintainer? should i talk to Tim Penhey mentioned here https://code.edge.launchpad.net/~vcs-imports/pymarc/trunk ?
[14:57] <thumper> edsu: that's me
[14:57] <edsu> thumper: oh hi :)
[14:57]  * beuno tries to remember how to set the dev focius
[14:57] <edsu> thumper: thanks for adding pymarc to launchpad a while back :)
[14:57] <thumper> edsu: however we need an lp admin to change the project maintainer from the registry admin to you
[14:57] <edsu> thumper: gotcha
[14:57] <thumper> beuno: from the series
[14:58] <thumper> beuno: we should have a link on the project code page
[14:58] <beuno> ah, ew
[14:58] <beuno> actually
[14:58] <beuno> kinda no
[14:58] <thumper> beuno: maybe, maybe not
[14:59] <kiko> thumper, sure. does he want it?
[14:59] <thumper> beuno: we can talk later
[14:59] <beuno> https://launchpad.net/pymarc/+edit
[14:59] <thumper> kiko: yes,
[14:59] <beuno> edsu, ^
[14:59] <beuno> on the bottom
[15:00] <kiko> edsu, what's your launchpad id?
[15:00] <kiko> thumper, edsu: saw the privmsg, done
[15:00] <kiko> edsu, yours :)
[15:00] <edsu> kiko++ # thanks
[15:01] <edsu> bueno++
[15:01] <edsu> thumper++ # too for patience, and info
[15:01] <thumper> edsu: https://edge.launchpad.net/pymarc/trunk, there is a menu on the RHS to link to branch
[15:01] <thumper> edsu: put your branch in there
[15:02] <thumper> edsu: I'll mark the old vcs-import branch as abandoned
[15:04] <edsu> odd i can't seem to find my branch in the 'Select a Branch' menu, it only seems to find stuff in ~vcs-imports
[15:05] <thumper> edsu: just type in your lp id
[15:05] <thumper> edsu: and it should find your branch
[15:05] <edsu> right on
[15:06] <thumper> edsu: worked?
[15:06] <kiko> thumper, yeah, that vocab is weird
[15:06] <edsu> think so
[15:06] <thumper> kiko: yeah, kinda
[15:06] <thumper> kiko: we should change the widget rather than the vocab
[15:06] <thumper> implementation details
[15:06] <thumper> edsu: yep it worked
[15:06] <beuno> thumper, talking about implementation details
[15:06] <mwhudson> "invalid input, which of these 1 options did you actually mean?!"
[15:06] <edsu> sweet, thanks much
[15:06] <beuno> I found my "ToDo with thumper at Epic" note
[15:07] <thumper> edsu: you'll notice you can get your branch with `lp:pymarc` now
[15:08] <edsu> very nice
[15:09] <thumper> edsu: I notice that your last three commits don't have full email addresses in the bzr commit log
[15:10] <thumper> edsu: new machine?
[15:23] <edsu> thumper: yeah, is it just ed@hammer?
[15:23] <thumper> edsu: uh ha
[15:23] <thumper> edsu: `bzr whoami`
[15:23] <edsu> thumper: i hadn't run bzr whoami yet on that machine :(
[15:23] <thumper> edsu: no time like the present
[15:23] <edsu> yup already done sir
[15:23]  * beuno has a half-baked patch for bzr to warn you about that
[16:44] <aladin> How can I add me to the list named "Also notified" of a bug?
[16:45] <thekorn> aladin: subscribe to the bug mail for this project/package
[16:48] <thekorn> aladin: if it is a rojects the link is like https://bugs.edge.launchpad.net/yourproject/+subscribe
[16:49] <thekorn> or for a package : https://edge.launchpad.net/mydistro/+source/mypackage/+subscribe
[16:51] <aladin> thekorn: I want to be notified by https://bugs.launchpad.net/ubuntu/+bug/102910    Have I do click to "Subscripe"?
[16:53] <thekorn> aladin: in this case click on "subscribeÂ" to get all bugmails for tjhis bugreport
[16:56] <aladin> thekorn:  OK. Now I am on the list of Subscribers. How can I put me on the list "Also notified" in this case?
[16:57] <andrea-bs> aladin: do you want to receive notifications about all bugs in ubuntu?
[16:58] <persia> aladin, You *don't* want to receive notifications about all bugs in ubuntu.  The volume is high enough that it will probably break your mail client unless you have specialised scripting in place.
[16:58] <aladin> andrea-bs: About all bugs? No. About some bugs...
[16:59] <andrea-bs> aladin: are you interested in some specific packages?
[17:01] <aladin> andrea-bs: Yes, but also interested in some bugs without corresponding packages (Bug 102910).
[17:02] <mpt> ooh, that's an interesting and useful thing
[17:02] <andrea-bs> aladin: well, actually you can only subscribe to specific packages or to everything in ubuntu
[17:02] <mpt> subscribed to all bugs without packages
[17:02] <mpt> report a bug asking for that :-)
[17:03] <mpt> (Actually, that would probably still be a deluge)
[17:04] <aladin> andrea-bs: OK, thank you!
[18:19] <calc> why does this bug show up as an upstream pending bug for OOo?
[18:19] <calc> https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/216995
[18:19] <calc> er pending_bugwatch to be precise
[18:52] <mae^> can someone help me.. when I branch the ActiveRDF trunk I'm only getting 1 revision in the branch history though I can see all the revisions through the loggerhead interface
[18:55] <beuno> mae^, what's the URL?
[18:55] <mae^> https://bazaar.launchpad.net/~activerdf/activerdf/trunk/
[18:56] <beuno> mae^, ah, the branch seems borken somehow
[18:57] <beuno> do you have write access to it?
[18:58] <mae^> dont think so
[18:58] <beuno> mae^, ok, I'll try and get an admin to look at it
[18:59] <mae^> thanks
[19:35] <beuno> mae^, trying to fix it now...
[19:48] <mae^> beuno: great!
[19:51] <mthaddon> mae^, should now be fixed
[20:44] <det> I have source packages compatible with both ubuntu and debian, does launchpad offer a PPA service for Debian ?
[20:44] <beuno> det, it doesn't for now
[20:44] <det> If not, are there any other services that I can use ?
[20:45] <beuno> I wouldn't know who else provides build serviced...
[20:52] <NCommander> det, SuSE's build service supports Debian, but that may not be what you are looking for
[20:53]  * NCommander notes that more for building custom distributions
[21:02] <mae^> mthaddon: hrmm.. nope  http://pastie.org/297452
[21:03] <mthaddon> mae^, thx - we just realized this here - still working on it... :(
[21:07] <beuno> mae^, that actually looks alright
[21:07] <beuno> 717 revisions
[21:12] <mae^> beuno: look at the branch history.. 1 revision
[21:12] <beuno> mae^, try running:  bzr reconcile
[21:14] <mae^> holy fsck! that was it! what did that do?
[21:14] <beuno> to me, it's mostly magic
[21:16] <mae^> so doesn't that mean the branch on the launchpad side needs the same?
[21:16] <beuno> yes
[21:17] <beuno> we ran it
[21:17] <beuno> I don;t know why it's still broken
[21:17] <beuno> some moving part I don't know about
[21:18] <mae^> hrmm. so is it fixable?
[21:22] <beuno> yes
[21:22] <beuno> I'll email the owner
[21:22] <beuno> unless you know him
[21:23] <mae^> I talked with him last night, he didn't know what to do and only had a lightweight checkout on his machine so he didn't have any of the old revisions
[21:24] <beuno> mae^, get him to run:    bzr reconcile lp:activerdf
[21:24] <beuno> and it'll get fixed
[21:24] <beuno> I have a copy of the branch
[21:24] <beuno> so we can find out what went wrong
[21:24] <mae^> ok, I'll pass that along
[21:25] <beuno> thanks
[21:29] <mae^> thank *you*
[21:29] <huayra> !bug #1
[22:28] <awilkins> Question : what are the odds of you lot releasing launchpad sources to a major national governmental organisation for internal trial and development?
[23:04] <Odd_Bloke> I'm looking at https://code.launchpad.net/~daniel-thewatkins/bzr-twitter/bzr-twitter and am wondering if Launchpad might have a copy from before whatever went wrong on my end went wrong?
[23:15] <kiko> Odd_Bloke, hmmm, probably not
[23:16] <Odd_Bloke> :(
[23:16] <Odd_Bloke> I'll look at this more tomorrow.
[23:16] <Odd_Bloke> kiko: Thanks for answering. :)


[02:33] <excalibr> good morning eberywant
[02:37] <fairuz> excalibr: hello bro
[02:44] <excalibr> hai..
[02:45] <excalibr> this channel is quiet as always
[03:23] <fairuz> tu ler
[04:10] <excalibr> te lur
[13:39] <excalibr> Docker is pretty interesting..
[13:40] <excalibr> http://www.docker.io/ ('Docker - the Linux container engine')


[13:43] <OvenWerks> Just updated my 15.10 install. It actually did a distro upgrade... that is a lot has happened.
[13:44] <OvenWerks> I think I originally installed 15.10 soon after the first changes, so it was pretty close to 15.04.
[13:45] <OvenWerks> The login screen is fixed! \o/
[13:45] <OvenWerks> My settings for dual screens was not kept, I had to redo it.
[13:46] <OvenWerks> It went back to "mirror".
[13:47] <OvenWerks> I turned mirror off... the two monitors were on the wrong side, so I swapped them... they were still on the wrong side.
[13:47] <OvenWerks> Second swap worked.
[13:49] <OvenWerks> I think this is X changing the monitor numbers. I think X tends to auto change whatever monitor is on the left to primary.
[13:52] <OvenWerks> Or maybe not any more... I think x or xfce changed the monitor numbers in 15.04 and doesn't now. Something odd anyway. But it works ok once set.
[13:53] <OvenWerks> We really need to get rid of arandr now that Display works for everything.
[13:54] <OvenWerks> Having two display settings apps is confusing. It was just the only choice when we first added it and the need for it was gone the very next release.
[13:58] <OvenWerks> Ardour4 is correctly labled. Should be updated to 4.1. 4.2 is almost out. Ardour seems to be going through a lot of development. The gui is going to change 4.2 or 4.3.
[14:03] <OvenWerks> Opps I have got something wrong, or the master menu config has changed for xfce. Our doc menu items appear in system as well as our own sub.
[14:06] <OvenWerks> There is a calligra item in office that fails/shouldn't be there. Comes with krita?
[14:10] <OvenWerks> I can make it not show, but if someone then installs calligra in studio they would be missing a menu item. I think it is a bug in packaging that there is a menu item (desktop file) installed for an app that is not installed.
[15:36] <OvenWerks> There is no reason (looking at all the menu files) why the category "Documentation" should end up in the System menu.
[15:37] <OvenWerks> We may have to exclude it.
[15:39] <OvenWerks> As an aside: the stock KDE and gnome menu files are as bad or worse than ours for complexity and special cases.
[15:40] <OvenWerks> The gnome menu spec has changed a lot since 14.04 where it was very basic.
[15:41] <OvenWerks> KDE has always been the odd one out though it has changed a lot too.
[15:42] <OvenWerks> I think in both cases, the movement away from using menus has given feedback that those who still do use menus like them very much and would like to see improvements with them rather than abandoning them.


[00:50] <infinity> Oh look.  Linux 3.10.
[00:51] <infinity> apw: ^-- I'm assuming no one minds if we don't let that migrate until after the alpha?
[00:51] <bjf> c'mon, what could go wrong?
[00:52] <infinity> bjf: Nothing, the kernel team is perfect, and a beacon of light and hope to the world.
[00:52] <bjf> infinity, exactly, we exhaustively tested it, there are no bugs in it
[00:53] <infinity> bjf: Oh, if there are no bugs, then that's cool.
[00:57] <bjf> but then, i only care about stable :-)
[06:20] <didrocks> thanks a lot infinity :)
[07:58] <apw> it seems rtg's upload yesterday missed the fix for the autopkgtest definitin
[07:58] <apw> definition, should i fix and re-upload or shall we 'ignore' it as previously
[07:59] <infinity> apw: That's okay, I wasn't planning on letting it migrate anyway, unless you really want to disrupt alpha1 with a brand new upstream.
[07:59] <apw> infinity, heh no indeed
[07:59] <infinity> apw: So, you have until thursday/friday to upload a new one if you want, no rush.
[08:00] <apw> infinity, may as well upload a new one then, to confirm that autopkgtest sorts itself out
[08:00] <apw> infinity, though i guess i don't want to ram the buildds ...
[08:01] <infinity> apw: Meh, the buildds are fine, as long as you don't upload 8 kernels in an hour for 5-character fixes.
[08:05] <apw> infinity, this will be one in an hour for a 10 character fix, sigh
[08:05] <infinity> apw: You keep strange time.  Tim's upload was ~12h ago.
[08:06] <apw> infinity, :)
[09:07] <xnox> infinity: didrocks: that unity raring SRU have version numbers higher than saucy: libgrip, libcompizconfig0, libdecoration, compiz, g-c-c-u, ..... E.g. saucy has 0.3.6daily13.06.10-0ubuntu1, while raring-proposed now has 0.3.6daily13.06.19~13.04-0ubuntu1
[09:08]  * xnox goes to figure out why my saucy box has raring-proposed enabled....
[09:08] <didrocks> xnox: hum, that's a good point, I thought about same release day release and thus, this appending of ~13.04…
[09:09] <didrocks> but yeah, there is a versionning issue in that case, I need to think about it
[09:09] <xnox> didrocks: I mean the quick solution is to force release/bump version numbers in saucy.
[09:09] <didrocks> xnox: well, we are going to have a release today once the tests failing are fixed
[09:09] <xnox> didrocks: or have saucy bump "upstream" version number, with each ubuntu series.
[09:10] <seb128> didrocks, including compiz?
[09:10] <didrocks> xnox: bump it's difficult when you have 90 components to have upstream bumping their version and all them agrees :)
[09:10] <didrocks> seb128: not today, but in the coming week normally
[09:10] <seb128> cool
[09:10] <didrocks> there is one regression with compiz trunk they need to fix
[09:10] <didrocks> (Qt apps behind the top panel)
[09:10] <seb128> I was not sure how much that one was on the "it works, don't touch it" state
[09:10] <seb128> ;-)
[09:10] <xnox> didrocks: hehe. Always encode "13.10" before date?
[09:11] <seb128> yeah for even longer version number?
[09:11] <didrocks> seb128: seems that would be the road…
[09:11] <didrocks> xnox: thanks for the pointer, noting it and will deal with it
[09:12] <xnox> didrocks: no worries, it's hardly the end of the world. We will have daily release before saucy goes out the door ;-) to make saucy higher again.
[09:12] <seb128> didrocks, yeah, sort of make sense ... if we want shorter versions we should just drop the "<upstream>daily" part, but that's another "battle"
[09:12] <didrocks> if only upstream fixed their tests everyday or their FTBFS, we won't have this issue
[09:12] <didrocks> xnox: yep, I just want to avoid that issue if possible ^
[09:12] <didrocks> seb128: I tried starting that one :)
[09:13] <didrocks> seb128: but it's a very very long term plan :p
[09:13] <infinity> didrocks: Well, unless the code in 0.3.6daily13.06.10-0ubuntu1 and 0.3.6daily13.06.19~13.04-0ubuntu1 somewhat match, those versions are meaningless anyway without an upstream bump of some sort on a new series.
[09:13] <didrocks> infinity: they don't match, but that's why for SRUs you have ~13.04
[09:13] <didrocks> so that you don't have in raring and saucy 2 0.3.6daily13.06.19-0ubuntu1
[09:13] <didrocks> with different content
[09:13] <infinity> But that's not what ~foo means.  It doesn't mean "this is completely different, but the same version". :P
[09:14] <infinity> At least, not to most people.
[09:14] <didrocks> infinity: well, suggestions welcomed :)
[09:14] <infinity> I expect my 1.2.3-4 and 1.2.3-4~foo to be basically the same thing.
[09:14] <didrocks> to cope with autobumping, upstream merger, and all those use case, with transitionning, having the same version in both saucy and raring
[09:14] <infinity> If they're two different upstream branches, the upstream versions should really reflect that better.
[09:14] <didrocks> while keeping when upstream doesn't bump to have raring > saucy
[09:15] <didrocks> oupss <
[09:15] <didrocks> infinity: go convince for those 90 components :p
[09:15] <infinity> I don't see how that's hard...
[09:15] <infinity> Surely, they're all versioned simply enough that one can bump at least a minor/micro or something.
[09:15] <didrocks> infinity: please open a discussion with PS, I already tried it…
[09:16] <infinity> They used to bump versions on new series before this daily landing stuff...
[09:16] <infinity> We got a new unity with every series.
[09:16] <didrocks> infinity: unity, yeah, not for all components
[09:16] <seb128> they should probably just do "serie.date"
[09:16] <seb128> <IP_ADDRESS>
[09:17] <infinity> Yeah, if they don't care about strict and sane branch-based versioning, just using the series number would work.
[09:18] <didrocks> seb128: well, you know I've already proposed that
[09:19] <seb128> didrocks, right, that's why I wrote "that's another battle" ;-)
[09:19] <didrocks> we could do the other way around, but the issue to do with <version>.<series> is that sometimes, they add a micro version (so an extra digit)
[09:19] <seb128> didrocks, but eventually we will get there
[09:19] <didrocks> seb128: I completely hope so :)
[09:20] <infinity> didrocks: So, why is it <upstream>daily<date>~series intead of <upstream>daily<series>~date?
[09:21] <infinity> didrocks: That wouldn't make me happy as far as versions being not-crack, but it would solve the ordering problem.  Cause saucy would always be >> raring.
[09:21] <didrocks> infinity: because <series> wasn't thought at first, and you were complaining about version too long already :)
[09:21] <didrocks> infinity: so that's why I only added it once we entered maintainance mode
[09:21] <infinity> didrocks: Yeah, the versions are insane (and the "daily" string is redundant).
[09:22]  * xnox thinks we are now past the point of caring of how long it is ;-)
[09:22] <seb128> I think we all agree here on that
[09:22] <infinity> didrocks: Heck, the date part itself might be pointless.
[09:22] <didrocks> infinity: again, will be pleased with a solution dealing with upstream's realities
[09:22] <infinity> didrocks: It could just be <upstream>+<series>.<int> where <int> is an integer that increments on every upload.  The date is encoded in the changelog, it doesn't need to be in the version.
[09:23] <xnox> where int, is bzr revno
[09:23] <infinity> xnox: Or that.
[09:23] <didrocks> xnox: I prefer date, it's more meanfull, especially with feature branch that are running in parallel
[09:23] <didrocks> xnox: otherwise, we won't be able to remerge
[09:23] <xnox> infinity: the date does give _some_ alignment though - e.g. everything is up to date.
[09:24] <didrocks> infinity: so you do expect that <upstream>+<series> to be different upstream content than <upstream>+<series+1>
[09:24] <infinity> xnox: And that would be relevant, if the other 6000 packages on your system also showed the date in dpkg -l
[09:24] <infinity> didrocks: No, I still think it's crack for upstream to not rev their versions, but as you say, I can't control that.
[09:24] <xnox> infinity: touche
[09:25] <infinity> didrocks: But it's saner for YOU to do <upstream>+<series> instead of <upstream>+<date> and tack series on as an afterthought, cause mine sorts correctly. :P
[09:26] <infinity> Sadly, this probably can't be changed for raring now (though, dpkg --compare-versions may tell me otherwise, let's see...)
[09:26] <didrocks> infinity: I tried with dpkg --compare-versions and it seems fine
[09:26] <infinity> Oh, wait.  Yay.
[09:26] <infinity> (base)adconrad@cthulhu:~$ dpkg --compare-versions 0.3.2+13.04 gt 0.3.2daily13.06 && echo Yes
[09:27] <infinity> Yes
[09:27] <infinity> So, yeah.  That could work quite nicely.
[09:27] <didrocks> infinity: ok, I'll implement that then
[09:27] <didrocks> let me try some other cases
[09:27] <didrocks> with features branch in particular
[09:27] <didrocks> (which have another versionning to deliver in a ppa, while still being compatible with distro once merged back)
[09:27] <infinity> Fun.
[09:28] <infinity> I don't envy your life.
[09:28] <didrocks> isn't it? :)
[09:28] <didrocks> ahah
[09:28] <didrocks> if it works, I'll handle the transition the sanest possible way
[09:28] <didrocks> this means that upstream shouldn't use + in the upstream versionning
[09:28] <infinity> Also, I'd pay good money to stop having useless changelog entries that say "automatic snapshot".  Which could go away if the revno was in the version. :P
[09:28] <didrocks> which isn't unreasonable to ask :)
[09:28] <didrocks> infinity: well, we can add the revno in the version, but that would be in addition to the date
[09:29] <didrocks> so I don't think you want it :p
[09:29] <infinity> I was thinking instead of the date.
[09:29] <infinity> But yeah, I don't want both.
[09:29] <didrocks> not possible again because of feature branch
[09:29] <infinity> Cuase I think date.date is CONFUSING.
[09:29] <didrocks> having different revision meaning other things
[09:29] <infinity> Well, if you use datestamps instead of dates-as-versions, it's a bit less confusing.
[09:30] <didrocks> datestamps?
[09:30] <didrocks> infinity: what about 0.3.2+13.04+13.06.03 for instance? (two +, but at least, more readable)
[09:30] <infinity> Like, 0.3.6+13.04.20130627 is less confusing than 0.3.6+<IP_ADDRESS>.27 where we have a repeating thirteen dot oh something.
[09:31] <didrocks> yeah, that as well
[09:31] <didrocks> then still .1, .2, .3
[09:31] <didrocks> if we rerelease the same day?
[09:31] <infinity> Sure, yeah.  Same as we date stamp ISOs.
[09:31] <didrocks> I'm good with this schema
[09:31] <didrocks> let me ensure all corner cases are tackled
[09:31] <didrocks> and I'll work on this this week
[09:32] <infinity> I hate to bikeshed abot versions, but yeah, the current ones are wrong from sort order perspective, and just plain ugly. :)
[09:32] <infinity> And the "daily" thing is off-putting, especially for SRUs.
[09:33] <infinity> Nothing instills confidence in your stable updates like a daily snapshot. :)
[09:33] <didrocks> infinity: well, at least, happy that we can come up with a better situation :) (the maintenance/SRU case was expected to be looked at in 14.04 TBH because of rolling)
[09:33] <didrocks> infinity: well, on the contrary, we never had that much confidence thanks all the testing that is done automatically on a daily basis :)
[09:34]  * didrocks wonders if there is a tool somewhere to convert a code name is stable release series version
[09:35] <infinity> didrocks: I'm not saying that internally it's not better, just that externally, "daily" and/or "snapshot" are scary words. :)
[09:36] <didrocks> yeah, I understand :)
[09:37] <mlankhorst> didrocks: I failed to parse that sentence..
[09:38] <infinity> didrocks: I don't know of a codename<->version converter, you might suggest to bdrung that distro-info could grow some arguments to do that, since it has the tables anyway.
[09:39] <infinity> didrocks: Of course, you could write one with distro-info-data.
[09:39] <infinity> didrocks: /usr/share/distro-info/ubuntu.csv has what you're after.
[09:40] <didrocks> infinity: ah, excellent, yeah, will use that one, better than querying launchpad for that :)
[09:41] <cjwatson> Riddell,ScottK: There seems to be no migration block yet?
[09:42] <cjwatson> Or is somebody else doing it?
[09:42] <Riddell> cjwatson: I'm wondering the best way to do it
[09:42] <Riddell> cjwatson: i.e. best way to find the list
[09:42] <Riddell> cjwatson: is getting the source packages from the germinate output the best?
[09:42] <cjwatson> ScottK has done it in the past, I think.  I don't recall exactly what he did
[09:42] <cjwatson> Might be a case of trawling through IRC logs ...
[09:44] <cjwatson> http://irclogs.ubuntu.com/2012/12/05/%23ubuntu-release.html
[09:45] <Riddell> ah yes, the .sources files would be easier
[09:46] <cjwatson> http://irclogs.ubuntu.com/2012/12/05/%23ubuntu-release.html#t14:04
[09:46] <cjwatson> Has what's actually a better option
[09:46] <cjwatson> Take .manifest and .list from images, munge until you get a list of binary packages, map to corresponding source packages
[09:47] <infinity> (You probably want to wait for the new kde4libs to finish and get through)
[09:47] <infinity> Though, I guess you can unblock just that version after doing the generic block.
[09:48] <Riddell> that was my next question, there's a bunch of things still needing to get in, does an unblock override a block?
[09:48] <infinity> Yes.
[09:51] <cjwatson> bzr di -c58 lp:~ubuntu-release/britney/hints-ubuntu   if you want the list for raring beta-1
[09:56] <Riddell> cjwatson: that should be the block in place
[09:58] <cjwatson> that was quick, thanks :)
[09:58] <cjwatson> I'll watch it actually work once before starting auto-sync
[10:07] <Riddell> cjwatson: what does it mean if an autopkgtest is running?
[10:07] <Riddell> e.g. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kde-baseapps says autopkgtest for pango1.0 1.32.5-5ubuntu1: RUNNING
[10:07] <cjwatson> vast confusion because I haven't worked it out yet
[10:07] <Riddell> why does a test for pango affect kde-baseapps?
[10:09] <cjwatson> I think it's a known problem with excessive following of virtual packages
[10:09] <cjwatson> libpango1.0-doc Depends: www-browser, konqueror Provides: www-browser
[10:10] <cjwatson> jibel mentioned that as a known issue when fixing the converse problem (deps on virtual packages not being noticed at all)
[10:11] <cjwatson> looks like it might actually genuinely have been running and so should clear soon
[10:11] <cjwatson> perhaps I should make force imply force-autopkgtest
[10:13] <Laney> It was non-genuinely RUNNING but jibel was looking into that
[10:13] <Laney> maybe this new run will clear it out indeed
[10:14] <cjwatson> there was a run recently enough that it's plausible
[10:14] <cjwatson> Anyway, force implies force-autopkgtest now
[10:48] <cjwatson> Riddell: Could you please add versions to all your unblocks?  The syntax is "unblock SRC/VER"
[10:48] <Riddell> cjwatson: ah gotcha
[10:48] <cjwatson> unfortunately the bad syntax crashes proposed-migration - I should fix that
[10:53] <Riddell> oops sorry
[10:54] <cjwatson> I think I've fixed the crash now
[11:02] <bdrung> didrocks: it would make sense to enhance distro-info to convert codenames into version and vice versa
[11:03] <didrocks> bdrung: agreed, but in fact, it's independant of my problematic for dailies, thinking about it. I need to be able, when saucy is frozen to still daily release what will become t* content, but in the "next" ppa on saucy
[11:04] <didrocks> cjwatson: btw, read the technical board meeting about name. It's great to have this "next" as a name proposal. However, I'm disappointed now to have use that name for this transitional between 2 release ppa (ubuntu-unity/next), as they are close by usage and we'll get confusion ;)
[11:05] <bdrung> didrocks: distro-info needs to learn the freeze date for this use case
[11:06] <didrocks> bdrung: yeah, that may be a possibility and having the target in debian/changelog (saucy or t* deduced from the version + freeze/release date)
[11:06] <cjwatson> didrocks: mail technical-board@ please
[11:07] <cjwatson> I will forget
[11:10] <didrocks> cjwatson: not sure it worths mentionning TBH, an external ppa shouldn't infer the TB decision for distro
[11:11] <didrocks> s/infer/impact/
[11:14] <Riddell> infinity: you're a genius, kde4libs compiled
[11:15] <cjwatson> I'm retrying some associated failed builds now
[11:15] <Riddell> thanks
[11:16] <Riddell> infinity: what kind of storage does that pandaboard have?  I tried on mine and it ran out of disk space (4GB SD card)
[11:20] <StevenK> Riddell: I think they build onto USB drives
[11:23] <didrocks> infinity: xnox: seb128: and here we go! http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/330
[11:23] <didrocks> I'll deploy that today
[11:26] <cjwatson> schedule amended to move DIF to week 13; mail sent to ubuntu-release@; auto-sync running
[11:34] <cjwatson> [Updating] requests (1.2.0-2 [Ubuntu] < 1.2.3-1 [Debian])
[11:34] <cjwatson> oops, echan
[11:44] <Riddell> hmm, arm fail https://launchpadlibrarian.net/143356647/buildlog_ubuntu-saucy-armhf.kamera_4%3A4.10.80-0ubuntu1_CHROOTWAIT.txt.gz
[11:44] <cjwatson> better to link to the +build, then we can tell which builder it is
[11:45] <cjwatson> heka
[11:45] <cjwatson> reported to ops
[11:45] <cjwatson> and heka on manual
[11:48] <cjwatson> I've retried all heka's failures
[12:52] <cjwatson> Anyone fancy processing click-package in NEW?
[12:52] <mlankhorst> cjwatson: can you wipe xorg-server from raring unaccepted?
[12:56] <cjwatson> mlankhorst: I'll have to give a reason, so if you can give me one, that'd be good
[12:56] <mlankhorst> will regress
[12:56] <mlankhorst> it needs another fix because a regression was found when it was uploaded to saucy, sec let me get bug #
[12:57] <mlankhorst> hm doesn't seem to be one, but it broke nvidia prime support, unless another patch was also applied on top
[12:58] <seb128> cjwatson, let me have a look
[12:59] <cjwatson> $ queue -s raring-proposed -Q unapproved reject -m 'requested by mlankhorst; breaks nvidia-prime support' xorg-server
[12:59] <cjwatson> will do well enough
[13:00] <cjwatson> (done)
[13:00] <mlankhorst> thanks
[14:02] <skaet> stgraber,  cjwatson, infinity - my freenode password appears to need a reset - could one of you please edit the #ubuntu-release topic to indicate we're working towards Alpha 1 this week?
[14:03] <cjwatson> there
[14:03] <skaet> Thanks cjwatson :-)
[14:09] <seb128> cjwatson, click-package NEWed (sorry for the delay, still debugging gtk at the same time)
[14:10] <ogra_> clickedy click ...
[14:17] <cjwatson> seb128: cool, thanks
[14:22] <skaet> stgraber, my understanding from yesterday is you wanted to test the iso tracker will automatically create the milestone when the runs are triggered.   If that's not the case,  please let me know and I'll go in and add them now.
[14:23]  * skaet figures that some of the flavors want to start testing
[14:23] <stgraber> skaet: nope, what I said yesterday is that I'll create the milestone when the first flavour needs it
[14:23] <stgraber> skaet: and so far nobody asked for their first alpha1 spin
[14:23] <skaet> stgraber, ah, my misunderstanding.
[14:23] <stgraber> skaet: also, can you provide me with a list of all products participating in the alpha1 so I can populate the manifest? currently all I have is a list of flavours
[14:27] <skaet> stgraber,  assume the same products as are produced in the dailies for the flavors for now.    We've heard back from kubuntu, lubuntu, ubuntukylin, ubuntu gnome
[14:55] <skaet> stgraber,  based on input from Riddell,  Kubuntu will just be desktop i386 and amd64 ( no active or other architectures this time around)
[14:56] <stgraber> skaet: ok
[14:57] <skaet> stgraber,  I'm worried that the process of requesting a build isn't well understood with the flavors right now,  the MilestoneProcess page still has reference to an initial set being produced, and then a mail out.
[14:57] <xnox> stgraber: skaet: given that kde4libs on armhf got fixed, I thought there can be kubuntu+armhf something, unless we don't have any armhf kernel & X stacks left for a desktopy build.
[14:58] <xnox> Riddell: ^
[14:58] <skaet> Riddell, ^^ you
[14:58] <stgraber> skaet: well, I quite clearly mentioned the new process as a reply to your e-mail to all flavour leads...
[14:58] <skaet> s/you/you want ?/
[14:59] <stgraber> skaet: and mentioned it here a few times too (and in #ubuntu-quality), so if people haven't read any of that, ... their bad
[14:59] <skaet> stgraber,  yes. but given its Tuesday, and no requests have come in,  time to figure out the glitch
[14:59] <Riddell> xnox: yeah but it's pretty low priority for alpha 1
[15:00] <Riddell> xnox: also it won't work same as it didn't for 13.04, ubiquity don't work in that mode for some reason I'm yet to debug
[15:00] <xnox> ack
[15:01] <skaet> Riddell, are you waiting for anything, or do you want stgraber to kick the first set of builds off for your now?
[15:02] <cjwatson> xnox: the armhf stack is still mid-build
[15:03] <cjwatson> Though, admittedly, it should be sorted out by end of day or so
[15:08] <Riddell> skaet: I think lots of kde bits still need to get into -release
[15:09] <skaet> Riddell,  ack.
[15:11] <Riddell> skaet: calligra, kate, kde-baseapps, kde-workspace, kmix, ktp-text-ui, pykde4, rekonq
[15:12] <Riddell> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[15:13] <skaet> thanks
[15:33] <phillw> stgraber: has the fix for bug 1193526 hit the build area yet?
[15:33] <ubot2> Launchpad bug 1193526 in ubiquity (Ubuntu) "Clicking "Install Xubuntu 13.10" in live session doesn't work." [Undecided,Fix released] https://launchpad.net/bugs/1193526
[15:34] <gema> slangasek, cjwatson: hangout?
[15:35] <cjwatson> yep, we're just finishing off a 1+!
[15:35] <cjwatson> 1+1
[15:36] <gema> cjwatson: ack
[15:56] <stgraber> phillw: I'm only doing builds and publishing for this alpha1, so you'll have to track bugs and package version yourself this time around
[15:56] <stgraber> phillw: (though I did take a look at that one and the answer is no, it's not in the release pocket yet)
[16:13] <cjwatson> stgraber: ubiquity should have landed recently
[16:13] <cjwatson> Yep, looks like last publisher run
[16:14] <cjwatson> Several additions of python3-* I've noticed in binary NEW lately :)
[16:25] <phillw> stgraber: hi, I'm sorry, you will have to be patient with me. I'm still learning (and my email system is currently down). We had the cron for lubuntu turned off last night. Can the images currently in 'daily' be copied over to 'alpha 1'. I'm not 100% sure if the ubiquity bug from the LiveCD warrants a re-spin of an alpha 1 for lubuntu, I'll ask the other testers this evening (we have a lubuntu meeting tonight). If it does, I'll mark the desktop
[16:28] <cjwatson> phillw: I would say it probably does - it means you can't start the live installer from the desktop, which is pretty confusing
[16:29] <stgraber> phillw: copied
[16:30] <phillw> cjwatson: that is a moot point, as we have recently included ZRam to reduce the memory size of a desktop install from the CD. Launching a live session and then installing does seem counter intuitive. But, I'm the new boy here and will go with your recommendation.
[16:31] <cjwatson> zram doesn't really seem related to me.  One thing I've learned is that, even if it seems counterintuitive to me, if the facility's provided then people will try it :)
[16:31] <cjwatson> (I do think it's a useful facility; it lets you try the desktop out for a bit before deciding whether you want to install it.  That's why it's there)
[16:32] <phillw> okies, then stgraber can you respin desktop & upgrade and just copy over the alternate images.
[16:32] <stgraber> phillw: as I said earlier, I already copied everything. Please just mark those you want respin on the tracker
[16:32] <phillw> thanks, will do :)
[16:33] <phillw> stgraber: the upgrade ones aren't on there... are they handled differently?
[16:34] <cjwatson> upgrade isn't a "respin" FWIW
[16:34] <cjwatson> no spin involved :)
[16:34] <phillw> thanks.
[16:35] <phillw> stgraber: status updated
[16:35] <cjwatson> it's just a marker every so often for people to submit upgrade tests
[16:42] <seb128> could somebody let gnome-session migrate from proposed to release?
[16:43] <seb128> the current release version segfaults if one of the autostart services fails to start which is letting some users without a working session
[16:43] <seb128> the fix is a one liner, it would be good to get it in today rather than after a1
[16:43] <cjwatson> it should happen automatically
[16:43] <Laney> yeah, it's not blocked; see excuses
[16:44] <cjwatson> I don't particularly know why it isn't frozen (Riddell, aren't we releasing Ubuntu GNOME on Thursday?), but it isn't
[16:44] <seb128> ok, I was not sure how much is blocked with e.g Ubuntu GNOME
[16:44] <cjwatson> Riddell: which images did you take as input for the block?
[16:44] <stgraber> cjwatson: hmm, could it be that our lock file under /srv/cdimage.ubuntu.com/etc/.lock-build-image-set isn't per-architecture?
[16:44] <cjwatson> stgraber: It's not meant to be
[16:45] <cjwatson> Oh, I'm thinking of sem-
[16:45] <Laney> I thought Riddell's block was just for Kubuntu
[16:45] <cjwatson> argh
[16:45] <cjwatson> wish that had been clear!
[16:45] <cjwatson> Riddell: I thought you were acting for the release team and not just for Kubuntu
[16:45] <knome> skaet, stgraber, cjwatson: if the xubuntu installer bug is fixed, we're in for A1
[16:45] <skaet> thanks knome
[16:46] <Laney> r188 commit message confirms that
[16:46] <cjwatson> stgraber: I think it probably isn't per-architecture, no.  I didn't really expect that people would be building different arches for the same thing in parallel
[16:46] <cjwatson> Sigh.  Can somebody get a block generated and in place ASAP before there's further interaction with auto-sync?
[16:47] <cjwatson> knome: If you mean bug 1193526, it should be
[16:47] <ubot2> Launchpad bug 1193526 in ubiquity (Ubuntu) "Clicking "Install Xubuntu 13.10" in live session doesn't work." [Undecided,Fix released] https://launchpad.net/bugs/1193526
[16:47] <knome> cjwatson, i've no idea (i was just told there was some critical one), but i suppose it's that :)
[16:48] <stgraber> cjwatson: so my code isn't terribly clever in that regard. I basically pull builds from the rebuild queue, get one per architecture, build that and start again, which means that I always set ARCHES=<single arch> even if I'm building the same product for multiple arches at the same time
[16:48] <cjwatson> stgraber: Hm, that's not the expected model and it will be rather less efficient - is there any way you could aggregate instead?
[16:48] <skaet> knome,  https://launchpad.net/bugs/1193526 is the one that Lubuntu was waiting on.
[16:48] <ubot2> Ubuntu bug 1193526 in ubiquity (Ubuntu) "Clicking "Install Xubuntu 13.10" in live session doesn't work." [Undecided,Fix released]
[16:49] <cjwatson> stgraber: That also means all the different architectures get different build IDs but the later ones will copy the earlier ones over - in fact, since they're published to the same directory, that's why lock-build-image-set *can't* be per-architecture
[16:49] <cjwatson> stgraber: I think you need to fix this, sorry :)
[16:49] <knome> skaet, ok :) that sounds "correct"
[16:49] <jbicha> ubuntu-gnome doesn't have its own packageset yet if that's what you're using to figure out the blocks
[16:49] <cjwatson> jbicha: the procedure was to grab .manifest and .list, collect binary packages, map to source packages
[16:50] <cjwatson> so based on images not packagesets
[16:50] <stgraber> cjwatson: hmm, yeah, ok, I'll have that be per-project then, will be less efficient from a buildd usage point of view though
[16:51] <cjwatson> You don't need to go as coarse-grained as that - it can be per-project/series/image-type combination
[16:51] <cjwatson> Which often winds up distributing fairly well since ARM often has different image-types
[17:01] <cjwatson> $ bzr ci -m 'Make ubuntu/saucy/daily-live and ubuntu-server/saucy/daily current symlinks trigger-controlled on amd64 and i386.'
[17:01] <cjwatson> plars: ^-
[17:01] <cjwatson> Hopefully that should work as of the next run ...
[17:01] <plars> cjwatson: awesome :)
[17:02] <cjwatson> Oh, glib2.0 is blocked, that would need to be unblocked for gnome-session
[17:03] <cjwatson> stgraber: Do you think unblocking glib2.0 is OK?
[17:03] <cjwatson> with respect to builds in progress
[17:03] <cjwatson> changelog looks reasonable though I haven't checked what's in the new upstream
[17:04] <Laney> should be alright
[17:04] <stgraber> cjwatson: there's currently no build in progress, I'm changing my script
[17:04] <Laney> I wouldn't say I'm confident that my new autopkgtest will pass though :-)
[17:06] <cjwatson> Hm, it's unfortunate that autopkgtests aren't run for blocked packages
[17:06] <jbicha> I'd really like to have the new libsignon-glib for Ubuntu GNOME Alpha1; it's seeded by almost every flavor though
[17:07]  * cjwatson unblocks
[17:07] <cjwatson> (glib2.0)
[17:08] <Laney> great, that means I don't have to figure out why gtk+3.0 claims to be blocked on glib2.0
[17:08] <cjwatson> Presumably bumped shlibs?
[17:09] <Laney> it's symbols and the deps don't seem to be versioned
[17:09] <Laney> obviously missing something
[17:11] <knome> skaet, FYI, elfy/hobgoblin is now the xubuntu QA lead and also part of the xubuntu release team, so feel free to turn to him if i'm not around
[17:11] <knome> ^ same goes for all release team, but i think most of you know that already
[17:12] <stgraber> running: http://paste.ubuntu.com/5799101/
[17:14] <stgraber> cjwatson: so my code is very very stupid at the moment, it groups by project+build-type, builds the first, the goes to the next. I'll need to teach it about being able to run non-live builds in parallel and find cases where we have no arch overlap between two sets and so can be parallelized (I could also just start everything and not care, leaving the locks deal with the mess)
[17:16] <cjwatson> You can start live builds in parallel too, if you like - they'll just block
[17:17] <cjwatson> I think I've made proposed-migration start autopkgtests even for blocked packages now ...
[17:25] <skaet> stgraber,  re your paste,   I thought Edubuntu wasn't participating.   Has this changed?
[17:26] <stgraber> skaet: no, still not participating. Doesn't prevent us from triggering rebuilds through the tracker
[17:27] <cjwatson> kde-workspace seems to have a real build failure on armhf
[17:27] <cjwatson> (double vs. qreal, at a very brief glance?)
[17:28] <stgraber> cjwatson: I think I'll update my code to go with the "just start everything in parallel and wait for things to settle", that's the most efficient thing I can do without having to add a ton of logic.
[17:28] <cjwatson> Good, autopkgtests for packages that are only ineligible due to blocks seem to be working now
[17:28] <cjwatson> stgraber: I think that was what I expected you to do :)
[17:29]  * Laney just got an ENOSPC from jenkins when converting the image
[17:30] <slangasek> "converting the image"?
[17:30] <Laney> well, whatever it's doing when it says qemu-img: /dev/shm/adt/saucy-amd64-glib2.0-20130625_172110.nMTaJv.img: error while creating qcow2: No space left on device
[17:30] <slangasek> is it Laney's fault that I'm receiving adt failure mails with ENOSPC?
[17:30] <Laney> That can't be my fault :P
[17:31] <cjwatson> Glad somebody's receiving them
[17:31] <skaet> stgraber, ack.
[17:31] <cjwatson> Hmm.  I wonder if failed autopkgtests are not being remembered properly
[17:32] <cjwatson> 16:08:48.log:I: [Tue Jun 25 16:13:44 2013] - Requested autopkgtest for software-properties_0.92.21
[17:32] <cjwatson> 16:08:48.log:I: [Tue Jun 25 16:14:07 2013] - Collected autopkgtest status for software-properties_0.92.21: RUNNING
[17:32] <cjwatson> 17:09:16.log:I: [Tue Jun 25 17:12:53 2013] - Collected autopkgtest status for software-properties_0.92.21: FAIL
[17:32] <cjwatson> But now no mention of it
[17:35] <slangasek> jibel, retoaded: ^^ what's going on with space on jenkins?
[17:35] <slangasek> e.g., https://jenkins.qa.ubuntu.com/job/saucy-adt-pango1.0/29/ARCH=amd64,label=adt/console
[17:35]  * Laney has generated a massive block
[17:35] <cjwatson> jibel: Am I meant to store pass/fail results retrieved from adt-britney collect and map them onto the requesting package myself?
[17:36] <Laney> http://paste.ubuntu.com/5799165/
[17:36] <cjwatson> I think I must be.  I do have all the state ...
[17:37] <cjwatson> Laney: No way I'm reviewing that :)
[17:37] <cjwatson> Do sort it though, please
[17:37] <Laney> ok
[17:37] <Laney> That's ubuntu-gnome lubuntu xubuntu. Did I miss any?
[17:37] <Laney> kylin?
[17:42] <skaet> kylin is participating
[17:42] <Laney> ok, here goes
[17:49] <retoaded> slangasek, it's not an issue with space on jenkins but in the shared memory on albali (where the job is being run).
[17:58] <slangasek> retoaded: hmm, alright.  So is this being worked on, and can we expect these jobs to start running normally again soon?
[18:00] <retoaded> slangasek, there is a build currently running on the jenkins node albali that is consuming a large portion of the memory. It started an hour and 40 minutes ago with no estimated time of completion.
[18:01] <retoaded> When it completes the memory should be freed up.
[18:01] <slangasek> hmm
[18:01] <slangasek> will the adt jobs be retried automatically?
[18:02] <retoaded> that would be more of a jibel question.
[18:03] <retoaded> fwiw, i plan on heading over to 1SS later this afternoon and it might help this situation of I shut down albali and add more memory (it's on my list of to do's anyway)
[18:07] <jibel> cjwatson, no, collect is supposed to do that
[18:08] <jibel> slangasek, retoaded I'll take care of albali, jobs will be retried.
[18:09] <slangasek> jibel: ok, thanks
[18:09] <slangasek> jibel: is this a problem that we have to worry about recurring in the future?
[18:09] <retoaded> jibel, do you want me to add another 32GB RAM to albali when I head over later today?
[18:09] <cjwatson> jibel: I think what I mean is, is collect supposed to keep them around?  At the moment it seems to archive them once it considers the job done, but proposed-migration is going to keep trying as long as the triggering package is a candidate
[18:11] <jibel> slangasek, no it's because I increased disk size of the VMs for libreoffice to the limit of what can be supported, I'll reduce it to again and do something specific for LO
[18:11] <slangasek> ok
[18:55] <rtg_> can the Nexus kernels be promoted ? I don't think they'll have an impact on any alpha milestones. linux-{grouper,maguro,mako,manta}
[18:55] <infinity> rtg_: They don't have any blocks, AFAIK, they should auto-promote fine once they're all build and such.
[18:55] <infinity> s/build/built/
[18:55] <rtg_> infinity, k
[19:22] <jbicha> can libsignon-glib be unblocked?
[19:26] <stgraber> cjwatson: just landed an update to the self-rebuild code, we now have different status codes for: requested, queued, building, built, published and canceled (instead of just requested, building, published and canceled)
[19:27] <stgraber> cjwatson: so the plan is for my script to run every couple of minutes, take anything in requested state moved them to queued and spawn the rebuild commands, then have the build code move it to building when it actually starts, built when its done building and the tracker will move to published once post-qa is done for the whole set.
[19:28] <stgraber> that should give us proper per-product state and timing instead of the current rather vague "it's building" status which may take several hours depending on what else is going on on nusakan
[19:29]  * stgraber gets back to adding the required code for the building and built status handling
[21:31] <stgraber> to anyone who'll be getting the failure e-mail, yes I broke nusakan, fix in progress
[21:31] <Laney> ^_^
[21:36]  * Laney force-autopkgtests glib
[21:36] <stgraber> looks like I fixed it or at least changed it in a way that takes longer to fail
[21:36] <Laney> I'll finish packaging the proper test runner and upload that again some point soon
[21:43] <infinity> stgraber: "... or at least changed it in a way that takes longer to fail"
[21:44] <infinity> stgraber: Reminds me of every time I cheered while porting glibc 2.16/2.17 to freebsd and I thought I'd won.
[21:44] <cjwatson> I see uninstallables are down to a happier level.
[21:45] <infinity> cjwatson: I'm assuming making kde4libs build on armhf helped that a little.
[21:47] <cjwatson> It took a stack above that too, but yes
[21:49] <xnox> cjwatson: britney now handling removals as well? "Removing packages left in testing for smooth updates (2):"
[21:50] <cjwatson> xnox: It thinks it does, but they don't actually get removed
[21:50] <cjwatson> Not worth disabling the analysis step :)
[21:51] <xnox> Ah... joy =)
[23:58]  * cjwatson makes http://people.canonical.com/~ubuntu-archive/proposed-migration/log/ exist, for possibly easier debugging in some cases
[23:59] <stgraber> cdimage people: I have now added the self-builds to cron, every 5min nusakan will look for new build requests and process them. If you see something going wrong, please disable from cron and ping me about it.
[23:59] <cjwatson> (I don't recommend you stare at it unless you're debugging britney itself, or maybe hints or auto-package-testing - for ordinary package handling the update_excuses and update_output files should be enough
[23:59] <cjwatson> stgraber: *shiver* :)
[23:59] <cjwatson> )


[03:09] <ourtv> where do you change the playback jump mount?
[03:14] <ourtv> found it.
[03:53] <Egghead> does anyone know if they are getting rid of the gui diskless image setup part in mmc, in karmic?
[04:00] <tgm4883> Egghead, i don't know, why?
[04:01] <Egghead> i just installed karmic with repos installed, and the mcc doesnt have the setup area for diskless anymore
[04:02] <Egghead> the part where u can run mcc to config the diskless image
[04:02] <tgm4883> Egghead, I pinged the author of that feature, but he is in germany and is likely asleep by now
[04:02] <Egghead> just wondering if thats been 86'd
[04:03] <Egghead> cool thanks for trying :)
[04:04] <Egghead> btw karmic installed nicley
[04:04] <tgm4883> Egghead, that is great to hear
[04:05] <Egghead> glad to see that the network setup allowd me to config for manual w/o any probs :)
[04:05] <Egghead> every other time i had to manually edit stuff like resolv.conf ect to get static addys working
[04:06] <Egghead> also it seems alot faster, i mean really noticable faster
[04:08] <Egghead> awsome job
[04:18] <dserban> Issues with media keys, can anyone help?  (other than google)?
[04:19] <dserban> It involves two usb keyboards, media keys and other fun stuff such as xmodmap.
[17:53] <teprrr> hi there.. are crashes when scanning for channels in mythtv-setup expected/known problem? running clean mythbuntu 9.04 here
[17:54] <teprrr> segfaults when trying to do a full scan based on given information and gives '"pure virtual method called" "terminate called without an active exception"' and aborted when trying to import channels.conf
[17:55] <superm1> teprrr, multicore processor?
[17:57] <teprrr> superm1, yeah. just noticed a post in some ml saying that it works better on non-smp machines..
[17:57] <superm1> teprrr, well there is a way to set the affinity of a single process
[17:58] <superm1> i thought it was like taskset -c 0
[17:58] <superm1> and actually the mythtv-setup script already does that
[17:58] <teprrr> oh.. okay.. I run mythtv-setup.real here :)
[17:59] <superm1> don't
[17:59] <superm1> there's a reason we have a wrapper script :)
[17:59] <teprrr> yeah, apparently cli params work just fine with the wrapper too :)
[18:00] <teprrr> (I'm trying to configure my system over x forwarding here :)
[18:00] <superm1> it would actually be a lot faster if you spawned a vnc server (with start4vnc or startvnc4, forget the command) and then run mythtv-setup in that
[18:00] <teprrr> yay, works fine now. thanks :)
[18:01] <superm1> it's not as bandwidth heavy, and in case the connection is severed, things still run
[18:01] <superm1> i've found it far more useful for doing channel scans from a laptop over wifi that would normally take /ages/
[18:01] <teprrr> hmm, well, I'd prefer nx perhaps, but X forwarding seems to work just fine inside lan
[18:01] <teprrr> though my htpc is connected over wlan to it
[18:07] <teprrr> btw, does mythtv nowadays support limiting of live recordings? ie. if you left a channel on it'll start to remove it later? or does that depend still on changes in programs?
[18:08] <teprrr> I busted my old installation with leaving a channel on and it filled the whole drive then :P
[18:10] <tgm4883> teprrr, sounds like you need to add the live tv timeout
[18:16] <teprrr> tgm4883, okay. will look into that
[18:36] <kristofer> Hello. During a recent update in mythbuntu xine, vlc and mplayer stopped working when playing DVDs. Xine says unknown buffer type and dies.
[18:36] <kristofer> Does anyone know what this might be?
[19:12] <teprrr> http://pastebin.ca/1562351 hmm, any ideas why mythfrontend frm my other machine fails to watch live from that other backend?
[19:13] <superm1> make sure the timezones are set correctly on both boxes
[19:13] <superm1> and check the log of the other box for what it's screaming
[19:19] <teprrr> hmm, at least date on console displays the correct times
[19:19] <teprrr> and watching it doesn't work directly from the backend box either..
[19:20] <teprrr> ahh, permission problem. changed the recording dir to somewhere else which wasn't owned by user mythtv..
[19:21] <teprrr> now it works, great :)
[23:21] <jordanwb> Does anyone know if the Twinhan AD-SE200 works with MythTV?
[23:31] <jordanwb> is anyone here?


[23:13] <lousygarua> philipballew, Hi, I've sent the postcard last week
[23:13] <philipballew> lousygarua, thats really cool. I will look for it soon. So whats the issue with the bots in this channel?
[23:45] <lousygarua> philipballew, the bots that asks you to stay in the channel and wait for an answer? something that avihay is developing for users
[23:49] <avihay> I noticed I've ruined the message module, by accidently pasting the firstgreet module on it (x_X)
[23:50] <avihay> and it's not in the first commit to the repository
[23:50] <philipballew> lousygarua, oh, thats cool.
[23:50] <philipballew> lousygarua, thank you for sending the card


[01:31] <philipballew> setting up a vpn is annoying
[17:13] <pleia2> aww, I slept through the earthquake
[18:26] <MarkDroid> mobile. O ly using wifi
[18:26] <DonkeyHotei> ok


[12:54] <intercept|X> hello guys hows ur day?
[12:54] <intercept|X> is this channel still active?
[14:35] <intercept|X> oh < > < >


[12:10] <ejat> openstack-dashboard timeout when i tried to login
[12:10] <ejat> what should i do ?
[13:05] <mup> Bug #1468726 changed: Retain page position on refresh <ui> <MAAS:Won't Fix> <https://launchpad.net/bugs/1468726>
[14:21] <kiko> good morning
[17:51] <mup> Bug #1497392 opened: maas text-mode "node-group-interface" bug fails with MAAS 1.8.2+bzr4041-0ubuntu1~trusty1 <MAAS:New> <https://launchpad.net/bugs/1497392>
[18:00] <mup> Bug #1497392 changed: maas text-mode "node-group-interface" bug fails with MAAS 1.8.2+bzr4041-0ubuntu1~trusty1 <MAAS:New> <https://launchpad.net/bugs/1497392>
[18:03] <mup> Bug #1497392 opened: maas text-mode "node-group-interface" bug fails with MAAS 1.8.2+bzr4041-0ubuntu1~trusty1 <MAAS:New> <https://launchpad.net/bugs/1497392>
[19:15] <nodtkn> Howdy.  The ubuntu vivid root-tgz files are missing the python-yaml package that is required for me to juju add a newly installed node.  Does anyone know of documentation for modifying the root image.  Ideally I would like to mount it, add the python-yaml package, unmount it, and load it as a custom image in MAAS.
[19:20] <mgz> nodtkn: can't you just add python-yaml in your cloud-config in your dependencies? using non-stock root images is generally a bad idea.
[19:21] <mgz> also, juju doesn't depend on python-yaml.
[19:28] <nodtkn> mgz: I have modified my preseed files to install python-yaml, but that adds to my installation time.  I am always installing a few things like build-essentials so I would rather do it in a custom image.
[19:30] <nodtkn> mgz:  Are you sure about python-yaml not being required.  I was getting errors when I attempted to add vivid nodes and preinstalling python-yaml removed those erros.
[19:30] <nodtkn> mgz:  It might have been that bootstrap was failing instead of add-machine.
[19:43] <ennoble> Is there a way to have maas install on a specific type of media (e.g. hd vs. ssd  vs. nvme)?
[19:46] <nodtkn> mgz:  My mistake it was a failure at juju deploy so I would have to log in to the host and run apt-get install python-yaml before I could deploy a service that used charmhelpers.
[19:49] <mgz> nodtkn: yeah, you just want to fix the charm install hook it sounds like
[19:55] <nodtkn> mgz: That would be nice, but I generally I think the ability to create a custom ubuntu image would be awesome.   I could modify it to run the latest kernel, update all of the packages (instead having to call apt-get upgrade), and install all of the common packages that are needed by my charms.
[20:10] <roaksoax> /w/win 7
[21:26] <kiko> nodtkn, yep, we agree -- this is something we've been thinking about how to automate and make easier
[21:30] <nodtkn> kiko: I tried out the maas-image-builder I was thinking if it worked for centos I would attempt to modify it to work with ubuntu.
[22:04] <ennoble> is there a way to control what media maas provisions the machines with when multiple storage types are connected?


[14:30] <aisrael> is bac around today?
[14:33] <aisrael> or anyone else that can take a look at ingestion into the charm store?
[14:36] <aisrael> nm
[14:39] <rick_h_> aisrael: everything ok?
[14:40] <rick_h_> aisrael: just ping jujugui or such and everyone will get a big ping :)
[14:40] <rick_h_> aisrael: but no, bac is out today. Other folks canhelp though
[14:40] <aisrael> rick_h_: Yeah. I thought I had an ingestion problem, but realized the repo I was waiting to show up was empty. My bad.
[14:40] <aisrael> rick_h_: good to know, though. Hopefully I never need to pull the fire alarm :)
[14:41] <rick_h_> aisrael: all good, and if you need anything feel free to pull alarms/ping
[14:41] <rick_h_> aisrael: :( now that you've got a big wait in front of you.
[14:43] <aisrael> rick_h_: Does it still run every 20 minutes or so?
[14:56] <rick_h_> aisrael: it runs every 15min but it takes about 2 full hours to get through everything on both old and new systems
[14:56] <aisrael> rick_h_: awesome, thanks!
[14:57] <rick_h_> aisrael: that was the 'long wait' I meant you had before it was all there/usable from the new store
[14:57] <aisrael> rick_h_: gotcha. I lucked out; I'm up and playing with fire now.
[14:58] <rick_h_> aisrael: woot