[00:56] <TJ-> Juglugs: https://cdimage.ubuntu.com/daily-live/   current = "Latest images to have passed any automatic testing; try this first"   pending = "Most recently built images; not yet automatically tested"
[14:01] <lotuspsychje> basenji: new comments on bug #1951399
[14:06] <basenji> OK, they have not made a new daily build today still dated 11/20/2021
[14:07] <lotuspsychje> ok, so if you really want to try one of those affected flavours, could try that workaround?
[14:07] <lotuspsychje> see if his pinpoint can be reproduced
[14:18] <basenji> glad their is a workaround for the installer.
[14:21] <basenji> I will wait for the next daily build. Have to go- Out
[22:47] <basenji> I am applying to become an Ubuntu member.
[22:47] <basenji> Mabey you are able to help by submitting a testimonial?   https://discourse.ubuntu.com/t/bernard-stafford-membership-application/25395
[22:57] <Bashing-om> basenji: Good effort - Appreciate that you do this.
[22:58] <basenji> Still trying
[22:59] <basenji> I am a member of Ubuntu Quality team
[23:00] <Bashing-om> basenji: Hang tough and do well - we get this the 1st time :D
[23:05] <basenji> The anonymous way to submit a testimonial: email: ubuntu-membership-boards@lists.ubuntu.com


