[00:00] <Trevinho> jbicha: against which branch I should base?
[00:00] <jbicha> debian/master
[00:00] <Trevinho> master?
[00:00] <Trevinho> ok
[00:00] <Trevinho> having salsa there helps a lot, I already use it with bzr anyway
[00:00] <Trevinho> but still cause me to do a 2nd pass
[00:03] <Trevinho> wow, for g-s there's not even a 3.28 releas or what?
[00:03] <Trevinho> for sure there's not the branch
[00:08] <Trevinho> hmhmmh
[00:08] <Trevinho> how is it that https://gitlab.gnome.org/GNOME/gnome-shell/commits/master has not https://salsa.debian.org/gnome-team/gnome-shell/commit/6b2ebee26c7053f4c45cab05b208770c96845479 ?
[00:10] <jbicha> that's a merge commit
[00:11] <jbicha> Lan_ey briefly mentioned the upstream/latest branch in his gvfs demo
[00:12] <jbicha> git-buildpackage creates a merge commit for every upstream tarball imported
[00:13] <jbicha> and there is another merge commit to get the upstream/ branch into the debian/master branch
[00:14] <jbicha> this is the upstream 3.28.0 release https://gitlab.gnome.org/GNOME/gnome-shell/tags/3.28.0
[01:22] <jamesh> robert_ancell: looking.
[04:08] <jamesh> robert_ancell: I gave the new gnome-software branch a spin on a clean xenial VM, and it worked as intended for the libreoffice case
[04:09] <robert_ancell> jamesh, ok, good! so the tester didn't get it right? Perhaps they didn't restart G-S
[04:10] <jamesh> I'll restart the VM and give it another shot just to make sure
[04:16] <jamesh> it still launches the main libreoffice command
[04:16] <jamesh> not restarting gnome-software seems like a definite possibility
[05:04] <robert_ancell> jamesh, thanks for testing that
[05:09] <seb128> good morning desktopers
[05:23] <jibel> good morning
[05:24] <jibel> salut seb128
[05:35] <duflu> Morning seb128, jibel
[06:16] <jibel> Hi duflu
[06:17] <seb128> lut jibel, duflu, how are you?
[06:17] <duflu> seb128, going well. You?
[06:18] <seb128> I'm doing ok, the cold is a bit better and it's friday!
[06:19] <jibel> seb128, I'm good, thanks
[06:25] <didrocks> good morning
[06:54] <duflu> Hey didrocks
[07:16] <didrocks> hey duflu
[07:19] <didrocks> jamesh: didn't know about build-snaps, thanks for pointing it out!
[07:19] <jamesh> didrocks: it doesn't look like it has hit the documentation on the website yet.  I heard about it at the Snapcraft Summit
[07:20] <didrocks> you, insider! :-)
[07:21] <didrocks> I'll clean up that logic in gtk-common-themes and as well the crafted CI in communithemes
[07:21] <didrocks> thanks ;)
[07:29] <didrocks> jamesh: oh, as it's not documented, do you know if build-snaps enable you to select the channel?
[07:29] <didrocks> jamesh: remember that we build from the edge channel
[07:30] <jamesh> lets see
[07:30]  * didrocks looks into snapcraft source
[07:31] <jamesh> didrocks: looks like communitheme/edge should do it
[07:31] <jamesh> looking at install_snaps() in snapcraft/internal/repo/snaps.py
[07:31] <didrocks> I was in /usr/lib/python3/dist-packages/snapcraft/internal/errors.py:        '`build-snaps: [patchelf/latest/edge]` to the failing part in your '
[07:31] <didrocks> which seems to confirm :)
[07:32] <didrocks> jamesh: I'll give it a try, thanks for the suggestion again!
[07:36] <didrocks> (for reference for those interested, it's communitheme/latest/edge)
[07:44] <seb128> hey jamesh didrocks
[07:45] <didrocks> hey seb128!
[07:46] <didrocks> jamesh: pushed those changes with a testbuild + content inspection
[07:46] <jamesh> hi seb128
[07:46] <jamesh> didrocks: looking
[07:57] <oSoMoN> good morning desktoppers
[07:58] <didrocks> hey oSoMoN!
[08:00] <seb128> lut oSoMoN, en forme ?
[08:00] <oSoMoN> salut didrocks, seb128
[08:00] <oSoMoN> la forme, et vous?
[08:01] <oSoMoN> seb128, ça va mieux?
[08:01] <didrocks> oSoMoN: ça va :)
[08:01] <seb128> moi un peu, ça commence à passer,  c'est au tour du petit d'être bien pris et avec la fièvre en plus :/
[08:02] <Laney> hey
[08:02] <Laney> happy friday (I hope it is friday)
[08:03] <oSoMoN> seb128, bon courage, c’est pas rigolo quand c’est les petits qui sont malades :/
[08:03] <oSoMoN> Laney, I hope so too!
[08:03] <seb128> oSoMoN, 'ci!
[08:03] <seb128> happy friday Laney! how are you? ready for the w.e ;)
[08:04] <seb128> well, still some work in between but you know what I mean!
[08:04] <Laney> hey seb128
[08:04] <Laney> I caught your cold over IRC I think
[08:04] <seb128> :-(
[08:04] <seb128> get better!
[08:04] <didrocks> morning Laney
[08:04] <Laney> hey didrocks
[08:04] <Laney> how are you both?
[08:05] <didrocks> Laney: you infer that seb128 should stop talking to not contaminate us? :p
[08:05] <seb128> I'm slightly better, hopefully back on shape tomorow
[08:05] <didrocks> rather good, finally cold is almost over for me as well
[08:06] <Laney> high fives
[08:08] <willcooke> o/
[08:09] <didrocks> friday willcooke!
[08:09] <willcooke> woo
[08:09] <willcooke> feels like it's been a long week
[08:10] <oSoMoN> hey willcooke
[08:10] <oSoMoN> how was the homemade pizza?
[08:10] <seb128> hey willcooke
[08:12] <willcooke> oSoMoN, actually, quite good
[08:12] <willcooke> One sec
[08:14] <willcooke> My internet is bad again today, trying to share via Telegram but it's just sat there retrying
[08:14] <willcooke> Getting new internets on Monday, so I wonder if they are doing some work on my line
[08:14] <willcooke> Anyway, the important this, pizza..
[08:15] <seb128> right, blame it on the internet when you are using an Apple device :p
[08:15] <didrocks> The real one correct? American pizza ofc?
[08:15] <didrocks> (f r i d a y)
[08:15] <willcooke> I made the sauce earlier in the week for pasta, and then left it to reduce on the hob all day yesterday.  Has a little sharp, but worked really well on the pizza.  Made the dough at lunchtime, let it rise, knocked it back and put in the fridge wrapped in film.  Where it continuted to expand and pushed everything off the shelf
[08:16] <willcooke> Put the oven on as hot as it would go and put a stone thing in there, and yeah, 10 mins or so and it was really tasty
[08:16] <didrocks> be careful when you put it in the fridge, we left some home made pizza pasta a week once, and didn't notice it was really expanding like crazy
[08:16] <willcooke> yeah!  I thought the cold would stop it, but no
[08:17] <didrocks> only freeze does :)
[08:17] <didrocks> freezer*
[08:17] <didrocks> shouldn't have used the team "freezer" with seb128's cold :p
[08:17] <willcooke> I had loads of dough left, so I've frozen that.  Wonder if it will work? Will I still be able to eat it once it's defrosted
[08:18] <didrocks> willcooke: it does, this is what we generally do (and keep it frozen for a couple of months, if not more)
[08:18] <willcooke> cool!
[08:18] <willcooke> that will make it easier next time
[08:18] <didrocks> yeah, we do like 4-6 parts of dough, and then, it's easy to do a quick pizza in the week-end :)
[08:18] <willcooke> \o/
[08:19] <duflu> oh, morning oSoMoN, Laney, willcooke
[08:19] <willcooke> ahoy duflu
[08:20] <oSoMoN> hey duflu
[08:43] <didrocks> hum, snapcraft --help doesn't list all options… weird for things that are supposed to be autogenerated
[09:50] <willcooke> Removing the ubuntu-wallpapers package stops the desktop from starting
[09:51] <willcooke> hm, maybe that's not what caused it
[09:51] <willcooke> bah, I've broken this machine now.  Will just reinstall, and see if I can break it again
[10:00] <willcooke> Laney, typo in this commit message?  https://bugs.launchpad.net/ubuntu/+source/ubuntu-wallpapers/+bug/1762722/comments/3  (says 17.10) or am I missing somthing?
[10:00] <ubot5`> Ubuntu bug 1762722 in ubuntu-wallpapers (Ubuntu) "Ubuntu 18.04 LTS Free Culture Showcase community wallpapers" [Undecided,Fix released]
[10:03] <Laney> yes
[10:03] <Laney> it doesn't do anything though
[10:05] <Laney> https://bazaar.launchpad.net/~ubuntu-art-pkg/ubuntu-wallpapers/ubuntu/revision/243
[10:06] <willcooke> thx Laney
[10:07] <Mirv> typo in "typp", unless intended :)
[10:08] <Laney> it was a little joke :(
[10:08] <Mirv> I thought it might be that deep
[10:08]  * Laney feels scrutinised
[10:08] <Laney> thanks guys :P
[10:12]  * willcooke is newslettering. Going through the notes from the meeting for news fodder
[10:20] <oSoMoN> willcooke, libreoffice 6.0.3 is in bionic, that's new since the meeting
[10:26] <willcooke> thanks oSoMoN
[11:13] <Laney> seb128: did you make any progress on that orca thing?
[12:04] <seb128> Laney, I didn't get the "drop priviledge" things working, I'm pondering writing a simple 10 lines python script that does the watch/start (in fact I had it since I made a standalone version to test) and install that, it just means another process using memory which is suboptimal
[12:05] <seb128> Laney, the callback is never called, even if it has been registered after a drop of privileges
[12:31] <Laney> seb128: it's weird, I just looked a bit and if you make it set the value right after connecting the signal the callback is called
[12:35] <GunnarHj> Laney: Do we want it to be possible to set any value via the --domain option?
[12:35] <Laney> any value?
[12:36] <GunnarHj> Laney: Yeah, it's supposed to be the correct domain, people make mistakes.
[12:37] <Laney> I suppose warn?
[12:37] <Laney> I think we only have good detection for meson
[12:39] <GunnarHj> Laney: In case of meson, is it possible that the correct domain is not detected via introspect? In case of other packages, where dh_translations fails to get the domain by parsing, I can't see what a warning would be based on.
[12:41] <seb128> the meson introspection just rely on conventions no?
[12:41] <seb128> technically you can call the target as you want, they is no way to query a "type"? like those are not flagged as "translations update"?
[12:42] <Laney> it's not really right to call it a convention
[12:42] <Laney> more an implementation detail, but it's probably part of the interface now so unlikely to change
[12:42] <Laney> the thing is generated from the domain you give to the i18n call
[12:42] <GunnarHj> If you set a domain which introspect hasn't identified, I take it that the ninja call for building POT will fail anyway.
[12:43] <seb128> right, but you can't tell that because the target exists then it is a translations one
[12:43] <Laney> You can tell /if/ the target the user supplied exists
[12:44] <seb128> right
[12:44] <Laney> If we're going to call ninja <target> and we can tell it doesn't exist
[12:44] <Laney> could error with a more friendly message
[12:44] <seb128> makes sense
[12:45] <Laney> GunnarHj: you're talking about upgrading the warning in your patch to an error?
[12:47] <GunnarHj> No, I'm not ( even if it would be tempting ;) ). I suppose we can basically have it as is (checking if the domain exists) for Meson, and still make it possible to use --domain for other build systems without any check.
[12:48] <Laney> OK I'm not sure what you're asking then, sorry
[12:48] <Laney> I don't see how we can check for non-meson things unless there's a similar interface for (say) CMake
[12:48] <Laney> If we can tell it's going to error out in a second anyway then it's potentially a good idea to do it earlier with a nicer message
[12:51] <GunnarHj> Laney: Maybe I jumped at conclusions. So then my understanding is: Make it possible to use --domain everywhere, and warn / ignore when possible (i.e. for Meson packages). Is that what we should do?
[12:52] <Laney> GunnarHj: Right, except I'm saying (and I thought this was what you were asking for) that erroring for a bad --domain where you can tell it's bad is not on the face of it an awful idea.
[12:52] <Laney> I don't have a super firm opinion on that though.
[12:53] <GunnarHj> Laney: I'd love to trigger a fatal error in those cases and make package maintainers take more responsibility for translations. :)
[12:54] <Laney> If it's only for explicit --domain then it shouldn't break anything that already exists
[12:55] <GunnarHj> Laney: Not sure what you meant by your latest comment,.
[12:56] <GunnarHj> Laney: Or maybe I do. You argue for triggering a fatal error.
[12:59] <GunnarHj> Laney: And that makes sense. If we add a new option, and people make mistakes when making use of it, why wouldn't we tell the loudly if possible?
[13:00] <Laney> That's what I'm saying
[13:01] <GunnarHj> Laney: Ok. Then I just wait for a final decision before starting to work with a new patch. :)
[13:03] <Laney> GunnarHj: On this point? I'd say feel free if you agree it's right.
[13:05] <GunnarHj> Laney: I do. Just a detail about the syntax in a dh_* program for doing that. would it be 'error "..."' instead of 'warning "..."' or should we say exit 1 explicitly?
[13:06] <Laney> I'm not sure if error exits on its own - try it :P
[13:07] <GunnarHj> Ok.
[13:08] <seb128> Laney, you are debugging the ubiquity/signal issue more?
[13:09] <seb128> or do you have any idea why the callback stop working later? how did you test it?
[13:09] <Laney> seb128: I just added a call to change a value in the schema right after you connect to the signal, and it gets called then
[13:10] <Laney> it's probably some uid thing
[13:10] <Laney> there's a message in the debug log about not starting a message bus when setuid
[13:11] <Laney> (/var/log/installer/debug)
[13:11] <Laney> got to go have lunch now, back in a bit
[13:12] <seb128> Laney, enjoy! and yeah, if you do it from the code the process "context" might be the same as ubiquity when it might not be from the gsd process
[13:18] <didrocks> enjoy Laney ;)
[13:18] <kenvandine> dang... i just missed Laney  :)
[13:20] <kenvandine> i'm working on creating preinstalled disk images for ubuntu-desktop with livecd-rootfs
[13:20] <kenvandine> i'm assuming i should be using live-build to create them?
[13:21] <kenvandine> i've added a SUBPROJECT of desktop-preinstalled to build IMAGEFORMAT=ext4
[13:21] <kenvandine> and i'm getting an ext4 image that i don't think has a bootloader
[13:21] <kenvandine> just want to make sure i'm actually using the right tool before i go to far :)
[13:21] <kenvandine> seb128, didrocks ^^ either of you know?
[13:22] <seb128> kenvandine, it has been a while I didn't touch to those projects and I don't remember the details, sorry
[13:22] <kenvandine> i guess didrocks did that recently for minimal though :)
[13:23] <ogra_> typically live-build only builds rootfses (that might have changed in the times of could though, but for a decade it only did that)
[13:23] <ogra_> making bootable images out of that used to be a task of debian-cd
[13:23] <kenvandine> ogra_, yeah... i couldn't find anything else documented though
[13:23] <seb128> kenvandine, the minimal work is not an iso, it's just an ubiquity change
[13:24] <kenvandine> oh, there is some stuff in livecd-rootfs that adds packages to an exclude list, maybe that's for other flavors or something
[13:24] <kenvandine> ogra_, does debian-cd make bootable disk images?  not just isos?
[13:24] <seb128> kenvandine, like desktop-next at the time was added with that change https://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/887
[13:24] <jbicha> kenvandine: building isos is a huge pain. It's strong incentive for Ubuntu flavors to become official so devs don't have to do it any more
[13:25] <seb128> k, need to step out for a bit
[13:25] <kenvandine> jbicha, yeah, i don't want an iso
[13:25] <seb128> bbl
[13:25] <kenvandine> i want a disk image
[13:25] <kenvandine> bye seb128!
[13:25] <ogra_> kenvandine, it used to ... i havent touched it in ages though ... the whole setup might have changed (UbuntuCore FTW :) )
[13:25] <kenvandine> ogra_, cool!
[13:30] <didrocks> yeah, I didn't build it for quite a while, I used to unsquashfs, then modify the chroot, then resquash
[13:30] <didrocks> it was the easiest ;)
[13:30] <didrocks> kenvandine: btw, here we go: https://github.com/ubuntu/communitheme-snap-helpers/pull/4#issuecomment-381135053
[13:30] <ubot5-ng> ubuntu bug (Pull request) 4 in communitheme-snap-helpers "Enable releasing as well gtk-common-themes with latest communitheme" (comments: 4) [Open]
[13:30] <didrocks> see the addition of "You may want to download as well gtk-common-themes snap from edge/communitheme-snap-helpers-pr4 channel to test your snaps with those changes.
[13:30] <didrocks> "
[13:31] <didrocks> so, basically, every communitheme (on any of the 5 projects) commit in master will now push communitheme/edge and gtk-common-themes/edge
[13:31] <kenvandine> didrocks, cool, thx
[13:31] <didrocks> and any PR will release communitheme/edge/pr-name and gtk-common-themes/edge/pr-name
[13:31] <didrocks> (and any further push to PR will do that as well ;))
[13:31] <didrocks> tokens updated in all project, time to merge!
[13:36] <kenvandine> oh... maybe i should be using ubuntu-image instead of live-build directly :)
[13:36]  * kenvandine peels the onion
[13:37] <didrocks> kenvandine: do you want to test some changes or do something official?
[13:38] <didrocks> kenvandine: if it's just for testing something, I would really say unsquashfs/resquash it
[13:38] <kenvandine> for image creation?
[13:38] <didrocks> yep
[13:38] <kenvandine> no, this is for microsoft's hyper-v gallery
[13:38] <kenvandine> going to be official
[13:39] <didrocks> yeah, so you may want something a little bit more official then ;)
[13:39] <didrocks>                  edge                                0.1        3
[13:39] <didrocks> \o/
[13:39] <didrocks> (for gtk-common-themes)
[13:52] <didrocks> kenvandine: hope that makes sense: https://forum.snapcraft.io/t/snap-application-and-snap-themes/4946/9?u=didrocks
[14:19] <Laney> seb128: don't understand what gsd has to do with it at this point, the callback is in ubiquity too.
[14:19] <Laney> kenvandine: did you get my email?
[14:19] <Laney> sounds like you reinvented a bit what I sent you in that?
[14:19] <kenvandine> Laney, no... i didn't
[14:20] <Laney> Date: Wed, 4 Apr 2018 18:42:01 +0100
[14:20] <Laney> From: Iain Lane <iain.lane@canonical.com>
[14:20] <Laney> To: ken.vandine@canonical.com
[14:20] <Laney> Subject: livefs-preinstalled notes
[14:21] <kenvandine> weird... i have no emails from you on that day
[14:22] <Laney> Apr  4 18:42:03 cripps postfix/smtp[24104]: D9B0C206B8: to=<ken.vandine@canonical.com>, relay=mx.canonical.com[91.189.95.10]:25, delay=0.08, delays=0.01/0.02/0.04/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as E94AC1A2968)
[14:22] <kenvandine> dang... can you resend it?
[14:22] <Laney> sure
[14:22] <kenvandine> maybe i accidentally deleted it or something
[14:23] <didrocks> or… Laney was *filtered* out!!!
[14:23] <kenvandine> lol
[14:23] <kenvandine> i have other mails from him, on different days
[14:23] <didrocks> probably spam then! :p
[14:24] <didrocks> doko: any news on the ubuntu-report MIR now that the different comments were addressed?
[14:26] <kenvandine> Laney, thx
[14:27] <kenvandine> Laney, that's my exact diff :)
[14:28] <Laney> good sign
[14:28] <kenvandine> Laney, ok, i did that and i built it with live-build and got a .ext4 file
[14:28] <kenvandine> but it's not bootable, so was thinking it didn't install a bootloader or something
[14:29] <kenvandine> the contents of the file look sane, so i think it's pretty close
[14:29] <kenvandine> now i see there is ubuntu-image that seems to work some nice magic
[14:29] <Laney> I think you can use qemu-img on those
[14:29] <kenvandine> did that
[14:29] <Laney> but it was too big so I didn't actually download the artifact that LP made
[14:30] <kenvandine> ubuntu-image wraps live-build and then works some magic, i think
[14:30] <Laney> never used it
[14:30] <ricotz> hey desktopers
[14:30] <kenvandine> but now live-build isn't working... held packages
[14:30] <kenvandine> The following packages have unmet dependencies:
[14:30] <kenvandine>  rsyslog : Depends: libfastjson4 (>= 0.99.7) but it is not installable
[14:30] <kenvandine> so i guess bionic might be a little broken today?
[14:32] <jbicha> seb128: I don't know if you were subscribed to this MR but it was just merged
[14:32] <jbicha> https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/22
[14:33] <ubot5-ng> GNOME bug (Merge request) 22 in gnome-control-center "thunderbolt: new panel for device management" (comments: 29) [Merged]
[14:33] <Laney> looks ok here
[14:34] <jbicha> kenvandine: it sounds like it's building from bionic-proposed? rsyslog is stuck in -proposed because of bug 1746327
[14:34] <ubot5`> bug 1746327 in libfastjson (Ubuntu) "[MIR] libfastjson" [High,New] https://launchpad.net/bugs/1746327
[14:35] <ricotz> is there a chance for appstream 0.12.0-3 and appstream-generator 0.7.1-3 being synced?
[14:35] <Laney> first one is done
[14:35] <Laney> why do you care about the generator?
[14:36] <ricotz> for 3rd party reasons, I guess they should go together
[14:38] <ricotz> ah didn't see the appstream update yet, looks like the amd64 package publications is stuck
[14:38] <kenvandine> jbicha, should be
[14:38] <kenvandine> COMMAND FAILED: ['sudo', 'PROJECT=ubuntu', 'SUITE=bionic', 'ARCH=amd64', 'SUBPROJECT=desktop-preinstalled', 'PROPOSED=False', 'IMAGEFORMAT=none', 'lb', 'build']
[14:38] <kenvandine> shouldn't rather :)
[14:38] <didrocks> kenvandine: do you mind pointing robert to bug #1763736, I guess it worths a look to see what is different between 18.04 and 16.04
[14:38] <ubot5`> bug 1763736 in gnome-software (Ubuntu) "communitheme snap not present in gnome software on bionic, but it is on 16.04" [Undecided,New] https://launchpad.net/bugs/1763736
[14:38] <ricotz> Laney, it needs to be new'ed ;)
[14:38] <jbicha> kenvandine: nope, you're not tricking me into building Ubuntu images ;)
[14:39] <didrocks> (I tagged it so that we remember)
[14:39] <didrocks> and maybe it's not the only case triggering this
[14:39] <kenvandine> didrocks, sure
[14:39] <didrocks> thx!
[15:11] <seb128> jbicha, yeah, I'm talking regularly to gicmo as said, but you seem pretty interested by that panel/feature, do you want to take over? there is no need to have several persons doing the same tracking/upstream relation work there
[15:11] <jbicha> seb128: do you have thunderbolt?
[15:12] <seb128> jbicha, not at the moment no, do you?
[15:12] <jbicha> my computer might support it but I don't have any peripherals so "no"
[15:12] <seb128> jbicha, I just know gicmo (upstream) from long time and I've good work relations with him
[15:13] <jbicha> I'm happy if you keep handling the thunderbolt work. I was just letting you know it was merged :)
[15:14] <seb128> thx
[15:14] <seb128> I'm going to look to get that in .1
[15:14] <jbicha> ok
[15:14] <seb128> it feel like it's late to try to get a ffe/in .0 now
[15:14] <seb128> like we wouldn't get translations and such and it didn't get any testing yet
[15:15] <seb128> neither upstream nor in other distro
[15:15] <jbicha> that makes sense
[15:15] <seb128> Laney, my understand was that gsd-media-keys is what catch the keybinding and toggle the gsettings key to enable the screen-reader
[15:15] <seb128> now I'm unsure how to test
[15:16] <seb128> since we don't have the indicator atm I've been testing using the keybinding
[15:16] <seb128> the gsettings key get correctly toggle in response so that side of things seem to work
[15:16] <Laney> seb128: oh, well I was using gsettings from a terminal to set the key on or off
[15:16] <seb128> ah
[15:16] <Laney> and watching if the callback gets called
[15:16] <Laney> which it is not
[15:16] <seb128> using what user?
[15:16] <Laney> ubuntu one
[15:17] <seb128> k, so either something doesn't work in the drop priviledge world or it's not listening on the same bus or something
[15:17] <seb128> do you debug that?
[15:17] <Trevinho> morning
[15:17] <seb128> hey Trevinho
[15:17] <didrocks> hey Trevinho
[15:18] <Laney> not right now, looking at some appstream-generator problem with ximio_n in another channel atm
[15:18] <Laney> I did print the uid and euid and they were right though
[15:18] <seb128> k
[15:19] <seb128> day is a bit cahotic here so I'm probably not going to debug much before monday, especially I'm unsure how to go about debugging that
[15:21] <seb128> andyrock, good to see they fixed that gtk segfault :)
[15:22] <seb128> andyrock, and please stop putting cards in done when the fix is upstream and not in Ubuntu yet :p
[15:23] <andyrock> ops sorry about that
[15:24] <seb128> no worry :)
[15:25] <seb128> Trevinho, btw "gnome-shell migration list" got recent tweaks for gnome-tweaks and evolution name changes, you might need to catch up with unity (unsure if you did already in your first version)
[15:33] <jbicha> seb128: our compatibility .desktop files have enough bugs I'd really like to drop them now if we could get away with it :|
[15:35] <seb128> jbicha, what sort of bugs?
[15:35] <seb128> too late now for bionic though
[15:35] <seb128> I had a card for it and tried to push for that at the start of the cycle
[15:36] <seb128> but d_idrocks though it was important and L_aney that we could handle things better iirc, anyway we never got consensus
[15:36] <seb128> at this point we have migrations for GNOME and Unity so we can probably drop them next cycle
[15:36] <jbicha> the compatibility .desktop is set the wrong direction
[15:37] <jbicha> the new file has NoDisplay=True when it should be the old one that does
[15:37] <seb128> is that a specific one?
[15:37] <jbicha> it's our script that's broken
[15:37] <seb128> or did we do that for each? and if so do you remember why and what issue does it create?
[15:37] <jbicha> yes
[15:37] <jbicha> the issue is that we're not really converting people to the new .desktop
[15:38] <seb128> (I need to step out for a bit but I'm going to read backlog/comment again once I'm back)
[15:38] <seb128> isn't gnome-shell doing that for us?
[15:38] <jbicha> maybe, but it's still wrong for other desktops
[15:38] <seb128> https://sources.debian.org/src/gnome-shell/3.28.0-1/js/ui/appFavorites.js/?hl=42#L10
[15:38] <jbicha> and other desktops was the reason we were still keeping the old .desktop's, right?
[15:38] <seb128> well nothing we do to the .desktop is going to migrate configs for users
[15:39] <seb128> well, main reason was unity
[15:39] <jbicha> 2. right-click an app (like Text Editor) in the Activities Overview and click Show Details. It doesn't go to the right place (although GNOME Software is admittedly smarter there than it was in zesty or artful)
[15:39] <seb128> but now that has a conversion in bionic
[15:39] <seb128> so we can drop in bionic+1
[15:39] <seb128> the desktop we care about are GNOME and Unity
[15:39] <jbicha> "Open with Other Application" shows duplicate apps
[15:40] <seb128> other desktops are welcome to fix things
[15:40] <seb128> but we are not going to block on them
[15:40] <seb128> right
[15:40] <jbicha> my #2 is pointing out that we're not actually doing the conversion in bionic anyway…
[15:40] <seb128> I patched g-c-c for a duplicate issue
[15:40] <seb128> we should probably include a workaround patch in gtk for bionic
[15:40] <seb128> until we drop them next cycle
[15:40] <jbicha> the NoDisplay is telling desktops besides GNOME and Unity to use the old names
[15:41] <seb128> that topic is complicated, I don't remember the details of the previous discussions
[15:41] <jbicha> I mean I understand if our final answer is "not for bionic" since things are really late. I'm just pointing out that there are unnecessary bugs here because of the compatibility .desktop files
[15:41] <Laney> If you have a configuration which specifies the old name
[15:41] <seb128> but I was in favor of dropping them and d_idrocks (and maybe L_aney) agreed against iirc
[15:41] <Laney> And it gets NoDisplay in a new version
[15:41] <jbicha> and it's incomplete, we don't have compatibility .desktops for most of the universe renames anyway
[15:41] <Laney> Then you have a bad time.
[15:41] <Laney> That's why it is the way round it is.
[15:42] <seb128> right
[15:42] <Laney> I was in favour of dropping them.
[15:43] <Laney> I proposed a solution where you made a centralised mapping of names somewhere on the system
[15:43] <seb128> so it was d_idrocks who argue that it's small polish like respecting user config on upgrades that make a difference
[15:43] <Laney> and desktop environments could write their own way to migrate, consuming that list
[15:43]  * didrocks argues it's not "small" :)
[15:43] <Laney> I don't exactly remember why we didn't do anything like that
[15:43] <seb128> lack of resources to allocate to that work I guess
[15:43] <didrocks> but yeah, we should handle a one shot migration, maybe with session-migration
[15:43] <didrocks> before the DE starts
[15:43] <didrocks> (and so unity drops unknown desktop files)
[15:43] <seb128> anyway it's too late now for bionic
[15:44] <Laney> There was this unity problem
[15:44] <Laney> We had a card to get that fixed, and I thought it got assigned
[15:44] <jbicha> this is what was done in Unity this week: https://bazaar.launchpad.net/~unity-team/unity/trunk/view/head:/tools/migration-scripts/07_unity_migrate_gnome_favorites
[15:44] <Laney> but maybe not
[15:44] <seb128> jbicha, please report the issues or give me the bug numbers, we can at least patch the duplicates out of "open with" in gtk
[15:44] <didrocks> Laney: yeah, but IIRC, it was a lot of work to fix it
[15:44] <didrocks> if we do it all in session-migration, which forces us to have another list though, it's done before Unity starts
[15:44] <didrocks> and so, we should be good even without the Unity fix
[15:44] <Laney> ok, but it got assigned at the start of this cycle
[15:44] <seb128> Laney, unity is fixed in bionic
[15:44] <seb128> so we can drop them next cycle
[15:44] <didrocks> oh, it's fixed?
[15:44] <Laney> it is?
[15:45] <Laney> I thought the point was to fix it in xenial
[15:45] <didrocks> last time I heard about it was "not going to do it, too complex"é
[15:45] <seb128> well, unity does the same as gnome-shell in bionic now
[15:45] <didrocks> sweet
[15:45] <seb128> so if we keep the old files we end up with them rewritten to the new one
[15:45] <jbicha> seb128: my old bugs were bug 1606901 and bug 1623748
[15:45] <ubot5`> bug 1606901 in nautilus (Ubuntu Xenial) "Clicking "Show details" in AO for Nautilus produces "Could not find 'nautilus.desktop'" error from gnome-software" [Low,Triaged] https://launchpad.net/bugs/1606901
[15:45] <ubot5`> bug 1623748 in gnome-pkg-tools (Ubuntu) "Use non-compatibility .desktop files by default" [Undecided,Confirmed] https://launchpad.net/bugs/1623748
[15:45] <Laney> ok, well the topic got away from me then
[15:45] <seb128> which means unity users on bionic are going to have the new names in use
[15:45] <seb128> so we can drop the compat in +1
[15:45] <didrocks> sounds like a plan
[15:46] <Laney> the problem was that as soon as you upgraded and a desktop file went away
[15:46] <Laney> it was purged from your launcher
[15:46] <Laney> so you could not migrate
[15:46] <didrocks> yep, that was the issue
[15:46] <didrocks> but with a migration list, that's fine
[15:46] <Laney> no it's not, not if it's removed from the launcher
[15:46] <Laney> then you don't know what to rewrite
[15:47] <didrocks> if unity fixes it, I think they are doing it when they load the gsettings list
[15:47] <didrocks> so before matching/checking file existing state
[15:48] <didrocks> Trevinho/andyrock would know
[15:53] <Trevinho> seb128: yeah, I noticed that (migration list), I have in my list
[15:53] <Trevinho> Yeah, the migration happens in a script, so it runs just after the session starts
[15:53] <Trevinho> didrocks: ^
[15:54] <didrocks> Trevinho: ah, so using session-migration?
[15:59] <jbicha> seb128: I filed LP: #1763763
[15:59] <ubot5`> Launchpad bug 1763763 in nautilus (Ubuntu) "Duplicate apps in Open With Other Application" [Undecided,New] https://launchpad.net/bugs/1763763
[16:24] <Trevinho> didrocks: yes, your kid :)
[16:24] <didrocks> :p
[16:24]  * didrocks waves good evening and good week-end
[16:26] <seb128> jbicha, thx
[16:26] <seb128> Laney, right, so in bionic unity migrates the .desktop to the new name so the bionic configs are never going to include the compat names so in +1 we are fine to drop them, no?
[16:29] <Laney> seb128: Upgrade from Xenial to Bionic while you are logged in. If that bug is still present, as the upgrade progresses your favourites get removed.
[16:30] <Laney> So it doesn't matter if they are migrated when you next log in, since the entries are already gone.
[16:30] <seb128> Laney, right, which is why we don't drop the old names in bionic but in +1
[16:30] <Laney> In any event Unity isn't supported then
[16:30] <Laney> So we could jsut do nothing at all and this problem resolves itself.
[16:30] <seb128> the only issue would be people upgrading from xenial to bionic +1 through bionic without login in
[16:31] <seb128> right
[16:31] <seb128> I don't understand why didrocks cares so much about that :/
[16:31] <seb128> we should have dropped those compat files in bionic
[16:31] <Laney> No, we'd have had to fix that bug then and apparently we didn't want to
[16:31] <seb128> Unity to GNOME is enough of a change, that's not a potential tiny config change due to launcher renames that would have been the end of the world
[16:32] <Laney> maybe, we could have made that decision
[16:32] <seb128> well, as you said Unity is no supported
[16:32] <Laney> It's supported in Xenial.
[16:32] <Laney> For C there is no supported upgrade path from Unity.
[16:32] <seb128> true
[16:32] <seb128> anyway we are where we are now
[16:32] <seb128> too late to remove them
[16:33] <seb128> let's drop them next cycle
[16:34] <seb128> jbicha, the "show in software" thing is really minor and not likely to happen since g-s migrates the config
[16:34] <seb128> and we can fix the dup entry one
[16:34] <jbicha> seb128: the show in Software bug still exists but it's a lot more minor now because GNOME Software works better than it used to
[16:35] <seb128> I don't understand why it exist
[16:35] <seb128> isn't g-s migrating the launcher items?
[16:35] <seb128> so it should query with the correct .desktop name no?
[16:37] <jbicha> I guess it doesn't. The results look like  gnome-software --details=gedit.desktop  instead of  gnome-software --details=org.gnome.gedit.desktop
[16:38] <Laney> the bionic solution does rely on us having made those compat desktop files, and I don't think we've been particularly comprehensive in doing that
[16:39] <seb128> you mean?
[16:39] <jbicha> but gnome-shell does save org.gnome.gedit.desktop to favorites correctly
[16:39] <Laney> have we created those compat files for every package which renamed its desktop file?
[16:39] <seb128> Laney, https://sources.debian.org/src/gnome-shell/3.28.0-1/js/ui/appFavorites.js/?hl=42#L9 is the bionic solution, at least for our main session
[16:40] <Laney> talking about the unity migration
[16:40] <seb128> https://bazaar.launchpad.net/~unity-team/unity/trunk/view/head:/tools/migration-scripts/07_unity_migrate_gnome_favorites is the same
[16:40] <seb128> no?
[16:40] <Laney> yes
[16:40] <Laney> but if the old desktop file stops existing
[16:40] <Laney> this doesn't work
[16:40] <seb128> ah right
[16:40] <seb128> indeed
[16:40] <seb128> we only covered some of the most likely to be important/in user configs
[16:41] <seb128> like gedit, nautilus
[16:41] <jbicha> I never added compatibility .desktop's because we all know I didn't like them so universe apps in particular don't have them
[16:42] <Laney> oh well
[16:43] <Laney> this is a description of the situation, doubt anything is going to change
[16:43] <Laney> unless we get this prioritised for upgrades before .1
[16:44] <jbicha> (oh and it created a lot of extra diff with Debian, but that's not much of a problem if we're dropping them in Chaotic Chameleon)
[17:10] <seb128> k, enough for this week, more orca debugging on monday
[17:10] <seb128> have a good w.e desktopers!
[17:28] <Trevinho> I need to add a migration script to u-s-d which is not using dh though, how can I do that?
[17:28] <Trevinho> Laney: maybe? :)
[17:30] <Laney> what does dh have to do with migration scripts anyway?
[17:30] <Laney> just add a line in the .install file listing it
[17:30] <Laney> and maybe depend on session-migration too
[17:31] <Trevinho> Laney: for using dh-migraitons I mean
[17:31] <Trevinho> as that will parse a .migration file and do all the things
[17:32] <Laney> just do what I said, or maybe you could call dh_migrations from the build
[17:32] <Trevinho> Laney: yeah, that was I wanted to do
[17:32] <Trevinho> but at what level?
[17:32] <Trevinho> install?
[17:32] <Laney> this is going to be more effort than doing it manually
[17:33] <Laney> binary-post-install/package:: maybe
[17:39] <willcooke> night all
[17:39] <Trevinho> Laney: ok, i see if it goes well otherwise I'm going with install
[17:43] <Trevinho> Laney: yeah, worked quickly, thanks
[18:09] <jbicha> Trevinho: I see that fmuellener has tagged mutter 3.28.1
[18:10] <jbicha> he does this entertaining thing where he tags releases several hours before he actually publishes the tarballs
[18:15] <Trevinho> jbicha: mh I see
[18:15] <Trevinho> jbicha: so feel free to update salsa so I will work on latest
[18:16] <jbicha> I need to wait for the tarball to import it into salsa
[18:17] <Trevinho> k
[18:20] <jbicha> the most plausible reason to wait hours is if you're doing testing of the tarballs, but if you're doing testing, shouldn't you wait to push the tag?
[18:47] <Trevinho> Laney: still here?
[18:53] <Trevinho> well, in case... https://code.launchpad.net/~3v1n0/unity-settings-daemon/use-and-migrate-unity-monitors-xml/+merge/343230 if not, have nice weekend EU, i'm leaving for lunch.
[19:34] <Trevinho> jbicha: maybe you can review that? ^
[19:49] <jbicha> Trevinho: I'm hoping someone else could take a look at that one since it's a bit outside my expertise, sorry
[19:55] <oSoMoN> kenvandine, https://forum.snapcraft.io/t/call-for-testing-chromium-65-0-3325-146/4390/20 looks like the issue you were seeing 2 days ago I think
[19:55] <oSoMoN> I'm looking into it
[19:55] <oSoMoN> adding libsecret to the snap to see if that makes things better
[19:56] <Trevinho> jbicha: ok, ok.. i'll wait next week
[19:56] <kenvandine> oSoMoN, hmm
[19:56] <kenvandine> oSoMoN, i don't even remember now :)
[19:58] <oSoMoN> kenvandine, the chromium snap not starting any longer, I can reliably reproduce the issue after logging in to a google account
[19:58] <kenvandine> i don't remember what i did now though
[19:58] <kenvandine> maybe started over?
[20:00] <oSoMoN> so if I add libsecret to the snap and do "snap connect chromium:password-manager-service" then it starts
[21:22] <oSoMoN> got a workaround for that issue that seems to work reliably, this will require some more testing on Monday
[21:22] <oSoMoN> time for some rest
[21:22] <oSoMoN> have a good week-end everyone!
[23:30] <GunnarHj> Hi jbicha, how would I do to see the result of that apport hook?
[23:35] <jbicha> sorry, I should have mentioned that in the bug. Just run   ubuntu-bug yelp
[23:43] <GunnarHj> Ah, thanks. Yeah, I think the proper place to point the users is https://www.ubuntu.com/support/community-support .
[23:46] <GunnarHj> jbicha: Btw, I tried ubuntu-bug ubuntu-docs first, and was told that ubuntu-docs is not an official Ubuntu package. (Not that I would like to see apport data on ubuntu-docs bugs, but still...)
[23:47] <jbicha> ubutnu-bug ubuntu-docs works here
[23:48] <jbicha> do you have a different version installed?
[23:48] <jbicha> it doesn't have an apport hook so it would just open a LP bug
[23:48] <GunnarHj> I have. :) I'm on artful but have the bionic version of ubuntu-docs... Thanks.
[23:50] <GunnarHj> jbicha: As regards your latest dh_translations suggestion, wouldn't that be an enhancement compared to what the program has done up to now?
[23:50] <jbicha> the --domain stuff is an enhancement too
[23:51] <jbicha> running the help-*-pot target just brings us up to where we are with autotools I think
[23:52] <GunnarHj> It is, but the purpose is to fix regressions due to Meson. Not saying it would be a bad idea, just that dh_translations always has figured out *the* domain and built one POT.
[23:53] <jbicha> well something is building the help .pot for gnome-mahjongg
[23:54] <GunnarHj> I'm going to look at the packages you mention and comment on the bug report. But that will happen tomorrow.
[23:57] <jbicha> I think it's dh_translations that builds the help .pot for gnome-mahjongg because I just built on Debian and it wasn't built there
[23:57] <jbicha> have a good night :)
[23:58] <GunnarHj> You too (whenever the night comes for you).