[04:50] good morning [04:52] Morning didrocks [04:52] Huh? The only working call to vaCreateSurfaces is the one where we pass the parameters in the wrong order (!?)... where working means status=0 but still corruption [04:54] Oh... macro magic to rearrange parameters [04:59] hey duflu, good Monday? Sounds some wayland fights ;) [05:00] didrocks, It is Monday at least. Yes, Wayland :) [05:00] heh :) [05:35] \o/ Hardware decoding under Wayland to Clutter! [05:35] (with many hacks that now need eliminating) [06:40] didrocks, Yes it is now a good Monday :) [06:40] How are you? [06:41] duflu: I'm good, thanks! What happened so that it became a good Monday? :p [06:41] didrocks, I finally got hardware video decoding on Wayland fixed. Only took a week [06:42] oh, that will be a great enhancement :) [07:00] good morning! [07:01] hey andyrock, good week-end? [07:01] Morning andyrock [07:01] hey didrocks [07:01] hey duflu [07:01] good enough [07:01] spend the we in Bologna with my brother [07:02] sounds great ;) [07:07] good morning desktopers! [07:09] hey andyrock duflu, re didrocks [07:09] Hi seb128 [07:09] hey seb128 [07:09] re seb128 [08:03] what's up [08:04] morning all! [08:04] Doing a pretty good impression of winter here today [08:08] hey Laney, willcooke, how is u.k today? [08:09] more automn like here === maclin1 is now known as maclin [08:11] hey seb128 [08:11] yeah quite grey, wet and windy [08:12] Morning seb128 Laney willcooke andyrock duflu [08:12] Hi flexiondotorg [08:13] hey flexiondotorg [08:16] good morning all :) ! [08:17] hey alexarnaud [08:17] seb128: how are you today? [08:19] good! you? === JamieBen_ is now known as JamieBennett [09:21] seb128: good :) === carlolo is now known as clobrano [10:41] seb128: Who do I complain to that since rebooting from unity to gnome-shell, I can no longer disable my touchpad? [10:42] infinity: could be the -synaptics vs libinput transition? [10:42] I don't think my driver changed. [10:42] But the mouse/keyboard options sure did. [10:42] infinity, uninstall synaptic if it's installed [10:42] bug #1686081 [10:42] bug 1686081 in xorg (Ubuntu) "If -synaptics is installed, GNOME Mouse & Touchpad Settings doesn't work" [High,Confirmed] https://launchpad.net/bugs/1686081 [10:43] Hrm. Will try and report back. [10:43] seems didrocks is on the case, /me goes back to what he was doing [10:47] didrocks: You win. How very unintuitive. [10:47] didrocks: But thanks for saving me from going insane with accidental palm drags. [10:48] infinity: let's say "have experience with it" :-) [10:48] happy that it helped! [10:49] didrocks, do we have a "proper" solution to that, like can we forcibly remove synaptics or something? [10:50] didrocks: I assume there's still ongoing work to make the default theme less... Fedora? [10:50] (All the blue is rather jarringly unUbuntu) [10:50] infinity, yeah we do - got a hackfest kinda thing planned for end of August [10:51] infinity, I made a start. kinda. http://imgur.com/a/NjUXa [10:51] few things to fix there ;) [10:51] willcooke: Cool. I think in the interim, only a few colours need changing to make it at least kinda look right (the +/- bars in the panel, and the default lock screen colour) [10:51] willcooke: there is a trello card for it: https://trello.com/c/9GI3EFh2/122-bug1686081-if-synaptics-is-installed-gnome-mouse-touchpad-settings-doesnt-work, discussed about it with seb128, not trivial, but really annoying [10:51] willcooke: Oh, and maybe the top bar slightly less absolute black. :P [10:52] infinity, yeah totally agree. Thats what I was trying to fix actually. global search and replace was a bad idea it seems. who knew?! [10:52] (ie: same background as our gnome-terminal) [10:52] didrocks, thanks! [10:52] infinity: I guess we all are in favor of blackless top bar (at least, with our theme :p) [10:52] willcooke, it's the same old "need to port u-c-c to libinput" that oem wants and we are talking about for some cycles [10:53] didrocks: I actually like the default GNOME theme, I just don't want it identical to Fedora. And we don't use true black anywhere, so that same "purplish almost-black" that we use in the terminal background would be appropriate. === Kamilion is now known as |{amilion === |{amilion is now known as Kamilion [10:54] infinity: could be, we'll experiment (and maybe provide 2 sessions: gnome upstream one with default themes et our own "ubuntu experience"), that's still to be discussed :) [10:54] And, of course, something orangeish to replace the blue +/- bars. [10:54] I'm going to miss menus in my window titlenbars. [10:54] titlebars, too. [10:55] (same) [10:55] As horrible hacks go, when it finally worked how I wanted it, it was niceish. [10:55] what have you changed? [10:55] just curious, could be useful feedbacks [10:55] any extensions/anything? [10:55] Basically nothing. Literally just logged into the fresh session a few hours ago. [10:56] I assume it migrated over some generic settings from unity (ie: it's still got my wallpaper selection), but for the most part, it looks very Fedora. [10:56] apart from the launcher and some icon renames, nothing is ported, the keys were still the generic one [10:56] so nothing to port was the net benefit :) [10:57] Right, I didn't mean to imply there was actual migration, just that it's obvious some stuff went unchanged, like who renders the root window (nautilus?) [10:58] Oddly enough, that's sort of comforting. Even when your whole workflow goes to crap, having the wallpaper consistent feels like not all is lost. :P [10:58] ahah :) [10:58] that familiar feeling… [11:02] didrocks: Anyhow, I won't be shy about providing some feedback as I find things that rub me the wrong way. [11:02] thanks infinity, all feedback gratefully received [11:02] didrocks: First thing I noted (other than the synaptics bug) was that Super-L wasn't bound to lock screen anymore. That must have been a Unity special. [11:02] I'm sure you won't be shy ;) and yeah, please feel free :) [11:03] haha! Told you so seb128 & Laney ;D ^ [11:03] didrocks: But given that binding also works in Windows, I found it a pleasant analog. [11:03] yeah, their default is the old ctrl+alt+l? [11:03] *nod* [11:03] I think both worked for me in Unity because I got Super+L from Unity and Ctrl-Alt-L from the gnome keyboard settings. [11:03] On relog, of course, I only had the latter. [11:04] And since they don't seem allow binding two things to one action, I now have the former. :P [11:04] yeah, I never left Ctrl+Alt+l, the other one was added to compiz as a secondary action [11:04] I use a Windows desktop for gaming, and Super-L is the shortcut there, and I dig consistency. [11:05] But also, it's the binding that makes more sense when Super is "they key to manage overall desktop stuff". [11:05] willcooke: can you add it to your special list of polish that we can discuss about? [11:05] (Though, I guess maybe GNOME people still live in a pretend world where some people's keyboards were made prior to 1997?) [11:05] Or Happy Hackers. [11:05] but worskpace changes are still Ctrl+Alt + something [11:06] Yeah. True. But also no analog there on other OSes, which may be why I care less. ;) [11:06] I remeber we had the plan for super + anything on unity, we only did half of it though [11:06] ;) [11:06] didrocks, I'll create a trello card to track [11:06] great ;) [11:06] I think we should have both keybindings to lock working [11:06] ^ [11:06] I'd agree with that. [11:06] if we pick one we are going to piss half of the users either way [11:06] Is there a way under the hood to make GNOME take two bindings? [11:06] The UI sure won't let you. [11:06] I don't think so [11:06] which is the issue [11:06] Ick. [11:07] we might need to hack and special case ctrl-alt-L or something [11:07] I guess you could just add a second binding "Alternate Desktop Lock". [11:07] I think I found an old patch to move the gsetting to an array [11:07] Which calls the same thing. [11:07] or that [11:07] willcooke, right, that's more work/incompatible changes though [11:07] willcooke: the issue isn't doing it, it's more about exposing it with minimal changes in g-c-c [11:07] ack [11:07] I mean, I think it would be stellar to allow an array for ANY binding, but a second binding would be a reasonable hack for this one small regression. [11:08] And simple. [11:08] yeah, but as seb128 told, it means we need to change all gesttings keys from string to list of array [11:08] and patch every apps which are using them [11:08] Right, that's a mess. [11:08] Hence the other thing. [11:08] doesn't seem minimal, not going to work in the snap world sharing the same keys from other code [11:08] yeah [11:08] but yeah, having "lock screen" and "alternative lock screen" lines wouldn't be the end of hte world [11:08] I guess making that one special is fine as well [11:08] the other way would be to special case one in the shell [11:09] which is what we did in unity it looks like [11:09] and we never got a complain about it [11:09] Special casing one makes it effectively invisible to the user. [11:09] But fair play, since that's how it was before too. :P [11:09] right [11:09] and you could say that the documented one is the one in the settings [11:09] (Though it did show up in the Unity help screen, I think, so only "invisible" fromthe POV of the keyboard bindings screen) [11:09] and the other one is the compat one of people who are too used to the old keybinding [11:11] seb128: I think one of my favourite things about having a Unity7 and Windows7 (now Win10) desktop side-by-side was that all the important bindings were effectively identical. [11:12] Super+Num to pick from the launcher, Super+L to lock, etc. [11:12] I suspect that wasn't an accident. [11:13] Really, the only noticeable difference between them is that one of them can play more video games, and WINDOWS UPDATE IS STILL A FLAMING HEAP OF OH GOD HOW HAVE THEY NOT IMPROVED THIS IN TWENTY YEARS ARGH. [11:13] Otherwise, they're hard to tell apart. [11:14] (Seriously, the next time you're hating on the performance of dpkg and apt, go update a fresh Windows installation and get some perspective) [11:20] Oh nice, Firefox seems to have survived the transition. It only shows me a menu bar when I press Alt, like the upstream builds do. [11:21] (PS: I took your survery, please don't switch the default browser, kthx) [11:23] infinity, we wouldn't have to deal with builds on weird archs if chromium was our default :p [11:23] I'm pretty sure I've had to fix Chromium on armhf in the past. [11:24] right, armhf is something we need to deal with [11:25] ppc64el or s390x not so much [11:25] If we get no commitment from IBM on those, we'll drop them. [11:26] I don't object to dropping things with zero upstream support, I object to the knee-jerk "it didn't build, so let's not look into it and discuss dropping it". [11:26] Since there have been many times in the past when it was a simple 1-liner. [11:27] Well, s390x is already dropped, so that's a red herring people keep bringing up. [11:27] it's not "it didn't build", it's "firefox is outdated for most of the cycle and our unstable users have a version with security issues" [11:27] But I'll talk to the POWER guys about ppc64el. [11:27] and that has been the case for at least 3 cycles now [11:28] it's not a one time thing [11:28] it has been pretty much a permanent situation since xenial [11:28] It's not a 1-time thing, but it's also different arches each time. [11:28] jfyi, current failures of firefox 55 https://launchpad.net/%7Emozillateam/+archive/ubuntu/firefox-next/+sourcepub/8091927/+listing-archive-extra [11:29] so arm64 in addition of what artful currently has [11:29] In xenial, it's currently armhf and ppc64el. In trusty, it's arm64 and ppc64el. Which is curious. [11:29] ff 56 for comparsion https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa/+sourcepub/8099928/+listing-archive-extra [11:30] Given identical upstream codebases, if armhf fails on one series and arm64 on another, it might be our bug, not upstream's. [11:30] (arm64 is happy there) [11:31] (some failures are rust related) [11:31] 56 is missing cargo on ppc64el [11:32] seb128, I know, I hacked some packages myself [11:32] I think chrisccoulson is onto updating those officially [11:33] https://bugs.launchpad.net/ubuntu/+source/cargo/+bug/1701556 [11:33] Ubuntu bug 1701556 in rustc (Ubuntu) "Backport rustc 1.17 and cargo 0.18 to 14.04/16.04 and 17.04" [Undecided,New] [11:35] didrocks: So, plugins. Is there anything (you know of) that will restore my ability to see several timezones in my clock applet? [11:38] * infinity decides that maybe trying to sleep is smarter than worrying about what timezone he's in. [11:38] Oh, I like the virtual desktop upper bound just being "one more than you're using" instead of a static number. [11:39] infinity, you can add locations from gnome-clocks and they should be listed [11:39] (we currently don't pre-install gnome-clocks though) [11:39] good morning [11:39] hey jbicha [11:39] seb128: Ahh. I was going to say "That's not a command I have". :P [11:41] seb128: Hrm. I have them in gnome-clocks, but that doesn't change the applet drop-down in any meaningful way. [11:41] I proposed a gjs SRU … which resulted in this email: https://lists.ubuntu.com/archives/ubuntu-release/2017-July/004163.html [11:42] jbicha: Robie's very much a letter of the law guy. Which isn't the worst thing ever (I'd rather that than the opposite), but yeah, probably means we need more law for him to follow. [11:43] jbicha: FTR, if he'd passed on it, you could have poked me directly. [11:43] infinity, right, it isn't working for me either but jbicha said that was supposed to do that iirc, I didn't have time to debug/have a look yet [11:44] the current status is that Robie added the GNOME microrelease exception to the SRU wiki page [11:44] GNOME's always had an MRE, literally since we first had SRUs. [11:44] But we may have undocumented it when we went to the new blanket statements. [11:44] Oops. [11:45] yes, it was removed from the wiki but it's back now [11:45] so assuming there are no objections, it should be a bit smoother for GNOME SRUs now :) [11:47] infinity, in fact it works today for me, maybe it needed a session restart after installing gnome-clocks or something... it's listed in the popup you get when clicking on the date in the top panel [11:47] seb128: Ahh, lemme log out, I guess. [11:49] seb128: Well, one bug down, one new one discovered. [11:50] seb128: Seems on a fresh boot, Ctrl-Alt-T gives me terminals in a snappy and quick timeframe. When I log out and back in (WTF?), Ctrl-Alt-T has a delay of some 10-20 seconds. [11:50] seb128: Thought this was a 1-time weirdness last time I did a log out dance, but it just reproduced this time too. [11:50] dunno about this one [11:51] seb128: Have you seen that, or am I special/insane? [11:51] I guess I'm special. [11:51] I didn't see it [11:52] seb128: Must be something long-running between sessions, but I kinda assumed logins would be under a systemd user session and the cgroup blown away on logout (maybe I'm wrong there) [11:54] In fact, all keyboard shortcuts have that massive delay. Lock screen was the same. [11:54] Weeeeeird. [11:55] I wonder if it's some conflict between the two gsd-keyboard sessions running. Though, they should both be running on a fresh boot/login too. [11:55] if there was a cgroup that was killed on logout, maybe we wouldn't have had LP: #1610944 [11:55] Launchpad bug 1610944 in gnome-session (Ubuntu Zesty) "GNOME Online Accounts breaks if you log out (until you reboot)" [High,Triaged] https://launchpad.net/bugs/1610944 [11:55] upstream has a different workaround as of last week but not in artful yet https://bugzilla.gnome.org/764029 [11:55] Gnome bug 764029 in general "goa-daemon (and most other D-Bus services) not stopped when the user session goes away" [Critical,New] [11:56] jbicha: Ahh, hrm. Well, that is probably related to the bug I'm seeing now. [11:57] is one of the gsd-keyboard's from gdm3? because that would make sense since gdm3 itself runs a minimal gnome-shell session [11:57] I find it strange that the distro that foisted systemd on us isn't using it correctly. [11:58] jbicha: Yeah, one's gdm, and one's me. Like I said, I'm sure they're always both running, so that's a red herring. [11:58] jbicha: But clearly, some state is breaking on log out/in. [11:58] that GOA bug was a release blocker for much of Fedora 26's release cycle [11:58] jbicha: And it's odd breakage, since I'd expect shortcut keys to either work or not work, rather than working after a 15s delay. :P [12:00] just add a splash screen :P [12:01] A nice modal dialog that says "GNOME has detected you used a keybinding shortcut, we'll process your request and act on it shortly..." [12:01] :) [12:02] Oh well, for now I'll reboot. That one will surely drive me batty in short order and I'll file a bug and/or debug it myself. [12:02] But yes, it would almost certainly "just go away" if we used a proper user session. [12:02] Murdering all the things is a simple fix for so many bugs. [13:03] willcooke: wow https://imgur.com/a/NjUXa is very orange [13:03] jbicha, ha! I got a bit carried away [13:08] we'll just ship sunglasses along with the isos [13:09] lol [13:15] Laney, https://trello.com/c/9kiXF8rW/134-systemd-user-session-for-gnome-shell ... do we have no systemd user session at all in GNOME atm? how did it start under unity/would it be difficult to do the same for the GNOME session? [13:15] I don't remember the details [13:16] seb128: Exec=/usr/lib/gnome-session/run-systemd-session unity-session.target [13:17] so we "just" need an equivalent target under GNOME I guess? [13:18] dunno [13:18] that would be the first thing to try [13:18] I'm not sure if there would be issues or not [13:18] do we feel like we need that for 17.10? [13:19] I wonder if we have things that got made systemd user jobs that are not going to work anymore without that [13:19] that was all downstream stuff, so I doubt it [13:22] hum, k [13:22] going to keep investigating why file sharing over bluetooth is not working then [13:22] it looked like it could be due to that but maybe not [13:22] thanks Laney [13:23] there could be issues like things not being killed when you log out [13:24] Laney, fedora has http://pkgs.fedoraproject.org/cgit/rpms/bluez.git/tree/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch [13:25] Laney, I don't think logout is the issue there, I think bluez just expect the user session to be there [13:25] I guess we could use the fedora workaround [13:25] * seb128 tries that [13:29] seb128: that SystemdService specified unit doesn't exist [13:30] Failed to introspect object / of service org.bluez.obex: Unit dbus-org.bluez.obex.service not found. [13:31] https://paste.ubuntu.com/25162502/ [13:32] * mancman3 waves @ the good non ms winshit users [13:36] Laney, you are right [13:37] seb128: bluetooth.service has Alias=dbus-org.bluez.service [13:38] Laney, typo you think? [13:38] maybe? [13:39] not sure what it's supposed to be [13:39] but maybe it's a missing alias on obex.service? [13:40] no, that is there [13:40] I think the obex package should enable the unit (or create that symlink) [13:41] hum, ctrl-R at the wrong place [13:42] Laney, I'm a bit confused now, isn't it simply the SystemdService being wrong as your sed-ed earlier? [13:42] or is that not enough? [13:42] seb128: the value it had should work because obex.service has an alias for it [13:43] but it doesn't because the unit isn't enabled by the package [13:43] you can fix it by making a symlink [13:45] Laney, thanks [13:50] ricotz, hey, did you get any reply from meson upstream about the armhf issue? [13:52] seb128, no, I guess since doko proposed the other arm fixes, he pretty sure knows how to fix the remaining ones [13:52] ricotz, did you ask him about it? [13:53] seb128, no [13:53] ricotz, could you? ;-) [13:53] seb128, you are afraid? ;) [13:54] no but you are the one that asked for that version to be synced and you seem to understand the issue [14:18] Laney, sorry but I'm going to bother you again about that systemd thing, the right way to enable it would be to create a symlink to the service in a .wants? [14:18] Laney, is there a standard "service-used-by-default" we use for such cases? I tried to look for examples and failed to find some [14:19] well https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764678 has sockets.target.want but it's for a socket unit [14:19] Debian bug 764678 in debhelper "dh-systemd: Please support systemd user services" [Wishlist,Open] [14:19] didrocks, ^ or maybe you know? [14:20] seb128: just in /usr/lib/systemd/user/ [14:20] depends, user services or system service? [14:21] didrocks, systemd --user [14:21] system services should use dh_systemd to enable it, indeed [14:21] it doesn't need to be in wants of anything [14:21] ah [14:21] how do you call that? [14:21] this is dbus activation [14:21] I don't know if dh_systemd has the support for it, I would say no [14:21] didrocks, cf the bug I just mentioned [14:21] it doesn't [14:21] that's why I'm asking about the symlink ;-) [14:21] seb128, regarding meson, basically https://paste.debian.net/plain/977929 [14:22] seb128: symlink is fine, it's basically what dh_systemd does (+ service start/restart) if you are in the systemd case [14:22] ricotz, can you send that upstream? (and maybe a debdiff to Debian or us for packaging) [14:22] it doesn't use systemctl enable, because of systemd bootstrapping issue [14:22] (like, when you get to your first release with systemd, but it's not installed yet, so you don't have systemctl, and so on…) [14:23] hum [14:23] I'm getting confused [14:24] if it's an user service, a symlink to the corresponding .wants to enable it is enough [14:24] Laney, there is a obex.service already in that dir but you said the issue is that it's not enabled and would need a symlink? [14:24] yes [14:24] but not to wants [14:24] to where? [14:24] ah, I see, Laney says it's dbus activated [14:24] right [14:24] the value specified in alias= [14:24] that's what systemctl --user enable foo would do [14:24] you have to do that manually, that's what didrocks is saying [14:25] why do we need an alias at all here? [14:25] things seems more complicated that they should be [14:25] because the dbus service file is asking for that unit to be started [14:25] why don't we just the dbus service start the right unit? [14:25] (I'm having the same, probably stupid question than seb) [14:26] they expect the unit to be enabled [14:26] that is a fair expectation [14:26] what unit? [14:26] there are multiple provider? [14:26] (hence the alias?) [14:26] don't know [14:26] but it is fair enough for something to rely on a unit being enabled [14:26] I guess I don't understand why we need an alias [14:26] rather than having 1 unit [14:26] and the dbus activation used that 1 unit [14:26] using [14:27] no idea, it wasn't any of us that developed this [14:27] I'm telling you how to make it work with how it is set up now [14:27] k, so you are not suggesting the design is better [14:27] Laney: where is dbus activation file btw which reference that alias? (just curious) [14:27] just hitting on what to do with what upstream is providing? [14:27] /usr/share/dbus-1/services/org.bluez.obex.service [14:27] Laney, gotcha, sorry for being slow to get it [14:27] I have no idea if that design is optimal or not [14:27] Laney, thanks again! [14:27] presumably there is a reason they did it this way [14:27] np! [14:27] maybe they want a non version alias where maybe there will be versioned one [14:27] seb128, https://paste.debian.net/plain/977932 [14:27] or multiple prociders [14:28] providers* [14:28] jbicha, do you think you could get that patch from Rico in debian ^? [14:29] didrocks, it's a bit difficult to get proper context on bluez bugs, they don't have proper bug tracking&such [14:29] do you know how this dbus activation is working, as there is no service, it seems as you get the bug it doesn't fallback to Exec= [14:29] correct? [14:29] that's right [14:30] seb128, jbicha, note this an attempt [14:30] ok, so there is no point in keeping the Exec= as soon as you have SystemdService= [14:30] oh, or maybe dbus is smart enough to say "no systemd running, I'm ignoring SystemdService and only using Exec=" [14:31] yep [14:31] didrocks, http://pkgs.fedoraproject.org/cgit/rpms/bluez.git/tree/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch suggests it does [14:31] interesting, didn't follow those user sessions changes [14:31] (the comment/description) [14:31] it's for if you don't have systemd --user [14:31] yeah, making sense [14:31] yeah you can see that the old file in that patch was buggy in that case [14:32] oh ok, so yeah, disabling it unconditionnally ofc is wrong [14:32] thanks for the quick tech catchup Laney, seb128 ;) [14:32] thanks didrocks Laney ;-) [14:32] #ubuntu-desktop Tech Talks [14:33] :-) [14:33] /m/me needs a tech talk [14:33] ffs [14:33] and better wifi [14:34] not a better keyboard? :) [14:34] or mosh or something [14:34] heh [14:35] trying to work with GMainContext, threads and such [14:35] it's confusing [14:36] another threading bug your are fighting against? [14:36] same [14:36] argh, good luck :( [14:37] sendto(3, "GET /v2/system-info HTTP/1.1\r\nHost: \r\nConnection: keep-alive\r\nUser-Agent: snapd-glib/1.16\r\n\r\n", 93, MSG_NOSIGNAL, NULL, 0) = 93 [14:37] poll([{fd=3, events=POLLIN}, {fd=6, events=POLLIN}], 2, -1 [14:37] why does that poll block? [14:37] there should be shit coming back from snapd [14:38] I guess you can't mock easily the daemon-side of the API because there are other exchanges first? [14:38] nah [14:38] I made a minimal version that does the same thing [14:38] works ofc [14:38] so, snapd doesn't answer? [14:39] or sounds like it doesn't [14:39] seb128: the Debian maintainer of meson == meson upstream maintainer [14:39] pretty sure it does [14:39] hum [14:39] but for some reason I don't get it [14:39] jbicha, but he refuses to get fixes in Debian? [14:39] it's all GSocket and stuff at the application level of course [14:39] * Laney shrugs [14:40] back in a min [14:41] jbicha, the issue is that the meson updates are blocked in artful-proposed due to armhf autopkgtest issues, I asked rico if he could ping upstream about it and he came with that patch but I don't think he upstreamed it [14:41] seb128: I don't think he's really refusing, it's just the patches need to be proposed and maybe pushed a bit [14:41] seb128, https://github.com/mesonbuild/meson/pull/2110 [14:41] ricotz, thanks [14:41] jbicha, seems ricotz did upstream it now, so unping [14:42] :) [14:42] as said I haven't/can't confirmed that it actually fixes it [14:42] it's fine [14:42]