[00:06]  * woo6 was finally able to install xub 14.04 on win10....HyperV created some challenges
[00:31] <micahg> knome: I'll try to take a look this week
[09:34] <knome> micahg, thanks - and please tell us if it looks like you have no time, because then we'll have more time to track down other people who can do stuff
[09:34] <knome> hello slickymasterWork
[09:35] <slickymasterWork> hey knome
[09:39] <akxwi-dave> Morning All
[09:40] <knome> slickymasterWork, did you see how the PDF files are linked in the documentation yet?
[09:53] <dkessel> !team | 8-minutes-before-meeting-ping
[09:57] <knome> dkessel, but that was 7 minutes...
[09:58] <dkessel> not in my own timezone
[09:58] <knome> wait, what?
[09:58] <knome> :PP
[09:58] <knome> is your timezone misaligned by one minute? that's very silly..
[09:59] <slickymasterWork> !team | meeting time!
[10:00] <slickymasterWork> #startmeeting
[10:00] <meetingology> Meeting started Wed Sep  2 10:00:08 2015 UTC.  The chair is slickymasterWork. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[10:00] <meetingology> Available commands: action commands idea info link nick
[10:00] <slickymasterWork> So, who's here for the meeting?
[10:01] <dkessel> o/
[10:01] <slickymasterWork> hmmm wondering where Unit193 and knome might be hiding?
[10:01] <Unit193> I am not here.
[10:01] <bluesabre> oh, actually made it
[10:02] <slickymasterWork> apparently not Unit193 :P
[10:02] <knome> of course i'm hiding
[10:02] <slickymasterWork> #chair bluesabre, knome
[10:02] <meetingology> Current chairs: bluesabre knome slickymasterWork
[10:02] <slickymasterWork> #topic Open action items
[10:02] <slickymasterWork> there doesn't seems to be none
[10:03] <slickymasterWork> anyone has anything?
[10:05] <bluesabre> nothing here
[10:05] <bluesabre> still collecting myself
[10:06] <knome> of course not, if there aren't any, there aren't any... ;)
[10:06] <slickymasterWork> knome, I believe the update of the debian/copyright for the documentation is done, right?
[10:07] <slickymasterWork> ok, moving along then
[10:07] <slickymasterWork> #topic Team updates
[10:07] <slickymasterWork> gentlemen, the floor is your's
[10:07] <slickymasterWork> please use #info for your items
[10:07] <knome> slickymasterWork, yes
[10:07] <bluesabre> #info xfpanel-switch and patched xfce4-panel now available in wily and included on daily image
[10:08]  * knome refers to tracker.xubuntu.org
[10:08] <slickymasterWork> can you please #info that knome
[10:08] <knome> #info knome updated debian/copyright for documentation
[10:08] <slickymasterWork> thanks
[10:08] <knome> #info knome made the "Official Documentation" part on the startpage more prominent
[10:08] <knome> #info knome created a timeline of finished work items in the status tracker
[10:09] <knome> #info flocculant sent exploratory testing information to testers via ML
[10:09] <knome> #info pleia2 got first batch of flyers printed
[10:09] <slickymasterWork> dkessel, anything new in the use of jenkins for automated image testing front?
[10:09] <dkessel> slickymasterWork: no, now news
[10:09] <dkessel> argh. no news
[10:09] <slickymasterWork> ok, thanks
[10:10] <slickymasterWork> anything else bluesabre?
[10:10] <knome> i think we might want to stop doing these updates at some point if the tracker serves us them anyway
[10:10] <knome> (just use work items to notify about important things)
[10:10] <bluesabre> slickymasterWork: nothing noteworthy yet, just a lot of things in progress (see tracker)
[10:11] <slickymasterWork> oki doke
[10:11] <slickymasterWork> apparently I'm going to set a new record time for a team meeting
[10:11] <slickymasterWork> beating Unit193's record :P
[10:11] <knome> i've had short ones too
[10:12] <bluesabre> good luck, I think ochosi might have set that pretty low once
[10:12] <slickymasterWork> lol
[10:12] <slickymasterWork> #topic Team updates
[10:12] <knome> slickymasterWork, we did that already...
[10:12]  * bluesabre can info his items again
[10:13] <slickymasterWork> sorry my bad (multitasking with some work stuff) :P
[10:13] <slickymasterWork> #topic Discussion
[10:13] <slickymasterWork> there's noting set in the wiki, so does anyone has any last minute items?
[10:14] <knome> i guess i could start this here
[10:14] <bluesabre> any questions or anything needed from me (uploads, patches, etc?)
[10:14] <slickymasterWork> go ahead knome, please
[10:14] <knome> #subtopic Stop doing team updates on meetings
[10:14] <knome> so, as i just said, since the tracker gives us most of that information already, i think this might be more or less useless
[10:15] <bluesabre> as long as people link bugs and document work items thoroughly, yeah
[10:15] <knome> especially since it means people have to wait until the meeting to see the updates - the tracker serves them more or less live
[10:15] <slickymasterWork> fair point knome
[10:15] <knome> the original reason for doing the updates on the meetings was to help gathering the monthly team report
[10:16] <knome> but we haven't been doing that since april
[10:16] <knome> and still, the tracker is much more reliable
[10:16] <knome> but of course, it requires that people add work items for anything worth mentioning
[10:16] <slickymasterWork> yes
[10:17] <bluesabre> knome: the tracker is excellent, thanks for getting it together and being responsive with requests and updates ;)
[10:17] <knome> but since it's one less task to do (to remember the work items for the meeting), and you already need to work with the work items...
[10:17]  * knome bows
[10:17] <knome> i'll send a mail about this to the ML
[10:17] <slickymasterWork> aha
[10:17] <knome> #action knome to send a mail to the mailing list about phasing out "Team updates" in the meetings
[10:17] <meetingology> ACTION: knome to send a mail to the mailing list about phasing out "Team updates" in the meetings
[10:18] <slickymasterWork> thanks also for that knome
[10:18] <knome> np
[10:18] <knome> i think i might have had something else
[10:18] <knome> give me 5 minutes to think about it
[10:18] <slickymasterWork> take your time
[10:18] <knome> or 2...
[10:19] <knome> nah, i don't think it was anything for the meeting :)
[10:21] <slickymasterWork> lol
[10:21] <knome> we do have a few things to discuss about docs together though
[10:21] <slickymasterWork> yeah, but I was thinking on this evening knome
[10:21] <knome> sure, finish the meeting first
[10:22] <slickymasterWork> #action pleia2 to schedule the next meeting
[10:22] <meetingology> ACTION: pleia2 to schedule the next meeting
[10:22] <slickymasterWork> #endmeeting
[10:22] <meetingology> Meeting ended Wed Sep  2 10:22:32 2015 UTC.
[10:22] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/xubuntu-devel/2015/xubuntu-devel.2015-09-02-10.00.moin.txt
[10:22] <knome> thanks david
[10:22] <slickymasterWork> sure, np
[10:22] <knome> so, the few things, just that you know what to expect:
[10:23] <knome> - did you look how the pdf is linked from in the documentation?
[10:23] <knome> - installer slideshow stuff
[10:23] <Unit193> Team updates are a nice thing if it wasn't on the blueprint, just something out of the blue that got done.  Also a nice dumping grounds.
[10:23] <knome> - installer slideshow translations
[10:23] <Unit193> bluesabre: xfdesktop, the new point release?
[10:23] <knome> - faq stuff for website?
[10:23] <slickymasterWork> ok knome
[10:24] <knome> slickymasterWork, what time would work for you?
[10:24] <slickymasterWork> 21:00 UTC
[10:24] <knome> Unit193, if it wasn't on the blueprint but is something that would be worth mentioning and of interest generally, then it can be added to  blueprint
[10:24] <slickymasterWork> today is going to be very busy dirung the day
[10:24] <slickymasterWork> * during
[10:25] <slickymasterWork> does that work for you knome?
[10:25] <knome> Unit193, but sure, we can still do updates about general tasks that aren't really important enough to put on the blueprints
[10:25] <knome> slickymasterWork, should do, i'll let you know in advance if it doesn't
[10:25] <slickymasterWork> ok, thanks
[10:28] <bluesabre> Unit193: yeah, that sounds like a nice release. Want to add it to the -dev bp?
[10:28] <bluesabre> otherwise I'll just keep forgetting about it
[10:28] <bluesabre> :D
[10:28] <slickymasterWork> Minutes are up
[10:29] <knome> thanks slickymasterWork
[10:29] <slickymasterWork> ta
[10:30] <bluesabre> thanks for hosting the meeting slickymasterWork!
[15:22] <sidi> Anybody here running 14.04 or 15.04, who wants to make a bit of money in exchange for letting me log stuff on their computer? It's for science! You can get up to ~£50 / €68... Ideally UK based, or EU based
[15:23] <sidi> https://study.cs.ucl.ac.uk/multitasking/web/hello (haven't updated but I dumped Unity in favour of Xfce for my study, because reasons)
[18:46] <krytarik> Sorry for being AWOL for so long, but I finally just got my internet back! \o/  And picked up with stuff a bit already, but now it's time for dinner.
[18:47] <knome> bon appetit :)
[18:47] <krytarik> Well. :)
[18:54] <krytarik> knome: Btw, did you notice the rather excessive margin below the translation links on  https://unit193.net/xubuntu/docs/  after your recent changes?
[18:55] <knome> i did, it's ok
[18:55] <knome> there's a dotted line there
[18:55] <knome> and padding and stuff
[18:57] <krytarik> I think the bottom padding of '#documentation' could be set to zero or something like that.
[18:58] <knome> oh gosh no
[18:58] <knome> don't you see it has a different bg color?
[18:58] <krytarik> Nope, not here.
[18:58] <knome> it's likely not easy to see on lousier monitors, but there it is
[18:58] <knome> ok.
[18:58] <knome> it does
[18:59] <knome> it is #fff while the rest is something else
[18:59] <knome> #fafafa or #f1f1f1 iirc
[18:59] <krytarik> Yeah, lousy, old CRT here. :P
[18:59] <knome> sure, it's slight
[18:59] <knome> but it's there
[18:59] <krytarik> The first, yes.
[18:59] <knome> brb
[19:02] <flocculant> welcome back krytarik :)
[19:02] <krytarik> Thanks! \o/
[19:03] <flocculant> so it seems the way to get people to disappear is add them to Xubuntu Team :D
[19:03] <krytarik> Yep, at least that works for me. :P
[19:03] <flocculant> ha ha
[19:05] <Unit193> Didn't work for me, sorry.
[19:10] <krytarik> knome: Hah, on switching it off and on, I can see it here now! :P
[19:14] <krytarik> knome: PDF links are still 'DONE', btw - unless you disapprove, of course.
[19:27] <knome> krytarik, well, i don't think they are perfect...
[19:27] <knome> krytarik, but we're seeing with slickymaster in 1,5 hours, let's see what he says (and feel free to join the docs sprint)
[19:28] <Unit193> Oh, and do the thingy where it doesn't tell you about every rendered page.
[19:28] <knome> Unit193, like?
[20:50] <knome> i need the 10 minutes though
[20:50] <slickymaster> want to kick things os, knome?
[20:50] <slickymaster> ok, we'll wait
[20:50] <slickymaster> with both eyes on the TV
[20:50] <knome> well, feel free to start with things you don't need me for
[20:50] <knome> hah :P
[20:56] <ochosi> evening
[20:56] <slickymaster> hey ochosi
[20:57] <ochosi> hey slickymaster
[20:57] <slickymaster> how's everything?
[20:58] <ochosi> buuuuusy :)
[20:58] <ochosi> and tired tired tired
[20:58] <slickymaster> lol
[21:02] <ochosi> knome, bluesabre, flocculant: i pinged satya about numix and gtk3.16 support today, since UIF is creeping up. i haven't tested how bad it currently is - if you can, please take a look so we can decide whether we can continue shipping it as is
[21:02] <ochosi> i would take a look myself, but i'm too tired, sry
[21:03] <knome> i don't know numix well at all, but i could probably look at obvious bugs
[21:03] <ochosi> yeah, this is about visual regressions in gtk3 apps
[21:04] <ochosi> if there are none, then we shouldn't care too much
[21:04] <knome> who cares about gtk3 apps anyway?
[21:04]  * knome hides
[21:04] <ochosi> i know i had to fix many things for greybird to work ok
[21:04] <ochosi> eg. try an app with CSD but with xfwm4 compositing disabled
[21:04] <knome> slickymaster, more or less ready now, eating a night snack on the side ;)
[21:04] <ochosi> etc
[21:05] <knome> slickymaster, did you check the PDF linking krytarik made?
[21:05] <slickymaster> shall we start with how the pdfs are linked from in the documentation, knome?
[21:05] <knome> yep :P
[21:06] <slickymaster> nopes, not yet
[21:06] <knome> well do that
[21:06] <slickymaster> opening LP
[21:06] <knome> huh, this is going to take forever
[21:06] <ochosi> bluesabre: also, how's it going with the parole and mugshot bugs?
[21:06] <ochosi> lol
[21:08] <slickymaster> knome, that was by rev. 408, right?
[21:08] <knome> just pick the latest revision...
[21:09] <slickymaster> already doing that
[21:09] <slickymaster> was just asking if that was the one
[21:09] <knome> i don't know, probably
[21:12] <slickymaster> the it takes to build them now is huge
[21:12] <slickymaster> * time
[21:12] <knome> make startpage html
[21:12] <knome> doesn't do the translations...
[21:13] <slickymaster> hmm, where are the pdfs stored?
[21:14] <knome> who cares?
[21:14] <knome> just go see how the documentation shows them
[21:14] <knome> :P
[21:14] <knome> actually, you'll likely need "make startpage html pdf"
[21:14] <knome> but if you built all, you'll have it
[21:15] <slickymaster> ahah getting page not found from either a4 and us letter links
[21:15] <slickymaster> nopes
[21:15] <slickymaster> that's why I was asking
[21:15] <knome> should be in the same dir as the html files
[21:15] <knome> do you have all the build-deps?
[21:15] <slickymaster> krytarik: this is was I got:
[21:15] <slickymaster> ../scripts/pdf-create.sh de es fi fr pt
[21:15] <slickymaster> ../scripts/pdf-create.sh: 5: ../scripts/pdf-create.sh: fop: not found
[21:15] <slickymaster> ../scripts/pdf-create.sh: 7: ../scripts/pdf-create.sh: fop: not found
[21:15] <slickymaster> ../scripts/pdf-create.sh: 5: ../scripts/pdf-create.sh: fop: not found
[21:15] <slickymaster> ../scripts/pdf-create.sh: 7: ../scripts/pdf-create.sh: fop: not found
[21:15] <slickymaster> ../scripts/pdf-create.sh: 5: ../scripts/pdf-create.sh: fop: not found
[21:16] <slickymaster> ../scripts/pdf-create.sh: 7: ../scripts/pdf-create.sh: fop: not found
[21:16] <slickymaster> ../scripts/pdf-create.sh: 5: ../scripts/pdf-create.sh: fop: not found
[21:16] <knome> slickymaster, sudo apt-get install fop
[21:16] <slickymaster> ../scripts/pdf-create.sh: 7: ../scripts/pdf-create.sh: fop: not found
[21:16] <slickymaster> ../scripts/pdf-create.sh: 5: ../scripts/pdf-create.sh: fop: not found
[21:16] <knome> slickymaster, awwwh, you should know better
[21:16] <slickymaster> ../scripts/pdf-create.sh: 7: ../scripts/pdf-create.sh: fop: not foundnow he tells me :P
[21:16] <knome> :)
[21:16] <knome> you might want to make sure you also have fonts-droid
[21:16] <knome> but you likely do..
[21:16] <slickymaster> I think I have
[21:17] <knome> ANYWAY
[21:17] <knome> the question is the way the PDFs are linked to
[21:17] <slickymaster> wow 32.2 MB of additional disk space will be used
[21:17] <knome> well, it's a small amount to be able to... fop
[21:17] <knome> you know. :P
[21:17] <slickymaster> :P
[21:17] <ochosi> night all
[21:17] <knome> nighty ochosi :)
[21:18] <slickymaster> night ochosi
[21:18] <slickymaster> bulding
[21:18] <knome> slickymaster, make startpage html pdf
[21:18] <knome> slickymaster, then it's a lot quicker
[21:18] <slickymaster> just about finishing
[21:20] <slickymaster> now it's naging about java
[21:20] <knome> huh?
[21:21] <knome> krytarik, forgot something from the build-deps?
[21:21] <slickymaster> /usr/bin/fop: 304: exec: /usr/local/java/jdk1.7.0_51/bin/java: not found
[21:21] <slickymaster> and I do have java
[21:22] <krytarik> knome: Nope.
[21:22] <slickymaster> what do you think it might be then, krytarik?
[21:23] <slickymaster> knome, I'll build them tomorrow at work in my VB box, so we can move on now
[21:24] <knome> yeah, the question was about the linking anyway
[21:24] <knome> not the PDFs
[21:24] <krytarik> slickymaster: What *Ubuntu version are you on then? Should be Wily, of course.
[21:24] <slickymaster> what about it?, their placement
[21:24] <knome> krytarik, works for me in vivid
[21:24] <knome> slickymaster, yes, that, and potentially the appearance
[21:24] <slickymaster> nopes, this one is still 14.04 krytarik
[21:24] <knome> the current place isn't my favorite - it's a bit disrupting
[21:24] <slickymaster> haven't update my laptop yet :P
[21:25] <slickymaster> I don't particulary like where they are now
[21:25] <slickymaster> * particularly
[21:25] <knome> ideally, as i see it, they'd only appear on the front page of the documentation
[21:26] <knome> (eg. NOT the startpage, but the docs main page with ToC)
[21:26] <knome> probably before "welcome"
[21:26] <knome> "Would you rather like to read this documentation in PDF? ..."
[21:26] <knome> or sth
[21:26] <slickymaster> I would place them between the last paragraph ant the ToC
[21:27] <knome> that works for me as well
[21:27] <knome> the only question with that is "should/how do we check if the files exist"
[21:27] <slickymaster> and I would prefer a sentence rather then a dry PDF: A$ US Letter
[21:27] <knome> it would be nice if that paragraph wasn't there when the PDF files weren't around
[21:27] <knome> but meh
[21:28] <knome> it would have to be a build-time thing
[21:28] <knome> like the languages on the startpage
[21:28] <slickymaster> well it will be a trade of, unless krytarik manages to script something
[21:28] <knome> but i really don't want to split up the xml...
[21:28] <knome> so the question is:
[21:28] <knome> by default, do we always commit to build the PDFs for all languages?
[21:29] <slickymaster> my opinion is yes, we do
[21:29] <knome> i don't care if james from jamaica does "make html" and then has a broken link
[21:29] <knome> (but of course it would be nice if he didn't)
[21:30] <slickymaster> of course, but the way I see it if we're shipping it why wouldn't commit to build the pdf's in all shipped languages?
[21:30] <slickymaster> s/wouldn't/wouldn't we
[21:31] <slickymaster> put it like this, if we weren't to commit the build for all languages, to which ones would we build?
[21:31] <slickymaster> what would be the criteria?
[21:31] <knome> http://www.sagehill.net/docbookxsl/ModularDoc.html#XIncludeFallback
[21:32] <knome> slickymaster, none, i guess
[21:32]  * slickymaster opens the link
[21:32] <knome> though that doesn't totally fix the issue
[21:33] <knome> we should probably use that mechanism for the translators though
[21:33] <knome> krytarik, you listening?
[21:33] <slickymaster> but does provides some margin knome
[21:33] <krytarik> knome: Yep.
[21:33] <slickymaster> + us
[21:33] <slickymaster> what's your opinion krytarik?
[21:34] <knome> slickymaster, yes, at least we can build the xml file to be included dynamically only when pdf files exist
[21:34] <knome> the problem is...
[21:34] <knome> how are the translations handled?
[21:34] <slickymaster> at build time?
[21:34] <knome> strings we want to translate should be in the templates
[21:34] <slickymaster> yes
[21:34] <knome> LP can't pick up something we land with a script
[21:35] <knome> unless we figure out some other way to translate those strings
[21:35] <knome> or add them to the translation template
[21:35] <slickymaster> the last would be the fast and easier one
[21:36] <slickymaster> thing is we start the all process and there's a lot of work done
[21:37] <slickymaster> what in both your opinions is the best scenario??
[21:37] <krytarik> knome: If you want to include an elaborate sentence that'll have to be translated, it'll have to be in an XML file that's not just generated at build time.
[21:37] <krytarik> Like the translators one.
[21:37] <knome> krytarik, yeah, i was thinking about that
[21:41] <knome> krytarik, currently, scripts/get-pot.sh only builds the pot for files that are shipped
[21:41] <knome> so the translators xml isn't translater
[21:41] <knome> - not that it should, it's always replaced with other info
[21:42] <krytarik> It's not there in the first place either.
[21:42] <knome> except if we want to move the other string there as well
[21:42] <knome> The contributors to the various translations of this documentation are:
[21:42] <knome> Attributed on each translation's page.
[21:42] <knome> this is a bit clunky
[21:43]  * slickymaster goes to smoke in the meanwhile
[21:43] <knome> i would just leave it out from the english version
[21:44] <krytarik> knome: Yep, apply some DocBook magic then. :)
[21:47] <knome> the problem is that translators.xml is built dynamically
[21:48] <knome> so maybe we should include translator-credits.xml (when translators exist) which then shows the message and includes translators.xml with the translator names
[21:48] <knome> brb
[21:48] <slickymaster> in a separate xml file knome
[21:49] <slickymaster> translator-credits.xml, that is
[21:49] <knome> yes
[21:51] <slickymaster> that would solve your issue of not wanting to split up the xml
[21:51] <knome> i mean split the same way as we split up the html
[21:52] <slickymaster> yes
[21:52]  * knome thinks
[21:58] <krytarik> slickymaster: Ftm, the rationale behind linking to the respective PDFs from every page is better accessibility, and them possibly being accessed directly from a web search.
[21:59] <knome> krytarik, then we should look to put them in the header or sth
[21:59] <knome> that place is meh
[21:59] <slickymaster> yes, I know that. Regarding that I have no doubts
[21:59] <krytarik> Like I said earlier, I tried verious places already.
[21:59] <krytarik> * various
[22:00] <slickymaster> my objections are purely aesthetic krytarik
[22:00] <slickymaster> just that
[22:03] <knome> krytarik, are we using the build_creds_alt function?
[22:04] <krytarik> Nope.
[22:04] <slickymaster> knome, should we move on to the other items so you and krytarik can mature a possible solution for this
[22:04] <knome> i'm brewing it
[22:04] <slickymaster> ok
[22:09] <knome> well sigh
[22:09] <knome> the slideshow stuff isn't happening today
[22:09] <knome> well, we can surface it
[22:10] <slickymaster> tomorrow I'll have a good day at work knome
[22:10] <knome> when have you looked at it the last time?
[22:10] <slickymaster> last sunday I took a quick look at it, after branching it
[22:11] <knome> ok, do we need a lot of changes?
[22:11] <slickymaster> I wouldn't say a lot
[22:11] <slickymaster> we should address LO, of course
[22:12] <knome> yes...
[22:12] <slickymaster> and maybe find a way to add the panle switch to one of the existing slides
[22:12] <slickymaster> * panel
[22:13] <slickymaster> and also referring the fact that the -docs will also be available as pdf's
[22:13] <knome> maybe
[22:13] <slickymaster> but like I said, tomorrow I'm planning on a calm day, so we can start with this in the morning
[22:14] <knome> i should be around at least for some time
[22:14] <knome> well, i'll be around a lot
[22:14] <knome> but available...
[22:14] <slickymaster> so will I, after these frantic last few weeks
[22:15] <slickymaster> I'll ping you as soon as I get there
[22:15] <knome> sure
[22:15] <slickymaster> and we still have the installer translations to deal with knome
[22:16] <slickymaster> we didn't have no answers from dylan
[22:16] <knome> yeah
[22:16] <slickymaster> or Graber for that matter
[22:17] <slickymaster> ok, that's a 'date' then for tomorrow knome
[22:17] <knome> huhu
[22:17] <slickymaster> ahahaha
[22:17] <knome> not a three-way this time?
[22:17]  * slickymaster doesn't see krytarik agrreing on a three-way
[22:17] <slickymaster> * agreeing
[22:17] <krytarik> lol
[22:17] <slickymaster> :P
[22:18] <krytarik> I'll be there only from around 12 UTC though.
[22:18] <knome> that's fine...
[22:18] <slickymaster> until when krytarik?
[22:18] <krytarik> Open end of course. :P
[22:19] <knome> huh
[22:19] <slickymaster> lol
[22:19] <knome> let's see if i broke stuf...
[22:19] <knome> +f
[22:20] <slickymaster> I'll go and try to compensate the three hours of sleep I had last night
[22:20] <knome> good night
[22:20] <slickymaster> ttyt
[22:20] <slickymaster> thanks knome
[22:20] <slickymaster> mañana krytarik
[22:20] <knome> always
[22:20] <krytarik> Night slickymaster.
[23:48] <sidi> bluesabre, slickymaster cant remember which of you two told me how to fix the compiling issue with thunar by using --enable-maintainer-mode
[23:48] <sidi> i still have the same problem though
[23:49] <sidi> i cant build them... there's something missing in the Makefile somehow


