[00:53] <psusi> so snappy core doesn't have a gui desktop, or... man installed?  why ext4 for the r/o root instead of squashfs?
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== alvesadrian is now known as adrian
[03:12] <rottened> hello
[04:17] <pitti> Good morning
[06:15] <hyperair> in an sru'd bug, do i do the verification-{needed,done} tag change myself or is that for ~ubuntu-sru to do?
[06:53] <RAOF> hyperair: Please set those tags if you've done the necessary verification. That puts it on our todo board.
[06:53] <hyperair> oh okay
[07:00] <dholbach> good morning
[07:10] <seb128> hey dholbach
[07:12] <dholbach> salut seb128
[08:37] <seyeongkim> hello, any plan to backport or something for CVE-2015-4000 Issue for each releases?
[08:37] <ubottu> The TLS protocol 1.2 and earlier, when a DHE_EXPORT ciphersuite is enabled on a server but not on a client, does not properly convey a DHE_EXPORT choice, which allows man-in-the-middle attackers to conduct cipher-downgrade attacks by rewriting a ClientHello with DHE replaced by DHE_EXPORT and then rewriting a ServerHello with DHE_EXPORT replaced by DHE, aka the "Logjam" issue. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4000)
=== doko_ is now known as doko
[09:30] <seb128> pitti, is running "autopilot3 run autopilot_tests" from debian/tests supposed to work?
[09:30] <seb128>     "Unable to instantiate any backends\n%s" % '\n'.join(failure_reasons))
[09:30] <seb128> RuntimeError: Unable to instantiate any backends
[09:30] <seb128> X11: DisplayConnectionError(':0', b'Invalid MIT-MAGIC-COOKIE-1 key')
[09:30] <seb128> grumpf
[09:31] <doko> pitti, did something change with the autopkg test env? python2.7's autopkg tests now fail, trying to connect to an https sever on localhost
[09:31] <pitti> seb128: should be autopilot-sandbox-run
[09:31] <doko> URLError: <urlopen error Tunnel connection failed: 403 Forbidden>
[09:31] <pitti> seb128: but it was working before, it can't possibly be just autopilot3 without any xvfb or so (autopilot-sandbox-run makes that really easy)
[09:31] <seb128> pitti, but then I don't see what it's doing
[09:31] <pitti> doko: success on i386, fail on amd64?
[09:34] <pitti> doko: amd64 was recently moved by CI to running in ProdStack; they fixed the $*_proxy environment variables several times, but perhaps there's still something wrong
[09:35] <doko> pitti, according to https://jenkins.qa.ubuntu.com/job/wily-adt-python2.7/lastBuild/ both fail
[09:35] <pitti> doko: hm, no, they fail on i386 too
[09:35] <pitti> i386 didn't change
[09:35] <pitti> doko: we can re-run the vivid one to check, maybe something else changed somewhere
[09:35] <doko> where to report these issues?
[09:35] <pitti> doko: running now: http://d-jenkins.ubuntu-ci:8080/job/vivid-adt-python2.7/
[09:35] <pitti> so we have something for comparing distro changes vs. test env changes
[09:35] <pitti> doko: https://bugs.launchpad.net/auto-package-testing/+bugs is an okay place
[09:40]  * pitti cleans up the bugs while I'm there
[09:59] <pitti> doko: FYI, http://d-jenkins.ubuntu-ci:8080/job/vivid-adt-python2.7/ARCH=i386,label=adt/ succeeded
[09:59] <pitti> (amd64 still running, nova is much slower)
[10:00] <pitti> doko: so, this could of course still be an issue with the data center's proxy, but the env vars haven't changed in a long time on i386
[10:00] <pitti> maybe the newer python has a new test which exhibit a problem with them
[10:09] <doko> pitti, no, at least for 2.7, this test didn't change
[10:28] <pitti> doko: ah, amd64/vivid now shows the same 403 forbidden error; still odd why i386/wily fails as well
=== sabdfl_ is now known as sabdfl
[10:29] <pitti> doko: ah no, that fails differently:
[10:29] <pitti> error: [Errno 104] Connection reset by peer
[10:29] <pitti> SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:590)
[10:29] <pitti> (from http://d-jenkins.ubuntu-ci:8080/job/wily-adt-python2.7/10/ARCH=i386,label=adt/artifact/results/testsuite-stdout)
[11:19] <seb128> pitti, k, I fixed that shotwell test, it works locally now, but failed on jenkins/with the new libgphoto in proposed (doesn't find 2 photos to import)
[11:19] <pitti> seb128: ah, you already uploaded? cheers!
[11:20] <pitti> seb128: will look at that part
[11:20] <seb128> pitti, yes, since it worked locally I though it was going to work on the archive as well
[11:20] <seb128> thanks
[11:21] <pitti> seb128: haha @ the patch; I didn't quite like the down/down thingy, but I didn't see a better way (maybe someone more proficient with autopilot can robustify this)
[11:21] <pitti> seb128: right, it's not really CI vs. local, it's wily vs. wily-proposed
[11:21] <seb128> pitti, yeah, I can try having a look to robustify, just went for the easy solution today to unblock things
[11:21] <pitti> right, appreciated
=== _ is now known as Guest38326
=== tsdgeos_ is now known as tsdgeos
=== DrKranz is now known as DktrKranz
=== henrix_ is now known as henrix
=== alai` is now known as alai
=== _salem is now known as salem_
[12:49] <wgrant> tedg: We're upgrading Launchpad's sbuild from a 2004 fork to one based on vivid's, and indicator-sound is the only build regression in main. A test fails, as seen in https://launchpad.net/ubuntu/+archive/test-rebuild-20150521/+build/7451774. Do you have any idea what might be going on there?
[12:49] <wgrant> It succeeds on the bare metal ancient sbuild builders, fails on the OpenStack moden sbuild ones.
[12:54] <pitti> FTR, succeeds locally in sbuild too
[12:55] <pitti> eh, where is my mouse cursor..
[12:56] <pitti> it still "works"  but is invisible
[12:56] <pitti> we used to use "unclutter", but that's long gone -- is that built into unity or so?
[12:58] <xnox> pitti: there is a kernel option to "never hide mouse pointer" i think.
[12:59]  * xnox enabled that, or rather disabled the hide on inactive, and can't remember where it was
[12:59] <xnox> found it on askubuntu
[12:59] <ogra_> pitti, use an "edding"
[12:59] <ogra_> be creative ;)
[12:59] <pitti> well, I generally like the behavior of hiding it while typing, so that it doesn't get in the way
[13:00] <seb128> pitti, we never preinstalled/recommended "unclutter", it has side effect/issues, we don't have a solution for that afaik, it's just that some gtk widget like the text ones hide the cursor
[13:00] <pitti> ogra_: ok, that helped, but now I have 23 mouse pointers drawn on my screen and they don't go away any more
[13:00]  * pitti wipes harder
[13:00] <ogra_> lol
[13:01] <seb128> bdmurray, Laney, pitti: do you know what's going on with the trusty gtk+3.0 SRU? http://people.canonical.com/~ubuntu-archive/pending-sru.html lists a bunch of regression in autopkgtests but those don't seem really related to gtk, there are what looks like jenkins issues for most
[13:02] <seb128> same for the gvfs SRU
[13:03] <seb128> did those tests used to run on that serie?
[13:03] <seb128> the deja-dup fails on "env: dbus-launch: No such file or directory"
[13:03] <Laney> I was under the impression that the SRU team only uses those results for advice, since the baseline isn't clean
[13:04] <seb128> Laney, the gtk one is marked as validated and is 25 days old, so I've the feeling they are blocking it
[13:05] <Laney> Well, then have developers been told they need to watch out for and fix autopkgtests for SRUs?
[13:05] <seb128> Laney, dunno, that was sort of my question, you uploaded that gtk sru, did you get news from them after it
[13:07] <tedg> wgrant, Nothing obvious…
[13:07] <Laney> I don't think so
[13:07] <tedg> Ironically I'd say the testing in indicator-sound isn't great, funny it'd be the only failure.
=== salem_ is now known as _salem
[13:08] <wgrant> Heh
[13:09] <tedg> Let me take a look through the tests and see if I can see anything funky.
[13:09] <seb128> Laney, btw seems like you didn't push your release commit to the vcs, did you forgot to push?
[13:10] <Laney> could be
[13:10] <Laney> done
[13:10] <seb128> thanks
[13:10] <seb128> I'm stacking another SRU
[13:14] <wgrant> tedg: You can reproduce by uploading to a normal PPA, as all the virtual builders are using the new sbuild. If you can't see anything suspicious in the test suite, I'll try to narrow down why it works locally but not on an almost identical sbuild on scalingstack.
=== _salem is now known as salem_
=== mzanetti is now known as mzanetti|otp
[13:31] <pitti> seb128, Laney: right, the mechanics to run SRUs in trusty were different, so the tests still have some bugs/hidden assumptions
[13:31] <pitti> failures there can't be a reason to reject an SRU
[13:32] <seb128> k
[13:32] <seb128> I guess that's a question for bdmurray&co then
[13:32] <seb128> danke
[13:32] <pitti> I think SRUs just haven't been processed for a week or so
[13:32] <pitti> might be just that
[13:33] <pitti> seb128: hm, http://d-jenkins.ubuntu-ci:8080/job/wily-adt-shotwell/29/ARCH=i386,label=adt/console still failed on "button not found", and that's ubuntu3
[13:33] <pitti> anyway, will run locally
[13:34] <pitti> ah, perhaps because it didn't find any pics
[13:34] <seb128> pitti, well, it failed on a different one
[13:34] <seb128> "{'label': '2 Photos'}."
[13:34] <seb128> and that works locally/with old libgphoto
[13:34] <seb128> so I assumed that the photo count is wrong with the new lib
[13:34] <pitti> {'label': '2 Photos'}
[13:34] <pitti> right, I see
[13:35] <pitti> seb128: sorry for the noise
[13:35] <seb128> nw!
[13:46] <pitti> seb128: meh, shotwell (both wily and wily-proposed) just keeps hanging when trying to import..
[13:46] <seb128> pitti, :-/
[13:46] <seb128> wfm
[13:47] <pitti> both with wily and wily-proposed libgphoto
[13:47] <pitti> seb128: PtP camera, or direct sd-card?
[13:47] <seb128> pitti, android phone
[13:48] <roaksoax> pitti: howdy! I wsa wondering if you may have an idea of an issue we are experiencing. After we committed http://paste.ubuntu.com/11391993/ , we started seeing http://paste.ubuntu.com/11222479/ . The funny thing is that this only happens in Utopic, so I'm wondering if this has something to do with systemd related changes or how the handling happens?
[13:49] <roaksoax> pitti: the issue is not present in Trusty nor Vivid
=== gammax90 is now known as gammax
=== mzanetti|otp is now known as mzanetti
[14:05] <pitti> import               PASS
[14:05] <pitti> seb128: ^
[14:06] <seb128> pitti, how did you fix it?
[14:07] <seb128> pitti, did you manage to run the autopilot test locally? they wouldn't for me
[14:07] <seb128> just under the sandbox, but then you don't get to the see the UI interactions on screen
[14:07] <pitti> seb128: ah, the hang was because apparently something between my camera/libgphoto/shotwell didn't like the two mini "synthetic" pictures I put on the card
[14:07] <pitti> seb128: (worked fine with gvfs) -- so I just took two tiny real ones
[14:14] <pitti> roaksoax: right, bug in utopic's invoke-rc.d
[14:14] <pitti> roaksoax: i. e. if a package only ships an upstart job/systemd unit without an init.d script, then invoke-rc.d bails out
[14:14] <pitti> roaksoax: while this is not technically a valid Debian package, it's valid "enough" for Ubuntu, so we fixed that in vivid
[14:16] <pitti> roaksoax: so perhaps you have an /etc/init.d/maas-regiond, but no /etc/init.d/maas-regiond-worker?
[14:16] <pitti> roaksoax: you can work around this by: dh_installinit --no-start --name maas-regiond-worker
[14:16] <pitti> roaksoax: if you can deal with the worker not being started automatically by package installation (if you need that, you need to add it manually to postisnt)
[14:37] <micahg> is anyone looking at the lintian "regression" for perl in wily, if not, I'll try to poke at it today
[14:40] <roaksoax> pitti: ok, cool, I can definitely do that work around!
[15:00] <pitti> seb128: to clarify, we can drop block-proposed from bug 1456965 now, right?
[15:00] <ubottu> bug 1456965 in Shotwell "Shouldn't use CSD under Unity" [Medium,Confirmed] https://launchpad.net/bugs/1456965
[15:01] <seb128> pitti, yes, how does that work? I assumed it wouldn't stop migration since it was listed as to close in the changelog, but maybe the system is not smart enough to figure that out?
[15:01] <Laney> indeed, you need to delete the tag
[15:01] <pitti> seb128: right, chicken-egg -- the bug only gets closed once it hits wily, which it can't because of that open bug :)
[15:01] <Laney> (or close the bug)
[15:02] <seb128> pitti, I though it was maybe parsing changelog and substracting closed bugs
[15:02] <seb128> but yeah, then needs to be untagged
[15:03] <pitti> ack, done
[15:07] <seb128> pitti, thanks
[15:33] <tarpman> hi, is this the right place to ask about having autopkgtests retried? openldap is blocked by a couple of fails that I don't think are my fault: one looks like the bzr issue that I think was already fixed, the other seems to be network related
[15:34] <pitti> tarpman: yes, it is; which pacakges?
[15:34] <pitti> tarpman: although the amd64 ones (adt-nova) seem to have some networking problems due to proxy config, this is usually not just a glitch but needs fixing properly
[15:35] <pitti> tarpman: but I can retry either way
[15:36] <tarpman> pitti: squid3 (amd64 only -- guess that's what you're talking about) and boottest failed
[15:37] <tarpman> pitti: rather, excuses still says "Test in progress" for boottest... after 36+ hours... don't think it's going anywere
[15:37] <pitti> tarpman: squid3 will fail again, retry won't help
[15:39] <pitti> tarpman: retried boottest
[15:40] <tarpman> thanks!
=== lifeless_ is now known as lifeless
=== rickspencer3_ is now known as rickspencer3
[16:39] <roaksoax> pitti: what is the correct way to check whether systemd is being used?
[16:41] <strikov> roaksoax: juju looks for /run/systemd/system (see: https://github.com/juju/juju/blob/master/service/systemd/service.go#L31)
[16:41] <strikov> roaksoax: pitty may know a better way though
[16:42] <didrocks> strikov: roaksoax: it's the way we implemented with pitti in most services to decides if systemd is running or not
[16:42] <didrocks> decide*
[16:42] <strikov> didrocks: good to know, thanks!
[16:42] <didrocks> yw
[17:07] <pitti> roaksoax: what didrocks said
[17:07] <pitti> (sorry, was in meeting)
[17:44] <roaksoax> pitti: great! thanks
[17:51] <roaksoax> strikov: thanks :)
=== manjo` is now known as manjo
=== oSoMoN_ is now known as oSoMoN
[18:40] <infinity> xnox: I'll send you buckets of maple syrup if you fix upstart's test_job_process to stop failing the "with single line command writing lots of data fast and exiting" test.
[18:41] <infinity> xnox: The entire testsuite is effectively useless for regression testing because that one's almost always red.
[18:53] <mterry> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
=== FlannelKing is now known as Flannel
[20:19] <stgraber> doko: hey, are you aware that powerpc gccgo is bused in wily?
[20:19] <stgraber> doko: lxd builds fine on all arches except powerpc (the 32bit kind): https://launchpadlibrarian.net/207637499/buildlog_ubuntu-wily-powerpc.lxd_0.10-0ubuntu1_BUILDING.txt.gz
[21:30] <mterry> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== salem_ is now known as _salem