[03:42] <robert_ancell> duflu, does bug 1557984 actually relate to LightDM directly?
[03:43] <duflu> robert_ancell: No, but yes. Depends on whether urandom is already getting run on the phone. I'm not sure yet
[03:43] <robert_ancell> duflu, where is lightdm.override?
[03:43] <duflu> It gets run at level S but not rc level 2 (normal boot)
[03:44] <duflu> robert_ancell: upstart scripts dir
[03:44] <duflu> /etc/init/ from memory
[05:50] <hikiko> Hi
[08:19] <pitti> Good morning
[08:23] <didrocks> hey pitti
[08:23] <pitti> meh, seems our data center is on fire again
[08:23] <pitti> bonjour didrocks !
[08:23] <didrocks> pitti: good luck (I think you need then to restart some of your services)
[08:24] <pitti> well, they auto-retry, but doesn't help; ssh times out on the instances
[08:24] <didrocks> yeah
[08:55] <TheMuso> Hey willcooke.
[08:56] <willcooke> evening TheMuso
[08:59] <seb128> hey TheMuso willcooke pitti, re didrocks
[09:02] <pitti> bonjour seb128 !
[09:02] <didrocks> re seb128
[09:04] <Laney> meowowowow
[09:04] <alexarnaud> hello world!
[09:08] <seb128> hey Laney
[09:08] <seb128> hey alexarnaud
[09:09] <seb128> how are things in other part of Europe and for our u.k friends?
[09:14] <Laney> hey seb128!
[09:14] <Laney> blue sky!
[09:15] <seb128> here as well
[09:15] <seb128> quite a nice day
[09:15] <seb128> yesterday evening was very nice as well
[09:15] <seb128> not too cold, dry and no wind
[09:16] <seb128> I played tennis for 2 hours was good to be outside
[09:16] <seb128> it even start still being day at 7pm ;-)
[09:17] <Laney> yep, this is good
[09:17] <Laney> and then the clocks are changing soon which means even more light evenings
[09:17] <seb128> indeed
[09:18] <Laney> hey didrocks
[09:18] <Laney> I found https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1556175 ;-)
[09:18] <seb128> didrocks, Laney, btw did you get details on your shutdown issues?
[09:18] <seb128> lol
[09:18] <Laney> HEH
[09:18] <Laney> happy days
[09:18] <seb128> ;-)
[09:19] <pitti> Laney: sorry, I hope you didn't waste too much time on that
[09:19] <pitti> Laney: I wasted 1.5 hours on Friday, only to find out that it was already known
[09:19] <pitti> but lamont is currently landing fixes
[09:19] <Laney> [  276.668148] systemd[1]: networking.service: State 'stop-sigterm' timed out. Killing.
[09:20] <Laney> pitti: nah, I analysed a log and then found the bug
[09:20] <pitti> yep, dhclient doesn't want to die
[09:20] <pitti> ok, good
[09:20] <Laney> so thanks for filing it!
[09:20] <pitti> Laney: I put a "pkill -9 dhclient" workaround into the autopkgtests reboot hooks for that
[09:20] <pitti> h4cks 4r3 us
[09:20] <Laney> 31337
[09:20] <Laney> it's good enough for me to be able to leave the room
[09:20] <Laney> if I know it's going to shut down eventually :P
[09:21] <pitti> Laney: I sorted out the worker serial timeout suicide du jour now
[09:21] <Laney> nice
[09:21] <Laney> what was it now?
[09:21] <pitti> so much fun
[09:21] <pitti> Laney: the vivid-proposed kernel is botched
[09:21] <pitti> Laney: that, and lgw went down last night
[09:21] <pitti> not fully back yet, disabled now
[09:21] <Laney> :/
[09:21] <pitti> but things are catching up now
[09:22] <seb128> we have infra on vivid?
[09:22] <seb128> and using -proposed?
[09:23] <Laney> autopkgtests
[09:23] <pitti> seb128: touch
[09:23] <seb128> oh, I guess that makes sense if we still do uploads there
[09:23] <seb128> ah, right
[09:23] <seb128> good old touch!
[09:23] <pitti> with emphasis on "OLD"
[09:24] <Laney> still uploading the kernel though?
[09:24] <seb128> indeed
[09:24] <pitti> Laney: yeah, for *drumroll* touch
[09:24] <pitti> and I think we have some snappy stuff there too
[09:24] <Laney> I thought that used device specific things
[09:24] <pitti> I think kernel is actually for snappy, yes
[09:24] <Laney> fair
[09:25] <Laney> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1558447
[09:26] <pitti> yep, was just talking to apw :)
[09:26] <Laney> HMM
[09:27]  * Laney might be spotting an appstream-dep11 bug
[09:27] <seb128> oh! which one?
[09:27] <seb128> Laney, btw do you know if not using our custom screenshot server is a design decision?
[09:27] <Laney> https://paste.ubuntu.com/15406870/
[09:27] <seb128> or asked differently if there is a reason to not add it as a fallback case
[09:28] <Laney> the decision is to have upstreams provide them
[09:28] <Laney> probably ask ximion
[09:28] <seb128> right
[09:28] <seb128> but meanwhile we have a stack of apps not there yet and which have screenshots on our side
[09:29] <seb128> so it looks like we do a "if no_upstream_screenshot; try ours"
[09:29] <seb128> k
[09:29] <seb128> going to ask him when he's online
[09:30] <seb128> brb testing a greeter change
[09:35] <seb128> woot
[09:35] <seb128> that made my day I think
[09:35] <seb128> https://code.launchpad.net/~kaihengfeng/unity-greeter/fix-hidpi-trasition-wallpaper/+merge/289137
[09:35] <seb128> Laney, ^ can you try that?
[09:35] <seb128> it seems to fix the greeter->login visual corruption issue we have since we enabled scaling
[09:35] <seb128> robert_ancell emailed me to ask if I can test since he doesn't have hidpi hardware
[09:36] <Laney> ok, will do shortly
[09:36] <Laney> fixing this bug first
[09:36] <seb128> I don't either but I GDK_SCALE trick which was enough to see the issue and it seems resolved with ^ for me, but confirmation from somebody with actual hardware/real workflow would be nice
[09:36] <seb128> I though that would be tricky and that we would likely not look at it before release
[09:37] <seb128> so it's great that somebody did ;-)
[09:38] <willcooke> gnight TheMuso
[09:40] <seb128> chrisccoulson, hey
[09:40] <chrisccoulson> hi seb128
[09:41] <seb128> chrisccoulson, how are you?
[09:42] <chrisccoulson> seb128, I'm not too bad thanks. How are you?
[09:42] <seb128> I'm good thanks ;-)
[09:42] <willcooke> chrisccoulson, nudge: https://code.launchpad.net/~willcooke/firefox/bookmarks-update/+merge/286633
[09:42] <seb128> chrisccoulson, I see you just did another firefox upload and I think you didn't respond to will ping the other day ... ^
[09:42] <willcooke> ha!
[09:42] <seb128> bah, willcooke just snaped me on it :p
[09:42] <willcooke> some physic stuff going on here
[09:42] <seb128> urg, one ctrl-W too much
[09:43] <seb128> not rage quiting don't worry ;-)
[09:43] <willcooke> LOL
[09:43] <chrisccoulson> seb128, willcooke, yeah, I'll get to it. Unfortunately, we have bigger issues with Firefox right now ;) (like the fact that we can't currently produce builds for the next version)
[09:43] <willcooke> pfft.  Builds.
[09:44] <willcooke> ;)
[09:44] <willcooke> thanks chrisccoulson
[09:44] <seb128> chrisccoulson, it's a one liner, seems like it would take a minute
[09:44] <seb128> but yeah, build is more important ;-)
[09:44] <seb128> chrisccoulson, thanks!
[09:44] <seb128> "one line in bookmarks" even
[09:44] <seb128> one line of code can be more difficult to review since it might impact on things
[09:46] <seb128> chrisccoulson, what's the issue with the next version? toolchain fun?
[09:46] <seb128> willcooke, you might know, but is chrome dropping support for 32bits?
[09:47] <seb128> the trusty install from my gf told him that chrome wasn't supporting that platform anymore and would get newer updates
[09:47] <seb128> that's a i386 install, so I guess it's the issue but I was not sure
[09:48] <chrisccoulson> seb128, yes, google is dropping support for x86, and also 12.04
[09:48] <willcooke> seb128, it is dropping support yeah.  Chromium won't be for a while, or at least qengho has said he'll keep building it for 32bit for now.  But that will get harder and harder, so perhaps we need a plan to transition away
[09:48] <seb128> k
[09:48] <seb128> chrisccoulson, willcooke, thanks
[09:49] <willcooke> Maybe worth a UOS session
[09:49]  * willcooke adds it to his list
[09:49] <chrisccoulson> seb128, https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/FoE6sL-p6oU
[09:50] <chrisccoulson> Can we kill x86? ;)
[09:50] <seb128> lol
[09:50] <seb128> why so much hate :p
[09:50] <seb128> I might have to reinstall my laptop one day if you guys keep going this way
[09:51]  * happyaron waits to see seb128 reinstalls
[09:52] <willcooke> Not saying we should drop support (although, seriously, upgrade dude)
[09:52] <willcooke> but we should be public about our continuing support for 32 bit Cr.
[09:53] <willcooke> aka the Softpedia effect
[09:53] <willcooke> ;)
[09:53] <seb128> :-)
[09:53] <chrisccoulson> seb128, It'll be Firefox dropping support for x86 next - https://groups.google.com/forum/#!topic/mozilla.dev.planning/URCpj-kTjVU
[09:53] <chrisccoulson> And https://bugzilla.mozilla.org/show_bug.cgi?id=1209932
[09:53] <seb128> bah
[09:53] <willcooke> wow
[09:55] <davmor2> willcooke: well even windows 7/8/10 are 64bit by default
[09:55] <Laney> haha
[09:55] <Laney> that doesn't say that
[09:55] <Laney> you fearmonger
[09:56] <davmor2> Laney: if you stop testing an arch the next step is dropping it
[09:56] <Laney> balls
[09:56] <chrisccoulson> Laney, from experience, if there's no tests, it breaks fairly quickly
[09:57] <davmor2> chrisccoulson: just look at devel-proposed
[09:57] <chrisccoulson> And see https://bugzilla.mozilla.org/show_bug.cgi?id=1209932#c1
[09:57] <chrisccoulson> Laney, see https://developer.mozilla.org/en/docs/Supported_build_configurations for a description of the support levels. No tests and no builds is tier 3 (ie, the same as powerpc)
[09:59] <chrisccoulson> I wish we had an idea of how many ubuntu users are using x86, and of those users, how many of them could run x86-64
[10:00] <seb128> _o/
[10:01] <seb128> :-)
[10:05] <chrisccoulson> does anybody on the desktop team have an account on https://bugzilla.mozilla.org/ ?
[10:08] <seb128> I don't
[10:08] <seb128> why?
[10:08] <chrisccoulson> seb128, it would be useful for me to subscribe someone on the desktop team to some issues :)
[10:10] <seb128> lol
[10:10] <seb128> try ask to willcooke if he wants to create one
[10:10] <seb128> he already picked up the theme and seems up to challenge, and he seems to like webbrowser so who knows... ;-)
[10:12] <chrisccoulson> Oh, willcooke already has an account
[10:13] <willcooke> yeah, I subscribed to a few issues before
[10:13] <willcooke> feel free to sub me
[10:48] <willcooke> ARGH the wiki search is flippin useless
[10:49] <willcooke> We'd be better off embedding a simple Google box pre populated with site:wiki.ubuntu.com
[10:58]  * Laney wrings hands
[11:32] <alexarnaud> didrocks: Hey! I see we'll gointo to Paris next wednesday. I think I'll be there also.
[11:33] <didrocks> alexarnaud: excellent! :)
[11:49] <willcooke> Xenial release notes updated with Libre Office details.  Thanks Sweet5hark
[11:49] <desrt> hello desktop!
[11:50] <willcooke> what up desrt
[11:50] <Sweet5hark> willcooke: yw
[11:50] <Sweet5hark> desrt: welcome!
[11:50] <desrt> I am up.
[11:52] <desrt> at about 7pm last night i decided to go on a magical journey
[11:52] <desrt> achievement unlocked: IKEA by public transit
[11:53] <desrt> also, 15000 steps in my first full day of fitbit measurement :D
[11:53]  * desrt brought home a desk and a lamp on the subway
[11:54] <willcooke> :D  that must have been a whole bunch of no fun
[11:55] <desrt> it was actually pretty entertaining
[11:55] <desrt> i had to stop and rest a bit at some points though... those boxes get heavy
[12:00] <willcooke> :)
[12:13] <Sweet5hark> desrt: next time, buy a poäng and have the most comfy public transport ride ever!
[12:14] <desrt> lol
[12:15] <desrt> trying to picture how that works on the escellator
[12:18] <qengho> seb128: I think Chrome is already 64-bit only.
[12:20] <willcooke> Laney, cyphermox(?) - animal graphic due EOD
[12:26] <Laney> willcooke: 'k - do you know if anyone is updating the slideshow?
[12:27] <willcooke> I don't, hence CCing c_yphermox
[12:27] <willcooke> If he doesn't know, I'll do some digging
[12:27] <willcooke> (I think it was he who did it last time0
[12:27] <willcooke> )
[12:28] <Laney> willcooke: noooooooooooooo
[12:28] <Laney> I mean new content
[12:28] <willcooke> ohh
[12:28] <willcooke> then no
[12:28] <Laney> it has a thing about the software center
[12:28] <willcooke> oh, good catch
[12:31] <Laney> nod
[12:36] <seb128> hey desrt!
[12:41] <seb128> desrt, Trevinho, how are the gtk changes going?
[12:41] <Trevinho> seb128: I'm waiting for a new review
[12:42] <seb128> desrt, you have that on your list for today?
[12:43]  * desrt didn't see the new patch
[12:43] <Trevinho> desrt: same MP https://code.launchpad.net/~3v1n0/gtk/unity-border-radius-support/+merge/288331, I linked that few days ago
[12:44] <desrt> ah.  indeed.  thanks.  i'll take a look.
[12:44] <seb128> thanks
[12:52] <willcooke> hey seb128 - just remembered... alternative toolbar in Rhythmbox.... I really like it.  Any thoughts on making it the default?
[12:52]  * willcooke is making installer screenshots
[12:52] <willcooke> oh wait, I forgot lunch
[12:52] <willcooke> brb
[12:52] <Trevinho> seb128: as for https://code.launchpad.net/~3v1n0/gtk/unity-maximized-headerbar-buttons-hide/+merge/288552 do you want take that or leave it to desrt as well?
[12:52] <seb128> willcooke, it's not as simple as changing a default, that was a plugin to install
[12:53] <seb128> I still have it on my list but but it wasn't high priority enough to push it forward
[12:53] <seb128> need a package MIRed etc
[12:53] <willcooke> seb128, sure, no worries.  I'll open a bug and we can track it for maybe next time
[12:53] <seb128> thanks
[12:54] <seb128> I might still try to have a look later today
[12:56] <willcooke> worlds crappiest "bug" report:  https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/1558539
[13:04] <desrt> Trevinho: looking a bit better, but a few things need fixing still
[13:04] <seb128> Trevinho, oh, sorry, forgot to reply, if desrt could do it that would be great
[13:04] <Trevinho> seb128: np
[13:04] <seb128> desrt, ^
[13:04] <Trevinho> desrt: checking
[13:04] <desrt> biggest problem: you moved the signal connect to widget::style-updated but you still disconnect from the context -> boom
[13:07] <cyphermox> willcooke: new animal soon, ack
[13:10] <willcooke> cyphermox, I'm fixing up the screenshots in the installer, so I can probably take care of that side of things
[13:12] <cyphermox> ok
[13:13] <cyphermox> we didn't usually do anything special, just replacing that one screen where the image is on top of the background image, IIRC centered vertically; and centered in the second half of the underlying image
[13:13] <cyphermox> lemme know when you need review/sponsoring
[13:13] <willcooke> thanks cyphermox
[13:25] <desrt> Trevinho: commented on the hide-titlebar bug too
[13:25] <desrt> this patch makes me unhappy...
[13:27] <desrt> it feels like it's inside out
[13:29]  * Laney hands in head
[13:30]  * desrt pats Laney on the back
[13:30] <desrt> willcooke: alternative toolbar?  https://img.grouponcdn.com/deal/4V2C4Bn3wp7cpM2KjTNK/AH-960x576/v1/c700x420.jpg
[13:32] <Laney> hi desrt
[13:32] <Laney> wrote a moderately dirty solution, then found out it doesn't work
[13:32] <Laney> so back to the start
[13:33] <Laney> luckily the approach I'm now trying is one I aborted a few hours ago
[13:34] <Laney> and stashed instead of just junking
[13:36] <Trevinho> desrt: border radius patch updated again, please check
[13:37] <desrt> will check in a bit
[13:51] <andyrock> hey all
[13:56] <Laney> hullo andyrock
[13:57]  * Laney tentatively runs this
[14:00] <seb128> hey andyrock! how are you?
[14:00] <seb128> still dealing with screensaver issues?
[14:01] <andyrock> seb128: today is the last day
[14:01] <andyrock> i'll push the changes
[14:01] <andyrock> it's a driver issues
[14:01] <seb128> great
[14:01] <andyrock> *issue
[14:01] <seb128> did you find something you can do to workaround it?
[14:01] <andyrock> nope
[14:01] <andyrock> the problem is going to be harder to reproduce
[14:01] <seb128> so what do you push? ;-)
[14:01] <andyrock> just changes that make sense to make the problem harder to reproduce
[14:02] <andyrock> but it cannot considered fixed
[14:02] <willcooke> seb128, turns out it's a driver issue
[14:02] <andyrock> i talked with intel guys yeasterday
[14:02] <willcooke> but andyrock has some improvements that we can use which make things less bad
[14:02] <andyrock> it's a very well known problem
[14:02] <seb128> k
[14:06] <seb128> andyrock, do you have an intel driver bug number for reference?
[14:06] <seb128> I'm just curious
[14:06] <andyrock> nope
[14:06] <andyrock> i just have the irc log
[14:06] <seb128> k, no problem
[14:07] <andyrock> they said they fixed a similar problem in the last few weeks
[14:07] <andyrock> but "mine" is not fixed yet but it's just the same problem
[14:07] <seb128> andyrock, btw I saw bug #1557717 ... that's what you were working on in London right? that never went anywhere?
[14:07] <andyrock> yup
[14:07] <seb128> k
[14:07] <andyrock> i moved to something else and now it's to late because it requires an api change
[14:07] <seb128> andyrock, I guess it's off the list for xenial at this point?
[14:08] <seb128> well, we could get a ffe if we really wanted
[14:08] <seb128> but I guess it might not be worth it
[14:08] <andyrock> indeed
[14:14] <willcooke> cyphermox, if I change the text in one of the slides to I need to manually update the pot file too?
[14:14] <cyphermox> I thought there was some command for it in the source
[14:14] <willcooke> ah, is that what update-launchpad-translations.sh  does
[14:15] <willcooke> hrm, no I dont think so
[14:16] <willcooke> ah
[14:16]  * willcooke reads the readme
[14:26] <abeato> pitti, hi, I have some autopkg tests from ofono-phonesim failing: http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#ofono
[14:26] <abeato> pitti, how do you debug this kind of issues?
[14:27] <abeato> I can reproduce locally using a qemu instance, but no idea on how to iterate on changing the testing script, etc.
[14:28] <pitti> abeato: I just retried it
[14:28] <pitti> abeato: you can call adt-run -s [....], then you'll get a shell after a test failure
[14:28] <pitti> and can then poke around, run just a single test, modify it, etc.
[14:29] <abeato> pitti, thanks, I'll try that
[14:48] <dobey> willcooke, seb128: we aren't shipping the unity8 session by default are we?
[14:48] <seb128> dobey, lol, no we are not
[14:48] <seb128> why?
[14:48] <seb128> it's not really ready for that and a good part of the stack is still in universe
[14:49] <dobey> seb128: so just having unity-scope-click depend on packagekit should make clicks installable, right?
[14:49] <dobey> afaict, installing packagekit doesn't break gnome-software installs
[14:49] <seb128> dobey, that might create issues for unity7 users
[14:49] <seb128> you are not Cced on that discussion?
[14:49] <dobey> seb128: what issues?
[14:50] <dobey> i wasn't no
[14:50] <seb128> it would swap out aptdaemon-pkkit.compat for packagekit
[14:50] <seb128> or packagekit 0.8 isn't handle debs so well
[14:50] <seb128> so you might get issues with langpacks or codecs installs on unity7
[14:50] <dobey> it does do that
[14:50] <dobey> installing packagekit removes the pkcompat package
[14:50] <seb128> right
[14:51] <seb128> but the apt backend is 0.8 is not good
[14:51] <seb128> so we need to fix that
[14:51] <seb128> or unity7 users are going to hit those bugs
[14:51] <seb128> *in* 0.8
[14:51] <dobey> so why can we not make the pkcompat in aptdaemon handle installing clicks?
[14:52] <seb128> dobey, who said we can't, patches are welcome ;-)
[14:53] <seb128> it's just work that nobody signed up to do
[14:53] <seb128> dobey, Cced you on the ongoing discussion, there are already a group of people discussing the topic so we can as well not duplicate work
[14:53] <dobey> well it seems better than the suggestion to build a whole new service to install clicks
[14:54] <dobey> right; i'm not volunteering to do work :)
[14:54] <seb128> well, next cycle we are going to upgrade to packagekit 1.0 and remove the aptd compat layer
[14:54] <seb128> so we are going to need to do the work anyway
[14:54] <seb128> packagekit 1.0 has no plugin
[14:55] <dobey> remove as in delete the code, or remove as in stop shipping the package?
[14:55] <dobey> because we could ship the pkcompat package on the phone still, instead of packagekit, when we upgrade to 1.0, if we just put the click stuff in there
[14:56] <seb128> stop shipping the package
[14:56] <seb128> well, in fact no
[14:56] <seb128> that compat code needs to be ported to packagekit 1.0
[14:57] <seb128> api changed in 0.8->1.0
[14:57] <seb128> so if we want to keep it we need to port the code
[14:57] <seb128> which we didn't plan to do
[14:57] <seb128> but again, patches are welcome if somebody is wanting to do that
[14:58] <alecu> seb128: dobey: would you mind if we continue this in a hangout?
[14:58] <seb128> alecu, we can, are we waiting for willcooke?
[14:58] <seb128> alecu, also you need to send me the url :p
[14:58] <alecu> done
[15:24] <dobey> seb128, alecu: so there's a silo under testing right now that has a unity-scope-click branch in it for another feature; as soon as it lands i'll stick the dep change into a silo so we can land it
[15:24] <seb128> great
[15:24] <alecu> dobey: sounds great, thanks
[15:30] <seb128> attente, hey, any idea if https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1558629 is fixed with your git changes to refresh the appstream index?
[15:30] <seb128> I guess not? that list is probably the apt one, right?
[15:31] <attente> seb128: no, it's not fixed yet. it does regenerate the index, but for whatever reason GS still refuses to update its internal catalog
[15:31] <seb128> k
[15:31] <seb128> but it's a known issue I guess from what you say
[15:31] <desrt> apt-get update wouldn't fix that anyway
[15:31] <seb128> if you are working on it maybe assign to be to yourself ;-)
[15:32] <desrt> since it has nothing to do with package lists, but rather dpkg state
[15:32] <attente> i thought i did?
[15:32] <attente> oh... that's a dupe
[15:33] <attente> oh... no, that's an entirely different bug
[15:33] <attente> sorry, i thought you were talking about https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1554023
[15:33] <desrt> attente: maybe it's the same bug, in fact...
[15:34] <desrt> i mean.. now that you trigger the apt update properly, the g-s refusing to update its internal catalog seems to be the same issue as g-s refusing to update after installing an update
[15:34] <attente> desrt: yeah, they seem quite similar
[15:34] <desrt> ie: maybe something is wrong about the way in which it monitors changes on the backend
[15:44] <seb128> hum, I wonder why g-s doesn't list rhythmbox in the updates list
[15:48] <willcooke> Laney, could you do me a hidpi screenshot of a default desktop with just g-s open?
[15:48] <Laney> is that one I gave to mhall11_9 ok?
[15:48] <willcooke> my screen res is too small to get the whole thing in to the size allowed for the installer.  I wonder if I might be able to scale a hidpi one a bit better
[15:48] <Laney> http://people.canonical.com/~laney/weird-things/g-s.png
[15:49] <willcooke> BOOM
[15:50] <willcooke> thanks Laney, that works nicely
[15:52] <Laney> sweet
[15:56] <Laney> fun distraction in appstream land
[15:56]  * Laney does the actual planned work
[15:56] <Laney> gggggggggstreamer
[15:57] <seb128> :-)
[16:28] <seb128> andyrock, Trevinho, do you have any idea why gnome-software and gnome-calendar don't get added to the dash recently used applications?
[16:28] <andyrock> seb128: is locked in the launcher?
[16:28] <seb128> no
[16:28] <seb128> it's listed in th dash if you type
[16:29] <seb128> but it just doesn't get list is recently used
[16:29] <andyrock> but it's no pinned in the launcher?
[16:29] <seb128> in
[16:29] <seb128> no it's not
[16:29] <andyrock> mmmm
[16:29] <seb128> try on your system
[16:29] <seb128> start gnome-calendar
[16:29] <seb128> close it
[16:29] <andyrock> i'm on w right now
[16:29] <seb128> ah, k
[16:29] <seb128> that might do the same :p
[16:29] <andyrock> i'll try in a moment
[16:29] <seb128> thanks
[16:29] <andyrock> let me push a branch
[16:29] <attente> seb128: it might be because it's still running as a gapplication service...
[16:30] <Trevinho> Mh, it's weird, there's should be nothing special
[16:30] <Trevinho> does the .desktop files define something particular?=
[16:30] <seb128> not that I know
[16:31] <seb128> attente, I though about that, but they are not listed even after being closed, also gnome-calendar doesn't seem to do that
[16:32] <seb128> in fact
[16:32] <seb128> /usr/share/dbus-1/services/org.gnome.Calendar.service
[16:32] <seb128> so yeah maybe
[16:32] <seb128> I wonder if the dash could do a better job with those
[16:32] <seb128> or if we need to patch them out to be such services
[16:33] <seb128> would dropping the .service be enough?
[16:33] <attente> seb128: was that after sigterm'ing it? it still happened?
[16:33] <seb128> attente, yes, they don't get registred in the dash it seems
[16:33] <seb128> it might have to do with how they start
[16:33] <attente> hrm...
[16:34] <seb128> well, gnome-calendar doesn't keep running here after I close the UI
[16:34] <seb128> though it used to do that
[16:34] <seb128> so nothing to kill
[16:35] <seb128> Trevinho, tedg, who "maintains" indicator-appmenu today? any opinion on https://code.launchpad.net/~seb128/indicator-appmenu/dont-recommends-qt4/+merge/287501 ?
[16:35] <andyrock> seb128, Trevinho does dash listen to zeitgeist events to monitor the "close"?
[16:36] <seb128> andyrock, I've no idea
[16:36] <seb128> willcooke, other thing we didn't really keep tracking but might want to ffe still https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1544376
[16:37] <seb128> willcooke, the fwupdate MIR was approved, the fwupd is waiting on security team
[16:37] <seb128> maybe worth checking with them
[16:37] <willcooke> seb128, I spoke to security the other day about those, they're
[16:37] <willcooke> on the case
[16:37] <seb128> k
[16:37] <willcooke> I spoke to Tyler on, maybe Monday
[16:37] <willcooke> maybe last week,
[16:38] <willcooke> anyway it was recently
[16:38] <tyhicks> sarnold is currently reviewing fwupd
[16:38] <willcooke> there you go
[16:38] <tyhicks> I think he's getting pretty close to being done
[16:38] <willcooke> :)
[16:38] <willcooke> thanks tyhicks
[16:38] <tyhicks> np :)
[16:39] <seb128> great
[16:39] <Laney> mhall119: aaahh
[16:39] <willcooke> The system works!
[16:39] <seb128> willcooke, I turned the gnome-software bug into a ffe
[16:39] <seb128> since we are going to need an ack
[16:39] <willcooke> thx seb128
[16:39] <Laney> mhall119: Then, set the Assigned To field to “ubuntu-sponsors”
[16:39] <Laney> mhall119: that should be telling people to subscribe
[16:40] <Laney> although there's a few already that have done neither
[16:41] <seb128> k, going for some exercice while it's still sunny outside
[16:41] <seb128> back in 45 min or so
[16:41] <willcooke> have fun seb128
[16:42] <willcooke> make pot
[16:42] <willcooke> err, wrong window
[16:42] <Laney> that's illegal
[16:42] <Laney> HAHAHAHAHAHAHA
[16:42] <willcooke> badum tisch
[16:42] <ogra_> now the NSA logs this channel too ... fun
[16:43] <willcooke> someone at the door brb
[16:43] <willcooke> and a black helicopter .
[16:43] <ogra_> :D
[16:44] <willcooke> alllrighty
[16:44] <willcooke> screenshots updated
[16:44] <willcooke> text and PO updates done
[16:44] <willcooke> just waiting on the arrival of the squirrel
[16:58] <flexiondotorg> Trevinho, Just seen your updates to my merge proposal for Compiz. Thanks for sorting that for me :-)
[16:59] <Trevinho> flexiondotorg: np, can you get someone to review it as well?
[16:59] <Trevinho> Albert maybe?
[17:00] <flexiondotorg> One sec...
[17:00] <Trevinho> flexiondotorg: ah, "\ No newline at end of file"... if you can add a blank line too...
[17:02] <flexiondotorg> Trevinho, I'll add the new line. The testers also sent me some other minor tweaks for the Compiz MATE profile lastnight.
[17:02] <flexiondotorg> Can I add those?
[17:02] <flexiondotorg> Basically shadowing tweaks.
[17:09] <flexiondotorg> Trevinho, The Ubuntu MATE team and Compiz-Reloaded (Compiz 0.8 fork) have tested the profile. We consider it good to go.
[17:09] <flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/compiz/mate-tweaks/+merge/289395
[17:09] <flexiondotorg> Trevinho, includes the missing new line also.
[17:25] <flexiondotorg> muktupavels, Could you review the following merge proposal please? https://code.launchpad.net/~ubuntu-mate-dev/compiz/mate-tweaks/+merge/289395
[17:26] <muktupavels> flexiondotorg, why me? I don't use MATE...
[17:27] <flexiondotorg> Trevinho, suggested you.
[17:27] <flexiondotorg> If for no other reason that a sanity check.
[17:27] <flexiondotorg> muktupavels, What do you run BTW/
[17:27] <muktupavels> flexiondotorg, GNOME Flashback...
[17:28] <flexiondotorg> Nice :-)
[17:32] <seb128> brb, colder outside with the wind that it looked like behind the windows!
[17:32] <willcooke> heh
[17:33] <seb128> it's ok though, after 15 min I was warm and now I'm red :p
[17:35]  * Laney remembers red seb128 from Oakland one time
[17:35] <seb128> lol
[17:35] <seb128> not the same red :p
[17:35] <Laney> :D
[17:36] <Laney> being spammed with icon bugs now
[17:36] <Laney> no way I can handle these on my own
[17:36] <seb128> :-/
[17:36] <seb128> are those tagged bugs or something?
[17:37] <Laney> yeah tag appstream
[17:37] <seb128> what are the issue? just people submitting icons?
[17:37] <Laney> yeah
[17:37] <Laney> I checked some
[17:37] <seb128> or also files in -common & such?
[17:37] <Laney> and often the upstream includes the icon already
[17:37] <Laney> people are just making or finding icons and attaching them
[17:41] <seb128> shurg
[17:41] <seb128> shrug even
[17:41]  * Laney ran:
[17:41] <Laney> In [16]: for bug in lp.distributions['ubuntu'].searchTasks(tags='appstream'): bug.bug.subscribe(person=lp.people['ubuntu-sponsors']) bug.lp_save()
[17:45] <seb128> I just saw dholbach jump on his chair and starting the email composer writing about how the sponsoring queue had an increase and needs some extra hands :p
[17:46]  * Laney skipped piloting so far
[17:46] <Laney> better do that tomorrow
[17:51] <seb128> tedg, Trevinho, saw my appmenu ping earlier?
[17:51] <willcooke> I gotta dash.  Beavers tonight. mhall119 can you help round up some support for Laney for checking all the icons?  ^^^ Seems your blog post was super effective!
[17:52] <willcooke> night all
[17:52] <mhall119> absolutely, what can I do Laney ?
[17:52] <muktupavels> Trevinho, https://code.launchpad.net/~albertsmuktupavels/compiz/gwd-dark-theme/+merge/289406
[17:53] <Laney> mhall119: first see my earlier ping
[17:53] <Laney> second get people to do some sponsoring :-)
[17:53] <Laney> probably more of a dholbach thing
[17:54] <seb128> yeah, new gst stack
[17:54] <mhall119> Laney: ack, I will udpate my block post shortly
[17:55] <mhall119> I cna also go through and change any created bugs to subscribe instead of assign
[17:55] <Laney> can you do that with urls?
[17:56] <seb128> Laney, btw the session-shortcuts .desktop are listed as apps in gnome-software, can we get those out in some way?
[17:57] <Laney> X-AppStream-Ignore=true
[17:57] <seb128> the new action .desktop to be able to e.g shutdown from the dash
[17:57] <seb128> k
[17:57] <mhall119> Laney: you mean auto-subscribe ubuntu-sponsors with URLs? I don't think so
[17:57] <Laney> nod
[17:58] <mhall119> we wouldn't want it assigned at creation time anyway, only after an icon has been attached
[17:58] <mhall119> s/assigned/subscribed/
[17:58] <Laney> I didn't see people doing the assignment anyway
[17:58] <Laney> not that I checked them all mind
[17:59] <Laney> 8° and time to go out for a ride
[17:59] <Laney> yeehaw
[18:00] <Laney> laters
[18:00]  * Laney one more sync
[18:00] <Laney> syncpackage: Error: Debian version 2.47.92-1 has not been picked up by LP yet. Please try again later.
[18:00] <Laney> :(
[18:08] <ximion> Laney: did I understand the problem correctly in your PR?
[18:14] <ximion> Laney: because if I did understand the problem correctly, this shouldn't be possible to happen...
[18:49] <seb128> ximion, hey, do you know if anyone considered using screenshots from http://screenshots.debian.net/ as fallback for softwares not having one? (or in addition to those)
[18:49] <ximion> seb128: libappstream does that by default, check /etc/appstream.conf
[18:49] <ximion> I thought hughsie implemented something similar in as-glib a while ago...
[18:50] <seb128> ximion, hum, I wonder why that doesn't work then :-/
[18:50] <ximion> seb128: maybe hughsie dropped that from appstream-glib
[18:50] <ximion> the main problem is that we don't know if a screenshot on screenshots.d.o actually exists
[18:51] <ximion> so with libappstream, people will get a filler image in that case
[18:51] <ximion> maybe that wasn't wanted
[18:52] <ximion> implementing support for this in GS or as-glib should be rather simple though
[18:52] <seb128> ah, that might be the case
[18:56] <seb128> ximion, does in work for you in Debian? (asking before looking more)
[18:56] <seb128> inkscape for example should have one
[18:57] <ximion> seb128: no, doesn't work
[18:57] <seb128> k, thanks
[18:57] <ximion> we only have screenshots for stuff with metainfo
[18:57] <ximion> at time
[18:58] <ximion> for weird reasons, sometimes GS also confuses screenshots and shows the wrong screenshots for an app, at least on my machine
[18:58] <ximion> I didn't encounter this with the Git snapshot for a while though, so this might be fixed
[18:59] <seb128> ximion, https://git.gnome.org/browse/gnome-software/commit/?id=ec41a3671850df63dabe04f197f638956af2ddba
[18:59] <seb128> could be that
[19:00] <ximion> yeah, that is likely
[19:00] <ximion> appstream-generator doesn't use hashes for screenshots
[19:01] <ximion> hmm, likely not worth cherry-picking - GS will be released soon together with the rest of GNOME
[19:01] <sarnold> appstream appears to support use of md5 and sha1 hashes; is there a way that libraries that use it can require using e.g. sha256 or better?
[19:05] <mhall119> Laney: http://mhall119.com/2016/03/help-make-gnome-software-beautiful/ better?
[19:08] <ximion> sarnold: huh? AppStream has nothing to do with hashes...
[19:09] <ximion> the only place where they are used is for checksumming metadata on the server, and that is purely for duplicate-detection, and not for security
[19:10] <sarnold> ximion: hmm.
[19:10] <sarnold> ximion: i'm reviewing fwupd at the moment and I _think_ that it's using these hashes for authenticity verification, but I haven't yet found any code that requires reasonable minimums
[19:12] <ximion> sarnold: ah, indeed - I forgot about that, it's mostly hughsie's domain
[19:12] <ximion> anyway, the allowed hashes there are SHA-1 and SHA-256 at time
[19:12] <sarnold> ximion: any chance you can aim me at the code that implements the minimum requirements? :)
[19:14] <ximion> you mean
[19:14] <ximion> https://github.com/ximion/appstream/blob/master/src/as-release.h#L48
[19:14] <ximion> or
[19:14] <ximion> https://github.com/hughsie/appstream-glib/blob/master/libappstream-glib/as-checksum.h#L73
[19:14] <ximion> ?
[19:15]  * ximion isn't sure if he gets the question
[19:16] <seb128> attente, do you know offhand where is the code that build the list of packages that have updates available?
[19:16] <sarnold> interesting, the debian version has md5 still.. http://sources.debian.net/src/appstream-glib/0.5.10-2/libappstream-glib/as-checksum.c/?hl=140#L268
[19:16] <attente> seb128: no, sorry
[19:16] <seb128> attente, no worry
[19:16] <sarnold> ximion: I was just hoping to find a configuration file or a library interface that would allow an appstream consumer to require good hashes, not just any hash
[19:17] <sarnold> ximion: thanks for the links :)
[19:17] <attente> seb128: i guess each plugin has a get_updates function you can start with
[19:17] <ximion> sarnold: that is hughsie violating the spec ;-)
[19:17] <seb128> attente, no such function in gs-plugin-apt.c
[19:18] <sarnold> ximion: ahhhh :)
[19:18] <attente> err. sorry, seb128 try "gs_plugin_add_updates"
[19:18] <ximion> sarnold: we agreen on to not define MD5, because it's insecure - not sure why he added it anyway...
[19:18] <seb128> attente, thanks
[19:19] <ximion> could have been a customer request, or for testing
[19:20] <seb128> attente, bah, that bug is my fault, I did dpkg -i my local build it seems ...
[19:21] <tedg> seb128: That seems fine to me, but I'm not sure who's in charge of it. I would have guessed Trevinho :-)
[19:21] <attente> seb128: :)
[19:30] <Trevinho> desrt: can you change the review to approved in https://code.launchpad.net/~3v1n0/gtk/unity-border-radius-support/+merge/288331 then?
[19:30] <Trevinho> seb128: sorry, I missed your appmenu thing... I can check it
[19:31] <seb128> Trevinho, thanks
[19:31] <Trevinho> seb128: I see ci failures... Let me check
[19:32] <Trevinho> Mh...
[19:32] <Trevinho> indicator-appmenu.c:813:21: error: implicit declaration of function 'bamf_view_peek_children' [-Werror=implicit-function-declaration]
[19:32] <Trevinho>   GList * children = bamf_view_peek_children (BAMF_VIEW (application));
[19:32] <Trevinho> Well it should be defined in bamf headers...
[19:32] <Trevinho> ah, it builds in wily? :o
[19:32] <seb128> Trevinho, dunno, I just wanted the mp approved to I can land
[19:32] <seb128> maybe CI needs to be updated
[19:33] <Trevinho> seb128: I've approved it, do you land it or should I add it to my silo?
[19:33] <Trevinho> seb128: also, first gtk patch is approved, I need to fix the 2nf
[19:33] <Trevinho> d*
[19:38] <seb128> Trevinho, I can look at sponsoring gtk tomorrow
[19:38] <seb128> Trevinho, if you have a silo and wants to add appmenu that would be nice
[19:38] <seb128> but I can do it if you prefer
[19:38] <Trevinho> seb128: I've it ready, so i can do that
[19:39] <seb128> thanks
[19:39] <Trevinho> it will probably land monday or such though
[19:39] <desrt> Trevinho: not really my place to ack
[19:40] <Trevinho> desrt: I mean, since it's need fixing..
[19:40] <desrt> oh.  I didn't realise it works this way
[19:40] <seb128> desrt, thanks for the reviews on the gtk changes from Trevinho
[19:40] <desrt> current status is "needs review"
[19:41] <seb128> yeah, I'm going to change that
[19:41] <desrt> ie: package maintainer should sign off..
[19:41] <seb128> but you can comment approve to say it's +1 from you
[19:41] <desrt> thanks
[19:41] <desrt> it's "I don't see further obvious problems" from me :)
[19:42] <seb128> I saw, thanks
[19:42] <Trevinho> desrt: I finish something then I probably have to ask about the headerbar one
[19:43] <seb128> Trevinho, but I'm on vac starting friday, but L_aney is there next week and can help you landing gtk & co
[19:43] <seb128> well, I can upload what is ready tomorrow
[19:44] <seb128> but then if you have more changes needed
[19:48] <Trevinho> seb128: ok, thanks. I hope to get that acked by tomorrow :P
[19:48] <seb128> :-)
[20:09] <pitti> Laney: btw, I'm on vac tomorrow; could you have an eye on the test minions?
[20:09] <pitti> coming to London tomorrow, over the weekend!
[20:11] <attente> robert_ancell: hey.. so that one patch does depend on the apt plugin since it's the plugin that actually does updates the appstream index
[20:12] <robert_ancell> attente, the "Refresh appstream index if needed" patch?
[20:12] <attente> yeah
[20:13] <attente> i cherry picked it onto the ubuntu-changes branch, but it stopped working
[20:13] <robert_ancell> attente, it stopped working?
[20:13] <robert_ancell> It seems to me it should go into the wip/ubuntu-changes branch
[20:13] <attente> and i figured out that the UI isn't updating properly because we're not updating the state of the GsApps, but i'm not sure how we're supposed to get that information after org.debian.aptd.UpdateCache
[20:14] <attente> robert_ancell: yeah, the patch only works on the apt branch
[20:14] <attente> since it's the apt plugin that's updating the appstream index
[20:15] <attente> via org.debian.apt.UpdateCache
[20:16] <robert_ancell> attente, g-s refreshes the package list after update has been called. So is the bug not that the APT plugin is not blocking for long enough?
[20:18] <attente> no, the bug is that the state of the GsApps in the list aren't being changed from AS_APP_STATE_UNKNOWN to AS_APP_STATE_AVAILABLE
[20:18] <robert_ancell> attente, is this solving the first refresh issue?
[20:18] <robert_ancell> i.e. on startup?
[20:20] <attente> robert_ancell: yes, the bug where we have to apt update after installation to update the appstream index https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1554023
[20:21] <robert_ancell> attente, so this would affect all appstream users wouldn't it?
[20:21] <robert_ancell> I just don't see the direct connection to the apt plugin - this just seems like a general issue
[20:24] <attente> it's just that it depends on the apt plugin to work. i'm having a really hard time trying to understand if this is an upstream bug or not
[20:29] <seb128> Trevinho, sorry about that, but could you take the indicator-appmenu change out of the silo?
[20:31] <seb128> Trevinho, I don't think we are going to manage to drop the other bits this cycle so there is no point to drop that one, it's going to result in less good qt4 integration for no win
[20:39] <seb128> robert_ancell, hey
[20:39] <robert_ancell> seb128, hi
[20:39] <seb128> robert_ancell, the greeter scaling fix looks fine to me, but I could only simulate the session
[20:40] <seb128> Laney said he would test but I guess he was too busy today
[20:40] <robert_ancell> seb128, OK, I'm happy to land it, just really wanted a second opinion
[20:40] <seb128> so feel free to wait another day to get his feedback or to just land it
[20:40] <seb128> great
[20:40] <seb128> I'm glad somebody looked at it, it was bothering me but I had the feeling nobody would have slots for that before release
[20:40] <seb128> I though it would be more difficult
[20:41] <seb128> like having to do with the order in which process exit or something
[20:41] <robert_ancell> Yeah, the other hidpi issues have been more complex, but this one seems fairly straightforward
[20:42] <seb128> robert_ancell, other one, do you have any idea if https://bugs.launchpad.net/bugs/1557752 would be easy to implement?
[20:42] <seb128> unsure where the issue is
[20:42] <robert_ancell> seb128, not sure. I think it should certainly be done in the appstream layer
[20:43] <seb128> ximion said that appstream has it
[20:43] <robert_ancell> I will have a look and see if something broke there - you think it used to work right?
[20:43] <seb128> and he though hughsie had it in -glib
[20:43] <seb128> but that maybe it got removed because they didn't want placeholder images when there is no screenshot or something
[20:44] <seb128> appstreamcli has those
[20:44] <seb128> I tried on inkscape
[20:44] <seb128> so the info is there, maybe -glib doesn't expose it or g-s doesn't use it
[20:45] <robert_ancell> Most of those issues seem to have been having multiple entries, and g-s using the one without screenshots
[20:45] <robert_ancell> But they're not too hard to track down
[20:46] <ximion> seb128: -glib doesn't expose it
[20:46] <ximion> and I think that is because the code has ben removed together with the AppInstall bits we previously had in there
[20:47] <ximion> but I could also imagine GNOME having something against the placeholder images
[20:47] <ximion> (it doesn't look nice ^^)
[20:47] <ximion> on the other hand, I thing there's no GUI app having a placeholder image in Ubuntu
[20:48] <robert_ancell> seb128, ximion, any idea how many packages have the issue? Could we just fix their appstream data to have valid images?
[20:48] <robert_ancell> That would be the nicest solution, rather than hacking in placeholders
[20:48] <seb128> http://screenshots.ubuntu.com/ states " 7718 screenshots online."
[20:48] <ximion> robert_ancell: phew, that's not a bad idea, but the dep11-generator would then need to know whether images are present or not...
[20:49] <robert_ancell> I meant find the packages that don't have screenshots in their appstream data, and add the Ubuntu ones
[20:49] <robert_ancell> (in the upstreams)
[20:50] <seb128> right
[20:50] <ximion> ah, yeah, that would be even better!
[20:50] <seb128> there is only 7718 ones to submit
[20:50] <seb128> you don't sleep at night anyway right? ;-)
[20:50] <ximion> finding that out isn't hard, maybe a few lines of Python to parse the YAML file and find type:desktop-app components w/o Screenshots tag
[20:50] <robert_ancell> seb128, not all of them... this is just finding the top 100 apps right and making sure they look good
[20:50] <seb128> joke aside I don't know how many are useful, and ideally we would fix every single project to have valid data including screenshots
[20:50] <robert_ancell> Ultimately it's the issue of the upstreams to provide this
[20:51] <seb128> but realistically we have other things more important to work on before release
[20:51] <seb128> yeah
[20:51] <seb128> it's just that xenial is this cycle
[20:51] <ximion> yes
[20:51] <seb128> and that project is too new
[20:51] <seb128> we can probably drop the fallback later
[20:51] <robert_ancell> I'm really just trying to gague the scope of the problem (just a few or most apps)
[20:51] <seb128> but it would be useful meanwhile
[20:51] <ximion> oh well, I started libappstream in 2012, and AppStream exists since 2011 - 4 years for upstream projects to provide files ^^
[20:53] <ximion> (well, 2-3 years, to be fair ^^ - metainfo files didn't exist before, and the original idea was to have distros implement the screenshots.d.o API, which OpenSUSE even did :) )
[20:53] <seb128> there is no incensitive to do so when those datas don't reach your users
[20:53] <seb128> I think most upstream didn't/don't care
[20:53] <ximion> true - withough hughsie writing GNOME Software, we'd still have close to zero metainfo files
[20:55] <ximion> btw, I have some time next week that I'll spend on speeding up the appstream-generator rewrite - when that is done, we can do a lot more with the metadata faster
[20:55] <ximion> the dep11-generator has a few hard-to-fix quirks and also is Debian/Ubuntu-only
[20:56] <ximion> if upstreams don't add screenshots fast enough, we could also always inject screenshots.u.o screenshot urls into our metadata for Xenial then ;-)
[20:57] <seb128> thanks
[21:06] <ximion> seb128: I need to talk with Laney about that - too bad he isn't around
[21:06] <seb128> k
[21:30] <robert_ancell> seb128, which is the debian/rules part that is best to copy a binary file for a patch? i.e. it should be done before make
[21:31] <robert_ancell> trying to get the gnome-software packaging into a branch..
[21:32] <seb128> robert_ancell, dh9?
[21:32] <robert_ancell> yes
[21:33] <seb128> override_dh_auto_build:
[21:34] <seb128>     <cmd>
[21:34] <seb128>     dh_auto_build
[21:34] <seb128> should work I guess?
[21:34] <robert_ancell> yeah, that was my guess looking at other packages
[21:34] <robert_ancell> thanks
[21:35] <seb128> yw
[22:02] <robert_ancell> attente, are there any bugs to link the firmware update error change and the appstream refresh change to?
[22:02] <robert_ancell> writing changelog for next release nwo
[22:03] <attente> robert_ancell: an upstream one for the error: https://bugzilla.gnome.org/show_bug.cgi?id=763778
[22:03] <robert_ancell> attente, could you open a LP one and link to that?
[22:04] <attente> still hesitant about the refresh change because i have no idea how to get the UI to refresh properly
[22:04] <attente> well, the index to be refreshed properly internally
[22:10] <attente> robert_ancell: https://bugs.launchpad.net/gnome-software/+bug/1558816
[22:10] <robert_ancell> attente, ta
[22:11] <robert_ancell> attente, and the appstream issue?
[22:11] <attente> robert_ancell: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1554023
[23:03] <Laney> hi ximion
[23:03] <Laney> I'm here for 5 minutes!
[23:03] <Laney> I was like "hmm, should I go on IRC?"
[23:03] <Laney> but my fingers automatically did it for me
[23:07] <Laney> robert_ancell: sorry I forgot, I can do that tomorrow if you want to wait
[23:07] <robert_ancell> Laney, already uploaded :)
[23:07] <Laney> k
[23:07] <robert_ancell> So shout out if it's broken!
[23:15] <ximion> Laney: nice!
[23:16] <ximion> main question: did I understand the bug in your pull-request?
[23:16] <ximion> because I'm not sure I did...
[23:16] <ximion> and you're right, reprocessing is terrible, opening debs multiple times is bad
[23:16] <ximion> ;-)
[23:16] <Laney> The bug is that combined with the optimisation to skip suites if we think nothing changed then you miss if packages migrate between them
[23:17] <Laney> but it fixes itself next time the target suite gets written for another reason
[23:19] <Laney> I'm struggling to think right now what 'another reason' might be
[23:19] <Laney> reprocessing is one, or (mainly for Ubuntu) if a package manages to build and migrate before we see it in the generator
[23:22] <ximion> ah, right, now I get it!
[23:22] <ximion> I forgot that we do that optimization now...
[23:23] <ximion> then we would always need to update the database with new suite information... not sure if that's better than just rewriting the file...
[23:23] <Laney> https://github.com/ximion/appstream-dep11/blob/master/dep11/generator.py#L187 <- that bit
[23:24] <ximion> will think about it - in that light, your patch doesn't look too bad
[23:24] <Laney> ok
[23:24] <ximion> only that we will have to update suite data and store another sub-database in LMDB bothers me a bit...
[23:24] <ximion> ignoring migrating packages is no option either though ^^
[23:25] <ximion> Laney: btw, I am making good progress with the D rewrite of the generator - I will have a lot more time next week to work on it, I think
[23:25] <ximion> that means we can use it earlier
[23:25] <ximion> and it means that the appstream-generator project will be the future
[23:26] <ximion> because for future extension of the project, I don't want to implement the same parser and emitter once in Python and in C
[23:26] <ximion> having it in one place makes maintaining that stuff a lot easier
[23:26] <ximion> (and the new generator is really much faster and more reliable)
[23:27] <Laney> I tried to do it directly, without that, in this commit: https://github.com/iainlane/appstream-dep11/commit/86fa951946c5af63b7273fe78f80cdc7be455907
[23:27] <ximion> this will also allow some neat things in future like instant validation of metadata files
[23:27] <Laney> but that breaks for packages which already exist in the target and I didn't figure out how to fix that
[23:27] <Laney> ximion: nice, if I get time and you make it easy enough I will set up a testing environment with that one
[23:28] <ximion> Laney: that's the annoying part: I'll need to package a few D bits to make this easy for people
[23:28] <ximion> but it's manageable
[23:28] <ximion> but not as nice as deploying a Python software, unfortunately
[23:29] <Laney> it's fine if it's packaged
[23:29] <ximion> Laney: you will need to compile AppStream (C) and appstream-generator (D), which are developed in parallel, which complicates things a little
[23:29] <ximion> if Git versions should be used
[23:29] <Laney> mmm
[23:30] <ximion> I will package that thing, maybe even in time for Xenial (but IÄm not yet 100% sure if that's possible)
[23:30] <Laney> if you can make it so that I don't have to have a local mirror that would be nice ;-)
[23:30] <Laney> or at least abstract the .deb stuff so that someone else could contribute that
[23:30] <ximion> Laney: right now the generator can produce YAMl and XML metadata, merge .esktop files and metainfo files and transform them - missing is the Screenshots and Icons part (the hard stuff ^^)
[23:31] <ximion> Laney: the new generator supports backends: https://github.com/ximion/appstream-generator/blob/master/source/backends/interfaces.d
[23:32] <ximion> implement those two interfaces, and the thing will be usable on any distribution
[23:32] <ximion> well, three with the contentsindex...
[23:32] <ximion> but maybe I can find a way to get rid of the latter
[23:33] <Laney> 'dir' looks suspicious
[23:33] <ximion> (main issue there is that we need to have the contents of all packages before being able to process metadata, so we would need two passes at the packages, which is meh)
[23:33] <Laney> although a remote one could put the mirror there
[23:34] <ximion> Laney: the Packages index must be local - but the "Package" object could download stuff on demand
[23:34] <ximion> as long as getContentsList and getFileData work, the generator won't care
[23:36] <ximion> if it turns out that your requirements are so special that they can't be implemented in the debian backend or in some generic way, one can always create an ubuntu backend, and I won't get in your way then
[23:36] <ximion> (on the Debian AppStream server CPU is the bottleneck, and we have plenty of diskspace)
[23:37] <Laney> you get a nice NFS mounted mirror
[23:37] <Laney> we don't have those :(
[23:38] <ximion> don't you have a datacenter or something?
[23:38] <ximion> I thought providing this would be even easier for Canonical, since I assumed your hardware would be less diverse than Debian's
[23:38] <Laney> yeah but it doesn't provide that facility
[23:39] <Laney> don't ask me why
[23:39] <ximion> ^^
[23:39] <ximion> Laney: btw, the Python bz2 reader doesn't properly read the bz2 files in the Ubuntu and Debian archives
[23:39] <Laney> indeed
[23:40] <ximion> and those contain the long descriptions for packages...
[23:40] <Laney> I looked at this when you implemented it
[23:40] <ximion> this is super dumb, because the bz2 files are valid
[23:40] <Laney> it was crashing originally iirc
[23:40] <ximion> and the new appstream-generator (powered by libarchive) reads them without problems
[23:40] <Laney> should probably file a bug about that...
[23:40] <ximion> it smells like a bug in Python's implementation, but I didn't investigate this more
[23:42] <ximion> Laney: anyway, this description issue is something I feel we should definitely fix before the release
[23:43] <Laney> In [4]: b.readline()
[23:43] <Laney> Out[4]: b'Package: abi-compliance-checker\n'
[23:43] <Laney> maybe I don't remember what the problem is
[23:43] <ximion> if after next week it looks like the new generator could reach feature parity with the dep11-generator quickly, I will ignore the issue in the latter (maybe report a bug against Python anyway, if it's really not me using the API wrong)
[23:43] <ximion> Laney: is it working now?
[23:44] <Laney> no
[23:44] <Laney> but I'm not reproducing it that simply
[23:53] <ximion> :-/
[23:53]  * Laney shrugs
[23:53] <Laney> I can't even get it to work on xenial now
[23:53] <Laney> In [11]: for s in TagFile(bz2.open('/home/laney/temp/Translation-en.bz2', mode='rb')):
[23:53] <Laney>         print (s.get('Package'))
[23:53] <Laney>    ....:
[23:53] <Laney> In [12]:
[23:55] <Laney> meh
[23:55] <Laney> need to sleep now
[23:55] <Laney> night!