=== anthonyf is now known as Guest33778
=== salem_ is now known as _salem
=== marcusto_ is now known as marcustomlinson_
=== marcustomlinson_ is now known as marcustomlinson
[05:09] <pitti> mhall119: that sounds a bit like our merge-o-matic?
[05:09] <pitti> Good morning
[05:10] <pitti> infinity, Laney: can we please ignore the broken tests for linux 4.0.0-2.4 as well?
[05:12] <infinity> pitti: It's broken for other reasons, we're not letting it migrate right now.
[05:13] <infinity> pitti: But if you want to ignore it for something waiting on it, sure.
[05:13] <pitti> infinity: ok; but it blocks other packages
[05:13] <infinity> pitti: Fixing.
[05:13] <pitti> infinity: cheers!
[05:33] <pitti> jdstrand: I'm merging libseccomp2 again (it's rather trivial), I need Debian's -2 to unbreak separate /usr; I hope you don't mind?
[05:38] <sarnold> pitti: that's almost certainly fine, the last changelog entry looks like there's not many local changes remaining
[05:39] <pitti> sarnold: no, just adding the autopkgtest
[05:39] <pitti> and the only change in -2 is to move the library from /usr to /lib
[05:39] <sarnold> pitti: at least, jdstrand's usually good about keeping his changelogs precise and accurate :)
[05:39] <pitti> sarnold: yes, and the patches.u.c. diff agrees with him :)
[05:40] <sarnold> pitti: are the 'new' library paths still covered by the apparmor <abstractions/base> file?
[05:40] <pitti> sarnold: oh, do we do per-library paths in apparmor? /me checks
[05:40] <pitti> grep -r seccomp /etc/apparmor*  → no hits
[05:40] <sarnold> pitti: not usually.. I ust wanted to make sure that these weren't going someplace unexpected :)
[05:41] <pitti> no, just the standard /lib/x86_64-linux-gnu/ (or whatever the architecture is)
[05:41] <sarnold> pitti: how have I been here nearly three years and never seen patches.ubuntu.com??? this is awesome. thanks. :)
[05:41] <pitti> like libc.so.6 or libdbus and stuff
[05:41] <pitti> sarnold: heh -- it's a by-product of MoM (merges.ubuntu.com)
[05:43] <sarnold> this is cool, I've thought before that relying upon the changelog to keep track of the ubuntu/debian delta was prone to mistakes. this is great :)
[05:44] <pitti> sarnold: but you did see MoM, I hope? that also gives you both diffs
[05:44] <sarnold> pitti: I think I've only ever seen the summary universe.html and so on there..
[07:11] <dholbach> good morning
[07:13] <dkessel> good morning dholbach
[07:16] <dholbach> hey dkessel
[07:22] <dholbach> mitya57, did you upload ubuntu-packaging-guide already?
[07:23] <mitya57> dholbach, oops, I forgot :/
[07:23] <mitya57> Will do now :)
[07:23] <dholbach> awesome, thanks!
[07:51] <mitya57> dholbach, uploaded (will be in NEW queue though)
[07:52] <dholbach> thanks a lot mitya57!
[07:52] <mitya57> Sorry for forgetting :)
[07:52] <dholbach> no worries :)
[08:05] <infinity> pitti: What's the state of the art on reproducing adt failures locally?
[08:05] <pitti> infinity: hasn't changed in a long time -- easiest is to use the qemu runner
[08:05] <pitti> infinity: http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
[08:06] <pitti> infinity: the biggest difference is the internet proxy that we (have to) use in production
[08:06] <pitti> otherwise it's pretty much exactly the same
[08:06] <infinity> pitti: Kay.  Can I run a single test there, or will it just run everything in debian/tests/control unconditionally?
[08:06] <pitti> infinity: you can use --testname to run a single test
[08:06] <infinity> pitti: Shiny.  Thanks.
[08:06] <pitti> adt-run --testname mytest1 mysrc
[08:07] <pitti> infinity: and usually you want -s too
[08:07] <pitti> (--shell-on-failure)
[08:07] <infinity> pitti: I think I had all this going at one point, then new laptop happened.
[08:07] <pitti> infinity: well, it's really just one "adt-buildvm-ubuntu-cloud" command away :)
[08:08] <pitti> infinity: and yeah, getting new laptop beats destroying a throwaway VM any time :)
[08:08] <infinity> Apparently, cloud-images.ubuntu.com is connected to the internet with a bendy straw.
[08:09] <pitti> oh, is it slow for you?
[08:09] <infinity> pitti: Around 1MB/s, looks like.
[08:09] <infinity> pitti: So, slow for me.
[08:09] <pitti> up to vivid it was reasonably fast here, then in April/May it was ridiculously slow, and now it magically fixed itself again to be as moderately-fast as before
[08:09] <pitti> infinity: so, best not to look at it :)
[08:10] <infinity> A watched image never downloads?
[08:17] <Odd_Bloke> infinity: Are you connected to the VPN; I've sometimes seen image downloads routed through that.
[08:17] <Odd_Bloke> s/the VPN/the Canonical VPN/
[08:17] <Odd_Bloke> Which is obviously sloooow.
[08:17] <infinity> pitti: If I'm just experimenting with debian/tests, I assume I want something like '--unbuilt-tree foo-1.2.3-1 -B'?
[08:18] <infinity> Odd_Bloke: Yeah.  Until we fix it to allow me to be connected to both endpoints, that's probably my issue.
[08:18] <infinity> Odd_Bloke: I do occasionally forget I have that issue, though. :P
[08:19] <pitti> infinity: put the -B before (it only applies to the next test argument), but in principle yes
[08:19] <pitti> infinity: I usually use something like "adt-run ./ --- qemu ...", typing laziness
[08:19] <pitti> infinity: <dir>/ is an abbreviation for --built-tree <dir>
[08:19] <pitti> and <dir>// for --unbuilt-tree <dir>
[08:20] <pitti> greetings from iwj from 9 years ago :)
[08:23] <infinity> pitti: Hahaha.
[08:28] <infinity> pitti: FWIW, --testname isn't documented in the manpage.
[08:31] <infinity> pitti: Erm, and my first derp.  Clearly this isn't performing exactly how prod does...
[08:31] <infinity> Source Package Version: 4.0.0-2.4
[08:31] <infinity> Running Kernel Version: 3.19.0-20.20
[08:31] <infinity> ERROR: running version does not match source package
[08:32] <pitti> infinity: man> thanks, fixed in http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=16eb56eac
[08:33] <pitti> infinity: well, production gets called on a source package; I assume your test that does this comparison is newer than the binaries in wily?
[08:33] <pitti> infinity: i. e. if your --built-tree is newer, you also need to include the newer .debs in the adt-run to run against those instead of wily's binaries
[08:33] <infinity> pitti: I'm running against a source package that matches the binaries in wily-proposed.  Which means the testbed needs to upgrade and reboot.  Which I assume it does in prod.
[08:34] <pitti> infinity: or enable proposed
[08:34] <infinity> pitti: proposed is enabled on the commandline.
[08:34] <pitti> infinity: yes, that's mentioned on http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
[08:34] <infinity> Oh, wait, maybe I missed -U
[08:34] <infinity> Let's see if that fixes it.
[08:35] <pitti> infinity: yes, --apt-pocket only adds the apt source, doesn't run apt-get
[08:36] <infinity> pitti: Yeah, bad copy-pasta on my part.
[08:36] <infinity> Ahh, lovely.
[08:36] <infinity> adt-run [02:36:44]: rebooting testbed after setup commands that affected boot
[08:36] <infinity> That looks more promising.
[09:20] <mardy> mvo: hi! Do you have some minutes to help me investigate bug 1454210?
[09:20] <ubottu> bug 1454210 in webapps-sprint "accounts are lost each time the app is updated from the store or run on the device from qtc" [High,Triaged] https://launchpad.net/bugs/1454210
[09:23] <mvo> mardy: let me have a look
[09:27] <mvo> mardy: that bug is confusing, so it only removes evernote accounts but nothing else? click does not touch userdata (yet) on upgrade. it will stop the app though
[09:29] <mardy> mvo: so, we have a click hook in OA, which has a pattern to copy some files to ~/.local/share/online-accounts-hooks/
[09:30] <mardy> mvo: then we have a hook processor which reads these files and generates a more elaborated version under ~/.local/share/accounts/providers/
[09:30] <mardy> mvo: this hook processor also takes care of removing stale files and accounts, when the corresponding app gets removed
[09:31] <mardy> mvo: the way it works, is that it scans ~/.local/share/accounts/providers/, and then it tries to find the corresponding originating file in ~/.local/share/online-accounts-hooks/
[09:31] <mardy> if it doesn't find it, then it deduces that the app has been removed, and therefore removes the file in ~/.local/share/accounts/providers/ and any created accounts
[09:32] <mardy> mvo: does this sound correct to you? ^
[09:32] <mardy> mvo_: did you miss some lines?
[09:32] <mvo_> mardy: sorry, network issues, the last I got was "seconds)
[09:32] <mvo_> <mardy> mvo: this hook processor also takes care of removing stale files and accounts, when the corresponding app gets removed"
[09:32] <mardy> mvo_: ok, I'll repaste
[09:32] <mardy> mvo_: the way it works, is that it scans ~/.local/share/accounts/providers/, and then it tries to find the corresponding originating file in ~/.local/share/online-accounts-hooks/
[09:33] <mardy> mvo_: if it doesn't find it, then it deduces that the app has been removed, and therefore removes the file in ~/.local/share/accounts/providers/ and any created accounts
[09:33] <mardy> mvo_: does this sound correct to you? ^
[09:33] <mardy> mvo_: the files are named after the short app id (that is, without the version number)
[09:34] <mvo_> mardy: yes, makes sense
[09:34] <mvo_> mardy: so one fix would be for click to behave differently I guess - I need to look first why its doing what its doing
[09:34] <mardy> mvo_: mmm... actually, wait... the hook pattern we use keeps the version number
[09:35] <mardy> mvo_: ok, I guess that I have something to fix there, I should try to match the unversioned file
[09:35] <mvo_> mardy: ok, thanks. let me know how it goes and good luck :)
[09:35] <mardy> mvo_: ok, if you don't here from me, then all it's good on your side :-)
[09:36] <mvo_> :)
[09:36] <mvo_> ok
[09:46] <jamespage> please could an archive-admin merge lp:~james-page/+junk/sync-backlist-openstack into the sync backlist - some updates for openstack projects
[09:47] <jamespage> thanks
[09:51] <cjwatson> jamespage: I remain confused why we're blacklisting these at all.
[09:51] <cjwatson> jamespage: Surely we have "ubuntu" substrings in our versions.
[09:52] <jamespage> cjwatson, I'm happy just to drop them all tbh - I just tripped on trying to sync a client package from debian
[09:52] <jamespage> cjwatson, you are quite correct - they would always show as a merge
[09:54] <jamespage> cjwatson, ok I've dropped all openstack packages from my branch - ok to go with that?
[09:54] <cjwatson> jamespage: The only one there might be any justification for would be openstack-meta-packages
[09:54] <cjwatson> jamespage: Do you want that to pop into wily?
[09:55] <jamespage> cjwatson, let me check on openstack-meta-packages
[10:24] <infinity> jamespage: openstack-meta-packages probably conflicts conceptually with the "openstack" package that I'm waiting on stokachu to reupload.
[10:25] <infinity> jamespage: It doesn't actually conflict, but I imagine confusion if we ship both.
[10:38] <jamespage> infinity, ok - lets leave that blacklisted still - I think it relies on a load of features in the debian versions of those packages we don't support in ubuntu
[10:40] <jamespage> infinity, cjwatson: lp:~james-page/+junk/sync-backlist-openstack updated
[10:43] <caribou> Q: When adding an upstart job to an existing package, does the sysVinit script get automatically inhibited or we need to add the 'init_is_upstart' override ?
[10:44] <ogra_> caribou, for what release ?
[10:44] <caribou> ogra_: Trusty
[10:44] <ogra_> upstart is gone (for system statup)
[10:44] <ogra_> ah
[10:44] <caribou> ogra_: yeah, I know it's for a Trusty SRU
[10:45] <caribou> ok, I think I found the answer :
[10:46] <caribou> when the package is installed with an upstart job, the sysVinit script is installed but not enabled
[10:47] <caribou> I'll put the override, in case someone enable the script by accident
[10:47] <cjwatson> jamespage: merged; give it 5min or so to propagate before you try syncpackage again
[10:47] <cjwatson> caribou: You should follow https://wiki.ubuntu.com/UpstartCompatibleInitScripts
[10:48] <caribou> cjwatson: thanks for the URL
[10:52] <jamespage> cjwatson, thankyou
=== soee_ is now known as soee
=== MacSlow is now known as MacSlow|lunch
=== _salem is now known as salem_
=== MacSlow|lunch is now known as MacSlow
[12:42] <rbasak> infinity: around? docker.io backports incoming. Preview in https://launchpad.net/~docker-maint/+archive/ubuntu/staging/+packages - do you want me to just throw all of this at the SRU queues?
[12:42] <rbasak> infinity: bug is https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1454719 - shall I create a task for each package being backported?
[12:42] <ubottu> Ubuntu bug 1454719 in docker.io (Ubuntu Vivid) "docker.io update to 1.6.1" [Wishlist,Triaged]
=== anthonyf is now known as Guest64410
[12:48] <infinity> rbasak: Should be tasks for everything, yes.
[13:12] <rbasak> infinity: OK bug updated and everything is in the queue now
[13:13] <infinity> rbasak: Ta.
[13:32] <LocutusOfBorg1> Hi Folks, I see libjsoncpp still in universe pocket, is it normal?
[13:32] <LocutusOfBorg1> talking about bug 1461517 and comment #3
[13:32] <ubottu> bug 1461517 in libjsoncpp (Ubuntu) "[MIR] libjsoncpp" [Undecided,Fix committed] https://launchpad.net/bugs/1461517
[13:33] <LocutusOfBorg1> there is a serious bug against libjsoncpp and I merged in Debian the relevant delta
[13:33] <LocutusOfBorg1> so I would like to ask a plain sync ASAP
[13:33] <LocutusOfBorg1> but I don't know how this deals with the MIR request
[13:34] <infinity> LocutusOfBorg1: I'll have a look at both.
[13:34] <LocutusOfBorg1> infinity, it's almost dinstall time in debian
[13:34] <LocutusOfBorg1> so the sync is not possible (yet) I guess ;)
[13:34] <LocutusOfBorg1> thanks!
[13:34] <doko> wgrant, stealing your ustr merge
[13:35] <mhall119> pitti: I'm not familiar with merge-o-matic
[13:35] <infinity> LocutusOfBorg1: Where's this new cmake that the MIR talks about?
[13:35] <LocutusOfBorg1> -proposed I guess
[13:36] <infinity> Oh, so it is.
[13:36] <LocutusOfBorg1> https://launchpad.net/ubuntu/+source/cmake/3.2.2-2ubuntu1
[13:36] <infinity> component-mismatches-proposed isn't showing the promotion.  Grr.
[13:36] <LocutusOfBorg1> (I feel guilty for the cmake merge, this is why I'm bothering so much :p )
[13:37] <infinity> LocutusOfBorg1: Guilt is a good motivator.
[13:37] <LocutusOfBorg1> :)
[13:37] <LocutusOfBorg1> and the love for cmake is a good motivator for a merge
[13:38] <infinity> LocutusOfBorg1: Tell me more about this "broken shlibs file" fixed in -4...
[13:38] <infinity> LocutusOfBorg1: Is it so broken that we don't want things building against -3?
[13:39] <infinity> LocutusOfBorg1: Should I remove it from -proposed?
[13:39] <LocutusOfBorg1> yes, exactly
[13:39] <LocutusOfBorg1> that would be awesome
[13:39] <LocutusOfBorg1> it isn't generating the shlibs:depends correctly, so packages built against libjsoncpp-dev won't depend on libjsoncpp0
[13:40] <infinity> LocutusOfBorg1: Oh, that's quite unfortunate.  Do we know if anything's been built with that breakage so far? :/
[13:40] <LocutusOfBorg1> please look at the debian bug in -release
[13:40] <LocutusOfBorg1> I can do something similar for ubuntu
[13:41] <LocutusOfBorg1> anyway I guess the answer is "nothing"
[13:42] <infinity> LocutusOfBorg1: If you could check the rdeps and see if anything was built against the broken version, that would be great.
[13:42] <infinity> LocutusOfBorg1: Hopefully, the answer is no, but best to know.
[13:42] <infinity> LocutusOfBorg1: And I've removed it from -proposed for now.  -4 can be synced when LP learns about it.
[13:43] <LocutusOfBorg1> sysdig is built against the old jsoncpp
[13:43] <LocutusOfBorg1> thanks
=== rickspencer3_ is now known as rickspencer3
[13:46] <infinity> LocutusOfBorg1: sysdig is broken on ARM anyway, can kill two birds with one stone by just deleting it and waiting for a new Debian sync that fixes that. :P
[13:48] <infinity> LocutusOfBorg1: Anything else?
[13:50] <LocutusOfBorg1> much stuff built against the old version
[13:50] <LocutusOfBorg1> kopete was a lucky case, uploaded the day before libjsoncpp, but I looked at all the build logs and they are fine (picked up the old one everywhere)
[13:52] <infinity> LocutusOfBorg1: Just so I'm sure I'm parsing that correctly: the only broken package was sysdig, then?
[13:52] <LocutusOfBorg1> no
[13:52] <infinity> LocutusOfBorg1: Which I've just removed wholesale, since it was FTBFS on ARM anyway, so meh.  No need to rebuild it.
[13:53] <LocutusOfBorg1> broken is anything depending on 0.10.2-1+
[13:54] <LocutusOfBorg1> and nothing is built against it
[13:54] <LocutusOfBorg1> many packages are built against the old 0.6 who was fine
[13:54] <infinity> LocutusOfBorg1: Okay, that's what I said. :)
[13:55] <LocutusOfBorg1> I just had a trouble for kopete, uploaded on the day before, but it built quickly
[13:55] <LocutusOfBorg1> and with the old version
[13:55] <LocutusOfBorg1> so I guess syncing it, and MIRing it would be fine
[13:55] <infinity> LocutusOfBorg1: MIR already sorted.
[13:55] <infinity> LocutusOfBorg1: Can sync when LP knows what's up.
[13:56] <LocutusOfBorg1> so now cmake starts building?
[13:56] <infinity> Should do soon, yeah.
[13:56] <infinity> Assuming it can build against 0.6
[13:56] <infinity> (If it can't, it should have a versioned build-dep, which it doesn't, so...)
[13:57] <LocutusOfBorg1> wow, yes, actually I built and tested against 0.6
[13:57] <LocutusOfBorg1> I got the trouble because my ppa had universe enabled
[14:00] <LocutusOfBorg1> the only problem is actually than the old jsoncpp wasn't versioning correctly
[14:00] <LocutusOfBorg1> infinity, is that a problem?
[14:01] <LocutusOfBorg1> bug 1218220
[14:01] <ubottu> bug 1218220 in libjsoncpp (Ubuntu) "[MIR] libjsoncpp" [Undecided,Won't fix] https://launchpad.net/bugs/1218220
[14:01] <LocutusOfBorg1> this is why I was trying to merge the new one
[14:02] <pitti> Laney: in case you are interested, the udisks2 regression is tracked in bug 1466081
[14:02] <ubottu> bug 1466081 in systemd (Ubuntu) "[udev] no uevent when block devices change" [High,Triaged] https://launchpad.net/bugs/1466081
[14:02] <infinity> LocutusOfBorg1: I don't recall what I meant by that, since it was two years ago...
[14:03] <LocutusOfBorg1> it was lacking of a sane versioning ABI
[14:03] <infinity> LocutusOfBorg1: Okay, well, it's still libjsoncpp0, I don't see how that solved the problem. :P
[14:03] <LocutusOfBorg1> and this is fixed with the new one, I would like to cancel cmake builds and wait for the new jsoncpp, but you are the boss, not me :)
[14:04] <LocutusOfBorg1> this is "fixed" because upstream tracks ABI changes closely now
[14:04] <LocutusOfBorg1> http://upstream.rosalinux.ru/versions/jsoncpp.html
[14:07] <doko> tracking ABI changes closely and keeping the soversion?
[14:10] <LocutusOfBorg1> yes, I should bother them to bump the soversion
[14:10] <doko> infinity, can you do the dpkg merge?
[14:11] <jdstrand> pitti: re seccomp, I don't mind at all. merge away :)
[14:13] <pitti> jdstrand: ack :)
[14:13] <jdstrand> pitti: fyi, I also did submittodebian on the autopkgtests and I'm discussing that with Debian
[14:14] <pitti> jdstrand: yes; I asked kees yesterday and he seemed to think the nature of these tests is more like "upstream test suite", not a package integration one
[14:15] <infinity> doko: Yeah, I think 1.18.1 has probably cooked enough by now.
[14:15] <jdstrand> yes, he does. I think he is right about some but not all :) we'll figure it out
[14:17] <LocutusOfBorg1> is cmake https://launchpad.net/ubuntu/+source/cmake/3.2.2-2ubuntu1 still building on armhf?
[14:17] <LocutusOfBorg1> I'm getting oops
[14:20] <infinity> LocutusOfBorg1: LP bug.  Under investigation. :P
[14:20] <infinity> LocutusOfBorg1: I might have hit a button too hard.
[14:22] <LocutusOfBorg1> is that your hand? http://ecx.images-amazon.com/images/I/41fXAZENBZL.jpg
[14:43] <doko> pitti, could you have a look at https://bugs.launchpad.net/ubuntu/+source/sessioninstaller/+bug/1440368 ? or find somebody from desktop (although this is foundations)
[14:43] <ubottu> Ubuntu bug 1440368 in sessioninstaller (Ubuntu) "sessioninstaller should be ported to Python3" [Undecided,New]
[14:48] <Laney> pitti: thanks for looking, seems like a real real regression - yay for tests
[15:27] <cjwatson> LocutusOfBorg1: DB row fixed, that build is (I'm told) intentionally cancelled.
[15:35] <barry> slangasek: https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1324391/comments/19  (thanks bdmurray!)
[15:35] <ubottu> Ubuntu bug 1324391 in python-pip (Ubuntu Trusty) "pip 1.5.4 import an invalid dependencies " [High,Fix committed]
[15:36] <hyperair> hi. could someone let banshee into vivid-updates please? the bug has been marked verified-done for a while now
[15:37] <bdmurray> looking
[15:41] <LocutusOfBorg1> yes cjwatson it should be cancelled, thanks!
[15:43] <bdmurray> hyperair: its been released
[15:43] <hyperair> yay thanks
=== zumbi_ is now known as zumbi
[15:44] <hyperair> bdmurray: launchpad doesn't seem to have updated yet though
[15:48] <cjwatson> hyperair: https://launchpad.net/ubuntu/+source/banshee/+publishinghistory -> pending publication
[15:48] <hyperair> ah, thanks
[16:13] <LocutusOfBorg1> infinity, syncpackage libjsoncpp ?
[16:14] <LocutusOfBorg1> still not good
[16:14] <infinity> syncpackage: Error: Debian version 0.10.2-4 has not been picked up by LP yet. Please try again later.
[16:14] <LocutusOfBorg1> requestsync doesn't show the error
[16:14] <LocutusOfBorg1> but syncpackage does
[16:14] <infinity> LocutusOfBorg1: It does if you pass -V
[16:14] <LocutusOfBorg1> strange
[16:14] <infinity> Oh, requestsync.  I never use that, for obvious reasons.
[16:15] <infinity> And it might be buggy with rmadison returning multiple versions in unstable.
[16:15] <infinity> I was just knee-deep in that code a couple of days ago, perhaps I should dive back in.
[16:16] <LocutusOfBorg1> infinity, some hours ago it was failing at the begin with "ubuntu has an higher version", now seems to go a little after
[16:16] <LocutusOfBorg1> syncpackage: D: Source package libjsoncpp is temporarily blacklisted (blacklisted_current). Ubuntu ignores these for now. See also LP: #841372
[16:16] <LocutusOfBorg1> syncpackage: Source libjsoncpp -> wily/Proposed: current version 0.6.0~rc2-3.1ubuntu1, new version 0.10.2-4
[16:16] <ubottu> Launchpad bug 841372 in Launchpad itself "Incorrect auto-blacklisting in DSD?" [Low,Triaged] https://launchpad.net/bugs/841372
[16:16] <LocutusOfBorg1> I see it there https://launchpad.net/debian/+source/libjsoncpp/0.10.2-4
[16:17] <LocutusOfBorg1> lol I asked at the same time
[16:17] <LocutusOfBorg1> now should be fine
[16:18] <infinity> synced.
[16:18] <LocutusOfBorg1> <3
[16:19] <LocutusOfBorg1> the whole borg community thanks you
[16:20] <ogra_> LocutusOfBorg1, i thinnk he'd be happy with only 7of9 :)
[16:20] <infinity> ogra_: But why rule out 1 through 6?
[16:20] <LocutusOfBorg1> ogra_, I would be happy too :D
[16:23] <ogra_> haha
[16:28] <pitti> arges: oh, you are doing SRU today?
[16:28] <arges> pitti: yes... why? : )
[16:29] <pitti> arges: could we release utopic/vivid for bug 1461425 today? there's already the next round of updates in bug 1464669
[16:29] <ubottu> bug 1461425 in postgresql-9.4 (Ubuntu Vivid) "New upstream microreleases 9.1.17, 9.3.8, 9.4.3 - fixes regression in previous update" [Undecided,Fix committed] https://launchpad.net/bugs/1461425
[16:29] <ubottu> bug 1464669 in postgresql-9.4 (Ubuntu Vivid) "New upstream microreleases 9.1.18, 9.3.9, 9.4.4" [Undecided,In progress] https://launchpad.net/bugs/1464669
[16:29] <pitti> sorry about that, this was a bit crazy
[16:29] <pitti> shold be back to one update every 3 months now
[16:30] <arges> pitti: ah perfect i see you went through the jenkins 'failures'. I'll work on releasing that then reviewing the next round
=== Elimin8r is now known as Elimin8er
=== tarpman_ is now known as tarpman
[16:54] <pitti> arges: cheers!
[17:00] <LocutusOfBorg1> pitti, do you think libjsoncpp is good for a cmake rebuild?
[17:00] <LocutusOfBorg1> I mean, rebuilding cmake should pick the proposed one, right?
[17:01] <cjwatson> I don't think the new binaries are entirely published yet; at least rmadison doesn't show them
[17:01] <cjwatson> But once they are, a rebuild will pick them up
[17:03] <LocutusOfBorg1> automagically?
[17:03] <LocutusOfBorg1> seems it is restarted
[17:04] <seb128> stgraber, hey http://iso.qa.ubuntu.com/user/register?destination=qatracker "Have you forgotten your password?" points to http://iso.qa.ubuntu.com/user/password which is invalid
[17:04] <cjwatson> LocutusOfBorg1: I don't know what you mean by automagically.  Builds in -proposed fetch build-dependencies from -proposed.
[17:05] <seb128> stgraber, do you know what would be the right url to use?
[17:05] <seb128> also I'm trying to log through sso and it tells me that a seb128 user already exist
[17:05] <cjwatson> Hopefully whoever retried those builds checked.
[17:05] <LocutusOfBorg1> it was on "build cancelled" state, do the retry happen automatically?
[17:05] <cjwatson> LocutusOfBorg1: No, only manually.
[17:06] <LocutusOfBorg1> ack thanks
[17:06] <stgraber> seb128: it's all Ubuntu SSO, no local accounts
[17:07] <stgraber> seb128: and yeah, we can't disable those links, the best we can do is make them fail
[17:07] <cjwatson> LocutusOfBorg1: The master site has the new versions at the moment, so it's hopefully OK.
[17:08] <seb128> stgraber, well, sso fails telling me that "The name seb128 is already taken."
[17:08] <stgraber> seb128: ok. We had that happen ocasionally with old accounts, I can nuke your account in the DB which will solve that, just need to reown the data you have in the DB first
[17:08] <seb128> stgraber, I guess I've an account from the before sso time but I don't remember the password
[17:08] <seb128> stgraber, thanks
[17:09] <stgraber> manually doing the SSO link is something I haven't figured out yet, so nuking the old account is easier :)
[17:09] <stgraber> well, I could also rename the old account, that should work
=== salem_ is now known as _salem
[17:09] <seb128> you can nuke it as far as I'm concerned
[17:10] <stgraber> seb128: try now
[17:10] <Laney> stgraber: after you fix his account, can you see why the rebuild I just requested failed? :)
[17:10] <Laney> (see the email)
[17:10] <Laney> perhaps it needs tweaking to do a cron.preinstalled build or something
[17:10] <seb128> stgraber, "
[17:10] <seb128> Error message
[17:10] <seb128> The e-mail address seb128@ubuntu.com is already registered. Have you forgotten your password?"
[17:11] <stgraber> damn, let me change that too :)
[17:11] <seb128> ;-)
[17:11]  * Laney screams at the rain - washing is out
[17:11]  * Laney runs
[17:11] <stgraber> seb128: try now
[17:12] <seb128> stgraber, works! thanks ;-)
[17:12] <stgraber> Laney: looking
[17:14] <stgraber> Laney: desktop next I assume?
[17:14] <Laney> oui
[17:14]  * Laney is damp
[17:15] <stgraber> ok, so I see 3 requests (one for each product) 10min ago
[17:16] <stgraber> DB state is 3 which means, built according to nusakan but not published yet
[17:16] <Laney> I got failure emails
[17:16] <stgraber> ah, must have removed them without reading them, can you bounce them back to me?
[17:17] <infinity> LocutusOfBorg1: cmake seems to have happily built against the new libjsoncpp.  Cheers.
[17:17] <LocutusOfBorg1> cheers!
[17:17] <Laney> stgraber: It needs to have SUBPROJECT=system-image and run cron.daily-preinstalled
[17:18] <Laney> (bounced)
[17:19] <infinity> Curiously, it tried to build them on the old livefs builders instead of on LP.
[17:19] <infinity> Didn't even know that codepath still existed.
[17:30] <stgraber> infinity: yeah, still happens when there's no LP project setup in the config
[17:30] <stgraber> likely to fail horribly as we drop those old builders though :)
=== _salem is now known as salem_
=== tlyu_ is now known as tlyu
[18:18] <dobey> does anyone know how to do the equivalent of "python3 -m testtools.run discover" using python3-covearge?
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== TheMaster is now known as Unit193
[20:25] <pitti> LocutusOfBorg1: sorry, what about libjsoncpp? (I have no idea about C++ or cmake, what was the problem there?)
[20:59] <infinity> pitti: It's all sorted.
[21:01] <infinity> pitti: Also, I fixed the linux autopkgtests.  Merry Christmas.
[21:01] <pitti> infinity: I saw, great job!
[21:02] <infinity> pitti: The best part was that after I fixed it all, I noticed Brad had (most of) the same changes staged in another branch he just hadn't gotten around to merging.
[21:02] <infinity> pitti: So, yay for duplicated work. ;)
[21:02] <pitti> erk
[21:02] <infinity> (This is really, really, really not our week for kernel stuff)
[21:03] <pitti> utlemming: wrt. bug 1262951, I noticed that this is incompatible with what Debian's ifupdown now does: they include all files in /etc/network/interfaces.d/ which *don't* have a suffix, and that cloud specific change only includes *.cfg files
[21:03] <ubottu> bug 1262951 in Ubuntu "cloud-images /etc/network/interfaces shoud source-directory interfaces.d" [Medium,Fix released] https://launchpad.net/bugs/1262951
[21:03] <pitti> utlemming: what would I report this against?
[21:04] <infinity> pitti: I'd guess cloud-init and curtin, at least, probably use that facility.
[21:04] <infinity> pitti: And the only sane way forward would be to merge the two behaviours, including no-suffix and *.cfg, but nothing else.
[21:04] <infinity> pitti: IMO.
[21:05] <pitti> yeah, I guess so; I. e. additionally have the source-directory /etc/network/interfaces.d/ which Debian does
[21:05] <infinity> Cause trying to mangle things on upgrade might end in tears.
[21:06] <pitti> one doesn't usually dist-upgrade cloud instances, so that shouldn't be such a big deal
[21:07] <pitti> (i. e. mangling /etc/network/interfaces)
[21:07] <infinity> pitti: Lots of people dist-upgrade cloud instances.
[21:08] <infinity> pitti: If you're not a hip and cool "my whole life is ephemeral" cat, starting with a cloud image and dist-upgrading is perfectly reasonable.
[21:08] <infinity> pitti: But also, I'd be willing to bet curtin uses the same bits (maybe not, but worth a check), and maas+curtin for base installs is generally less cloudy.
[21:09] <pitti> well, at least appending that line to /e/n/i on upgrade is not that big of a deal, but as it isn't really owned by any package it still bears the question where to put that
[21:09] <pitti> (ifupdown presumably)
[21:10] <infinity> pitti: Oh, if it's only included in the config file, not a default include in the source, it might be just as valid to just start doing this on new installs only.
[21:10] <infinity> pitti: It's not like old installs will (as a general rule, anyway) start growing new interfaces that people expect to configure that way?
[21:11] <infinity> pitti: But, YMMV, I dunno.
[21:11] <pitti> yeah, hence my original question what to report this against -- is that cloud-init? or some cloud-image-builder-thingy?
[21:11] <pitti> the bug above is against "Ubuntu"
[21:11] <infinity> pitti: Probably cloud-init has the affected code.
[21:11] <infinity> pitti: And maybe curtin, like I said.  And who knows what else.
[21:11] <infinity> d-i uses interfaces snippets now too, I thought.
[21:13] <infinity> Yeah, d-i does, and also writes out 'source /etc/network/interfaces.d/*'
[21:13] <infinity> Which seems like neither of the behaviours you described...
[21:14] <infinity> netcfg (1.127) unstable; urgency=medium
[21:14] <infinity>   * Add support for /etc/network/interfaces.d/ by adding a "source"
[21:14] <infinity>     directive (Closes: #770078). It can be replaced with a
[21:14] <infinity>     "source-directory" one during the next release cycle.
[21:14] <infinity> netcfg (1.127) unstable; urgency=medium
[21:14] <infinity>   * Add support for /etc/network/interfaces.d/ by adding a "source"
[21:14] <infinity>     directive (Closes: #770078). It can be replaced with a
[21:14] <infinity>     "source-directory" one during the next release cycle.
[21:14] <infinity>  -- Cyril Brulebois <kibi@debian.org>  Sun, 04 Jan 2015 22:48:47 +0100
[21:14] <infinity> Oops, stutter paste.
[21:16] <infinity> pitti: So, netcfg in Debian hasn't caught up to the new world order.  d-i still sources *, rather than source-directory.
[21:16] <infinity> pitti: In conclusion, this is all a bit of a mess right now.
[21:17] <pitti> yay consistency
[21:18] <infinity> pitti: So, I think the right answer here is "hunt down all installers, and change what they do"... What ifupdown does is irrelevant, since 99% of the time, it's not writing interfaces(5)
[21:18] <infinity> pitti: And if it's trying to change any old config files on upgrade, that would be massively wrong.
[21:19] <infinity> Also, yes, yay consistency.
[21:21] <infinity> netcfg still appears to write everything to interfaces(5) too.  It could really use a rewrite to write per-interface to the .d directory.
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== sergiusens_ is now known as sergiusens
=== pgraner is now known as pgraner-afk
[23:29] <hallyn> do-release-upgrade -d -f noninteractive.  should work?
[23:32] <sarnold> hallyn: are you hitting this? https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1452238
[23:32] <ubottu> Ubuntu bug 1452238 in apt (Ubuntu) "Failed to upgrade system from 14.04" [Medium,Confirmed]
[23:33] <hallyn> sarnold: nah, nothing so drastic.  it just isn't being noninteractive, sits and waits for me to hit y/enter/ several times.
[23:33] <sarnold> ahhhhh