[01:33] <jamesh> robert_ancell: https://github.com/snapcore/snapd/pull/7054 <- here's the PackageKit support PR
[01:33] <gitbot> snapcore issue (Pull request) 7054 in snapd "interfaces: add an interface that grants access to the PackageKit service" [Open]
[01:33] <robert_ancell> jamesh, nice!
[01:33] <jamesh> robert_ancell: do you plan on implementing the PackageKit session interface in snap-store?
[01:34] <robert_ancell> jamesh, as opposed to using a library?
[01:34] <jamesh> that is, claiming org.freedesktop.PackageKit on the session bus?
[01:34] <jamesh> From a confinement position, I don't think it matters if it is as a library or from scratch
[01:35] <robert_ancell> jamesh, I hadn't considered that, but I guess probably yes.
[01:36] <jamesh> robert_ancell: I think the standard "dbus" snapd interface is probably best for that rather than trying to cram it into this one
[01:36] <jamesh> since that will eventually allow bus activation
[01:36] <robert_ancell> jamesh, agreed. Since a PK interface user won't specifically need to register that.
[01:37] <jamesh> [once my yak shaving expedition winds to a close]
[05:52] <oSoMoN> good morning desktoppers!
[06:00] <duflu> Morning oSoMoN
[06:02] <oSoMoN> afternoon duflu
[07:14] <didrocks> good morning
[07:17] <oSoMoN> salut didrocks
[07:18] <duflu> Hi didrocks
[07:26] <didrocks> hey oSoMoN, duflu
[08:01] <willcooke> morning all
[08:01] <didrocks> hey willcooke
[08:04] <Laney> hey
[08:06] <seb128> goooood morning desktopers!
[08:07] <didrocks> hey Laney, seb128
[08:07] <duflu> Morning willcooke, Laney and seb128
[08:07] <seb128> hey didrocks, how are you? did you recover a bit from falling yesterday?
[08:07] <seb128> hey duflu
[08:07] <duflu> :-o
[08:07] <didrocks> seb128: a little bit, but it's still hurting
[08:08] <duflu> How are you seb128?
[08:09] <seb128> didrocks, :-(
[08:09] <seb128> duflu, I'm good!
[08:18] <Laney> hey didrocks duflu seb128
[08:18] <seb128> hye Laney, how are you?
[08:19] <oSoMoN> good morning willcooke, Laney, seb128
[08:19] <seb128> lut oSoMoN! ça va comment ?
[08:20] <oSoMoN> ça va bien, merci!
[08:20] <Laney> seb128: yeah good, climbing then folk club last night, was nice - and it's sunny this morning
[08:20] <Laney> moved some of the house plants outside for their summer holiday
[08:20] <Laney> hey oSoMoN
[08:20] <seb128> sounds fun ;-)
[08:20] <Laney> saw your chromium fix, nice one
[08:22] <Trevinho> morning guyzzz
[08:22] <oSoMoN> yeah, not sure why this didn't work without that patch in qemu but it did in e.g. virtualbox, but the patch is fine and I spent too much time investigating the issue already. And it will prevent similar issues with other packages that run selenium/chromedriver tests
[08:22] <oSoMoN> buon giorno Trevinho
[08:23] <Trevinho> bunjourn oSoMoN
[08:23] <duflu> Morning Trevinho
[08:23] <Trevinho> bonjour*
[08:23] <Laney> BUNJUN MARCO
[08:23] <duflu> Murning Marco
[08:23] <Trevinho> bejump
[08:24] <Trevinho> Laney: !
[08:24] <seb128> bonjouno Trevinho!
[08:24] <Trevinho> heya seb128
[08:25] <cpaelzer> oSoMoN: any patch that I need for qemu in the package?
[08:26] <oSoMoN> cpaelzer, nope, I patched chromedriver in the chromium snap, nothing on the qemu side
[08:26] <oSoMoN> (that's bug #1834052 for some context)
[08:27] <cpaelzer> ok, thanks
[08:27] <cpaelzer> just didn't want to miss anything :-)
[08:28]  * Laney patches cpaelzer to run 2.4% more efficiently and 3.93% cooler
[08:35] <cpaelzer> wth, thanks I guess?
[08:36] <Laney> you're welcome!
[09:34] <oSoMoN> jamesh, what's the latest status on https://forum.snapcraft.io/t/firefox-removable-media-interface-auto-connect-request/5929/10 ?
[09:40] <seb128> hum, new bolt has an option to install tests
[09:41] <seb128> I wonder if it's worth installing them in a new binary/making maybe an autopkgtest (though no need to have them installed for that)
[09:41]  * Laney likes doing that
[09:41] <seb128> the tests also use umockdev to emulate things and bolt itself has few rdepends, mostly glib/udev so I'm not sure that would test much
[09:42] <Laney> Simon put them in the -dev package for something recently, until the next soname change that would mean a trip through NEW anyway
[09:42] <Laney> that was ok I thought
[09:42] <seb128> Laney, they are basically the same tests as in the source, you think there is value in having them in a binary rather than unpacking the source?
[09:43] <oSoMoN> jamesh, I see that xdg-desktop-portal is still not installed by default in bionic, is there a plan to change that?
[09:44] <jamesh> oSoMoN: I think we still need to update ubuntu-desktop dependencies, yeah.
[09:44] <seb128> (well they need to be built, but bolt is small so that's not resource expensive to unpack/build/make check)
[09:44] <Laney> yes of course
[09:44] <jamesh> oSoMoN: I'm sorry this has taken so long
[09:44] <Laney> you test the thing that is being built and distributed
[09:44] <seb128> fair point
[09:44] <Laney> rather than additionally testing the toolchain
[09:44] <seb128> Laney, thx for the input
[09:44] <oSoMoN> jamesh, no worries, just trying to figure out what's missing at this point
[09:45] <seb128> let me add that
[09:45] <seb128> and go through NEW :p
[09:45] <Laney> you can put it in the -dev if you want
[09:45] <seb128> (bolt isn't split, I don't want them installed in the main binary)
[09:45] <seb128> I would if bolt had one :)
[09:45] <Laney> https://salsa.debian.org/gnome-team/gnome-desktop/commit/82cab2e95483079f31e14bab865b2631df0595ab
[09:46] <Laney> oh how do you build against it?
[09:46] <seb128> you don't
[09:46] <seb128> bolt is a dbus service
[09:47] <Laney> ok so you use gbdus-codegen or something
[09:47] <seb128> no convenient library/api provided
[09:47] <seb128> right
[09:48] <Laney> -tests package sounds good to me then!
[09:49] <oSoMoN> jamesh, what else do I need to make the document portal work in an existing snap (chromium), apart from installing xdg-desktop-portal{,-gtk} on the host system?
[09:50] <seb128> Laney, thx, useful conversation!
[09:50] <jamesh> oSoMoN: for file open/save, setting GTK_USE_PORTAL=1 in the environment will do (e.g. using the environment stanza in snapcraft.yaml)
[09:51] <oSoMoN> ack
[09:52] <jamesh> it will probably also handle opening mime associations too, provided it doesn't match the .desktop files provided by the base snap
[09:53] <jamesh> for a web browser, the xdg-open.desktop file probably won't cause problems
[09:53] <jamesh> for some reason core18 includes a vim.desktop that might
[09:57] <oSoMoN> jamesh, I'm running the chromium snap in a bionic VM with xdg-desktop-portal-gtk installed, and with GTK_USE_PORTAL=1, but the file open dialog won't let me browse to /media, what am I missing?
[09:58] <oSoMoN> could this be specific to chromium because of the way they instantiate the file open dialog?
[09:59] <jamesh> oSoMoN: I'd forgotten about that: the other half of the problem is that the app must use the GtkFileChooserNative API to present the file chooser
[09:59] <oSoMoN> aha
[10:00] <jamesh> or if it is using Qt, I think there is a QPA plugin that does the right thing
[10:00] <jamesh> I needed to port gedit to the new API to get things working there
[10:00] <jamesh> how difficult the port is depends on what file chooser features are being used
[10:02] <oSoMoN> that's the chromium implementation: https://cs.chromium.org/chromium/src/chrome/browser/ui/libgtkui/select_file_dialog_impl_gtk.cc
[10:03]  * jamesh looks
[10:06] <jamesh> oSoMoN: from a quick look, the main things that aren't portable to GtkFileChooserNative are previews and custom filters
[10:07] <jamesh> Anything that relies on the application controlling an already displayed file chooser is off the table
[10:08] <jamesh> the custom filter could probably be replaced by providing multiple globs for both upper and lower case
[10:09] <jamesh> or even translate to file_extension="jpeg" to "*.[Jj][Pp][Ee][Gg]"
[10:12] <Laney> I think you can still supply previews, but they may or may not be actually rendered and may cause a non-native dialog to be shown instead of the native one
[10:15] <jamesh> I think you're right, yeah
[10:16] <jamesh> looks like the preview widget will be ignored and you'd never see the update-preview signal if portals are being used
[10:16] <jamesh> but in fallback mode it should work like before
[10:19] <oSoMoN> jamesh, Laney: thanks for the analysis, I could probably give a go at porting the implementation to GtkFileChooserNative, not sure whether upstream would accept it though, if it degrades the existing UX
[10:20] <jamesh> oSoMoN: so it sounds like it should be possible to port chromium forward without loss of functionality.  The custom filter => glob pattern change is probably the most complex, but you could probably start with a simple glob
[10:21] <jamesh> oSoMoN: presumably if Chromium is updated, that will percolate through to all the Electron apps eventually too
[10:24] <oSoMoN> that sounds like a good idea then
[10:26] <jamesh> yeah.  This definitely sounds like something that should happen
[10:26] <jamesh> oSoMoN: the only other complication with porting is that GtkFileChooserNative is not a GtkWindow (or even a GtkWidget)
[10:27] <juliank> What would people think if we'd show debconf questions from daemons in modal gnome-shell dialogs rather than these debconf-communicate windows?
[10:27] <jamesh> it subclasses GtkNativeDialog instead, which has its own show/hide/destroy methods
[10:43] <oSoMoN> jamesh, thanks, I filed https://bugs.chromium.org/p/chromium/issues/detail?id=981309 to request comments from upstream before I embark on porting the existing code
[10:57] <jamesh> oSoMoN: cool.  If you do start on the port and have any more questions, I'll help any way I can.
[11:13] <willcooke> does anyone know, off hand, the difference between date_last_updated and date_last_message in the LP API?
[11:13] <willcooke> they can be different
[11:14] <Laney> I would guess the last comment vs any update in the activity log
[11:14] <willcooke> where activity could be someone assigning the bug for example?
[11:15] <Laney> right, if you stick +activity on the end of a bug URL you can see it
[11:15] <willcooke> ah nice one
[11:15] <willcooke> thanks Laney
[11:15] <willcooke> I think last_updated is probably what I need
[11:15] <Laney> is that right?
[11:15] <willcooke> (also: no more dupes in the output)
[11:15] <Laney> win
[11:15] <willcooke> well, I think someone could assign the bug to themselves, but not actually comment on it
[11:16] <Laney> I mean my guess
[11:16] <willcooke> ah right
[11:16] <willcooke> testing...
[11:17] <willcooke> yeah, looks like iot
[11:17] <willcooke> it
[11:17] <Laney> 🥇 for me
[11:18] <willcooke> :)
[11:19] <Laney> fml
[11:19] <willcooke> oh?? what happened?
[11:20] <Laney> different thing
[11:20] <Laney> but thanks for your concern!
[11:20] <Laney> laney@raleigh> dpkg --compare-versions 1.14.5-0~ubuntu18.04.1 '>=' 1.14.5 || echo no                                                                                                                                              ~
[11:20] <Laney> no
[11:20] <Laney> messed up a version number a bit but thought it would be ok
[11:20] <willcooke> heh
[11:20] <Laney> turns out it's bloody not
[11:21] <willcooke> oh, thats odd
[11:21] <Laney> you'd think the first one would be >= the second wouldn't you
[11:21] <jamesh> "~" means before
[11:21] <Laney> yes
[11:21] <Laney> and 0 is basically ignored, that's what the problem is
[11:22] <jamesh> So would 1.14.5 and 1.14.5-0 compare equal?
[11:22] <Laney> laney@raleigh> dpkg --compare-versions 1.14.5 = 1.14.5-0 && echo yes                                                                                                                                                              ~
[11:22] <Laney> yes
[12:38] <willcooke> https://discourse.ubuntu.com/t/testing-the-new-rls-bugs-output/11672
[12:38] <willcooke> desktoppers ^  see what you think
[12:39] <willcooke> sleepy face = > 7 days
[12:39] <willcooke> sunglasses < 7 days
[12:39] <willcooke> since it was updated that is
[12:39] <willcooke> thinking about adding a tally for how many bugs people have?  Also, what about @ing people?  Too invasive?
[12:40] <Laney> +1 for @ing
[12:40] <Laney> I think the idea is to reply each time with a status update, so that would be helpful as a reminder
[12:41] <didrocks> maybe @ing when the bugs goes from sunglasses to sleepy?
[12:41] <Laney> if you're saying that sunglasses don't need reporting on then leave them out completely
[12:42] <Laney> (disagree, if this is being posted on Monday morning then that's 6 days since the meeting)
[12:42] <didrocks> hum, I'm a poller, but some people are pinger-needed
[12:42] <didrocks> puller*
[12:42] <Laney> the script broke the ñ in Treviño
[12:43] <didrocks> outrageous
[12:43] <willcooke> urgh. utf8 time
[12:43] <Trevinho> arggggggggggggggggggggghhhhhhhhhhhhhh
[12:43] <Trevinho> how dareeeee
[12:44] <willcooke> :D
[12:44] <Trevinho> ehhehe :)
[12:44] <Trevinho> I'm not sure in how many sites I found out that I couldn't login with Treviño but I was able with Trevio xD
[12:44] <Laney> does that last activity thing only count activity from the assigned person?
[12:45] <Trevinho> I keep it for making sure utf is always well supported :P
[12:45] <willcooke> Laney, no it just looks at the last update time
[12:45] <Laney> also does it include comments?
[12:45] <willcooke> yeah
[12:45] <Laney> ok
[12:45] <willcooke> adding a comment changes the update time. hmmm.. well I think it does, I will check
[12:46] <Laney> they don't appear in +activity, that's why I'm asking
[12:48] <Laney> but it looks good, nice work
[12:48] <willcooke> thx :)
[12:48] <Laney> if you're posting manually, can they be wiki posts then?
[12:48] <willcooke> I'll look in to that, I /think/ so
[12:48] <Laney> le win
[12:50] <willcooke> bah, no "make wiki" button?!
[12:50] <willcooke> I'll have to read up
[12:50] <Laney> https://meta.discourse.org/t/how-to-create-a-wiki-post/30802
[12:50] <Laney> if you're a moderator
[12:52] <willcooke> yeah, that's the button which is missing
[12:53] <willcooke> yet I have admin powers
[12:53] <Laney> :'(
[13:13] <willcooke> booo...  http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-dd-tracking.json
[13:13] <willcooke> no unicode in there ^
[13:17] <jibel> could anyone with a machine with an nvme drive boot the latest eoan live cd and tell if he sees the corresponding devices in /dev/ ?
[13:19] <seb128> (not me, I don't have a machine with nvme drivers)
[13:19] <seb128> drives
[13:19] <jibel> it's weird I see them with 18.04.2 but not Eoan
[13:21] <jibel> question 2: Could someone do an installation of Eoan on a real machine with UEFI?
[13:21] <jibel> the important part is uefi. In my case it fails to create the esp
[13:22] <willcooke> jibel, sure thing, gimme a little while though
[13:22] <jibel> willcooke, I'm using today's build
[13:23] <willcooke> downloading
[13:23] <willcooke> jibel, I wont be able to do an install (without a lot a faff) so let me see if I can at least see the devices first
[13:24] <jibel> i'll try to reproduce in a vm
[13:24] <jibel> (the uefi issue)
[13:42] <willcooke> Laney, confirming - it _does_ include comments 👍
[13:54] <willcooke> jibel, right, going to test that UEFI thing, brb
[14:46] <willcooke> brb
[16:07] <oSoMoN> marcustomlinson, https://blog.documentfoundation.org/blog/2019/07/04/tdf-announces-libreoffice-625/
[16:08] <marcustomlinson> oSoMoN: building in my ppa at the moment
[16:08] <oSoMoN> ah, I knew you'd be on top of it already :)
[16:08] <marcustomlinson> :)
[17:38] <willcooke> nighty night all
[21:00] <robert_ancell> kenvandine, are you still getting any issues with snap-store?
[21:04] <marcustomlinson> morning robert_ancell :)
[21:04] <robert_ancell> marcustomlinson, hi!
[21:05] <marcustomlinson> robert_ancell: could you trigger this for me? :) https://autopkgtest.ubuntu.com/request.cgi?release=eoan&arch=amd64&package=libreoffice&ppa=marcustomlinson/libreoffice&trigger=libreoffice/1:6.2.5-0ubuntu1
[21:06] <robert_ancell> marcustomlinson, done. I thought I might have to click something but it looks like just following the link did it.
[21:06] <marcustomlinson> yeah looks good thanks!