[05:40] <Unit193> pitti: Howdy.
[05:40] <pitti> Good morning
[05:40] <pitti> hey Unit193
[05:41] <pitti> cjwatson: oh, thank you!
[05:41] <pitti> doko_: ah, sorry; corresponding postgresql-9.4 will be uploaded today; I'll sort out python3.4 in the meantime
=== timrc is now known as timrc-afk
=== doko_ is now known as doko
=== chiluk` is now known as chiluk
=== Sweetsha1k is now known as Sweetshark
[09:17] <rbasak> doko: can you sponsor me a sync of icu please? This will fix the open-vm-tools FTBFS from the rebuild test.
[09:17] <rbasak> doko: OOI, do you have a rebuild button in your rebuild test? Or do we want a no-change rebuild of open-vm-tools anyway, to build against a newer icu?
[09:18] <rbasak> No real changes - just compiler flags regressed in Utopic and are fixed in unstable.
[09:18] <doko> rbasak, done
[09:19] <rbasak> Thanks!
[09:24] <Saviq> seb128, ideas about app updates in settings stuck at 0%?
[09:24] <Saviq> that's mako rtm
[09:24] <seb128> Saviq, yes, remove your U1 account and add it back
[09:25] <Saviq> seb128, yay
[09:25] <doko> dobey, pitti: please could you have a look at the dirspec ftbfs and autopkg test failure?  https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-dirspec/lastBuild/? and http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html
[09:25] <seb128> Saviq, they revoked the sso token earlier this week and the settings app fails at letting you know that you hit an auth error
[09:25] <Saviq> kk
[09:25] <seb128> Saviq, bug #1378678
[09:25] <ubottu> bug 1378678 in ubuntu-system-settings (Ubuntu) "updates panel doesn't deal with invalid u1 tokens" [High,New] https://launchpad.net/bugs/1378678
[09:25] <doko> jibel, pitti: weren't libreoffice autopkg tests ignored?
[09:26] <pitti> doko: they were as long as they were failing, but now they started succeeding; already retried
[09:26] <pitti> one of these days I have to get behind that weird "tar: unexpected EOF" thing, it's utterly hard to reproduce locally
[09:26] <doko> pitti, and s3ql and skimage too
[09:26] <Saviq> seb128, yup, helped, thanks
[09:27] <pitti> doko: yep, already queued (there's some lag, tons of tests are running ATM)
[09:27] <seb128> Saviq, yw!
[09:27] <pitti> doko: dirspec> yes, looks like simple pep-8 issues, queueing
[09:27] <doko> pitti, yep, but ftbfs too
[09:27] <pitti> doko: right,  I meant "queueing for today's work"
[09:28] <pitti> doko: I'm watching python3-defaults excuses, btw
[09:28] <doko> looking ...
[09:28] <pitti> doko: oh, I thought that's what you were concerned about
[09:29] <doko> ahh yes, I am
[09:55] <Saviq> ricmm, hey, so, do we need to do anything to benefit from QML compilation?
[09:57] <ricmm> no
[09:59] <Saviq> ricmm, so it compiles it on first use and cache, or?
[09:59] <ricmm> Saviq: yea, first use it compiles and caches
[10:00] <Saviq> coolz
[10:00] <ricmm> further uses use the cache unless it needs to recompile something
[10:12] <xnox> jdstrand: slangasek: in /etc/pam.d/sudo shouldn't the pam_env.so lines be "session" rather than "auth"?
[10:12] <xnox> cause at the moment it looks like variables set in /etc/environment as not present under $ sudo -i
[10:14] <xnox> yet it was suppose to be working per these bugs
[10:14] <xnox> bug #25700
[10:14] <ubottu> bug 25700 in sudo (Ubuntu) "sudo does not read /etc/environment on interactive logins (directly, not through pam_env)" [Medium,Fix released] https://launchpad.net/bugs/25700
[10:15] <xnox> bug #982684
[10:15] <ubottu> bug 982684 in sudo (Ubuntu Quantal) "sudo, pkexec don't apply global environment settings from /etc/environment" [Medium,Fix released] https://launchpad.net/bugs/982684
[10:15] <xnox> bug #1301557
[10:15] <ubottu> bug 1301557 in sudo (Ubuntu) "sudo not setting environment variables in /etc/environment" [Undecided,Confirmed] https://launchpad.net/bugs/1301557
=== MacSlow is now known as MacSlow|lunch
[11:25] <pitti> jamespage: just making sure: you got the swift regression notification mail?
[11:26] <Laney> pitti: He uploaded ubuntu3 to fix the test
[11:40] <jamespage> pitti, I did indeed - resolved now
[11:49] <doko> jamespage, I see you looked into https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695296 in the past. the package ftbfs with the current tests. do you want to take a look?
[11:49] <ubottu> Debian bug 695296 in libunwind "libunwind: Add test suite execution on amd64" [Normal,Open]
[11:52] <jamespage> doko, no capacity right now - there is a trick to it tho - there's a readme in debian
[11:53] <doko> jamespage, ugh, how do you suggest to do that for the Debian buildds?
[11:53] <jamespage> doko, well most buildds don't have apport enabled right?
[11:54] <doko> no
=== _salem is now known as salem_
[12:18] <pitti> jamespage: ah, thanks
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
[12:49] <jamespage> doko, sorted?
[12:50] <doko> jamespage, libunwind?
[12:50] <jamespage> yeah
[12:50] <doko> no
[12:50] <jamespage> oh
[12:50] <doko> nmu'ed to Debian; ignoring test results. not a regression, because the testsuite wasn't run before
[12:51] <doko> I think I'll updat tp the trunk for the v-series
[12:51] <pitti> doko, dobey: fixed dirspec uploaded (waiting for RT review), and forwarded upstream: https://code.launchpad.net/~pitti/dirspec/pep8/+merge/237776
[12:53] <doko> pitti, thanks!
[13:04] <doko> barry, could you have a look at the flask ftbfs in http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140912-trusty.html ?
[13:10] <barry> doko: yep
[13:10] <pitti> mvo, cjwatson: hmm, my chroot with click installed now produces failures like http://paste.ubuntu.com/8526692/ -- does that ring a bell?
[13:12] <pitti> mvo, cjwatson: oh sorry, I figure this is a false alarm; /etc/schroot/default/nssdatabases copies passwd, and I don't have the user locally
=== MacSlow|lunch is now known as MacSlow
[13:44] <arges> hallyn: good morning
[13:56] <arges> debfx: looking at your bug 1379346
[13:56] <ubottu> bug 1379346 in libvirt (Ubuntu) "Error creating a VM: internal error: No PCI buses available" [Critical,In progress] https://launchpad.net/bugs/1379346
[13:57] <hallyn> arges: yo
[13:58] <arges> hallyn: hitting the above bug ^^ didn't know if you were already looking into it, but looks like debfx already has a patch, so I'm working on it now
[13:59] <hallyn> arges: nope hadn't seen that
[14:00] <arges> hallyn: yup, testing the patch now.
[14:00] <hallyn> arges: huh.  i swear i used to have tha tpatch
[14:00] <hallyn> arges: could you please add the trusyt and utopic machine types too?
[14:01] <hallyn> then +1 from me. thanks debfx !
[14:01] <arges> hallyn: so the prefix needs to be ubuntu || trusty || utopic   for utopic?
[14:03] <arges> hallyn: ' qemu-system-x86_64 -machine ? ' only shows me ubuntu prefixes plus pc-* where trusty/utopic are postfixes
[14:04] <hallyn> arges: no, || pc-i440fx-trusty || pc-i440fx-utopic
[14:04] <hallyn> (sorry i hate those mt names :)
[14:04] <arges> ah since its STREQ
[14:04] <arges> hallyn: ok i'll add those
[14:04] <hallyn> thx
[14:05] <arges> hallyn: actually there is a condition that says 'STRPREFIX(def->os.machine, "pc-i440")' so I would assume that would catch pc-i440fx-trusty right?
[14:05] <hallyn> jdstrand: sarnold: rharper: just a check, have you had any luck in either reproducing or bisecting the qemu corruption issue?
[14:05] <hallyn> arges: d'oh
[14:05] <hallyn> yes
[14:06] <hallyn> so th eoriginal patch is good
[14:06] <arges> its ok : ) i'll test the patch anyway
[14:06] <rharper> hallyn: I've not tried in a while now
[14:06] <hallyn> rharper: ok.  i've not seen it in awhile, though i have to work a vm pretty long+hard to get corruption
=== mpt_ is now known as mpt
[14:11] <kenvandine> doko, i think that arm64 build of gdb is hung
[14:12] <doko> kenvandine, I'm tracking it
[14:12] <kenvandine> doko, thx
[14:12] <cjwatson> kenvandine: waiting for infinity to wake up
[14:17] <jdstrand> hallyn (and sarnold and rharper): I have reproduced so much that I had to downgrade again. I don't have a simple reproducer though so I wasn't able to bisect
[14:17] <jdstrand> ie, it just happens sometimes
[14:18] <jdstrand> I went a whole weekend in a script and it was fine. then, I went to work on Monday and lost VMs
[14:23] <arges> hallyn: ok works for me, i'm going to have sforshee confirm and then i'll upload it
[14:23] <hallyn> arges: thanks
[14:24] <hallyn> jdstrand: ok, now that i have working serverstack maybe i can try reproducing there next week.  (couldn't keep sacrificing my server)
[14:26] <sforshee> arges, hallyn: that fixes the problem for me too
[14:26] <arges> cool
[14:27] <sforshee> arges: thanks a bunch
[14:54] <slangasek> xnox: /etc/pam.d/sudo> I don't know off hand, but I do know that my $LANG is being set from /etc/default/locale when I run either sudo -s or sudo -i on utopic
[14:55] <slangasek> xnox: hmm nope, testing shows the setting is coming from somewhere else
[14:55] <slangasek> inherited from the caller in fact
[14:55] <dpm> cjwatson, slangasek, do you know if it's possible to mirror a PPA? Some app developers in China tell us that it's very slow for them to download the SDK from the SDK team's PPA
[14:56] <cjwatson> dpm: it's just an apt archive, debmirror can do it
[14:57] <cjwatson> (or at least I assume it can, it would be very surprising if not ...)
[14:57] <dpm> ok, thanks cjwatson
[14:59] <doko> kenvandine, done
[14:59] <kenvandine> doko, thanks!
=== oSoMoN_ is now known as oSoMoN
[15:33] <smoser> geser, slangasek i posted some more info to bug 1377005.
[15:33] <ubottu> bug 1377005 in cloud-init "Breaks machine without IPv4: "Route info failed"" [Undecided,New] https://launchpad.net/bugs/1377005
[15:33] <smoser> i cannot figure out what is removing addresses. something is doing it, and without the 'ip' command.
[15:36] <slangasek> smoser: btw, why did this bug not get marked as a duplicate of the other known bug?
[15:36] <smoser> no good reason.
[15:36] <smoser> well, jtv said he didn't think it was. (but i disagree)
[15:37] <smoser> and also cloud-init *does* put that annoying comment in the console about route info
[15:37] <smoser> so that should be fixed anyway for cloud-init.
[15:37] <smoser> if you want to dupe it yo ucan
[15:45] <smoser> what could possibly be removing that address?
=== timrc-afk is now known as timrc
[15:57] <pitti> smoser, cloud folks: is there any hope to re-fix nova boot --file (bug 1376176)? it makes it really hard to inject a script into instance creation, especially as precise's cloud-init doesn't yet support write_files:
[15:58] <ubottu> bug 1376176 in python-novaclient (Ubuntu) "regression: nova boot --file does not work" [Undecided,New] https://launchpad.net/bugs/1376176
[15:59] <smoser> pitti, i suspect that your cloud has just disabled that as injection.
[15:59] <smoser> so theres 2 ways that happens on the backend.
[15:59] <pitti> smoser: it's canonical bootstack
[15:59] <pitti> ah, perhaps
[15:59] <smoser> a.) the nova compute (through libguestfs) would insert it itself.
[15:59] <pitti> so write_files in userdata doesn't work either :(
[16:00] <smoser> b.) the files are presented through config-drive, and cloud-init would have to handle them.
[16:00] <slangasek> smoser: removing that address> at this point I have no guesses.  But it has to be either something triggered via ifupdown, or the kernel itself
[16:00] <smoser> can you let me into an instance real quick ?
[16:00] <pitti> ok, I guess I'll stop using cloud-init then, but instead wait for ssh and remote-execute the script through that :)
[16:00] <smoser> slangasek, yeah, i think kernel. but that just seems absurd.
[16:00] <smoser> so i didn't say it out loud
[16:00] <pitti> smoser: ah, so it might not be a regression in nova, but a proprerty of bootstack
[16:01] <pitti> smoser: it worked with HP cloud, but I lost access to that, so I can't compare
[16:01] <pitti> smoser: thanks
[16:01] <slangasek> smoser: ipv6 addressing is very magic in the kernel and I would not rule it out :)
[16:01] <smoser> pitti, can you launch one and let me in? i can see if its fixable. it probably *is* a property of openstack. and a *fix* in my mind.
[16:01] <pitti> smoser: 172.19.0.77 if you want to play around with that
[16:02] <pitti> smoser: (bog standard utopic i386 image)
[16:02] <pitti> smoser: but anyway, I figure running the script through ssh might be quite a bit more robust anyway
[16:02]  * pitti needs to leave for today, but thanks for the heads-up!
[16:04] <smoser> pitti, permission denied ?
=== _salem is now known as salem_
[16:25] <smoser> slangasek, fix found
[16:25] <smoser>  rm -f "$MOUNTPOINT/etc/sysctl.d/10-ipv6-privacy.conf"
[16:26] <smoser> fun bug.
[16:30] <rbasak> doko: fyi, I'm deep into the python-greenlet armhf FTBFS right now. I can work around it fine but am doing some more analysis toward sending a fix upstream.
=== robbiew is now known as robbiew-afk
=== salem_ is now known as _salem
[16:47] <doko> stgraber, please have a look at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html  libparse-debianchangelog-perl
[16:49] <doko> jpds, mdeslaur: please could you have a look at the strongswan ftbfs, and if updating from debian would help?
[16:52]  * mdeslaur looks
[16:57] <mdeslaur> jpds: any ideas?
[16:59] <mitya57> ScottK: too late to merge new Sphinx (which apparently can also break some stuff), and that's the only thing why I needed -issuetracker.
[17:05] <stgraber> doko: I doubt I'll have much time before release week in Washington, on vacation, conference and sprinting until then
[17:06] <doko> bah
[17:06] <stgraber> also, I don't know that package, I'm probably an accidental TIL on it :)
[17:06] <doko> looking at the merge then ...
[17:07] <stgraber> thanks
[17:07] <stgraber> I may have some time for packaging work on Sunday during my train ride to Düsseldorf but that's going to very much depend on how good a cell signal I get and what kind of roaming deal I can get :)
[17:11] <doko> stgraber, you could have spent the time arguing here instead by saying that it can be synced ;-P
[17:12] <stgraber> oh, it can? :) as I said, I don't know that package and my cell phone isn't particularly great to look things up
[17:15] <bdmurray> cjwatson, infinity, slangasek: Here are the search results for /etc/os-release. http://paste.ubuntu.com/8527959/
[17:18] <infinity> bdmurray: checkbox's usage might be interesting to look more closely at.
[17:19] <infinity> Definitely a longer list than I expected.
[17:21] <slangasek> how many of these packages are in ubuntu-rtm?
[17:21] <slangasek> (ubuntu-rtm is still a subset, right?)
[17:21] <slangasek> checkbox isn't in rtm
[17:22] <infinity> Ahh, fair point.  At least for now.
=== roadmr is now known as roadmr_afk
[17:28] <slangasek> bdmurray, infinity: complete list of the named packages that are actually in rtm: http://paste.ubuntu.com/8528017/
[17:28] <slangasek> base-files is obvious; apport is the reason we're proposing the change; the others bear a closer look to be sure
[17:30] <slangasek> augeas just references it in terms of a configuration file, doesn't care about the contents
[17:32] <bdmurray> gnome-control-center uses it to display the name
[17:33]  * slangasek nods
[17:35] <slangasek> qtcreator uses NAME and VERSION_ID to compose a platform name for the platform in its PluginManager API; that may need further checking
[17:44] <slangasek> bdmurray: qtcreator looks clean; none of the plugins in rtm care about the platformName (which is good, they shouldn't)
[17:46] <slangasek> kde-runtime only uses it for drkonqi, which never runs in a phone context
[17:46] <slangasek> (and it's probably informational as well)
[17:46] <bdmurray> slangasek: plymouth doesn't seem relevant does it?
[17:47] <slangasek> util-linux supports pulling variables from here into agetty configs, so that's not relevant
[17:47] <slangasek> bdmurray: looking
[17:49] <slangasek> bdmurray: yeah, plymouth is display-only
[17:57] <slangasek> bdmurray: systemd is clean
[17:58] <bdmurray> slangasek: okay, I'm not clear on how packagekit uses it
[18:01] <slangasek> bdmurray: packagekit is possibly a concern, pk_get_distro_id() returns it in its api and it's also in pk_engine_daemon_get_property DistroId
[18:01] <slangasek> cjwatson, mvo: ^^ do you know if our packagekit use on the phone will be unhappy if distro_id changes?
[18:14] <sarnold> hallyn: sorry, I never had any luck finding a reliable-enough reproducer in the time I've put into it..
[18:15] <mvo> slangasek: I don't I would have to investigate (tomorrow)
[18:15] <mvo> slangasek: I doubt it (there is config file for backend selection), but cjwatson may know more
[18:18] <hallyn> sarnold: yeah, grumble, ditto.  i guess if nothing else works i'll jus thave to buy a second colo to run the tests on, bc we have GOT to figure this out
=== roadmr_afk is now known as roadmr
[18:54] <infinity> slangasek: Err, isn't distro_id just the ID field from os-release?
[18:54] <infinity> slangasek: Or no?
[18:54]  * infinity goes to look at the source.
[18:56] <infinity> Ahh, poorly named function, it definitely wants ID and VERSION_ID.
[19:39]  * DistroFeud Ywans
[19:39] <DistroFeud> a friend of mine tells me ubuntu dev work is mostly done by upstream debian packagers
[20:03] <cjwatson> slangasek: looks like that's only used by the service pack stuff, which we don't care about
[20:03] <cjwatson> (packagekit)
[20:04] <slangasek> cjwatson: within packagekit, yes, but it was also in the api so I wasn't sure
[20:04] <slangasek> bdmurray: ^^ anyway, looks like we can conclude os-release is safe to change
[20:08] <bdmurray> slangasek: okay, the general ubuntu hook in apport uses lsb_release -sc but that's just for adding a tag so meh
[20:09] <geser> smoser, slangasek: your last analysis helped in finding the source of your ipv6-only network problem: bug #994931
[20:09] <ubottu> bug 994931 in linux (Ubuntu Utopic) "Altering use_tempaddr drops all IPv6 addresses" [Medium,In progress] https://launchpad.net/bugs/994931
[20:12] <smoser> geser, yeah, odd though. i really thought i understood it.
[20:12] <smoser> but then i thought that adading this would fix it:
[20:12] <smoser> pre-up f=/etc/sysctl.d/10-ipv6-privacy.conf ; [ ! -f "$f" ] || sysctl -e -p "$f"
[20:12] <smoser> but it did not.
[20:14] <smoser> oh.
[20:14] <smoser> i see why.
[20:16] <smoser> no i dont
[20:16] <smoser> i thought the above would basically set it before 'ip addr add' happened, and then it wouldn't be set to a different value.
[20:30] <geser> smoser: could you add a check if the sysctl was set to the expected value in your ip wrapper?
[20:31] <smoser> well, /var/log/upstart/ shows it to have been set
[20:31] <smoser> and it doesn't fail.
[20:31] <smoser> but yeah, that would be a reason. but i can just extend it . to read the values. too (hat 'pre-up' )
[20:37] <smoser> geser, well, it reads them back at the settings it wrote. (ie, it sure thinks it sets them to '2' in pre-up).
[20:38] <geser> hmm
[20:38] <smoser> i suspect net.ipv6.conf.eth0.autoconf=0 now. as ifup does that based on autoconf setting.
[20:38] <smoser> trying that now.
[20:39] <smoser> nop. i dont knwo . something fishy there.
[20:40] <geser> and without the ipv6-privacy.conf file it works?
[20:40] <smoser> yeah. i know. i dont trust me either :)
[20:47] <smoser> it definitely works. just doing a mv of that file to .disabled.
[21:05] <geser> hmm, this sounds like even with the pre-up command the sysctl value gets set at the wrong time but I can't imagine why
[23:50]  * DistroFeud YWANS
=== kitterma is now known as ScottK