[00:13] <mwhudson> well i've found the binutils commit that's to blame
[00:13] <mwhudson> 32ec889602502348b704cfb16e65c83dc3eec095
[00:13] <mwhudson> "Tidy up readelf's use of boolean values."
[00:37] <Unit193> mwhudson: Ahaha!  Awesome timing, just now I get an email about it being stuck in proposed. :D
[00:38] <mwhudson> Unit193: heh
[00:39] <mwhudson> Unit193: gocryptfs?
[00:39] <Unit193> Yep.
[00:39] <mwhudson> the bot is a harsh mistress
[01:43] <blahdeblah> There is a brief outage on *.qa.ubuntu.com coming up shortly; apologies for any inconvenience.
[01:44] <blahdeblah> (also includes loco.ubuntu.com)
[01:45] <Unit193> That's just loco.
[01:46] <blahdeblah> Unit193: what do you mean?
[01:46] <Unit193> Bad joke, sorry.
[01:47] <blahdeblah> Some of us non-South Americans are a little slow
[01:47] <blahdeblah> (Or is that all Spanish speakers?    Also, Ohioian here, very north America.  Thanks for letting us know about the downtime.
[01:50] <blahdeblah> It's long since done, BTW
[03:34] <Logan> rbasak, smoser: would you mind taking a look at my merge request for scim-chewing when you get the chance? https://code.launchpad.net/~logan/ubuntu/+source/scim-chewing/+git/scim-chewing/+merge/327575
[03:35] <Logan> also, what's the process for becoming a member of the Ubuntu Server Dev import team?
[07:38] <LocutusOfBorg> mapreri, any idea for diffoscope autopkgtestsuite? it is blocking a lot of python stuff...
[07:38] <mapreri> yes
[07:38] <mapreri> LocutusOfBorg: it's due to this: https://sourceware.org/bugzilla/show_bug.cgi?id=21820
[07:38] <LocutusOfBorg> so, regression in binutils?
[07:39] <mapreri> Also reported as Debian #869532 for diffoscope
[07:40] <LocutusOfBorg> thanks :(
[07:42] <mapreri> LocutusOfBorg: do you have any idea about why binutils didn't trigger a diffoscope autopkgtest, and wasn't blocked in proposed?
[07:43] <mapreri> in general it feels like there are fewer tests than expected
[07:57] <ricotz> hi, there are still quite a bunch of rebuilds to be done -- http://people.canonical.com/~ubuntu-archive/transitions/html/python3.6.html
[08:13] <rbasak> Logan: it's on my team's list to take a look. Sorry it hasn't bubbled to the top yet.
[08:48] <LocutusOfBorg> ricotz, maybe people are waiting for autopkgtestsuite become green?
[08:48] <LocutusOfBorg> not sure who is handling that python transition
[08:51] <xnox> the new binutils is blocked in proposed and not migrating
[08:54] <ricotz> LocutusOfBorg, hopefully not, I guess it is mwhudson
[08:58] <rbasak> cyphermox: any news on bug 1624519 please? It unsnoozed on my board.
[09:01] <mwhudson> ricotz: huh i hadn't seen that that had been updated
[09:01] <mwhudson> mapreri: yeah that binutils thing is heaps of fun :(
[09:01] <LocutusOfBorg> mwhudson, revert that commit for binutils? :)
[09:02] <mwhudson> LocutusOfBorg: guess what the debdiff i have here does!
[09:02] <LocutusOfBorg> just to make things migrate, otherwise a lot of stuff including python is blocked
[09:02] <LocutusOfBorg> lol wonderful!
[09:02] <LocutusOfBorg> mwhudson, do you want some help in python? I have not much knowledge, but I can allocate some hours there probably
[09:03] <LocutusOfBorg> Its blocking my sane-backends gsoap and something more transitions :)
[09:03] <mwhudson> LocutusOfBorg: sure
[09:03] <LocutusOfBorg> and meh, there is a lot of perl fun that is waiting for it :)
[09:03] <mwhudson> there's not much stopping python3-defaults from migrating really
[09:04] <mwhudson> but knocking some things off the transition tracker would be nice
[09:04] <mwhudson> careful, some are kind of false hits though
[09:04] <mwhudson> e.g. boost i think
[09:05] <mwhudson> LocutusOfBorg: if you want to figure out what's going on with botch......
[09:05] <LocutusOfBorg> python-pex seems to be easily fixable
[09:05] <LocutusOfBorg> mwhudson, botch is out of my knowledge
[09:05] <mwhudson> yeah that one looks easy
[09:05] <LocutusOfBorg> I already tried
[09:05] <LocutusOfBorg> :)
[09:06] <mwhudson> i'm surprised the package builds, but it does
[09:06] <mwhudson> LocutusOfBorg: dammit
[09:06] <LocutusOfBorg> I read your mail to ubuntu-devel list, and looked at it already, but I'll do a deeper look
[09:06] <mwhudson> ubuntu-make is confusing me
[09:06] <LocutusOfBorg> that one too, meh, strange
[09:06] <LocutusOfBorg> only on some archs, it makes no sense
[09:07] <LocutusOfBorg> maybe a meld of the good vs bad arch can show some stuff with new version built only partially
[09:11] <LocutusOfBorg> pex uploaded, lets hope
[09:11]  * LocutusOfBorg leaves changing network
[09:14] <mapreri> mwhudson: the problem wrt diffoscope is that its behaviour when an external command fails is quite hardwired, and 1. changing it only for the elf comparator is just not possible without rewriting everything or doing very nasty hacks 2. changing it for all comparators is sure to have unintended effects
[09:14] <mapreri> I suppose we could figure something out, but…
[09:25] <mwhudson> mapreri: that was the impression i got
[09:25] <mwhudson> mapreri: a wrapper around readelf? :)
[09:25] <mapreri> mwhudson: That's an example of nasty hack :3
[09:26] <mapreri> besides, the elf comparator is so complex by itself
[09:26] <mwhudson> mapreri: people working on transitions get good at nasty hacks :)
[09:26] <mapreri> why are elf files so complex
[09:26] <mapreri> everything should be an interpreted language
[09:26] <Unit193> Sloooow.
[09:34] <mwhudson> zip should be good enough for everyone
[09:42] <ricotz> mwhudson, regarding python-transition: boost is not a false positive
[10:18] <LocutusOfBorg> mwhudson, python-pex is fixed, and I emailed the patch to Barry
[10:29] <doko> jamespage: #1698350, missing bug subscribers
[10:30]  * jamespage looks
[10:30] <jamespage> bug logfile not supported in this QEMU binary
[10:30] <jamespage> bug 1698350
[10:33] <jamespage> doko: done - commented on bug
[10:36] <LocutusOfBorg> mwhudson, for some reasons pex is not fixed
[10:42] <doko> jbicha: I see you changed the myspell-* seed stuff in supported. I'd like to demote dict-nr dict-ns dict-ns dict-st dict-tn dict-ts dict-xh (ftbfs and not updated for years). How would that be done?
[10:42] <doko> Laney: ^^^
[10:52] <LocutusOfBorg> mwhudson, fixed now, the testsuite was running correctly and returning 120, what a mess
[10:57] <mwhudson> ricotz: oh right i guess it needs a rebuild for that one extension module it rebuilds
[11:00] <mwhudson> mapreri, doko: here's the binutils patch that might fix the diffoscope build http://paste.ubuntu.com/25161894/
[11:00] <mwhudson> (testing diffoscope build with those packages now)
[11:00] <mapreri> that's basically a revert of the regressing upstream commit, right?
[11:02] <doko> mwhudson: is this just reverting an upstream commit?
[11:03] <doko> is this somewhere tracked?
[11:03] <mapreri> doko: https://sourceware.org/bugzilla/show_bug.cgi?id=21820
[11:04] <mwhudson> doko: yeah it's reverting the commit mentioned in the bugzilla
[11:04] <mwhudson> (with some fixups)
[11:05] <mwhudson> oh ffs doesn't fix the build??
[11:05] <mwhudson> ah no, holding it wrong
[11:06] <mwhudson> i love[0] the way sbuild --extra-package x does not fail if x does not exist [0] may be a lie
[11:06] <doko> ta, tracking the issue
[11:07] <ginggs> doko: hi, any objections to a tbb sync? i have test-built a couple of rdeps, and i'll keep a lookout for any new failures
[11:07] <mwhudson> i noticed that readelf exits with code 0 if you try to read a *missing* section
[11:07] <doko> mwhudson: can you attach the object file to the bug report, just in case ...
[11:07] <mwhudson> so exiting with code 1 for a present, empty, section must be a bug
[11:07] <doko> ginggs: from experimental?
[11:08] <ginggs> doko: yes, from experimental, including the multiarch
[11:08] <doko> ginggs: sounds fine. we need it for GCC 7 anyway
[11:08] <ginggs> doko: ta
[11:11] <mwhudson> doko: done
[11:15] <mwhudson> well that patch doesn't fix the build completely :(
[11:15] <mwhudson> mapreri: does http://paste.ubuntu.com/25161949/ mean anything to you?
[11:16] <mapreri> yes, that should be fixed with the last upload I think
[11:16] <mapreri> at least I remember noticing it, and doing something to fix it.
[11:16] <mapreri> ah, no, only in git still :(
[11:16] <mapreri> mwhudson: https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=c8927db98131a129c5d7354bfe8a6b0886ca66f8 + https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=e62306e17e8a9b981d3b7f427bc99f8582a0301a is what I did to fix it.
[11:17] <mapreri> I thought that was released already, but apparently I did it right after the last release was cut :S
[11:17] <mapreri> (+ https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=c12bee5fc718c918d6280102d4dbe688b0a553cf)
[11:27] <mwhudson> mapreri: time for an upload then? :)
[11:27]  * mwhudson goes to bed
[11:27] <mapreri> mwhudson: currently git doesn't pass the test as somebody did an incomplete addition... also would love to fix the autopkgtest also in debian :S
[11:50] <hjd> Looks like the jruby and ruby-psych packages have a circular dependency on artful https://launchpad.net/ubuntu/artful/amd64/+builds?build_text=&build_state=depwait
[11:51] <hjd> Anyone around to do a bootstrap or should I file a bug report on it? :)
[12:12] <ahasenack> hi, could someone please sponsor https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1644428 ?
[12:12] <LocutusOfBorg> mwhudson, done
[12:12] <ahasenack> it's a 2nd time regression, and a patch/MP has been up for weeks
[12:13] <LocutusOfBorg> ahasenack, zesty-updates version + patch on comment #32?
[12:13] <ahasenack> LocutusOfBorg: yes (the MP has been up for longer, but that's an internal problem I think that no-one looks at it)
[12:14] <LocutusOfBorg> Hunk #1 FAILED at 1.
[12:14] <LocutusOfBorg> 1 out of 1 hunk FAILED -- saving rejects to file debian/changelog.rej
[12:14] <LocutusOfBorg> please rebase it
[12:14] <ahasenack> of course...
[12:14] <ahasenack> story of my life :)
[12:14] <ahasenack> will get to it
[12:15] <LocutusOfBorg> meh I can do it
[12:15] <LocutusOfBorg> nvm
[12:15] <LocutusOfBorg> debdiff is trivial
[12:17] <jbicha> doko: the 'supported' seed was updated to match language-selector's data/pkg_depends
[12:18] <ahasenack> LocutusOfBorg: thanks
[12:18] <LocutusOfBorg> done yw
[12:21] <LocutusOfBorg> mwhudson, isn't the botch failure some sort of missing sorting for the output?
[12:41] <rbasak> jbicha: o/
[12:42] <rbasak> jbicha: in bug 1698553, are you saying that the ppc related bit of the diff definitely isn't a regression? Or are you not commenting on that bit?
[12:44] <rbasak> I suppose if autoreconf has always been running then it shouldn't matter, but I'm not sure exactly how to confirm that.
[12:49] <jbicha> you can confirm autoreconf is running by checking the build logs, here's the artful build which should be pretty similar
[12:49] <jbicha> https://launchpad.net/ubuntu/+source/gjs/1.48.5-0ubuntu1
[12:49] <jbicha> I don't know anything about what autotools does to ppc except that 1.48.5 built on artful for all supported Ubuntu arches
[12:50] <jbicha> dh simple rules with debhelper compat 10 in zesty will run dh_autoreconf unless it's turned off (which isn't the case here)
[12:52] <rbasak> by "that", I meant the "shouldn't matter" part, not that autoconf has always been running. Sorry I wasn't clear.
[13:38] <smoser> Logan, i'll read... process... we dont really have a process at the moment.  the three members were just the people that kind of kick-started this. ultimately the goal is to have bot-only doing imports.
[13:39] <smoser> Logan, still there ?
[13:42] <ricotz> jbicha, hi, regarding mozjs52 I haven't spot something obvious yet
[13:43] <ricotz> jbicha, the "autoreconf" patch is done with a ubuntu/debian toolchain?
[13:45] <jbicha> ricotz: it came from https://github.com/ptomato/mozjs/commit/740bc5d9d66433370ba4137d03390d5ee21f26b4
[13:50] <smoser> i think i misunderstood...
[13:53] <ricotz> jbicha, so you don't know, is autoconf2.13 going away? otherwise I would suggest to keep the "real autoreconf"
[14:31] <xnox> mwhudson, all i can say is that even diffoscope master FTBFS with old binutils and python3.6
[14:31] <xnox> https://launchpadlibrarian.net/330406667/buildlog_ubuntu-artful-amd64.diffoscope_85~ubuntu1_BUILDING.txt.gz
[15:05] <ginggs> doko: nice, your blender rebuild exercised the new tbb
[17:08] <ahasenack> after verifying the fix for all affected releases, should I flip the global "verification-needed" tag to "verification-done"? Case in point: https://bugs.launchpad.net/ubuntu/+source/openvpn-auth-ldap/+bug/1602813
[17:08] <ahasenack> I did set verification-done-$release for all affected releases after testing
[17:49] <tsimonq2> Logan: ack
[18:32] <bdmurray> Why does autopkgtest end up using a lot of space on my / mount when I am using a qemu image on a different mount point?
[18:48] <xnox> i thought it does a cow snapshot, to keep the golden image unmodified, and stores the copy-on-write layer somewhere in /tmp no?
[18:48] <bdmurray> Could be, I haven't dug into it.
[20:29] <tsimonq2> Is there a Core Developer available that would be able to help me with a Qt transition? I need a couple more rebuilds in the PPA then someone will need to land it. Details here: https://bileto.ubuntu.com/#/ticket/2819
[20:31] <tsimonq2> Before that's landed though, I think we need to get the rest of the Unity 8 removals done so that there's minimal impact on the transition.
[20:31] <tsimonq2> mitya57 went on vacation, so I'll be on my own for this one.
[20:31] <tsimonq2> He told me before he left that slangasek had more information... what's new?
[21:48]  * mwhudson is lost in a maze of britney output :(
[21:48] <mwhudson> why is hunspell not migrating?
[21:51] <jbicha> mwhudson: because of libreoffice which depends on python3-defaults
[21:51] <mwhudson> ah
[21:51] <mwhudson> same old story
[21:53] <mwhudson> i think the link-grammar autopkgtests are now failing because the build the package with some of proposed enabled and then switch to running it with all of propsed
[21:53] <mwhudson> or something along those lines
[21:57] <mwhudson> need an aa to apply some force to this migration i think
[22:51] <mwhudson> ok lets see if i can fix ubuntu-make today
[23:04] <jbicha> LO i386's autopkgtest would need to be ignored too


[15:01] <mschemerii> Good Morning, everyone!
[15:01] <cody-somerville> Morning! :)
[15:02]  * cody-somerville stretches.
[15:02] <charlie-tca> morning :-)
[15:02] <vinnl> Good afternoon ;-)
[15:02] <jeromeg> hey everybody
[15:02] <cody-somerville> I hope Jim hasn't gotten got caught up in the winter weather
[15:03] <j1mc> hi all
[15:03] <vinnl> Speaking of the devil :)
[15:03] <j1mc> sorry i'm late  :)
[15:03] <cody-somerville> \o/
[15:03] <vinnl> Wow, everybody;s here :)
[15:03] <JPohlmann> Morning ;)
[15:03] <j1mc> morning :)
[15:03] <JPohlmann> Just woke up, it's 4pm
[15:03] <j1mc> heh
[15:04] <mschemerii> just woke up, myself... 10am
[15:04] <cody-somerville> JPohlmann, still on California time? ;]
[15:04] <j1mc> hi mschemerii
[15:04] <JPohlmann> cody-somerville: Kinda, yeah
[15:05] <mschemerii> Hi Jim
[15:05] <mschemerii> Anyone else need some coffee?
[15:05] <charlie-tca> got mine; 8 am :-)
[15:06] <j1mc> i do
[15:06] <j1mc> shall we get started?
[15:06] <vinnl> I need it but can't drink it :P
[15:06] <cody-somerville> Sounds splendid! :)
[15:06] <vinnl> Yeah
[15:06] <cody-somerville> j1mc, do you want to chair?
[15:06] <knome> sorry.
[15:06] <vinnl> Just in time :)
[15:06] <knome> :)
[15:07] <j1mc> cody-somerville: sure
[15:07] <knome> fire it up
[15:07] <j1mc> so, topics for today: https://wiki.ubuntu.com/Xubuntu/Meetings
[15:08]  * cody-somerville wonders if we should use moot bot
[15:08] <j1mc> let's get started with a recap of outcomes from UDS.  cody?
[15:08] <j1mc> I would, but I don't think this meeting is "on the fridge"
[15:08] <cody-somerville> It is
[15:08] <j1mc> #Startmeeting
[15:08] <cody-somerville> I added it :]
[15:08] <MootBot> Meeting started at 09:08. The chair is j1mc.
[15:08] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:09] <j1mc> all right, we are in motion now then
[15:09] <j1mc> #topic - updates from UDS
[15:09] <cody-somerville> I think it is: [TOPIC]
[15:09] <j1mc> [TOPIC] Updates from UDS
[15:09] <MootBot> New Topic:  Updates from UDS
[15:10] <cody-somerville> Alrighty, I guess I'll go first.
[15:11] <cody-somerville> Unfortunately I didn't get to participate in the all the great sessions as much as I would have liked on a count of being sick most of UDS, a close friend dying while I was down in San Francisco :(, and being busy with OEM Services stuff. However, from the sessions I did participate in and the time I was able to spend with the folks from the Xubuntu community, I'd say overall it was a very productive get together.
[15:11] <cody-somerville> We discussed a number of import issues, built friendships, got a better understanding for how each other work (specifically with regards to Xfce4, thanks to Jannis for making the long trip), and fleshed out some ideas for Jaunty
[15:11] <cody-somerville> *important
[15:12] <cody-somerville> Among our accomplishments at UDS, we: fleshed out a first draft roadmap for Jaunty, discussed artwork for Jaunty
[15:12] <cody-somerville> discussed how to grow the Xubuntu community, and plans for xfce 4.6 in Jaunty
[15:13] <cody-somerville> The jist of our discussions are documented in gobby documents at gobby.ubuntu.com
[15:13] <cody-somerville> I'm hoping to turn them into specs (or get people to volunteer to turn them into specs)
[15:14] <cody-somerville> If nobody has any questions, I'll pass the floor to knome
[15:15] <mschemerii> question
[15:15] <j1mc> knome: i know we talked some about artwork and such
[15:15] <cody-somerville> mschemerii, shoot :)
[15:15] <mschemerii> I find nothing at gobby.ubuntu.com... can you point me to a how to so I can access it properly?
[15:15] <knome> Ok, I'll start recapping now:
[15:15] <JPohlmann> mschemerii: You'll have to use the gobby editor
[15:16] <mschemerii> ok... thanks... sorry to interrupt
[15:16] <JPohlmann> mschemerii: And then connect to gobby.ubuntu.com:6522
[15:16] <knome> I think it was really great to meet the guys at UDS and we definitely were productive. Also it was nice to get in touch with the Ubuntu community in general to make some connections with other artists and teams which might be able to help us.
[15:17] <knome> Even if Cody wasn't available all times, we got work done and things going forward - and fast.
[15:17] <knome> Next one?
[15:18] <j1mc> Sure - we also had a meeting about xubuntu and xfce documentation.
[15:19] <knome> (I have to leave in 15mins, but I will be back later, hopefully before the session ends.)
[15:19] <j1mc> The Xfce user guide wasn't fully updated for Xfce 4.4, and will need to be updated for 4.6
[15:19] <j1mc> JPohlmann suggested pooling people together from different distros to work on the Xfce 4.6 user guide.
[15:20] <JPohlmann> And the end user docs for applications like xfce4-settings.
[15:20] <j1mc> We discussed having a session on IRC where xfce developers could outline how the components of Xfce work together to build the desktop environment
[15:20] <j1mc> to help orient potential documentors
[15:20] <jeromeg> as a side note, I sent a patch a few days ago to update the xfdesktop documentation
[15:21] <j1mc> jeromeg: woot.  :)  we had discussed what could be done to get the docs into a consistent state
[15:21] <j1mc> for ppl to work on them
[15:21] <j1mc> and how these docs might integrate with Xubuntu system docs
[15:22] <j1mc> . . . so that's my doc discussion recap
[15:22] <JPohlmann> Ok
[15:22] <JPohlmann> Guess it's my turn then
[15:22] <cody-somerville> (j1mc, I'd be interested in seeing a follow up meeting for those interested in Xubuntu documentation and the into-distro collaboration on xfce4 docs)
[15:22] <cody-somerville> ( j1mc, can you take that action item )
[15:23] <j1mc> cody-somerville: me, too - ok.  I invited mschemerii here - he's interested in working on xubuntu docs
[15:23]  * cody-somerville nods.
[15:23] <cody-somerville> JPohlmann, sorry for interrupting :)
[15:23] <JPohlmann> It's ok ;)
[15:24] <j1mc> [ACTION] Jim follow-up on xubuntu-doc meeting
[15:24] <MootBot> ACTION received:  Jim follow-up on xubuntu-doc meeting
[15:25] <JPohlmann> The session about how components work together was intended to be some kind of kick-off session, but maybe we should create a schedule where we first have a generic kick-off session, then a session to explain how things work together and then a session on how to organize the team etc.
[15:25] <JPohlmann> I guess Jim and I could work that out.
[15:26] <j1mc> JPohlmann: sounds good.
[15:26] <j1mc> do you think it would be better to hold that meeting on #xfce?
[15:28] <JPohlmann> Haven't thought about that yet
[15:28] <j1mc> ok
[15:28] <jeromeg> we could even create a xfce-dev channel ?
[15:28] <jeromeg> oups
[15:28] <jeromeg> xfce-doc
[15:28] <knome> (I'm leaving now, I'll be back ASAP.)
[15:28] <JPohlmann> See you Pasi
[15:28] <cody-somerville> (gak, we're almost 30 minutes into the meeting, we need to hurry up!)
[15:28] <j1mc> yah
[15:28] <JPohlmann> Ok
[15:28] <JPohlmann> Then let me just recap
[15:30] <JPohlmann> So, first of all it was great meeting (almost) everybody and being able to discuss face-to-face. I think after the docs session, we have a rough idea in mind on how this collaboration could work at least. I'm really hoping that we can form a joint team for that.
[15:32] <JPohlmann> One thing that clearly needs more discussion is *how* we want the documentation to be written and with which technologies.
[15:32] <JPohlmann> We also discussed the main complaints in Xubuntu and how to solve them for jaunty, like disappearing panels, non-fd.o-compliant menu, samba/network browsing in Thunar etc.
[15:32] <j1mc> non-fd.o-compliant menu.  :(
[15:32]  * j1mc glares at menu
[15:32] <j1mc> :)
[15:33] <j1mc> anything else, JPohlmann
[15:33] <JPohlmann> I think NCommander started to backport Xfce 4.4.3 to intrepid I think.
[15:33]  * cody-somerville nods.
[15:34] <JPohlmann> And the idea to port the user switcher applet to the xfce panel came up. Not sure who's going to work on that though ;)
[15:34] <JPohlmann> I guess that's it.
[15:34] <JPohlmann> j1mc: The menu issue is already solved by having a fd.o-compliant menu implementation in Xfce 4.6.
[15:34] <cody-somerville> Awesome \o/
[15:34] <JPohlmann> (Even though it's not feature-complete)
[15:34] <j1mc> :)
[15:34] <j1mc> anything else on UDS?
[15:35] <jeromeg> guys, I need to leave in a second, just want to say a word about xfce4-screenshooter
[15:35] <jeromeg> if you guys agree ?
[15:35] <j1mc> sure
[15:35] <cody-somerville> jeromeg, sure :)
[15:35] <jeromeg> I'm maintaining it since august
[15:35] <jeromeg> cody told me you consider it for inclusion in jaunty
[15:35] <jeromeg> please tell me in you have any thoughts/requests/bug reports on this app
[15:36] <jeromeg> I'll release a new version around the 5 of January
[15:36] <jeromeg> featuring a "select a region feauture"
[15:36] <jeromeg> and copy to clipboard
[15:36] <jeromeg> + full documentation + interface cleanup
[15:36] <j1mc> jeromeg: sounds good!
[15:36] <jeromeg> that's all, I'm done :)
[15:36] <JPohlmann> Wow
[15:37] <jeromeg> thanks to David Collins, a user who submitted some great patches !
[15:37] <j1mc> :)
[15:37] <jeromeg> (xubuntu user btw ;) )
[15:38] <cody-somerville> w00t
[15:38] <j1mc> anything else on this, jeromeg or cody-somerville ?
[15:38] <jeromeg> nope
[15:38] <j1mc> next topic?
[15:38] <cody-somerville> I'd just like to give jeromeg a big kudos for maintaining that app :)
[15:38] <cody-somerville> j1mc, sounds good
[15:38] <jeromeg> got to go, see you guys, that was a pleasure
[15:38] <j1mc> +1 for jeromeg - see you!
[15:38] <j1mc> [TOPIC] Jaunty xubuntu-team meeting schedule
[15:38] <MootBot> New Topic:  Jaunty xubuntu-team meeting schedule
[15:39] <j1mc> how often do we want to have these meetings during this cycle?
[15:39] <j1mc> once a month?
[15:39] <cody-somerville> I propose an official meeting monthly
[15:39] <cody-somerville> but I encourage sub-teams to get together as often as they'd like
[15:40] <cody-somerville> and I definitely encourage spontaneous meetings in #xubuntu-devel when ever people fancy :)
[15:40] <j1mc> that sounds good to me.  anyone else?
[15:40] <JPohlmann> I agree with Cody
[15:40] <charlie-tca> +1
[15:40] <j1mc> Would Saturdays generally work for everyone?
[15:41] <cody-somerville> Yea, I think as long as we get reminders out
[15:41] <JPohlmann> Depends on the time. Sunday afternoons are usually better for me.
[15:41] <vinnl> Depends
[15:41] <cody-somerville> lol
[15:41] <cody-somerville> :P
[15:41] <vinnl> Same here
[15:42] <j1mc> move them to sundays then?
[15:42] <vinnl> +1
[15:43] <j1mc> We'll move them to Sundays and see how things work.  I'll try to avoid major holiday weekends.
[15:43] <JPohlmann> Sounds fine
[15:43] <j1mc> next topic then :)
[15:43] <j1mc> [TOPIC] Finalize Jaunty roadmap
[15:43] <MootBot> New Topic:  Finalize Jaunty roadmap
[15:43] <cody-somerville> Okay
[15:43] <cody-somerville> knome was nice enough to update the wikipage for us
[15:44] <cody-somerville> So please take a look at https://wiki.ubuntu.com/Xubuntu/Roadmap
[15:44] <JPohlmann> We definitely need more subpages for the bigger items like "Implement Xfce 4.6".
[15:44]  * cody-somerville nods.
[15:44] <JPohlmann> We can also move some content from the gobby documents there.
[15:45] <cody-somerville> JPohlmann, agreed
[15:45] <cody-somerville> Here are the main objectives I currently propose for Jaunty:
[15:45] <cody-somerville>  * Grow the Xubuntu Community (xubuntu-community)
[15:45] <cody-somerville>  * Refresh distro artwork (xubuntu-artwork)
[15:45] <cody-somerville>  * Update the documentation via improved collaberation with Xfce doc team (xubuntu-xfce-documentation)
[15:45] <cody-somerville>  * Implement Xfce 4.6 (xubuntu-xfce)
[15:45] <cody-somerville>  * Thunar Improvements: Implement Samba Browsing & Thunar meta-data pane
[15:45] <cody-somerville>  * Port user switcher applet to the Xfce panel
[15:46] <vinnl> Hmm, there's some deprecated specs ther
[15:46] <vinnl> *e
[15:46] <JPohlmann> I can probably move the content and create status tables and whatnot.
[15:46] <cody-somerville> vinnl, such as?
[15:47] <vinnl> The website thing
[15:48] <cody-somerville> Where do you see website stuff?
[15:49] <j1mc> "Xubuntu Website Plan"
[15:49] <mschemerii> Specifications
[15:50] <j1mc> cody-somerville: re: samba - are you considering modifying thunar, and pushing changes upstream?
[15:50] <cody-somerville> j1mc, there is already a patch for thunar
[15:50] <j1mc> also, have you seen the newly-proposed xfce app to assist with mounting shares?
[15:50] <cody-somerville> j1mc, and the patches are upstream
[15:50] <j1mc> ok
[15:50] <cody-somerville> j1mc, however, the samba patch won't be accepted
[15:50] <cody-somerville> but JPohlmann is working on gio for Thunar
[15:51] <cody-somerville> so we'll drop our samba patch once thats done
[15:51] <cody-somerville> and I'm packaging sion for Ubuntu right now
[15:51] <mschemerii> the goodies project has thunar-shares-plugin
[15:51] <JPohlmann> Which is probably after jaunty.
[15:51] <cody-somerville> yup
[15:51] <cody-somerville> mschemerii, there is another patch too :)
[15:51] <cody-somerville> mschemerii, (for browsing)
[15:51] <j1mc> sounds good, cody-somerville.  thanks for clearing that up.  i didn't know the status on those items
[15:51] <JPohlmann> That's what we can put on a subpage for "Thunar improvements"
[15:52]  * cody-somerville nods.
[15:52] <cody-somerville> Okay, so if folks can indicate their general approval of the listed main objectives via +1 or +0 it would be greatly appreciated. I'll make a decision later today and mail the xubuntu-devel ml.
[15:53] <mschemerii> +1
[15:53] <charlie-tca> +1
[15:53] <vinnl> +!
[15:53] <vinnl> *+1
[15:54] <j1mc> I don't see anything objectionable in there.  :)  +1
[15:54] <cody-somerville> +1
[15:55] <j1mc> I have some community ideas - I'll add them to the community wiki page, and will also link to some of my doc roadmap stuff from that page.
[15:55] <JPohlmann> +1
[15:55] <j1mc> moving on, then?
[15:56]  * cody-somerville nods.
[15:56] <j1mc> [TOPIC] Xubuntu QA/Testing Lead Candidate Charlie Kravetz
[15:56] <MootBot> New Topic:  Xubuntu QA/Testing Lead Candidate Charlie Kravetz
[15:56] <JPohlmann> \o/
[15:56] <j1mc> +1 \o/
[15:57] <charlie-tca>  /me too \o/
[15:58] <cody-somerville> charlie-tca, :)
[15:58] <cody-somerville> charlie-tca, It is understood that you'd like to take on the responsibility of leading Xubuntu QA/Testing efforts. Is this correct? :)
[15:58] <charlie-tca> it is correct.
[15:58] <JPohlmann> http://www.youtube.com/watch?v=1G_YueJ8Wos
[15:58] <MootBot> LINK received:  http://www.youtube.com/watch?v=1G_YueJ8Wos
[15:59] <cody-somerville> charlie-tca, could you tell us about your experience working on QA and Testing efforts in the Ubuntu and Xubuntu community?
[15:59] <JPohlmann> Big la ola for charlie ;)
[16:00] <charlie-tca> I am a member of bugsquad and bug-control. I have been in the top 5 for bug triage the last 2 months
[16:00] <cody-somerville> :D
[16:00] <j1mc> w00t!!
[16:00] <vinnl> JPohlmann, omg, over-synchronising really _can_ ruin even the best shows :P
[16:00] <cody-somerville> charlie-tca, how would you rally the community to help triage Xubuntu bugs and test image candidates?
[16:00] <charlie-tca> I did a lot of testing for the intrepid release, and found 3 major bugs before the final release
[16:01] <JPohlmann> vinnl: True ;)
[16:01] <charlie-tca> We need to hold regular bug days and testing days for xubuntu
[16:01] <charlie-tca> The ones we had for intrepid were very successful.
[16:02] <charlie-tca> The bug triage is very manageable right now, with less than 100 triaged
[16:02] <charlie-tca> no, to be triaged
[16:02] <vinnl> Mostly thanks to your hard work :)
[16:03] <charlie-tca> We show 52 testers in launchpad, I need to get them more involved in testing before the releases
[16:03] <mschemerii> right on...
[16:03] <cody-somerville> charlie-tca, what do you think about starting a 5-a-day bug team?
[16:03] <mschemerii> ;)
[16:04] <charlie-tca> I don´t know if that will work. Some people will feel preasured to get 5 no matter what, and that defeats the purpose of it
[16:04] <charlie-tca> Perhaps we should discuss it though.
[16:05] <charlie-tca> If it will help keep the bugs triaged, we should work on it.
[16:05] <charlie-tca> Also, we have many confirmed bugs that should be sent upstream
[16:05] <j1mc> charlie-tca: i noticed that you updated the xubuntu-testing wiki pages the other day - it's great that you are getting things in sync with the ubuntu QA team
[16:06]  * cody-somerville nods.
[16:06] <charlie-tca> Yes, I'm still working on them. I would like to have the long format testing become extended tests from the qa page
[16:06] <JPohlmann> I have to leave in a few minutes, so just for the record: Brian is planning to add the launchpad integration to the Xfce bugzilla.
[16:06] <cody-somerville> charlie-tca, Getting the wiki up2date with test cases and what not I think would be a key objective for someone taking on this role. Do you agree charlie-tca?
[16:06] <cody-somerville> JPohlmann, w00t
[16:07] <charlie-tca> yes. They need considerable work yet.
[16:07] <charlie-tca> I have updated the QA test cases already
[16:08] <charlie-tca> It makes it much easier to make sure the pre-release is really ready for the users
[16:08] <j1mc> we're kind of getting into our next topic area (QA Efforts for the Jaunty cycle)
[16:08]  * cody-somerville nods.
[16:08] <cody-somerville> I think we can all agree charlie-tca will do a great job
[16:08] <JPohlmann> Yes
[16:08] <j1mc> definitely
[16:09] <cody-somerville> charlie-tca, Would you accept the role of the Xubuntu QA Lead?
[16:09] <charlie-tca> Yes, gladly
[16:09] <j1mc> w0000t  :)
[16:09] <JPohlmann> I've made a note to move contents from the gobby documents to the roadmap subpages. Leaving now. See you guys!
[16:09] <vinnl> \o/
[16:10] <j1mc> later, JPohlmann
[16:10] <vinnl> Bye\
[16:10] <j1mc> +1111ONE!ONEWON1 for charlie-tca
[16:11] <cody-somerville> :)
[16:11] <cody-somerville> Welcome to the team charlie-tca
[16:11] <vinnl> ^^What he said :)
[16:11] <charlie-tca> Thanks. I will do my best!
[16:11] <j1mc> :)
[16:11] <cody-somerville> charlie-tca, Can you please pm me your launchpad id?
[16:11] <mschemerii> \0/
[16:12] <charlie-tca> Okay
[16:12] <j1mc> next topic then.  :)
[16:12] <j1mc> [TOPIC] Discuss QA efforts & plans for Jaunty cycle
[16:12] <MootBot> New Topic:  Discuss QA efforts & plans for Jaunty cycle
[16:12] <cody-somerville> Few ideas I have include:
[16:12] <j1mc> charlie-tca and cody-somerville :)
[16:12] <cody-somerville> 1. Have a list on the wiki with people we know can do certain tests
[16:13] <cody-somerville> So that we can bug them easily to do them :)
[16:13] <cody-somerville> 2. charlie-tca should accept the action item of sending reminders to the mailing list about the upcoming dates where we'll need to get tests done for a release.
[16:14] <charlie-tca> good idea
[16:15] <cody-somerville> 3. charlie-tca should send an e-mail to the ml about how to subscribe to certain tests (a feature provided by the iso qa tracker)
[16:15] <j1mc> cody-somerville: i think that the ubuntu-qa site also sends out email reminders about tests that testers can sign up for
[16:15]  * cody-somerville nods.
[16:15] <j1mc> still, it would be good to have a bit more advance notice via the ML
[16:16] <cody-somerville> j1mc, maybe we can setup an account on it and put the ml as the address
[16:16] <cody-somerville> that way the list gets notified automagically :)
[16:16] <charlie-tca> I think qa don´t remember good
[16:16] <cody-somerville> charlie-tca, hmm
[16:16] <cody-somerville> ?
[16:16] <j1mc> true - but we only get updated on the day the test gets requested - on testing day
[16:16] <cody-somerville> okay
[16:17] <cody-somerville> j1mc, I think we should put the dates into a google calendar too
[16:17] <cody-somerville> that way I can get sms reminders :)
[16:17] <charlie-tca> I subscribe to the tests, etc, but they don´t send reminders out on time
[16:17] <j1mc> :)
[16:17] <cody-somerville> charlie-tca, maybe you can work with the QA team to get that fixed
[16:17] <cody-somerville> that would be awesome
[16:18] <charlie-tca> Okay, I´ll do that
[16:18] <j1mc> [ACTION] charlie-tca sends out email notices to remind about testing
[16:18] <MootBot> ACTION received:  charlie-tca sends out email notices to remind about testing
[16:18] <j1mc> [ACTION] charlie-tca check with ubuntu-qa team to make sure auto-reminders get sent out on time
[16:18] <MootBot> ACTION received:  charlie-tca check with ubuntu-qa team to make sure auto-reminders get sent out on time
[16:19] <j1mc> [AGREED] charlie-tca will be super-awesome as xubuntu-qa and testing lead
[16:19] <MootBot> AGREED received:  charlie-tca will be super-awesome as xubuntu-qa and testing lead
[16:19] <j1mc> :P
[16:19] <vinnl> +1 :P:
[16:19] <cody-somerville> charlie-tca, is there any tools or infrastructure that we could whip up to make stuff easier for you?
[16:20] <cody-somerville> charlie-tca, thinking now about both iso testing and bug triage
[16:20] <j1mc> good question, cody-somerville
[16:20] <charlie-tca> Not that I can think of. I'm still learning some of the tools. I would like qa´s traker expanded for us.
[16:20] <charlie-tca> I need to work with them on that.
[16:21] <j1mc> charlie-tca: are there any bookmarks you have set in your browser to help you perform searches for bugs at a certain status that are particular to xubuntu packages?
[16:21] <j1mc> the ubuntu-bugjam page has a set of links to launchpad searches.  maybe we could put up similar links on the xubuntu wiki.
[16:21] <charlie-tca> Yes, many. The two biggest are the Xubuntu packages, and all new bugs with xubuntu in them
[16:22] <charlie-tca> I'm hoping to do that, j1mc
[16:22] <charlie-tca> I have to work the bug triage wiki page yet
[16:22] <cody-somerville> charlie-tca, what do you think about making the xubuntu-testers team moderated? Giving you a queue of people to get in contact with and ensure they know what they need to do to help so that they can?
[16:23] <charlie-tca> That could work
[16:24] <charlie-tca> Right now there is no approval needed, but I don´t think most of those signed up do testing on the iso
[16:24]  * cody-somerville nods.
[16:24]  * j1mc nods
[16:24] <cody-somerville> charlie-tca, if thats something you'd like to do, feel free to do so
[16:24] <charlie-tca> Many are running the release, and just making updates
[16:25] <charlie-tca> I'll give it some thought
[16:25] <mschemerii> It would be great to know what specific things need/want testing in both Intrepid and Jaunty
[16:26] <cody-somerville> I think thats where the test cases come in
[16:26] <mschemerii> for Xubuntu, that is
[16:26] <j1mc> when i sent out notes to the xubuntu-users mailing list requesting help with testing, i usually got a decent response
[16:26] <cody-somerville> I think we need to make them more prominent and easier to find
[16:26] <charlie-tca> That´s why I´m working the wiki page
[16:26]  * cody-somerville nods.
[16:26] <j1mc> :)
[16:26] <vinnl> Dinner time here
[16:27] <j1mc> anything else on xubuntu-qa for now?
[16:27] <charlie-tca> I want people to find the test cases from Xubuntu wiki, not by knowing the qa website
[16:27] <vinnl> Don't think I'll be back before the end of the meeting, so good luck with it :)
[16:28] <j1mc> thanks for being here, vinnl
[16:28] <charlie-tca> I´m done now
[16:28] <j1mc> cody-somerville - anything else?
[16:28] <cody-somerville> We're now at 1.5hrs so I think we should wrap up
[16:28] <j1mc> quickly then
[16:28] <j1mc> [TOPIC] Team updates (Packaging, Bug Triage, Development / Coding, Testing, Documentation, Artwork)
[16:28] <MootBot> New Topic:  Team updates (Packaging, Bug Triage, Development / Coding, Testing, Documentation, Artwork)
[16:28] <cody-somerville> One thing I'd like to say to everyone
[16:29] <cody-somerville> j1mc charlie-tca mschemerii gpocentek JPohlmann knome jeromeg etc. etc.: Please be sure to update the monthly team report in time each month! :)
[16:30] <j1mc> cody-somerville: ok
[16:30] <cody-somerville> We'll finish up the agenda at the next meeting :)
[16:30] <mschemerii> cody-somerville: ok
[16:30] <j1mc> sounds good.  :)
[16:30] <charlie-tca> cody-somerville: okay
[16:30] <cody-somerville> I'll write an e-mail to the list to recap this meeting
[16:30] <cody-somerville> and to announce other initiatives for Jaunty
[16:30] <j1mc> thanks for making it, everyone
[16:30] <cody-somerville> \o/
[16:30] <cody-somerville> Indeed
[16:31] <cody-somerville> Thanks everyone!!
[16:31] <j1mc> #endmeeting
[16:31] <MootBot> Meeting finished at 10:31.
[16:32] <knome> duh
[16:33] <j1mc> :)
[16:33] <mschemerii> Hey Jim
[16:33] <mschemerii> nm... he left ;)


 It's far enough away
