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