/srv/irclogs.ubuntu.com/2015/05/27/#ubuntu-devel.txt

psusiso snappy core doesn't have a gui desktop, or... man installed?  why ext4 for the r/o root instead of squashfs?00:53
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== alvesadrian is now known as adrian
rottenedhello03:12
pittiGood morning04:17
hyperairin an sru'd bug, do i do the verification-{needed,done} tag change myself or is that for ~ubuntu-sru to do?06:15
RAOFhyperair: Please set those tags if you've done the necessary verification. That puts it on our todo board.06:53
hyperairoh okay06:53
dholbachgood morning07:00
seb128hey dholbach07:10
dholbachsalut seb12807:12
seyeongkimhello, any plan to backport or something for CVE-2015-4000 Issue for each releases?08:37
ubottuThe 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)08:37
=== doko_ is now known as doko
seb128pitti, 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
seb128RuntimeError: Unable to instantiate any backends09:30
seb128X11: DisplayConnectionError(':0', b'Invalid MIT-MAGIC-COOKIE-1 key')09:30
seb128grumpf09:30
dokopitti, did something change with the autopkg test env? python2.7's autopkg tests now fail, trying to connect to an https sever on localhost09:31
pittiseb128: should be autopilot-sandbox-run09:31
dokoURLError: <urlopen error Tunnel connection failed: 403 Forbidden>09:31
pittiseb128: 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
seb128pitti, but then I don't see what it's doing09:31
pittidoko: success on i386, fail on amd64?09:31
pittidoko: amd64 was recently moved by CI to running in ProdStack; they fixed the $*_proxy environment variables several times, but perhaps there's still something wrong09:34
dokopitti, according to https://jenkins.qa.ubuntu.com/job/wily-adt-python2.7/lastBuild/ both fail09:35
pittidoko: hm, no, they fail on i386 too09:35
pittii386 didn't change09:35
pittidoko: we can re-run the vivid one to check, maybe something else changed somewhere09:35
dokowhere to report these issues?09:35
pittidoko: running now: http://d-jenkins.ubuntu-ci:8080/job/vivid-adt-python2.7/09:35
pittiso we have something for comparing distro changes vs. test env changes09:35
pittidoko: https://bugs.launchpad.net/auto-package-testing/+bugs is an okay place09:35
* pitti cleans up the bugs while I'm there09:40
pittidoko: FYI, http://d-jenkins.ubuntu-ci:8080/job/vivid-adt-python2.7/ARCH=i386,label=adt/ succeeded09:59
pitti(amd64 still running, nova is much slower)09:59
pittidoko: 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 i38610:00
pittimaybe the newer python has a new test which exhibit a problem with them10:00
dokopitti, no, at least for 2.7, this test didn't change10:09
pittidoko: ah, amd64/vivid now shows the same 403 forbidden error; still odd why i386/wily fails as well10:28
=== sabdfl_ is now known as sabdfl
pittidoko: ah no, that fails differently:10:29
pittierror: [Errno 104] Connection reset by peer10:29
pittiSSLError: [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)10:29
seb128pitti, 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
pittiseb128: ah, you already uploaded? cheers!11:19
pittiseb128: will look at that part11:20
seb128pitti, yes, since it worked locally I though it was going to work on the archive as well11:20
seb128thanks11:20
pittiseb128: 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
pittiseb128: right, it's not really CI vs. local, it's wily vs. wily-proposed11:21
seb128pitti, yeah, I can try having a look to robustify, just went for the easy solution today to unblock things11:21
pittiright, appreciated11:21
=== _ 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_
wgranttedg: 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
wgrantIt succeeds on the bare metal ancient sbuild builders, fails on the OpenStack moden sbuild ones.12:49
pittiFTR, succeeds locally in sbuild too12:54
pittieh, where is my mouse cursor..12:55
pittiit still "works"  but is invisible12:56
pittiwe used to use "unclutter", but that's long gone -- is that built into unity or so?12:56
xnoxpitti: there is a kernel option to "never hide mouse pointer" i think.12:58
* xnox enabled that, or rather disabled the hide on inactive, and can't remember where it was12:59
xnoxfound it on askubuntu12:59
ogra_pitti, use an "edding"12:59
ogra_be creative ;)12:59
pittiwell, I generally like the behavior of hiding it while typing, so that it doesn't get in the way12:59
seb128pitti, 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 cursor13:00
pittiogra_: ok, that helped, but now I have 23 mouse pointers drawn on my screen and they don't go away any more13:00
* pitti wipes harder13:00
ogra_lol13:00
seb128bdmurray, 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 most13:01
seb128same for the gvfs SRU13:02
seb128did those tests used to run on that serie?13:03
seb128the deja-dup fails on "env: dbus-launch: No such file or directory"13:03
LaneyI was under the impression that the SRU team only uses those results for advice, since the baseline isn't clean13:03
seb128Laney, the gtk one is marked as validated and is 25 days old, so I've the feeling they are blocking it13:04
LaneyWell, then have developers been told they need to watch out for and fix autopkgtests for SRUs?13:05
seb128Laney, dunno, that was sort of my question, you uploaded that gtk sru, did you get news from them after it13:05
tedgwgrant, Nothing obvious…13:07
LaneyI don't think so13:07
tedgIronically I'd say the testing in indicator-sound isn't great, funny it'd be the only failure.13:07
=== salem_ is now known as _salem
wgrantHeh13:08
tedgLet me take a look through the tests and see if I can see anything funky.13:09
seb128Laney, btw seems like you didn't push your release commit to the vcs, did you forgot to push?13:09
Laneycould be13:10
Laneydone13:10
seb128thanks13:10
seb128I'm stacking another SRU13:10
wgranttedg: 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.13:14
=== _salem is now known as salem_
=== mzanetti is now known as mzanetti|otp
pittiseb128, Laney: right, the mechanics to run SRUs in trusty were different, so the tests still have some bugs/hidden assumptions13:31
pittifailures there can't be a reason to reject an SRU13:31
seb128k13:32
seb128I guess that's a question for bdmurray&co then13:32
seb128danke13:32
pittiI think SRUs just haven't been processed for a week or so13:32
pittimight be just that13:32
pittiseb128: 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 ubuntu313:33
pittianyway, will run locally13:33
pittiah, perhaps because it didn't find any pics13:34
seb128pitti, well, it failed on a different one13:34
seb128"{'label': '2 Photos'}."13:34
seb128and that works locally/with old libgphoto13:34
seb128so I assumed that the photo count is wrong with the new lib13:34
pitti{'label': '2 Photos'}13:34
pittiright, I see13:34
pittiseb128: sorry for the noise13:35
seb128nw!13:35
pittiseb128: meh, shotwell (both wily and wily-proposed) just keeps hanging when trying to import..13:46
seb128pitti, :-/13:46
seb128wfm13:46
pittiboth with wily and wily-proposed libgphoto13:47
pittiseb128: PtP camera, or direct sd-card?13:47
seb128pitti, android phone13:47
roaksoaxpitti: 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:48
roaksoaxpitti: the issue is not present in Trusty nor Vivid13:49
=== gammax90 is now known as gammax
=== mzanetti|otp is now known as mzanetti
pittiimport               PASS14:05
pittiseb128: ^14:05
seb128pitti, how did you fix it?14:06
seb128pitti, did you manage to run the autopilot test locally? they wouldn't for me14:07
seb128just under the sandbox, but then you don't get to the see the UI interactions on screen14:07
pittiseb128: ah, the hang was because apparently something between my camera/libgphoto/shotwell didn't like the two mini "synthetic" pictures I put on the card14:07
pittiseb128: (worked fine with gvfs) -- so I just took two tiny real ones14:07
pittiroaksoax: right, bug in utopic's invoke-rc.d14:14
pittiroaksoax: i. e. if a package only ships an upstart job/systemd unit without an init.d script, then invoke-rc.d bails out14:14
pittiroaksoax: while this is not technically a valid Debian package, it's valid "enough" for Ubuntu, so we fixed that in vivid14:14
pittiroaksoax: so perhaps you have an /etc/init.d/maas-regiond, but no /etc/init.d/maas-regiond-worker?14:16
pittiroaksoax: you can work around this by: dh_installinit --no-start --name maas-regiond-worker14:16
pittiroaksoax: 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:16
micahgis anyone looking at the lintian "regression" for perl in wily, if not, I'll try to poke at it today14:37
roaksoaxpitti: ok, cool, I can definitely do that work around!14:40
pittiseb128: to clarify, we can drop block-proposed from bug 1456965 now, right?15:00
ubottubug 1456965 in Shotwell "Shouldn't use CSD under Unity" [Medium,Confirmed] https://launchpad.net/bugs/145696515:00
seb128pitti, 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
Laneyindeed, you need to delete the tag15:01
pittiseb128: 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:01
seb128pitti, I though it was maybe parsing changelog and substracting closed bugs15:02
seb128but yeah, then needs to be untagged15:02
pittiack, done15:03
seb128pitti, thanks15:07
tarpmanhi, 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 related15:33
pittitarpman: yes, it is; which pacakges?15:34
pittitarpman: 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 properly15:34
pittitarpman: but I can retry either way15:35
tarpmanpitti: squid3 (amd64 only -- guess that's what you're talking about) and boottest failed15:36
tarpmanpitti: rather, excuses still says "Test in progress" for boottest... after 36+ hours... don't think it's going anywere15:37
pittitarpman: squid3 will fail again, retry won't help15:37
pittitarpman: retried boottest15:39
tarpmanthanks!15:40
=== lifeless_ is now known as lifeless
=== rickspencer3_ is now known as rickspencer3
roaksoaxpitti: what is the correct way to check whether systemd is being used?16:39
strikovroaksoax: juju looks for /run/systemd/system (see: https://github.com/juju/juju/blob/master/service/systemd/service.go#L31)16:41
strikovroaksoax: pitty may know a better way though16:41
didrocksstrikov: roaksoax: it's the way we implemented with pitti in most services to decides if systemd is running or not16:42
didrocksdecide*16:42
strikovdidrocks: good to know, thanks!16:42
didrocksyw16:42
pittiroaksoax: what didrocks said17:07
pitti(sorry, was in meeting)17:07
roaksoaxpitti: great! thanks17:44
roaksoaxstrikov: thanks :)17:51
=== manjo` is now known as manjo
=== oSoMoN_ is now known as oSoMoN
infinityxnox: 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:40
infinityxnox: The entire testsuite is effectively useless for regression testing because that one's almost always red.18:41
mterry@pilot in18:53
=== 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
stgraberdoko: hey, are you aware that powerpc gccgo is bused in wily?20:19
stgraberdoko: 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.gz20:19
mterry@pilot out21:30
=== 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

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!