[02:27] robert_ancell: are there any plans to backport newer versions of snapd-glib to xenial? [02:28] jamesh, I haven't bothered since gnome-software doesn't use it. It would be a pain to get through the SRU process. [02:28] Is there something that needs it? [02:29] robert_ancell: I was working on a backport of the pulseaudio snap policy module, and ran into problems with me missing a snapd_client_connect_sync() call [02:29] robert_ancell: my first thought was to just add that call and treat that as the end of it, but then I was wondering what happens if snapd is restarted during the user session? [02:30] jamesh, certainly it would be better to go straight to 1.43 - want to do the paperwork? [02:30] it looks like the automatic reconnect behaviour came with the deprecation of connect() [02:30] yeah [02:30] it did [02:31] robert_ancell: I'll check with Ken when he gets back. See whether it is worth pursuing the pulse backport [02:31] jamesh, the other option is to put snapd-glib (or part of it) in the pulse patch. [02:47] robert_ancell: by the way, I updated https://github.com/snapcore/snapd-glib/pull/40 based on your feedback -- I'm still not sure whether it is worth merging in its current form, or whether to look at improving the snapd API first [02:47] snapcore issue (Pull request) 40 in snapd-glib "WIP: Add support for the "interface info" mode of the /v2/interfaces API" [Open] [06:24] good morning [06:46] Hi didrocks [06:46] hey duflu [06:55] Hey didrocks and duflu [06:55] Hi tsimonq2 [07:08] good morning desktoppers [07:12] morning [07:14] hey tsimonq2, oSoMoN, Nafallo === pstolowski|afk is now known as pstolowski [07:14] Hey oSoMoN and Nafallo [07:14] hey Nafallo, didrocks, tsimonq2 [07:48] Trevinho, hey, in bug 1789421, what do you want to know exactly? [07:48] bug 1789421 in ubiquity (Ubuntu) "No theme in ubiquity-dm: Error: No valid stylesheet found for 'ubuntu.css'" [High,Incomplete] https://launchpad.net/bugs/1789421 [07:59] Morning all! [08:00] hey willcooke [08:07] good morning willcooke [08:08] Morning oSoMoN, Nafallo, jibel, willcooke [08:08] hey duflu [08:09] good morning desktoper [08:10] a bit later on IRC, our internet is down, I worked a bit offline but it's not coming back so I had to relocate [08:11] salut seb128 ! [08:11] lut didrocks;, en forme ? [08:11] seb128: ça va, et toi ? [08:11] ça va bien ! [08:19] jibel: ubuntu-report 1.3.0 just uploaded to cosmic. Do you want to give a round of testing before I SRU it for bionic? Also, do you prefer me or you turning bug #1786432 and bug #1784383 as a SRU bug? [08:19] bug 1786432 in ubuntu-report (Ubuntu) "Collect DCD file " [Undecided,Triaged] https://launchpad.net/bugs/1786432 [08:19] bug 1784383 in ubuntu-report (Ubuntu) "Collect number of disks and disk size" [Undecided,Triaged] https://launchpad.net/bugs/1784383 [08:21] didrocks, go straight to the sru and I'll do the verification [08:22] jibel: sounds good, and for the bugs? If you don't have time, I can turn them as SRU [08:22] didrocks, you know the code and the potential regression. I can document the test case if you need to [08:23] that's fine, let me handle them completely [08:27] Trevinho, hey, for your ubiquity question, grepping the source would have give you the answer no? [08:27] the ubiquity mode in data has " "stylesheetName": "ubuntu.css"," yes [08:28] does that need to be changed to be yaru? [08:28] Yaru/gnome-shell.css [08:29] seems like "yes" :) [08:29] yep :) [08:29] I wonder if we should have kept a symlink name ubuntu.css for compat [08:29] rather than having to chase down mentions like that [08:29] hum, I didn't think about ubiquity, but only the mode mentionning it [08:29] the rest should use the mode directly [08:29] which didn't change and is still named ubuntu [08:30] k, well a one line patch then [08:30] (I changed the reference to the new stylesheet there) [08:30] no big deal :) [08:30] sorry, didn't think about the ubiquity-dm mode :/ [08:30] no worry, it's minor [10:24] Did Debian suddenly decide that /usr/libexec actually makes sense again? [10:24] jamesh, ? [10:25] seb128: just noticed I've got files in /usr/libexec from xdg-desktop-portal and flatpak [10:25] likely a packaging bug [10:25] both the same package maintainer, so I was wondering if it is a policy change or an activist packager [10:25] or those are special situations and need those for some reason [10:26] like the flatpak expect those locations to exist or something [10:26] seb128: they weren't using those locations in bionic [10:26] changelog says "* Put helper binaries in /usr/libexec as allowed by FHS 3.0" [10:27] I'm not complaining: I think /usr/libexec makes a lot of sense [10:27] ah [10:27] jamesh, https://salsa.debian.org/debian/flatpak/commit/09929622 [10:27] right [10:27] FWIW I've seen smcv changing the paths to libexec in flatpak and ostree as well, i think it must be a policy he is now doing to all his packages [10:28] I don't have an opinion on the topic [10:28] it's a bit suboptimal to have things non consistant though [10:28] well, /usr/libexec is consistent with almost every other distribution :-) [10:32] I don't know why Debian didn't use it before, I guess FHS didn't include it [10:32] at the same time I don't think anyone out of packagers care about those details [10:33] it's not like it was visible to users or making any difference [10:34] Yeah. I believe Debian's decision to reorganise every package was due to libexec being excluded from FHS < 3 [10:35] (which I think came down to the opinion of the spec author rather than a reflection of how software generally installed [10:37] well Debian doesn't "reorganise", libexecdir has been a standard configure option [10:38] it's not like they were force moving something which was meant to be in another location [10:38] reorganise as in "change the default" [10:39] it's amazing that people do care about that [10:39] but seems you do :p [10:40] I only noticed because I was responding to a review that queried the location of an executable [10:41] was going to explain that is found in different locations on different distros due to that policy, and then found the executable was back in libexec on cosmic :) [10:41] which was a surprise [11:07] Night [11:10] Looks like we might see more libexec changes as time goes by. The debian-policy manual was updated: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787816 [11:10] Debian bug 787816 in debian-policy "Replace FHS 2.3 by FHS 3.0 in the Policy." [Normal,Fixed] [11:18] jbicha, should we sync the new webkit2gtk revision from debian? you follow webkitgtk more than I do :) [11:22] didrocks, saw https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/armhf/u/ubuntu-report/20180830_085747_1a6b1@/log.gz ? [11:28] seb128: no, I didn't check autopkgtest yet. Thanks for noticing! This test isn't new, I wonder what have changed in cosmic… [11:28] didrocks, could be flackyness, we can retry in case, it worked on other archs... [11:29] seb128: interesting that those strings manipulation could be flaky, but yeah, let's retry for now [11:29] didrocks, yeah, I mentioned it since we don't get proper notificaiton for autopkgtest issues (we do now for "stuck in proposed", but having direct email on failures like for builds would be nice, though it could be a bit noisy) [11:29] k, doing that [11:29] thx! [11:30] seb128: right, TBH, as the same tests are ran during build, I didn't think of checking autopkgtests for this one [11:30] I was just look at http://people.canonical.com/~mwh/team-summary.html [11:30] which is nice/interesting [11:30] I think we want that info on version [11:30] oh nice! [11:30] I didn't know about that one [11:30] yes [11:31] or in a dashboard [11:31] it's new [11:31] was just being mentioned on #ubuntu-devel [11:31] so I looked and saw ubuntu-report it in ;) [11:31] ah, I didn't miss the memo then! :) [11:31] hehe [11:34] emacs is part of our set [11:34] I'm sure it's due to seb128 :) [11:35] haha [11:41] interesting, your retry passed (when I looked at the "running" page), but it's not listed yet on http://autopkgtest.ubuntu.com/packages/ubuntu-report/cosmic/armhf [11:42] I don't know how often those update [11:42] and I don't see it either on the "recent test runs" part [11:43] it restarted? :( [11:43] http://autopkgtest.ubuntu.com/running#pkg-ubuntu-report [11:43] was running for 8 minutes, last test pass [11:43] and disappeared [11:43] weird [11:44] that service still feels a bit flacky :/ [11:44] yeah… [11:57] ok, passed now [11:57] I have really *no [11:57] idea on how this could be racy though [11:57] and seeing the number of runs on armhf, it's not that racy at least: http://autopkgtest.ubuntu.com/packages/ubuntu-report/cosmic/armhf [11:59] so, I guess for the SRU, I would use 1.3.0~18.04 for versionning [11:59] that should make tsimonq2 happy :p [12:01] seb128: not yet, that webkit2gtk version doesn't build on some arches [12:01] k [12:01] didrocks, :) === pstolowski is now known as pstolowski|lunch [12:07] hmm, does gdk-pixbuf-query-loaders actually require DISPLAY to be set ? (i'm trying to roll a snap without desktop-launcher and run gdk-pixbuf-query-loaders from an install hook instead ... but the file it produces is not listing anything but the header) [12:09] ogra: it shouldn't. It runs fine from .deb postinst scripts [12:09] thats what i thought ... very weird [12:10] the .gdk-pixbuf-loaders.cache it produces actually shows the correct LoaderDir in the header comment ... but nothing more [12:10] so it even looked in the correct dir [12:14] Can someone remind me of the file I need to delete to make g-i-s appear again? [12:14] ah, .config/ [12:15] yeap gnome-initial-setup-done ;) [12:15] gnome-initial-setup-done [12:15] thanks didrocks [12:15] we should discuss about ubuntu-report and g-i-s btw [12:15] what about people upgrading? Right now, as g-i-s doesn't show up (due to that flag), there will be no ugprade report [12:15] ubuntu-report supports per-release uploads [12:16] didrocks, oh, like for 18.04 -> 18.10? [12:16] the question is what to do with g-i-s [12:16] yep [12:16] interesting [12:16] On the one hand, we shouldnt spam the user. On the otherhand, we might have added some nice new stuff [12:16] seb128: in case you didn't get notifiations about build failures: https://buildd.debian.org/status/package.php?p=libdazzle&suite=experimental [12:16] willcooke: yeah, it would be great if the g-i-s introduced really "what's new" in one screen [12:17] and it will be an opportunity to reask for livepatch, report, snaps… [12:17] jbicha, I didn't, are those supposed to be unmailed? [12:17] andyrock, g-i-s hides the livepatch panel if LP is already on right? Is there a way to trick it in to showing it to me again? [12:17] maybe a VM is a quicker solution here [12:17] but yeah, otherwise, we won't have any metrics as think people are running bionic when they upgraded to cosmic [12:18] didrocks, interesting problem. No quick answers I can think of. Could you add it to the Brussels list? [12:18] seb128: I think they're mailed to the "Maintainer" but you can use tracker.debian.org to subscribe to specific packages or an entire team like https://tracker.debian.org/teams/debian-gnome-team/ [12:18] willcooke: wouldn't Brussels be late? but sure, can add [12:18] jbicha, thx [12:19] https://tracker.debian.org/accounts/subscriptions/ lets you pick what kind of emails to get (build is what you'd want here) for subscribed packages [12:20] didrocks, oh yikes, good point [12:21] didrocks, off the top of my head, showing it again (i.e. removing the flag file) is probably ok. [12:21] maybe discussing that next week's meeting? [12:21] I'm still adding a point for Brussels [12:22] didrocks, +1 for the meeting === pstolowski|lunch is now known as pstolowski [12:58] hum, isp website says they fixed the issue, i'm trying to go back to see if it's true :) [13:20] hey [13:20] hey cyphermox [13:20] I have some questsions about the new theme [13:21] I thought it maybe was just how it was, but it's bugging me a bit ;) [13:21] is it on purpose that say, the login screen is purple, rather than aubergine? [13:21] cyphermox: yes, that's a design decision from the yaru team [13:22] cyphermox: you can get in touch with them on the community hub [13:22] this is where the community has some inputs :) [13:22] mmkay [13:22] that's kind of a weird departure from the branding ;) [13:22] mention that to them? [13:22] community hub? [13:22] yep [13:23] the particular post is linked to any of my blog post :) [13:23] ok [13:23] reading blog is certainly going to depart from reading UEFI code ;) [13:25] heh, since it's community driven I won't complain. You say it's widely liked [13:26] didrocks: did you see there are some bugs in https://bugs.launchpad.net/ubuntu/+source/yaru-theme ? [13:30] cyphermox: you can still raise this [13:30] jbicha: hum, just looking at them [13:30] jbicha: if you want them to debian, this will make our upload workflow slower [13:30] I don't have upload rights, TBH, and don't have a desktop debian system to test it there [13:31] nothing prevents someone interested to backport it to debian? [13:31] why do you need to test it on Debian? (I'm sort of serious) [13:33] jbicha: I (and IIRC, I wasn't alone) was told that "if you want to upload to Debian, test it on a Debian system" [13:33] which makes sense, but not something I have time for [13:33] seb128, LO 6.1.1 hasn't actually been released, what's in debian is RC1 (see https://wiki.documentfoundation.org/ReleasePlan/6.1#6.1.1_release) [13:34] Don't tell Debian, but I don't specifically test most of my uploads on Debian (unless they are things like new gnome-shell versions where we diverge enough) [13:35] I'd wait for someone to report bugs because generally there shouldn't really be a difference between Debian & Ubuntu here except that a Debian user will have to manually choose the Yaru themes [13:35] I think becoming a Debian Maintainer is relatively easy, and Seb and Laney would appreciate more people being able to upload stuff there [13:36] Debian Developer is the tough one that requires multiple interviews via email or whatever (so it takes months usually) [13:37] jbicha: right, if I can get time to become a DM, why not [13:37] I remember DM as "is your key signed by a DD" and does a DD vouch for you? ok, have fun :) [13:37] but not beforehand for sure [13:38] it may take a few weeks for processing but it's not much work on your part [13:38] jbicha: if you have pointers, maybe could do in a few weeks [13:38] Debian updates their keyring about every 4 weeks which is the biggest delay [13:38] https://nm.debian.org/wizard/ [13:39] Since Alioth has been shut down, account registration is disabled, unafortunately that means sso.debian.org accounts cannot be created by users anymore. If an account is needed create a ticket in the SSO RT queue either by emailing mailto:sso@rt.debian.org (the email needs to include the string "Debian RT" in subject) or via RT webfrontend. Please include reasoning for your new account. This has been [13:39] announced at Debian devel mailing lists [13:39] painful :/ [13:40] hmm, ok I'll look into that [13:40] thx! [13:40] jbicha: oh unrelated, did you see that the volume override is finally merged? [13:41] I know there is a code freeze, unsure how much you want to fight for that in this Tweaks release [13:41] I don't remember, the PR was still up IIRC? [13:41] MP* [13:50] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libreoffice seems to indicate that binary package libreoffice-kde4 needs to be deleted, how do I do/request that? [13:51] https://wiki.ubuntu.com/ArchiveAdministration#Removals [13:51] I guess I need a core dev to do that on my behalf [13:52] kenvandine[m], can you help there? ^ [13:53] oSoMoN, versions disagrees with that statement :) [13:54] oSoMoN, http://download.documentfoundation.org/libreoffice/src/6.1.1/ exists and has tarballs [13:55] seb128, yes, but that looks like an error on upstream's part to me, there's almost always two RCs before a minor update [13:56] oSoMoN, k, anyway no big deal [13:56] and https://www.libreoffice.org/download/download/ doesn't list 6.1.1 [13:58] oSoMoN, what's that kde4 thing? [13:59] oh on s390x [13:59] and others, can't read [13:59] the kde5 depends issue do you know what that is? [13:59] it's also blocked by poppler & glib [14:00] oSoMoN, did you stop building that binary on purpose? did you check if there are remaining rdepends? [14:01] oSoMoN, also next time it would be nice to have a full changelog on https://launchpad.net/ubuntu/+source/libreoffice/1:6.1.0-0ubuntu1 I bet there are most changes that those 3 bullet point, maybe a -v to incude extra entries? [14:01] seb128, no I don't know what that kde5 depends issue is, the version requirements seem to be fulfilled (and I verified that it can be installed cleanly) [14:02] you're right, I should have made the changelog more verbose [14:02] there are no remaining rdepends, so it's safe to remove libreoffice-kde4 [14:09] oSoMoN, done for -kde [14:11] seb128, thanks [14:12] oSoMoN, the kio thing is because the new binary got NEWed to main and those kde packages are in universe, that looks like an error, I'm moving it back to universe [14:13] oSoMoN, done as well [14:13] oSoMoN, hopefully next update it's listing only glibc/poppler which are known transitions and not yours to solve :) [14:14] great, thanks for your help! [14:15] np! [14:19] oSoMoN, the -l10n autopkgtest is unhappy on armhf, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/armhf/libr/libreoffice/20180829_171705_52190@/log.gz [14:19] oSoMoN, I'm going to retry in case that's enough [14:21] ack, thanks [14:23] [fwl.SubstituteVariables::com::sun::star::util::XStringSubstitution] is testcode: [ifc.util._XStringSubstitution] - COMPLETED.FAILED [14:23] was the issue in that log === ecloud_wfh is now known as ecloud [14:46] wow, inflation of colons ... === chrisccoulson_ is now known as chrisccoulson === disi is now known as Guest42234 [15:46] k, I got the git merge requests listed on version ;) [15:46] going to make Trevinho happy, his changes are on top of http://people.canonical.com/~platform/desktop/desktop-packages.html now [15:57] seb128: <3 :-D [15:58] seb128: for glib it mentions the MP for bionic though, not sure you can filter that [15:59] anyway nice to have the PRs listed too :) [16:01] didrocks: shell side is updated, I took a bit more as we had some ping-pong on upstreameable fixes with Florian [16:04] Trevinho: nice! I will give another round of review on Monday (as tomorrow I'm off and near EOD) [16:04] unless someone else beats me to it [16:04] seb128: in https://bazaar.launchpad.net/~ubuntu-desktop/ubuntu-desktop-versions/trunk/view/head:/versions.py#L93 there are a few more: https://git.launchpad.net/~canonical-desktop-team/+git/ubuntu-desktop-gbp-importer/tree/projects-mapping.source#n12 [16:05] didrocks: ok thanks for what you did anyway so far :) [16:05] yw! ;) [16:10] * oSoMoN calls it a day, have a good evening everyone! [16:14] Trevinho, k, feel free to mp changes :) [16:14] * Trevinho lazy :-D [16:15] Trevinho, though your table are diff upstream/debian not debian/ubuntu [16:15] our gdm source is gdm3 for example [16:15] debian_aliases I'm saying [16:15] seb128: nm, I think they're basically the same [16:16] gtk isn't also? [16:17] nope is the same... weird as the salsa basename project is not matching there then [16:17] nm then [16:21] yeah, Debian used the upstream vcs names and we sticke to name them as our sources as name [16:21] named [16:23] on that note calling it a day [16:23] have a nice evening desktopers! [16:40] Trevinho: sorry about the confusing repo names in Debian (gdm for instance). When I did that, I wasn't thinking about Launchpad repo organization at all [16:40] we could rename the gdm3 source package to gdm in Debian, but that's a pretty low priority [16:42] see https://wiki.debian.org/Gnome/Git#Packages_named_differently_from_their_git_repos === pstolowski is now known as pstolowski|afk [17:19] night all