[07:52] <duflu> Even further away it looks like the north of the state is flooding
[07:52] <marcustomlinson> ok I hope it stays that way
[08:02] <didrocks> hey marcustomlinson, callmepk
[08:38] <seb128> hey again desktopers
[08:39] <didrocks> salut seb128, ça va ?
[08:42] <seb128> lut didrocks, un peu decalqué niveau sommeil mais sinon ça va. Et toi ?
[08:42] <callmepk> hi seb128
[08:43] <seb128> hey callmepk
[08:44] <didrocks> seb128: ça va, les tracas habituel mais pas besoin de s’étaler dessus :)
[08:46] <duflu> Hi seb128
[08:59] <Wimpress> Morning desktoppers o/
[08:59] <duflu> Morning Wimpress
[08:59] <jibel> Good morning Wimpress
[09:02] <Laney> sup
[09:03] <seb128> hey Wimpress, jibel, Laney
[09:03] <duflu> Hi Laney
[09:03] <didrocks> hey Wimpress, jibel, Laney
[09:03] <seb128> oh and also hey duflu :-)
[09:05] <Laney> moin seb128 duflu et didrocks
[09:06] <oSoMoN> hey ho marcustomlinson, callmepk, seb128, Wimpress, Laney
[09:06] <seb128> lut oSoMoN!
[09:08] <jibel> salut didrocks
[09:09] <marcustomlinson> hey seb128 Wimpress Laney
[09:11] <seb128> hey marcustomlinson!
[09:21] <callmepk> hey Laney
[09:55] <Laney> hey oSoMoN marcustomlinson callmepk
[10:47] <ginggs> hi desktoppers!   i see some packages in merge-o-matic universe that used to be in main, e.g. fonts-vlgothic, fonts-ipaexfont, which are no longer maintained.  is it worth trying to keep the delta, or should they just be sync'd?
[10:51] <Laney> ginggs: Be better if those fontconfig files were upstreamed to Debian I guess; personally I think they're still valuable
[10:52] <ginggs> thanks Laney
[12:25] <Wimpress> seb128: Asking you since you're the last person on the desktop team to touch libdbusmenu.
[12:26] <Wimpress> I'm being asked if the developer running the Ayatana Indicator project could be the upstream for libdbusmenu?
[12:44] <seb128> Wimpress, didn't they fork the different indicator projects under new names? are they changing their mind on this now?
[12:44] <Wimpress> Yes, they did.
[12:45] <Wimpress> No, they are actively developing Ayatana Indicators. Recently the requirement to use patched GTK for IDO was removed in Ayatana Indicator.
[12:45] <Wimpress> They are actively expanding the portfolio of indicators.
[12:47] <seb128> well they did fork e.g libappindicator, I wish they had asked to take over those instead
[12:47] <seb128> anyway to reply to the original question, I'm not owning the project, I would personally be fine with it but I don't think I can take that decision
[12:52] <sunweaver> seb128: we forked many components under a new name.
[12:52] <sunweaver> for dbusmenu, my fear is that the impact on 3rd party projects might be immense.
[12:52] <sunweaver> But I haven't checked fully, yet.
[12:52] <Wimpress> seb128: Meet sunweaver. DD and one of the maintainers of Ayatana Indicators.
[12:52] <sunweaver> as of today, it would be easier to keep the dbusmenu namespace.
[12:52] <sunweaver> _o/
[12:52] <seb128> we exchanged email in the past
[12:52] <seb128> right
[12:53] <seb128> as it would have been easier to keep the libappindicator one
[12:53] <sunweaver> yeah, admittedly.
[12:53] <seb128> we wouldn't be in the situation now where different distro or desktop are on different forks
[12:53] <sunweaver> I was a bit hasty back then and did not count in the full impact.
[12:55] <sunweaver> so, back to dbusmenu... The UBports people and also us devs of Aytana Indicators heavily rely on dbusmenu and I wonder if it would be ok, to maintain it under the AyatanaIndicators umbrella.
[12:56] <sunweaver> thus avoiding the fork, but also releasing the dbusmenu code from CLA.
[13:04] <seb128> I would be fine with that but I'm not the position to decide that, Wimpress should be able to figure out where to ask though
[13:04] <seb128> would you be open to do the same for the other libraries or do you think that doesn't make sense now that they diverged?
[13:04] <sunweaver> seb128: thanks for this
[13:04] <sunweaver> seb128: which other libraries do you have in mind?
[13:05] <seb128> libayatana-appindicator vs libappindicator
[13:06] <sunweaver> hmmm...
[13:06] <seb128> Ubuntu still uses libappindicator as of today and libayatana-appindicator is in universe
[13:06] <sunweaver> I presume the libappindicator <-> libayatana-appindicator can-of-worms has been opened now.
[13:06] <seb128> well, probably similar situation for the indicators themselves
[13:06] <seb128> it's just a shame that we end up with different versions, there was no need for that
[13:07] <seb128> but we had the discussion over email at the time, or rather after fact, so that ship probably sailed by now...
[13:07] <sunweaver> the libappindicator fork could have been avoided. So a big sorry from my side. The fork of that library wasn't necessary, esp. not the name space change.
[13:07] <sunweaver> With the system indicators, it is different.
[13:07] <sunweaver> Ayatana System Indicators now work on a vanilla GTK 3
[13:07] <sunweaver> the GTK3 patch that Ubuntus ships is not necessary anymore.
[13:08] <seb128> that would have been a welcome change for the ubuntu indicators as well I think
[13:08] <sunweaver> Ubuntu Touch / UBports / Lomiri upstream is currently switching over to Ayatana Indicators, Ubuntu MATE has already switch, as well. So, for system indicators, I recommend trying Ayatana System Indicators and consider switching over.
[13:09] <sunweaver> The development is quite progressive and will be co-funded by the UBports foundation in the near future, I hope.
[13:10] <seb128> we don't use those indicators anymore for Ubuntu so I guess that's not for us to decide which variant is being used
[13:10] <sunweaver> What we could try to do in Ayatana Indicators is providing a drop-in replacement for libappindicator (esp. for the gir1.2-* packages), so that you don't have to port all applications.
[13:10] <seb128> well porting is not the issue
[13:10] <sunweaver> seb128: it's more for the flavours (like XFCE, lubuntu and such)
[13:11] <seb128> I think porting is fine enough
[13:11] <sunweaver> ok, then.
[13:11] <seb128> is that you end up having a choice to make between competing implementations
[13:11] <sunweaver> If you need any changes to libayatana-*, simply file a pull request on github.com/AyatanaIndicators and I'll be happy to process that.
[13:11] <seb128> which is a sucking situation to be in, especially where there was no reason to create the competing situation
[13:12] <seb128> right
[13:12] <sunweaver> I guess, at that time I felt quite helpless regarding having an impact on the code base
[13:13] <seb128> I've personally difficulties to get behind an hostile fork of opensource projects
[13:13] <seb128> but I should probably get over it there
[13:13] <sunweaver> I discussed various changes with David Barth around 2012 for the Unit Greeter, the patches ended in nirvana and I guess I should have tried again regarding indicators.
[13:13] <seb128> you didn't even try to reach out to ask if you could take over the upstream project at the time (what you are doing now today for libdbusmenu)
[13:13] <sunweaver> Also, at the time when I forked indicators, it became obvious that the projects were switching into sustainmaint-mode.
[13:14] <seb128> right, which would have been a perfect time to help them carry forward being becoming maintainer
[13:14] <sunweaver> seb128: I think, all I can say today is: I am tootaly sorry for my hastiness at that time.
[13:14] <seb128> thanks for saying that
[13:15] <sunweaver> It would have been the better approach to stick heads together. I realize that now (and also many times before, but haven't said it to the right person).
[13:16] <seb128> anyway, that said and going forward, I would support handing over libdbusmenu, I will try to see if I can help Wimpress with that request
[13:16] <seb128> and we need to revisit using libayatana-appindicator for Ubuntu
[13:16] <Wimpress> Thanks seb128
[13:16] <sunweaver> thanks for expressing your pain about it and exchanging thoughts here and now.
[13:17] <sunweaver> seb128: awesome and thanks!!!
[13:19] <seb128> np!
[13:20] <sunweaver> o/
[14:27] <hellsworth> good morning desktopers
[14:27] <jibel> Good morning hellsworth
[14:28] <hellsworth> hey jibel :)
[14:30] <seb128> hey hey hey
[14:31] <seb128> Wimpress, meeting? ;-)
[14:31] <Wimpress> Hello o/
[14:31] <seb128> ah :p
[14:31] <didrocks> hey hey
[14:31] <Wimpress> #startmeeting Desktop Team Weekly Meeting - 2021-02-02
[14:31] <meetingology> Meeting started at 14:31:35 UTC.  The chair is Wimpress.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[14:31] <meetingology> Available commands: action, commands, idea, info, link, nick
[14:31] <Wimpress> Roll call:  didrocks, duflu, hellsworth, jamesh, jibel, kenvandine, Laney, marcustomlinson, oSoMoN, seb128 , tkamppeter, Trevinho, robert_ancell, callmepk
[14:32] <Trevinho> o/
[14:32] <hellsworth> o/
[14:32] <jibel> \0
[14:32] <callmepk> o/
[14:32] <marcustomlinson> \o
[14:32] <oSoMoN> o/
[14:32] <Wimpress> Hello desktoppers :-)
[14:32] <Wimpress> #topic rls-bb-bugs
[14:32] <Wimpress> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html
[14:33] <Wimpress> Clear
[14:33] <Wimpress> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-tracking-bug-tasks.html
[14:33] <Wimpress> https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984
[14:34] <Wimpress> Assigning to Timo
[14:34] <Wimpress> Everything else is in order.
[14:34] <Wimpress> #topic rls-ff-bugs
[14:35] <Wimpress> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html
[14:35] <Wimpress> http://launchpad.net/bugs/1910838
[14:35] <Wimpress> I think we discussed that one last week.
[14:35] <Wimpress> Waiting for feedback.
[14:36] <Wimpress> HWE is being discussed.
[14:36] <Wimpress> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-tracking-bug-tasks.html
[14:38] <Wimpress> https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1912498
[14:38] <Wimpress> ANy of us involved in the above?
[14:38] <Wimpress> Looks like sil2100 is working that?
[14:38] <Laney> Nah, that's for Łukasz, assign it imo
[14:39] <Wimpress> Done.
[14:39] <Wimpress> https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/1913656
[14:40] <Wimpress> Any takers?
[14:41] <Laney> for Till maybe?>
[14:41] <seb128> tkamppeter_, ^ one SRU for you maybe there?
[14:41] <Trevinho> guess it's for TIll?
[14:41] <Laney> lol
[14:41] <Laney> Tillfest
[14:41] <seb128> :-)
[14:41] <Wimpress> Till wins a bug
[14:42] <hellsworth> till he protests..
[14:42] <Wimpress> Everything else is assigned.
[14:42] <oSoMoN> it's "adopt a bug" day
[14:42] <Wimpress> #topic rls-gg-bugs
[14:42] <Wimpress> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-gg-incoming-bug-tasks.html
[14:42] <Wimpress> Is fine ^
[14:43] <Wimpress> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-gg-tracking-bug-tasks.html
[14:43] <Wimpress> http://launchpad.net/bugs/1913651
[14:44] <Laney> it's for tselio_t and in progress afaik, assign it
[14:45] <Wimpress> Yep. Assigned.
[14:45] <Wimpress> http://launchpad.net/bugs/1913651
[14:45] <Wimpress> That is being handled by Dave.
[14:46] <seb128> that was the same number than before?
[14:46] <Laney> wrong link, or else we're all in the matrix
[14:46] <Wimpress> https://bugs.launchpad.net/ubuntu/+source/pi-bluetooth/+bug/1901272
[14:46] <Wimpress> That one ^
[14:46] <seb128> right
[14:46] <Wimpress> Everything else is in order.
[14:46] <Wimpress> #topic rls-hh-bugs
[14:47] <Wimpress> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-hh-incoming-bug-tasks.html
[14:47] <Wimpress> Is fine ^
[14:47] <Wimpress> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-hh-tracking-bug-tasks.html
[14:47] <Wimpress> Also fine ^
[14:48] <Wimpress> #topic update_excuses_by_team.html#desktop-packages
[14:48] <Wimpress> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages
[14:48] <seb128> right
[14:49] <seb128> tiff is waiting for MIR team, their meeting is just after this one
[14:49] <seb128> I will go ask if it didn't get picked for review because it was assigned
[14:49] <Wimpress> OK
[14:49] <seb128> n-m sounds like a systemd issue, I pinged r_balint about it
[14:49] <rbalint> seb128, ?
[14:50] <seb128> rbalint, we are reviewed blocked in proposed for our team and I was talking about https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1914062
[14:50] <rbalint> n-m does not start in lzc
[14:50] <Wimpress> Anything else in excuses a cause for concern?
[14:50] <seb128> software-properties/armhf, probably to check with foundations
[14:50] <seb128> that keeps beeing flaky or problematic
[14:51] <Wimpress> Flappy test?
[14:51] <seb128> :-)
[14:51] <seb128> but otherwise nothing new or problematic, the few glib failures probably need to be checked
[14:51] <seb128> and that's it
[14:51] <Wimpress> Thanks.
[14:51] <Wimpress> #topic AOB
[14:52] <Wimpress> Anyone have anything else they want to discuss?
[14:52] <Wimpress> OK, I'll go.
[14:52] <Wimpress> I met with the Yaru team last night.
[14:53] <rbalint> seb128, the log from the bug contains this: Get:263 http://ftpmaster.internal/ubuntu hirsute-proposed/main amd64 network-manager amd64 1.28.0-2ubuntu1 [2002 kB]
[14:53] <Wimpress> TL;DR in terms of Yaru - merging the GTK4 and GNOME40 themes looks to be business as usual.
[14:54] <Wimpress> No expected major issues.
[14:54] <seb128> great
[14:54] <seb128> I'm going to upload GTK4 to hirsute today
[14:54] <seb128> Debian NEW is taking forever and since there was a call for testing on discourse
[14:54] <Wimpress> Yaru team do have one request though.
[14:54] <Wimpress> Can GNOME40 snapshot be uploaded to a PPA so they can test/validate everything is indeed working?
[14:55] <seb128> no
[14:55] <Wimpress> So, next cycle then?
[14:55] <seb128> we will eventually get there, but one of the reason we postponed is that we don't have the engineering capacity to do the work required by the updares
[14:55] <seb128> updates
[14:56] <Wimpress> Understood.
[14:56] <seb128> the lack of resources applies also to some degree to the ppa
[14:56] <Laney> there's a gtk4 package in debian, and that has a demo application or two in it
[14:56] <seb128> we might have wip work landing at some point
[14:56] <Laney> which is probably good enough to rebuild on ubuntu, and use for testing
[14:56] <seb128> Laney, I'm basically just fake syncing the version that is sitting in NEW
[14:56] <Wimpress> clobrano ^
[14:56] <Laney> good
[14:57] <seb128> I just finished a test build on hirsute and it's fine :-)
[14:57] <Laney> so I assume the demos are packaged in there and they can be used for now until we get some apps which require it
[14:58] <Wimpress> I have nothing else to add regarding Yaru etc.
[14:58] <Wimpress> Anyone have any other topics?
[14:59] <Wimpress> Also Feichtmeier ^
[14:59] <seb128> I'm just going to mention recent topics from discourse for those not follow the website
[14:59] <seb128> https://discourse.ubuntu.com/t/refreshing-the-ubuntu-desktop-installer/20659
[14:59] <Wimpress> Good point!
[14:59] <seb128> https://discourse.ubuntu.com/t/trying-wayland-by-default-again/20575
[14:59] <Trevinho> Wimpress, clobrano: I can do the simplest thing by just copy the debian sources (as they are) in a PPA once they hit that...
[14:59] <Trevinho> may be enough for testing
[15:00] <seb128> https://discourse.ubuntu.com/t/staying-on-gtk3-and-gnome-3-38-this-cycle
[15:00] <Wimpress> Thanks Trevinho
[15:00] <seb128> Trevinho, Debian is frozen
[15:00] <Trevinho> well experimental isn't going to be updated?
[15:00] <seb128> they might still update to experimental but I doubt that's going to be a focus
[15:01] <Wimpress> Are we done?
[15:01] <seb128> I think so
[15:01] <Wimpress> #endmeeting
[15:01] <meetingology> Meeting ended at 15:01:53 UTC.  Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-desktop/2021/ubuntu-desktop.2021-02-02-14.31.moin.txt
[15:01] <Wimpress> Thanks everyone.
[15:01] <hellsworth> gonna miss you Wimpress
[15:02] <oSoMoN> thanks
[15:02] <didrocks> thank you Wimpress!
[15:02] <jibel> Thanks Wimpress
[15:02] <callmepk> thanks Wimpress
[15:03] <Trevinho> thanks!!


