[00:50] tedg: "##SELECTION_END##"? [00:50] sarnold: ? [00:50] tedg: your comment on https://bugs.launchpad.net/bugs/1613420 [00:50] Launchpad bug 1613420 in Snappy "no way to run daemons on user session " [Undecided,New] [00:51] Huh, wonder what happened there. [00:52] tedg: are you using evolution? https://codesearch.debian.net/search?q=%23%23SELECTION_END%23%23 -- evo's the only hit in debian's archive.. [00:52] sarnold: Interesting, it is in the plain text copy of the e-mail, but not the html version. [00:53] sarnold: Yeah, evolution === salem_ is now known as _salem [05:42] Good morning! /me resurfaces from summer holidays [06:02] hey pitti! how are you? :) [06:08] tsimonq2: I'm great, thanks! well-relaxed after vacations [06:20] infinity: hey Adam, how are you? I fixed some tests and hints from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#glibc yesterday, but there's some remaining ones which might be actual issues [06:24] infinity: cjs, linux-raspi2, log4cxx, umbrello in particular, although some of them might also be due to a new compiler; the others are unrelated and can be hinted once these four get investigated === ljp is now known as lpotter [08:51] tseliot, pitti, could you make ubuntu-drivers-common stop build-depending on python3-aptdaemon.pkcompat in yakkety? it's a nbs binary now [08:59] seb128: I'm updating all the metas after mangling the seeds, so you can ignore those r-recommends. [09:02] infinity, was not going to bother about the recommends but thanks! [09:02] I'm looking at fixing the real depends though [09:03] infinity: We're seeing yakkety build failures because of sagari's old kernel. Do I need to re-upload our hack-around for that to our build PPA, or might you be able to upgrade that kernel soonish? [09:04] Odd_Bloke: Is trusty's new enough? [09:04] infinity: I _think_ so. [09:04] Odd_Bloke: I'll file a ticket. [09:05] Yeah, https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums suggests it landed in 3.6. [09:07] Oh, but we didn't do LTS backports on all arches in precise. That started in trusty. Grr. [09:07] * infinity doesn't file the ticket. [09:08] Odd_Bloke: Unfortunately, the solution is going to be to either upgrade sagari entirely or pull it out of rotation. Less fun. [09:09] Oh, that sucks. :( [09:12] Odd_Bloke: I'll pull it out of rotation for now, but no guarantees it'll stay that way if the queues get deep. [09:14] infinity: OK, thanks. We can cope with it being in rotation if there's a queue, because we're less likely to get scheduled on it. :p [09:16] Odd_Bloke: Heh. I'll throw some hours later at parallelising my current builders a bit more to make it a non-issue. [09:16] infinity: Thanks. <3 [09:21] seb128: this would break installation of graphics/wifi drivers, so this needs to be entirely rewritten (it doesn't work with packagekit as that doesn't support plugins and thus WhatProvides()) [09:21] urg [09:22] Laney, cyphermox, ^ [09:22] pitti, well, we went ahead with the packagekit1.0 transition and cyphermox deleted pkgcompat from aptdaemon [09:22] unsure how that migrated if it breaks ubuntu-drivers-common though [09:23] oh, it's only a Suggests [09:23] seb128: language-selector as well; dist-upgrade now wants to remove these two and ubuntu-desktop [09:23] shrug [09:23] how did that migrate [09:26] and why is language-selector not on http://people.canonical.com/~ubuntu-archive/nbs.html ? [09:27] oh, I misread [09:27] it depends on python3-aptdaemon.widgets [09:27] not on the compat one [09:27] ah, right; so that one is still okay? [09:27] yes [09:27] it's only the packagekit compat layer that got removed [09:27] in favor of using packagekit directly [09:28] I need to check what software-properties uses, the PackageKit what-provides API or the UbuntuDrivers module directly [09:28] since the apt backend there is judged better maintained [09:28] in the former case this needs to be ported [09:28] k [09:28] pitti, thanks [09:29] pitti, why is dist-upgrading wanting to remove language-selector? [09:29] it should [09:29] ubuntu-drivers-common only suggests the compat binary [09:29] * pitti boots VM again, hang on [09:30] seb128: I get http://paste.ubuntu.com/23060985/ === vrruiz_ is now known as rvr [09:31] pitti, what happens if you "apt-get install sessioninstaller system-config-printer-gnome ubuntu-desktop"? [09:31] "already the newest version" of course, but with aptdaemon I get [09:31] aptdaemon: depends p3-aptdaemon, breaks: p3-aptdaemon.pkcompat [09:31] oh, right [09:32] add p3-aptdaemon ? [09:32] oh, that's better [09:32] http://paste.ubuntu.com/23060994/ [09:33] so it seems apt rather wants to remove l-s & co than install packagekit [09:33] right, the "right" solution is not scored enough :-/ [09:33] I guess we need to move the aptdaemon dependencies to packagekit? [09:34] could be [09:34] seb128: what's the plan now, is aptdaemon obsolete entirely in favor of PK, or just the pkcompat bits? [09:34] i. e. will sessioninstaller & co move to PK directly? [09:34] I can do that, it's an alternative depends atm but we should just remove the first option [09:35] no plan afaik, nobody is really working on that stack [09:35] :/ [09:35] but we wanted to unblock packagekit1.0 because we were on an old unmaintained version [09:35] * pitti rips out the PK plugin from u-d-common [09:36] ideally things would use packagekit directly and we remove aptdaemon [09:36] ok [09:36] but it doesn't hurt to keep using it until somebody has cycles to work on that [09:36] which doesn't seem to be the case atm [09:37] well, the what-provides plugins of l-s and u-d only work with aptdaemon's pkcompat plugins, so they can go [09:37] aptcc doesn't have plugin support [09:37] the apt PK backend used to, but AFAIK it's gone [09:38] a shame really, the plugin concept of PK is really nice and the whole point of using the PK abstraction in the first place [09:38] yeah :-/ [09:38] are we going to see a feature regression in l-s and u-d? [09:39] u-d itself is fine, need to check software-properties which has the actual UI for driver installation [09:39] but if so, it woudl already be broken [09:39] k [09:39] need to go for some errands and lunch, bbiab [09:44] wow, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-drivers-common is 77 days old [09:44] I now have a package that builds again, running autopkgtests [09:46] pitti: great, so that I can finally add a few changes that I was planning to make to u-d-c :) [09:47] seb128, tseliot: uploaded [09:47] :) [09:47] tseliot: including teh xenial SRU, I guess :) [09:48] seb128: are you going to unseed it? [09:48] pitti: yes, I might revert that change, and go with a lighter approach (which might give us the same results) [09:49] tseliot: which change? [09:49] pitti: the fix for the performance issue in gpu-manager [09:49] I need to check if the alternative solution I have in mind is as good though [09:51] seb128: software-properties doesn't use the PK interface, thus should be fine [10:10] Hi,when root partition is full, and i delete some files,but it is the same,is there some people met the same ? [10:12] yanku: This channel is for the development of Ubuntu itself (e.g. discussing packaging). Your question is more suited to #ubuntu (if you're on a desktop) or #ubuntu-server (if you're on a server). :) [10:49] juliank: Heya, I changed the patch to now only take is_like from os_release, the other values come from lsb_release https://github.com/apachelogger/python-apt/commits/aptsources-distro-os-release so it should be fully backwards compatible. I did add a TODO note about the need for behavior change though [10:55] oh pitti is back, welcome! [10:59] hey Mirv, thanks! [11:04] pitti: Can debian/tests/control take [arch] specifiers in Depends:? [11:04] xnox: o/ Any plans to backport https://bugs.launchpad.net/launchpadlib/+bug/1471927 to xenial? [11:04] Launchpad bug 1471927 in launchpadlib "AccessToken.from_string() crashes on python3" [Undecided,Fix committed] [11:04] infinity: yes, anything that apt can parse [11:04] pitti: Kay. Just adding gcc/binutils/linux-libc-dev [linux-any] to the glibc deps, so they land in Test-Triggers. [11:05] pitti: Though, irksome that I need gcc-6, since gcc isn't from gcc. :/ [11:05] One more place to update. Maybe I can generate that. [11:06] Odd_Bloke, once i upload the fix ups, i guess i could. [11:06] Odd_Bloke, do you want SRU, or would you be happy with a xenial-backports upload? [11:07] * xnox .o( pip3 install lp:launchpadlib ) [11:07] xnox: Why wouldn't you SRU? [11:07] good point [11:10] :) [11:11] xnox: I've had problems (the specific nature of which I cannot recall) installing launchpadlib with pip previously; is it expected to work (and currently working)? [11:13] at the moment trunk > packages > pip, in terms of # of fixes. [11:13] Ah, I guess I was installing from PyPI with pip, rather than trunk. [11:15] It was out of date on PyPI for a while, but I uploaded a less archaic version there recently. [11:21] sitter: Great, I'll take a look later [11:22] greetings pitti ! i just wanted to poke you about the status of the systemd upstart thing for ubuntustudio.. i don't have a lot of technical knowledge about it tbh. so i wonder about how it will affect the audio apps and such. i guess my question is: how is the timeframe looking? [11:23] sakrecoer: sorry, what does "systemd upstart thing" mean? [11:23] oh, you mean running the ubuntustudio session under systemd? [11:23] that shouldn't affect audio apps at all, just a question of getting more robust services with better logging [11:24] pitti: sorry, yes that is what i ment. [11:24] ok. sounds fair :) [11:24] thank you, pitti [11:24] time frame> I'm working on netplan ATM which is higher prio, so I might have a look in September [11:24] sakrecoer: but there shouln't be any breakage with current ubuntustudio yakkety, is there? [11:24] (or regression) [11:25] pitti: september sounds great. i don't know if there are any breakages, that is why i was hopeing we would get some time before release to try everything :) [11:28] thank you pitti for your answer and time! bye for now :) o/ [11:30] pitti: http://paste.ubuntu.com/23061299/ [11:30] pitti: That seem like a reasonable approach? [11:31] infinity: nice! [11:31] infinity: oh, do we use gcc-6 now? that might explain some of the new glibc regressions [11:31] ah, so we do [11:31] pitti: We do. It explains the linux-raspi2 one, for sure. [11:31] pitti: Lots of new warnings, and that's building with -Werror. [11:32] I like the misleading-indentation warning. [11:32] oh yes, that's awesome [11:33] what are we doing with python3-aptdaemon.pkcompat as seen on https://people.canonical.com/~ubuntu-archive/nbs.html [11:33] xml/domtestcase.cpp:193:117: error: narrowing conversion of ‘194’ from ‘int’ to ‘log4cxx::logchar {aka char}’ inside { } [-Wnarrowing] [11:33] infinity: ^ this (log4cxx) also looks gcc related then, not libc [11:34] jbicha: Unwinding the rdeps and then nuking it. [11:34] infinity: and umbrello is also a C++ incompatibility, not glibc [11:34] infinity: thus I don't see any real glibc regressions; time for force-skiptest? [11:34] infinity: or do you want to let it bake longer? [11:35] infinity: so I can/should just drop it from ubuntu-gnome's seed? [11:35] it blocks a fair bunch of other packages in -proposed [11:35] pitti: I don't think baking will do much good, if the tests look reasonable. [11:35] jbicha: Already done. [11:35] infinity: agreed; ok, hinting [11:35] jbicha: And uploaded meta. [11:35] pitti: Besides, I will be doing another upload and resetting all the tests to zero. :P [11:35] ubuntu-drivers just landed too (wrt. pkcompat removal) [11:35] infinity: cool, thanks [11:35] infinity: my minions will be pleased! [11:37] infinity: btw, britney doesn't look at Testsuite-Triggers: yet, but that's reasonably high on my list [11:39] Laney: when is a good time for me to do the evolution 3.22 transition since I believe it collides with the qt transition? bug 1613291 [11:39] bug 1613291 in evolution-data-server (Ubuntu) "Update evolution stack to 3.22" [Wishlist,In progress] https://launchpad.net/bugs/1613291 [11:40] pitti: Yeah, I figured it didn't yet, but never hurts to be prepared. :) [11:41] pitti: I'm kinda hoping we can do something approximating The Right Thing with this to fix the kernel testing mess. Or make it less messy, anyway. [11:41] infinity: indeed not, and with this I can take out some hardcoded triggers [11:41] jbicha: When it migrates, just the kernel left AFAICT [11:42] pitti, unseed the pkgcompat binary? infinity did(is doing?) that [11:43] jbicha: I pinged #ubuntu-kernel earlier but no reply yet [11:43] Laney: thanks [11:44] Laney: The kernel is tied up in the Qt transition? [11:44] Laney: How or why would that be? [11:45] linux-tools. Hrm. [11:47] Laney: linux-tools doesn't depend on Qt, what else got pulled into this mess? [11:49] binutils [11:49] Well, isn't that lovely. [11:49] It's zooper dooper [11:50] FWIW, I see a couple more non-kernel packages there. [11:50] perf-tools-unstable, qbittorrent, btfs [11:50] Anyone knows which app I need to run to have the com.canonical.AppMenu.Registrar dbus service? [11:50] Oh, p-t-u just depends on linux-tools [11:51] I don't see qbittorrent and btfs those in the autohint I'm looking at [11:52] There's one which includes it in the hint [11:52] shemgp, it doesn't work like that, what are you trying to do? [11:53] Ahh, I missed the bigger block. [11:53] nod [11:53] shemgp, on unity it's unity-panel-service which owns the name [11:53] apw: Are you back from vacation yet? [11:54] Who needs a kernel anyway [11:54] let's just remove it [11:54] *smirk* [11:55] If libbfd actually had sane versioning, this wouldn't be an issue. [11:55] Friggin' binutils. [11:55] If we removed the kernel, we'd also be able to close out pretty much all other bugs as unreproducible. [11:55] So that's another positive. [11:56] seb128: I'm tinking of creating a global menu widget for gnome 3. Do I need to run my own dbus service then? [11:56] Laney: FWIW, this is the major metric the kernel team will use to decide if we can let it in: http://people.canonical.com/~kernel/status/adt-matrix/yakkety-linux-meta.html [11:56] Laney: Feel free to examine missing or regressions and figure out why. :P [11:57] infinity: Is the baseline usually good? [11:57] Laney: Well, you can compare to previous versions there. [11:58] Oh right, the columns, derpy [11:59] is this meant to correlate to excuses? [11:59] shemgp, try talking to tedg when he's online (should be in the next hour or so) but you you can probably build an extension around indicator-appmenu [11:59] because it's saying some things are regressions that excuses calls always failed === _salem is now known as salem_ [12:02] Laney: Excuses lies, that's why this exists. [12:02] Laney: Due to hacks involved for moving triggers around from linux to linux-meta, britney doesn't keep history correcly for those tests currently. [12:07] tseliot: Any idea why nvidia-304 hates kernel 4.6, and if that can be fixed in a jiffy? [12:08] seb128, okay. Thanks for the pointers. [12:08] infinity: I thought I had already fixed that. What's the error this time? [12:08] shemgp, yw! [12:08] tseliot: Unsure, the autopkgtest just says it didn't install. [12:08] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/n/nvidia-graphics-drivers-304-updates/20160813_022829@/log.gz [12:09] tseliot: Oh wait, that's 304-updates, not 304. [12:10] tseliot: You just need to bump updates to match, it looks like. [12:10] infinity: I thought had an admin remove 304-updates from the archive [12:10] *tjalton had [12:10] tseliot: The archive disagrees. [12:11] infinity: I can make transitional packages in 304 for -updates, and get rid of the problem [12:11] tseliot: Sure, that works too. [12:12] * infinity was never quite sure what the updates packages were for anyway... [12:12] infinity: they're all going away :) [12:12] Is that just insurance, so users can roll back? [12:12] it was but not any more [12:12] * infinity nods. [12:12] Good riddance to them, then. [12:12] yep [12:12] So, we can ignore that test failure, if you're killing 304-updates. [12:16] tedg, I'm trying to add global menus to gnome 3. I already run unity-panel-service so that I can get the using menus from gdbus but not all apps are showing their menus returned. What am I doing wrong? [12:19] Laney: I've got Tim looking at iscsitarget, and rerunning all the missing tests. [12:19] Laney: Odds are, we'll be good to go later today. [12:20] infinity: 'k, thanks [12:20] tseliot: Oh, and there's some urgency on that 304-updates think, so if revving it to match 304 is the faster solution before you EOD (I imagine that's trivial), just do that, and kill *-updates later. [12:20] Let's hope nobody uploads anything that ruins it all in the meantime [12:20] * Laney deactivates everyone's upload rights [12:20] tseliot: Cause I don't want people using -updates to suddenly be broken when the kernel migrates. [12:23] pitti: The libnih test on s390x seems well and truly hung. You might want to hit it with a bat. [12:34] infinity: I blacklisted it yesterday as it keeps on running forever; for some reason this manages to circumvent the timeout (on all arches) [12:35] pitti: As if I needed more motivation to remove scottware from the archive. [12:35] pitti: Death to nih and upstart. [12:35] infinity: i. e. this is a case of "needs reproducing locally and investigating", just not at the top of my list [12:35] hm, what's holding back glibc [12:36] skipped: glibc (517, 64, 7) [12:36] got: 167+0: a-54:a-14:a-16:i-16:p-19:p-15:s-33 [12:36] Oh. It needs some migration. I'll do that. [12:36] * amd64: apitrace, apitrace-gui, apitrace-tracers, bro, broctl, dante-client, libdsocksd0, libnss-db, libsocksd0, libsocksd0-dev, unscd [12:36] Yeah. I'll fix those. [12:36] They use private symbols, need a rebuild on major version bumps. [12:36] do we have some libc6 (<= something) deps? I don't see any on e. g. apitrace [12:36] I usually wait until output.txt reminds me of the list. :P [12:37] pitti: apitrace-tracers [12:37] oh, apitrace-tracers [12:38] Every once in a while, I do a "why are you using private symbols, you fools" pass, but the current list looks mostly like they have valid excuses. [12:38] Anyhow, will upload rebuilds for all of those after I get back with my coffee. :P [12:38] s/upload/test and then upload/ [12:39] thanks [12:52] tedg, I guess my query now is: How do I make, for example, the menu of gnome-terminal hide so that when I show the menu in the global menu it's not duplicated? Thanks. [13:00] infinity: sure [13:00] pitti: Actually, looks like doko beat me to the rebuilds, so something else to unwind here... [13:01] pitti: Hahaha. And that makes glibc end up in the Qt block. :) [13:02] oh gawd [13:02] pitti: So, back to "need to get the kernel moving". [13:02] has that still not landed [13:02] pitti: The kernel is the last bit. [13:02] Working on it. [13:02] wow, how did we intertwine Qt with the kernel? [13:03] pitti, binutils upper version deps [13:04] Yeah, that. [13:04] doko: My kingdom for properly-versioned binutils shared libs. [13:05] infinity: remember, only ever give away half of your kingdom [13:05] I find it entertaining that binutils, of all things, is the project that can't sort that out. [13:05] so that you can do it arbitrarily often instead of just once :) [13:05] pitti: http://www.smbc-comics.com/comic/2011-02-10 [13:06] haha [13:07] pitti: Yes, that one's a bit of a sad "haha" for me, given how true it rings. [13:09] pitti: Oh, on the upstart-removal front, is cgmanager still a useful thing in our systemd world? And, if so, is the libnih dep part of the design, or a side-effect of upstart support? [13:10] infinity: the main thing that still uses it is ubuntu-app-launch, which tedg will port [13:10] and qtmir build-depends on it, not sure what it does with that as it doesn't binary-depend on it [13:11] pitti: Yeah, I was just talking to him on #-release, where you seem to be missing. [13:11] * pitti blames proxy restart after holidays [13:11] pitti: And he seems less convinced about it being a near-term goal. [13:11] lxc-android-config also depends on it, also unsure why [13:11] I don't think we can drop Upstart from U8 until we drop vivid. [13:14] tedg: Dropping vivid would be LOVELY. [13:14] +1000 [13:14] tedg: But even without doing so, I don't find "we're triple-landing, so the code can't fork" to be a compelling argument. [13:15] tedg: yakkety can't be hamstrung by vivid. [13:15] preacher, choir [13:15] if we are triple-landing anyway, why doesn't xenial work as a basis for touch again? [13:15] pitti: gcc5 broke things [13:15] just because of the changed C++ ABI? (as solving that would be much easier than what we do now) [13:16] dobey: really, we are dragging along vivid *just* because of that? [13:17] wouldn't it be so much easier to upload a gcc-defaults to the xenial overlay that switches back to g++ 4.9 and rebuild the 20-odd packages that are part of the app ABI? [13:17] no [13:18] infinity: I don't think you're gonna find a lot of disagreement from engineers on those points, and I'm hoping management is moving on them as well. But today, in practice, we are hamstrung by vivid. [13:18] much of it is not only used on the phone, and the issue wouldn't be limited to just "things supported by the SDK" [13:18] tedg: well, some things could be made optional during build/runtime [13:19] Sure, but we'd be effectively increasing the QA surface area then. Which isn't really a win. [13:19] I suspect xenial upgrades would just need to be a flag day with forced app updates to match. Isn't this exactly what versioned frameworks are for? [13:19] We could also have different branches for each release to land into. Also a PITA. [13:20] tedg: I have different branches for all my packages. [13:20] tedg: I'm not sure why we decided that was unhip for a certain section of the archive. [13:20] dobey: you mean there are apps which link to C++ libraries outside of the SDK? I thought click apps mustn't do that [13:20] (I know that we break our own rules, but I thought that was just for us, not for third-party apps) [13:20] (But if you'd like me to keep landing new upstream versions of glibc to precise and trusty, sure) [13:21] infinity: It's hard to maintain when you're landing features in all of them. If some are bug fix and one is features that's not too bad. [13:21] pitti: i mean, not everything is a click app, and the SDK is not self-contained. [13:21] dobey: right, but the others are ubuntu debs which are already rebuilt against the new API and have proper binary dependencies [13:21] err, ABI [13:23] pitti: right, but to do what you suggested, we'd need to pull a lot more stuff into the overlay PPA, and rebuild everything against 4.9, but then that breaks the plan of moving to snaps, which will all be built with gcc5 ABI, too [13:23] I don't think reverting gcc is remotely sane, no. [13:23] But I still can't grasp why framework versions don't cover this. [13:23] well, that's what we effectively do, just with dragging along a whole release in addition [13:24] with triple landing, the overlay just turns into vivid with g++4.9 over time.. [13:24] err, "into yakkety" [13:24] infinity: well, they sort of do. it just means we wouldn't have any framework versions on 16.04, and so no apps will be installable from the store [13:24] pitti, reverting the ABi in a xenial ppa doesn't solve the problem though, it just move it to the next upgrade and make us get more clicks built against an abi we are trying to move away from [13:24] it basically forces all developers to repackage their apps at that point [13:25] if frameworks were chroots that provide ABI or something, sure, but that's not how they are [13:25] it seems easier to me to maintain gcc-4.9 in x/y than the whole of vivid, but *shrug* [13:25] I guess the root problem is indeed the lack of an upgrade path for apps [13:26] pitti: for values of the phone images, those two statements are roughly equivalent [13:26] and there are no plans to build phone images off yakkety at all, ever, afaik [13:26] right, and they shouldn't be -- but xenial for sure [13:27] pitti, right, but xenial might move to arm64 or new android and they want to do one transition in that case and not do one for gcc and then another for a new arch [13:27] pitti: but "maintain xenial for the phone" and "maintain vivid for the phone" are pretty much equivalent, if we're rebuilding all the bits of xenial with 4.9 ABI in the PPA; probably worse because then we have to deal with conflicts against the gcc5 versions in the upstream archive [13:29] dobey: ask tedg about fun with too old cmake :) and we have to keep a whole lot of infra running for it too, like ddebs or autopkgtests [13:29] dobey: Sure, I get that it would force an app update, but our store isn't that amazingly populous, is it? Can we not reach out and JFDI? [13:31] pitti: yes, it sucks. but it is what it is, and we have to deal with it [13:32] infinity: i don't recall the numbers, and i'm not important enough to make such decisions anyway. i'm sure there's more to it than just the gcc5 break, but the gcc5 break is certainly a big thing. [13:34] shemgp: Hey, so for GNOME3 you'd probably be better off chatting with desrt. Apparently not in this channel :-) Try #ubuntu-desktop [13:34] tedg, thanks. [14:14] tseliot: Still around? [14:15] tseliot: I've made an executive decision that, to unblock this kernel, I'll just upload 304-updates with the 4.6 patch. You can worry about getting rid of *-updates and such in a more stately and well thought-out fashion instead of under pressure. Deal? [14:17] infinity: yes, it's not EOD yet [14:18] infinity: as you prefer, I was working on it [14:18] tseliot: Heh. S'ok, I'd rather not rush you to do all the removals and transitionals and such. Take your time. [14:18] tseliot: I'm uploading the synced 304-updates now. :) [14:18] infinity: ok, good [15:02] is anybody else's sbuild started to fail? [15:03] gpg: Warning: not using 'Sbuild Signer' as default key: No secret key [15:03] hence it fails to sign dummy archive Release file =( [15:09] xnox: In yakkety? [15:09] infinity, not quite. I think we want to backport http://metadata.ftp-master.debian.org/changelogs//main/s/sbuild/sbuild_0.70.0-1_changelog to xenial [15:09] because thanks to gpg now gpg2, the sbuild-keys no worky anymore with "xenial host -> yakkety/unstable chroots" [15:10] unless the ascii armored keys are used as in 0.70 [15:10] * xnox upgrades quickly. [15:10] I just moved the contents of /var/lib/sbuild/apt-keys/ out of the way and then all was well [15:10] ha [15:11] Oh, and I need to change all my overlays to overlay from overlayfs... [15:11] La la la. [15:22] infinity: can we mark wily as obsolete in LP now? [15:23] pitti: Almost. Sorry, I keep getting distracted from my kernel cleaning script writing. [15:23] some LP builders are still on wily [15:23] cjwatson: I don't see why that should matter, LP builders already pull from a PPA. [15:23] cjwatson: We won't remove it from ftpmaster/archive, just close it. [15:24] if you think we can realistically get kernel security updates in there ... [15:25] cjwatson: We're not getting kernel security updates regardless of the state of the archive. [15:26] cjwatson: The kernel team stopped when they were meant to. [15:29] Ah, OK [15:32] cjwatson: As for the hypothetical "what if we need to update the kernel", PPA should be fine, since we don't boot signed kernels on those instances. [15:32] yeah, this is true [15:32] I really hope somebody figures out why xenial makes those systems very sad though [15:32] cjwatson: Things seem to be getting worse instead of better. [15:33] cjwatson: 4.2 was kinda unstable, 4.4 is really vile, 4.6 doesn't boot. [15:33] cjwatson: So, I assume 4.8 will take your dog out back and shoot it. [15:33] and I don't even have a dog [15:33] cjwatson: I know, but I couldn't bring myself to s/dog/cat/ in that sentence. [15:59] infinity, kees: TB meeting? [16:00] slangasek: If you insist. [16:09] infinity: Thanks for updating ubuntustudio-meta. Was actually just about to do it myself. [16:10] zequence: I did some seed changes to many flavours, and decided to just respin all the metas and see what fell out. :P [16:11] infinity: Oh, ok. Well, thanks anyway :) [16:12] zequence: NP. [16:49] tedg: ah an explanation :) https://mail.gnome.org/archives/commits-list/2016-May/msg06756.html [17:02] bdmurray: maliit-framework has ~phablet-team as a bug subscriber. A team that might make sense for further MIR'd packages too. Might be worth adding to the package-subscribers script? Doesn't seem to be a comparable team there, covering Touch in general [17:02] Or at least the upper levels of touch (there is a phonedations team) === JanC is now known as Guest86015 === JanC_ is now known as JanC [18:04] Hi, I´m looking for some help to fix this bug in Ubuntu 14.04. https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/1398569 is this the right place for it? [18:04] Launchpad bug 1398569 in schroot (Ubuntu) "overlayfs: handle v3.18 overlay union type" [Medium,Fix released] [19:13] tinoco: Why is bug 1570678 verification-done when there is not testing info re: xenial? [19:13] bug 1570678 in percona-cluster (Juju Charms Collection) "mysqld got signal 11 during setting up root password on package installation on ppc64el" [High,Confirmed] https://launchpad.net/bugs/1570678 [19:13] bdmurray: checking [19:15] bdmurray: i've asked final user to verify xenial but he made a comment that he verified - again - trusty.. [19:15] that is why i got confused, my bad [19:16] i'll seek for verification again, no ppc machines for me to test unfortunately [19:16] tinoco: no problem, I wanted to make sure I wasn't missing something [19:26] coreycb: openstack-trove in xenial-proposed still needs bug 1516471 verified fwiw [19:26] bug 1516471 in openstack-trove (Ubuntu Wily) "systemd init scripts not setting correct conf file" [High,Triaged] https://launchpad.net/bugs/1516471 [19:27] bdmurray, ok I'll take a look, thanks [19:32] Mirv: qtbase5-dev-tools seems to have dropped qdoc in yakkety-proposed. Is that intentional? [19:47] Ah, it's now in qttools5-dev-tools === Elimin8r is now known as Elimin8er [21:08] ups, i guess i need to MIR golang-github-coreos-pkg === salem_ is now known as _salem === dax is now known as barista === barista is now known as dax [22:45] slangasek: can you upload nplan 0.7 for xenial to the snappy-dev ppa? [22:46] slangasek: would it make it any easier for you if i uploaded it to some ppa first? (all i'm doing is dch -D xenial -r 'rebuild for Xenial') [22:46] mwhudson: please go ahead and upload it to the ubuntu-image ppa, then I'll just copy-package it [22:47] slangasek: ok, done [22:49] mwhudson: and copied [22:50] slangasek: thanks [23:11] Laney: what am I supposed to do with this? aptdaemon stuff http://paste.debian.net/789960/ [23:31] jbicha: Hrm, would be nice is packagekit was being pulled in there by apt. :/ [23:31] s/is/if/ [23:33] infinity: ok, I'll add pk to ubuntu-gnome-desktop for today [23:33] jbicha: It's already in the task. But maybe it needs to be an explicit dep of the meta to smooth the transition, indeed. [23:33] If so, gnome won't be the only one with that problem. [23:34] And maybe it belongs in desktop-common. [23:34] or I can let you take care of it :) [23:34] Heh. [23:34] Yeah. [23:34]