[00:40] <kenvandine> jamesh: do you think the breeze MR is ready to be merged?
[00:41] <kenvandine> jamesh: i think it looks fine and i did some testing today, didn't see any regressions
[00:41] <jamesh> kenvandine: I suppose we could merge it and do the icon theme later.  It shouldn't hurt to have one without the other
[00:41] <kenvandine> jamesh: i need to push out an update soon for some USNs anyway, would like to get as many fixes/improvements out as i can
[00:41] <kenvandine> yeah
[00:41]  * kenvandine merges
[00:42] <jamesh> kenvandine: I think I've got things sorted to let Yaru's CI trigger g-c-t's CI too now
[00:43] <kenvandine> i think someone complained about cursor theme, that would be included in their icon theme right?
[00:43] <jamesh> quite possibly, yeah.
[00:43] <jbicha> Laney: g-s-d 3.31.90 works with gnome-shell 3.30. I haven't tried 3.31.91 though
[00:44] <jamesh> cursor themes are generally part of the icon theme
[00:44] <kenvandine> jbicha: i think he's away until tuesday
[00:44] <kenvandine> jamesh: yeah
[00:44] <kenvandine> jamesh: something to confirm
[00:46] <jbicha> ok, I think glibc will take a bit more time to migrate anyway
[00:47] <jamesh> kenvandine: hmm.  Looks like the cursors are in breeze.git, separate from breeze-icons.git
[01:59] <robert_ancell> jbicha, can I get you to sponsor the new snapd-glib (in git). I've added autopkg tests which is a requirement for SRU exception.
[01:59] <robert_ancell> I've never done them before so if you know better than I do please have a look if they make sense!
[02:02] <robert_ancell> Laney, ^ I saw your name on the glib ones (i.e. I copied those). Let me know if they look wrong! https://salsa.debian.org/debian-ayatana-team/snapd-glib
[02:28] <kenvandine> jamesh: if you have any thing else you might be able to get into gtk-common-themes by Monday my time, take a swing at it
[02:28] <kenvandine> or rather tuesday, i'm out on monday :)
[02:28] <kenvandine> i'll defer publishing it until then, that's the snap i'm most concerned with publishing to stable to often
[02:30] <kenvandine> jamesh: also, FYI in case you weren't aware the CI builds publish to edge but we have a git mirror on LP that publishes to candidate
[02:30] <kenvandine> as the seeded snaps have to be built on LP
[02:30] <jbicha> robert!
[02:30] <kenvandine> jamesh: https://code.launchpad.net/~ubuntu-desktop/+snap/gtk-common-themes
[02:31] <kenvandine> hey robert
[02:34]  * kenvandine heads off to get more sleep
[06:40] <didrocks> good morning
[06:54] <duflu> Morning didrocks
[06:54] <didrocks> hey duflu
[07:51] <jibel> Good morning
[07:53] <duflu> Hi jibel
[07:54] <jibel> Hi duflu
[07:56] <didrocks> salut jibel
[07:57] <jibel> Salut didrocks
[08:07] <tjaalton> what's this packagekit daemon and why is it blocking manual apt update
[08:07] <tjaalton> locks the db
=== pstolowski|afk is now known as pstolowski
[08:09] <tjaalton> ah, bad network
[08:33] <oSoMoN> good morning desktoppers
[08:33] <didrocks> salut oSoMoN
[08:33] <duflu> Hi oSoMoN
[08:34] <oSoMoN> salut didrocks, hey duflu
[08:49] <seb128> good morning desktopers
[08:49] <seb128> tjaalton, it's the service used by e.g gnome-software to interact with the packaging system
[08:52] <tjaalton> seb128: right, it's not new but was blocking apt on a new install because the network driver of the new hw is buggy
[08:53] <tjaalton> first time I saw it running
[08:55] <willcooke> morning all
[08:58] <duflu> Morning willcooke
[08:58] <seb128> tjaalton, k
[08:58] <seb128> willcooke, hey!
[08:59] <seb128> & bbiab, going to co-working now
[09:00] <didrocks> hey willcooke
[09:02] <willcooke> Hot cross buns for breakfast \o/
[09:05] <jibel> Hi willcooke
[09:08] <oSoMoN> hi willcooke, salut jibel
[09:33] <jibel> I'm seeing bug 1818199 on every boot on disco. Anyone else have this crash?
[09:33] <ubot5> bug 1818199 in packagekit (Ubuntu) "packagekitd crashed with SIGSEGV in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace()" [Medium,New] https://launchpad.net/bugs/1818199
[09:33] <willcooke> jibel, checking
[09:35] <jibel> I cannot find something similar on the tracker but there are so many pkgkit crashes there
[09:35] <duflu> jibel, tjaalton was just mention problems in packagekit
[09:35] <jibel> error tracker*
[09:35] <duflu> *mentioning
[09:36] <tjaalton> yeah it's crashing here too
[09:36] <seb128> same as bug #1818059?
[09:36] <ubot5> Error: Launchpad bug 1818059 could not be found
[09:38] <seb128> but packagekit didn't change since 01-07
[09:41] <jibel> I don't know the trace in the private bug is too incomplete
[09:41] <willcooke> hrm, not seeing anything in the logs for a fresh install
[09:41] <jibel> apt changed yesterady
[09:42] <jibel> and pk crashes in the apt backend
[09:42] <tjaalton> hmm, didn't crash this time
[09:43] <didrocks> I didn't update for a couple of days, but it's only at startup?
[09:43] <didrocks> ah, I'm wrong: -rw-r----- 1 root whoopsie 4467454 févr. 25 08:25 /var/crash/_usr_lib_packagekit_packagekitd.0.crash
[09:43] <didrocks> so, for quite some days already
[09:45] <duflu> jibel, yeah I found lots of reports of that and similar. All in bug 1818199 now
[09:45] <ubot5> bug 1818199 in packagekit (Ubuntu) "packagekitd crashed with SIGSEGV in __memmove_sse2_unaligned_erms() from std::char_traits<char>::copy() from std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_copy() from std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace()" [Medium,Confirmed] https://launchpad.net/bugs/1818199
[09:45] <seb128> who wants to valgrind it?
[09:46] <seb128> duflu, when did those start?
[09:46] <duflu> seb128, May 2018
[09:46] <jibel> duflu, thanks for finding the duplicates
[09:47] <seb128> k, so nothing new
[09:47] <duflu> just more common
[09:47] <seb128> still would be good to debug is someone can reproduce
[09:47] <seb128> brb
[09:48] <jibel> duflu, are you sure the crashes in the tracker are the same?
[09:48]  * duflu checks again
[09:49] <duflu> jibel, yes but the robots will call them two different crashes. The top function (sse2 vs avx) is just a runtime choice of which function is best for your CPU model
[09:55] <duflu> The real bug is below that and the same
[09:58] <duflu> seb128, appears to be a misuse of C++ at apt-messages.cpp:55 but I can't tell what the mistake is
[09:58] <duflu> (assuming it's not an STL bug)
[10:26] <Laney> jbicha: thanks, you can unblock it if you want to be responsible for that :-)
[10:26] <Laney> (not here!)
[10:28] <Laney> unblocking won't make it move by itself, still blocked on new glibc
[10:28] <Laney> wonder what the blockers are there
[10:28] <Laney> not going to check though
[10:28] <Laney> HI AND BYE!
[10:28] <Laney> 👋
[10:29] <didrocks> see you Laney :)
[10:29] <willcooke> see you Laney
[10:29] <willcooke> have a good weekend
[10:33] <didrocks> and that's a good Friday push : +1500 lines, -83
[10:34] <didrocks> (well, started a little bit earlier than this morning though :p)
[10:37] <willcooke> :)
[11:29] <seb128> didrocks, jibel, tjaalton, do you get packagekit to segfault if you start it manually? if so could one of you get a valgrind log?
[11:36] <didrocks> nope, doesn't crash manually
[11:37] <seb128> :/
[11:37] <seb128> same here
[11:45] <seb128> jbicha, ricotz, who is dealing with the new vala transition?
[11:45] <seb128> gnome-shell-pomodoro autopkgtests are failing, sounds like due to it, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/g/gnome-shell-pomodoro/20190223_231441_1816a@/log.gz
[11:45] <seb128> also rygel fails to build now :/
[11:45] <seb128> error: Return: Cannot convert from `GLib.List<Rygel.DLNAProfile>' to `GLib.List<weak Rygel.DLNAProfile>'
[11:48] <seb128> which seems https://gitlab.gnome.org/GNOME/rygel/merge_requests/3.patch but that needs to be uploaded then
[11:48] <gitbot> GNOME issue (Merge request) 3 in rygel "renderer: Fix type-argument mismatch" [Merged]
[11:52] <ricotz> seb128, I mentioned the required upstream commits to jbicha, seems he didn't get it yet
[11:52] <seb128> ricotz, you should really consider applying for upload rights at some point :)
[11:52] <ricotz> seb128, please see my last messages in #debian-gnome
[11:54] <seb128> ricotz, why not doing MPs/sponsoring request for packages fixes, would open the way for you to be addded to pkg-gnome and being able to do those fixes directly which would benefit everyone
[11:55] <ricotz> seb128, I see, although as a bad experience there was my zeitgeist update which didn't get anywhere for weeks, or the vala SRUs
[11:57] <ricotz> this made me think again that the spare time is better invested upstream
[11:58] <ricotz> regarding folks, this basically mean and proper rebuild for bionic/cosmic must be considered
[11:59] <ricotz> what does "rls-bb-notfixing" mean?
[11:59] <tjaalton> seb128: nope, doesn't crash
[12:00] <ricotz> seb128, rygel https://gitlab.gnome.org/GNOME/rygel/commit/5234b48eb0765b7ed3e7836213747fbb3b0ee2b5
[12:03] <seb128> ricotz, it means we are not tracking the bug as a team-owned-item
[12:04] <jbicha> jibel: there was a packagekit fix uploaded to Debian that we need to merge for disco
[12:04] <seb128> ricotz, re sponsoring, yeah we are low on resources, which is why it would be best if you could upload yourself without having to block on others
[12:04] <ricotz> seb128, ok, I am really hoping your are not underestimating those vala bug fixes
[12:05] <seb128> ricotz, I probably am, I don't know much about vala and I don't know of any concrete user visible issue those would fix
[12:05] <seb128> jbicha, were you going to merge or should I? we probably want that one
[12:05] <seb128>    [ Andrew Hayzen ]
[12:05] <seb128>    * Add aptcc-use-correct-return-type-in-function.patch:
[12:05] <seb128>      - Fix function return type, which resolves packagekitd crash
[12:05] <seb128>        when gnome-software launches, causing gnome-software to hang
[12:06] <ricotz> seb128, considering a core gnome build-dep as not critical seems problematic
[12:06] <seb128> ricotz, I think we simply have different perspectives on the problem
[12:06] <jbicha> seb128: I just asked Julian in #ubuntu-devel if we can get our diff pushed to Debian so we can sync again
[12:06] <seb128> I'm looking at SRUs from an user-impact
[12:07] <jbicha> I have appointments today so I won't be able to do uploads until tomorrow
[12:07] <seb128> and I don't know how any problem existing and bitting users today that would get resolved by the vala update
[12:07] <seb128> but I'm happy to be informed
[12:07] <seb128> jbicha, ok, I can do that
[12:07] <seb128> or let's see if julian wants to do it
[12:08] <jbicha> Julian is an "Uploader" for pk in Debian :)
[12:08] <jbicha> ok, bye for now :)
[12:09] <ricotz> seb128, ok, my pov is vala upstream, and see people working with older versions and reporting fixed bugs is unfortunate, in case of bionic as LTS release is even worse having an out-dated versions while this is usually a development target
[12:10] <ricotz> seb128, maintaining several vala branches as LTS releases is reason to provide stable release updates for those distro releases
[12:11] <seb128> right
[12:11] <seb128> it's always tricky to do toolchain updates in stable series
[12:11] <seb128> you ideally need to test rebuild/runtime the rdepends
[12:12] <seb128> which is non trivial work
[12:12] <seb128> didrocks, jibel, tjaalton, the packagekit issue should be fixed in https://launchpad.net/ubuntu/+source/packagekit/1.1.12-2ubuntu1
[12:13] <ricotz> does this actually happen for updates like gcc 8.2 or openjdk 11 in that detail?
[12:14] <seb128> ricotz, openjdk yes, the SRU bug lists all the rdepends and there is a ppa used https://launchpad.net/~openjdk-11-transition
[12:15] <seb128> I don't know about gcc
[12:15] <ricotz> ok
[12:16] <seb128> vala would probably make a good classic snap :)
[12:16] <seb128> would make easier for users on any serie to get the version they want
[12:17] <seb128> while we could be more conservative with the distro version which is used to build the archive
[12:17] <ricotz> seb128, vala is part of the gnome-sdk which is sufficient for user wanting it that way
[12:18] <ricotz> this doesn't help building archive packages though
[12:19] <ricotz> proving newer series of vala in released ubuntu versions is not my goal
[12:20] <ricotz> but fixing issues discovered over the time
[12:22] <seb128> right, well I agree it would be nice to have the current version
[12:22] <seb128> but it's lot of work and people are busy :/
[12:22] <seb128> it also doesn't give confidence that things might need to be rebuilt, it means other packages might also hit problems
[12:23] <ricotz> I am fine with scratching the cosmic update, but the keeping bionic updated is kind of essential with its 10 years support
[12:25] <ricotz> if it is realized that a package actually needs an rebuild it would be buggy already
[12:27] <ricotz> you won't see such failures which are happening with vala 0.43.x in rygel
[12:28] <ricotz> e.g. rygel fix itself would likely apply and fix memory management issues in stable releases too
[12:28] <seb128> right
[12:28] <seb128> anyway don't worry, we will look at the bionic SRU
[12:29] <ricotz> alright, there will be a vala 0.40.14 soon
[12:31] <seb128> k
[12:32] <ricotz> thanks
[12:35] <seb128> jbicha, did you plan to ffe the new gupnp?
=== ecloud_wfh is now known as eckoud
=== eckoud is now known as ecloud
[13:39] <didrocks> seb128: I'll keep an eye on the crashers after updating
[13:39] <seb128> didrocks, 'ci
[13:43] <ricotz> is it possible to let the blocked-by-glibc packages to transition from -proposed?
[13:51] <didrocks> ricotz: maybe ask doko? I don't know the impact if there are some ABI compatibility on some archs which creates this transition
[13:53] <ricotz> didrocks, it is fine I assume he is on this glibc issue
[13:53]  * ricotz is just getting the usual stuck-in-proposed emails
[13:58] <seb128> yeah, not easy way around that :/
[14:03] <seb128> didrocks, could you review https://code.launchpad.net/~vanvugt/ubuntu/+source/gnome-shell/+git/gnome-shell/+merge/363831 since you know about the topic and it's changing a patch you wrote?
[14:03] <seb128> also the code diff is small so hopefully it doesn't require too much work, maybe just a round of testing if you validate the approach
[14:07] <didrocks> seb128: sure! Just need a test + reboot (will probably do that in the morning, when I don't have too much stuff opened ;))
[14:07] <seb128> didrocks, sounds good, thx!
[14:08] <didrocks> de rien!
[14:09] <didrocks> it looks good, but I want to check the color actually matches now
[14:09] <didrocks> trusting duflu on this, but you never know :)
[14:16] <seb128> yeah, always good to double check
[14:16] <seb128> even if for sure he has better eyes than me for colors and frames
[14:24] <didrocks> yeah, same :)
[14:47] <kenvandine> This is a crazy notification https://usercontent.irccloud-cdn.com/file/10pGZ7CC/Screenshot%20from%202019-03-01%2009-44-37.png
[14:47] <kenvandine> i'm guessing update-notifier is using an icon that's way too big?
[14:50] <willcooke> ha
[14:56]  * kenvandine files bug
[14:58] <kenvandine> actually maybe it's a notification-daemon bug
[14:58] <kenvandine> i'd think it should be scaling the icon
[15:00] <kenvandine> bug 1818246
[15:00] <ubot5> bug 1818246 in notification-daemon (Ubuntu) "update-notifier's notification is huge due to large icon" [Undecided,New] https://launchpad.net/bugs/1818246
[15:13] <kenvandine> jbicha: do you know what epiphany uses for password storage?  To me it seems like it would use the keyring... but it doesn't seem to
[15:14] <kenvandine> i noticed timeouts on the console storing passwords
[15:14] <kenvandine> but not apparmor denials
[15:14] <kenvandine> i added the password-manager-service plug thinking it should need it, but it really should have shown denials if it was using that
[15:14] <kenvandine> but that didn't work
[15:16] <seb128> kenvandine, lol
[15:17] <seb128> kenvandine, is notification-daemon still used? also wth about update-notifier being ready, that's supposed to be a service, not something to notify users about
[15:17] <kenvandine> oh... dunno :)
[15:18] <kenvandine> so it's all in the shell now
[15:18] <kenvandine> duh
[15:19] <kenvandine> :)
[15:19]  * kenvandine updated the bug
[15:20] <kenvandine> all i know is i got a HUGE notification from update-notifier
[15:20] <kenvandine> freaking shell focus
[15:21]  * kenvandine edits bug
[15:21] <seb128> did you trigger update-notifier manually in some way?
[15:22] <seb128> do you use scaling?
[15:22] <kenvandine> no and no
[15:23] <kenvandine> i was typing in irc when that popped up
[15:23] <kenvandine> does update-notifier raise a window when updates are ready?
[15:23] <kenvandine> oddly i never got such a window
[15:24] <seb128> it triggers update-manager
[15:25] <kenvandine> i also hadn't rebooted or anything
[15:25] <kenvandine> so it's not like the service should have just started
[15:26] <seb128> kenvandine, epiphany does use gnome-leyring
[15:26] <seb128> or libsecret at least
[15:26] <seb128> see https://gitlab.gnome.org/GNOME/epiphany/blob/master/lib/sync/ephy-password-manager.c
[15:26] <seb128> also https://gitlab.gnome.org/GNOME/epiphany/commit/50baa8136
[15:27] <seb128> (flatpak allowed access to the keyring)
[15:27] <kenvandine> i saw it was linked against libsecret
[15:28] <kenvandine> it's timing out though, something else to debug :)
[15:28] <kenvandine> seb128: i updated the bug
[15:28] <kenvandine> i guess it's two thing, the shell should scale large icons down
[15:28] <kenvandine> s/thing/things/
[15:29] <kenvandine> jbicha: i'm going to go ahead an push a couple changes to the epiphany snap, as at least they are correct.  but we still need to figure out why it's not working
[15:31] <kenvandine> oddly there is no denials at all from epiphany... which is really unusual
[15:31] <kenvandine> so it's clearly not even trying
[15:31] <seb128> do you build from source?
[15:32] <kenvandine> yes
[15:32] <kenvandine> it might not be building with libsecret
[15:33] <kenvandine> checking
[15:34] <kenvandine> it does
[15:35] <seb128> do you have the build log?
[15:37] <kenvandine> it's on LP, i'll look at it
[15:37] <seb128> it doesn't seem optional anyway
[15:37] <seb128> so dunno sorry
[15:39] <kenvandine> Dependency libsecret-1 found: YES 0.18.6
[15:40] <kenvandine> anyway, i have more pressing things to worry about :)
[15:41] <seb128> kenvandine, btw, side comment from testing gedit yesterday, your layouting of iso-codes failed warning but there are no dictionnary so still no spell checking (but bundling dictionnaries doesn't sound nice :/ maybe something worth having an interface over to access the host or shared content for dict between apps)
[15:42] <kenvandine> oh
[15:42] <seb128> kenvandine, oh and there are denials about the session logout inhibit, which I think has no interface atm so a wishlist for snapd, unsure if that's already known/reported/on some of our lists?
[15:42] <kenvandine> portals will handle that
[15:43] <seb128> how so?
[15:43] <kenvandine> there is a portal for session inhibit
[15:43] <kenvandine> need a newer gtk and glib though
[15:43] <seb128> prompting users every time they open edit to know if it's ok to inhibit their session?
[15:43] <seb128> or what's the user interaction?
[15:43] <kenvandine> i don't think that one has any user interaction
[15:43] <kenvandine> some of them don't
[15:44] <kenvandine> or maybe once
[15:44] <kenvandine> and it remembers
[15:44] <seb128> ok, nice :)
[15:44] <seb128> thx ken!
[15:44] <kenvandine> np
[15:44] <kenvandine> thanks for testing and giving feedback
[15:44] <seb128> oh, I forgot to ask how you feel today!
[15:44] <seb128> a bit better I hope?
[15:44] <seb128> np
[15:44] <kenvandine> no... sadly
[15:44] <kenvandine> it's been a miserable week
[15:45] <kenvandine> wednesday i was the only day i didn't have a fever
[15:45] <kenvandine> it came back
[15:45] <didrocks> kenvandine: take it easy :(
[15:45] <kenvandine> been on antibiotics for the past 2 days, still not helping
[15:45] <kenvandine> my family has me in quarantine :/
[15:46] <didrocks> yeah, I imagine… source of infection :p
[15:46] <kenvandine> i've only left the bedroom to go to the doctor all week
[15:46]  * kenvandine is going crazy
[15:46] <kenvandine> it means i've been spending my evenings working :/
[15:47] <kenvandine> otherwise too bored
[15:47]  * didrocks hugs kenvandine
[15:48] <kenvandine> my poor wife... spent 2 weeks now taking care of all the kids on her own
[15:48] <didrocks> yeah, thought you would come back and rest a little bit… Lies!
[15:48] <kenvandine> damn ubuflu
[15:49] <frederik-f> test
[15:49] <kenvandine> tset
[15:49] <didrocks> hey frederik-f!
[15:49] <frederik-f> Huhu, ah now I understood IRC
[15:49] <didrocks> frederik-f: going to apply for ubuntu membership next? :)
[15:50] <frederik-f> Yes I already made it to the wiki page: https://wiki.ubuntu.com/Membership/Boards
[15:50] <frederik-f> But I have no contributions on launchpad yet, so I linked the yaru repo. Hope that's okay?
=== chrisccoulson__ is now known as chrisccoulson
[15:52] <didrocks> frederik-f: I guess you broke the array and you still need to write a wiki page presenting you :) This is where you will explain your contribution and link to the yaru repo
[15:52] <didrocks> (and community.ubuntu.com and so on…)
[15:52] <frederik-f> okay, I try my best! :D
[15:53] <k_alam> seb128: Hi, good afternoon, can you sponsor few unity mps ?
[15:53] <seb128> k_alam, hey, maybe, feel free to give the urls and I will see what I can do
[15:53] <k_alam> seb128: https://paste.ubuntu.com/p/MSQSKFfH7d/
[15:54] <seb128> kenvandine, urg :( get better!
[15:54] <kenvandine> seb128: thx
[15:55] <k_alam> seb128: will vala 44 be in disco ? It is breaking many packages...unity-greeter, scopes....etc
[16:02] <seb128> k_alam, https://launchpad.net/distros/ubuntu/+source/vala ... 0.43.91 is in disco-proposed, jbicha and ricotz are supposed to handle those issues, you didn't hear from them/got patches?
[16:05] <k_alam> ricotz patched libunity......that leaves greeter and scopes...not sure if any one working on those....I fixed glib related deprecation in greeter
[16:05] <seb128> no-one from desktop team at least
[16:08] <k_alam> ok...let me try fixing those in greeter....I will ask jbicha later
[16:15] <ricotz> seb128, k_alam, I have several updated packages
[16:16] <ricotz> e.g. https://launchpad.net/~ricotz/+archive/ubuntu/vala-disco/+packages?field.name_filter=greeter&field.status_filter=published&field.series_filter=
[16:16] <seb128> ricotz, did you submit the fix to the vcs-es?
[16:16] <ricotz> seb128, no, most of them were synced from debian
[16:17] <seb128> :(
[16:17] <ricotz> I guess unity-greeter could have been proposed
[16:17] <seb128> well at least you are hanging out here :)
[16:17] <seb128> k_alam, ^ try grabbing the diff from that ppa?
[16:21] <k_alam> Alright..let me try that...Thanks.
[16:27] <seb128> k_alam, launchpad is being unhappy, I uploaded unity-control-center but had to do the logo change locally since I couldn't grab the branch at the time
[16:27] <seb128> those 2 u-c-c ones are uploaded now
[16:39] <k_alam> seb128: The diff seems ok to me for u-c-c....u-s-d diff also seems fine....I used bzr rebase for u-c-c.......may be that's why some issues are happening...
[16:41] <seb128> k_alam, no, the issue is the launchpad server being out of order atm
[16:41] <seb128> or some bits at least
[16:59] <seb128> k_alam, k, so I sponsored most of those, I don't have the slots to deal with the lenses/dh-python now though but the others are in
[16:59] <seb128> k_alam, unity-greeter I didn't upload since I think that needs the vala fix as well? let me know when you mp that
[17:04] <k_alam> Thanks....yes I am preparing a mp for greeter....vala fixes required only after 43.91 lands, so it will work for now...same for libunity......
[17:04] <seb128> of course libunity failed to build...
[17:05] <seb128> k_alam, no, new vala is in proposed already and packages build again proposed
[17:05] <seb128> k_alam, https://launchpadlibrarian.net/413314917/buildlog_ubuntu-disco-amd64.libunity_7.1.4+18.04.20180209.1-0ubuntu3_BUILDING.txt.gz
[17:07] <k_alam> libunity requires this first... https://code.launchpad.net/~ricotz/libunity/syntax-fixes/+merge/362923 it needs to be reviewed though
[17:08] <k_alam> and dh-python in build depends...which was added without going through trunk
[17:09] <seb128> right
[17:10] <k_alam> should I remove dh-python from my merge since it was already added ?
[17:11] <seb128> you can but it's not needed
[17:11] <seb128> well I already sorted that out for the changes I uploaded
[17:19] <seb128> k_alam, ricotz, that libunity situation is suboptimal, unsure we have people to review those changes/knowing the rdepends, also changing the API seems suboptimal but I don't understand vala enough to know why that's needed
[17:21] <ricotz> the diff could be reduced by concentrating on errors only for easier review
[17:23] <seb128> would that means not changing the API?
[17:23] <ricotz> moving the out parameters are only vala API changes without effecting C
[17:24] <ricotz> the API changes I am referring there are the ownership changes
[17:27] <seb128> well as said before I don't understand vala enough to comment on that
[17:27] <seb128> I think we want to minimal changes required to fix the build to ease the review
[17:35] <ricotz> seb128, k_alam, minimized and updated the merge
[17:35] <seb128> ricotz, thx!
[17:40] <k_alam> ricotz:  thanks.
[17:42] <k_alam> ricotz: will open a merge for unity greeter too ? Only for vala fixes..I can replay my merge on top of that...
[17:42] <k_alam> *will you
[17:43] <ricotz> k_alam, I don't care for credits, so just use the diff
[17:44] <k_alam> Alright...bzr supports author..so I will use that.. :)
[17:44] <ricotz> (bazaar feels a bit clumsy to work with compared to git)
[17:47] <k_alam> some unity related already moved to git...rest will move soon
[17:49] <ricotz> good :)
[18:03] <willcooke> night all, have a good weekend
[18:09] <Trevinho> desktoppers, fractional scaling stuff (wayland) just merged upstream!
[18:56] <jibel> I'm debugging automated desktop tests of disco and I see a timeout of portal service. What is this service? and when has it been introduced?
[18:57] <jibel> then a timeout of packagekit.service. It seems to be blocking ubiquity?
[18:57] <jibel> -?
[19:21] <oSoMoN> Trevinho, congrats, you deserve a beer!
[19:23] <jibel> ah no, it's a problem with partman
[19:32] <kenvandine> Trevinho: congrats!
[19:32] <kenvandine> seb128: aspell is included in the gnome content snap, which you recommend i include hunspell?
[19:32]  * kenvandine isn't up to speed on what's recommended
[19:33] <kenvandine> i might be able to use a layout to provide the proper access
[19:34] <kenvandine> either way we'd need to add other langs
[19:38] <seb128> kenvandine, yes, but enchant is what is used to access the dict
[19:42] <kenvandine> enchant is in the content snap as well
[19:42] <kenvandine> seb128: so you think i should add hunspell?
[19:46] <jibel> seb128, FYI, automated tests failure is a real failure with preseeded installations of desktop. I filed bug 1818285.
[19:46] <ubot5> bug 1818285 in partman-base (Ubuntu) "[disco desktop] preseeded installation fails with parted_server: No data in infifo. parted_server: Line 2387. CRITICAL ERROR!!! EXITING." [Undecided,New] https://launchpad.net/bugs/1818285
[19:48] <seb128> kenvandine, well, you want to add the individual dictioonnaries?
[19:48] <seb128> jibel, ah, good, thx!
[19:48] <kenvandine> yeah, but do we need both aspell and hunspell?
[19:48] <kenvandine> iirc hunspell is desired
[19:49] <kenvandine> seems sensible to add all the languages to the content snap
[19:50] <seb128> jibel, I pinged Steve about it on #ubuntu-devel
[19:51] <seb128> kenvandine, the iso has aspell-en and then hunspell-de/es/fr/it/etc
[19:51] <seb128> it sucks if we need to bundle all the dicts for all locales though
[19:51] <kenvandine> seb128: i think we do need to
[19:52] <seb128> we should allow access to the dict from the host
[19:52] <seb128> same as fonts
[19:52] <seb128> imho
[19:52] <kenvandine> since we don't have a means to add them dynamicly
[19:52] <kenvandine> seb128: good point
[19:52] <kenvandine> that should be harmless
[19:52] <kenvandine> and very stable
[19:52] <seb128> there is no abi/format change there
[19:52] <seb128> right
[19:53] <kenvandine> oh
[19:53] <kenvandine> we do already have that access
[19:53] <kenvandine> from the sandbox i can list /usr/share/hunspell
[19:54] <kenvandine> and see what's on the host
[19:54] <kenvandine> that's good... now we just need to figure out why it's not working :)
[19:55] <kenvandine> gedit says there is no language set but hints it could be the lack of dictionaries
[19:55] <kenvandine> but maybe it is really just the language not being set :)
[19:56]  * kenvandine straces
[20:01] <kenvandine> oh my... i think it's blowing up because it can't find gspell-1.mo
[20:08] <seb128> :/
[20:29] <kenvandine> that's easily fixable :)
[21:01] <oSoMoN> good night and good week-end all
[21:04] <seb128> it's work-late-friday today it looks like
[22:04] <kenvandine> jdstrand: i have a couple of snaps awaiting review for dbus slot assertions
[22:05] <kenvandine> jdstrand: transporter and feedreader
[22:06] <kenvandine> jdstrand: and the snap-store auto connection for system-observe has the votes now
[22:06] <kenvandine> jdstrand: just nagging a little :)
=== Dmitrii-Sh_ is now known as Dmitrii-Sh
=== FourDollars_ is now known as FourDollars
=== pstolowski_ is now known as pstolowski
=== PaulW2U_ is now known as PaulW2U
=== kenvandine_ is now known as kenvandine
=== tedg_ is now known as tedg
=== plars_ is now known as plars
=== zyga_ is now known as zyga