[09:57] <bkerensa> pleia2: quite a bit of summaries complete let me know if anything else needs worked on before publish date
[09:57]  * bkerensa retires to bed
[14:41] <pleia2> bkerensa: thanks, I wasn't even sure what the status of the doc was (at a conference, hadn't had a chance to do any link review)
[14:41]  * pleia2 looks quickly before conference day 2!
[14:59] <pleia2> ok, I still need to catch up on my RSS reader to see if we can find some In the Press news, but I've added a bunch of planet posts and I'll send out the call for summary writers now
[15:04] <pleia2> there we go
[15:08]  * pleia2 finds a couple press articles
[15:09] <pleia2> ok, skipping out now, later all :)


[00:32] <hallyn> dannf: there's an extra patch in there, qemu-Add-virQEMUCapsSetGICCapabilities.patch, which is not in series?
[00:33] <hallyn> dannf: other than that, nope, pls feel free.
[01:00] <hallyn> pitti: thx - have you figured out my moronic mistake yet? :)
[01:01] <hallyn> i was wrong before btw - i thought that this succeeded in xenial, and maybe with libvirt it did, but with my test pkgs it just fails differently in xenial.
[01:49] <cjwatson> s390x builders back up; took a bit longer than expected, but there were no builds to be delayed
[04:58] <hallyn> pitti: I find that if I manual rm the Alias symlink (/etc/systemd/system/pkg2.service) that seems to fix it
[05:01] <hallyn> suggesting that i can simply in libvirt-bin.preinst do an rm -f /etc/systemd/system/libvirtd.service (the old alias)
[05:08] <hallyn> dannf: if you push that new libvirt pkg could you also toss in http://paste.ubuntu.com/16503889/ ?
[06:09] <cpaelzer> good morning
[06:45] <pitti> good morning
[08:13] <pitti> bdmurray: FTR, I reviewed all items in xenial-proposed queue, and they now all have something to complain about; the exception is pollinate which I uploaded myself, would be nice if you could review this?
[08:25] <jamespage> pitti, apologies for those no-op MIR's - I'll make sure ddellav and coreycb pickup on those before they get to the SRU team in future...
[08:25] <jamespage> MIR/SRU's
[08:25]  * jamespage has not had enough coffee yet)
[08:28] <pitti> jamespage: no worries -- should they be rejected?
[08:28] <jamespage> pitti, yes please - I've marked the xenial bug tasks as won't fix
[08:29] <pitti> ack, done
[08:29] <jamespage> pitti, thanks...
[08:43] <happyaron> pitti: waiting asac to add me to ~network-manager... so I can change the repo ownership
[08:43] <pitti> happyaron: ah great, thanks for updating it
[09:30] <Laney> doko: libpeas question - can you remember why you multiarched manually instead of setting the libdir?
[09:31] <pitti> apw, sil2100: vivid-proposed has had linux-flo and linux-mako for > 250 days now (see http://people.canonical.com/~ubuntu-archive/pending-sru.html); are these orphaned and shoudl be removed, or released?
[09:36] <apw> pitti, a good question indeed ... i am guessing they have been copied (if needed) out to the overlay ...
[09:37] <pitti> apw: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.name_filter=linux&field.status_filter=published&field.series_filter=vivid
[09:37] <pitti> no, they haven't
[09:38] <pitti> apw: however, jibel said that "These kernel have been on flo and mako for a while, marking as verification done."
[09:38] <pitti> jibel: ^ do the images build with vivid-proposed enabled?
[09:41] <Laney> barry: ^^^ AFAICT this is going to break since libpease-1.0-0 is M-A: Same
[09:41] <Laney> libpeas-1.0-0
[09:42]  * Laney is struggling to think why the loaders can't be multiarched
[10:00] <sil2100> pitti: hmm, need to take a look
[10:01] <sil2100> pitti: yes, our images build with -proposed enabled IIRC
[10:02] <sil2100> pitti: actually these packages are not used during image builds but during the android package build
[10:02] <sil2100> And since our silos have -proposed enabled, they have been used by our devices since long
[10:02] <sil2100> pitti: so I would also opt for releasing them
[10:03] <pitti> ah
[10:03] <pitti> sil2100: ok, makes sense; I just didn't want to release them blindly and introduce a new kernel on touch all of a sudden
[10:03] <sil2100> I'm triple confirming in the logs now
[10:03] <pitti> apw: no objections from your side either?
[10:04] <mvo> bdmurray: hi, could you please have a look at the snapd sru in the queue and let me know if there is anything missing on our end?
[10:04] <sil2100> Give me a minute for firefox to un-hang itself ;)
[10:04] <pitti> mvo: I commented on the bug already
[10:04] <pitti> bdmurray: ^
[10:04] <pitti> sil2100: not urgent at all :)
[10:04] <mvo> pitti: oh, great
[10:05] <pitti> mvo: also, 2.0.4 regresses tests in yakkety, so it didn't land; this could likely also affect xenial?
[10:05] <mvo> pitti: on bug #1583085 or a different one?
[10:05] <pitti> mvo: bug 1576287
[10:06] <sil2100> Get:1 http://ftpmaster.internal/ubuntu/ vivid-proposed/universe linux-image-3.4.0-7-mako armhf 3.4.0-7.39~15.04.1 [8138 kB] <- yeah, looks like the one from -proposed
[10:06] <sil2100> pitti: if apw has no objections then 'ship it!'
[10:06] <sil2100> :)
[10:06] <pitti> mvo: #1583085 isn't even mentioned in the SRU changelog
[10:06] <pitti> sil2100: thanks for quadruple-checking :)
[10:07] <mvo> pitti: thanks, I will do a 2.0.5 that clarifies the point you mention there then
[10:07] <pitti> mvo: no need for a version bump, but if you upload a 2.0.5 to yakkety anyway, sure
[10:07] <pitti> mvo: btw, cleaner to have 2.0.5 in devel and 2.0.5~16.04 as backport
[10:09] <mvo> pitti: yeah, there is a 2.0.5 planned anyway so I will just fold it all in
[10:09] <mvo> pitti: thanks again
[10:09] <caribou> Q: when a package makes a modification to the default grub config, should it trigger a grub-update or just warn the user about the need to update grub ?
[10:10] <pitti> mvo: no worries, *hug*
[10:11] <apw> caribou, the kernel tells  grub, but it does cheat as in it supplies hooks which grub itself ties into
[10:11] <caribou> apw: yeah, I do the same for kdump-tools to build the smaller initrd.img
[10:12] <caribou> apw: but postinst only triggers the build of the small initrd.img; in this case, I'm adding crashkernel= to the boot param
[10:13] <caribou> apw: what kexec-tools used to do. Hmm, I should check what was done by kexec-tools & do the same
[10:13] <apw> caribou, yeah, i would expect you to be calling update-grub i suspect
[10:15] <Odd_Bloke> pitti: smoser: I'm seeing a ~6 minute hang on boot after a "systemd-udevd[459]: seq 1648 '/devices/pci0000:00/0000:00:03.0/virtio0/net/ens3' is taking a long time" message in syslog, with "cloud-init-local.service @1.034s +7min 17.851s" in `systemd-analyze critical-chain`; what can I do to further work out what's going on here?
[10:16] <Odd_Bloke> pitti: smoser: (I'm assuming this is something to do with the conversations you were having in Austin; I can give you SSH access to a machine exhibiting this problem if you want :)
[10:16] <pitti> Odd_Bloke: at first sight this sounds like cloud-init blocking uevents
[10:17] <pitti> Odd_Bloke: in Austin we indeed figured out how to avoid that, but I guess that change isn't in xenial (or even yakkety) yet
[10:17] <Odd_Bloke> (This is yakkety, I should add)
[10:18] <pitti> bug 1577844
[10:18]  * pitti nudges ubottu
[10:18] <pitti> Odd_Bloke: so, this is almost surely https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1577844
[10:18] <caribou> apw: indeed that's what kexec-tools.postinst does
[10:21] <Unit193> bug 1577844 in cloud-init (Ubuntu) "Drop unnecessary blocking of all net udev rules" [Medium,Triaged] https://launchpad.net/bugs/1577844
[10:23] <Odd_Bloke> pitti: OK, so presumably I would expect to see this on xenial as well?
[10:23] <pitti> Odd_Bloke: yes
[10:23] <pitti> Unit193: oh, are you playing ubottu now? :-)
[10:24] <Unit193> :)
[10:24] <Odd_Bloke> Or is ubottu playing Unit193? :p
[10:24] <pitti> let the Turing test begin
[10:41] <caribou> pitti: is there a 'smart' way to run DEP8 tests on debian (equivalent to adt-buildvm-ubuntu-cloud) using qemu virt ?
[10:45] <doko> Laney, because then the loaders dir changes as well. I wasn't sure what would need changing too. so best thing would be change it as well, and rebuild all things having loaders
[10:47] <Laney> doko: you can't have external loaders, so I think it's okay
[10:53] <rbasak> caribou: there are instructions in the adt-virt-qemu manpage
[10:53] <caribou> rbasak: thanks; didn't think to look there :)
[10:54] <Laney> doko: unless you can think of any other reasons, I'll do a full multiarch in Debian & then sync, if that's okay?
[10:55] <doko> Laney, sure, but there's still #815727
[10:55] <doko> but I assume that's addressed with your rationle
[10:55] <doko> rationale even
[10:56] <Laney> yup
[10:56] <Laney> I was trying to figure out why you did it that way
[12:04] <pitti> hallyn: I followed up to bug 1579922, but you pretty much figured it out already (I used d-s-h to also clean up in the Debian specific enablement tracking, although that's not really that important)
[12:04] <pitti> hallyn: and it's far from moronic, this is way more complicated than it ougth to be..
[12:17] <crocodilehunter> where the devs at?
[13:05] <cpaelzer> Hi, I've seen the following in my builds quite often - is there something I e.g. can/should add to build dependencies to avoid that?
[13:05] <cpaelzer> dpkg-distaddfile: warning: File::FcntlLock not available; using flock which is not NFS-safe
[13:05] <cpaelzer> googling for it hit so many build logs that the obvious solution (if ther is one) is hidden behind them
[13:14] <smoser> Odd_Bloke, why would it be 6 minutes ?
[13:15] <Odd_Bloke> smoser: I have no idea. :)
[13:16] <asac> happyaron: to lp?
[13:17] <smoser> Odd_Bloke, where did you see this ?
[13:18] <Odd_Bloke> smoser: Vexxhost.
[13:19] <GunnarHj> Hi bdmurray, could you please move the SRU at bug #1575555 to -updates? Affects quite a few users.
[13:19] <barry> Laney: yeah.  unfortunately i doubt i'll be able to finish that before pycon.  i got pulled into another project that has higher priority. :/
[13:37] <happyaron> asac: yep, so I can put the git repos under the team, :)
[13:38] <mvo> pitti: I uploaded a new 2.0.5 version that fixes the issues you mentioned
[13:38] <pitti> ah, still with +16.10 .. unusal version number for devel
[13:39] <pitti> mvo: thanks!
[13:40] <mvo> pitti: our target right now is still xenial, thats where this comes from, but yeah, easy to enough if it really bothers someone :)
[13:40] <pitti> cjwatson: I tested http://paste.ubuntu.com/16506628/ locally as much as possible (with local britney.py b2 run and running the sed locally), and it works; does that look halfway sensible?
[13:41] <caribou> pitti: when DEP8 tests run on the builders using qemu virt, are the qemu images rebuilt each time ?
[13:41] <cjwatson> cpaelzer: no, just ignore it
[13:41] <cjwatson> pitti: I think so, but you'll also need something elsewhere to save the output somewhere useful
[13:42] <pitti> cjwatson: isn't the new output_notest.txt rsynced to people.u.c?
[13:42] <cjwatson> pitti: bit more complicated than that, look at the stats function
[13:42] <pitti> cjwatson: I actually can't sudo -u ubuntu_archive -i any more on lillypilly, might be that this got moved somewhere?
[13:43] <cjwatson> pitti: also there's no rsync involved, lillypilly does proxypass to snakefruit
[13:43] <cjwatson> pitti: ubuntu-archive@lillypilly is gone
[13:43] <cjwatson> pitti: you just need to put the files somewhere plausible in $HTML in the stats function
[13:43] <pitti> cjwatson: ah, so snakefruit:~ubuntu-archive/public_html is "the thing"
[13:43] <cjwatson> yep
[13:43] <pitti> cjwatson: understood, thanks
[13:45] <pitti> cjwatson: http://paste.ubuntu.com/16506661/
[13:45] <pitti> cjwatson: I deliberately didn't archive it yet, I don't think it's very useful (if we want it later, we can still add it)
[13:45] <pitti> cjwatson: archive> $HTML/update_excuses/$SERIES/$NOW
[13:46] <pitti> actually, only doing that for the devel series would suffice, and save some time
[13:46] <pitti> so, adding a [ "$SERIES" = "$DEFAULT_SERIES" ]
[13:48] <cjwatson> pitti: that seems fine; the archives are very large as it is
[13:48] <cjwatson> pitti: oh, one other thing
[13:49] <cjwatson> pitti: the output from this all gets dumped into the raw log, and I think it might be confusing to have the two runs in succession
[13:49] <pitti> cjwatson: next iteration: http://paste.ubuntu.com/16506698/
[13:49] <cjwatson> pitti: I think the notest run should be >/dev/null 2>&1
[13:49] <cjwatson> or at least >/dev/null
[13:49] <pitti> cjwatson: good point; I'd do one run as-is, check that everything works as intended, and hten commit the >/dev/null ?
[13:50] <cjwatson> pitti: first if there should have an else block that rms output_notest.txt
[13:50] <cjwatson> rm -f that is
[13:50] <cjwatson> otherwise it'll get confusing when a series goes from default to non-default
[13:50] <pitti> cjwatson: ah, that applies to both if's actually
[13:51] <asac> happyaron: ok done
[13:51] <asac> thanks
[13:53] <cpaelzer> cjwatson: thanks!
[13:54] <pitti> cjwatson: http://paste.ubuntu.com/16506747/
[13:54] <pitti> cjwatson: (I can locally drop the >/dev/null for debugging on snakefruit if needed); I also dropped the -v, no point with >/dev/null
[13:55] <dannf> hallyn: oh, good catch. and yeah - i'll add that patch for ya.
[13:56] <cjwatson> pitti: LGTM
[13:56] <pitti> cjwatson: thanks for your review!
[14:06] <hallyn> pitti: it seems like a sort of 'deb-systemd-helper rename-service pkg1.service pkg2.service new-package' would be helpful
[14:06] <hallyn> pitti: in libvirt it's a bit simpler bc we restart on upgrade,
[14:07] <hallyn> but if we didn't want to restart - as in lxcfs - then this would be even more complicated
[14:08] <pitti> hallyn: yeah, then it gets hairy, as you remove the unit from the disk, so you can never restart it ; i. e. this basically needs a reboot (or a way to restart it after all)
[14:10] <hallyn> pitti: but so when i have libvirt-bin.service provided by libvirt-bin pkg, and an upgrade doesn't have libvirt-bin.service;  does the upgrade not turn off and disable the libvirt-bin.service?
[14:11] <pitti> hallyn: no, debhelper can't know that an earlier package version used to ship a unit that doesn't exist any more
[14:11] <pitti> hallyn: i. e. there could certainly be some debhelper/dpkg-maintscript helper for this, but it needs to be declared explicitly
[14:11] <hallyn> heh, sure it can, we have the technology :)   I thought prerm and postrm would do it
[14:11] <hallyn> ok.
[14:12] <hallyn> clearer then
[14:12] <hallyn> thanks!
[14:12] <pitti> well, we could pry it out of the /var/lib/systemd/deb-systemd-helper-enabled/ data
[14:13] <pitti> but that doesn't have information which package shipped a service, so no
[14:13] <hallyn> ... dpkg -S knows...
[14:13] <pitti> at most, preinst could iterate over the previous .deb contents and disable stuff that disappeared, but that's well within "flaky heuristics/overcomplicated" territory I think
[14:14] <pitti> so I think explicitly declaring this is more practical (also given how rare this is)
[14:14] <hallyn> ok
[14:14] <pitti> but that declaration should be much easier than writing the preinst code etc. yourself
[14:15] <hallyn> actually what i think surprised me most was finding out that aliases are stored... under /etc.
[14:15] <hallyn> so /etc/systemd is where deb-systemd-helper stores its info?
[14:15] <pitti> hallyn: well, not speicifcally for d-s-helper
[14:15] <pitti> that's where systemd itself stores its info
[14:16] <pitti> /var/lib/systemd/deb-systemd-helper-enabled/ is just a helper to see whether or not to enable newly appearing services during upgrades
[14:16] <pitti> hallyn: yes, Alias= translates to nothing more than a symlink in /e/s/ for the new name
[14:25] <pitti> cjwatson: http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_output_notest.txt \o/
[14:25] <pitti> and the world didn't explode, it didn't clobber HeidiResult, and stuff with regressions didn't get promoted
[14:25] <cjwatson> great
[14:25] <pitti> cjwatson: thanks for your help!
[14:26] <cjwatson> np
[14:26] <pitti> doko: FYI: http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_output_notest.txt
[14:27] <caribou> pitti: when running DEP8 tests with adt-run, one can provide the --show-boot to the qemu runner, is it possible to have that done systematically by the builders ?
[14:28] <caribou> pitti: in short, is there a way to stipulate that in the source package ./debian/tests/control file ?
[14:28] <doko> pitti: nice. some for excuses?
[14:45] <bdmurray> pitti: was complaining about items in the xenial-proposed queue done in bugs?
[14:50] <karstensrage> thank you Laney !!
[15:01] <pitti> caribou: there isn't, as most virt backends don't actually have that option
[15:01] <pitti> bdmurray: yes, I followed up to the referenced bug reports; a few issues got sorted out in the meantime and rejected
[15:02] <caribou> pitti: k
[15:03] <pitti> doko: not right now, what would be the point? it's regular excuses if you ignore the tests
[15:04] <LocutusOfBorg> what happened to ppc64el builders?
[15:04] <pitti> bos01 cloud just died
[15:04] <pitti> autopkgtests on ppc64el are down too
[15:05] <bdmurray> pitti: Thinking about the process did you subscribe to those bugs? Should we tell people to really ping us after fixing stuff?
[15:05] <LocutusOfBorg> :(
[15:06] <pitti> bdmurray: I didn't subscribe, I was just going to look again when I reprocess; but sub'ing sounds better indeed, I'll do that from now on
[15:06] <cjwatson> impressive, I can't even sync logs from the ppa-manage unit
[15:06] <pitti> even "nova list" is hanging
[15:08] <bdmurray> pitti: Maybe we should put that in the SRU process then
[15:08] <LocutusOfBorg> also almost all the arm64 build started some minutes ago are stuck in the fetch of gcc-4.9
[15:08] <cjwatson> yes they're in the same cloud.
[15:10] <LocutusOfBorg> thanks
[15:56] <seb128> wtf
[15:57] <seb128> sil2100, seems like you are copying some sort of overlay over to yakkety?
[15:57] <Laney> barry: I'll upload what is (hopefully) a syncable version to unstable, and you can pick it up when ready
[15:58] <barry> Laney: +1.  won't be until after pycon for me tho
[15:58] <Laney> no biggy
[15:58] <seb128> sil2100, unping
[15:59] <sil2100> seb128: yeah, a batch copy of binaries, now will proceed with doing source copies for projects that had no-change rebuilds
[15:59] <seb128> sil2100, I though one was reverting some xenial changes but I got confused by the changelog
[15:59] <sil2100> (mentioned it on -release just in case there are any objections)
[15:59] <hallyn> dannf: so, just to be sure, you're going to push that?  Or were you wanting me to?
[16:11] <showaz> zabbix 3.x (agent) not work 15.04/16.04
[16:11] <dannf> hallyn: already did :)
[16:13] <hallyn> dannf: rockin' :)  thanks
[16:13] <hallyn> then i can move on to qemu merge
[16:18] <tdaitx> bdmurray: regarding 1566201, I can't reproduce the error locally, I just get a message:
[16:18] <tdaitx> Unknown channel 'xenial-partner'
[16:18] <tdaitx> The channel 'xenial-partner' is not known
[16:21] <tdaitx> bdmurray: if I remove the "?channel=xenial-partner" param then a pop up "Install additional software" comes up and I can install it normally
[16:21] <bdmurray> tdaitx: cyphermox and I are working on it
[16:22] <tdaitx> bdmurray: nice, let me know if you need some testing... I'm not running unity though, I wonder if that is why I can't reproduce it...
[16:23] <bdmurray> tdaitx: what was the command line you are using?
[16:29] <tdaitx> bdmurray: the one from the bug report (with sudo)
[16:30] <tdaitx> bdmurray: let me know if I should test without sudo (I have a private ppa entry in sources.list.d that is unreadable for any other use besides sudo and apt tools fail to work because of that)
[16:31] <tdaitx> * s/besides sudo/besides root/
[16:59] <mvo> bdmurray: if you could have a look at todays snapd 2.0.5 sru upload, that would be great
[17:00] <bdmurray> mvo: okay
[17:19] <GunnarHj> bdmurray: Thanks. :)
[17:41] <LocutusOfBorg> I hope you will catch the arm64/ppc64el soon :)
[17:43]  * LocutusOfBorg leaves
[17:45] <bdmurray> dosaboy: From which archive did you test the fix for bug 1578351? The clould archive or the official ubuntu one?
[17:45] <egsome> I'm thinking in creating a simple application which hooks into Apport to track program crashes and retrieve possible solutions from AskUbuntu and other websites. What do You think about that ?
[17:46] <bdmurray> egsome: When you say solutions do you mean workarounds / hacks or updated packages to install which fix the crash?
[17:47] <egsome> bdmurray, All of them. Workarounds, Hacks and Packages to install or update.
[17:47] <dobey> i think that's a bad idea
[17:47] <dobey> workarounds/hacks are unsupportable, and can possibly cause problems when fixed packages are available
[17:48] <egsome> dobey, Great, Why then ?
[17:48] <egsome> dobey, OK, You're right, and that what would be displayed to the user, to be careful while using any of these solutions.
[17:49] <dobey> and it perpetuates a problem we have with random people on the internet giving bad information to users
[17:49] <egsome> dobey, But, What actually happens for most of Ubuntu users, is their being looking for answers ( Hacks, Workarounds, .. ) simply in Google once they face a crash or a problem.
[17:49] <dobey> "be careful" isn't enough
[17:50] <dobey> if you want to make the situation better, then the better thing to do would be to help fix the crashes and get the fixes landed in ubuntu and then SRUed out to the stable releases
[17:50] <egsome> dobey, Users would be able to see the possible solutions / workarounds, also the comments written on them, and maybe the rating of the answer ( Stack Overflow ).
[17:52] <egsome> dobey, Fixing the bugs is something important, which I don't consider as part of the idea I'm talking about. The idea simply make the Ubuntu Community closer to new users and even old Ubuntu users.
[17:53] <dobey> well, for one, there shouldn't be anything on askubuntu about "solving" crashes, because bug reports are off topic for ask ubuntu, so any question about a crash should be closed as off topic, and tell the person to report a bug
[17:54] <dobey> sending mroe people to askubuntu to be turned away because they're asking off topic things, is not the right way to do whatever it is you're trying to do :)
[17:54] <egsome> dobey, I'm not going to send people to AskUbuntu, I'm just developing a tool that queries AskUbuntu and similar resources for possible workarounds and solutions.
[17:55] <egsome> dobey, OK, Let's talk about an issue like nm-applet being closed or "hidden" as most users express.
[17:55] <dobey> express?
[17:56] <egsome> dobey, I remember I saw lot of questions on AskUbuntu about it, and people talking about how to get it back, is that also off-topic ? I'm not sure, just asking.
[17:56] <egsome> dobey, Sorry, I mean "as most users say or consider it is just getting hidden not crashed"
[17:56] <dobey> while there may be a serious issue related to network-manager in 14.04 as the result of some other update, trying to generalize the sitaution to all problems isn't helpful.
[17:57] <egsome> dobey, I'm using 16.04 and nm-applet also crash for specific situations.
[17:57] <dobey> well yes, any software running on any comptuer can crash for many reasons
[17:58] <dobey> it doesn't mean that you are prescient of those reasons or can somehow determine what to query askubuntu or other sites for
[17:58] <nacc> does askubuntu even export an API to search all questions?
[17:58] <dobey> nacc: yes, SE has an API
[17:58] <egsome> dobey, I mean that such a tool can be useful in such cases, nm-applet crash, Apport dialog appear with possible solutions or workarounds like how to get it running again.
[17:58] <nacc> dobey: ah ok, thanks
[17:59] <nacc> egsome: but i think the underlying question is how do you determine "possible solutions or workarounds"?
[17:59] <egsome> dobey, While that happen, the bug report already sent, and fixing the bug is the most important mission have to be done.
[17:59] <nacc> egsome: as in, how do you know what is the root cause of the bug?
[17:59] <dobey> egsome: askubuntu has no idea what crash reports are. the only way apport could associate a crash with a question would be if the question had a pre-existing crash report, and apport could find and match that data
[17:59] <dobey> egsome: otherwise, it's just an arbitrary search, and it's only going to add confusion to the problem
[18:00] <egsome> nacc, Apport collect lot of details about the crash, I'm sure that can be done in accurate way, maybe not the best, but would save lot of time, as I think.
[18:00] <nacc> dobey: well- (better-than-me)-said
[18:00] <dobey> egsome: askubuntu, ubuntu forums, google, etc… have no idea about the contents of crash reports
[18:00] <dobey> so you can't query them to find "possible solutions"
[18:01] <egsome> dobey, Sure I'll not search using the whole report ! I'd get use of the keywords to get the closest possible question.
[18:01] <dobey> egsome: the only 'keywords' you could use are the package name. which as i said, is a general search and not going to be helpful here
[18:02] <egsome> dobey, Sorry, It is not the only one at all ! Apport reports include lot of details even the error message if available, all of that can be used for the querying !
[18:03] <dobey> egsome: well then just go do it. why did you ask what others think if you don't wnat to listen to any dissenting opinions? :)
[18:04] <egsome> dobey, I don't want to listen ?? I wouldn't come here to discuss at all if I don't want to listen ! I'm just discussing the points You mention, which I think the main objective of being in this channel, development-related discussions.
[18:04] <nacc> egsome: in open source development, code speaks louder than words, fwiw :)
[18:05] <egsome> dobey, Anyway, I'm sorry if I have been annoying somehow, and I'm open for any discussion related to the idea I told.
[18:05] <dobey> apport does a retrace on the crash reports server, not on the client. people don't go digging into the .crash files to find the stack trace signature when asking questions on askubuntu
[18:05] <egsome> nacc, That's a fact nacc, but discussing with others before coding is very important, to be capable of focusing our efforts on the right track.
[18:05] <dobey> they ask general things like "i have no network, how do i get it back?"
[18:06] <nacc> egsome: it would be interesting to see, if given your crash in apport, you can extract enough useful information to query askubuntu for relevant articles
[18:06] <egsome> nacc, That's exactly the core of my idea.
[18:06] <nacc> egsome: right, so do that for one specific case and see if it can work?
[18:07] <nacc> egsome: i disagree, in this case, re: discussing before coding
[18:07] <nacc> egsome: you can always rewrite
[18:07] <dobey> i'm just saying it's not feasible, because askubuntu doesn't know anything about crash reports. and your idea assumes that it does, and that there is useful information there related to how to "fix" the issues
[18:07] <nacc> egsome: but you've chosen a relatively difficult problem to get "right"
[18:07] <nacc> egsome: so it's better to try it first, see if it's tractable at all, then discuss, with that demo in hand
[18:07] <TJ-> Great project to rope in a DNN though!
[18:08] <dobey> i'm just pointing out all the difficulties you'll have to overcome to get something remotely close to what you want
[18:08] <egsome> dobey, Can You have a look here ? http://askubuntu.com/search?q=nm-applet include 539 questions mentioning nm-applet, not just "Network tray icon is not there". So, Crashes related to nm-applet would have 539 results to get the closest one using rest of the keywords provided in Apport crash report.
[18:09] <nacc> crashes != questions, as mentioned above -- they should be in bugs if they are crashes (and the question would have been closed, iiuc)
[18:09] <egsome> nacc, I agree with You. I think a working demo is required to have more clear discussions. And sure re-writing is always possible.
[18:09] <TJ-> egsome: if it helps you decide, I've been working on something similar, albeit with different aims, for 6 months now, and it is a very nuanced challenge to crack - artifical intelligence is the only way to have a chance
[18:11] <dobey> and if we had that, we wouldn't even need moderators on askubuntu any more, because the AI would be smart enough to close questions as spam, duplicates, off-topic, whatever
[18:11] <TJ-> you give AI too much credit... this is far harder than winning a game of a Go :)
[18:11] <nacc> skynet.
[18:12] <egsome> TJ-, I love AI, and I think Machine Learning can be used a lot to make that solution more smart and can decide more what to suggest to the user. Can I have a look at what You done so far if it is open-source ? I can even continue working on it with You if it is OK.
[18:12] <TJ-> egsome: it's not open (yet) and it's very different in aim (it processes live streams of data )
[18:12] <dobey> TJ-: my point exactly. if you had an AI that can understand the nuances of English, and the very bad English which is used on the Internet at that, then it would be good enough to be a moderator
[18:13] <nacc> i mean in some sense what you are describing is an 'expert system' for ubuntu bugs, which could take as input some 'bug report' and spit out from all data sources 'relevant data'. Sort of like a good google search :)
[18:14] <TJ-> dobey: as I told egsome in #ubuntu, any solution would need a lot of curating too
[18:15] <TJ-> to make such a system effective the training needs to be done by expert bug solvers who can recognise solutions from misguided shotgun approaches
[18:16] <jcastro> egsome: I think a generic AU scope would be useful
[18:16] <jcastro> we used to have one, and when it worked it was awesome
[18:17] <dobey> well, the suggested thing would be useless for the discussed situation where egsome is claiming it would be useful. if network-manager is crashing, and thus the applet has gone away, then there is no network, so apport would be unable to query AU anyway
[18:17] <egsome> TJ-, Exactly, Training is a key to success of such system.
[18:17] <jcastro> right, I'm just saying, if you ignore the crasher part, it's a good idea
[18:17] <nacc> dobey: :)
[18:18] <nacc> jcastro: good point, it's really two tools -- get stuff from crasher (unclear if it's possible) and query AU (useful)
[18:18] <TJ-> it'd be great for folks using Chrome and wondering why the backspace key no longer goes back through the history, though :)
[18:19] <egsome> jcastro, How it would be aware of the current issue user is facing without using the crash reports ?
[18:19] <egsome> jcastro, To be just as a Searching Tool for AU ?
[18:20] <nacc> egsome: don't try to solve too much :)
[18:20] <nacc> egsome: in one tool
[18:20] <dobey> askubuntu-mode.el
[18:22] <egsome> nacc, Do You mean to ignore the Crash analysis part ? Don't know, feel like it would be just a searching tool.
[18:23] <nacc> egsome: right
[18:23] <nacc> do *two* tools
[18:23] <nacc> egsome: there are two separate problems, as jcastro points out
[18:23] <nacc> or problem-spaces, i guess
[18:23] <egsome> nacc, One for analyzing the apport reports, and other for searching Communities of Ubuntu ?
[18:24] <nacc> right
[18:24] <egsome> nacc, Isn't Google enough for the second one ? I mean that second one can just be useful if integrated with the first one.
[18:24] <nacc> then your solution is just tying them together by passing data from one to the other, presumably
[18:24] <nacc> egsome: if so, then work on the first problem, but i don't think it is
[18:24] <nacc> given some input, i dont' think google gives you the most relevant results
[18:25] <nacc> or even knows what relevancy is, beyond its own algorithms
[18:25] <egsome> nacc, Sure it doesn't, I've to do lot of work to make it capable of searching for the problem included in the Apport report.
[18:25] <dobey> google is a pretty poor search engine any more
[18:25] <dobey> but good if you like living in a bubble
[18:26] <egsome> I think it is a good idea to begin with the part of analyzing Apport reports. I'm thinking in hooking into it using the py hooks available, and get the info of each report, and try to get out the primary keywords that can be useful in searching for the solutions or workarounds.
[18:31] <TJ-> egsome: maybe see https://launchpad.net/+tour/api
[18:33] <nacc> dobey: true
[18:33] <ogra_> sounds more llike another frontend to errors.ubunntu.com
[18:33] <egsome> TJ-, Thanks, I'm writing now a simple Apport hook in Python, trying to get a deeper idea of the structure of  'report' object passed. I hope it is well structured.
[18:34] <ogra_> *http://errors.ubuntu.com
[18:34] <nacc> egsome: --^ may want to look at htat too
[18:34] <ogra_> which already maps crashes to bugs
[18:35] <nacc> yep
[18:35] <egsome> nacc, ogra_, Going to have a look at that.
[18:35] <nacc> and there's tooling,i think, to add new rules to help it along
[18:36] <dobey> errors.u.c has restricted permissions because crashes may contain private info
[18:36] <nacc> which goes back to my previous point of how much information do you legitimately expose of the user's crash data to do these queries...
[18:37] <dobey> basically, as little as possible, and only over secure transports
[18:40] <nacc> yep
[19:19] <dosaboy> bdmurray: i tested both xenial-proposed and trusty-proposed/mitaka (UCA) so should be good to go
[19:23] <bdmurray> dosaboy: Got it, thanks for clarifying in the bug.
[19:23] <dosaboy> bdmurray: np
[21:09] <mwhudson> i have a vaguely general question, this failed build https://launchpad.net/ubuntu/+source/golang-github-hpcloud-tail/1.0.0+git20160415.b294095-3/+build/9686605 is blocking -proposed migration
[21:09] <mwhudson> i don't really care about this package, i care even less about it on powerpc but i want to get it off the excuses page
[21:10] <mwhudson> i think the best way to do this would be to remove the binary from yakkety-release and then it can continue to ftbfs on powerpc
[21:10] <mwhudson> infinity, slangasek: does this ^ sound plausible? needs an AA presumably
[21:18] <slangasek> mterry: does require an AA, yes; is generally a reasonable solution for per-arch build failures that we don't expect to see fixed, provided there's a specific reason why; in this case golang-github-mitchellh-packer-dev also depends on it so you'd need to go up the chain an remove revdeps too
[21:18] <slangasek> hum
[21:18] <slangasek> mwhudson: does require an AA, yes; is generally a reasonable solution for per-arch build failures that we don't expect to see fixed, provided there's a specific reason why; in this case golang-github-mitchellh-packer-dev also depends on it so you'd need to go up the chain an remove revdeps too
[21:18] <mterry> :)
[21:18] <mwhudson> :-)
[21:18] <mwhudson> ok
[21:18] <mwhudson> surely golang-github-mitchellh-packer-dev is an _all package?
[21:19] <mwhudson> huh no it isn't
[21:19] <mwhudson> well that's strange
[21:19] <mwhudson> oh it's never built on powerpc though
[21:20] <slangasek> ah
[21:20] <slangasek> ok then
[21:20] <slangasek> (and yes, actually the -dev package is arch: all, so that's fine anyway)
[21:20] <mwhudson> slangasek: file a bug, subscribe ~ubuntu-archive or can you just jfdi?
[21:21] <mwhudson> btw looking into build failures in odd situations is a good way of finding hilarious bugs
[21:21] <slangasek> mwhudson: for this particular build failure, why is golang-golang-x-sys-dev apparenly so broken?
[21:21] <mwhudson> https://github.com/golang/go/issues/15738 <- my favourite bug of recent months
[21:21] <mwhudson> slangasek: it just doesn't have support for powerpc
[21:22] <slangasek> ok
[21:22] <mwhudson> it's an inherently arch/os dependent package
[21:22] <mwhudson> it could be added
[21:22] <slangasek> good argument for removing the binary
[21:22] <slangasek> removed
[21:22] <mwhudson> thanks
[21:22] <mwhudson> i chased s390x support in golang-golang-x-sys-dev in via debian yesterday :)
[21:59]  * mwhudson afk for a while