=== ben is now known as 7F1AAQCDM
=== ogasawara is now known as Guest14527
=== ikonia is now known as Guest16046
=== wgrant is now known as Guest27601
=== kgunn is now known as Guest52384
[01:26] <Pwnna> cjwatson: yeah this thing i'm working on is all about this.
[01:27] <Pwnna> cjwatson: so if my file, /a is not in conffile and present in version 1.0, when i update the package to version 1.1, which no longer include the file /a, it will get automatically removed?
[01:28] <ScottK> Yes.
[01:30] <Pwnna> and if 1.0 depend on b, which depends on a. and 1.1 don't depend on b anymore, will b and a be removed?
=== Guest27601 is now known as wgrant
[01:31] <ScottK> Not without an additional command.
[01:32] <ScottK> They'll no longer be required to met the dependency, so apt-get autoremove would remove them.
[01:32] <Pwnna> hm so i should apt-get upgrade and then autoremove if i want this?
[01:32] <ScottK> Yes.
[01:33] <sarnold> the deborphan / orphaner programs can be helpful to clean up machines that have gone through a dozen upgrades
[01:33] <sarnold> they require a careful use, of course, but they're helpful
[01:34] <Pwnna> wait what's the difference between deborphan and autoremove?
[01:35] <Unit193> sarnold: Plus  dpkg-query -W -f='${Conffiles}\n' | grep obso  and debsums.
[01:35] <Pwnna> i'm not quite sure i understand the difference from this description.
[01:35] <Pwnna> does it show manually installed packages too?
[01:35] <sarnold> Pwnna: I've used them all for a decade and still don't know the exact differences :)
[01:35] <Pwnna> lol
[01:37] <sarnold> Unit193: heh, dpkg-query -W -f='${Conffiles}\n' | grep obso | wc -l  -> 30
[01:37] <sarnold> Unit193: I hadn't seen that before, thanks.
[01:37] <Unit193> sarnold: Yeeeeah, can drive you nuts.  Means someone didn't do packaging right. ;)
=== nudtrobert1 is now known as nudtrobert
[04:23] <pitti> Good morning
[04:28] <pitti> stgraber: nice work on lxd!
[04:29] <pitti> barry: yay for fixing pex!
[04:29] <pitti> what a morning, so little stuff being stuck in -proposed :)
[04:29] <barry> pitti: that was a fun one :)
[04:31] <pitti> barry: eww @ bug 1485093, what on earth is that doing??
[04:31] <ubottu> bug 1485093 in ubuntu-release-upgrader (Ubuntu Wily) "python3-distupgrade contains symlink to externally owned directory" [Undecided,New] https://launchpad.net/bugs/1485093
[04:31] <barry> pitti: it's madness
[04:34]  * barry really needs to go to sleep
[04:53] <pitti> wgrant: hm, didn't get an export on https://translations.launchpad.net/ubuntu/wily/+language-packs -- did it crash or so?
[04:53] <pitti> infinity: ^ FYI, langpack delay
[04:54] <wgrant> pitti: Yeah, it died, apparently :/
[04:54] <wgrant> pitti: Should I kick another one off now?
[04:54] <pitti> wgrant: please
[04:56] <infinity> pitti: Right, hopefully we get those soon. :P
[04:57] <pitti> wgrant: a full export takes how long now? some 6 hours?
[04:58] <wgrant> pitti: A little under four hours, usually.
[04:58] <pitti> ah, good
[04:59] <pitti> OMFG, is scalingstack lcy01 down *again*
[04:59] <wgrant> Really?
[04:59] <pitti> ERROR: HTTPConnectionPool(host='10.89.64.69', port=5000): Max retries exceeded with url: /v2.0/tokens (Caused by <class 'httplib.BadStatusLine'>: '')
[04:59] <wgrant> It keeps running into some very unfortunate situations.
[05:00] <pitti> it was shaky in the last few days already
[05:00] <wgrant> haha you have no idea
[05:00] <pitti> I got all kinds of weird errors
[05:00] <wgrant> Junien should be around in a bit to sort it out.
[05:00] <pitti> ah, did you already talk to IS? I was about to raise an RT
=== fabo_ is now known as fabo
[06:26] <sarnold> pitti: thanks for the postgresql updates
[06:26] <pitti> sarnold: thanks for publishing them
[06:50] <dholbach> good morning
[06:52] <sladen> still a tad dull and wet here
[09:05] <doko> roaksoax, look at python3-twisted-experimental. it has all the modules which should be supported in python3
=== soee_ is now known as soee
[09:29] <Saviq> morphis, ok so I still have trouble with BT on vivid/flo, it worked fine on first boot after flashing, but is gone after a reboot
[09:33] <Saviq> morphis, had to run bluetoothd manually to get it back, pointers on which of the bluetooth{,-touch{,-flo}} upstart jobs should work?
[09:34] <doko> mwhudson, the example was given to me by dobey. I just played around with it until it could be built.
[09:52] <cking> is it possible for https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1491729, to sponsored, it's been waiting ~6 weeks
[09:52] <ubottu> Launchpad bug 1491729 in dkms (Ubuntu) "[FFE]: dkms: add module build ordering for ZFS on Linux" [High,In progress]
[09:56] <pitti> seb128, wgrant: yay, we have a wily export! /me turns the crank
[09:56] <seb128> pitti, \o/
[10:01] <Laney> \o/
[11:06] <morphis> Saviq: I am currently setting up my flo to see if I can reproduce that
[11:06] <morphis> Saviq: the bluetooth-touch-flo one should work
[11:07] <morphis> does it fail to start?
[11:07] <Saviq> morphis, I just rebooted, no BT indicator icon
[11:08] <Saviq> morphis, but it seems like it actually works
[11:08] <morphis> what does hciconfig -a say?
[11:08] <morphis> does it list the hci0 device as up?
[11:09] <Saviq> morphis, http://pastebin.ubuntu.com/12797827/
[11:11] <Saviq> morphis, ok, it seems to actually be working
[11:11] <Saviq> morphis, so the problem seems to be in the bluetooth indicator service that says it's not
[11:12] <doko> tvoss, is mediascanner2 in -proposed still targeted for wily?
[11:13] <morphis> Saviq: can you run /usr/bin/bluez-test-adapter ?
[11:13] <tvoss> doko, need to dispatch, pstolowski is your friend
[11:13] <Saviq> morphis, what command?
[11:14] <morphis> Saviq: just /usr/bin/bluez-test-adapter
[11:14] <Saviq> morphis, that just showed me a list of commands to run
[11:14] <doko> tvoss, not here, which channel?
[11:14] <Saviq> morphis, list said http://pastebin.ubuntu.com/12797849/
[11:14] <morphis> looks good
[11:14] <Saviq> morphis, but it took ~10s
[11:14] <morphis> Saviq: so seems to be a problem with the indicator
[11:14] <tvoss> doko, #ubuntu-touch
[11:14] <morphis> Saviq: really?
[11:14] <Saviq> morphis, well, maybe not 10
[11:15] <Saviq> morphis, ah, it suspended
[11:15] <Saviq> morphis, it's fine, device was just slow because suspended
[11:15] <morphis> ok
[11:16] <Saviq> morphis, ok so yeah, you're off the hook, indicator to blame
[11:16] <morphis> through settings everything works?
[11:16] <Saviq> morphis, yeah, and restarting BT indicator seems to fix it, too
[11:16] <morphis> hm
[11:17] <Saviq> morphis, will follow up with charles
[11:17] <morphis> Saviq: can you check in .cache/upstart if there is a log file for the indicator?
[11:17] <morphis> Saviq: btw. the indicator will change quite a bit with the BlueZ5 upgrade
[11:17] <Saviq> morphis, there is one, but just one msg about rfkill
=== nopf_ is now known as nopf
[11:17] <morphis> Saviq: can you paste it?
[11:18] <Saviq> ** (process:2132): CRITICAL **: rf_kill_switch_real_try_set_blocked: assertion '_tmp1_ != _tmp2_' failed
[11:19] <Saviq> morphis, .1.gz had http://pastebin.ubuntu.com/12797881/
[11:19] <Saviq> morphis, on reboot I got ** (process:2128): CRITICAL **: bluez.vala:104: Error calling StartServiceByName for org.bluez: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1
[11:19] <morphis> I saw that one before
[11:19] <Saviq> and no BT icon
[11:19] <Saviq> looks like a race maybe
[11:19] <morphis> yeah
[11:20] <morphis> and it doesn't find the adapter
[11:20] <Saviq> indicator starts too early and doesn't try again later
[11:20] <morphis> right
[11:20] <Saviq> morphis, ok, that helps a lot, will file bug with i-b
[11:20] <morphis> Saviq: before you file a bug
[11:21] <Saviq> try BZ5
[11:21] <Saviq> will do
[11:21] <Saviq> later today
[11:21] <morphis> exactly
[11:21] <morphis> if that doesn't work too, then we need to file the bug
[11:21] <Saviq> ack
[11:21] <morphis> Saviq: if you file please add the tags "bluetooth" and "bluez5"
[11:28] <Saviq> kk
=== _salem is now known as salem_
[12:27] <doko> apw, cking, zfs-linux on ppc64el is an acute schizophrenic mood about it's endianess ...
[12:28] <cking> doko, yup, thanks, I'm aware of this bizarre schizomode
[13:00] <Odd_Bloke> I'm looking at python-taskflow; it Depends on a bunch of things that provide optional behaviour; if I wanted to trim some of these dependencies out, can I just demote them to (Recommends|Suggests) and test core functionality works without them installed, or do I need to do something more complex?
[13:02] <rbasak> Odd_Bloke: it's pretty normal in Ubuntu to do what you described when the dependencies are in universe.
[13:03] <rbasak> Odd_Bloke: it's common for python packages to build-depend on most of their dependencies so that tests can be run as part of the package build; you might need to check those too.
[13:03] <rbasak> This is assuming that there's no other need to keep the functionality you're dropping, of course.
[13:06] <Odd_Bloke> rbasak: Would having all the packages in Build-Depends but then as (Recommends|Suggests) in the binary package be a problem?
[13:07] <Odd_Bloke> Oh, it might be a problem for main inclusion down the line.
[13:09] <Odd_Bloke> I missed the 'build and' in "All build and binary dependencies (including Recommends:) must be satisfyable in main".
[13:10] <Odd_Bloke> Oh, no, python-taskflow is already in main.
[13:18] <rbasak> Odd_Bloke: what are you actually trying to do?
[13:18] <rbasak> Odd_Bloke: fix a component mismatch or something else?
[13:19] <Odd_Bloke> rbasak: We're considering python-taskflow as a cloud-init 2.0 dependency; as things stand, installing it increases image size by ~50MB.
[13:19] <rbasak> I see
[13:19] <rbasak> I think it's an openstack dependency too
[13:19] <rbasak> Probably worth having a look for other reverse deps
[13:20] <rbasak> As long as every consumer is happy I see no issue in trying to slim it down
[13:20] <Odd_Bloke> OK, cool.
[13:21] <Odd_Bloke> ATM I'm just trying to get a sense of how small a footprint it could have, and work out if we're happy with that.
[13:21] <Odd_Bloke> But didn't want to do so in a way that couldn't possibly fly in the archive. :)
=== imcleod_ is now known as imcleod
[13:56] <doko> pitti, jamespage: looks like you didn't merge the debian packaging for mongodb?  don't see why google-perftools should be an arch-specific b-d
[14:02] <jdstrand> pitti: hey, curious if otoh you know why if I'm building in a schroot I sometimes, but not always, see http://paste.ubuntu.com/12799014/
[14:03] <jdstrand> pitti: google didn't help me. if you don't know otoh, don't bother wasting time
[14:03] <jdstrand> it is weird though. cause I tried to build something, it failed with that. I do nothing else and try again, and it works
[14:04] <jdstrand> this has been happening for a while now. not a new thing
[14:34] <pitti> jdstrand: I think I've seen it in some bug report, but no clue I'm afraid
[14:35] <pitti> jdstrand: stracing dpkg might help, if you can reproduce it
[14:35] <jdstrand> pitti: normally I just update the schroot so it doesn't have to upgrade that package during a build
[14:36] <jdstrand> pitti: thanks
[14:36] <pitti> jdstrand: ah
[14:36] <pitti> jdstrand: might be an overlayfs bug?
[14:36] <pitti> jdstrand: I use tarball schroots, but I've never seen this in my sid schroot (which is overlayfs) either
[14:36] <jdstrand> oh
[14:37] <jdstrand> why yes: http://paste.ubuntu.com/12799337/
[14:39] <pitti> jdstrand: go overlayfs :)
[14:40] <pitti> doko: maybe; I fixed an FTBFS during the g++ migration, but that doesn't mean that I now take over maintenance of this :)
[15:11] <hallyn_> xnox: ping
[15:11] <hallyn_> (re https://mentors.debian.net/package/netcf)
[15:16] <xnox> hallyn_: yes.
[15:17] <xnox> hallyn_: again, new, or did i not do an old one?
[15:17] <xnox> ah new upstream release
[15:25] <seb128> mvo, hey, do you know what app-install-data-partner is used by/for?
[15:25] <seb128> it didn't get updated since 13.04 it seems
=== tych0- is now known as tych0
[15:33] <mvo> seb128: its so that the stuff in the canonical partner archive has icons and can be installed
[15:34] <seb128> mvo, is there a process to refresh it? should that be done or did the data not change since raring?
[15:37] <mvo> seb128: I think it should get updated - or we just drop it given that its not well maintained
=== wendar_ is now known as wendar
[15:38] <seb128> mvo, is the process to update it documented?
[15:41] <hallyn_> xnox: yeah, you'd looked at it a few days or weeks ago (time flies) but at EOD
[15:41] <hallyn_> xnox: the experimental version still FTBFS so ideally this version would just repalce it without a need for a separate fix
[15:45] <roaksoax> doko: yeah I saw that, but that made me ask the question. We were hoping on moving be moving to python3 in MAAS, but the experimental part of twisted makes us wonder whether this is a blocker or not
[15:46] <doko> roaksoax, just pretend that you don't see it. I introduced that some years ago
[15:46] <doko> waiting for free to package 15.4, and then build both python packages from the same source
[15:47] <roaksoax> doko: ok, cool!
[16:00] <mvo> seb128: its manual unfortunately
[16:00] <mvo> seb128: no automatic update script or anything, it used to be such a small number of packages that it was not worth automating
[16:57] <infinity> pitti: Any idea what's up with the systemd and apport failures?
[17:01] <xnox> hallyn_: is this upload to experimental or unstable then?
[17:02] <seb128> infinity, he wrote that earlier about the apport one
[17:02] <seb128> <pitti> seb128: I just saw it failing, no idea yet; appareantly some changes on ddebs.u.c.
[17:02] <seb128>  seb128: I hinted it for now, will look when it's not release crunch time
[17:03] <hallyn_> xnox: unstable
[17:03] <xnox> hallyn_: cool.
[17:06] <hallyn_> xnox: that'll then automatically supersede the (older) experimental version right?
[17:06] <xnox> hallyn_: si
[17:08] <hallyn_> awesome - thanks
[17:09] <infinity> seb128: Ahh, indeed, he did force apport.  I'll see if a systemd retry clears that one up.
=== willcooke_ is now known as willcooke
[17:50] <pitti> infinity: apport> ah, seb128 already quoted
[17:50] <pitti> infinity: I retried systemd, that looks like a race condition in the test
[17:50] <pitti> infinity: I already did
[17:50] <pitti> infinity: the queues are achingly long again; I requeued all regressions already
[17:51] <pitti> infinity: but with lcy01 down again it's going to take a fair while :/
[17:51] <infinity> pitti: Oh.  Yeah.  I retried too.  Not helpful, I guess.
[17:51] <pitti> infinity: so we only have 8 parallel tests now, which sucks :( (on x86)
[17:51] <infinity> pitti: And two GCC uploads means the queues will explode shortly.
[17:52] <infinity> Oh, Qt too.
[17:52] <infinity> Yay.
[17:52] <pitti> infinity: nope, I tamed gcc
[17:52] <infinity> pitti: Tamed how?
[17:52] <pitti> amd64 queue is 288, i386 queue 243
[17:52] <pitti> infinity: gcc-5 only triggers some 5 key packages now, and stuff like gcc-4.7 doesn't trigger anything at all
[17:53] <infinity> pitti: libgcc1 rdeps don't trigger anymore?  Doesn't that sort of defeat the purpose of autopkgtest?
[17:53] <pitti> infinity: the 5 key pakcages includes some libgcc rdepends
[17:54] <pitti> infinity: but there's actually not that many in main
[17:54] <infinity> pitti: Sure, but how can we be sure it's good coverage?
[17:54] <infinity> I mean, libgcc isn't as complex as libc, but there's still a fair bit that can, in theory, go wrong.
[17:54] <pitti> so, we need to know that libgcc1 isn't totally broken, for that running 10 tests or so is sufficient
[17:55] <pitti> infinity: well, give me some actual horsepower and we can switch it back on
[17:56] <infinity> pitti: Did you have more horsies before the scalingstack move?
[17:56] <pitti> infinity: well, at least two regions, i. e. 2x8
[17:56] <infinity> pitti: Were any of your build machines suitably new/beefy enough that we could ask for them to be turned into scalingstack compute nodes?
[17:56] <pitti> infinity: I hope lcy01 comes back up soon; the last time (a month ago or so) it lasted for a full week, which sucked
[17:57] <pitti> infinity: I got promised a bunch of beefy nodes a while ago, but didn't get them yet
[17:57] <pitti> anyway, /me -> back to real life, this was just a quick drive-by check if anything completely exploded
[17:57] <pitti> but http://autopkgtest.ubuntu.com/status/alerts/ looks okay
[17:58] <pitti> and not too many regressions
[17:58] <pitti> so, let's let it clear up over night/saturday
[17:58]  * pitti waves
[18:20] <luist> what Qt version is coming in 16.04?
[18:33] <dobey> lol
[18:33] <dobey> whatever version is ready by the time the freeze happens
[18:44] <infinity> luist: At least 5.4 :P
=== salem_ is now known as _salem
[22:35] <jcastro> If anyone has time to help with: https://bugs.launchpad.net/ubuntu/+source/steam/+bug/1498655 and https://bugs.launchpad.net/ubuntu/+source/steam/+bug/1498658 that would be swell!
[22:35] <ubottu> Launchpad bug 1498655 in steam (Ubuntu) "Steam Controller support: need read-write access to Valve-owned input event device nodes." [Undecided,Confirmed]
[22:35] <ubottu> Launchpad bug 1498658 in steam (Ubuntu) "Steam Controller support: need read-write access to /dev/uinput for controller emulation" [Undecided,Confirmed]
[22:35] <jcastro> bzr branches are attached