[04:23] <tsimonq2> hey everyone
[04:23] <tsimonq2> hardinfo is currently FTBFS in Yakkety, and it's the only FTBFS in the lubuntu packageset
[04:24] <tsimonq2> (at the moment)
[04:24] <tsimonq2> I've already gotten a +1 from several people here, but the fix is detailed in this email: https://lists.ubuntu.com/archives/lubuntu-devel/2016-September/000824.html
[04:25] <tsimonq2> I addressed it to Julien, our developer lead, but unfortunately he has been busy lately, so he asked me to get it sponsored
[04:25] <tsimonq2> (over FB messenger)
[04:25] <tsimonq2> so if somebody could upload this for me, that would be awesome
[04:25] <tsimonq2> have a good evening
[06:30] <Mirv> pitti: you could kill all autopkgtests that have Triggers: one of the following, as it's no longer the latest version (upstream updated their commit) http://pastebin.ubuntu.com/23249960/
[06:50] <pitti> Mirv: thanks, I think I caught all the matching queued tests now (not the running ones, too much effort)
[07:10] <ventrical> any news on the state of unity8 desktop?
[07:14] <sladen> ventrical: this is quite a broad question.  If you can narrow it down a bit, somebody like popey might be able to help you
[07:17] <ventrical> I was here yesterday and got no replies. Most testers at ubuntuforums are getting freeze ups , no libertine and no app store and a diminished apps scope with barely any useable icons
[07:32] <caribou> slangasek: well, I've just noticed that mdeslaur has updated a 0.99-2 everywhere so maybe our best choice is to get that version in Y and see if we still want to MIR tomsfastmath and do it in Z
[07:32] <caribou> slangasek: so far, the security team was not sure if they could do the MIR security review for 16.10
[07:33] <caribou> rbasak: maybe there is something you want to add to this ^^^
[07:51] <david89> Hello. Is the ubuntu sdk available for other distros other than ubuntu?
[08:08] <Mirv> david89: hi! I think it will be available as a .snap package for other distros too, but I'm not sure if there is an usable snap yet.
[08:09] <Mirv> there are some first builds done but also some bugs still that may prevent using it in a meaningful way right now
[08:10] <sil2100> Hey! Does anyone know if a package is in the Unapproved queue, can I push a new (fixed) version of it with the same version number?
[08:11] <sil2100> Since I found a small typo in an SRU I pushed, would like to fix that but I'm not sure if I should bump the version number or re-upload as the same one
[08:11] <sil2100> The package currently is still in the Unapproved queue
[08:11] <sil2100> Should I first ask someone to reject it and then re-upload?
[08:13] <sil2100> pitti, tjaalton: what do you guys think? ^
[08:13] <tjaalton> sil2100: use same version, old one will be dropped from the queue
[08:13] <sil2100> Excellent, thanks :)
[08:13] <tjaalton> which one is it?
[08:14] <sil2100> livecd-rootfs
[08:14] <tjaalton> just xenial?
[08:14] <sil2100> Yeah
[08:15] <tjaalton> ok, I'll drop the one from tuesday
[08:15] <sil2100> tjaalton: thank you
[08:15] <sil2100> Uploading the updated one
[08:19] <david89> Mirv: were can I find the alpha builds?
[08:19] <david89> Also, does the ppa work on derivatives/spins?
[08:22] <Mirv> david89: let me ask zbenjamin if there is any SDK snap downloadble anywhere, just for fun :) maybe not.
[08:22] <Mirv> david89: sure PPA should work on any official Ubuntu flavors, and probably derivatives too if they're not too .. derivative
[08:23] <zbenjamin> Mirv: there is nothing that works atm.
[08:23] <Mirv> zbenjamin: right, that's what I feared, ok
[08:25] <david89> thanks anyway!
[08:26] <david89> Apart from snap, could I possibly try building it?
[08:26] <zbenjamin> david89: sure, lp:ubuntu-sdk-ide
[08:26] <zbenjamin> david89: however you will need LXD and lp:ubuntu-sdk-tools
[08:28] <david89> zbenjamin: LXD could be a problem with my kernel, are there build instructions for the other two?
[08:29] <zbenjamin> david89: ubuntu-sdk-ide is cmake based, so mkdir build && cd build && cmake <pathtosource> && make
[08:29] <zbenjamin> david89: the other one is a Go project so you'd need to setup a Go workspace
[08:30] <david89> zbenjamin: ok, thanks. Ill see what happens
[08:31] <zbenjamin> david89: but without LXD the SDK will not be much useable. Its a core requirement
[08:31] <zbenjamin> david89: we use build containers to provide the toolchains
[08:32] <david89> zbenjamin: LXD containers?
[08:32] <zbenjamin> david89: yes
[08:32] <david89> zbenjamin: are they public?
[08:32] <zbenjamin> david89: sure, https://sdk-images.canonical.com/
[08:33] <david89> thanks again. Im building linux now
[08:34] <zbenjamin> david89: thats the script to create new images if you need it http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-sdk-ide/trunk/view/head:/dist/qtcreator/src/plugins/ubuntu/share/qtcreator/ubuntu/scripts/usdk-target-build
[08:52] <Mirv> pitti: is the akonadi s390x still in endless loop mode?
[08:52] <Mirv> it's testing a 6 day old build right now
[08:54] <acheronuk> Mirv: yofl seems not really available for the time being. do you think the release team could be persuaded to repeat what was dicussed here? http://paste.ubuntu.com/23250241/
[09:00] <Mirv> acheronuk: it totally depends on how grumpy they are :) but yes, possible.
[09:03] <Mirv> acheronuk: the more Kubuntu people can evaluate the situation yourselves the better - I mean, the autopkgtests are being run anyway and take days, the results should mean something. if it's mostly green, the red ones could be quickly glanced through to see if anything scary. if it's mostly red, then maybe there's something really problematic.
[09:07] <acheronuk> Mirv: ok. not sure any of us who are available have a great deal of a clue how to decide what is serious on those or not, but I guess if a couple of days or so we can put a case together as best we can
[09:11] <Mirv> acheronuk: to quickly get a list of stuff on excuses page that has regressions, I use wget -q -O - http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html | grep Regression | sed 's/^<li>autopkgtest for \([a-z0-9-]*\).*/\1/'| sort | uniq
[09:12] <acheronuk> Mirv: oooh. nice. :) ^^^^
[09:12] <acheronuk> ty
[10:02] <Skuggen> Are there any irc channels for snap?
[10:03] <ogra_> Skuggen, #snappy
[10:04] <Skuggen> ogra_: Thanks :)
[10:23] <tjaalton> is there a list of supported arm hw somewhere?
[11:10] <pitti> Mirv: I suppose it is, I'll kill it
[11:11] <pitti> Mirv: oh, I only blacklisted it for y, not for x
[11:17] <pitti> Mirv: I put it out of its misery now
[11:17] <pitti> sil2100: rejecting and reuploading with same version number is cleaner
[11:17] <pitti> sil2100: you can even upload it right away, and in the queue we then reject the older one
[11:25] <pitti> sbeattie: oh, don't we have a CVE pool any more?
[11:27] <pitti> sbeattie: I'm applying it to Debian, next SRU etc. now, so I wonder if there's a CVE for the changelog
[11:37] <jgdx> doko, hi, re bug 1628327, is that last comment an okay solution?
[12:11] <coreycb> hello, can an archive admin please accept python-os-api-ref from the yakkety new queue?  this is a required build-depend for openstack packages.
[12:22] <mdeslaur> caribou: if tomsfastmath doesn't get the MIR in time, you can just use the bundled one like I did in xenial. It needs a couple of patches, see the xenial package.
[12:22] <mdeslaur> caribou: I can do that for you if it gets to that
[12:22] <caribou> mdeslaur: that was my idea, just get your package into Y
[12:23] <mdeslaur> well, there are a few changes in Y worth keeping
[12:23] <mdeslaur> I'll just change the tomsfastmath part
[12:23] <caribou> mdeslaur: the delta was not that big b/w your package & my merge
[13:20] <dobey> ventrical: you got replies. apparently you just chose to ignore them. no, libertine app/tools aren't installed by default, but you can certainly just apt-get install libertine to use it. the store scope was removed for the time being as clicks are not supported on yakkety, and until we have a usable snap store. the unity8 session is a tech preview, not a finished product.
[13:51] <smoser> pitti, around ?
[13:51] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1576692 i think needs init-system-helpers let through
[13:53] <dobey> ventrical: you were also referred to #ubuntu-unity for questions about unity
[13:54] <ventrical> yes I was  and I did ..
[13:55] <ventrical> no .. I did not ignore .. I don't understand what you are talking about
[13:56] <smoser> seems http://people.canonical.com/~ubuntu-archive/pending-sru.html might be blocking init-system-helpers ?
[13:56] <dobey> ventrical: it sounds like you are expecting unity8 to be a final release product in 16.10, but it's only a technical preview
[13:57] <ventrical> no I do not expext it to be a final release .. I expect it to be a working release .. there is no place, no where where Mark had said this was a technical preview  that is just plain not correct!
[14:00] <dobey> it does work; because you only have 3 things installed that work under unity8 doesn't mean unity8 isn't working
[14:00] <ventrical> dobey  please get facts correct. We at Ubuntu Development Version Testing (U+1) have been working on Unity8  tersting under the premise that it will be a working alternate desktop for 16.10
[14:00] <ogra_> huh ?
[14:01] <ogra_> that has definitely never been said
[14:01] <ventrical> mark said it in his frist webinar .. that he had 90 people commited to working on just unity8
[14:01] <ogra_> sure ... and that there will be an ability to switch to a unity8 session to preview the state in 16.10
[14:02] <ogra_> but that an actual switch will only happen when the community agrees it is ready
[14:02] <ogra_> nobody promised "a working alternative desktop"
[14:02] <ventrical> well I certainly  would have hoped that this would have been made more clear  a while back after all the time we have put into testing it. I don't think this kind of 'teaze' is very forthright
[14:03]  * dobey also pretty sure he has "facts correct" here
[14:03]  * ogra_ doesnt understannd what you mean ... if your expectations went off, how can we help with that 
[14:04] <ventrical> sorry but I beg to differ .. however I cannot stand up to community council policies so I guess I'll just have to accept it..
[14:04] <dobey> unity8 is meant to be an alternate preview session on 16.10 ISO
[14:05] <dobey> i'm pretty sure that it was never stated or implied that it could be a total replacement for all users in 16.10
[14:05] <ogra_> yes, and it was never advertised any different
[14:05] <ventrical> hey orga .. no problem .. we are just testers ...
[14:05] <cjwatson> are you sure Mark said "90 people"?  That really doesn't sound right
[14:05] <cjwatson> 19, maybe
[14:05] <ogra_> yeah :)
[14:05] <ogra_> unless he counted snappy in ;)
[14:05] <bregma> I would certainly expect Unity 8 to be usable as a limited day-to-day desktop (browsing, playing music, editing files, tame stuff like that) and that's certainly what we're aiming for in 16.10
[14:05] <bregma> not stable, not reliable, nut usable
[14:05] <ventrical> yes he said 90 persons commited to just unity8!!
[14:05] <bregma> *but usable
[14:05] <dobey> bregma: and it's certainly usable for that
[14:06] <bregma> dobey, not in the beta release
[14:06] <ventrical> bregman.. thanks for sharing that
[14:06] <bregma> there were bugs that rendered it unusable, as you know since you;re fixing them
[14:06] <bregma> all will be well by 16.10
[14:06] <ventrical> totally unusable .. those others are using the ppa
[14:06] <cjwatson> http://news.softpedia.com/news/mark-shuttleworth-we-won-t-make-the-same-mistake-again-with-unity-8-503796.shtml quotes Mark as saying "a team of eighteen people", from the Q&A I believe you're referring to
[14:07] <dobey> well, you can play music and edit files in the browser just fine. :)
[14:07] <ogra_> hah, cjwatson found what i was llooking for since 10min :)
[14:07] <bregma> except you couldn't launch the browser
[14:07] <bregma> it was a bug, it's being fixed
[14:08] <ventrical> no .. in the ewebinar he said 90 persons.. ok .. i'm dropping it..
[14:08] <bregma> there are serious gaps in the QA process that let that bug pass
[14:08] <dobey> bregma: which bug is that one?
[14:09] <bregma> dobey, the bug in which no apps appear in the launcher
[14:09] <dobey> bregma: apps scope, or launcher?
[14:09] <ogra_> both
[14:09] <ogra_> i had it on the weekend too when testing
[14:10] <ogra_> fixed with some update on tuesday or so
[14:10] <bregma> "no way to use the GUI to launch applications" might sum it up
[14:10] <ogra_> but that didnt make beta afaik
[14:10] <dobey> ogra_: no apps in apps scope only happened after installing libertine-tools and creating a container (or if you already had one), though
[14:10] <dobey> certainly not a default install issue
[14:10] <bregma> dobey, many people use their desktops
[14:11] <ogra_> well, that might be ... i'm just telling what i saw when trying it on the weekend
[14:11] <bregma> "default install" isn't good enough
[14:11] <jgdx> mterry, hey, could you take a look at my comment for bug 1628327 ?
[14:11] <ogra_> i actually only test u8 when i'm having to reboot my laptop anyway ... because of a kernel upgrade or so
[14:12] <ogra_> and i guess many people do it like that
[14:12] <dobey> bregma: "default install" is what ISO testers test; and it pretty much is good enough for the "tame stuff like that" you mentioned. :)
[14:12] <ogra_> (apart from "popescu sorin" ... who tests every day ;) )
[14:12] <dobey> i certainly couldn't use it daily, even with fully working libertine
[14:13] <dobey> ogra_: i'm testing xenial+overlay in a kvm. (was told yakkety had issues because of mesa and such)
[14:14] <dobey> i'm pretty sure gnuserv/emacs doesn't work under mir
[14:15] <dobey> anyway
[14:15] <bregma> I think "we do a half-assed job of automated testing" is a poor excuse for doing a half-assed job of automated testing, as can be demonstrated by the fact that a critical ship-stopping bug got through on the shipped beta version of software
[14:16] <bregma> what is being done for testing right now is simply Not Good Enough
[14:16] <mterry> jgdx: if they're in main already and you can replace existing deps, that sounds great to me
[14:17] <jgdx> mterry, great, thank you for the quick reply
[14:17] <mterry> (sorry, didn't realize it was a question in the bug, rather than a statement of intent)
[14:23] <ventrical> dobey and all  here is the kink to the plenary Q&A with sabdfl. Listen closely .. he says "90" people working on unity8. Although he did say he was careful not to "overpromise" he did not say anything about a technical preview http://summit.ubuntu.com/uos-1605/meeting/22664/mark-shuttleworths-qa/
[14:25] <ogra_> ventrical, then i guess he counted snappy, phone/tablet etc into this number too
[14:25] <ogra_> in all these areas a few people work on ubity8 integration
[14:25] <ogra_> *unity
[14:25] <ventrical> bregma  we are testing the daily ISO in U+1 and there is a small group of us still testing unity8 in yakkety and xenial .. with ppa and without ppa.. the problem is that it was working really well and then evrything went south and (at least) all my installs got broke as I updated upgraded them.
[14:26] <ventrical> orga .. listen to it please he said specifically 90 people dedicated to unity8 .. unless he meant 19 .. I dunno  sure sounds like 90 to me..
[14:27] <cjwatson> ventrical: it's 50 minutes, roughly what time?
[14:27] <ventrical> I think it is over the half way mark ... I'll look see and get back ..
[14:28] <bregma> at one point we probably had 90 people working on Unity and the entire Touch stack, it seems like an historically reasonable number
[14:29] <bregma> I do not believe we have that number now as the major development push is over and the long tail begins
[14:29] <cjwatson> the thing I just heard was "for about 80 people, that is their top priority" (at about 25:30)
[14:30] <cjwatson> looking through the internal directory, my guess is that that refers to the size of the "Devices - Ubuntu Engineering" department
[14:30] <cjwatson> (it's a bit off from right now, but close enough)
[14:31] <bregma> right now, we have about 30 people for whom the new Unity 8 aegis it is their top priority and another 10 or so indirectly involved, plus support staff and management
[14:31] <cjwatson> so it's the top priority for the department, though that isn't necessarily going to translate in every single person there doing nothing but working on the unity8 codebase
[14:32]  * bregma has difficulty counting non-engineers as people sometime
[14:32] <cjwatson> anyway, I don't know that arguing about exact numbers of people is useful, bregma has already given much more informative answers about solidifying automated testing etc.
[14:33] <cjwatson> which is way closer to how this kind of thing gets better :)
[14:34] <bregma> ventrical, could you please repost the URL to the U+1 group so I can add it to my monitoring list?
[14:36] <ventrical> at point 25:00 he starts talking about unity8 .. that it will be an option (not technical preview) and that "80 people" will be working on it .. that it will be an option like gnome and MATE is for 16.04
[14:37] <ventrical> bregma  https://ubuntuforums.org/forumdisplay.php?f=427
[14:39] <ventrical> cjwatson  just at the 25:00 minute point mark starts talking about unity8. There is nothing indicating  that it will be a technical preview.  If it was we wouldn't be testing it .. we already went the preview route with lxc
[14:40] <dobey> it's always been an "option" like gnome and mate, but it's not an "option" like Ubuntu GNOME and Kubuntu and Ubuntu MATE; i think you're reading more out of what was said, than was actually said
[14:40] <ventrical> dobey .. did you actually listen to it ?
[14:40] <jbicha> it's still the intent to try to get Unity 8 on the primary yakkety iso, right?
[14:41] <ventrical> I hope so ... if not then we are jsut wasting a lot of time..
[14:41] <dobey> jbicha: yes, as a preview session
[14:41] <bregma> ventrical, it's definitely going to be a technical preview, since we know it will not have full functionality like proper multi-monitor support, but it will also be included on the ISO as an optional login session for those early adopters who wish to try it out and give feedback
[14:41] <bregma> so, in 16.10 it will not be ready for just anyone to use as their daily driver
[14:41] <ventrical> bregma    ..wow....
[14:42] <bregma> on the brave
[14:42] <bregma> *only the brave
[14:42] <ventrical> ok... thanks ..
[14:42] <ventrical> :)
[14:43] <bregma> we're working hard to get everything through the rogorous Ubuntu approval process so we can include everything necessary on the ISO, and that is taking a lot of effort and explains why it's not yet in ISO images
[14:44] <bregma> we had to get security and packaging reviews for 110 new packages
[14:44] <bregma> not all new packages pass their reviews the first time around either
[14:45] <bregma> some of them not even he second round
[14:47] <dobey> the transition to snaps and clicks being broken makes things a lot more difficult too
[14:48] <ventrical> bregma  perhaps I misunderstood Mark. He was so enthusiastic about it. I thought  .. "with 80 people  working on unity8 they are going to get this thing done"
[14:50] <bregma> dobey, indeed...  it's been a rough ride the last few weeks
[14:50] <bregma> ventrical, yes, we're getting things done but we're not there yet, and deadlines are looming large
[14:52] <ventrical> as Mark said  "I want to be running unity8 for my desktop for 16.10"
[14:53] <ventrical> bregma   no problem... my aplologies   I centianly understand these deadlines..
[14:53] <lutostag> how do I mark a package that needs to resync from debian for yakkety?
[14:53] <lutostag> https://bugs.launchpad.net/ubuntu/+source/pepperflashplugin-nonfree/+bug/1628247 in particular
[14:55] <Laney> lutostag: subscribe ubuntu-sponsors
[14:58] <lutostag> Laney: thanks. done. hope that is enough
[15:00] <ventrical> bregma  I will try to inspire what small part of the U+1 that is testing unity8 to continue testing and sending bug reports.  It was working so well in yakkety at one point without the ppa. And then to have it break like it did has been frustrating for those who have been investing our time in testing it.. bu t.. onwards and upwards :)
[15:03] <bregma> ventrical, yeah, there should be no need for a PPA in the current Ubuntu dev version, but since it's pre-release, bugs happen
[15:03] <dobey> ventrical: well, how did it break? we do have a bug reporting system. you didn't mention any specfic bugs in here :)
[15:03] <bregma> ventrical, we certainly appreciate all the testing effort you folks can do
[15:04] <dobey> well there is no overlay for yakkety, so adding it wouldn't change anything anyway :)
[15:04] <ventrical> the bugs were aready reported.. I discussed this last night in another forum
[15:04] <dobey> ventrical: is it the blank apps scope issue?
[15:05] <ventrical> yep  https://bugs.launchpad.net/canonical-devices-system-image/+bug/1627759
[15:06] <ventrical> and..  https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1628807  which is just a rant..
[15:06] <dobey> ventrical: there's one fix in yakkety-proposed for that, which should hopefully migrate today; and another issue we found that causes the same problem, has a fix in the UNAPPROVED queue right now
[15:07] <ventrical> dobey.. ok thanks .. I am advising the U+1 team to keep testing past 16.10  I am not trying to be a pain here :)
[15:12] <ventrical> ok... I boosted it up at U+1 (now UDV)  https://ubuntuforums.org/showthread.php?t=2338565&p=13551108#post13551108
[15:45] <bdmurray> mvo: Have you had a chance to look at those unattended-upgrades bugs?
[16:24] <ventrical> correction  I stated earlier that MArk stated "90" people working on unity9 when actually it sounded like "80" people. He could have said "18" and perhaps the audio was just not exactly right .. so .. my bad .. mea culpa.
[16:25] <ventrical> unity8 thats is .. hehehe unity9 .!! heheh .. geesh .. typo there but thinking ahead :)
[16:44] <nacc> jgrimm: what did you want me to look for in heimdal specifically? it's failing the tests on the three failed archs (armhf, i386, powerpc)
[16:45] <infinity> nacc: So, all 32-bit arches?
[16:45] <nacc> infinity: heh, good point :)
[16:45] <infinity> nacc: Probably a bit of a hint there.
[16:46] <nacc> infinity: good catch, thanks!
[16:47] <jgrimm> nacc,  yep, looking into what's broken there.  its been stuck in proposed for something like 87days. :)
[16:47] <infinity> Some fantastic compiler warnings in those build logs too...
[16:47] <infinity> error.c:56:24: warning: self-comparison always evaluates to true [-Wtautological-compare]
[16:47] <infinity>      if (ap->error_code == ap->error_code)
[16:47] <infinity> LOLWUT.
[16:47] <nacc> heh
[16:48] <cjwatson> uh
[16:49] <dobey> wow
[16:49] <cjwatson> volatile int error_code;
[17:00] <smb> dannf, would be nice if you could coordinate uploads to libvirt with me or cpaelzer. And btw the arm64 build seems broken...
[17:05] <ubloomto> Hello
[17:05] <ubloomto> Is there a place where overwritten files are stored on the Ubuntu OS?
[17:09] <apw> ubloomto, as in once you write new contents to the file is the old maintained anywhere ?  not in the general run of things
[17:11] <dobey> no, the file system itself is not versioned
[17:19] <apw> if you are using the file manager graphical thing it has a trashcan much how windows does
[17:19] <apw> otherwise, nothing
[17:34] <nacc> jgrimm: fyi: http://paste.ubuntu.com/23252145/
[17:34] <nacc> those are the two failing cases
[17:34] <dannf> smb: will do. the FTBFS isn't arm64 specific - it's a missing python build-dep that was made apparent by a python3 migration afaict. i have a fixed package prepared, but would you prefer i file a bug so you can merge it?
[17:35] <smb> dannf, yeah would be nice since we got a lpgit tree which we try to keep in sync
[17:36] <dannf> smb: ok
[17:36] <jgrimm> nacc, heimdal?
[17:36] <nacc> jgrimm: ack
[17:36] <nacc> jgrimm: spinning up an amd64 build to see what's different
[17:37] <jgrimm> nacc, yep cool
[17:37] <smb> dannf, I got some other things staged as well, so if you assign the bug to me I merge everything together
[17:37] <dannf> smb: ah. checked for that in debian/control before uploading, but just saw the debian repo - and didn't find an ubuntu branch there.
[17:37] <smb> dannf, not debian -> https://git.launchpad.net/~libvirt-maintainers/ubuntu/+source/libvirt/log/?h=ubuntu/yakkety
[17:37] <dannf> smb: if you give me a link, i can send you PR in the bug (but patch is fine if you prefer)
[17:38] <dannf> smb: right - just saying Vcs-Git points to debian's
[17:38] <dannf> smb: thx
[17:38] <nacc> smb: we might want to, in ubuntu, do a Xs-Debian-Vcs-Git: and Vcs-Git: for libvirt?
[17:39] <nacc> with appropriate urls for the ubuntu packaging
[17:39] <smb> dannf, whatever format is fine, I guess its simply uncommenting the commented out python  line
[17:40] <smb> nacc, guess makes sense. might add that too if I remember until tomorrow
[17:40]  * smb needs to send himself some reminder emails
[17:44] <DRamaekers> can someone help me understanding launchpad? On my laptop, the file /usr/lib/command-not-found is on version 0.3. If I browse the code on lp, its on 0.2.44. What am I missing?
[17:45] <dannf> smb: LP: #1629041
[17:45] <smb> dannf, ack. thanks
[17:46] <dannf> smb: now, i also need to SRU the previous fix (numa on arm64) for xenial. how do you want me to handle that?
[17:47] <smb> dannf, I already changed the tree to match your upload, so when doing mine I'd just cover both in the changes file. would that work for you?
[17:47] <smb> oh wait xenial
[17:47] <dannf> smb: yeah, however you wanna do yakkety is fine w/ me
[17:48] <dannf> smb: that was just the debdiff i had prepared
[17:49] <smb> dannf, I have the bug number in the yakkety branch, So I might pick that change into Xenial and upload it for you
[17:49] <dannf> smb: want a patch for updating the debian/control git link?
[17:49] <dannf> smb: ok, thx
[17:50] <smb> dannf, If you got that done already ... sure whatever way you prefer
[17:50] <sbeattie> pitti: we have a CVE pool, we can only issue them when issues are private. If they're public, like this one already was, we run the risk of a duplicate CVE assignment, which mitre really wants to avoid, so we have to wait for mitre to assign it.
[17:56] <dannf> smb: emailed
[17:57] <tsimonq2> what's the equivalent of Qt Creator for GTK?
[17:57] <mvo> bdmurray: still not, sorry, I have one more close deadline that making juggling this a bit difficult, I'm pretty sure its straightfoward though, I try again in my morning
[17:57] <tsimonq2> I'd like to fix a bug in some GTK software that would be stupidly easy to fix using Qt Creator
[17:57] <mitya57> tsimonq2, https://wiki.gnome.org/Apps/Builder
[17:58] <tsimonq2> thanks mitya57, I'll look into it
[17:58] <smb> dannf, got it. thanks
[17:59] <tsimonq2> mitya57: hmm, no debug feature? or am I looking at this wrong?
[17:59] <mitya57> I never used it :)
[17:59] <tsimonq2> oh ok
[18:00] <tsimonq2> well I'll look into it in a few hours
[18:00] <bdmurray> mvo: Okay, thanks!
[18:01] <mitya57> tsimonq2, according https://wiki.gnome.org/Apps/Builder/Planning/Graphical_Debugger it's only planned
[18:01] <tsimonq2> :/
[18:04] <infinity> nacc: FWIW, there's a patch in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822749
[18:05] <infinity> nacc: Even seems like a vaguely reasonable patch (well, the explicit cast there points to a potential bug elsewhere, but as quick fixes go, it seems reasonable)
[18:05] <nacc> infinity: thanks -- interestingly, i reproduce the failure on 64-bit too
[18:05] <nacc> or think i did
[18:05] <infinity> nacc: That seems like it would be another failure then.
[18:06] <infinity> nacc: Since the one seen on the buildds in Ubuntu and Debian was clearly "all 32-bit arches fail, all 64-bit don't"
[18:07] <nacc> oh nm, PEBKAC -- yeah, i can reproduce, i'll test that fix
[18:07] <mvo> bdmurray: sorry sorry sorry
[18:17] <dobey> anyone intimately familiar with packaging of golang stuff that uses govendor upstream to have vendored code?
[18:52] <nacc> doko: jgrimm: fyi, i got llvm-toolchain-3.6 to build (simple patch), but it fails 2 tests: http://paste.ubuntu.com/23252443/
[18:54] <nacc> i'm not sure i know how to resolve them, though :)
[18:58] <doko> nacc, jgrimm: port clamav to 3.9, and don't care anymore about 3.6 ;p
[18:59] <nacc> heh
[18:59] <nacc> is that the only reason we have llvm-toolchain-3.6 in main?
[19:00] <nacc> yeah, i guess it's libclamav7
[19:01] <doko> nacc: yes, only package
[21:06] <pitti> sbeattie: ah, that makes perfect sense, thanks
[21:37] <pitti> niedbalski, sbeattie: I followed up to bug 1628687 with pointers to the improved patches; doing the sid/yakkety fixes now
[21:38] <pitti> presumably you want to do the followup via -security as well now, as it's a local DoS
[21:43] <nacc> infinity: fyi, that patch didn't seem to fix i386, at least
[22:50] <jamespage> doko_, I have no idea as to why but the tweak to the build process you did for libunwind makes ceph hang:
[22:50] <jamespage> https://bugs.launchpad.net/ubuntu/+source/libunwind/+bug/1629102
[22:50] <jamespage> I did a quick revert test to confirm
[22:52] <doko_> jamespage: is this amd64 only?
[22:52] <jamespage> doko_, I've not tried on any other archs yet
[22:52] <jamespage> but yeah - it impacts amd64
[22:53] <jamespage> doko_, its quite easy to repro in a schroot
[22:55] <jamespage> I suspect that it does impact amd64 only
[22:55] <jamespage> libunwind8-dev [amd64] (gperftools)
[22:56] <jamespage> doko_, I guess that could be limited to arm64 ?
[22:56] <jamespage> (the flag enablement)
[22:56] <doko_> well, maybe, if it doesn't break on arm64
[22:59] <jamespage> doko_, libunwind is not used by ceph on arm64 - ceph-mon commands run OK
[22:59] <jamespage> (checked on porter)
[23:00] <doko_> fortunately people requesting that change sit beneath me ... let me check
[23:01] <jamespage> doko_, are you at linaro connect perchance?
[23:01] <doko_> yep
[23:26] <doko_> jamespage: does it get fixed when you rebuild ceph against the new libunwind?
[23:34] <nacc> jgrimm: so debian may be removing heimdal https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837728
[23:39] <nacc> jgrimm: it seems like debian is at least moving the rdep packages to be |'d with other suitable packages. Obviously late in Y for this, but one of their reasons is this lack of buliding (and lack of upstream response)
[23:48] <nacc> jgrimm: infinity: sigh, ran the failing heimdal test manually (after it failed during build) and it passed
[23:52] <doko_> jamespage: hmm, ceph doesn't have any direct dependency on libunwind ...
[23:58] <nacc> doko_: fyi, python-docutils ftbfs appears to be https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837618
[23:59] <nacc> has a patch, but not yet accepted, do you want me to test it, or should we wait for debian?