[01:57] <anon^_^> everyone must be watching the pooper bowl
[07:10] <cpaelzer> good morning
[08:15] <mitya57> Laney: thanks, Sphinx migrated now! \o/
[09:05] <Laney> mitya57: someone skipped it ...
[09:21] <tjaalton> doko: hi, just a heads up that mesa et al will migrate to llvm-4.0 for zesty, probably post-ff as llvm-4.0 is still at rc1
[09:31] <Mirv> tjaalton: will you be the guy to switch the verification tag in bug #1641017? I see a community testing is mentioned, so I didn't dare to tag it as done just based on my testing.
[09:32] <Mirv> I did tag the other two bugs, especially as I happen to have Radeon 7750 mentioned in the other bug
[09:38] <tjaalton> Mirv: yeah, guess I should
[10:20] <rbasak> cpaelzer: could versioning the symbols be a solution?
[10:45] <lolek> hello everybody, I hope this is not wrong channel for this question, I'm trying to understand how the global menu in ubuntu is being done as I'm trying to fix one application behavior
[10:46] <lolek> so far I thought it's taking the app menu that's not hidden and is using it as a menu, but it seems it's not working like this, so my question is how can I have multiple global menus and switch between them?
[10:46] <juliank> I'm thinking about just pushing ndiswrapper 1.60-3 from yakkety/zesty to xenial to make it build with newer kernels (bug 1625089). Opinions on that?
[10:47] <juliank> It's a very leaf package in universe, the changes (https://anonscm.debian.org/git/collab-maint/ndiswrapper.git/diff/?id=debian/1.60-3&id2=debian/1.59-6) are fairly tiny, and I don't really want to bother rolling custom updates for stable series for a project that's on basic life support.
[10:53] <juliank> apw: ^ basically ready to go
[10:53] <juliank> AKA package built, not signed yet...
[10:59] <juliank> Uploaded now, but oh well, 1.60-3~ubuntu16.04.1 might not have been the best versioning choice - I think it should have been 1.60-3~ubuntu0.16.04.1?
[11:00] <juliank> or well, it's a ~, so it does not really matter
[11:00] <cpaelzer> rbasak: could work, but then how much more symbols would it be
[11:01] <cpaelzer> rbasak: that is part of the "it might be an upstream bug, but I have to fix packaging for now" story IMHO
[11:06] <rbasak> cpaelzer: it would be the same number of symbols per shared library still though, no?
[11:06] <rbasak> IIRC, libmysqlclient20 does this.
[11:07] <juliank> There's an ndiswrapper 1.61 now, but it failed to build or something, so no upload of that one ...
[11:09] <juliank> If we can just upload the new uploads to xenial (assuming neither I nor upstream do anything except basic life support), we can even continue having working ndiswrappers in xenial with new kernels.
[11:10] <juliank> We have the same problem with new kernels in precise and trusty, but they never got an update for ndiswrapper (but they probably also have no automated testing of dkms builds)
[11:13] <juliank> Unfortunately, I cleaned up the packaging after trusty/vivid (wily?) [see 1.59-4 changelog], so these would require backporting quite some stuff which I'm not really fond of doing (it's up for grabs if someone is interested in that stuff)
[11:23] <cpaelzer> rbasak: yeah I just meant this is a fix that I might propose upstream for the following versions
[11:24] <cpaelzer> rbasak: do you have a pointer to the libmysql example to I can refer to it?
[11:27] <rbasak> cpaelzer: I'm not sure, sorry. I'm not even sure how to confirm the symbols are versioned. I thought they were, but objdump/nm don't seem to think so.
[11:27]  * rbasak 's linker-fu is weak.
[11:39] <cpaelzer> rbasak: honestly I just think different versions of same so in the same exetubale space are doomed to cause trouble - the question for me is how to resolve that so that it won't happen
[11:40] <apw> juliank, i can reject that for you if you want to change the version
[11:40] <juliank> apw: Nah, I think it's normal for the ~ ones
[11:40] <cpaelzer> rbasak: after I summarized I'm kind of leaning towards the symlink-compat-lib solution I described for now
[11:40] <juliank> Only the non-~ ones have a 0. in front usually
[11:40] <cpaelzer> rbasak: and starting the discussion upstream how they want it in the long term
[11:41] <cpaelzer> rbasak: yet - I feel unsure enugh still that I'd really want some feedback from the more experienced packagers
[11:41] <apw> juliank, i suspect they are either ubuntu0.16.04.1 or ~16.04.1, but as long as they are consistent between releases so they sort right it doesn't matter much
[11:41] <rbasak> cpaelzer: I agree it's problematic, but I also think it's inevitable for complicated applications. libmysqlclient is an example - it may be that two different libraries need that for certain apps. If symbols are versioned, it should work correctly I think. The problem might come if the library breaks ABI only.
[11:41] <rbasak> (breaks ABI without declaring it, that is)
[11:42] <rbasak> Or, if the application wants to pass handles or data across different ABI versions of the same library. Then I'm not sure how to declare that relationship in dependencies in a clean way.
[11:42] <juliank> apw: Right. It just felt kind of wrong without "ubuntu" in there IMO (that would be 1.60-3~16.04.1)
[11:43] <juliank> pbuilder has 	0.227~ubuntu16.04.1 similar to my ndiswrapper upload, I think that looks nicer
[11:43] <apw> juliank, then that is good enough
[11:46] <juliank> apw: I accidentally have "(LP: ##1625089)" [two #] in the changelog, but the entry below it has the correct one, so the bug tracking works fine... :)
[11:46] <apw> heh, it is one of those days isn't it
[12:01] <juliank> apw: I love how you are talking to yourself in the semi-automated "please test" message :D
[12:02] <apw> juliank, heh .. lovely isn't it
[12:02] <apw> once the publisher gets caught up i'll wack that one and get the test rerun
[12:37] <mapreri> juliank: that's proposed for xenial-backports, not xenial-updates though.
[12:38] <juliank> mapreri: Ah, well. Both are technically backports, though, one is just tiny enough to SRU it
[12:38] <mapreri> (but apparently in ubuntu the same versioning is used for all pockets)
[12:39] <juliank> mapreri: Well, there's no clear rule on that anyway, except for the security rules.
[12:39] <juliank> And these don't have ~ rules ...
[12:50] <ogra_> pitti, oops ... http://planet.ubuntu.com/
[12:51] <ogra_> i guess you're cached there ...
[12:56] <pitti> ogra_: yeah, I got re-hacked after restoring everything, I permanently shut it down now
[12:56] <pitti> so planet's cache needs to get purged
[12:56] <ogra_> yeah, no idea who owns planet nowadays
[12:57] <ogra_> or how one would purge it
[12:57] <juliank> ogra_: maybe pitti's attacker can help :D
[12:57] <ogra_> lol
[12:58] <juliank> pitti: Your blog got hacked twice?
[12:58] <juliank> that's incredible.
[12:58] <pitti> two days ago already, so three times
[12:58] <juliank> I did not know you were such a valuable target :D
[12:58] <pitti> daily.2 looks good
[12:59] <pitti> hugo looks pretty good, and https://github.com/SchumacherFM/wordpress-to-hugo-exporter seems to do quite an amazing job
[13:00] <juliank> probably
[13:00] <juliank> I'm thinking of converting my ikiwiki to jekkyl, dropping the host and just hosting my website on github ...
[15:30] <smoser> bdmurray, when you arrive... were you looking at the xenial cloud-init sru ? (you requested SRU info on one of the bugs, i've added it). is there anything you need from me.
[17:01] <nacc> rbasak: around?
[17:10] <rbasak> nacc: o/
[19:46] <rbasak> cpaelzer, nacc or maybe caribou: I'd appreciate a review of my squid3 merge please. https://code.launchpad.net/~racb/ubuntu/+source/squid3/+git/squid3/+merge/316496
[19:47] <rbasak> I'll upload it in a week if nobody has had time to review by then.
[19:49] <rbasak> Review workflow at: https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow#Reviewing_Merges
[19:50] <nacc> rbasak: I will try if I can find the cycles :)
[19:50] <sarnold> it's 90% changelog, 90% QRT tests
[19:51] <nacc> sarnold: yeah, because a lot of stuff is being dropped in the merge (afaict)
[19:52] <rbasak> It's the total diff againt Debian you're seeing in the preview diff. It's a good sign when that's all that's remaining :-)
[19:52] <rbasak> https://git.launchpad.net/~racb/ubuntu/+source/squid3/log/ may be more helpful in understanding what the delta actually is.
[19:53] <rbasak> And https://git.launchpad.net/~racb/ubuntu/+source/squid3/log?id=logical/3.5.12-1ubuntu8 is what it was before.
[20:32] <dobey> who knows anything about lubuntu?
[20:32] <wxl> dobey: #lubuntu(-devel)
[20:33] <dobey> wxl: well i just need to know if it depends on xdg autostart functionality for starting indicators, or if it uses upstart or systemd instead
[20:34] <dobey> and if fossfreedom is around, i need to know the same about budgie
[20:34] <wxl> dobey: the indicators are all within lxpanel which is started with autostart
[20:35] <dobey> wxl: so indicator-messages and indicator-application are started with autostart?
[20:35] <fossfreedom> dobey: same on budgie - budgie-desktop starts the indicator
[20:36] <wxl> dobey: yep.
[20:37] <dobey> hmm. :-/
[20:47] <dobey> hmm, no, it looks like lxpanel is actually loading .so files for indicators? or am i reading this code wrong?
[20:48] <wxl> yepp. that's what i'm saying. the indicators are plugins that are built into lxpanel.
[20:48] <wxl> but lxpanel is loaded with autostart, which in turn loads those indicators.
[20:48] <dobey> hmm, i wonder why indicator-messages and indicator-sound are seeded in lubuntu
[20:49] <wxl> hm. maybe i'm wrong
[20:51] <wxl> there's no -messages in a yakkety vm but -sound is there
[20:52] <dobey> but indicator-sound doesn't provide libsoundmenu.so
[20:53] <wxl> -application is there, too
[20:53] <wxl> but not messages
[20:53] <wxl> and this coincides with the manifest
[21:26] <smoser> bdmurray, i've just uploaded cloud-init_0.7.9-0ubuntu1~16.04.2_source.changes
[21:26] <smoser> which has a fix on the sru you let in earlier today.
[21:26] <smoser> :-(
[21:29] <smoser> would appreciate a quick review and let that into -proposd.
[21:32] <bdmurray> smoser: accepted
[21:32] <smoser> thanks
[21:32] <wxl> dobey: libsoundmenu.so is provided by indicator-sound-gtk2 which lubuntu does have
[21:33] <dobey> wxl: yeah, i see that now, but i don't understand why that depends on indicator-sound
[21:33] <dobey> i also don't see any evidence that budgie is using ubuntu indicators at all
[21:34] <smoser> bdmurray, can you reject the upload to yakkety-proposed
[21:34] <smoser> for cloud-init.
[21:34] <smoser> and i am uploading it again right now.
[21:35] <wxl> dobey: well, i can't speak as to why indicator-sound-gtk2 depends on indicator-sound, if that's what you mean
[21:36] <dobey> wxl: sure. was just pointing out what i discovered. i'm in this rabbit hole because i'm making changes to indicator-sound that could potentially break some of the other flavors, so trying to make sure i don't
[21:36] <wxl> dobey: speaking for lubuntu, i appreciate your consideration :)
[22:08] <Unit193> infinity: Howdy.  Is there something I can follow to track the progress of geoip-database getting an "automatic" backport?  Also, you seem to be the dpkg guy.  Know if that's getting merged for zesty, or is that held up on LP .buildinfo support?
[22:46] <fossfreedom> dobey: in the case of Ubuntu Budgie - we do not make any use of any of the indicator-* packages.  So no impact on our side if you make changes to indicator-sound
[22:52] <fossfreedom> cjwatson: just wondering if our (Ubuntu Budgie) merge request is nearing the top of your todo list?  TIA https://bugs.launchpad.net/ubuntu/+source/debian-cd/+bug/1659278
[23:47] <wxl> cyphermox: caribou: if i understand this whole patch pilot thing correctly, you guys are on call to help with sponsorship, no? i've been trying for almost a week now to get my konversation in yakkety sponsored so i can pursue an sru https://bugs.launchpad.net/ubuntu/+source/konversation/+bug/1635911