[00:23] <tsimonq2> What sort of "rules of thumb" are there when wanting to become a MOTU? I've gotten pretty familiar with the release process, so I'm familiar with the infrastructure and the rules associated with it. I just haven't done a *lot* of package uploading through sponsorship. I have a few packages I've gotten fixes to, but other than that, not much.
[00:24] <tsimonq2> So I know I need to do more work before applying, but a lot of the documentation is horribly outdated. That's why I want to know what the general rules are here.
[00:25] <tsimonq2> I also generally need experience here, so feel free to throw things at me. ;)
[05:40] <pitti> Good morning
[06:50] <ginggs> pitti: guten morgen! do we still need a separate fftw3-mpi since archive re-org?
[06:55] <dholbach> good morning
[07:20] <pitti> ginggs: if it only builds new binaries which can stay in universe, we can sync again (I didn't check precisely)
[07:24] <ginggs> pitti: i'm not sure, that's why i asked.  why would we need to sync again?
[07:25] <pitti> ginggs: ATM it seems our fftw3 package still has an ubuntu delta and doesn't build the mpi packages?
[07:27] <pitti> ginggs: so I suppose syncing fftw3 and removing fftw3-mpi would do it?
[07:27] <pitti> sorry, need to get offline for a bit
[07:27] <ginggs> pitti: yes, but we already have 3.3.5-1 in proposed
[07:53] <ilmaisin> hi
[07:53] <ilmaisin> could some developer take a look at this: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1439771
[07:54] <ilmaisin> as laptops and wlans are more a rule than exception today, it's quite important and i don't understand why it's only "medium" in importance
[07:54] <ilmaisin> it's likely related to the systemd transition
[08:51] <ilmaisin> is the answer "no, canonical doesn't want to fix bugs as it is now working with microsoft and wants to tarnish the reputation of desktop linux"?
[08:53] <ilmaisin> difference, to, say, fedora is like day and night, in fedora, while it has problems of it's own too, fixing important "critical path" bugs is more like a matter of days rather than years
[08:53] <Laney> If you want to troll Ubuntu, take it elsewhere.
[08:54] <ilmaisin> Laney: i don't want to troll anything, i want someone to take look of the bug, trolling is only a desperate mean to achieve that
[09:29] <infinity> ilmaisin: All the noise on that bug implies people are seeing several different bugs and dogpiling on.
[09:29] <infinity> ilmaisin: As for criticality, if NM was entirely broken for everyone, we'd all be panicking, but literally all of us run Ubuntu on laptops and, clearly, it's not broken for all of us, so it's a bit messier to track down.
[09:30] <infinity> ilmaisin: And insulting people is a really poor way to get your bugs addressed.
[09:30] <infinity> ilmaisin: Turns out that's pretty demotivating.
[09:33] <infinity> ilmaisin: (PS: Not everyone who works on Ubuntu is paid by Canonical, just as not everyone who works on Fedora is paid by RedHat).
[09:33] <infinity> ilmaisin: So even if your conspiracy theories about Canonical were true (they're not), turns out other people could still upload a fix.  Or sponsor a fix with a patch you submitted even!
[09:35] <Son_Goku> ilmaisin, being slightly constructive here, it's highly unlikely to be related to systemd
[09:36] <Son_Goku> at least by this point, anywya
[09:36] <Son_Goku> *anyway
[09:36]  * Son_Goku pokes infinity
[09:37] <Son_Goku> any progress on those patches?
[09:37] <Son_Goku> you know the ones I'm talking about ;)
[09:37] <ilmaisin> infinity: i just can't help being quite frustrated on ubuntu's seemingly passive aggressive approach to bugs
[09:38] <infinity> ilmaisin: No distro has the manpower to fix every bug filed.  Or even to read them all.
[09:38] <ilmaisin> infinity: i can get it reproduced by suspending and resuming the system until the problem reproduces
[09:38] <infinity> ilmaisin: We're not "special" here.
[09:39] <infinity> ilmaisin: I have RH bugs that go unread until the "this version is EOL, so we're autoclosing the bug" bot sweeps them up and I have to reopen them.
[09:39] <infinity> ilmaisin: Everyone sucks at bugs.  The ened.
[09:39] <infinity> end*
[09:39] <Son_Goku> ilmaisin, the sad thing is, as a particular distribution becomes more popular, the amount of manpower available for dealing for each bug goes down
[09:39] <infinity> ilmaisin: If you can reproduce it reliably and provide any useful debugging info, please do.  If it happened on all laptops, I'd have noticed it, as would countless others of us.
[09:40] <Son_Goku> infinity: there's a tag you can add to keep the autosweeper from killing the bug in rhbz, btw
[09:40] <infinity> Son_Goku: !!
[09:40] <Son_Goku> we use it for long running DNF bugs that are taking a lot of time to fix
[09:40] <infinity> Son_Goku: Does the bot tell me this and I've just never read closely enough, or is it a hidden feature?
[09:41] <Son_Goku> it's a hidden feature of Bugzilla configuration
[09:41] <Son_Goku> I forgot where it was documented for rhbz
[09:41] <infinity> Well, spank me silly and call me Tilly.
[09:41] <Son_Goku> give me a sec...
[09:41] <ogra_> cant you just set it to triaged status ? whats the advantage of having a tag instead ?
[09:41] <infinity> I should be sleeping, though.
[09:41] <Son_Goku> Nooo :P
[09:42] <Son_Goku> ogra_, if a bug is set to NEW and never gets any updates and whatnot, it autocloses
[09:42] <infinity> ogra_: RH agressively closes bugs in obsolete series'.  Exactly what I've campaigned against in Ubuntu.  But, to each their own.
[09:42] <ogra_> Son_Goku, ugh
[09:42] <infinity> (Well, we close ones with a series target, but keep the devel target open)
[09:42] <ogra_> yep
[09:43] <ogra_> and never auto-close New i think
[09:43] <Son_Goku> we used to leave Rawhide alone
[09:43] <infinity> Each has its advantages.
[09:43] <Son_Goku> but it kept piling up...
[09:43] <ilmaisin> Son_Goku: the "as a particular distribution becomes more popular, the amount of manpower available for dealing for each bug goes down" thing sounds quite bad for me as that would mean that if linux on desktop gets more popular, it will choke to bug reports and fall apart
[09:43] <infinity> Volume of bugs is a real problem.
[09:43] <infinity> But so is closing valid bugs without a solution.
[09:43] <infinity> Both suck. :P
[09:43] <Son_Goku> there's no good way to deal with the problem, unfortunately :(
[09:43] <Son_Goku> I wish there was
[09:44] <infinity> ilmaisin: There are bugs in Windows that I've been aware of since 1994.  Software is like that.
[09:44] <infinity> Some bugs get fixed.  Others don't.
[09:44] <infinity> At least with free software, you generally have an avenue to complain a bit.
[09:45] <infinity> And one where we don't charge you for the privilege!
[09:45] <Son_Goku> infinity, I think if you add the keyword "Triaged" to the KEYWORDS field, it should stay open
[09:45] <infinity> Son_Goku: I may ask you about that again the next time I get a bug closed against my will. :P
[09:45] <Son_Goku> that and "FutureFeature", but I think "FutureFeature" is more about preventing the rawhide->release autoassigner
[09:45] <ilmaisin> infinity: yeah, if microsoft had a public bug tracker it would probably collapse to flood
[09:45] <Son_Goku> ilmaisin, the semi-public one already does
[09:46] <Son_Goku> it's down on a regular basis because it needs manual pruning
[09:46] <infinity> Yeahp.
[09:46] <infinity> And that has nothing to do with the quality of their software, it's just the volume of users.
[09:46] <infinity> Users are great.  Bug reports from users can be great.
[09:46] <infinity> But they also generate a lot of work.
[09:47] <infinity> And I don't mean "fixing bugs" work, I mean "reading bug reports" work.
[09:47] <Son_Goku> pretty much
[09:47] <Son_Goku> but volume of bugs always sucks
[09:47] <Son_Goku> yep
[09:47] <Son_Goku> I've been lucky so far with my own stuff in Fedora, but I know people who literally can't read bugzilla anymore because it just makes their brains explode
[09:47] <Son_Goku> just too much bugs
[09:48] <Son_Goku> and autoreporters like ABRT, Apport, etc. don't help
[09:48] <ilmaisin> infinity: so you haven't ever seen you laptop to lose ssid list and can't reproduce it how i said?
[09:48] <Son_Goku> again, great for making useful bug reports, but the required cognitive effort for dealing with them is still quite high
[09:49] <infinity> ilmaisin: Nope.
[09:50] <infinity> ilmaisin: Happens to my Android phone, but I know what that bug is.
[09:50] <infinity> Never to my Ubuntu machines, though.
[09:50] <ilmaisin> infinity: ok
[09:50] <ilmaisin> infinity: what chipset do you have on the ubuntu laptop?
[09:50] <infinity> Intel something
[09:51] <infinity> 7265
[09:51] <Son_Goku> fwiw, bcm wifi is just generally crappy
[09:51] <ilmaisin> ok
[09:51] <Son_Goku> a lot of issues are just caused by it being Broadcom
[09:51] <Son_Goku> and there's not a damn thing we can do about it
[09:51] <Son_Goku> on the Fedora side, Broadcom is our trickiest Wi-Fi module to support
[09:52] <infinity> Yeah, we're not fans in Ubuntu either.
[09:52] <ilmaisin> well, it's sometimes quite possible to work around hardware design flaws on os level, but not always though
[09:52] <Son_Goku> and as far as I know, no one has perfectly nailed down BCMxxxx chipset support
[09:52] <infinity> We attempt to "support" it, but there's only so much you can do when the "good" driver is close-source, and it's only barely better than the "bad" driver.
[09:52] <Son_Goku> yep
[09:53] <Son_Goku> and in our case, we can't officially recommend the closed-source driver like Ubuntu can
[09:53] <Son_Goku> so...
[09:53]  * Son_Goku shrugs
[09:54] <Son_Goku> that said, nobody in Fedora really *wants* to, as the closed-source driver is crappy and destabilizes the kernel in weird ways
[09:54] <infinity> The likely best option, if it's the driver being wonky, is to quirk it to remove and reinsert on suspend/resume, but I don't recall where that happens in the new world.
[09:54] <infinity> Cause I haven't had to use said quirk in a long time.
[09:54] <infinity> Possibly a snippet in /etc/pm/suspend.d
[09:55] <Son_Goku> forcibly unloading and reloading the driver does work (oss or proprietary), as long as the hardware firmware didn't hang
[09:55] <Son_Goku> which can happen too (!!!)
[09:55] <Son_Goku> then you have to do a cold restart to fix :(
[09:55] <infinity> Thanks, Broadbama.
[09:55]  * Son_Goku experiences this fairly regularly on his MacBook Pro running Linux
[09:55] <infinity> Okay.  I'm really asleep now.  Honest.
[09:55]  * infinity goes.
[09:56] <Son_Goku> :(
[09:57] <ilmaisin> http://www.macrumors.com/2016/03/18/apple-supplier-broadcom-wi-fi-chip-business/
[09:57] <ilmaisin> hmm
[09:57] <ilmaisin> they maybe are going to quit that business
[10:03] <Son_Goku> if it means Apple starts creating its own chips, we're screwed
[10:17] <ilmaisin> yes, the problem seems to be "solved" when i make my system to unload the module before sleep
[10:17] <ilmaisin> could that workaround be applied to the ubuntu packages somehow?
[10:22] <ilmaisin> maybe the bug importance should be "High" instead of "Medium" as bcm chips are quite common
[10:27] <Son_Goku> that's not for us to decide, that's for the bug triaging folks to decide
[10:27] <ilmaisin> ok
[10:27] <Son_Goku> but you can certainly comment about that as a possible solution
[10:27] <ilmaisin> Son_Goku: done that
[10:48] <ilmaisin> hopefully those snappy and flatpak things will free distro developer's time to deal with actual os issues instead of packaging every software that exists
[10:52] <rbasak> I suspect that bug has become a catch-all for "wifi doesn't work after suspend" which is probably an entire class of bugs rather than just one bug.
[10:52] <ilmaisin> rbasak: it's possible
[10:52] <rbasak> In that case it rapidly becomes impossible for developers to tackle the problem at all, since the comments may refer to radically different root causes.
[10:53] <ilmaisin> rbasak: though broadcom drivers appears to be a common factor there
[10:53] <rbasak> I would file a separate bug report with a much more rigid description. "With hardware X, when I do a fresh install and then follow exactly the steps Y, I get behaviour Z, with log messages stating A and B. If X, Y, Z, A and B don't match, you aren't affected by this bug".
[10:54] <rbasak> You might then find that you are actually the only person affected by your particular bug.
[10:55] <rbasak> ilmaisin: sure, and with a collection of specific bugs (perhaps grouped together by a tag), a developer may be able to identify a common way of fixing all of them at once.
[10:55] <ilmaisin> rbasak: i had a separate report on my case but i marked it as duplicate, but it was not as good report as you described
[10:55] <rbasak> But until then, they really need to be separate bugs. Otherwise the bug will remain intractable and never get fixed.
[10:56] <ilmaisin> rbasak: only if i had enough motivation to write long reports that won't in all likelihood lead to anything
[10:57] <rbasak> If a hundred people are affected by a well-described bug, it will usually get addressed IME, because by that stage a capable Ubuntu developer is affected.
[10:57] <rbasak> I'm sure there are exceptions though, and of course there's no guarantee.
[10:57] <rbasak> More likely we have a hundred people affected by a hundred different bugs, so nothing stands out to get prioritised.
[10:57] <ilmaisin> rbasak: and we need those 99 other people who are motivated to write long and detailed reports that won't alone lead to anything
[10:58] <rbasak> Well, this is the Free Software ecosystem. Either bugs affecting many people get fixed by one of those affected, or by a sponsor interested in fixing bugs affecting many people, or by somebody who pays to get a bug fixed.
[10:58] <rbasak> Or the bug doesn't get fixed.
[11:04] <ilmaisin> i'll have to re-test if it affects the proprietary driver as well
[11:55] <ilmaisin> it seems to be ok with the proprietary driver at least now
[16:00] <loganade1> hoi
[16:02] <loganade1> are you guys planning on doing another google code-in this year ?
[16:29] <niedbalski> arges, ping
[18:40] <x_7fffbad3> hello people! :) i want to add a custom menu at unity panel...can you give me some resources about this?
[18:42] <dobey> unity 7?
[18:43] <x_7fffbad3> it's `unity 7.4.0`
[18:44] <dobey> you need to write an application indicator
[18:44] <dobey> https://unity.ubuntu.com/projects/appindicators/
[18:45] <x_7fffbad3> dobey: that's what i need...thank you for link+keywords ;)
[18:45] <x_7fffbad3> dobey: next step: search -> program
[18:46] <hjd_> Is the sync from Debian working differently in Zesty compared to other release cycles? I seem to remember that most packages were synced and built when the archive opened for development, but this time around it seems to work more gradually.
[18:47] <jbicha> hjd_: I believe they're wanting to at least finish the perl transition first this time before starting autosync
[18:51] <hjd_> jbicha: Ah, I didn't know. Is there anywhere I can see an overview of the transition state?
[18:51] <jbicha> hjd_: click perl5.24 at https://people.canonical.com/~ubuntu-archive/transitions/
[18:52] <hjd_> :)
[19:47] <pitti> robru: FYI, autopkgtest refactoring into a britney Policy is going well! It's working now, I just want to clean up the code a bit now
[20:02] <LocutusOfBorg> rbasak, can you please fix mysql-5.7?
[20:03] <LocutusOfBorg> I need boinc to go in testing and it is blocked by this one. (and I can't use default-mysql package, because it is not in jessie-backports)
[20:03] <LocutusOfBorg> thanks
[20:05] <robru> pitti: oh cool, that was fast, thanks
[20:12] <pitti> robru: https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/commit/?h=policy-changes&id=1d9fc1756e
[20:12] <pitti> robru: the britney.py changes are now minimal -- only instantiate the new policy; and it doesn't touch excuse.py at all any more except for a backwards compat thing that we'll drop soon (I'll mail you and apw about adjusting kernel matrix and bileto)
[20:14] <robru> pitti: wow, very nice! That looks like a major reduction in maintenance burden
[20:15] <robru> Eg easier to rebase on upstream changes
[20:15] <pitti> absolutely
[20:15] <pitti> also more stable against behaviour changes
[20:15] <robru> Brilliant
[20:15] <pitti> robru: I still want to clean up/refactor the apply_policy_impl() code, this looks horrible now
[20:15] <pitti> but this will be completely internal
[20:15] <robru> Right
[20:15] <pitti> at least now all the tests pass again
[20:15] <pitti> and in principle you can now hook your's after AutopkgtestPolicy
[20:16] <pitti> I like this much better
[20:16] <robru> pitti: ok will rebase, thanks again
[20:16] <pitti> robru: britney might become a pretty girl some day :)
[20:16] <robru> Hahaha
[20:18] <dobey> pitti: just make her fast :)
[20:18] <pitti> Britney Bolt
[20:18] <pitti> daughter of Ursain :)
[20:18] <pitti> Usain even
[20:19] <pitti> robru: rebase> maybe wait until I land this in master? but of course you can already experiment against that branch
[20:20] <robru> pitti: yeah I'll wait of course. Will rebase when ready
[20:32] <sil2100> Just a heads up: I'm investigating the dbusada autopkgtest failures as seen after the dbus new upload in zesty (unrelated)
[20:41] <pitti> robru: https://bileto.ubuntu.com/#/ticket/1710 failed to publish as it stumbles over the nonexisting zesty/libindicator (this was just a backport, so there are no zesty changes); is there a way to publish this that doesn't invalidate all teh automatic and manual testing?
[20:42] <pitti> (I also forgot to tick the packaging ack, but that's the simple part)
[20:42] <robru> pitti: too many cooks in this kitchen i think: https://bileto.ubuntu.com/log/1710/
[20:43] <robru> pitti: please join our discussion in ci-eng
[20:43] <pitti> robru: that's not a meaningful channel on either freenode or C?
[20:44] <robru> pitti: #ubuntu-ci-eng
[20:44] <robru> It's the channel for all things bileto
[20:44] <rbasak> LocutusOfBorg: how so? You can't rdepend on mysql-5.{6,7} if you want to remain in testing.
[20:45] <rbasak> LocutusOfBorg: for jessie-backports you'll either need a delta or someone needs to sort out mysql-common/mysql-defaults in backports.
[20:56] <rbasak> LocutusOfBorg: see Debian bug 837615
[21:00] <LocutusOfBorg> rbasak, so, mysql5.6 can't migrate and 5.7 too
[21:00] <LocutusOfBorg> how can I see it migrate?
[21:01] <LocutusOfBorg> ok, so let me do an upload with the default, sigh
[21:54] <tjaalton> cyphermox: hi, what's the status of the xenial update for bug 1527727?
[22:48] <cyphermox> tjaalton: thanks for the reminder, I'll reupload that in a bit
[22:48] <tjaalton> cyphermox: nice, thx