[00:20] <lifeless> thumper: ping
[00:20] <lifeless> Bug 667554 is blocking deploys
[00:20] <_mup_> Bug #667554: State change and reviewer request emails go out for work in progress <code-review> <email> <qa-needstesting> <Launchpad Bazaar Integration:Fix Committed by thumper> <https://launchpad.net/bugs/667554>
[00:21] <lifeless> thumper: (This is the 'qa promptly...-please-' plea)
[00:21] <lifeless> thumper: I would nag wallyworld, but he isn't on irc just now :)
[00:23] <wgrant> lifeless: I think we may need to roll back cesium.
[00:23] <wgrant> It's knocked out half the non-virt builders.
[00:24] <StevenK> 'NoneType' object has no attribute 'processor'
[00:24] <StevenK> Wheee
[00:25] <wgrant> There's a Twisted callback being called after a failure, when it shouldn't.
[00:25] <wgrant> And the builder's cached behaviour is incorrect at the that point.
[00:26] <wgrant> A quick workaround may be to remove the behaviour cache.
[00:26] <wgrant> But can we just rollback to whatever it was before?
[00:26] <StevenK> lifeless: ^
[00:33] <wgrant> I don't have the time nor the log access to debug this much further :/
[00:56] <lifeless> ok
[00:57] <lifeless> wgrant: 11811 be ok ?
[00:59] <spm> soyuz-production-rev-9886 is more likely. that's a softlink change.
[00:59] <wgrant> lifeless: No. 11808 is probably the culprit.
[00:59] <wgrant> 11801 was the initial landing, it was rolled back in 11805, then brought back in 11808.
[00:59] <wgrant> I'd go with spm's suggestion.
[00:59] <lifeless> 11793 then
[01:00] <spm> any other revno isn't so much a rollback, as a rollout
[01:00] <lifeless> spm: ah, please do that.
[01:00] <lifeless> spm: we should also take cesium back out of nodowntime
[01:00] <spm> oki
[01:00] <lifeless> spm: until this is addressed
[01:00] <thumper> lifeless: where is the imap folder for the qastaging email box?
[01:00] <lifeless> perhaps we need a 'lock' facility in the deployment manager
[01:00] <lifeless> thumper: its the staging one
[01:01] <thumper> lifeless: how do I tell the difference?
[01:01] <lifeless> thumper: right now you don't. I've filed an RT asking for something
[01:01] <thumper> lifeless: ok
[01:01] <lifeless> thumper: OTOH there is almost no mail from staging/qastaging. So you can just empty the mbox
[01:01] <lifeless> then do your thing
[01:01] <thumper> lifeless: what bzr hosting do we have for qastaging?
[01:01] <lifeless> thumper: EPARSE
[01:02] <thumper> lifeless: like pushing branches to qastaging?
[01:02] <lifeless> its all there
[01:02] <lifeless> lp: won't work until the bzr bug I filed is fixed.
[01:02] <thumper> ok
[01:02] <lifeless> but the full paths will
[01:03] <lifeless> I should probably do the bzr one myelf
[01:05] <wgrant> spm: Once that's rolled back and b-m restarted, the disabled buildds need to be undisabled.
[01:05] <spm> figures
[01:05] <lifeless> spm: thanks
[01:05] <spm> it's rolled back, fwiw. that was fairly easy. just making sure all teh required services are restarted
[01:06] <lifeless> yeah, thats the idea :)
[01:06] <lifeless> low TTR
[01:09] <thumper> test_ppa_displayname_inline_edit  failing on db-devel builder
[01:15] <lifeless> :(
[01:19] <thumper> mwhudson: have you tried mumble recently?
[01:19] <thumper> mwhudson: it has started working for me fine
[01:21] <mwhudson> thumper: no
[01:21] <thumper> mwhudson: in the end I deleted my ~/.config/Mumble dir and started again
[01:22] <thumper> mwhudson: dropped the caching to 10ms
[01:22] <thumper> mwhudson: and it is working fine now
[01:22] <mwhudson> thumper: huh, cool
[01:22] <mwhudson> i should try it again then
[01:22] <thumper> I'm not entirely sure what else has changed, but I've been using it for standups this week
[01:22] <thumper> and for talking with flacoste
[01:29]  * StevenK peers at the build page. Where's my build log?
[01:30] <wgrant> StevenK: Which build is borked?
[01:30] <StevenK> wgrant: https://launchpad.net/ubuntu/+source/linux/2.6.37-2.10/+build/2032158 for example
[01:31] <wgrant> StevenK: Looks like it was killed by the failure counter.
[01:31] <wgrant> Retry.
[01:31] <wgrant> Bonus points if you unkill all the builders.
[01:32] <StevenK> I set it to OK and remove the failure message?
[01:34] <wgrant> Indeedily.
[01:35] <StevenK> Whee, adare promptly failed itself again
[01:36] <wgrant> That's not unexpected.
[01:36] <wgrant> ppc is sort of screwed at the moment.
[01:37] <wgrant> At least it has a proper error this time.
[01:40] <StevenK> I prefered the other error, it at least pointed to a code error in the buildd-manager :-)
[01:41] <StevenK> allspice picked itself back up, though
[01:43] <StevenK> wgrant: Have you filed a bug about this, or do I need to?
[01:43] <wgrant> StevenK: I haven't. Do you have the traceback and related log entries?
[01:44] <StevenK> Not to hand
[01:44] <wgrant> http://paste.ubuntu.com/526017/
[01:47] <StevenK> wgrant: bug 671242
[01:47] <_mup_> Bug #671242: New buildd-manager disabling everything in sight <Soyuz:Confirmed> <https://launchpad.net/bugs/671242>
[01:47] <persia> Good title!
[01:48] <wgrant> StevenK: Thanks.
[01:49] <wgrant> StevenK: is there a probe failure message immediately before each traceback?
[01:49] <wgrant> I see there's one 9 seconds later, but that's probably from the next scan.
[01:53] <StevenK> wgrant: After
[01:54] <wgrant> :(
[01:54] <StevenK> Traceback, and then the probe failure message immediately after
[01:56] <wgrant> StevenK: Is there a "builder BLAH failure count: X" line before the traceback?
[01:58] <wgrant> My theory is that assessFailureCounts knocks the build off the builder, then rescueIfLost fires in the same transaction, using the cached BFJB.
[02:01] <StevenK> wgrant: That's attached to the failed probe messages, isn't it?
[02:01] <StevenK> 2010-11-05 00:25:45+0000 [QueryProtocol,client] Builder lakoocha failed a probe, count: 4
[02:02] <wgrant> StevenK: The 'failed a probe' message occurs when a failure is detected with no build assigned.
[02:03] <wgrant> 'builder BLAH failure count: X, job 'BLAH' failure count: Y' is used when there is a build assigned.
[02:04] <StevenK> wgrant: I can see that in the logs for rothera, but it's a timeout error, not the processor none traceback
[02:04] <wgrant> Intriguing.
[02:06] <wgrant> Anyway, I guess we'll have to wait until Monday evening.
[02:06] <StevenK> wgrant: I wonder if there's an addErrBack for rescueIfLost
[02:08] <wgrant> StevenK: rescueIfLost isn't the problem here.
[02:08] <wgrant> Its caller is.
[02:09] <wgrant> It is being called with a dirty transaction with a builder with an outdated BFJB cache.
[02:09] <wgrant> There are enough commits and aborts around that that shouldn't happen.
[02:09] <wgrant> But there must be a missed case.
[02:10] <wgrant> But I am not exactly a Twisted expert.
[02:10] <StevenK> Neither
[02:11] <wgrant> Maybe I should acquire a book.
[02:13] <thumper> StevenK: I hope there is lots of lovely logging for the new buildd manager
[02:13] <wgrant> Not enough :(
[02:13] <wgrant> But it's not as bad as it ws.
[02:14] <thumper> well add some dear liza...
[02:14] <thumper> has the buildd manager been rolled back?
[02:14] <StevenK> wgrant: http://www.amazon.com/Twisted-Network-Programming-Essentials-Fettig/dp/0596100329/ref=sr_1_7?s=books&ie=UTF8&qid=1288923189&sr=1-7 ?
[02:14] <StevenK> thumper: Yes
[02:15] <thumper> StevenK: can I talk to you in about 30 minutes about PPAs?
[02:16] <StevenK> thumper: Sure
[02:16] <thumper> ta
[02:17] <wgrant> thumper: As I see it, we have a bit of a conflict. Code likes to delete things, while the rest of Launchpad does not delete anything ever.
[02:17] <thumper> wgrant: sure it does...
[02:17] <wgrant> Oh?
[02:17] <thumper> blueprints will be deletable soon
[02:18] <thumper> :-)
[02:18] <wgrant> I hope you mean the code.
[02:18] <thumper> we have lots of garbo scripts that delete things
[02:18] <thumper> and no, I don't mean the code
[02:18] <wgrant> They delete records of inconsequential happenings.
[02:18] <spm> hahaha
[02:18] <wgrant> Not OMGCRITICAL stuff like who uploaded some malware to Ubuntu.
[02:19]  * spm prints "<wgrant> They delete records of inconsequential happenings." to preserve for all time
[02:37] <lifeless>   Hard / Soft  Page ID
[02:37] <lifeless>      278 /    7  Archive:EntryResource:getBuildSummariesForSourceIds
[02:37] <lifeless>      207 /   55  Person:+commentedbugs
[02:37] <lifeless>       94 /    0  MailingListApplication:MailingListAPIView
[02:37] <lifeless>       90 /  375  BugTask:+index
[02:37] <lifeless>       83 /  269  CodeImportSchedulerApplication:CodeImportSchedulerAPI
[02:37] <lifeless>       34 / 2190  Archive:+index
[02:37] <lifeless>       32 /  138  Archive:+packages
[02:37] <lifeless>       19 /  323  Distribution:+bugs
[02:37] <lifeless>       18 /   14  ProjectGroup:+milestones
[02:37] <lifeless>       11 /   82  MaloneApplication:+bugs
[02:39] <StevenK> lifeless: Are they timeouts?
[02:41] <wgrant> Hm, we only hold three of the top ten, and two of those are probably the same issue. Not bad.
[02:42] <thumper> StevenK: mumble?
[02:43] <StevenK> thumper: Sec
[02:54] <LPCIBot> Yippie, build fixed!
[02:54] <LPCIBot> Project db-devel build (120): FIXED in 3 hr 9 min: https://hudson.wedontsleep.org/job/db-devel/120/
[02:54] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 11862
[02:54] <LPCIBot> included.
[03:04] <StevenK> lifeless: Interestingly, the deployment page says bad, but the bug is marked 'qa-untestable'
[03:17] <StevenK> thumper: Are you okay to mentor my review of https://code.edge.launchpad.net/~wallyworld/launchpad/person-mergequeue-listview/+merge/39933 or would you prefer someone els
[03:17] <StevenK> s/els$/else?/
[03:21] <thumper> I can take a look
[03:57] <lifeless> StevenK: which bug
[04:00] <lifeless> spm: can you please add a feature flag to qastaging for qa needs?
[04:00] <lifeless> hard_timeout team:bzr 15 5000
[04:03] <spm> lifeless: thatshould be applied
[04:23] <lifeless> spm: can you drop that to 2000 ?
[04:24] <spm> done
[04:24] <lifeless> great
[04:24] <lifeless> please remove the rule
[04:25] <spm> done
[04:29] <lifeless> thanks
[04:37] <wgrant> Is PQM happy at the moment, and likely to remain so? It threw out https://code.edge.launchpad.net/~wgrant/launchpad/destroy-distroseries-lucilleconfig/+merge/38648 yesterday.
[04:37] <lifeless> wgrant: we can't actually tell
[04:37] <wgrant> ...
[04:37] <lifeless> there is a bug
[04:37] <wgrant> Hwhat?
[04:38] <lifeless> the testfix state is not well exposed
[04:38] <lifeless> last build of devel workd
[04:38] <lifeless> last build of db-devel failed
[04:38] <wgrant> Yay.
[04:38] <lifeless> devel and db-devel are both building atm
[04:38] <lifeless> WindmillTestClientException: {u'suite_name': u'lp.soyuz.windmill.tests.test_ppainlineedit', u'result': False, u'starttime': u'2010-10-5T6:12:5.320Z', u'params': {u'xpath': u"//h1[@id='displayname']/span[1]", u'validator': u"Celso's default PPA"}, u'debug': u"Text 'Celso's default PPA' was not found in the provided node.  Found instead: PPA for Celso Providelo", u'output': None, u'endtime': u'2010-10-5T6:12:5.321Z', u'method': u'
[04:38] <lifeless>                   u'validator': u"Celso's default PPA"}, u'debug': u"Text 'Celso's default PPA' was not found in the provided node.  Found instead: PPA for Celso Providelo", u'output': None, u'endtime': u'2010-10-5T6:12:5.321Z',
[04:38] <lifeless>                   u'method': u'asserts.assertText'}
[04:39] <lifeless> looks like a genuine fail
[04:39] <lifeless> StevenK: ^
[04:39] <wgrant> Hudson's still happy, though :/
[04:40] <wgrant> So not very legit.
[05:05] <StevenK> That's ... odd
[05:36] <SpamapS> lifeless: was it you that pointed out mod_pagespeed?
[05:41] <lifeless> no
[05:41] <lifeless> I was the one that went eeeeek omg nooo
[05:41] <lifeless> [just on the probably complexity of the heuristics it must have]
[05:42] <lifeless> let alone the potential to mess with our API implementation
[05:42] <lifeless> SpamapS: ^
[05:42] <SpamapS> so I filed an ITP w/ debian to package it..
[05:42] <SpamapS> and have started looking into it
[05:43] <SpamapS> 45 dependencies.. I think 3 of them are already packaged
[05:43] <SpamapS> they build a .deb, but they don't use dpkg-buildpackage to do it
[05:43] <lifeless> -lol-
[05:43] <lifeless> I'm very unsurprised.
[05:43] <lifeless> Google project yeah?
[05:43] <SpamapS> the first thing it does, is sync all of its 3rd party dependencies from their upstream repositories at specific revisions.
[05:44] <SpamapS> yes, Google seems to be against releasing and stablizing things. ;)
[05:44] <lifeless> well
[05:44] <SpamapS> I have to wonder, are we fighting the good fight, or holding back progress?
[05:44] <lifeless> its a different definition of release ;)
[05:45] <SpamapS> TODO: describe advanced compilation options such as compiling against system headers.
[05:45] <lifeless> SpamapS: *blink*
[05:45] <SpamapS> am I the only one who thinks thats *BASIC* compilation?
[05:45] <lifeless> I hear ya
[05:46] <SpamapS> I can see how the conversation went at Google that led to gyp and gclient (the things that make this "just work")
[05:47] <SpamapS> "Its got 45 dependencies, it takes a long time to get them all onto one system."
[05:47] <SpamapS> "I can solve that!"
[05:47] <SpamapS> "Ok, solved. We can now compile all 45 dependencies with one command. Who wants to go play ping pong?"
[05:47] <lifeless> they have a specific diagnostic story
[05:47] <lifeless> if you look at go it becomes very clear
[05:47] <wgrant> Well...
[05:47] <lifeless> they -want- a single binary with no shared libraries
[05:48] <wgrant> Have you seen Chromium?
[05:48] <wgrant> It is the Java mentality cubed.
[05:48] <SpamapS> Yes, this uses the chromium tools
[05:48] <lifeless> the reason they want this is so that when there is a fault, they know all the deps precisely with no room for skew
[05:48] <lifeless> and for complete isolation between concurrently installed things on the same machine
[05:49] <wgrant> Yes, but it makes everyone else sick.
[05:49] <lifeless> I don't completely buy the value of this - apport does a pretty tremendous job
[05:49] <SpamapS> ridiculous.. they're including libjpeg, libpng, zlib
[05:49] <SpamapS> things that have been on every system for a long, long time.
[05:50] <lifeless> yes
[05:50] <lifeless> its not because they have to
[05:50] <lifeless> its because they want to
[05:50] <lifeless> the numeric analysis is something like:
[05:50] <wgrant> They *think* they want to.
[05:50] <lifeless>  - if we get 10billion downloads
[05:51] <lifeless>   - we'll save 5 hours diagnosis due to folk with zlib1e which had a buffer overflow
[05:51] <lifeless> wgrant: they want to. No thinking involved.
[05:51] <SpamapS> They're thinking in faster moving terms than most people actually move. Its valid for desktop software.. people see "there are updates" and they tend to update. Not so much for the server side.
[05:51] <lifeless> no
[05:51] <lifeless> its not about how fast things move
[05:51] <lifeless> its about reproducability and support overhead
[05:52] <SpamapS> Which is funny, thats why we do what we do. ;)
[05:52] <lifeless> I got into this fairly deeply @ LCA last year
[05:52] <SpamapS> But they're doing it by assembling a mini-distro around their product.
[05:52] <lifeless> none of it attributable, of course
[05:52] <SpamapS> which is actually totally awesome.. if you, the user, trust them to keep all those deps in top shape.
[05:55] <SpamapS> lifeless: we didn't really solve this at UDS.. too many distractions.. its the same old problem.
[05:55] <wgrant> SpamapS: Does the solution actually need discussion?
[05:56] <wgrant> I don't think there's any option but to declare their strategy as being utterly crackful, ignore it, and port their build system to use real system libraries.
[05:58] <SpamapS> wgrant: 45 is a drop in the bucket. Hudson has over 1000 java libraries that aren't packaged. This keeps coming up... upstreams don't build on top of distro's, they build on top of libraries.
[05:59] <wgrant> SpamapS: But Hudson at least doesn't bundle modified copies of its libraries, right?
[05:59] <SpamapS> modified, no, selected versions, yes absolutely.
[06:00] <SpamapS> to me, these upstreams have done a lot of our work for us and we throw it away because we only want to have one version of everything to support.
[06:03] <StevenK> Surely Hudson isn't 1,000? 200, 300, sure, but 1k?
[06:03] <wgrant> Doing a Launchpad and specifying a known-good set of unpackaged versions is one thing.
[06:04] <wgrant> But bundling libraries... uh... kill them.
[06:06] <StevenK> Didn't dpkg used to statically link against zlib in the deep dark ages?
[06:24] <StevenK> lifeless: Can you remind me of a discussion we had at UDS? You mentioned using btrfs on the Hudson build slaves -- that one I remember, but there was another suggestion
[06:57] <SpamapS> StevenK: talk to JamesPage about it.. 1000 was the number of libs hudson needed to download from maven to build *after* it cross referenced with everything debian had packaged.
[06:58] <lifeless> SpamapS: well I've argued (successfully I think) that we need N libraries concurrently for java and python
[06:59] <lifeless> StevenK: errr I didn't suggest btrfs on the build slaves.
[06:59] <lifeless> StevenK: I suggested an RT ticket asking for bigger images.
[06:59] <lifeless> StevenK: our you can roll your own
[07:01] <StevenK> lifeless: Actually, they're 20GiB, just the / is only 1.5GiB
[07:02] <lifeless> StevenK: yes, but thats the partition you need bigger to install java etc, right ?
[07:02] <StevenK> Currently it fits with about 50MiB to spare
[07:02] <lifeless> EMEEP
[07:03] <StevenK> Current devel slave has 120MiB, that will drop to roughly 50 over the course of the build
[07:05] <StevenK> lifeless: Too close, and I should repack?
[07:06] <lifeless> dunno about you but my sysadmin senses are screaming
[07:07]  * StevenK ponders an EBS store for persistant branches
[07:16] <StevenK> steven@hudson:/tmp$ ls -1 | wc -l
[07:16] <StevenK> 3589
[07:16]  * StevenK sobs
[07:54] <StevenK> lp.soyuz.windmill.tests.test_ppainlineedit fails on db-devel again ... How odd
[07:55] <wgrant> Huh.
[07:55] <wgrant> I don't recall that failing within the last few months.
[07:56] <StevenK> And has now failed twice in 2 builds, but not in devel
[07:58] <wgrant> And not in Hudson.
[08:04] <StevenK> Indeed
[08:04] <StevenK> Sounds like a reason to switch to me
[08:04] <StevenK> :-P
[08:12] <bac> hi wgrant, you still around?
[08:14] <wgrant> bac: Hi.
[08:14] <bac> wgrant: you know much about the inner workings of merge proposals?
[08:14] <wgrant> bac: Not a huge amount, but possibly enough.
[08:14] <bac> wgrant: i've noticed rollback branches don't get their status updated to 'merged'
[08:15] <bac> and they clutter up +activereviews until cleaned up
[08:15] <wgrant> Do you have a current example?
[08:15] <bac> https://code.launchpad.net/~bac/launchpad/rollback-11801/+merge/39422
[08:15] <lifeless> bac: uhm
[08:15] <bac> wgrant: unfortunately i spoiled it by updating the status manually
[08:15] <lifeless> bac: that means one of two things
[08:15] <lifeless> bac: it wasn't actually landed previous
[08:16] <lifeless> bac: or the scanner glitched at the same time
[08:16] <bac> https://code.launchpad.net/~mars/launchpad/rollback-11586-and-11588/+merge/36212
[08:16] <lifeless> bac: launchpad itself doesn't know about the rollback stuff
[08:16] <bac> lifeless: well, there is another
[08:16] <wgrant> Hm.
[08:16] <bac> i know the first actually landed
[08:16] <bac> i haven't checked on the second
[08:16] <wgrant> https://code.launchpad.net/~bac/launchpad/rollback-11801
[08:16] <wgrant> It's being scanned.
[08:16] <wgrant> Which is a little odd.
[08:16] <bac> ah, so it is
[08:16] <bac> for 10 days now
[08:17] <StevenK> lifeless: Interestingly, the deployment page says bad for r11825, but the bug is marked 'qa-untestable'
[08:17] <lifeless> see under scanner glitch
[08:17] <bac> score one for lifeless
[08:17] <wgrant> Indeed.
[08:17] <lifeless> StevenK: https://bugs.edge.launchpad.net/qa-tagger/+bug/670792
[08:17] <_mup_> Bug #670792: handling of bad-commit- tags needs improving <qa-tagger:Incomplete> <https://launchpad.net/bugs/670792>
[08:17] <wgrant> These non-edge URLs are strange and foreign :(
[08:17] <StevenK> Haha
[08:17] <StevenK> Blame lifeless
[08:18] <bac> wgrant: can i do anything to kick the scanner for that branch?
[08:18] <lifeless> StevenK: its bad because of the bad-commit-REVNO tag (which is how we mark that 11825 was faulty)
[08:18] <wgrant> bac: Not sure.
[08:18] <wgrant> I don't really know how the scanner works these days.
[08:19] <bac> wgrant: if it is a one-off i'm not concerned.  but i saw two that appeared to be in the same situation
[08:19] <wgrant> That is indeed concerning.
[08:20] <bac> lifeless: i see your comment on the MP
[08:20] <bac> lifeless: i didn't just now land it, i did it the day of the problem
[08:20] <bac> just updated the status of the MP today
[08:21] <lifeless> grah
[08:21] <lifeless> ok
[08:21] <lifeless> I wouldn't do that
[08:21] <bac> what would you do?
[08:21] <lifeless> because the metadata will be faulty about the rev it was merged into
[08:21] <lifeless> I would look to see why it hadn't updated and get that fixed ;)
[08:21] <bac> mark the MP rejected?
[08:23] <lifeless> no
[08:23] <lifeless> so, when you look at the branch and its scanning
[08:23] <lifeless> thats an issue
[08:23] <lifeless> look into that
[08:23] <bac> lifeless: i did not see the branch was scanning
[08:23] <lifeless> when its fixed, lp will mark the mp appropriately.
[08:23] <lifeless> bac: right, I know :). I'm saying what I would have done was to look around for clues.
[08:24] <lifeless> one of the places I'd look would be the branch page.
[08:26] <bac> lifeless: so would resetting the MP back to 'approved' be inappropriate now?
[08:27] <lifeless> bac: if the branch is still scanning, setting it back to approved is probably best.
[08:27] <lifeless> OTOH
[08:28] <bac> and then trying to get that scanner process kicked...
[08:28] <lifeless> the main thing I'm concerned about is figuring out what happened, ensuring there is a bug that when fixed will prevent it happening again.
[08:30] <bac> lifeless: ok, i'll change the MP back to 'approved' and open a bug referencing that branch but not request anything be done about the stuck scanner.  thanks.
[08:30] <wgrant> I'm not sure that it will be marked merged once it does scan, since the rev won't be new in devel. But I guess we'll see.
[08:31] <bac> wgrant, lifeless: fwiw the other example i cited is a rollback branch that never landed so it was a bad example.
[08:31] <lifeless> what pages does the recipe ui stuff turn up on ?
[08:32] <wgrant> lifeless: Every branch page.
[08:32] <lifeless> time to see if the flag really works
[08:32] <wgrant> lifeless: There's a "Related source package recipes" section just below the "Branch merges" section.
[08:46] <bac> ok
[08:46] <bac> er
[08:48] <adeuring> good morning
[08:54] <bac> hi adeuring
[08:54] <adeuring> hi bac!
[09:00] <mrevell> Morning
[09:10] <bac> hi mrevell
[09:11] <mrevell> hey bac, welcome back, heh
[09:21] <jml> hello
[09:22] <lifeless> jml: your scopes rules are present in production; both patches are in stable and qa'd - we just need to qa up to them and they will go live.
[09:25] <jml> lifeless: sweet.
[09:25] <jml> lifeless: I guess I need to populate the team, delete the edge rule and do comms
[09:25] <jml> anything else?
[09:28] <lifeless> yes. Synced with the revs being deployed of course.
[09:29] <lifeless> we probably want to do a beta program in-app too
[09:29] <lifeless> a-la gmail labs
[09:30] <jml> lifeless: "here are our beta features, sign up to them?"
[09:30] <lifeless> yeah
[09:31] <jml> lifeless: I think that would be an excellent thing.
[09:31] <wgrant> Are we going to have a lot of features for which that would be relevant, though?
[09:31] <lifeless> wgrant: we have 3 concurrent at the moment
[09:32] <jml> wgrant: I'm guessing so.
[09:32] <wgrant> Do we?
[09:32] <lifeless> wgrant: recipes, merge queues, subscribe-to-search
[09:33] <wgrant> Hm, true.
[09:34] <lifeless> oh and derived-series ui
[09:35] <jml> lifeless: https://code.edge.launchpad.net/~lifeless/launchpad/databasefixture/+merge/38694 – what's the actual state of that MP?
[09:35] <lifeless> jml: in principle landable
[09:36] <lifeless> it bounced with some glitches that I think I've fixed.
[09:36] <lifeless> if you want to give it a spin, please do.
[09:37] <jml> lifeless: ok. I probably won't today.
[09:48]  * jml away for a bit
[11:06] <deryck> Morning, all.
[11:30] <jelmer> wgrant: Argh, it looks like your branch is cursed or something.
[11:33] <wgrant> jelmer: Yeah, buildbot seems to have a failure that Hudson does not.
[11:37] <wgrant> Still, this is just two failures so far. One of my previous batch took 10 attempts. So not that bad.
[12:09] <mars> good morning
[12:15] <jtv> hi mars
[13:03] <mars> how is it possible that merely importing a TestCase subclass that defines 'layer = None' causes the Zope testrunner to barf?
[13:09] <jml> mars: importing a TestCase makes it discoverabl
[13:09] <jml> e
[13:10] <mars> jml, that appears so.  Now I'm trying to figure out how other people actually manage to use the subclass without it blowing up on import
[13:15] <mars> 'bin/py -m pdb bin/test lp.testing.tests' at least gives me a debugger
[13:24] <jml> do we have a way to mass add people to a team?
[13:25] <abentley> jml: why are you creating a new team for recipes instead of making them available to all members of the beta team as we have until now?
[13:28] <benji> jml: I don't know if it exposes adding people to teams, but a launchpadlib script suggests itself to me
[13:28] <jml> abentley: it seems a good way to try having a beta programme specific to a feature
[13:28] <jml> benji: yeah, that would work. lots of roundtrips, but it would work & probably be faster than manual data entry.
[13:29] <abentley> jml: I don't think we should take the feature away from people who already had the option of using it, even if they hadn't used it yet.
[13:29] <abentley> jml: So please make the beta team a member of the recipe team :-)
[13:33] <jml> the real spanner-in-the-works is that we don't yet have a way in-app of inviting people to join the beta
[13:35] <mars> jml, that means we have a chance to do it well
[13:35] <mars> jml, btw, turns out I had to put a 'del YUIUnitTestCase' at the end of the file, so the testrunner would not discover the class.
[13:36] <jml> mars: is that what other modules do?
[13:36] <abentley> jml: That is a serious deficiency.  People can join the team if they want, I suppose, but the requirement to do so will be new and surprising.
[13:36] <jml> abentley: well, only surprising if they don't read the blog.
[13:37] <abentley> jml: Who reads the blog?
[13:37] <jml> abentley: I think Francis does
[13:37] <jml> abentley: maybe some others.
[13:37] <mars> jml, no, they define the test_suite() function in the module, and explicitly build the suite contents.  Same effect though - the module imports are not implicitly included
[13:38] <jml> mars: how does YUTC blow up?
[13:39] <mars> jml, deep in the zope testrunner, it trys to look up 'layer.__module__'.  YUTC sets that attribute as layers = None, so it raises a TypeError
[13:39] <jml> mars: why not just delete that from YUTC?
[13:40] <mars> jml, I assume it was put there for good purpose, perhaps as a subtle signal to the programmer that they need to define it
[13:40] <mars> and I am writing a test for the class
[13:41] <mars> which does not use the class in the standard way
[13:41] <jml> mars: if it was put there for good purpose, then a test will fail if you delete it :)
[13:41] <mars> interesting
[13:41] <mars> well, worth a shot!
[13:42]  * jml gets some thinking juice
[13:57] <mars> jml, so this is fun - you can't import YUTC, because it uses layers.  But YUTC can't set layer=anything, because you can't import canonical.testing.layers into lp.testing (circular import maybe)
[13:57] <jml> mars: that *is* fun.
[13:57] <jml> but I have to go to a meeting
[13:57] <mars> YUTC uses layers because it inherits from lp.testing.TestCaseWithFactory, which uses layers
[13:57] <mars> jml, :)
[13:59] <mars> and TestCaseWithFactory needs layer=FunctionalLayer, but again, it can't set it, because lp.testing can't import canonical.testing.layers.
[14:15] <deryck> mars, hi.  Working on yui 3.2 upgrade in lp and have questions about something weird.  you have time to chat?
[14:16] <mars> deryck, sure
[14:16] <mars> deryck, how can I help?
[14:16] <deryck> mars, so I see lots of 404s in console for css files.  I can't find what's trying to load them.  turning devmode off I see 404 for yui combo? urls pointing to yahoo's site....
[14:17] <deryck> mars, I'm wondering if I have to explicitly turn of combo loading attempts?
[14:19] <mars> deryck, well, for starters, we should not be going off-site for anything.  Is this in launchpad.dev?
[14:19] <deryck> mars, yes
[14:19] <deryck> mars, and only going off site when not in devmode.
[14:20] <deryck> mars, I toggled out of devmode just to see if the 404s were devmode specific and maybe linked in a devmode block I couldn't find.
[14:25] <mars> deryck, maybe you could hack the page template to show what the loader is doing - debug output
[14:25] <deryck> ok
[14:26] <mars> deryck, have you ever done that before?
[14:26] <deryck> mars, yes, I have.  trying to recall how....
[14:27] <mars> oh, interesting
[14:28] <mars> deryck, reading the YUI Config object docs
[14:28] <mars> you can set a custom filter: attribute
[14:28] <mars> myFilter: {
[14:28] <mars> 'searchExp': "-min\\.js",
[14:28] <mars> 'replaceStr': "-debug.js"
[14:28] <mars> }
[14:28] <mars> which means you could do:
[14:28] <mars> debugLoader: {
[14:29] <mars> 'searchExp': "loader-.*js",
[14:29] <mars> 'replaceStr': "loader-debug.js"}
[14:30] <deryck> ah, ok.  That's not what I'm thinking of.  I thought you told me something similar before, though, about loader debugging.
[14:30] <mars> deryck, in devmode, you can look at base-template-macros.pt and replace the loader.js line directly
[14:31] <deryck> ok
[14:37] <deryck> mars, found it.  http://pastebin.ubuntu.com/526338/
[14:40] <mars> deryck, that was an easy fix
[14:40] <deryck> mars, indeed.  and unrelated to my other issues, but it clears up the errors in my console better :-)
[14:40] <deryck> mars, thanks for the help!
[14:40] <mars> no problem
[14:40] <mars> glad I could help
[15:54] <jml> jelmer: hi
[15:54] <jelmer> jml: hi
[15:54] <jml> jelmer: what happens when you run ./bin/test -cvv test_builder?
[15:55] <jml> sinzui: hello
[15:56] <jml> sinzui: I saw that you removed a bunch of glob imports recently. If I remove one from c.l.database.__init__ manually, will that mess with your automated tools
[15:56] <jelmer> jml: I get a test module import failure for lp.buildmaster.tests.test_builder, and it runs the test: lp.soyuz.browser.tests.test_builder_views.TestBuilderEditView.test_posting_form_doesnt_call_slave_xmlrpc
[15:56] <jml> jelmer: cool, thanks. that's what I get too.   Getting close on lazr-js actually.  http://pastebin.ubuntu.com/526387/
[16:13] <rockstar> deryck, is that working?  My sed of s/yui/yui3/ made things really broken.
[16:13] <deryck> rockstar, yeah, so far.  notice it's template and lp js changes.  if one without the other, it would break.
[16:14] <deryck> rockstar, I'm just reloading pages manually and making changes until it works.
[16:15] <rockstar> deryck, I thought the picker had WAY more references to creating items called yui-* than that.  The picker's working now?
[16:16] <deryck> rockstar, yes, I'm pretty sure.  I'm in a debugger session right now with the editor before I can confirm for sure.
[16:18] <rockstar> deryck, cool. I was wondering if there'd be more picking and choosing of which s/yui/yui3/ stuff to change.
[16:25] <deryck> rockstar, is there a yui lint tool of any sort?  To check a file for yui 3 vs 3.2 isms?
[16:26] <rockstar> deryck, not that I know of.
[16:27] <deryck> suck it
[16:31] <rockstar> deryck, may I suggest that you file bugs liberally on the javascript oddities you find in there?  Anything that makes the upgrade hard.
[16:32] <deryck> rockstar, sure.  just trying to get it done now.  but will certainly do it after it's good.
[16:32] <rockstar> Takes notes then.  :)
[16:33] <rockstar> deryck, I'm starting to wonder if there's a yak in our javascript anywhere.
[16:34] <deryck> rockstar, we're not consistent in how we write it
[16:34] <deryck> zope widgets, hand js, manual sniffing of classes
[16:35] <rockstar> deryck, yeah, I'd like to write a guide on writing javascript for the dev wiki.  I need to get around to that soon.
[16:46] <jml> jkakar: hello hello
[16:47] <jkakar> jml: Hi!
[16:48] <jml> jelmer: are there doctests that test the uploadpolicy?
[16:48] <jml> jelmer: the answer is 'yes'.
[16:48] <jelmer> jml: yes, and there are also some unit tests I believe.
[16:49] <jelmer> heh
[17:05] <deryck> rockstar, pickers do work for me.  But icons that launch overlays are now form buttons.  I guess I'm missing some CSS rules somewhere.
[17:06] <rockstar> deryck, something with activators, I suspect.
[17:06] <deryck> yeah
[17:06] <deryck> or actually, it may be where we didn't use the activator
[17:08] <rockstar> deryck, ah, okay, because I thought I had fixed that.
[17:19] <jml> jelmer: what about ./bin/test -cvvt nascentupload-closing-bugs.txt?
[17:21] <jelmer> jml: import failures in two mailman tests, but other than that it seems to work fine
[17:21] <jml> jelmer: I get this: http://paste.ubuntu.com/526452/. Guess I'll make clean, schema etc.
[17:22] <jelmer> hmm, interesting. is that current devel?
[17:24] <deryck> rockstar, got the icons back.  needed yui3-skin-sam for the body class, not yui-skin-sam.
[17:26] <rockstar> deryck, ugh.  That scares me a bit.  I suspect you'll want to check a large sampling of pages to make sure that doesn't break anything.
[17:26] <deryck> rockstar, yeah, I am.  Doing all the manual checks first, then back to re-enabling windmill tests.
[17:27] <jml> jelmer: stable.
[17:32] <abentley> rockstar: where was that custom description field, again?
[17:32] <rockstar> lp.services.fields I believe.
[17:33]  * jelmer tries stable as well
[17:33] <abentley> rockstar: thanks.
[17:37] <deryck> rockstar, so i don't see anything but I think'll I'll use both classes, i.e. "yui3-skin-sam yui-skin-sam" just to cover us.  Sound reasonable?
[17:37] <rockstar> deryck, if you don't see anything, then let's not even worry about it.
[17:37] <rockstar> We could complicate things by using both classes.
[17:37] <deryck> rockstar, ok
[17:45] <jelmer> jml: works in stable too, no import errors
[17:45] <jml> jelmer: ok, thanks.
[17:45] <jml> jelmer: make clean; make schema seemed to sort it out for me
[18:39] <jml> g'night all
[19:01] <abentley> rockstar: chat?
[19:47] <rockstar> abentley, sure!
[19:48] <abentley> rockstar: hop in!


