[00:20] <jbicha> GunnarHj: interesting read: https://girinstud.io/news/2018/02/ibus-hangul-and-compose-key-the-incredible-journey-of-a-simple-patch/
[00:35] <GunnarHj> jbicha: Yeah.. Bug hunting may be truly frustrating sometimes.
[00:55] <GunnarHj> jbicha: Btw, I can't reproduce that issue with compose:caps on artful.
[00:57] <jbicha> are you using ibus?
[01:55] <GunnarHj> jbicha: IBus is the selected IM framework, if that's what you mean.
[05:54] <ulysses> Hey guys, I accidentally botched my radeon config file, and I'm stuck in Wayland and csan't get to the file due to its root restrictions
[05:54] <ulysses> Any advice on how to restore the file to its defaults?
[05:54] <ulysses> I know how to fix it, it's just a matter of getting to the root file
[07:18] <oSoMoN> good morning desktoppers
[07:18] <duflu> Morning oSoMoN
[07:24] <duflu> Hmm Redback in the letterbox
[07:24] <duflu> Yep, it's summer
[07:24] <oSoMoN> hey duflu
[08:20] <didrocks> good morning
[08:38] <duflu> Morning didrocks
[08:39] <didrocks> hey duflu, how are you?
[08:39] <duflu> didrocks, I am imperfect. But this made it a good day: https://www.youtube.com/watch?v=bCc16uozHVE
[08:40] <duflu> How are you didrocks?
[08:40] <duflu> Morning seb128
[08:40] <seb128> good morning desktopers
[08:40] <seb128> hey duflu didrocks
[08:40] <didrocks> salut seb128
[08:51] <tjaalton> how to debug snaps that don't launch?
[08:56] <oSoMoN> good morning didrocks, seb128
[08:56] <tjaalton> "desktop-launch: not found"
[08:58] <GunnarHj> Good morning all!
[08:58] <GunnarHj> seb128: How about starting the day with a nice regex? :)
[08:58] <GunnarHj> It's the patch at bug #1688994
[08:58] <didrocks> salut oSoMoN
[08:59] <seb128> hey GunnarHj, do you ever stop working/sleep? ;)
[08:59] <seb128> lut oSoMoN
[08:59] <seb128> tjaalton, that would be an issue :p
[08:59] <GunnarHj> seb128: It happens. But don't tell anyone.
[08:59] <seb128> tjaalton, but usual way would be to try starting manually and see if it displays an error on stderr, then you can try to snap run --shell <snap>
[08:59] <seb128> that gives you a shell inside the snap
[08:59] <tjaalton> ok
[09:00] <seb128> GunnarHj, :)
[09:00] <seb128> GunnarHj, I'm still doing morning catching up but I look at that in 15 min or so
[09:00] <GunnarHj> seb128: Great!
[09:02] <seb128> tjaalton, inside the snap when you use --shell the env is not fully set, e.G you can't start the command directly, usually you want to use /snap/<snap_name>/current/command-<binname>.wrapper
[09:04] <tjaalton> seb128: that's what I tried and it said "desktop-launch: not found"
[09:04] <duflu> willcooke, seb128, hangout?
[09:04] <tjaalton> darktable
[09:04] <didrocks> tjaalton: in your snapcraft.yaml, do you have the desktop part?
[09:04] <tjaalton> where is that?
[09:05] <didrocks> this is your snap, correct?
[09:05] <tjaalton> no
[09:05] <didrocks> you authored snapcraft.yaml
[09:05] <didrocks> ah
[09:05] <tjaalton> installed from the store, darktable 2.4.1
[09:05] <didrocks> maybe the snapcraft author didn't pull the correct part
[09:05] <didrocks> first, do as seb told, using snap run --shell <snap_name>
[09:05] <tjaalton> tried to launch from the store page
[09:05] <didrocks> and try to find in $SNAP desktop-launch
[09:06] <willcooke> sorry duflu, didnt open my calendar and got sucked in to email
[09:06] <tjaalton> looks like I can't access anything while on the shell
[09:06] <didrocks> you should
[09:06] <didrocks> or you are not in $SNAP
[09:07] <tjaalton> "can't open directory /share/locale"
[09:07] <tjaalton> ok, the snap is probably busted, where to file bugs?
[09:08] <didrocks> flexiondotorg: is there a field people can use to contact snap's author? ^
[09:09] <seb128> duflu, willcooke, sorry, I still didn't get used to that one being shifted to be one hour earlier ... do you need me to join?
[09:09] <duflu> nah
[09:09] <seb128> if so give me a few minutes
[09:10] <seb128> tjaalton, email to the snap author?
[09:10] <seb128> there is no unique location like launchpad for snap reports
[09:11] <tjaalton> bah
[09:11] <tjaalton> ok
[09:17] <tjaalton> heh, is there no limit to how many instances of a snap app can be launched? installed wallpaperdownloader, and have a few copies running :
[09:17] <flexiondotorg> didrocks Yes, the contact field which is exposed via `snap info` and the store page.
[09:20] <seb128> flexiondotorg, hey, do you know if that snap is known to be buggy?
[09:25] <flexiondotorg> seb128 I've not tested darktable myself. I'll take a look when I'm back at work tomorrow.
[09:45] <seb128> ok, people who like regexps and maybe perl, how does  https://launchpadlibrarian.net/356033584/pkgbinarymangler-configure.ac.debdiff look to you?
[09:45] <seb128> it's to catch cases where " AC_SUBST([GETTEXT_PACKAGE], [name])" is used
[09:46] <seb128> instead of " GETTEXT_PACKAGE=<domain>"
[09:46] <didrocks> was there really a "like" in your sentence? :p
[09:46] <seb128> the regexp looks fine to me but I wouldn't say no to have somebody else to comment
[09:46] <seb128> didrocks, oh, I see you raise your hand, thanks for stepping up :p
[09:46] <didrocks> there was indeed a like…
[09:46] <didrocks> so doesn't match ;)
[09:47] <seb128> haha
[09:47] <didrocks> hum, I wonder if it shouldn't be matched in one expression instead of 2
[09:50] <seb128> you mean?
[09:51] <seb128> .*GETTEXT_PACKAGE<somethingcomplex>name
[09:51] <seb128> ?
[09:51] <seb128> where somethingcomplex is  "=" or "],/s*"?
[09:51] <seb128> \s
[09:52] <didrocks> yeah, I found an expression, but it's way less readable
[09:52] <didrocks> so, let's use the or
[09:53] <didrocks> my only remark is that I would use \S+ for both
[09:53] <didrocks> (first and second expression)
[09:53] <didrocks> to ensure $1 isn't empty
[09:53] <didrocks> and expand
[09:53] <didrocks> the rest looks good to me
[09:53] <didrocks> GunnarHj: ^
[09:56] <seb128> didrocks, thanks for having a look
[09:57] <GunnarHj> didrocks: \S+ is in both.
[09:58] <GunnarHj> Or did I misunderstand you?
[10:00] <didrocks> GunnarHj: not in the debdiff I saw at least: +    $domain = $1 if /^GETTEXT_PACKAGE\s*=\s*(\S*)/ or
[10:00] <didrocks> \S*, not \S+
[10:02] <GunnarHj> didrocks: Ah, see now. Actually there are several other regexes in the script which use \S* as well. Is it motivated to make that change all over?
[10:03] <GunnarHj> didrocks: (i.e. I didn't introduce \S*)
[10:04] <didrocks> GunnarHj: just have some consistency, either use \S* for both regexp or \S+
[10:04] <seb128> I wouldn't change the existing code
[10:04] <seb128> so yeah, maybe use \S* for the new line?
[10:04] <didrocks> so that $1 is consistent between packages having GETTEXT_PACAKGE= or AC_SUBST()
[10:05] <didrocks> wfm
[10:05] <GunnarHj> seb128, didrocks: Ok, I'll upload a new patch with that change.
[10:05] <seb128> thx didrocks & GunnarHj
[10:05] <didrocks> yw!
[10:07] <didrocks> building webkit…
[10:08] <seb128> it's I cold day, I can understand :)
[10:08] <didrocks> true
[10:09] <didrocks> my laptopt isn't warm enough yet though :p
[10:09] <didrocks> and I'm sure I'll have a gjs build after the webkit one…
[10:11] <seb128> :)
[10:11] <seb128> what bug are you chassing?
[10:12] <didrocks> just building the whole stack for GNOME design to test the Shell with volume overdrive
[10:13] <didrocks> on jhbuild
[10:16] <GunnarHj> seb128: New patch uploaded. Can you sponsor please?
[10:18] <seb128> GunnarHj, yes, I guess you tried it on packages using both syntax to verify it works as it should?
[10:18] <seb128> didrocks, I see, fun
[10:19] <GunnarHj> seb128: I tested the loop via a throw-away script and a fake configure.ac. Think that's sufficient.
[10:20] <seb128> right
[10:20] <seb128> thx for fixing that
[10:20] <GunnarHj> Tested both syntaxes, of course.
[10:20] <seb128> I had it on my backlog for a long time
[10:21] <GunnarHj> seb128: You provided the real solution. I just did last bit. :)
[10:25] <seb128> :)
[10:26] <seb128> GunnarHj, oh btw I don't remember now, you said that the remmina upload/tweak worked?
[10:26] <GunnarHj> seb128: Yes, it did.
[10:27] <seb128> good :)
[10:31] <GunnarHj> seb128: I'm also looking at bug #1730793. It's a really bad one - the .po files seems to not have been imported to LP in 7 years.
[10:32] <seb128> GunnarHj, is that only some locales? do we strip the translations/does it lead to have that software not translated at all for 7 years (we would have noticed no?)?
[10:33] <GunnarHj> seb128: There are translations in LP and in the langpacks, but they are dated.
[10:34] <seb128> ah
[10:34] <seb128> let me know if you figure out anything or if you need help
[10:35] <duflu> Wonderful. I can't fix one part of mutter because another part is too bad at math to support the fix. Will have to do a separate fix...
[10:35] <duflu> Tomorrow.
[10:35] <duflu> Later...
[10:35] <seb128> night duflu
[10:35] <GunnarHj> seb128: The latest build log claims that the tarball util-linux_2.30.2-0.1ubuntu1_amd64_translations.tar.gz was created. I'd like to see what it contains, but don't remember where to look.
[10:43] <seb128> GunnarHj, wait
[10:46] <seb128> GunnarHj, doing it with lp apis worked before
[10:46] <seb128> I had that in my notes
[10:46] <seb128> $ lp-shell
[10:46] <seb128> ubuntu = lp.distributions['ubuntu']
[10:46] <seb128> uploads = ubuntu.getSeries(name_or_version='bionic').getPackageUploads(name='util-linux', version='2.30.2-0.1ubuntu1 ', custom_type='raw-translations')
[10:47] <seb128> for upload in uploads:
[10:47] <seb128>     print(upload)
[10:47] <seb128> but that doesn't work on this one
[10:49] <GunnarHj> seb128: There were actually a couple of SRU uploads after the latest bionic upload. Can it have been replaced with any of those?
[10:49] <seb128> I don't think so
[10:49] <seb128> maybe try asking cjwatson on #ubuntu-devel
[10:50] <GunnarHj> seb128: Ok.
[11:05] <GunnarHj> seb128: Did you see Colin's link at #ubuntu-devel? Anyway, I checked
[11:05] <GunnarHj> https://launchpad.net/ubuntu/bionic/+upload/16957223/+files/util-linux_2.30.2-0.1ubuntu1_amd64_translations.tar.gz
[11:06] <seb128> GunnarHj, I did
[11:06] <GunnarHj> and found that it contains the updated .po files.
[11:09] <seb128> GunnarHj, my lp-shell line works as well, I just had an extra space in the version I didn't notice :/
[11:10] <GunnarHj> seb128: Maybe there is a template confusion. There is a util-linux-locales in the tarball (the name of the package which contains the translations at Debian), but at https://translations.launchpad.net/ubuntu/bionic/+source/util-linux/+pots/util-linux/+admin the template name is util-linux.
[11:11] <GunnarHj> seb128: s/util-linux-locales/util-linux-locales folder/
[11:12] <seb128> GunnarHj, how is named the .pot?
[11:12] <GunnarHj> seb128: util-linux.pot
[11:12] <seb128> so that's the correct domain
[11:14] <GunnarHj> seb128: So why isn't it imported?
[11:15] <GunnarHj> seb128: It seems that the package builds fine.
[11:15] <seb128> GunnarHj, https://translations.launchpad.net/ubuntu/bionic/+source/util-linux states " This source package is sharing translations with Util-Linux-ng head series. "
[11:15] <seb128> that might be the issue
[11:16] <seb128> it's importing translations from https://code.launchpad.net/~vcs-imports/util-linux-ng/trunk
[11:16] <seb128> which fails to import since 2015
[11:17] <seb128> GunnarHj, one way would be to fix that import, another would be to disable the sharing and redo a source upload so files from the package get imported
[11:18] <GunnarHj> seb128: The latter seems to be easier.
[11:18] <seb128> let's do that then
[11:18] <seb128> GunnarHj, I'm giving it a try
[11:19] <GunnarHj> seb128: I just dropped the share link.
[11:19] <seb128> I did a minute ago
[11:19] <seb128> if we both did it it should be in place for sure :)
[11:19] <GunnarHj> seb128: Then it ought to be safely gone!
[11:19] <seb128> indeed
[11:19] <seb128> I'm doing an upload
[11:19] <seb128> let's see
[11:20] <GunnarHj> Great.
[11:26] <jbicha> didrocks: I just use 'sudo apt build-dep' then 'jhbuild buildone' on the components I actually need instead of trying to build everything
[11:26] <seb128> GunnarHj, hum, the pkgbinarymangler upload failed, I did a retry but there might be issues to resolve (it didn't look related to the change though so maybe just other parts changed in bionic that create issues)
[11:26] <jbicha> good morning
[11:26] <seb128> hey jbicha
[11:26] <didrocks> jbicha: I have a bunch of components to build with particular patches
[11:26] <didrocks> jbicha: so, that's why I have my jhbuildrc
[11:26] <GunnarHj> seb128: :(
[11:26] <didrocks> which only builds what is needed
[11:26] <jbicha> didrocks: but webkit??
[11:27] <didrocks> sounds like it's on gnome-shell path…
[11:28] <GunnarHj> seb128: But it's currently building.
[11:34] <jbicha> didrocks: Ubuntu doesn't needs GNOME Tweaks' Sound panel, right?
[11:34] <seb128> GunnarHj, I retried the build in case it's a transient issue
[11:35] <GunnarHj> seb128: I see.
[11:35] <seb128> GunnarHj, it failed again, https://launchpadlibrarian.net/356106245/buildlog_ubuntu-bionic-amd64.pkgbinarymangler_132_BUILDING.txt.gz
[11:35] <didrocks> jbicha: no, we have the g-c-c patch
[11:36] <didrocks> jbicha: I'm still hoping to get aday reviewing the volume thing for 3.28 and get upstream approving, but we'll see
[11:36] <jbicha> didrocks: GNOME is applying your volume patches everywhere for 3.28 except for g-c-c, right?
[11:37] <didrocks> jbicha: that's the goal, indeed
[11:37] <didrocks> jbicha: we may have also the dialogs trigger that was made by GNOME design
[11:38] <didrocks> (but won't be applied in GNOME, unfortunately)
[11:38] <GunnarHj> seb128: Saw it. Looking at debian/rules. This is over my head.
[11:39] <seb128> GunnarHj, I'm going to have a look don't worry
[11:39] <jbicha> didrocks: ha, it confuses me when GNOME comes up with patches like GNOME bug 688320 but refuses to actually apply them! :)
[11:39] <GunnarHj> seb128: Ok, great.
[11:39] <didrocks> jbicha: yes ;)
[11:53] <andyrock> Hey all
[11:54] <didrocks> morn…afternoon andyrock :)
[11:56] <GunnarHj> seb128: https://translations.launchpad.net/ubuntu/bionic/+source/util-linux/+imports :)
[11:57] <seb128> GunnarHj, good, my theory was right :)
[11:57] <seb128> GunnarHj, I approved the template, it should import in a bit/while
[12:03] <andyrock> seb128: if you didn't upload the udisks debdiffs yet maybe backport is better then upstream in the Origin dep-3 field
[12:03] <seb128> hey andyrock
[12:04] <seb128> andyrock, so can you refresh me what you were saying yesterday ... you prefer to go for the hack in gdu? no need of the udisk upload then?
[12:04] <andyrock> there is no need but we can keep it
[12:05] <andyrock> in theory you can still use this to hide devices from gdu
[12:06] <andyrock> and maybe they solve the problem of existing mounted snaps directly in snapd
[12:06] <andyrock> and we already have the code there
[12:06] <andyrock> we'll just drop the second patch
[12:11] <seb128> k, so I can upload udisks2 then?
[12:13] <seb128> andyrock, ^?
[12:13] <andyrock> yep
[12:13] <andyrock> and please check the update patch for gdu
[12:16] <seb128> andyrock, looks good, I'm going to add the bug reference to the changelog and upload
[12:16] <andyrock> kk
[12:16] <andyrock> thanks seb128
[12:16] <seb128> andyrock, thanks for all the work on that!
[12:16] <seb128> andyrock, one down, back to livepatch? ;)
[12:16] <andyrock> yeah
[12:17] <andyrock> i'm trying to understand if it's possible to run snapd inside the chroot
[12:17] <andyrock> during the installer
[12:18] <andyrock> because if we login during the live that macaroons are not going to be valid once the system is installed
[12:18] <seb128> because they have infos on the system used to log in which are going to be different?
[12:18] <seb128> that might be something worth asking mvo about
[12:20] <seb128> jbicha, do you know if there is any reason we didn't follow the 3.27 versions of glib/libsoup/gvfs and from leaf apps during the cycle so far?
[12:22] <andyrock> sooo for what I understand snapd has an intern state (that is saved in /var/lib/snapd/state.json)
[12:23] <andyrock> a "field" of its state is the authenticated users + macaroons etc
[12:25] <andyrock> every time you try to authenticate a request, snapd will validate it also checking if the userr is "already in .../stage.json")
[12:25] <seb128> andyrock, please try asking on the #snappy channel if they can help you to understand/recommend what to do, easier than spending days to trying to figure out the pieces yourself
[12:34] <jbicha> seb128: glib tends to be more Laney's responsibility
[12:34] <seb128> right, I just wondered if you had a clue
[12:34] <seb128> he uploaded to Debian experimental mid-january
[12:35] <seb128> he's off this week, I ask him next week when he's back
[12:35] <jbicha> do you want 3.27 libsoup and leaf apps uploaded to bionic now?
[12:35] <seb128> not especially "now"
[12:35] <seb128> I was just curious if we were holding on those for a reason
[12:35] <seb128> usually you do update "non risk" apps
[12:36] <seb128> like gedit, I don't expect surprises to come from it since
[12:36] <jbicha> the last few cycles I mostly waited until the .90 milestone to upload those apps, and the .90 milestone is only this week
[12:36] <seb128> since there is no active maintainer/planned features|new design
[12:36] <seb128> k
[12:36] <seb128> that makes sense
[12:36] <seb128> thx
[12:37] <jbicha> I'd upload webkit now but it's blocked on security MIR review of brotli/woff2
[12:38] <seb128> those have been bounced to the security team only recently
[12:39] <seb128> it's a bit earlier to nag them yet
[13:59] <willcooke> Trevinho, hey, could you respond to Omer's question re: fractional scaling here:  https://plus.google.com/u/0/+WillCooke/posts/dmxF68Pha2a?cfem=1
[14:00] <Trevinho> willcooke: ok
[14:00] <willcooke> thanks Trevinho
[14:33] <Saviq> Trevinho: are huge emojis in Thunderbird a known issue in bionic? https://imgur.com/a/SVpgj (thanks popey!)
[14:34] <popey> oh wow
[14:34] <Trevinho> Saviq: oh... Nope... :|
[14:34] <seb128> Saviq, is that an hidpi issue?
[14:34] <Trevinho> Saviq: pretty funny
[14:34] <popey> Once again, me throwing random Emjoi in places uncovers bugs in surprising places!
[14:34] <Trevinho> jbicha: you know anything? ^
[14:34] <popey> *emoji
[14:34]  * seb128 wonders why Saviq as to Trevinho who hasn't been working on emojis nor tb
[14:34] <Trevinho> I guess it's just thunderbird not supporting properly the font
[14:35] <Saviq> seb128: he was the last to write here, and I knew he'd be amused ;)
[14:35] <Saviq> (and know who to throw this at)
[14:35] <seb128> :)
[14:35] <Saviq> and no, no hidpi
[14:35] <seb128> k
[14:35] <Saviq> 2 screens, 1080p and 1920x1200
[14:37] <Trevinho> Saviq: give a try removing the noto font...
[14:38] <Trevinho> oh, well it will fix it for sure :-D
[14:38] <Trevinho> no need to try
[14:38] <Trevinho> but, maybe trying other emoji fonts, but to mee it looks like thunderbird isn't uspporting such fonts properly... Sooo, possibilities are various
[14:41] <seb128> GunnarHj, that util-linux upload worked well, the french translations have been updated, going from 3k untranslated to 200
[14:41] <Saviq> I'll file a bug with Thunderbird, then
[14:42] <GunnarHj> seb128: Yep, same for Danish (the OP's language) and Swedish.
[14:42] <seb128> GunnarHj, good job!
[14:43] <seb128> Saviq, upstream best if you can, I don't think we have anyone reading lp bugs/having time to work on it
[14:43] <GunnarHj> seb128: I mostly made some noise; you spotted the problem.
[14:43] <seb128> GunnarHj, result is there :)
[14:43] <GunnarHj> Right. :)
[14:44] <seb128> jbicha, is shotwell something you usually look at/plan to update?
[14:49] <jbicha> seb128: feel free to work on shotwell if you like :)
[14:49] <seb128> jbicha, that's a "no"? :)
[14:49] <jbicha> the Debian Shotwell maintainer is frustrating to work with
[14:50] <Saviq> FWIW https://bugzilla.mozilla.org/show_bug.cgi?id=1360862 was filed already, as it happens
[14:50] <jbicha> I confirmed with Shotwell upstream that 0.28 is targetted to land at the same time as GNOME 3.28
[14:50] <seb128> Saviq, good to know, thx
[14:50] <Saviq> but that's Firefox, and fixed
[14:50] <seb128> jbicha, ok, I think I'm going to start by updating to the current stable and maybe try to have a look to 0.27 later
[14:51] <jbicha> seb128: 👍
[14:51] <seb128> jbicha, thx :)
[14:53] <jbicha> oh shotwell isn't too bad now, I guess it's simple-scan that has the ignored patches right now
[14:53] <jbicha> ignored by the Debian maintainer
[14:53] <Saviq> wonder if it's fixed in more recent thunderbird
[14:55] <Saviq> hmm there isn't a more recent thunerdbird :/
[14:56] <jbicha> Thunderbird builds its official releases from the Mozilla ESR branches
[14:57] <jbicha> If you just want an easy workaround, you can try Beta: https://launchpad.net/~mozillateam/+archive/ubuntu/thunderbird-next/
[14:58] <willcooke> That bug suggested that it wouldnt be in the ESR :(
[15:13] <seb128> andyrock, I'm going to upload the xenial diff to 17.10 rather than the bionic one if that's ok for you ... what do you think?
[15:13] <andyrock> ok for me
[15:13] <andyrock> safer and easier I guess
[15:13] <seb128> andyrock, I don't think we want to SRU the udisks change/new API
[15:13] <seb128> right
[15:13] <seb128> thx
[15:14] <oSoMoN> ricotz, FYI, I just pushed a patch to the ubuntu-bionic-6.0 branch for bug #1696250
[15:15] <andyrock> mvo: I'm trying to allow store login in the installer. One possible solution would be to:
[15:15] <andyrock> 1) stop/disable snapd.service/snapd.socket (the one running in the live session)
[15:15] <andyrock> 2) manually start snapd inside the /target chroot
[15:15] <andyrock> 3) a client can now talk with the chrooted snapd through /run/snapd.socket
[15:15] <andyrock> Do you think that (1) and/or (2) could create any side effect?
[15:16] <andyrock> ops wrong channel
[15:16] <andyrock> mvo let's move to #snappy
[15:19] <ricotz> oSoMoN, ack
[15:53] <willcooke> seb128, do you know if we're likely to get GStreamer 1.14 in for Bionic?
[15:54] <willcooke> Bryan pointed to a slide deck from FOSDEM which said MP3 codecs are moving to good
[15:54] <willcooke> So if we are likely to get it, I'll need to speak to legal again
[15:55] <tjaalton> bah, bionic has older firefox than xenial :P
[15:56] <seb128> willcooke, funny than you ask, I was poking gstreamer people about that earlier and yes I think it's likely
[15:56] <seb128> willcooke, they should have their pre-version for the new stable out next week
[15:56] <seb128> tjaalton, that's usual, dev series always have toolchain etc issue and usually updates are security ones which focus on stable series
[15:58] <tjaalton> 58 fixed slow horizontal tab scroll
[15:58] <tjaalton> kinda miss that already :)
[15:58] <seb128> you can probably install the 17.10 deb
[15:59] <tjaalton> it's in -proposed, ppc64el ftbfs
[15:59] <willcooke> thanks seb128
[16:14] <ricotz> kenvandine, hi, could you take a look at https://launchpad.net/~gnome3-team/+snap/gedit or disable it if it won't work
[16:16] <kenvandine> ricotz, i plan to fix that
[16:17] <kenvandine> ricotz, sorry about that, it's the relative git submodule for libgd
[16:17] <ricotz> kenvandine, alright, I see
[16:18] <kenvandine> haven't figured out how to solve that :)
[16:18] <kenvandine> but i want those daily builds
[16:18] <ricotz> ok, maybe disable it until then
[16:18] <kenvandine> ok
[16:18] <kenvandine> i'll do that
[16:18] <kenvandine> at least the automated builds
[16:19] <ricotz> thanks, less launchpad spam ;)
[16:19] <kenvandine> i'm really good at ignoring LP spam :)
[16:19] <kenvandine> sorry about that
[16:19] <kenvandine> ricotz, disabled
[16:20] <ricotz> thanks
[16:49] <ulysses> Hey guys, I accidentally botched my radeon config file, and I'm stuck in Wayland and csan't get to the file due to its root restrictions
[16:49] <ulysses> Any advice on how to restore the file to its defaults?
[16:49] <ulysses> I know how to fix it, it's just a matter of getting to the root file
[16:50] <gQuigs> ulysses: maybe I'm missing something... but use a VT?
[16:52] <ulysses> I have but one machine and I need to fix thing so I can get back on Xorg or Mate
[16:52] <ulysses> Wayland is great and all, but it's not exactly up to par yet
[16:52] <ulysses> A vt?
[16:53] <gQuigs> ulysses: what's the file you are trying to edit and how are you currently trying?
[16:53] <ulysses> I've been trying to get into it through root nautilus
[16:53] <ulysses> but Wayland doesn't support that
[16:55] <gQuigs> ulysses: what is the filename and path?
[16:55] <gQuigs> you could just open a terminal and do sudo nano path-to-filename
[16:56] <ulysses> I'm trying to remember the directory
[16:56] <mgedmin> IIRC you can open admin:/// in nautilus (via ctrl-l), this lets you edit files as root
[16:56] <ulysses> How does one do that?
[16:57] <ulysses> Pardon my ignorance, I've been out of the game for a bit
[16:57] <mgedmin> launch nautilus, press ctrl-l, type admin:///, press Enter
[16:57] <mgedmin> you get, effectively, a root nautilus that works on wayland
[16:58] <gQuigs> that's neat
[16:58] <ulysses> Dude that's really awesome
[16:58] <ulysses> Thank you so much
[17:24] <jhodapp> kenvandine, seb128 do you know if we plan to enable macsec support for wpa_supplicant for 18.04?
[17:25] <kenvandine> i have no idea
[17:25] <jhodapp> kenvandine, who controls that package?
[17:26] <jhodapp> for classic
[17:26] <kenvandine> i think cyphermox
[17:27] <jhodapp> cyphermox, can you confirm?
[17:34] <cyphermox> not really
[17:35] <cyphermox> whomever can upload it, I think Julian was doing a merge though
[17:36] <cyphermox> yeah, merge is done
[18:26] <jhodapp> cyphermox, any idea if we'll support macsec with wpa_supplicant for 18.04?
[18:28] <cyphermox> jhodapp: there are no specific plans
[18:29] <jhodapp> cyphermox, any reason why or just from omission?
[18:29] <cyphermox> no reason, and not omission, it's just not come up
[18:30] <jhodapp> cyphermox, ok
[18:30] <cyphermox> I do not routinely make wpa changes
[18:31] <jhodapp> cyphermox, yeah, besides taking in the latest package version
[18:52] <willcooke> night all
[18:52] <cyphermox> can someone please tell me whether/how snaps are integrating with the running desktop session? I have installed the gnome-characters snap, but I can't seem to find it in the applications list, same for Telegram
[18:53] <tjaalton> installed snaps don't seem to be executable from the gnome search thing?
[18:53] <tjaalton> or am I missing some pkg
[18:53] <cyphermox> right, that's what I see
[18:53] <cyphermox> no idea if I'm missing something though ;)
[18:54] <tjaalton> oh, echo :)
[18:54] <cyphermox> indeed :)
[18:54] <tjaalton> I've got a fresh bionic and have been trying snaps for the first time today
[18:55] <tjaalton> 'snap run spotify' seems to work, but the app can't be marked 'favourite' on the sidebar
[18:56] <tjaalton> and since I installed it via 'snap install spotify', the software gui still thinks it's not installed and just gives a failure when trying to install it
[19:09] <tjaalton> kenvandine: ^ I see you've replied here that this should work https://forum.snapcraft.io/t/gnome-3-shell-snaps-integration/2678/5
[19:09] <tjaalton> kenvandine: i mean shell integration
[19:13] <kenvandine> tjaalton, yeah
[19:13] <kenvandine> tjaalton, are you not seeing icons for snaps?
[19:13] <kenvandine> tjaalton, oh, i just read back
[19:13] <kenvandine> tjaalton, cyphermox: it should just work
[19:13] <tjaalton> no, if I search, the only hit is the "link" to software center, or whatever it's called
[19:14] <kenvandine> snap info spotify
[19:14] <tjaalton> doesn't matter which snap
[19:14] <kenvandine> hmm
[19:14] <tjaalton> they all are the same
[19:15] <kenvandine> i am running 17.10 and it's fine.  I have bionic in a VM as well
[19:15] <kenvandine> and i see the icons
[19:15] <kenvandine> or it was a week ago :)
[19:15] <davmor2> showing for me in neon
[19:16]  * kenvandine updates the bionic vm
[19:16] <tjaalton> could it be locale?
[19:16] <kenvandine> doubtful
[19:16] <tjaalton> k
[19:19] <kenvandine> working fine for me in my bionic VM, doing a dist-upgrade and will reboot to confirm nothing broke
[19:22] <kenvandine> tjaalton, echo $XDG_DATA_DIRS
[19:22] <kenvandine> ?
[19:23] <jbicha> is it still necessary to log out and log back in after installing a snap for the first time?
[19:23] <kenvandine> nope
[19:26] <cyphermox> kenvandine: XDG_DATA_DIRS is empty here; new install from a few days ago
[19:26] <cyphermox> my test case is gnome-characters
[19:26] <kenvandine> that's not good
[19:27] <kenvandine> snapd provides a script to set that
[19:27] <kenvandine> snapd: /etc/X11/Xsession.d/65snappy
[19:27] <kenvandine> not there on bionic now :(
[19:27] <kenvandine> cyphermox, can you please file a bug against the snapd package?
[19:27] <cyphermox> sure.
[19:27] <kenvandine> thx
[19:28] <cyphermox> I did think I had seen telegram and vscode show up before ;)
[19:28] <tjaalton> kenvandine: shows up empty
[19:31] <cyphermox> tjaalton: bug 1747993
[19:31] <kenvandine> cyphermox, that was definitely set before
[19:31] <cyphermox> I agree, see it on my laptop
[19:32] <tjaalton> cyphermox: thanks
[19:33] <kenvandine> this is interesting, even without that file the variable should still be set
[19:33] <kenvandine> echo $XDG_SESSION_TYPE
[19:33] <kenvandine> and
[19:34] <kenvandine> echo $XDG_SESSION_DESKTOP
[19:34] <kenvandine> please
[19:36] <kenvandine> oh, it looks like snapd moved that from Xsession.d to /etc/profile.d/apps-bin-path.sh
[19:40] <tjaalton> huh
[19:41] <tjaalton> wayland
[19:41] <tjaalton> shouldn't be
[19:41] <kenvandine> tjaalton, this should work in wayland or xorg
[19:42] <kenvandine> snapd in 17.10 has scripts in both profile.d and Xsession.d for setting that
[19:42] <kenvandine> but in bionic it only has the script in profile.d
[19:42] <tjaalton> well, it works with xorg just fine
[19:43] <tjaalton> no idea why the session changed
[19:43] <kenvandine> interesting
[19:43] <kenvandine> my VM is xorg of course
[19:43] <kenvandine> so i guess i never tested this in wayland on bionic
[20:08] <tjaalton> seb128: looks like darktable snap runs fine on xorg. for some reason I was using wayland session..