[02:39] <duflu> jbicha, out of curiosity, what name does 'xinput' refer to your touchpad as?
[02:39] <jbicha> um, I guess SynPS/2 Synaptics TouchPad
[02:41] <duflu> jbicha, yes that explains it. My hack around the gdk bug was case sensitive ("pad")
[02:41] <duflu> Although I copied it from the same source file :)
[02:45] <duflu> jbicha, I can do a more reliable fix that doesn't need a gdk fix. Plus the bug ID has changed. Will try to get that done today
[02:45] <duflu> Although it's kind of ugly unless gdk is fixed :/
[02:51] <jbicha> Robert!
[07:05] <oSoMoN> good morning desktoppers
[07:16] <duflu> Morning oSoMoN
[07:21] <jibel> Good morning
[07:25] <duflu> Hey jibel
[07:27] <oSoMoN> good afternoon duflu
[07:27] <oSoMoN> salut jibel
[08:12] <didrocks> good morning
[08:35] <duflu> Morning didrocks
[08:39] <didrocks> hey duflu, how are you?
[08:39] <duflu> didrocks, alright I guess. A bit rushed (some days the backlog of tasks grows faster than actual progress). You?
[08:41] <didrocks> duflu: same, happy to take time to write a very large set of tests for telemetry, found some bugs already or things that could be better, and improved them along the way!
[08:41] <didrocks> (already 70+ tests)
[08:42] <ShriHari> wassup
[08:43] <Nafallo> morning
[09:00] <willcooke> morning
[09:00] <Nafallo> morning willcooke
[09:01] <Laney> hey hey
[09:01] <didrocks> hey willcooke, Laney, Nafallo!
[09:03] <duflu> Morning willcooke, Laney
[09:03] <duflu> and Nafallo
[09:10] <seb128> good morning desktopers!
[09:12] <didrocks> hey seb128
[09:27] <ShriHari> hey seb128
[09:29] <Nafallo> salut seb128
[09:49] <duflu> Morning/evening seb128
[09:50] <Nafallo> hah. going for the state of tired there, duflu ? ;-)
[09:50] <duflu> Not intentionally
[09:52] <Nafallo> that said... more coffee!
[10:08] <duflu> Still bisecting, but also preparing dinner
[10:08] <duflu> night
[10:33] <popey> seb128: thanks for your reply to that performance thread. Will you also be looking at performance of things outside the GNOME space?
[10:34] <popey> (e.g. the top 5 things in the store with diverse setups, classic, using helpers, not using helpers, qt etc)
[11:27] <Nafallo> hmm. I think I've misunderstood -proposed. anyone know where I can read up about it?
[11:28] <Laney> Nafallo: https://wiki.ubuntu.com/ProposedMigration/ maybe?
[11:29] <Nafallo> ah. thanks Laney :-)
[11:30] <Laney> That might be too in the weeds already though.
[11:30] <Nafallo> specifically, I'm trying to figure out what's going on with https://launchpad.net/ubuntu/+source/ansible
[11:31] <Nafallo> three months migration seems a bit long for a successfully built `all` package :-)
[11:35] <Nafallo> autopkgtests
[11:36] <jibel> Nafallo, it's all red https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ansible
[11:37] <Nafallo> well, for an all package I'm not surprised ;-)
[11:37] <jibel> Nafallo,and this is why  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/o/os-faults/20180211_083835_a5a32@/log.gz
[11:38] <jibel> either fix ansible or os-faults to work with the newer version of ansible
[11:39] <Nafallo> yeah. let's see if I can figure it out :-)
[11:39] <Nafallo> autopkgtest wasn't there last time I did packaging in Ubuntu ;-)
[11:52] <jbicha> andyrock: what services will be using Ubuntu SSO in 18.04.0? Only LivePatch?
[11:52] <jbicha> (I mean with the new GOA provider)
[12:04] <andyrock> and all apps using the store
[12:07] <jbicha> can you explain more?
[12:08] <jbicha> I'm asking because I want to figure out whether your GOA patch should be pushed into Debian
[12:08] <jbicha> LivePatch is useless there, the Snap Store isn't useless but it's not installed by default either
[12:10] <Laney> it's going to come via upstream anyway
[12:13] <jbicha> there are 2 GOA patches, maybe the LivePatch helper script should be in a different package?? since it's not useful to other distros
[12:14] <jbicha> if the Ubuntu provider isn't useful at all to Debian, it doesn't make sense to enable that feature even if it an option upstream
[12:15] <jbicha> "Use for … Network Resources"
[12:25] <Nafallo> hrm. my autopkgtest keeps saying there is no tests in package when I try to reproduce it :-P
[12:26] <Laney> did you follow http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test ?
[12:27] <Nafallo> that's the one I'm trying, but with lxd instead
[12:27] <Nafallo> autopkgtest --apt-pocket=proposed=src:ansible ansible -- lxd autopkgtest/ubuntu/bionic/amd64
[12:27] <Laney> it's the test of os-faults
[12:28] <Laney> replace the second ansible
[12:32] <Nafallo> still something wonky. let me pipe it to pastebinit
[12:36] <Nafallo> http://paste.ubuntu.com/p/TCFtDHpzT8/
[12:46] <andyrock> jbicha: so it will be useful if gnome-software to buy snaps
[12:47] <andyrock> *in
[12:47] <andyrock> livepatch is in another patch on purpose
[12:47] <jbicha> andyrock: do we know when Snap purchasing will be enabled?
[12:48] <andyrock> jbicha: I don't know tbh
[12:48] <Laney> Nafallo: you might need to install autodep8
[12:48] <andyrock> seb128: ^^^
[12:48] <Laney> some packages have these automatically generated tests that come from there
[12:48] <seb128> popey, yes, it's on our my/our list, but our list of things to do is quite long so I don't know how much we are going to work on that and when :/ we should be at least able to do some poking, but having snappy team people helping would be nice
[12:49] <seb128> andyrock, jbicha, I don't know either, willcooke might be able to help
[12:49] <popey> seb128: I'll if I can get some time to help.
[12:49] <seb128> popey, thx!
[12:50] <willcooke> It'll be landing in G-Software real soon now.  It's already upstream, just that we didnt turn it on yet.  They are argreeing the final URL for the payments etc atm.  I'd say it will be on in the next week or so
[12:50] <willcooke> jbicha, ^
[12:51] <jbicha> oh wow, ok
[12:51] <seb128> grrr udisks autopkgtests
[12:51] <andyrock> jbicha: so we need to patch gnome-software to use gnome-online-accounts
[12:52] <andyrock> upstream already agreed
[12:52] <jbicha> seb128: :( I've got to figure out what broke in gnome-photos autopkgtests
[12:52] <andyrock> and I've already most of the code there
[12:52] <seb128> jbicha, dconf also we never figured out :/
[12:55] <seb128> jbicha, did you get any reply from mterry about deja-dup? I think it's fine to drop the ulimit hack if he doesn't respond
[12:57] <jbicha> no reply, I can go ahead and drop the ulimit thing without waiting longer for a response then
[12:58] <jbicha> it's going to be annoying for other distros though… but most distros don't include it by default anyway
[12:59] <seb128> right, and he might enventually reply/do an update for that
[12:59] <seb128> I still think we are going to have an issue there that it would nice to handle
[13:00] <andyrock> webkit crashing if ulimit is set?
[13:00] <seb128> yes
[13:00] <seb128> which deja-dup does in the Exec in its .desktop as a workaround for an (old) issue
[13:00] <seb128> that's easy to change
[13:01] <jbicha> seb128: right, I was going to ask you about doing that on Monday if we hadn't talked about it today :)
[13:01] <seb128> but it's likely some sysadminds/users out there set ulimits on their machines
[13:01] <seb128> they are going to have webkit/goa/etc just segfaulting without obvious reason
[13:01] <jbicha> andyrock: and Deja Dup is only affected because it uses GOA !
[13:01] <seb128> we should probably display a dialog at login telling them that ulimit use is incompatible with modern GNOME
[13:03] <jbicha> seb128: we should try it out to see what breaks. I mean GNOME Shell uses webkit for its captive portal handler so things could be really broken…
[13:05] <seb128> jbicha, right
[13:06] <andyrock> can webkit gigacage adapt to the maxixmum size?
[13:06] <andyrock> in order to not crash?
[13:06] <seb128> seems not according to the webkitgtk guys
[13:07] <jbicha> if it did that, it would eliminate the security hardening feature
[13:11] <andyrock> seb128: I asked bdmurray to review the software-properties patch
[13:12] <andyrock> if you also want to take a look
[13:15] <seb128> andyrock, did he reply? sure, it's on my list for today
[13:17] <andyrock> not yet
[13:18] <seb128> andyrock, he's not really a GTK hacker so I'm unsure how much he's going to be able to review, anyway I try to have a look
[13:18] <andyrock> kk
[13:31] <acheronuk> how does this minimal install exclusion list treat dependencies of the removed things? are they autoremoved as well, if not required by anything that is left?
[13:34] <jbicha> acheronuk: no
[13:35] <jbicha> speaking of that… didrocks: is this your area? https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-seeds/more-minimal/+merge/340759
[13:36] <acheronuk> right. thanks.
[13:38] <didrocks> jbicha: lgtm, pushing
[13:40] <jbicha> didrocks: we were wondering about adding totem to the list…
[13:40] <didrocks> jbicha: I don't think that's desirable, but I don't have any strong opinions
[13:41] <jbicha> the justification is that it's a popular app for people to replace with like gnome-mpv or vlc
[13:41] <acheronuk> jbicha: ok. if you remove a dependency via the list, will that in turn remove things that that depend on it? or will it baulk and refuse unless you list them all?
[13:41] <jbicha> so this way, we can sort of comply with the wishes expressed in the default apps survey without actually killing totem in the default install ??
[13:42] <acheronuk> just trying to work out how to do this most efficiently
[13:42] <jbicha> acheronuk: I don't know. I've not experimented with the feature
[13:42] <didrocks> jbicha: maybe next team meeting? I would like to have other opinions on that, but yeah, as some people will replace with vlc, that kind of make sense
[13:43] <didrocks> acheronuk: it will remove all things depending on it
[13:43] <didrocks> however, it doesn't remove reverse depends due to package being marked as manual, not auto
[13:44] <acheronuk> thanks. makes sense
[13:45] <didrocks> We have plans in the future to enhance that and have everything unused removed
[13:45] <didrocks> and that will speed up install time as well
[13:45] <didrocks> just not for 18.04 :)
[13:47] <acheronuk> right. understood. thanks again
[13:47] <didrocks> yw!
[13:48] <acheronuk> if I try this for Kubuntu, going to have a BIG list!
[13:49] <acheronuk> if it's going to be made worthwhile having
[13:50] <didrocks> :)
[13:51] <didrocks> I added support for the KDE variant of the installer
[13:51] <didrocks> so yeah, if you just drop the magic file before you start ubiquity, you should see it
[13:51] <acheronuk> I shall try some testing over the weekend
[13:52] <didrocks> feel free, I tried it on a Kubuntu live system at the time, but a double check is always appreciated :)
[13:52] <acheronuk> didrocks: can you pint me to where the file goes when ubiquity fetches it?
[13:52] <acheronuk> *point
[13:54] <didrocks> acheronuk: minimal_install_rlist_path = os.path.join(
[13:54] <didrocks>     '/cdrom',
[13:54] <didrocks>     get_casper('LIVE_MEDIA_PATH', 'casper').lstrip('/'),
[13:54] <didrocks>     'filesystem.manifest-minimal-remove')
[13:57] <acheronuk> didrocks: minimal_install_rlist_path = "/cdrom/casper/filesystem.manifest-minimal-remove" ?
[13:58] <didrocks> acheronuk: if LIVE_MEDIA_PATH isn't set in Kubuntu in /etc/casper.conf, yes :)
[13:59] <acheronuk> ok
[14:42] <Laney> jhbuildddddddddddddddddddddd
[14:43] <Laney> always good for tidying up your bos grunniens
[15:25] <ricotz> Laney, wth, was there some discussion about abandoning it?
[15:27] <Laney> ricotz: abandoning what?
[15:28] <Laney> jhbuild?
[15:33] <ricotz> I assumed you referred to https://bugzilla.gnome.org/show_bug.cgi?id=794393
[15:33] <ubot5`> Gnome bug 794393 in module sets "RFC: Add GNOME latest modulesets" [Normal,Resolved: fixed]
[15:36] <Laney> no
[15:36] <Laney> latest would be OK for me tbh
[16:05] <seb128> Laney, can you skip the udisks2 autopkgtest failures on arm64 and s390x in bionic-proposed? the arm64 one is one of the test being flacky, I see similar issues here and it had the same on other archs/worked after some retries and s390x is just disks being weird on that arch and such normal rules don't applying, that need work but I don't think we should delay testing the 2.7 serie on figureing out s390x issue when nothing is going to use udis
[16:05] <seb128> ks there anyway ... wdyt?
[16:06] <seb128> I'm going to debug the flacky one, but that's not going today and I've some days off next week
[16:06] <seb128> I would prefer we start testing 2.7 earlier than later
[16:06] <seb128> I can have a look to s390x as well but same than ^
[16:07] <Laney> to me http://autopkgtest.ubuntu.com/packages/u/udisks2/bionic/arm64 and http://autopkgtest.ubuntu.com/packages/u/udisks2/bionic/s390x look like they were working and then became worse
[16:08] <seb128> Laney, well as said arm64 has one test failing which is flaky
[16:08] <seb128> maybe something in the arch/env is making it more likely to hit the flakyness on it that it does on amd64 or i386
[16:09] <Laney> it looks like it became flaky though
[16:09] <seb128> Laney, see https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/i386/u/udisks2/20180316_120827_f40c5@/log.gz
[16:09] <seb128> right
[16:09] <seb128> as said, that's a known issue, and I'm going to work on it
[16:09] <seb128> but not today and I'm off part of next week
[16:10] <seb128> I'm arguing that it's more important that 2.7 gets early testing than it is that a flaky test is fixed to not be flaky
[16:10] <seb128> anyway, if you disagree you are the one deciding
[16:10] <seb128> I made my case :)
[16:10] <seb128> I'm back on friday next week and I expect to deal with backlog and other things
[16:11] <seb128> so I can look at it on monday 26th soonest
[16:11] <seb128> or we find somebody to look at it next week is an option
[16:11] <seb128> Laney, wdyt?
[16:13] <Laney> probably ok with skipping this version if someone does look at it
[16:13] <seb128> I look at it, maybe tomorrow in the train more
[16:13] <Laney> this was flaky on amd64 too, and this is all quite new so I think it wants some investigation
[16:14] <seb128> but I can't promise I'm going to fix it before being off
[16:14] <seb128> right, I'm poking at it
[16:14] <seb128> I just don't think I'm going to get it figured out/fixed today
[16:14] <Laney> ok
[16:15] <Laney> I'd appreciate a bug to track it if that's alright
[16:15] <Laney> then I can link to that in the hint file
[16:16] <seb128> Laney, https://trello.com/c/o8J0Uo6O/278-resolve-udisks2-flaky-test-s390x-issues
[16:16] <seb128> ah
[16:16] <seb128> I can do that as well, sec
[16:17] <seb128> Laney, https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1756378
[16:17] <ubot5`> Ubuntu bug 1756378 in udisks2 (Ubuntu) "Udisks2 flacky test (regression from 2.7)" [Undecided,New]
[16:18] <Laney> thx!
[16:18] <seb128> thank you!
[16:19] <seb128> Laney, btw if you feel like that should better blocked I'm not forcing the decision but respecting what you decide is best
[16:19] <seb128> I just think we need to start to get that update rolled out to users so it gets some better testing
[16:19] <seb128> so making my case for that :)
[16:23] <Laney> I find ignoring test failures we don't understand to be a bit uncomfortable, and I feel a bit forced by the "away for a week" thing
[16:23] <Laney> probably people are going to keep hitting that retry button
[16:23] <Laney> hopefully the flakes don't point to a real problem
[16:33] <Laney> got to go to physio now, see you later unles you're gone in which case have a nice weekend, unless you're seb128 in which case have a nice holiday!
[16:34] <Laney> 💞
[18:51] <seb128> Laney, k, as I said your call. If you think we should investigate rather than skip maybe you can find a slot to pick that up on monday if you are not too busy and see if you can figure it out?
[18:51] <seb128> Laney, worth case let's see where we are next friday, I might be able to fix it in the train tomorrow or on the way back on thursday
[18:52] <seb128> have a nice w.e/week desktopers (I'm off monday to thursday, probably going to be a bit online/checking backlog as I travel back on thursday)
[18:58] <willcooke> have a good one seb128
[18:59] <willcooke> I should probably call it EOD too, night all