[01:10] <Eickmeyer> ALL: I have yet to see any movement on bug 1851346 and I'm starting to get REALLY nervous. I can let it go for beta, but if this ends up in Final, with my flavor lead hat on, I will be very unhappy.
[01:10] <Eickmeyer> I'd at least like some comments, assignments, and status changes in the bug report, please.
[01:11] <Eickmeyer> xnox, juliank, bdmurray ^
[01:12] <Eickmeyer> popey: Could you help me follow-up with this rather critical bug? ^
[07:11] <juliank> Eickmeyer: fwiw, I picked it up for my committed queue last wed, so i'll either have a chance to investigate that soon, or it will revert to the general queue next week
[07:12] <juliank> Eickmeyer: It's fairly low priority, though - worst case you'd just remove the plugin and be grudgingly ok with it?
[07:13] <juliank> Eickmeyer: I'm stuck in grub work atm
[07:17]  * juliank really has to stop doing irc and email in the mornings
[07:25] <cpaelzer> doko: will you take a look at the llvm fix mentioned in https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-10/+bug/1867173 ?
[10:01] <m_tadeu> hi...is this the place to ask about issues on ubuntu20.04?
[10:08] <rbasak> m_tadeu: #ubuntu+1 please
[10:08] <m_tadeu> thanks
[12:04] <kanashiro> doko, do you have a way to coordinate the work that people have been doing on packages FTBFS you reported? I am asking this because I have proposed two MPs fixing packages and when they got reviewed and sponsored they were already fixed
[12:09] <doko> kanashiro: no, besides filing the bug reports. if you work on an issue, you should mention it in the issue. and maybe look before in https://launchpad.net/ubuntu/focal/+queue?queue_state=1
[12:12] <kanashiro> doko, ack
[12:48] <doko> seb128, Laney: could one of you help with https://launchpad.net/ubuntu/+source/libaccounts-glib/1.23+17.04.20161104-0ubuntu2 ?
[12:53] <seb128> doko, hey, sorry but probably not this week, that would require debugging and that's an universe package so not a priority
[13:25] <Eickmeyer> juliank: That bug has been there since November and nothing has happened. To say that response of it being a low priority, despite people's installations breaking, is a little off-putting.
[13:25] <Eickmeyer> I'm OK with it being in beta, but it needs to be fixed by final. Full stop.
[13:29] <juliank> Eickmeyer: it's low priority because a page offering you to remove optional components is not an essential part of an installer, and can be removed if necessary without really negatively impacting anybody's experience
[13:29] <juliank> The first time I saw the bug was last week
[13:30] <Eickmeyer> Then it needs to be delegated to somebody else.
[13:31] <juliank> Given that the bug was originally reported in November and you let it sit around until last week, it's not really fair to blame other people for it
[13:31] <juliank> * let it sit around as well
[13:31] <Eickmeyer> I did not let it sit. I had been talking to this channel about it with zero response. I've been ignored up until this point.
[13:32] <juliank> it was only raised in last weeks meeting
[13:32] <juliank> sand I don't even know why
[13:32] <juliank> The bug has no importance set
[13:33] <Eickmeyer> And that's the biggest reason I'm upset about this. It needs to be fixed ASAP. This is critical priority from an Ubuntu Studio point of view. (I don't have access to set importance).
[13:33] <juliank> We normally only look at critical and high bugs
[13:33] <juliank> Eickmeyer: then why did you not mark it as such?
[13:33] <juliank> the importance is still undecided
[13:33] <Eickmeyer> I don't have access to set it as such.
[13:33] <Eickmeyer> Launchpad literally will not let me.
[13:35] <juliank> bdmurray: Eickmeyer needs to be in ~ubuntu-bugcontrol or at the very least ~bugsquad
[13:35] <juliank> having a flavour lead that's not capable of setting importance of bugs is fairly bad
[13:37] <juliank> Eickmeyer: so, if you don't remove anything on the installer page, everything works?
[13:37] <Eickmeyer> juliank: Correct.
[13:38] <juliank> ok
[13:38] <juliank> I need to get an ubuntustudio image eventually
[13:38] <Eickmeyer> ok
[13:38] <juliank> I won't have a chance to look at it today, but tomorrow should be doable
[13:38] <Eickmeyer> That's fine. :)
[13:38] <bdmurray> juliank: there is an application process for bug control
[13:39] <juliank> bdmurray: right, I should have added a question mark?
[13:39] <bdmurray> https://wiki.ubuntu.com/UbuntuBugControl
[13:39] <juliank> now i added a question mark where it does not belong :(
[13:39] <bdmurray> Ah, yes to set importance join Bug Control or be a developer
[13:41] <Eickmeyer> "Ways to join:" Point #5 is definitely a qualifier for me, the list of bugs is in the hundreds.
[13:42] <Eickmeyer> Unfortunately, that would be too much to compile.
[13:42] <bdmurray> 5 bugs would be too much to compile?
[13:43] <Eickmeyer> I'd have to go through a ton of bug reports over the course of the past two years.
[13:44] <Eickmeyer> Possibly longer.
[13:46] <Eickmeyer> bdmurray: Can BugSquad set importance?
[13:46] <bdmurray> No
[13:46] <Eickmeyer> ok
[13:59] <popey> bdmurray what needs to happen in launchpad to enable Eickmeyer to be an effective leader of his flavour?
[14:00] <bdmurray> I don't know what it takes to be an effective leader but setting bug importance sounds useful and to do that one needs to be a member of Ubuntu Bug Control.
[14:02] <popey> Hah!
[14:45] <niedbalski> bdmurray: hey bryan o/, pinging you about lp: 1867398 (bionic)
[15:18] <Eickmeyer> bdmurray: Applied.