Unit193 | pitti: Howdy. | 05:40 |
---|---|---|
pitti | Good morning | 05:40 |
pitti | hey Unit193 | 05:40 |
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 | 05:41 |
=== 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 | ||
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:17 |
rbasak | No real changes - just compiler flags regressed in Utopic and are fixed in unstable. | 09:18 |
doko | rbasak, done | 09:18 |
rbasak | Thanks! | 09:19 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
doko | ahh yes, I am | 09:29 |
Saviq | ricmm, hey, so, do we need to do anything to benefit from QML compilation? | 09:55 |
ricmm | no | 09:57 |
Saviq | ricmm, so it compiles it on first use and cache, or? | 09:59 |
ricmm | Saviq: yea, first use it compiles and caches | 09:59 |
Saviq | coolz | 10:00 |
ricmm | further uses use the cache unless it needs to recompile something | 10:00 |
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:12 |
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:14 |
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 | 10:15 |
=== MacSlow is now known as MacSlow|lunch | ||
pitti | jamespage: just making sure: you got the swift regression notification mail? | 11:25 |
Laney | pitti: He uploaded ubuntu3 to fix the test | 11:26 |
jamespage | pitti, I did indeed - resolved now | 11:40 |
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:49 |
jamespage | doko, no capacity right now - there is a trick to it tho - there's a readme in debian | 11:52 |
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:53 |
doko | no | 11:54 |
=== _salem is now known as salem_ | ||
pitti | jamespage: ah, thanks | 12:18 |
=== salem_ is now known as _salem | ||
=== _salem is now known as salem_ | ||
=== salem_ is now known as _salem | ||
jamespage | doko, sorted? | 12:49 |
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:50 |
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:51 |
doko | pitti, thanks! | 12:53 |
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:04 |
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:10 |
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 | 13:12 |
=== MacSlow|lunch is now known as MacSlow | ||
arges | hallyn: good morning | 13:44 |
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:56 |
hallyn | arges: yo | 13:57 |
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:58 |
hallyn | arges: nope hadn't seen that | 13:59 |
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:00 |
hallyn | then +1 from me. thanks debfx ! | 14:01 |
arges | hallyn: so the prefix needs to be ubuntu || trusty || utopic for utopic? | 14:01 |
arges | hallyn: ' qemu-system-x86_64 -machine ? ' only shows me ubuntu prefixes plus pc-* where trusty/utopic are postfixes | 14:03 |
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:04 |
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:05 |
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 | 14:06 |
=== mpt_ is now known as mpt | ||
kenvandine | doko, i think that arm64 build of gdb is hung | 14:11 |
doko | kenvandine, I'm tracking it | 14:12 |
kenvandine | doko, thx | 14:12 |
cjwatson | kenvandine: waiting for infinity to wake up | 14:12 |
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:17 |
jdstrand | I went a whole weekend in a script and it was fine. then, I went to work on Monday and lost VMs | 14:18 |
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:23 |
hallyn | jdstrand: ok, now that i have working serverstack maybe i can try reproducing there next week. (couldn't keep sacrificing my server) | 14:24 |
sforshee | arges, hallyn: that fixes the problem for me too | 14:26 |
arges | cool | 14:26 |
sforshee | arges: thanks a bunch | 14:27 |
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:54 |
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:55 |
cjwatson | dpm: it's just an apt archive, debmirror can do it | 14:56 |
cjwatson | (or at least I assume it can, it would be very surprising if not ...) | 14:57 |
dpm | ok, thanks cjwatson | 14:57 |
doko | kenvandine, done | 14:59 |
kenvandine | doko, thanks! | 14:59 |
=== oSoMoN_ is now known as oSoMoN | ||
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:33 |
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:36 |
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:37 |
smoser | what could possibly be removing that address? | 15:45 |
=== timrc-afk is now known as timrc | ||
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:57 |
ubottu | bug 1376176 in python-novaclient (Ubuntu) "regression: nova boot --file does not work" [Undecided,New] https://launchpad.net/bugs/1376176 | 15:58 |
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 :( | 15:59 |
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:00 |
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:01 |
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:02 | |
smoser | pitti, permission denied ? | 16:04 |
=== _salem is now known as salem_ | ||
smoser | slangasek, fix found | 16:25 |
smoser | rm -f "$MOUNTPOINT/etc/sysctl.d/10-ipv6-privacy.conf" | 16:25 |
smoser | fun bug. | 16:26 |
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. | 16:30 |
=== robbiew is now known as robbiew-afk | ||
=== salem_ is now known as _salem | ||
doko | stgraber, please have a look at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html libparse-debianchangelog-perl | 16:47 |
doko | jpds, mdeslaur: please could you have a look at the strongswan ftbfs, and if updating from debian would help? | 16:49 |
* mdeslaur looks | 16:52 | |
mdeslaur | jpds: any ideas? | 16:57 |
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. | 16:59 |
stgraber | doko: I doubt I'll have much time before release week in Washington, on vacation, conference and sprinting until then | 17:05 |
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:06 |
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:07 |
doko | stgraber, you could have spent the time arguing here instead by saying that it can be synced ;-P | 17:11 |
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:12 |
bdmurray | cjwatson, infinity, slangasek: Here are the search results for /etc/os-release. http://paste.ubuntu.com/8527959/ | 17:15 |
infinity | bdmurray: checkbox's usage might be interesting to look more closely at. | 17:18 |
infinity | Definitely a longer list than I expected. | 17:19 |
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:21 |
infinity | Ahh, fair point. At least for now. | 17:22 |
=== roadmr is now known as roadmr_afk | ||
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:28 |
slangasek | augeas just references it in terms of a configuration file, doesn't care about the contents | 17:30 |
bdmurray | gnome-control-center uses it to display the name | 17:32 |
* slangasek nods | 17:33 | |
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:35 |
slangasek | bdmurray: qtcreator looks clean; none of the plugins in rtm care about the platformName (which is good, they shouldn't) | 17:44 |
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:46 |
slangasek | util-linux supports pulling variables from here into agetty configs, so that's not relevant | 17:47 |
slangasek | bdmurray: looking | 17:47 |
slangasek | bdmurray: yeah, plymouth is display-only | 17:49 |
slangasek | bdmurray: systemd is clean | 17:57 |
bdmurray | slangasek: okay, I'm not clear on how packagekit uses it | 17:58 |
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:01 |
sarnold | hallyn: sorry, I never had any luck finding a reliable-enough reproducer in the time I've put into it.. | 18:14 |
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:15 |
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 | 18:18 |
=== roadmr_afk is now known as roadmr | ||
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:54 | |
infinity | Ahh, poorly named function, it definitely wants ID and VERSION_ID. | 18:56 |
* DistroFeud Ywans | 19:39 | |
DistroFeud | a friend of mine tells me ubuntu dev work is mostly done by upstream debian packagers | 19:39 |
cjwatson | slangasek: looks like that's only used by the service pack stuff, which we don't care about | 20:03 |
cjwatson | (packagekit) | 20:03 |
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:04 |
bdmurray | slangasek: okay, the general ubuntu hook in apport uses lsb_release -sc but that's just for adding a tag so meh | 20:08 |
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:09 |
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:12 |
smoser | oh. | 20:14 |
smoser | i see why. | 20:14 |
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:16 |
geser | smoser: could you add a check if the sysctl was set to the expected value in your ip wrapper? | 20:30 |
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:31 |
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:37 |
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:38 |
smoser | nop. i dont knwo . something fishy there. | 20:39 |
geser | and without the ipv6-privacy.conf file it works? | 20:40 |
smoser | yeah. i know. i dont trust me either :) | 20:40 |
smoser | it definitely works. just doing a mv of that file to .disabled. | 20:47 |
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 | 21:05 |
* DistroFeud YWANS | 23:50 | |
=== kitterma is now known as ScottK |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!