[06:08] <pitti> Good morning
[06:10] <tsimonq2> o/ pitti, how are you?
[06:10] <pitti> quite fine, thanks! how about you?
[06:12] <tsimonq2> great :)
[06:23] <pitti> stgraber: is there some way to pass extra parameters to pid 1 with lxd? (just for testing locally -- something utterly hackish is totally okay)
[06:25] <pitti> stgraber: alternatively, passing env variables (SYTEMD_LOG_TARGET and friends) would work as well
[06:29] <sarnold> pitti: environment.* may work https://github.com/lxc/lxd/blob/master/doc/configuration.md
[06:30] <pitti> sarnold: oh, useful! thanks
[06:31] <sarnold> I could have sworn i'd seen the "command line" there somewhere but perhaps I imagined it..
[06:35] <pitti> you can set profile key/vals on the "launch" command line, I haven't seen config yet
[06:35] <pitti> anyway, will try in a few mins
[07:35] <LocutusOfBorg> can anybody with some mesa/GL/dpkg-update-alternatives knowledge help me a few seconds?
[07:51] <Saviq> pitti, morning, for some reason these excuses have no results for unity8, any idea? https://requests.ci-train.ubuntu.com/static/britney/ticket-1525/landing-076-xenial/excuses.html
[08:14] <pitti> Saviq: I'm afraid not; this needs a verbose britney log from robru to see what happens
[10:10] <pitti> smoser, stgraber: I think I found something in bug 1602192
[10:11] <flexiondotorg> rbasak, If you're able can you look at the mate-hud sponsoring request please - https://bugs.launchpad.net/ubuntu/+bug/1602270
[10:20] <pitti> apw: do we have someone in the kernel team who is reasonably familiar with inotify, for bug 1602192?
[10:35] <rbasak> flexiondotorg: I'll try to do it today. I'm just going to work on stuff for other people today - DMB, sponsoring, etc. But my queue is pretty big :-(
[11:18] <flexiondotorg> rbasak, Understood.
[11:49] <Odd_Bloke> I'm packaging up something for which upstream have provided systemd .service files, which I want to use.  Pretty much all of the documentation I've found assumes that I'll be writing my own service files in 'debian/*.service' but in this case I want to use 'init/systemd/named.service'; how should I go about doing that?
[11:50] <cjwatson> Odd_Bloke: binfmt-support does exactly this if you want an example
[11:50] <apw> pitti, i guess i'll have a look in the first instance
[11:50] <cjwatson> you basically just need to install the files (or let upstream's makefiles do it) and then the usual debhelper stuff will pick things up from there
[11:52] <apw> pitti, oh i will prolly poke seth
[11:55] <Odd_Bloke> cjwatson: Excellent, thanks!
[12:15] <rbasak> pitti: mysql-5.7 dep8 ppc64el force again please.
[12:48] <michael-vb> Trevinho: are you around?  And would you have time for a question regarding global appmenus?
[12:55] <alexbligh1> I have a bog standard install of trusty I can't upgrade due to http://pastebin.ubuntu.com/19489188/ - apparently missing a kernel image. I'd put this down to a 'mirror update in progress' issue except the last update was 27 June and I've waited and retried, but it does the same thing. Am I missing something?
[12:57] <rbasak> lamont: you seem to have forked yourself in https://code.launchpad.net/~laney/+junk/packageset :-/
[12:58] <rbasak> From rev 194
[12:58] <rbasak> Sorry, Laney
[12:58] <pitti> rbasak: I don't see it on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html, did someone already do it?
[12:58] <pitti> ... and of course now I do!
[12:59] <rbasak> :)
[12:59] <pitti> TGIF -- done!
[12:59] <rbasak> Thanks!
[13:07] <rbasak> Laney: looks like they should merge OK. I'll just pull everything in.
[13:12] <Laney> rbasak: I probably forgot to pull - ta
[13:15] <rbasak> flexiondotorg: around?
[13:15] <smoser> pitti, yikes.
[13:19] <flexiondotorg> rbasak, o/
[13:23] <lamont> rbasak: whew
[13:24] <rbasak> lamont: sorry!
[13:24] <rbasak> flexiondotorg: your fixes look good, thanks.
[13:24] <lamont> np.  I was worred I'd forked there
[13:24] <rbasak> flexiondotorg: did you look into the dpkg trigger about glib-compile-schemas?
[13:25] <flexiondotorg> I didn't, I must have missed the request to look at that.
[13:25] <lamont> :(){:&:};:  <-- gotta love that one
[13:26] <rbasak> flexiondotorg: also some really minor comments: 1) I'd expect the version to be <upstream>-0ubuntu1 or something. What's your intention there? 2) Drop the "Closes" from changelog unless you want to refer to a Debian ITP or something; 3) debian/watch is missing a terminating \n, so catting it is annoying; 4) debain/ubuntu-mate/hud is empty - should this be there?
[13:27] <rbasak> flexiondotorg: there are some lintian warnings. The two file-without-copyright-information should probably be fixed. A catch-all for GPL-2+ might be suitable here.
[13:27] <flexiondotorg> rbasak, This will not be upload to Debian, they don't carry the required libraries. But I can change the version if required.
[13:28] <rbasak> flexiondotorg: right, so drop the "Closes" - "LP: #XXXX" is sufficient.
[13:28] <flexiondotorg> OK
[13:28] <rbasak> flexiondotorg: and the version would be <upstream>-0ubuntu1, no?
[13:32] <flexiondotorg> rbasak, debian/changelog corrected.
[13:32] <flexiondotorg> rbasak, debian/watch corrected.
[13:33] <flexiondotorg> rbasak, debian/ubuntu-mate-hud removed.
[13:33] <flexiondotorg> rbasak, As for the lintian warning I have conflicting feedback about what to do about COPYING in the past.
[13:34] <rbasak> flexiondotorg: I'm happy to leave it as-is in that case.
[13:34] <flexiondotorg> The last DD I spoke with said just let lintian warn.
[13:36] <rbasak> flexiondotorg: I'm not seeing mate-hud or mate-hud-service byte-compiling anywhere. I'm not sure if I'm missing something here. May I refer this to someone else?
[13:36] <rbasak> barry maybe?
[13:36] <flexiondotorg> OK
[13:36] <rbasak> barry: for context, I'm reviewing https://launchpad.net/~ubuntu-mate-dev/+archive/ubuntu/crazy-mate/+files/mate-hud_16.10.0-1~yakkety1.2.dsc for upload to Ubuntu for flexiondotorg
[13:37] <flexiondotorg> I'm uploading a build to a PPA with the fixes we've just discussed
[13:37] <rbasak> flexiondotorg is dropping a couple of Python programs into /usr/lib/mate-hud/. Should these be being byte-compiled, and/or is this done right?
[13:37] <rbasak> Thanks
[13:38]  * barry waves
[13:40] <barry> rbasak, flexiondotorg generally this is done on install correctly, as long as you are using dh_python2 and/or dh_python3 (some older helpers do it right too, but you should be using those, e.g. python-support or even older python-central)
[13:41] <barry> rbasak, flexiondotorg in fact, it *has* to be done on package install, because at package build-time there's no way to know which pythons are on the user's system
[13:41] <rbasak> barry: is there any way to verify this? Where should I look on an installed system?
[13:42] <flexiondotorg> I am using dh_python3 but these scripts are not in a python module.
[13:42] <barry> rbasak: it will always be "near" the source py files.  the exact path depends on py2 or py3, but e.g. for py3, it will always create __pycache__/*.pyc files
[13:42] <flexiondotorg> So they are not being automatically byte compiled.
[13:42] <rbasak> I don't think it's working then :-(
[13:43] <barry> flexiondotorg: scripts  generally won't get byte compiled because they are just invoking the interpreter via shebangs.  that's another reason why scripts should be super simple, either auto-generated by entry_points, or a very simple hand-crafted script that imports some other module and runs that
[13:43] <flexiondotorg> I'm happy to add this, but I'm not going to have anytime to work on this for 2 weeks.
[13:44] <rbasak> flexiondotorg: I don't want to block you. Let's go ahead without, but please file a bug and fix when you can.
[13:44] <flexiondotorg> So is it possible the slightly fixed version that is building now can be accepted and I'll adjust the next upload to be a python module with byte compiling.
[13:44] <barry> e.g. /usr/bin/lsb_release shebangs /usr/bin/python3.  lsb_release itself won't get byte compiled
[13:44] <flexiondotorg> I'd really like to land this so the testers can start getting feedback preapred for alpha 2.
[13:45] <flexiondotorg> barry, rbasak I know what is required to make the package a complete module with byte compiling :-)
[13:45] <flexiondotorg> I'll fix this either just before or just after alpha 2.
[13:45] <rbasak> I didn't, so thank barry :)
[13:45] <rbasak> *thanks
[13:46] <barry> np!
[13:46] <flexiondotorg> rbasak, barry In the meantime here is the revised .dsc - https://launchpad.net/~ubuntu-mate-dev/+archive/ubuntu/ppa/+files/mate-hud_16.10.0-0ubuntu1~yakkety1.0.dsc
[13:46] <flexiondotorg> Which includes several fixes discussed a little earlier.
[13:47] <barry> flexiondotorg: i'm sorry, i don't have time right now to sponsor.  meetings^2 :)
[13:47] <rbasak> Looking.
[13:47] <flexiondotorg> rbasak, ty
[13:48] <rbasak> flexiondotorg: for the version, I mean that I expect <upstream>-0ubuntu1 only, with no ~yakkety1.0 suffix. What's the reason for the suffix?
[13:49] <flexiondotorg> I only added the usffix for the purposed of upload to a PPA.
[13:49] <flexiondotorg> I realised it should be removed.
[13:49] <rbasak> Oh, OK.
[13:49] <rbasak> I can drop when uploading, no problem.
[13:49] <flexiondotorg> Thanks.
[13:49] <rbasak> I appreciate you fixing the debian/watch file, but you have an extra blank line at the end now. Never mind :)
[13:54] <flexiondotorg> Nuts.
[13:54] <rbasak> flexiondotorg: uploaded. After archive admin acceptance, please file yourself two bugs: 1) use dpkg trigger instead of calling from mate-hud.postinst; 2) move Python code to module and use byte compilation.
[13:55] <flexiondotorg> rbasak, Thanks for your help.
[13:55] <flexiondotorg> Task add to Trello for filling/fixing bugs.
[13:56] <rbasak> flexiondotorg: np. Also, after it's accepted as a source package, we'll need to seed it and then regenerate the packageset.
[13:58] <flexiondotorg> Thanks. Also have a task for that :-)
[14:00] <Trevinho> michael-vb: hey, here I am
[14:00] <michael-vb> Great!
[14:01] <flexiondotorg> rbasak, Thanks for your time and patience. I also appreciate the education on best practice.
[14:01] <michael-vb> I have a bit of a problem with VirtualBox, two screen (i.e. two window) machines and the global menu.
[14:01] <michael-vb> When the second screen is active, the top-level menu entries are there in the global menu, but the menus themselves are empty.
[14:02] <michael-vb> If we are doing something wrong I would love to know what, otherwise it would be good to know that we are not.
[14:03] <michael-vb> And in the second case, if there is an easy work-around that would be good to know too.
[14:03] <michael-vb> No idea if you are the right person to ask, or even if you know who is...
[14:08] <brendand> pitti, would there be any issue with running ntp on a vm created by adt-virt-qemu? i'm recalling that clock-skew issue you showed me the patch for a while back and wondering if that might be related?
[14:20] <michael-vb> Trevinho: any ideas?
[14:22] <Trevinho> michael-vb: you mean there are no menu entries in there?
[14:23] <michael-vb> Right, just a long thin downward-stretching bar.
[14:23] <michael-vb> If I switch to a Firefox window now and click on a menu I see a bar like that for a moment too before it is populated.
[14:24] <Trevinho> Mh, not something that is handled by unity itself.... Is something apps do, via indicator-appmenu and - depending on the toolkit - via various libs
[14:24] <Trevinho> is that for any kind of app?
[14:24] <michael-vb> This is specifically for VirtualBox, which depends indirectly on libdbusmenu-qt5 on Ubuntu.
[14:25] <michael-vb> It was like that with the previous Qt4 version too.
[14:26] <michael-vb> Nick Dedekind who seems to be the person who knows most about libdbusmenu-qt suggested I ask you.
[14:32] <mitya57> michael-vb, I think it's a bug in appmenu-qt5 rather than libdbusmenu-qt
[14:32] <mitya57> Bad news is that appmenu-qt5 is no longer developed and changes to get it fixed are very low.
[14:32] <michael-vb> That was Nick's thought too I believe.
[14:33] <mitya57> Good news is that Qt ≥ 5.7 has its own D-Bus menu implementation (written by me :)) which might not have this bug.
[14:33] <michael-vb> Getting it fixed would be wonderful of course, but just establishing that it is not our bug so that we can send people elsewhere when they report it to use would be good.
[14:33] <michael-vb> to us
[14:34] <mitya57> If you or someone could try with Qt 5.7 and without appmenu-qt5 installed, it would be nice.
[14:36] <michael-vb> Do you know if there is anyone with the knowledge of appmenu-qt5 to at least give me clues to debug this?
[14:43] <michael-vb> mitya57: or Trevinho: ^^^
[14:49] <mitya57> michael-vb, I'm afraid I can't help you with this…
[14:49] <mitya57> Even though I was contributing to appmenu-qt5, its code is a mess and has too many hacks
[14:49] <mitya57> Any of them can be buggy
[14:50] <pitti> brendand: no, ntp ought to work as expected in a VM; it's not really needed unless you have particular requirements (as timesyncd is running by default), but timesyncd will not start if ntp is installed
[14:50] <michael-vb> mitya57: thanks then.
[14:50] <michael-vb> Trevinho: I will take no answer as "don't know either".  Thanks.
[14:50] <brendand> pitti, that's good to know, thanks
[14:54] <dobey> cjwatson, mvo: hi. so i tried setting TMPDIR to a different path, but that doesn't seem to keep the memory usage down. even pointing that at persistent storage, i only see a socket file getting created, and then later destroyed when click is done, but memory usage seems to grow incredibly while dpkg/dpkg-deb is being run, and memory usage still seems to grow to almost the size of the package itself
[14:54] <cjwatson> entschuldigung, ich weiss nicht
[14:56] <Trevinho> michael-vb: but the problem happens in the host or in the guest? Since having it in the quest would be weird
[14:56] <Trevinho> guest*
[14:56] <michael-vb> On the host.
[14:59] <mitya57> michael-vb, can you show me the log from dbus-monitor when this bug appears, please?
[14:59] <michael-vb> Any instructions or just improvise?
[15:00] <mitya57> dbus-monitor 2>log.txt, reproduce the bug, kill dbus-monitor
[15:00] <michael-vb> Where can I send the file?
[15:01] <mitya57> Send it to mitya57@u.c.
[15:01] <mvo> dobey: I just checked the source and it is using mkstemp() for the temp file.
[15:01] <mvo> dobey: it should honor TMDIR :/
[15:03] <michael-vb> mitya57: sent.
[15:04] <mitya57> got it
[15:04]  * mitya57 looks
[15:04] <dobey> mvo: it does honor TMPDIR, it's just not extracting anything to it
[15:04] <dobey> afaict, anyway
[15:08] <mitya57> michael-vb, not really useful, but at least it looks like virtualbox is returning an empty array in response to GetLayout call
[15:09] <mitya57> michael-vb, can you check if the same happens with other Qt 5 apps, i.e. Qt Assistant?
[15:09] <michael-vb> Does that have two windows with independant menus?
[15:09] <michael-vb> independent
[15:09] <michael-vb> English used to be my first language...
[15:10] <mitya57> Hm, no, it doesn't
[15:10] <michael-vb> I suppose historically it will always be my first...
[15:11] <michael-vb> mitya57: even if you can't tell me any more you have got me further.  I saw "GetLayout" in the libdbusmenu-qt source.
[15:11] <mvo> dobey: uh, you guys are using version 0.13, is that correct (15.04)? because that is actually hardcoding /tmp/debsig-verify.XXXXXX
[15:12] <mitya57> michael-vb, so does virtualbox have two windows with different menus?
[15:12] <michael-vb> Actually they should be identical, but yes they are two different objects.
[15:12] <dobey> mvo: i guess, i didn't notice my /tmp size increasing though.
[15:12] <michael-vb> And yes, I see something worth trying there...
[15:13] <dobey> mvo: 0.13 is what i have installed. should we backport something else to the phone overlay?
[15:13] <michael-vb> If our Qt person thinks it is doable.
[15:15] <dobey> mvo: should it be 0.14 or 0.15?
[15:18] <mvo> dobey: worth testing with 0.14, let me double check what changed in 0.15
[15:19] <mvo> dobey: 0.15 is probably a bit of a hassle to backport as it needs a relatievely new dpkg
[15:19] <dobey> ok
[15:19] <dobey> 0.14 doesn't need the new dpkg from xenial?
[15:20] <mitya57> michael-vb, my last try to figure out what's happening: are any warnings printed into stderr?
[15:21] <mitya57> appmenu-qt5 should print them if it fails to i.e. register window with the registrar
[15:21] <michael-vb> During the whole application lifetime you mean or when the error occurs?
[15:22] <mitya57> At any time
[15:22] <mitya57> Or maybe when the second window is created
[15:22] <michael-vb> Just a moment...
[15:23] <michael-vb> Each of these is repeated many times:
[15:23] <michael-vb> Qt WARNING: void DBusMenuExporterPrivate::fillLayoutItem(DBusMenuLayoutItem*, QMenu*, int, int, const QStringList&): No id for action
[15:23] <michael-vb> Qt WARNING: uint DBusMenuExporterDBus::GetLayout(int, int, const QStringList&, DBusMenuLayoutItem&): Condition failed: menu
[15:23] <michael-vb> Qt WARNING: void DBusMenuExporterPrivate::fillLayoutItem(DBusMenuLayoutItem*, QMenu*, int, int, const QStringList&): No id for action
[15:23] <michael-vb> (Another series.)
[15:23] <mitya57> Hmm, this is from dbusmenu, not from appmenu-qt5
[15:25] <mitya57> The first warning means that DBusMenuExporterPrivate::addAction was never called
[15:31] <mitya57> michael-vb, I would suggest you to check two things:
[15:31] <bdmurray> barry: Could you have a look at bug 1603436?
[15:31] <bdmurray> barry: I've recreated the issue.
[15:32] <mitya57> michael-vb, 1) Break in DBusMenuConstructor and check if the menu passed is really *your* menu (and not an empty one)
[15:32] <barry> bdmurray: i don't have much time right now to review it, but i will keep the tab open ;)
[15:32] <mitya57> michael-vb, 2) If it's yours, break in DBusMenuExporter::doUpdateActions and check if all actions are processed
[15:33] <bdmurray> barry: I'm asking you as doko is out for a week or so.
[15:33] <michael-vb> Not empty as in not NULL, or is there some subtle way of telling?
[15:33] <barry> bdmurray: i can look in upstream changelog and source, but it will have to be later (today, hopefully)
[15:34] <michael-vb> Definitely not NULL, I am now in the second call.
[15:34] <mitya57> michael-vb, not empty in sense that menu->actions() is a non-empty list
[15:34] <mitya57> If it's something else, then probably window->findChild<QMenuBar *> from appmenu-qt5 returns something else
[15:34] <michael-vb> (gdb) p menu->actions()
[15:34] <michael-vb> $8 = {<QListSpecialMethods<QAction*>> = {<No data fields>}, {p = {
[15:34] <michael-vb>       static shared_null = {ref = {atomic = {_q_value = -1}}, alloc = 0,
[15:34] <michael-vb>         begin = 0, end = 0, array = {0x0}}, d = 0x187d520}, d = 0x187d520}}
[15:36] <mitya57> What about menu->actions().size()?
[15:36] <mitya57> Oh, it's inline, gdb won't tell it
[15:37] <michael-vb> (gdb) p menu->actions().size()
[15:37] <michael-vb> $9 = 6
[15:37] <mitya57> Good :)
[15:37] <mitya57> But is it the first call to DBusMenuExporter or the broken one?
[15:38] <michael-vb> The second.  But I can restart and check both.
[15:38] <michael-vb> DBusMenu::DBusMenu
[15:38] <mitya57> And the number of submenus in the second window is 6?
[15:38] <michael-vb> Sounds about right.
[15:39] <michael-vb> The window is not visible just now, I would need to find a screen shot...
[15:39] <mitya57> you can check with UBUNTU_MENUPROXY=0
[15:40] <mitya57> this disables the global menu
[15:40] <mitya57> though, you say that top-level submenus show correctly in the Unity panel, right?
[15:40] <mitya57> So the issue happens only when recursing?
[15:41] <michael-vb> Due to another bug the menus are visible both in the global menu and embedded in the windows.  The embedded ones are correct.
[15:41] <michael-vb> libdbusmenu-qt5 or one of its dependencies can't handle setVisibility().
[15:44] <mitya57> Qt should set visibility to false if a platform menu is available
[15:44] <michael-vb> I went over that with other people, the answer was "hopefully Qt 5.7 will fix this".
[15:45] <mitya57> 5.7 is released so you can already test ;)
[15:45] <michael-vb> We still have to work out the licence situation, and since we do fancy things upgrading to a new Qt version is non-trivial.
[15:46] <michael-vb> It is scheduled for some time.
[15:46] <michael-vb> Will float the idea past our Qt person actually.
[15:46] <michael-vb> Said Qt person would also like to know if there is a way to tell that the Unity global menu is in use.
[15:47] <mitya57> Qt *should* ignore setVisible(true) calls if there are any, but according to the code it only does so on macOS.
[15:48] <mitya57> Unfortunately I have to go now. If it still happens with 5.7, please file a bug on bugreports.qt.io and it'll make its way to me or Shawn Rutledge.
[15:49] <michael-vb> I was just typing the same thing - I also have an appointment away from work and the computer.
[15:49] <sladen> michael-vb: can you file a minimal bug report in Launchpad so we have somewhere to track/point at this IRC log from
[15:50] <michael-vb> Will do that.  Thanks all.  Will also stay logged in for a while.
[15:50] <sladen> michael-vb: (PS. thank you to tying off the previous Launchpad bug with the summary + link to upstream committed fix)
[15:51] <michael-vb> Oh right, sorry for tying you up with that one.
[15:51] <michael-vb> Will still update it if there are more updates though for the interest of anyone following.
[15:55] <nacc> rbasak: should mysql-server upgrade from 14.04 -> 16.04? in a simple lxd container (only had bacula-director-mysql + deps installed), it just failed :/
[15:56] <rbasak> :-(
[15:56] <rbasak> What was the error?
[15:57] <rbasak> I have an SRU I'm trying to land that fixes a bunch of upgrade issues, but I don't think they should fail in the default case.
[15:58] <nacc> package mysql-server-5.7 5.7.12-0ubuntu1.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
[15:58] <nacc> is the reason it said it failed
[15:58] <nacc> but then i "I"-d it and it eventually finished?
[15:58] <nacc> looking through the log
[15:59] <nacc> "Column count of performance_schema.events_waits_current is wrong. Expected 19, found 16. Created with MySQL 50549, now running 50712. Please use mysql_upgrade to fix this error."
[15:59] <nacc> ?
[16:00] <rbasak> That's a known race condition. Bug 1577712, and the fix is in my SRU pending upload. Sorry, I was mistaken. that's one case that does fail in the default case.
[16:00] <nacc> rbasak: http://paste.ubuntu.com/19507773/ is the whole thing
[16:00] <nacc> ok
[16:01] <nacc> yeah, it looks like a race :)
[16:05] <robru> pitti: sil2100: guys, for the record, you shouldn't have to wait for me when you want verbose britney logs: http://bazaar.launchpad.net/~cupstream2distro-maintainers/bileto/trunk/revision/584#britney/fetch-indexes
[16:12] <robru> pitti: don't go anywhere, I'll need you to look at a verbose britney log in 30 minutes or so
[16:35] <robru> pitti: https://requests.ci-train.ubuntu.com/static/britney/log_20160715_161001.txt this mean anything to you? It's claiming NBS which is absurd, maybe the index is corrupt?
[18:18] <nacc> elbrus: around?
[18:18] <elbrus> nacc: yes
[18:19] <nacc> elbrus: really appreciated your mysql 5.7 help earlier; hitting another bacula issue with that, as while the scripts that manipulate the databases are now correct, the run-time usage by bacula itself fails with: "ERR=Incorrect datetime value: '0000-00-00 00:00:00' for column 'StartTime' at row 1"
[18:19] <nacc> elbrus: i'll google around and read themanuals, but if you had any idea of how that is supposed to be updated to handle mysql5.7, i'd appreciate any insight
[18:19] <elbrus> nacc: I think I tried to tell you that last time as well
[18:20] <elbrus> in cacti, I change the sql_mode PER SESSION
[18:20] <nacc> ah alwyas?
[18:20] <elbrus> please have a renewed look at the patch I already pointed out to you
[18:20] <nacc> ok, so i'll need to figure out where/if bacula does that in their c mysql wrapper
[18:20] <elbrus> yes
[18:21] <elbrus> and yes
[18:21]  * elbrus did that for cacti
[18:21] <nacc> elbrus: ok, sorry for my misunderstanding earlier, appreciate the pointer!
[18:21] <elbrus> nacc: I am not surprised you missed that earlier
[18:22] <elbrus> typically you only appreciate this kind of advice after you struggled :)
[18:22] <nacc> heh
[21:18] <coreycb> bdmurray, I just uploaded a new ceilometer version to yakkety so the sru for bug 1601854 should be ready to go
[23:38] <juliank> I think there's a regression in the gcc 5.3->5.4 xenial update: apt on xenial FTBFS in the PPA, with the compiler segfaulting :(
[23:38] <juliank> https://launchpad.net/~deity/+archive/ubuntu/apt-1.2/+build/10472777
[23:45] <juliank> Meh, now I reported a gcc bug with an attached .gz log file, and now launchpad produces nonsense
[23:46] <juliank> and now the retry worked. life sucks.
[23:49] <sarnold> wgrant: ^^^ juliank reported compiler ICEs on a ppc64el builder that worked on a subsequent retry
[23:49] <juliank> on bos01-ppc64el-021
[23:50] <juliank> full log of failed build is in https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1603588
[23:53] <slangasek> oh, on ppc64el; phew
[23:53] <slangasek> ;)
[23:53] <juliank> "Weird" architectures and their bugs...