[00:40] <slangasek> tdaitx: squid3 uploaded and in the queue
[01:42] <tdaitx> slangasek, thanks!
[04:30] <pitti> Good morning
[05:17] <pitti> coreycb: the neutron i386 regression is quite stable (http://autopkgtest.ubuntu.com/packages/n/neutron/wily/i386/), and it doesn't look like just a race condition; can you please have a look?
[05:17] <pitti> coreycb: until then the package is stuck in -proposed (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#neutron)
[05:34] <pitti> Riddell: bumping the force-badtest for cantor, but there's a bunch of new regressions
[05:36] <pitti> Riddell: kservice in particular
[06:09] <pitti> Riddell: so I went through everything else and adjusted hints etc.;  kservice is the remaining regression that's relevant
[07:28] <dholbach> good morning
[07:29] <seb128> hey dholbach ;-)
[07:29] <seb128> happy friday!
[07:29] <dholbach> hey seb128
[07:29] <dholbach> and the same to you :)
[07:55] <mardy> seb128: hi! Do you have a minute to talk about bug 1453549?
[07:55] <ubottu> bug 1453549 in shotwell (Ubuntu) "Cannot publish to Facebook" [High,Confirmed] https://launchpad.net/bugs/1453549
[07:55] <seb128> mardy, hey, sure
[07:55] <mardy> seb128: so, I got no reply from Yorba :-(
[07:55] <seb128> :-(
[07:55] <seb128> that was sort of expected
[07:56] <mardy> seb128: yesterday i created a new facebook key, and got it reviewd and approved by facebook
[07:56] <seb128> they didn't reply on the shotwell list since june
[07:56] <seb128> oh, nice
[07:56] <mardy> seb128: the latest commit here switches to the new key: https://code.launchpad.net/~mardy/shotwell/lp1453549
[07:56] <Laney> someone posted on desktop-devel-list yesterday(?) about API keys
[07:57] <mardy> Laney: oh, I'll have a look then
[07:57] <Laney> it doesn't immediately solve this problem but maybe the idea of having them owned by some group is good and can help to avoid it in future
[07:58] <seb128> Laney, was that about shotwell?
[07:58] <seb128> because IRC discussions were about goa I think
[07:58] <mardy> seb128, Laney: my idea was to distro-patch it with the new key, and comment on the upstream bug about the new key I created and asking who wants to maintain it
[07:58] <seb128> at least the ones between Bastien and Xavier
[07:58] <seb128> mardy, +1 from me
[07:58] <Laney> it is a general idea
[07:59] <Laney> even if they have one specific case which motivates it
[08:01] <mardy> seb128: I wonder if you would be willing to take care of releasing a new shotwell with the uoa patch from https://code.launchpad.net/~mardy/shotwell/lp1453549 ?
[08:01] <seb128> mardy, yes, I can do that
[08:02] <mardy> seb128: thanks a lot, I'll comment on the upstream bug then
[08:02] <seb128> mardy, thanks
[08:40] <seb128> mardy, your branch doesn't merge fine on the vcs, there is a conflict in 06_uoa.patch
[08:40] <mardy> seb128: where can I find the latest shotwell branch for ubuntu?
[08:40] <seb128> mardy, hum, your patch change is only changing the ClientId?
[08:41] <mardy> seb128: yes
[08:41] <seb128> mardy, lp:~ubuntu-desktop/shotwell/ubuntu
[08:41] <seb128> apt-get source tell you that ;-)
[08:41] <seb128> (or debcheckout)
[08:41] <seb128> mardy, it's ok, I can change the Id manually
[08:41] <mardy> seb128: ah, that will be way faster :-) thanks
[08:41] <seb128> mardy, yw
=== vrruiz_ is now known as rvr
=== oSoMoN_ is now known as oSoMoN
[10:05] <pete-woods> pitti: backport of 0.16 to vivid overlay kthx? promise won't ask for more landings for at least an hour
[10:07] <pitti> pete-woods: lol
[10:07] <pitti> pete-woods: the overlay has the NM fix -- you need the CLI params one too?
[10:12] <sysrex> hello all, I am looking to backport ubuntu 7.0.55 to 14.04 what would be the best approach?
[10:29] <tsdgeos> cjwatson: you working on launchpad right? how hard would be to make the " 1 branch dependent on this one. " link in https://code.launchpad.net/~aacid/unity8/new_dash_navigation work?
[10:33] <cjwatson> tsdgeos: That's an interesting failure mode ... probably not very hard, could you please file a bug about that?
[10:33] <infinity> seb128: Why is that unity-settings-daemon changelog such a cluster#%@$?
[10:36] <tsdgeos> cjwatson: would be https://bugs.launchpad.net/launchpad/+bug/496056 i guess
[10:36] <ubottu> Launchpad bug 496056 in Launchpad itself "Dependent branch list is empty" [Low,Triaged]
[10:36] <tsdgeos> just that that one doesn't work anymre
[10:37] <cjwatson> tsdgeos: Ah, yes, it is that bug.  Indeed I was just thinking "I wonder if this ever worked?".
[10:37] <tsdgeos> cjwatson: i'd say no :D
[10:37] <tsdgeos> i have a look a few years ago
[10:37] <tsdgeos> ~1.5
[10:38] <tsdgeos> but my unexistant knowledge of the language launchpad is written and of launchpad itself made it basically impossible for a 1 hour bugfix :D
[10:39] <cjwatson> tsdgeos: Lots of things in Launchpad would be accessible to a casual contributor, but this probably isn't one of them; merge proposals have quite complex code around them to make the database queries halfway efficient.
[10:47] <pitti> pete-woods1: done
[10:47] <pete-woods1> pitti: :D
[10:49] <cjwatson> tsdgeos: Ah, indeed, I see you filed https://bugs.launchpad.net/launchpad/+bug/1277469 then, and that was marked as a duplicate.
[10:49] <ubottu> Launchpad bug 496056 in Launchpad itself "duplicate for #1277469 Dependent branch list is empty" [Low,Triaged]
[10:53] <tsdgeos> cjwatson: right, that one :)
=== pete-woods1 is now known as pete-woods
[11:02] <rbasak> slangasek, tdaitx, infinity: ah, I was just about to do the squid3 merge, but I see the latest upload yesterday. Shall I leave it?
=== marcust__ is now known as marcustomlinson_
[11:03] <rbasak> Since we'll want it next cycle and you won't be in for a while I might as well start it I guess, but let me know if you want it uploaded now or not.
=== marcustomlinson_ is now known as marcustomlinson
[11:08] <GunnarHj> happyaron: Any chance that you can upload the patch at bug #1481025 soon? language-selector-gnome, which I uploaded yesterday, depends on it.
[11:08] <ubottu> bug 1481025 in im-config (Ubuntu) "Keyboard shortcut for layout switching works in Unity but not in Gnome-Flashback" [Medium,In progress] https://launchpad.net/bugs/1481025
[11:16] <happyaron> GunnarHj: just did it
[11:17] <GunnarHj> happyaron: Great, thanks!
[11:17] <happyaron> :)
[11:17] <cjwatson> tsdgeos: OK, I think I have most of a fix but I should really finish off the other urgent things I was working on before diving into writing tests ...
[11:18] <tsdgeos> cjwatson: cool and sorry for derailing you :)
[11:25] <pete-woods> any chance a packaging expert could help me out with this one? https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1472186 (http://bazaar.launchpad.net/~indicator-applet-developers/indicator-network/trunk.15.10/view/head:/debian/control)
[11:25] <ubottu> Launchpad bug 1472186 in indicator-network (Ubuntu) "Can't install libconnectivity-qt1-dev on multiarch" [High,Confirmed]
[11:37] <seb128> infinity, because I backported individual commits to the vcs with --author and the CI train seems to want to credit individual commiters rather than using the mp description/commit message
[11:37] <seb128> unsure how to workaround it
[11:45] <seb128> infinity, I can manually fix the changelog/merge the vcs if you want
=== _salem is now known as salem_
[12:19] <GunnarHj> happyaron: I see in the diff that you picked the old patch instead of the one I prepared, so currently there is a mismatch compared to the l-s code.
[12:21] <GunnarHj> happyaron: What's the reason for that choice? How do we deal with it now?
[12:38] <morphis> seb128: ping
[12:46] <coreycb> pitti, on it, thanks
[13:02] <seb128> morphis, hey
[13:02] <morphis> seb128: you ever looked at obexd on desktop since we updated to bluez5?
[13:03] <seb128> morphis, no, is it not working?
[13:04] <morphis> seb128: it looks suspicious
[13:04] <morphis> the bluez-obexd package provides a systemd user service file
[13:05] <morphis> but we still depend on upstart for the session jobs
[13:05] <seb128> no dbus activation?
[13:05] <pitti> sitter: do you have an idea about the kservice regression? http://autopkgtest.ubuntu.com/packages/k/kservice/wily/amd64/ (but on all arches) -- this is what keeps most KDE uploads in -proposed
[13:05] <pitti> FAIL!  : KSycocaTest::dirTimestampShouldBeCheckedRecursively() 'newTimestamp > oldTimestamp' returned FALSE. ()
[13:06] <morphis> seb128: that is what I thought too: http://paste.ubuntu.com/12723307/
[13:06] <pitti> but this isn't just a flaky timing issue, it consisently failed on all arches for 7 times
[13:07] <sitter> pitti: that's a new test. will have to take a closer look
[13:07] <pitti> sitter: ah, it's new, not a regression?
[13:08] <pitti> sitter: want me to force-badtest this then for this version, or want to keep everything in -proposed for now?
[13:08] <sitter> pitti: best force for now please
[13:10] <seb128> morphis, the obexd binary is active on my user session on wily
[13:11] <sitter> Riddell: did you upload kservice rc1 or rc2? it appears to me rc2 should fix http://autopkgtest.ubuntu.com/packages/k/kservice/wily/amd64/
[13:11] <pitti> sitter: hinted
[13:11] <sitter> cheers
[13:12] <seb128> morphis, it's on the session bus, so -y -> -e
[13:12] <morphis> ah right
[13:12] <morphis> works now, sorry for the noise :)
[13:12] <seb128> no worry ;-)
[13:32] <Saviq> morphis, hey, we noticed with mzanetti there's issues with pairing a BT keyboard on krillin (works fine on mako/flo) - you never get a PIN dialog and the settings app just says "connected", when it's really not
[13:32] <Saviq> morphis, is that a known issue? otherwise what can we provide to help fix that?
[13:32] <morphis> Saviq: that is know
[13:32]  * Saviq tries on stable in the mean time
[13:32] <Saviq> oh ok
[13:32] <morphis> I have fixes for that
[13:32] <morphis> but we will land those together with the BlueZ 5 work
[13:33] <Saviq> morphis, and it's a krillin specific bug?
[13:33] <morphis> Saviq: needs changes on the kernel to get that working
[13:33] <morphis> Saviq: yes
[13:33] <Saviq> ack
[13:33] <Saviq> thanks
[13:33] <morphis> Saviq: if you want I can give you a device tarball with those changes
[13:34] <seb128> morphis, is that going to be fixed before bluez5?
[13:34] <Saviq> morphis, if you need me to test, sure, not pressing for me
[13:34] <morphis> seb128: not with ota7
[13:34] <seb128> k :-/
[13:34] <morphis> and we're trying to get all bluez5 stuff into ota8
[13:34] <seb128> right
[13:34] <Riddell> sitter: I uploaded kservice rc2, the one that's currently on the kde server, and it does have the patch which should fix the test
[13:34] <seb128> I wonder if the fix would also fix prompting with my car not working
[13:35] <seb128> looking forward bluez5 to land ;-)
[13:35] <morphis> seb128: no
[13:35] <morphis> that is something different
[13:35] <seb128> k
[13:35] <seb128> maybe bluez5 fixes it though
[13:36] <morphis> seb128: btw. I've updated the silos with some fixes for the authentication/pin problem
[13:36] <sitter> Riddell: so why is it failing then? :P
[13:37] <seb128> morphis, I saw, thanks, I've it on my list to try with those updates
[13:37] <Riddell> sitter: good question, I'm trying to recreate it
[13:37] <pitti> sitter, Riddell: kde landing, brace for impact :)
[13:38]  * sitter hides under desk
=== marcusto_ is now known as marcustomlinson
[13:52] <sitter> Riddell: passes here
[13:53] <cousteau> Request for openjdk-8 to be added to the LTS repos, since Java 7 is EOL'd?
[13:53] <cousteau> (or where should I direct my request/suggestion?)
[13:55] <Riddell> sitter: test fails here building the package from the archive, and git doesn't build it seems to have a change in it which isn't in the tar
[13:55] <Riddell> sitter: what do you do that passes?
[13:55] <sitter> I build first and then adt-run on the built tree
[13:56] <sitter> also I run it in a docker container
[13:56] <Riddell> sitter: build what? the package from the archive?
[13:56] <sitter> yup
[13:57] <Riddell> spooky
[13:57]  * Riddell installs the built packages then runs the tests again
[14:00] <sitter>     QTest::qWait(1000); // remove this once lastModified includes ms
[14:00] <sitter> timing problem?
[14:00] <sitter> although that wouldn't really explain why it fails consistently
=== davidcalle_ is now known as davidcalle
[14:17] <sitter> Riddell: uff, wrong version >.<
[14:18] <Riddell> sitter: ?
[14:18] <sitter>  /tmp/kservice-5.14.3
[14:18] <sitter> pull-lp-source gave me the wrong version for some reason xD
[14:18] <Riddell> tsk
[14:23] <sitter> Riddell: it's failing because of qt 5.4
[14:23] <sitter> and I can reproduce now
[14:23] <sitter> upstream build against qt 5.4 also fails the test https://build.kde.org/job/kservice%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/89/console
[14:24] <sitter> qt 5.5 for comparision https://build.kde.org/job/kservice%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/94/console
[14:25] <Riddell> well spotted
[14:26] <Riddell> sitter: I guess the only thing to do is e-mail the frameworks list and the Xuetian Weng dude who's been working on it
[14:26] <sitter> yeah
[14:27] <Riddell> sitter: I'll send an e-mail
[14:28]  * sitter looks into why that testsuite rebuilds the buildtree
[14:29] <sitter> Riddell: ^ fixed that in unstable
[14:30] <Riddell> I always assumed there was a good reason for that, I just never worked out what it would be
[14:30] <Riddell> sitter: ooh?
[14:30] <sitter> Riddell: http://anonscm.debian.org/cgit/pkg-kde/frameworks/kservice.git/commit/?h=kubuntu_unstable&id=d96d6f3641b9166f352003fb5d968e2d622264dd
[14:30] <sitter> testsuite rebuilt the tree for no good reason
[14:30] <Riddell> genius
[14:31] <Riddell> sitter: all the frameworks seem to have this
[14:32] <sitter> Riddell: just some
[14:32] <sitter> one of them probably needed it and from there on out it was bad copynpaste :P
[14:33] <Riddell> sitter: but I feel like it would be good to have tested in the ubuntu archive before changing it all, there might be a perfectly rational explanation
[14:33] <sitter> the openbox testsuite needs to be put into pkg-kde-tools really
[14:34] <sitter> Riddell: could just do it for 5.16
[14:34] <sitter> after wily
[14:34] <Riddell> yep
=== adrian is now known as alvesadrian
[15:28] <smoser> anyone have a suggestion on how to check in python "is systemd service X running" ?
[15:34] <jrwren> smoser: shell out. :)
[15:35] <cjwatson> smoser: python3-systemd is a thing apparently
[15:36] <cjwatson> hm though its online docs don't document such an operation
[15:38] <sil2100> seb128: hey, I saw you posting a bug on debian about this: https://bugs.launchpad.net/debian/+source/telepathy-glib/+bug/1504506 <- are you working on this bug currently? :)
[15:38] <ubottu> Launchpad bug 1504506 in telepathy-glib (Ubuntu) "FTBFS due to failing unit tests" [Undecided,In progress]
[15:38] <jrwren> honestly, subprocess.call('systemctl','status'... may be best.
[15:38] <seb128> sil2100, Laney is, he sent a patch upstream and said he would handle Debian/Ubuntu uploads
[15:39] <sil2100> seb128: excellent, thanks o/
[15:39] <gQuigs> smoser:  I wonder if you can just read the journal of a specific service maybe ? (https://github.com/systemd/python-systemd)
[15:39] <seb128> sil2100, yw, assigned to Laney so other don't duplicate work
[15:40] <cjwatson> Shelling out to systemctl is probably easiest TBH
[15:45] <sil2100> btw. I see that python-pex autopkgtests are failing, blocking wheel in -proposed right now
[15:45] <sil2100> Is anyone looking into those right now?
[15:46] <didrocks> cjwatson: gQuigs: you should prefer using "show" rathen than "status". status is supposed to be human-readable and not for parsing
[15:46] <didrocks> rather*
[15:47] <cjwatson> didrocks: I didn't specify any particular thing
[15:48] <cjwatson> didrocks: and it was smoser who was actually trying to do it
[15:48] <didrocks> right, backlogged fully now, so smoser ^
[15:49] <sil2100> barry: hey! I see that the new wheel sync seems to cause some autopkgtests fail for python-pex and therefore got blocked in -proposed
[15:49] <sil2100> barry: for instance: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/armhf/p/python-pex/20151008_212123@/log.gz
[15:49] <smoser> yeah. i think i'll shell out.
[15:50] <sil2100> barry: this is a bit worrying: Resolving interpreter :: Setting up interpreter /usr/bin/python3.5 :: Interpreter cache resolving wheel<0.25.0,>=0.24.0 Could not find compatible interpreter <- could this be related to the failure?
[15:50] <smoser> i think i just need 'reload-or-restart'. and through shell.
[15:50] <smoser> thanks ffor feedback
[15:50] <sil2100> barry: the version you pulled in is 0.26.0-1, maybe we'd need some fixes/changes to python-pex too? Should I look into that or is it worked on already?
[15:51] <sil2100> barry: I actually see a new python-pex in -proposed
[15:52] <barry> sil2100: i just uploaded pex 1.0.3-2ubuntu1 but i guess it doesn't solve the problem.  i wonder if its a problem with the armhf and ppc platforms
[15:52] <slangasek> rbasak: up to you whether you think the squid3 merge should still be done this cycle; the blocking bugs have been resolved now, we weren't sure of an eta for the (big hairy) merge
[15:52] <rbasak> slangasek: thanks. Now that I've looked at it, it's even more hairy, so I'm going to decline to push it in this late now. I'll have it ready for early next cycle.
[15:52] <rbasak> infinity: ^
[15:52] <sil2100> barry: I see that all autopkgtest archs for the new python-pex are failing
[15:54] <sil2100> barry: btw. any package I could help out and pick up to fix the FTBFS? ;) I prefer to ask since I see many of the failures are already worked on,
[15:54] <barry> sil2100: dang.  and i specifically ran adt-run on that package before i uploaded it :(
[15:55] <gQuigs> would we recommend people to use systemctl not service in new releases?
[15:55] <barry> sil2100: i started with configglue, but just haven't gotten very far and too many other things got pushed on my stack. :(  it's an upstream incompatibility.  see LP: #1504288 if you'd like to take a look
[15:56] <ubottu> Launchpad bug 1504288 in python-configglue (Ubuntu) "Test suite failure with Python 3.4 & 3.5" [Undecided,New] https://launchpad.net/bugs/1504288
[15:57] <sil2100> barry: on it then!
[15:57] <barry> sil2100: thanks!  i'm getting some lunch now :)
[15:58] <sil2100> Have fun ;)
=== fginther` is now known as fginther
[19:04] <ben___> newb launchpad/bzr question -- but how do I see the source for changes after a package is released? e.g., using libvirt as an example, `bzr branch lp:ubuntu/trusty/libvirt` shows me the code for the release package (libvirt 1.2.2-0ubuntu13), how do I checkout the code for the updates package (libvirt 1.2.2-0ubuntu13.1.14)?
[19:13] <ricotz> doko, hi, maybe you could take a look at merging aptitude 0.7.3-1
[19:27] <cjwatson> ben___: The system for doing automatic imports into bzr is not very robust and is unmaintained, so it often breaks.  We plan to replace it with a similar system for importing into git at some point, but haven't started on that yet.  In the meantime it's more reliable to just fetch the source package; use "pull-lp-source" from the ubuntu-dev-tools package, or for just a quick diff to the last version you can start from ...
[19:27] <cjwatson> ... https://launchpad.net/ubuntu/+source/libvirt
[19:28] <ben___> cjwatson: thanks, that makes more sense.
[19:31] <hjd> cjwatson: Is pull-lp-source working again? (Last time I tried, I ran into bug 1453330)
[19:31] <ubottu> bug 1453330 in ubuntu-dev-tools (Ubuntu) "pull-{lp,debian}-source not getting source for binary because DDE is dead" [High,Triaged] https://launchpad.net/bugs/1453330
[19:32] <hjd> Or wait... that might be the debian-part of it only...
[19:32] <cjwatson> I believe that's only pull-debian-source, and in any case you can work around it by specifying a version
[19:32] <cjwatson> IIRC
[19:43] <hjd> tested now, and pull-lp-source seems to work fine at least. So ignore my comment above :)
[19:49] <ben___> yep, working here as well
[20:35] <barry> pitti: don't suppose you might still be around?
[22:24] <knome> slangasek, hullo! we have now updated the merge proposal for xubuntu core at https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167
[22:25] <knome> slangasek, should have changes you asked for, and if you want to discuss the way things have been done there, i brought krytarik, the author of the newest changes here :)
=== mfisch is now known as Guest27764
=== Guest27764 is now known as mfisch
=== Guest87130 is now known as balloons
=== salem_ is now known as _salem