[00:33] <ximion> robert_ancell: still there? You should maybe subscribe to appstream@lists.freedesktop.org - hughsie recently proposed his JSON protocol for ratings & reviews for inclusion into the standard, and I would like to have some feedback from other SC implementors
[00:34] <ximion> technically, you're "just" using GNOME Software, but especially since Ubuntu has it's own Ratings & Reviews, I would welcome feedback on this
[00:35] <ximion> I don't want to favor just one distro or add things to the spec which will only be used by very few people (with the rest using alternative implementations)
[00:59] <robert_ancell> ximion, I will take a look
[01:11] <ximion> reminds me, does Laney know that the AppStream mailinglist exists?
[01:11]  * ximion missed the opportunity to make some noise about it in the AppStream release notes
[01:11] <ximion> anyway, need sleep, gn8
[05:30] <hikiko> hello
[09:04] <Laney> sup
[09:04] <larsu> Laney: tried to drink orange juice, but the straw had a hole
[09:05] <seb128> good morning desktopers!
[09:05] <Laney> plug it with your finger!
[09:05] <seb128> hey larsu Laney
[09:05]  * larsu contends that he has the most interesting story of the morning
[09:05] <larsu> Laney: got a new one ;)
[09:05] <larsu> bonjour seb128!
[09:06] <Laney> hey seb128
[09:06] <Laney> ooh the new paint for the wall ↑ came this morning
[09:06] <Laney> that's an interesting story
[09:07] <Laney> check it out
[09:07] <larsu> hm, true
[09:07] <larsu> maybe we should put it up to a vote
[09:07] <larsu> I wonder if meetingology can conduct votes?
[09:07] <darkxst> Laney, does tha mean you have to paint the wall!
[09:07] <Laney> darkxst: our friend is starting a business doing painting :P
[09:08] <Laney> we are some of the first customers!
[09:08] <darkxst> Laney, so you are the guinea pig :)
[09:10] <larsu> Laney: nice color!
[09:11] <Laney> not as bright in place unfortunately, the wall it's going on doesn't get direct light ;_;
[09:12] <seb128> is that official Ubuntu orange? ;-)
[09:12] <seb128> Laney is a true believer in the brand
[09:12] <alexarnaud> Good morning everyone !
[09:12] <Laney> new official orange or old official orange?
[09:12] <Laney> :@
[09:13] <seb128> depend of your screen and color profile :p
[09:13] <seb128> we have melting snow this morning, I wonder if that's enough of a story to compete with the orange juice and paintain
[09:13] <seb128> ing
[09:14] <larsu> depends. how fast is it melting?
[09:14] <darkxst> seb128, it would melt way faster here ;)
[09:15] <seb128> larsu, now it's turning on "melting before reaching the ground"
[09:16] <seb128> but earlier it was sticking a bit on the ground
[09:16] <seb128> we would need a few °C less :/
[09:16] <larsu> wow... this story is suspenseful! I don't think the paint can compete with that
[09:16] <seb128> :-)
[09:19]  * Laney mutters
[09:19] <Laney> i'll get you next time
[09:19]  * darkxst trained the chickens to train the dogs, not to eat them! how it that for a story ;0
[09:20] <Laney> you...
[09:20] <Laney> can train chickens?
[09:20] <Laney> chickens can eat dogs?
[09:20] <Laney> so many questions
[09:20] <darkxst> apparently and no, dogs eat chickens or ours would!
[09:22] <Trevinho> muktupavels: so... https://code.launchpad.net/~albertsmuktupavels/compiz/gwd-marco-gsettings-v2/+merge/287836 is replacing the old branch from ~ubuntu-mate-dev?
[09:24] <seb128> hey Trevinho, how are your holidays going?
[09:25] <Trevinho> seb128: good, but working today :)
[09:26] <Trevinho> seb128: snow was awesome two days ago... I really enjoyed skiing
[09:27] <seb128> nice
[09:27] <seb128> Trevinho, ok, the "week summary" email said your were off on thursday/friday
[09:28] <Trevinho> seb128: yeah, I changed, since weather isn't great today, so I  prefer to work
[09:28] <seb128> k, makes sense
[09:28] <seb128> it's good that we have flexibility like that ;-)
[09:28] <Trevinho> Yeah... Like a dream :)
[09:28] <Trevinho> Also today there was the meeting with kylin, so I preferred to stay.
[09:32] <seb128> k
[09:32]  * seb128 doesn't know what to do with that GtkPlacesSidebar ABI change in gtk 3.18 and old nautilus
[09:33] <seb128> that's annoying
[09:33]  * seb128 wants snaps to be able to bundle an old gtk :p
[09:34] <darkxst> seb128, you could port the 3.18 sidebar widget to old nautilus, or you just don't like the new one?
[09:34] <seb128> I'm leaning toward copying the widget from gtk 3.16 in nautilus
[09:34] <seb128> but I then need to copy gtkbookmarks&trash as well
[09:35] <seb128> I can't easily do that no
[09:35] <Trevinho> Laney: did you see the upstream changes related to https://bugs.launchpad.net/ubuntu/+source/pkg-config/+bug/1523508 ?
[09:35] <Trevinho> Laney: not sure it's the case to backport the changes...
[09:35] <seb128> the issue is that sidebar changes to be menu based to handle popovers
[09:35] <seb128> but the new api is based on gactions
[09:36] <seb128> converting nautilus 3.14 is too much work
[09:37] <darkxst> and 3.18 nautilus is too unstable?
[09:38] <darkxst> it certainly has its issues, but 3.18.5 seems better
[09:38] <tjaalton> seb128: infinity is out so the xserver is still not copied to xenial.. should I just reupload it all so that they'll get rebuilt in -proposed instead?
[09:38] <Laney> Trevinho: can't we take 0.29.1?
[09:38] <Laney> Trevinho: can you test that commit?
[09:39] <Trevinho> Laney: we could take 0.29.1 yes...
[09:39] <Trevinho> Laney: as for compiz side, we handle both cases now, so... It just doesn't matter
[09:39] <Laney> still would be good to know if it fixes the original problem
[09:39] <Trevinho> but, to  avoid other unknown breakages around, I'd go with the old-fashioned way of handling vars
[09:40] <Trevinho> Laney: ok, yes
[09:40] <Trevinho> I can do that
[09:40] <seb128> darkxst, we had it and reverted, the zoom levels limitation and some other things make it risky user reception for the lts
[09:41] <seb128> tjaalton, hey, sorry I didn't follow ... what's the issue? are you blocked on copy and by what?
[09:41] <darkxst> seb128, yes I am aware it was reverted
[09:41] <Trevinho> Laney: however it seems quite likely, since it's a revert...
[09:42] <darkxst> seb128, zoom levels don't seem hard to fix, but what else is causing problems?
[09:42] <tjaalton> seb128: the xserver transition, I've been waiting for someone to copy the binaries but infinity is out
[09:42] <seb128> tjaalton, you don't have upload rights for it?
[09:42] <tjaalton> I do, but before they've been just copied from the staging ppa
[09:43] <seb128> well if you can upload you can copy
[09:43] <tjaalton> how?
[09:43] <seb128> I don't understand why you need somebody
[09:43] <seb128> using copy-package
[09:43] <tjaalton> never knew that
[09:43] <Laney> Trevinho: sounds like a revert + looking for quotes, so should be safe but still good to confirm - thanks!
[09:44] <Laney> nice that he fixed it
[09:44] <tjaalton> ok I have the archive-tools handy.. will give it a go then :)
[09:44] <seb128> great, let me know if you need help
[09:45] <seb128> tjaalton, should be something around the line of
[09:45] <seb128> ./copy-package --ppa=canonical-x --ppa-name=x-staging -s xenial --to-primary --to-suite xenial-proposed <name>
[09:48] <tjaalton> yep, seems to work
[09:49] <seb128> darkxst, there is a summary of the reasons in
[09:49] <seb128> https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1541954
[09:49] <seb128> tjaalton, sorry, I though that you know that whoever can upload can also copy
[09:49] <seb128> knew
[09:49] <seb128> I didn't really understand why you were holding, I would have told you earlier :-/
[09:51] <tjaalton> heh, no worries
[09:51] <tjaalton> realized that mlankhorst couldn't copy, not all of these anyway
[09:52] <tjaalton> Candidate copy target: https://api.launchpad.net/devel/ubuntu/+archive/primary
[09:52] <tjaalton> looks right?
[09:53] <seb128> where do you see that?
[09:53] <darkxst> seb128, its a balancing act, carlos has been pretty good backporting fixes to the 3.18 branch
[09:53] <seb128> I'm unsure to understand the question
[09:53] <tjaalton> Copy candidates: xorg-server 2:1.18.1-1ubuntu3 in xenial
[09:53] <tjaalton> Candidate copy target: https://api.launchpad.net/devel/ubuntu/+archive/primary
[09:54] <darkxst> but some things like zoom arent consider a problem upstream
[09:54] <muktupavels> Trevinho, only if you are ok with removing tests. why they are not enabled when building debian packages?
[09:55] <Laney> darkxst: did you see https://csorianognome.wordpress.com/2016/02/24/nautilus-3-20-last-change-zooms/ ?
[09:55] <darkxst> seb128, why is it so hard to add the menu bar back?
[09:55] <seb128> darkxst, they are, it's being worked on on e.g https://git.gnome.org/browse/nautilus/log/?h=wip/cosimoc/zoom-levels-v2 and csoriano said he's probably going to need to distro patch something there for the next RHEL update as well
[09:56] <darkxst> no I hadnt seen that
[09:57] <seb128> tjaalton, looks fine to me, I didn't use it for a while but if you did "--to-primary --to-suite xenial-proposed" it should be right
[09:57] <Laney> most people can't upload to the release pocket directly anyway
[09:57] <Laney> so it'll fail
[09:58] <seb128> Laney, but tjaalton can uploaded xorg so it should work no?
[09:58] <darkxst> but why wouldnt you cherry-pick improvement rather than revert
[09:58] <Laney> seb128: yeah I mean the maximum harm of getting it wrong isn't very high
[09:58] <seb128> darkxst, because at the time we reverted the improvements were still not done and judged difficult to do
[09:58] <seb128> Laney, right
[09:58] <Laney> unless you're in the release team in which case it gets accepted into xenial-release
[09:58] <seb128> darkxst, also that is one of the points
[09:58] <Laney> and then you get killed
[09:59] <seb128> haha
[10:00] <tjaalton> ok, all copied
[10:01] <tjaalton> oh hell
[10:01] <seb128> tjaalton, ?
[10:01] <tjaalton> guess I get to do a bunch of rebuilds
[10:02] <tjaalton> I thought this would copy the binaries too
[10:02] <seb128> arg
[10:02] <seb128> sorry my fault, you need "-b" for that :-/
[10:02] <tjaalton> yeah missed that from the help
[10:03] <darkxst> seb128, I dont rrally have time for what if's, but I do have maybe a week before I am back at full-time work
[10:07] <darkxst> but still I have largely no  idea whats needs to be done...
[10:08] <darkxst> and yes apparently I can't type while watching TV
[10:48] <willcooke> since I'm not doing a very good job of being off sick I might as well log in
[10:50] <tjaalton> seb128: is there a way to artificially keep a package in proposed?
[10:57] <tjaalton> hmm I guess xserver will remain there until rdeps have been rebuilt
[10:58] <tjaalton> which is good
[11:01] <Laney> hey willcooke
[11:01] <willcooke> ello
[11:01] <Laney> are you contagious?
[11:02] <willcooke> I think so
[11:02] <willcooke> I've put a face mask over my ethernet port
[11:02]  * Laney backs off
[11:02] <davmor2> willcooke: confirmed you modem bug
[11:02] <willcooke> thx davmor2
[11:02] <willcooke> spoke to cyphermox last night, he's going to see what he can do for NM upgrade
[11:03] <willcooke> davmor2, if you manually run usb_modeswitch does it "fix" it?
[11:03] <davmor2> willcooke: will try that now
[11:05] <davmor2> meh that'll be why I have modemmanger removed to be able to flash phones D'oh let me do a fresh install on some hardware and reconfirm
[11:05] <willcooke> ah ha
[11:06] <davmor2> willcooke: infact I can run it from a live session that will be quicker still
[11:12] <davmor2> willcooke: so for me in live session I get Mobile Broadband not enabled
[11:13] <willcooke> dont follow you
[11:13] <willcooke> is that good or bad?
[11:13] <davmor2> willcooke: so it looks like the switch is happening but not connection is made
[11:14] <willcooke> davmor2, oh.  But it detects the modem ok?
[11:15] <davmor2> willcooke: well debatable I'll wait for awe and cyphermox to get online and have a debug session from live session then hopefully we can whittle it down a bit for them
[11:15] <willcooke> davmor2, nice one, cheers matey
[11:27] <davmor2> willcooke: bugger looks like it is biting us in 14.04.4 too
[11:27] <willcooke> davmor2, erk
[11:28] <davmor2> willcooke: there though I get no connection at all so is likely to be the usb mode switch
[11:29]  * davmor2 is so glad to have all this spare hardware just lying around honest
[11:30] <davmor2> oh and it's a contract sim so not like it is out of credit either and if I test it in my mifi device is just connects so definitely and issue.
[11:31] <willcooke> davmor2, in fairness, I dont have a SIM in mine, but the HW should still show up (and indeed does when I run usb_modeswitch manually)
[11:31] <desrt> word up
[11:31] <willcooke> hihi desrt
[11:38] <desrt> morning, willcooke
[11:41] <andyrock> "motning"
[11:41] <andyrock> *morning
[11:42] <andyrock> willcooke: not sure what to do abouth this card: https://trello.com/c/GiWywEtG/1-work-out-what-to-do-about-desktop-files
[11:42] <andyrock> marco's was handling the bamf/unity part
[11:42] <andyrock> *marco was
[11:42]  * andyrock is still sleeping
[11:42] <andyrock> :D
[13:20] <GunnarHj> pitti: Do you have time to look at bug #1510198 (FFe)? There are still a few pending details, but it would be good to have a decision regards the FFe before spending more time on it.
[13:21] <Sweet5hark1> Laney: thanks for the update on the seed. two things though ...
[13:23] <Sweet5hark1> Laney: 1/ libreoffice-style-human and libreoffice-style-breeze are now _both_ on the image, I dunno why -human is still around. at least in the ubuntu-meta_1349.tar.xz, there is no reference to it.
[13:24] <Sweet5hark1> Laney: 2/ the dir in the ubuntu-meta tarball is named ...-1.350 which seems to be off for a 1.349 release
[13:25] <Sweet5hark1> ahh, the answer to 1/ is simple 5.1.1~rc2 is still in -proposed and 5.1.0-0ubuntu1 still deps somehow on -human, I guess.
[13:25]  * Sweet5hark1 checks
[13:26] <Laney> Also the migration happened after today's image
[13:26] <Laney> 2> dpkg-source doesn't care about the first component
[13:27] <Laney> I ran ./update twice and it renamed the directory the second time
[13:27] <Laney> then I manually changed it back
[13:27] <Laney> but that didn't rename it back :-o
[13:27] <Laney> use dget :-)
[13:28] <Sweet5hark1> Laney: I just looked into it on launchpad, so np, just noticed it to be odd.
[13:30] <Laney> nod, good observation!
[13:30] <Sweet5hark1> hmmm, libreoffice-gtk 5.1.0 already recommends -breeze. so I wonder what pulls in -human still.
[13:30] <Laney> the old seed
[13:30] <Sweet5hark1> Laney: ah, doh.
[13:31] <Laney> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-touch.xenial/rdepends/libreoffice/libreoffice-style-human
[13:31] <Laney> and we got breeze like this http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-touch.xenial/rdepends/libreoffice/libreoffice-style-breeze
[13:31] <Laney> s/-touch//
[13:32] <Laney> doesn't matter in that case :P
[13:57] <willcooke> thanks cyphermox :)
[13:57] <cyphermox> good morning
[13:58] <Sweet5hark1> aannd yet another more releasish libreoffice-snap build ... failing after 50 minutes on big bertha ...
[13:59] <willcooke> Sweet5hark1, https://www.youtube.com/watch?v=coZfzTcv4bA
[14:01] <Sweet5hark1> willcooke: oh thats a lot more cute than the stuff that resulted in that machine having the name bertha (https://en.wikipedia.org/wiki/Big_Bertha_%28howitzer%29)
[14:01] <willcooke> :D
[14:44] <mhall119> Laney: so I've been able to generate: https://wiki.ubuntu.com/mhall119/AppStreamTest
[14:44] <mhall119> it's a big list, but ranked by popcon installs
[14:46]  * mhall119 is surprised by how many xpm's are still in use
[15:10] <pitti> GunnarHj, Sweet5hark1: from an FF point of view, bug 1510198 seems fine to me
[15:12] <Sweet5hark1> pitti: oh, yeah, that one. Im in a call right now, will look afterwards. IIRC it wasnt hugely problematic when I last looked.
[15:13] <GunnarHj> pitti: Thanks! Can you please make a note about it on the bug report.
[15:15] <GunnarHj> Sweet5hark1: Great if you don't have any big doubts. There are still some pending details to deal with. I'm about to upload a new set of proposals to a PPA.
[15:18] <pitti> GunnarHj: I did already
[15:18] <GunnarHj> pitti: Have seen it now. Thanks again!
[15:39] <Laney> mhall119: cool!
[15:40] <Laney> how are you planning to run this?
[15:46] <mhall119> Laney: I will write a blog post detailing the need and the steps to contribute an icon (including working with upstream), then point to a wiki page with that list for people to choose from
[15:46] <mhall119> Laney: how often does the AppStream data on http://appstream.ubuntu.com/hints/xenial/main/ get updated?
[15:46] <Laney> hourly
[15:46] <mhall119> oh, wow
[15:47] <mhall119> well, I might re-generate the list on a daily basis for a while
[15:47] <mhall119> or just have people manually update it when they submit
[15:47] <Laney> you might want a link to search for already filed bugs
[15:47] <cyphermox> willcooke: I got NM to build (minus a lot of patches), so I'll get back to it in a few hours, see if I can quickly get nm-applet together
[15:47] <mhall119> Launchpad should do that for us
[15:48] <Laney> mmm
[15:48] <mhall119> Laney: since I'm pre-populating the bug title with the "Submit" link, it will match if somebody clicks it a second time
[15:48] <mhall119> that won't stop someone from creating a duplicate, but it should at least warn them
[15:48] <Laney> ok, then people should be told to file a bug when they start work
[15:49] <mhall119> sounds reasonable
[15:49] <mhall119> I can add a "claim" column to the page where people can also indicate that they've started on one
[15:50] <Laney> that or the bug assignee, don't know what is easier
[15:50]  * Laney had already started to finish banshee, better delete that
[15:50] <Laney> oh, wiki is 500ing, cool
[15:50] <willcooke> cyphermox, thanks!!
[15:50] <mhall119> yeah, keep trying, it 500's about half the time
[15:52] <Laney> meh
[15:52] <Laney> it means I can't log in
[15:59] <flocculant> Laney: re g-s, is it expected for it to leave packages behind that need apt-get autoremove ?
[16:02] <Laney> flocculant: I don't know, I'm not really working on the client side
[16:02] <Laney> what does software-center do?
[16:02] <flocculant> leaves configs
[16:03] <flocculant> Laney: best to talk to robert ancell later?
[16:03] <Laney> flocculant: yeah or report a bug
[16:04] <flocculant> Laney: I'll talk to him - don't want to report something not a bug ...
[16:04] <flocculant> if it is then I will :)
[16:05] <Laney> it's easy to close them
[16:07] <flocculant> I guess
[16:07] <Laney> well, up to you, either works
[16:07] <flocculant> :)
[16:11] <seb128> flocculant, g-s is not a system upgrader, why would it clean up things?
[16:12] <Laney> when removing
[16:14] <flocculant> seb128: it installed something - I'd expect it to clean up after itself :)
[16:14] <seb128> it's a complex problem
[16:15] <seb128> you install firefox which brings gtk2
[16:15] <seb128> then you install inkscape
[16:15] <seb128> then you remove firefox
[16:15] <Laney> apt wouldn't mark it as autoremovable then
[16:15] <seb128> gtk2 is not linked to firefox which installed it anymore
[16:15] <Laney> if you had some local gtk2 program though
[16:16] <seb128> right, I'm just saying that autoremove is different from "that comes from that program"
[16:16] <seb128> imho those cleanup jobs are still better handled by the upgrader component
[16:16] <seb128> g-s only knows about desktop components
[16:17] <flocculant> seb128: so not a bug as such?
[16:17] <seb128> well I guess it's valid to discuss
[16:17] <Laney> I think it's debatable
[16:18] <Laney> if one component is doing it then it cannot be more harmful for another one to also
[16:18] <flocculant> seb128 Laney - ok I'll report it then
[16:18] <seb128> thanks
[16:18] <Laney> but not really up to me :)
[16:18] <seb128> do we know how other distros/upstream g-s handle that?
[16:19] <seb128> also you said that software-center was "leaving configs"
[16:19] <seb128> but does it autoremove?
[16:19] <flocculant> seb128: yea - or did with the experiment I did
[16:21] <flocculant> I'll add as much info as I can to bug anyway
[16:21] <seb128> thanks
[16:24]  * flocculant makes alias for ubuntu-bug gnome-software ... 
[16:27] <seb128> lol
[16:32] <flocculant> bug 1552792 for better or worse :)
[16:50] <Sweet5hark1> snappy build still running, now at ~9GB ...
[16:53] <pitti> Sweet5hark1: erk
[16:53] <pitti> that's 7 times bigger than an entire ubuntu desktop iso which *contains* LibO
[16:53] <ogra_> whats 9GB compared to the size of the universe though
[16:54] <flocculant> 1/5?
[16:54] <pitti> ogra_: wait until his build finishes :)
[16:54]  * ogra_ is happy that we aim for embedded devices with snappy now ... 
[16:54] <Sweet5hark1> pitti: nono no panic, thats the size of the workdir, not the final snap. this is expected to be bigger than the snap will be in the end.
[16:54] <ogra_> the ones with a 5TB disk :P
[16:55] <pitti> ogra_: you don't have a 16TB SD card in your raspi yet?
[16:55] <ogra_> pitti, waiting for mediamarkt to seel them for 9,90
[16:55]  * Sweet5hark1 uses df -h as a progress bar :/
[16:55] <ogra_> *sell
[16:55]  * pitti ^5s ogra_
[16:55] <ogra_> :D
[16:55] <pitti> Sweet5hark1: hah, nice; what's 100%?
[16:56] <pitti> lBuild Architecture: amd64
[16:56] <pitti> Build-Space: 13169060
[16:56] <pitti> Build-Time: 22424
[16:56] <pitti> Distribution: xenial-proposed
[16:56] <pitti> I wonder what unit that is
[16:57] <pitti> I suppose kB or KiB, as it's certainly not B :)
[16:57] <pitti> 13 GB sounds plausible
[16:57] <pitti> man, you and your universe-heating packages :)
[16:57] <Sweet5hark1> yep. but that is without l10n, I assume?
[16:58] <pitti> yeah, I just looked at libo amd64 xenial's build log
[16:58] <Sweet5hark1> pitti: lets just say I am generous with distributing entrophy ....
[16:59] <Sweet5hark1> -h
[17:02] <Sweet5hark1> meh -- build looks odd though: 100% make, no childs and no output :/
[17:10] <attente> seb128: it's ok to install debs in GS using aptdaemon, right?
[17:11] <seb128> attente, yes
[17:11] <seb128> isn't that what we use as a backend atm?
[17:11] <attente> seb128: i wasn't sure because i didn't see aptdaemon in the GS depends
[17:14] <attente> seb128: it doesn't look like it from what i can tell
[17:14] <seb128> attente, it should probably be a depends, debian/patches/apt-plugin.patch uses it
[17:15] <seb128> aptd_transaction()
[17:15] <seb128> +	result = g_dbus_connection_call_sync (conn,
[17:15] <seb128> +					      "org.debian.apt",
[17:15] <seb128> +					      "/org/debian/apt",
[17:15] <attente> hrm... interesting. i'm not sure which branch that comes from
[17:15] <seb128> https://git.gnome.org/browse/gnome-software/log/?h=wip/rancell/apt
[17:15] <seb128> I would say
[17:15] <attente> ah. ok. i didn't see that
[17:15] <attente> thanks
[17:15] <seb128> yw
[18:05] <flocculant> seb128: sorry - got waylaid - gs/synaptic screeny added now
[18:08] <seb128> flocculant, thanks
[18:31]  * Laney woofs goodnight
[18:33] <seb128> woot, new gst landing
[18:33] <seb128> Laney, enjoy your evening!
[18:33] <Laney> stir fry night
[18:33] <Laney> gimme a helllllllllll yeah
[18:33] <Laney> you too! bye!
[18:39] <seb128> stir fry, yummy! :-)
[18:39]  * seb128 goes for dinner as well
[18:51] <flocculant> seb128: added a new screeny after starting a vm and installing the same package in synaptic and gnome software at the same time
[18:51] <seb128> flocculant, thanks
[18:52] <flocculant> seb128: sorry if I'm getting boring about this stuff - but I'm trying to test it to distraction for xubuntu ;)
[18:52] <seb128> flocculant, no, don't worry, it's useful feedback, please keep playing with it and reporting issues!
[18:53] <flocculant> :)
[18:53] <flocculant> I shall ofc
[19:29] <ximion> Laney: when working on the new data generator, I realized that some parts of the current one are a bit more complex than they need to be...
[19:29] <ximion> unfortunately the icon finder can't be simplified further :(
[19:29]  * ximion will fetch food, then review all outstanding PRs
[20:44] <robert_ancell> attente, I've removed all the non-review related changes in wip/rancell/reviews and put them in wip/ubuntu-changes
[20:45] <attente> robert_ancell: ok, thanks. sorry i wasn't sure if you wanted me to force push those removals or not...
[20:45] <robert_ancell> git revert it fine
[20:47] <attente> robert_ancell: i'm trying to get the deb sideloading to work, but for whatever reason GS refreshes to an empty page after installation
[20:47] <robert_ancell> attente, we don't currently reload the apt/dpkg information - could that be the issue?
[20:47] <attente> wondering if you have any ideas why it might be doing that...
[20:49] <attente> robert_ancell: it could be, there might be some disparity between the gsapp we generate for the deb and what's added to the db
[20:50] <seb128> robert_ancell, hey
[20:50] <robert_ancell> seb128, hello
[20:51] <seb128> robert_ancell, attente, should we make g-s refresh its index on start?
[20:51] <robert_ancell> seb128, it loads the index on start, but it never reloads it. I was going to add a file watch on the files and reload when they change
[20:51] <attente> seb128: i guess we have to refresh the index after the deb is installed
[20:52] <robert_ancell> G-S asks for new information after an install. I originally had it loading the index every time, but that seems inefficient
[20:52] <seb128> robert_ancell, does it? it doesn't indicate it's doing so and it's not obvious...
[20:53] <robert_ancell> seb128, after you install an app, G-S asks for the list of installed apps
[20:53] <seb128> g-s seems to lack feedback on when it's doing things/waiting
[20:53] <seb128> same if the apt lock is taken by another process
[20:54] <seb128> it acts like if it was doing work
[20:54] <robert_ancell> seb128, there is an issue with the theming where the loading bar is not shown
[20:56] <seb128> yeah, I saw that one. but even if the bar was loading, if something else is having a lock on apt you can wait for ever
[20:56] <robert_ancell> seb128, yes, but there's nothing we can really do about that...
[20:56] <robert_ancell> That's just apt being a bit shitty
[20:58] <seb128> software-center/update-manager handle that better, they tell you they are waiting because something has a lock on the db
[20:59] <seb128> so it's doable
[20:59] <seb128> but it might be hackish, no idea
[20:59] <attente> how does s-c detect the lock?
[20:59] <robert_ancell> attente, aptd gives status information, it's probably in there
[21:00] <robert_ancell> seb128, file a bug for a label as to why it's waiting!
[21:00] <attente> via the dbus interface?
[21:00] <robert_ancell> attente, yeah
[21:00] <seb128> I should do that ;-)
[21:00] <robert_ancell> attente, see transaction_property_changed
[21:00] <robert_ancell> attente, see transaction_property_changed_cb rather
[21:01] <robert_ancell> attente, your new gs_plugin_filename_to_app doesn't check if the number of tokens from the strsplit is what you expect...
[21:02] <robert_ancell> and your g_spawn_sync can return FALSE but doesn't set error...
[21:03] <attente> robert_ancell: yeah, i got a bit sidetracked with getting the app page to refresh properly..
[21:03] <attente> thanks for catching those
[21:05] <robert_ancell> desrt, has anyone ever proposed a g_strv_new, i.e. gchar **argv = g_strv_new ("foo", "--bar", "3", NULL);
[21:06] <robert_ancell> I feel like I'm writing that sort of code all the time
[21:06] <desrt> a common trick is to use split
[21:06] <robert_ancell> desrt, yeah, but that doesn't work well if the contents are variables
[21:07] <desrt> indeed
[21:07] <robert_ancell> ie..  gchar **argv = g_strv_new ("foo", "--bar", some_user_value, NULL)
[21:07] <desrt> why aren't you using gsubprocess?  :)
[21:07] <robert_ancell> desrt, is it worth proposing or is it the dreaded glib feature creep?
[21:07] <robert_ancell> I'm super glad g_strv_contains exists now
[21:08] <robert_ancell> Was sick of writing that over and over...
[21:08] <desrt> ya.. me too
[21:08] <seb128> robert_ancell, is bug #1552074 one of the issues you fixed? the git commit have no bug reference/bt so not easy to say
[21:08] <robert_ancell> seb128, I'm looking at that now, not fixed AFAIK
[21:08] <seb128> k
[21:08] <desrt> seriously, though
[21:08] <desrt> GSubprocess?
[21:09] <robert_ancell> desrt, sure, in that case, but there are others.
[21:09] <robert_ancell> People end up using GPtrArray instead, which is a bit heavy
[21:10] <desrt> or strv = g_new(char*, 4); strv[0] = ...; etc.
[21:10] <desrt> which is kinda reasonable imho
[21:10] <robert_ancell> yes
[21:10] <desrt> but g_strv_new() is also kinda reasonable
[21:10] <robert_ancell> well, I'd say it's leess than ideal
[21:10] <desrt> i'd be happy to review a patch
[21:10] <robert_ancell> ok
[21:10] <desrt> but it's too late for this cycle
[21:10] <robert_ancell> that's fine
[21:11] <robert_ancell> it's not urgent, but it makes GLib easier to use
[21:11] <desrt> imho it's not really great for this case
[21:11] <desrt> since it will necessarily dup the input strings
[21:11] <desrt> but meh
[21:11] <desrt> hint: try to copy the valist to avoid doing multiple allocations
[21:11] <desrt> ie: va_copy
[21:13] <desrt> i guess you could do some speculation and alloca() as well
[21:13] <seb128> robert_ancell, https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1552918 seems to be something quite some users hit
[21:13] <desrt> but in terms of how it will end up looking in assembly, the copy is definitely cleanest
[21:15] <desrt> (and just to avoid roundtrips, don't forget): docs section addition, sentinal attribute
[21:15] <desrt> you'll probably also get tripped up on the missing version macros.  feel free to submit a patch to add those =)
[21:16] <robert_ancell> desrt, missing version macros?
[21:16] <robert_ancell> i.e. defines for the latest version?
[21:17] <desrt> yes
[21:17] <desrt> since you're writing the patch against the not-yet-existent series-to-come...
[21:22] <attente> is that the LIM/headerbar bug?
[21:35] <ximion> seb128: btw, I found out why PK was percieved as slow: When it was tested initially, Ubuntu didn't have AppStream metadata, and in that case GS emits FindFiles() calls to PK, which cause a search for which pkg provides a specific filename - and those searches are super slow, even when using APT directly.
[21:36] <ximion> with AppStream metadata present, GS has all the package information and only rarely needs to resolve a filename to a package. For packages, it will only emit a Resolve() call, and resolve calls are really cheap
[21:39] <seb128> ximion, hey, k, so maybe that's a non issue then
[21:39] <ximion> seb128: I ran into this myself yesterday on a Debian machine which had broken metadata
[21:39] <ximion> was an enlightening experience on that matter
[21:44] <seb128> ximion, what's the status of the appstream-glib issue/screenshots? seems like the bug is without activity since december :-/
[21:44] <ximion> seb128: hughsie won't implement it, so someone else would need to do it
[21:45] <seb128> what's the difference which makes it work on fedora?
[21:45] <ximion> I wanted to quickly submit a match, but making this work requires passing around the media_baseurl parameter down to the parsing functions, which is a more invasive change
[21:45] <ximion> so I wanted to have hughsie take a look at it first
[21:46] <ximion> seb128: fedora is using the XML data, which doesn't know MediaBaseUrl and just duplicated the full url for every screenshot
[21:47] <ximion> libappstream implements the DEP-11 spec correctly, so the only SC which is currently affected by this bug is GNOME Software (and potentially other stuff using libappstream-glib, but the only bug report I got was from GS so far)
[21:49] <ximion> seb128: btw, technically implementing MediaBaseUrl isn't hard
[21:49] <ximion> the "Origin" field in AppStream metadata works the same way
[21:50] <seb128> I don't understand those details enough to get a clear idea of what's going on exactly
[21:50] <seb128> but we need to get that fixed this cycle one way or another
[21:50] <seb128> what do you recommend doing?
[21:51] <seb128> is that something robert_ancell_ or attente or Laney are looking at?
[21:51] <robert_ancell_> seb128, I'm aware of it, was hoping Laney was looking at it
[21:51] <ximion> seb128: definitely fix appstream-glib to follow the spec ;-)
[21:52] <seb128> that works if something is assigned/going to do it
[21:52] <robert_ancell_> ximion, is there a bug with the information? We can carry a patch in Ubuntu if necessary
[21:52] <seb128> which doesn't seem the case atm
[21:52] <ximion> theoretically we could make the generator thow out some different version of the data, but that would have some annoying issues on the server side, e.g. we couldn't easily change the url of the screenshots and icons anymore
[21:52] <seb128> could we just do whatever fedora is doing?
[21:52]  * ximion doesn't like that
[21:53] <ximion> robert_ancell_: no, the data is fine - just https://github.com/hughsie/appstream-glib/issues/70 needs to be fixed
[21:54] <robert_ancell_> ximion, ok, so it just needs someone to write the patch and convince hugshie this is the right thing to do?
[21:55] <ximion> spec here: https://www.freedesktop.org/software/appstream/docs/sect-AppStream-DEP11.html#spec-dep11-general
[21:55] <ximion> robert_ancell_: jup - while convincing hughsie would not be hard :)
[21:55] <ximion> (I hope ^^)
[21:55] <robert_ancell_> ximion, oh regarding reviews in appstream. That doesn't make sense to me either - they seem too dynamic to be mixed in..
[21:55] <robert_ancell_> And there could be many thousands of reviews
[21:56] <ximion> robert_ancell_: jup, I don't want that - but specifying the protocol to get them in AppStream is something I would like
[21:56] <ximion> jup, I am not sure if I misunderstood hughsie there
[21:56] <robert_ancell_> ximion, that makes sense I guess
[21:57] <ximion> we already have services in the spec: https://www.freedesktop.org/software/appstream/docs/chap-AppStream-Services.html
[21:57] <ximion> because before hughsie introduced metainfo / appdata files, it was thought that every distro would simply implement the Debian screenshot server API
[21:57] <ximion> and OpenSUSE even did that :)
[21:58] <ximion> now, the screenshot service is only a fallback
[22:00] <ximion> robert_ancell_: on the generator side, having MediaBaseUrl allows us to store the pre-generated metadata in a database and easily change the location of the screenshots server without regenerating all metadata or parsing all YAML and string-replacing the old url with the new one when altering it
[22:01] <robert_ancell_> yeah, that makes sense if you want to mirror it I guess?
[22:01] <ximion> also, this could later be used by distributions to have multiple mirrors for screenshots, or add a mirror pattern
[22:02] <ximion> some people expressed interest in this, because not everyone has a powerful server or redirect service running for this
[22:02] <ximion> jup, exactly
[22:03] <robert_ancell_> desrt, could you have a quick look at https://errors.ubuntu.com/problem/23ba6db9a4c30881ade44cef107a6dd5d76a41ef. Essentially, inside GApplication a GTK settings callback is trying to access app_menu_section, which is NULL even though it shoul be defined for the lifetime of the application.
[22:04] <robert_ancell_> Was wondering if perhaps the callback has been called after dispose() somehow
[22:04] <robert_ancell_> GtkApplication rather
[22:11] <desrt> sounds likely
[22:22] <desrt> robert_ancell_: the app_menu_section here is an attribute of the window itself -- not the app
[22:23] <desrt> it is created in _init() of the window and freed in dispose
[22:23] <robert_ancell_> aha
[22:23] <desrt> so this looks like someone is trying to realize a window after it has already been disposed
[22:24] <desrt> via gtk_widget_show
[22:25] <desrt> bug is in whatever defines gs_application_activate() i'd say
[22:26] <desrt> i'm guessing it holds a ref on the window so that it can show it again, but it doesn't prevent the window from being destroyed on delete