[04:02] <readlnh> 0+
[06:46] <didrocks> good morning
[06:48] <jibel> Salut didrocks
[06:50] <didrocks> salut jibel
[06:51] <jibel> didrocks, ça va? tu as passé un bon w-e?
[07:15] <duflu> o/  didrocks, jibel  \o
[07:16] <didrocks> jibel: bon week-end, ensoleillé, un peu de jeux pour Martin, donc c'était sympa
[07:16] <didrocks> et toi ?
[07:16] <didrocks> hello duflu
[07:20] <jibel> didrocks, match de hand samedi et ciné hier sinon repos
[07:20] <jibel> good morning duflu
[07:21] <didrocks> sympa :)
[07:35] <didrocks> jibel: do you want us to coordonate iso testing? I think I have some free slots to give some help if needed
[07:40] <jibel> didrocks, that's fine for the moment, I'm reviewing all the test cases to make sure nothing is utterly broken then we'll have more respins.
[07:41] <jibel> didrocks, although wednesday and thursday are usually busy and any help will be welcome
[07:42] <didrocks> jibel: deal! :)
[07:44] <jibel> Trevinho, Hi, have you been able to reproduce bug 1794280 on latest desktop image (buid 20181013.1) ?
[07:51] <seb128> good morning desktopers
[07:51] <duflu> Morning seb128. How goes?
[07:51] <seb128> good! you?
[07:52] <jibel> bonjour seb128
[07:52] <seb128> lut jibel
[07:52] <seb128> did you have a good w.e?
[07:52] <jibel> seb128, oui bien et toi?
[07:52] <duflu> seb128, yes pretty good. I feel I've almost caught up on my pre-travel domestic tasks
[07:53] <didrocks> salut seb128
[07:53] <seb128> nickel, y a fait beau et les gastros étaient passées pour tout le monde :)
[07:53] <didrocks> enfin un week-end tranquil donc ? :)
[07:54] <seb128> ouais :)
[08:17] <oSoMoN> good morning desktoppers
[08:18] <seb128> lut oSoMoN, en forme ? t'as passé un bon w.e ?
[08:21] <didrocks> salut oSoMoN
[08:21] <duflu> Hi oSoMoN
[08:25] <oSoMoN> salut seb128, didrocks, duflu
[08:25] <oSoMoN> excellent long week-end, oui, merci!
[08:28] <seb128> Trevinho, hey, bug #1797851 started with your most recent change, would be nice if you could have a look
[08:40] <didrocks> seb128: so, on check-language-support, it's even worse than I thought
[08:40] <didrocks> the info of "installed / want to have installed languages is coming from account services"
[08:40] <didrocks> on a fresh "french" selected installation, the list is:
[08:41] <didrocks>  fr_CA en_US  fr_FR en en_AU fr en_GB en_CA
[08:41] <didrocks> so some variants for french and english
[08:41] <didrocks> english is set at install time selecting en_US + fr_FR
[08:42] <didrocks> the others seems to be pulled by account-services, I think that's the switch to account-services which (maybe?) has us regressed
[08:42] <didrocks> and what I told the other days stays: if we select "en", all en_* are then selected
[08:43] <didrocks> /usr/share/language-tools/language-options is in perl… hum
[08:44] <didrocks> but:
[08:44] <didrocks> # add items without country code to facilitate lookups
[08:44] <didrocks>     ( my $lang = $loc ) =~ s/_[A-Z]+//;
[08:44] <didrocks> so stripping the _ is something done on purpose in language-options
[08:46] <seb128> hum
[08:46] <seb128> I don't think the use of account-services is any recent, it was probably there at the time we looked at the topic for xenial and probably didn't change since
[08:47] <didrocks> yeah, just checked that, oneiric
[08:47] <didrocks> but maybe it wasn't doing the above stripping of _, which leads to that…
[08:47] <didrocks> anyway, ubiquity / check-language-support should be in sync (one using the other one) to determine what to install / remove
[08:48] <didrocks> I wonder though how much effort this is, depending if we replace the installer…
[08:48] <didrocks> (also, the seed should be in sync with check-language-support, which isn't the case)
[08:49] <didrocks> that's separate from L_aney issue though, which is to ensure at least if you select en_GB, that en_GB is indeed selected and not en_US
[08:53] <seb128> right
[08:53] <seb128> we should maybe talk to GunnarHj about it, he knows the tricks in those perl scripts and why they are there
[08:53] <didrocks> yeah
[08:54] <didrocks> because it sounds really like a yak shaving task :p
[08:54] <didrocks> but at least, understanding this could be in a new installer redesign
[08:54] <didrocks> (fortunately, the perl script isn't really long)
[08:57] <seb128> well, if that worked in xenial the diff/change/bug is probably trivial, I doubt we had any "real change" in that stack
[08:57] <seb128> but yeah, doing it properly is likely yak shaving
[08:57] <seb128> and it doesn't seem important/high priority
[08:57] <seb128> thanks for investigating
[08:58] <seb128> I don't think it's worth persuing more atm, unless you have interest to get to the bottom of it
[08:58] <seb128> otherwise maybe record what you found in a bug report and call it enough for now?
[08:58] <didrocks> seb128: it worked in xenial when I tested it
[08:58] <didrocks> in January 2016
[08:58] <didrocks> but not in 16.04.5 as told on Friday
[08:59] <didrocks> so, even diffing isn't trivial :/
[08:59] <didrocks> I'm just printing a little bit what we get in the perl functions, and yes, file that in a bug report
[09:05] <seb128> didrocks, weird that it regression in a point update, or maybe it got buggy before .0 went out?
[09:05] <didrocks> I think there is a high chance of regression before .0 IMHO
[09:14] <Laney> moin
[09:17] <didrocks> hey Laney, how is London?
[09:19] <Laney> grey, cold
[09:19] <Laney> but i'm with some GREAT! GUYS!
[09:19] <Laney> how are you?
[09:20] <didrocks> I'm good, thanks! Overall great week-end :)
[09:20] <didrocks> you are with great gruys, unlike every week on IRC, I see, I see :p
[09:25] <Laney> i can touch these people
[09:25]  * Laney touches sil2100 to prove it
[09:26] <seb128> hey Laney, how is the office?
[09:28] <didrocks> "good" news, if you try to apply updates via GNOME Software, at least, you nothing is applied on boot, so you don't end up in a broken situation
[09:29] <seb128> ?
[09:29] <didrocks> well, you mentioned on Friday that GNOME Software update panel isn't hidden, which is a bug to fix
[09:29] <seb128> you are referring to bug #1797543 ?
[09:29] <seb128> I don't think your statement is always true
[09:29] <didrocks> ah?
[09:29] <didrocks> I have a mix of "system updates" + apps
[09:29] <seb128> we had report from foundations in bionic that it leads to screwed update when debconf is involved
[09:30] <seb128> maybe you didn't have anything with debconf
[09:30] <didrocks> could be, indeed, or maybe another package to install triggers packagekit to activate?
[09:30] <didrocks> (I'm a vanilla, default install)
[09:30] <seb128> well, that prompt kicks in the offline updates from packagekit
[09:31] <seb128> so if you reboot it does install updates in background I think
[09:31] <didrocks> which did nothing at all for me (no update, nothing)
[09:31] <seb128> nothing visible
[09:31] <seb128> you are sure it didn't install them in a way you didn't notice?
[09:31] <didrocks> I checked the package list and version before/after
[09:31] <didrocks> identical
[09:31] <seb128> k, another bug then :p
[09:31] <seb128> it "worked" for some people in bionic
[09:31] <didrocks> well, a "good" one in that case :)
[09:31] <didrocks> yeah :/
[09:31] <seb128> so either that "regressed"
[09:31] <seb128> or it's random
[09:32] <didrocks> could be, tried twice to ensure…
[09:32] <seb128> anyway I would prefer if Robert fixed it, he knows what to change from his comment on the bug
[09:32] <seb128> but I think he called it a day without having uploaded anyway
[09:32] <didrocks> or maybe you install something else which then hook up in the boot
[09:32] <seb128> unsure how much it's a release vs SRU issue
[09:32] <didrocks> yeah, as I didn't see anything coming, I wanted to check how bad that was
[09:42] <Laney> hey seb128
[09:42] <Laney> it's alright yeah
[09:46] <didrocks> seb128: do you know if there is any particular fixes we are interested in on new evince for bionic?
[09:48] <Trevinho> jibel: kvm yes... and i think is the same of willcooke one, I've spent some time on it already.
[09:49] <Trevinho> And looking at it still
[09:49] <Trevinho> seb128: hi seb, ok
[09:55] <jibel> Trevinho, I didn't try on kvm but I cannot reproduce it anymore on hw
[09:56] <Trevinho> jibel: kvm on qxl happens here. Time dependent a sleep fixes it
[09:56] <Trevinho> andyrock: ^
[09:58] <didrocks> seb128: (as you just left when I posted that): do you know if there is any particular fixes we are interested in on new evince for bionic?
[09:58] <didrocks> like some particular checks I should put in the test case?
[09:59] <seb128> not that I know no, sorry
[09:59] <didrocks> no worry, preferred to double check!
[09:59] <didrocks> I'll discuss the ps thingy with our security team though
[09:59] <didrocks> to ensure that's ok
[11:18] <andyrock> Trevinho: cannot run libvirt-bin.service here so I cannot test
[12:13] <Trevinho> seb128: I've pushed nautilus branches for both cosmic and bionic.
[12:17] <seb128> Trevinho, bionic is another regression fix for the current SRU?
[12:18] <Trevinho> seb128: it's fixing the pkg in sru queue
[12:19] <Trevinho> seb128: so, I was wondering if mentioning the bug in changelog or not, but for sure it doesn't need classic verification
[12:23] <seb128> Trevinho, if there was not git to deal with I would just re-upload to replace the current SRU from the queue without changing the version/changelog/bug reference
[12:24] <seb128> unsure what to do with the vcs in that case though
[12:26] <Trevinho> seb128: well, we can still do some force pushes, but not sure :-P
[12:27] <seb128> yeah, it would be bzr I would bzr uncommit; change; bzr commit; bzr push --overwrite
[12:28] <seb128> just how do that with git doesn't stick for me, or it feels too hackish
[12:28] <Trevinho> seb128: you can do the same on git, l_aney wouldn't like it but I can give you the recipe for the happiness if you want xD
[12:29] <seb128> haha
[12:29] <seb128> what happens if you tag again the same revision? it moves the tag to the new commit?
[12:29] <seb128> I mean tag again using the same tag string
[12:29] <seb128> not tagging the same commit id
[12:45] <Laney> it is exactly the same level of hackiness as it would be with bzr
[12:48] <Laney> you have to delete the tag and then re-tag
[12:55] <jbicha> seb128: by default anyone who has pulled the old tag won't get the new tag so if you think people might have the old tag, it may be better to use a new tag name
[12:55] <jbicha> also version numbers are cheap so it might just be easier to use a higher version number
[12:56] <jbicha> good morning
[12:59] <didrocks> morning jbicha
[12:59] <seb128> hey jbicha
[13:01] <seb128> jbicha, is that a bug that people won't get the tag change or by design?
[13:02] <jbicha> that's git upstream. I guess it's intentional
[13:03] <seb128> :(
[13:03] <jbicha> willcooke: I experience something that looks kinda like bug 1796822 if I enable automatic login in Settings > Details > Users then reboot (using VirtualBox after installing cosmic)
[13:05] <jbicha> do you think Debian bug 910892 is worth handling now in cosmic? (by uncommenting those header lines)
[13:06] <seb128> that doesn't seem important enough to be accepted now
[13:07] <seb128> could be a SRU though
[13:07] <jbicha> seb128: because it would trigger a debconf prompt for anyone who has modified those files, I don't think it's very good for an SRU
[13:07] <jbicha> or maybe it wouldn't trigger debconf, it's a strange file
[13:11] <didrocks> well, it's fine for a 0-day SRU, as it's only for updates
[13:13] <seb128> or it's fine for cosmic+1
[13:13] <seb128> it's only an issue for users who sudo edit a conffile
[13:13] <seb128> and screw their editing
[13:48] <Laney> somebody want to look into https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1796275 ?
[13:48] <seb128> on a similar topic bug #1797861
[13:48] <Laney> yes I already looked at that one
[13:48] <seb128> ah ok
[13:48] <Laney> similar in that it's about screen reader at least
[13:48] <Laney> but it's probably not the same bug
[13:49] <seb128> right, I just saw it passing by in my morning review of "recent bugs"
[13:49] <Laney> okies
[13:49] <Laney> so, anyone?
[13:49] <seb128> didrocks, ^ interested? if not I'm going to have a look
[13:50] <didrocks> seb128: I can, unsure though to have enough time before EOD
[13:50] <didrocks> so, don't expect a fix necessarily tonight
[13:50] <seb128> I don't
[13:50] <seb128> thx didrocks!
[13:50] <didrocks> yw ;)
[13:51] <Laney> merci
[13:51] <seb128> Laney, how are things looking from a London/r-t perspective atm?
[13:51] <Laney> xnox is looking into http://launchpad.net/bugs/1795882
[13:52]  * didrocks update-iso first
[13:52]  * Laney assigns to document that
[13:52] <seb128> ah, nice
[13:52] <seb128> plymouth is not happy in cosmic
[13:52] <Laney> otherwise, going to upload ubiquity soon and then do some moar isos
[13:52] <Laney> why not?
[13:54] <seb128> e.u.c top 1-3-5-6-8 from the weekly 18.10 view are plymouth reports
[13:54] <seb128> well, look variants of the same issue
[13:59] <jibel> the main issue is bug 1794292
[14:00] <Laney> finally go the f-ing thing to load
[14:00] <jibel> which had been marked fixed but is not. I just reopened it
[14:00]  * Laney spanks e.u.c
[14:00] <Laney> is that the one cyphermox tried to fix?
[14:00] <jibel> yes
[14:00] <Laney> nod
[14:01] <cyphermox> there's still a lot of room for improvement in plymouth
[14:03] <Trevinho> I also had a look in that some weeks ago
[14:04] <Trevinho> and I had some further ideas, that I thought were handled by that change, but it seems not.. .I see if  i can get something out of my stashes later
[14:04] <Trevinho> while in the gdm side of things..
[14:04] <Trevinho> https://pastebin.ubuntu.com/p/VzqX2JQw4D/
[14:07] <Laney> NON ESISTENTE
[14:28] <cyphermox> I have a possible fix, if it's breaking for the reason I think it is
[14:31] <cyphermox> jibel: were you able to reproduce the crash? I can't
[14:32] <jibel> cyphermox, no I cannot anymore
[14:33] <cyphermox> so I fixed your crash, but not all of them?
[14:35] <jibel> I am not sure what fixed it actually
[14:36] <Trevinho> Laney: exactly... is it normal that we're at that point with no devices around, who should be in charge of waiting them? I wouldn't think is gdm job. is it?
[14:37] <didrocks> jbicha: are you looking at gdm3 which is stuck in proposed?
[14:37] <didrocks> (didn't look at it at all)
[14:38] <jbicha> didrocks: either we need to ignore the systemd autopkgtest or retry it until it works. I think it is more likely to pass when the amd64 autopkgtest builders aren't as busy
[14:39] <jbicha> gdm was stuck for a few days because we had to handle the s390x removal again
[14:39] <didrocks> jbicha: ok, seems like you are retrying/looking at it
[14:40] <jbicha> sort of. We're running low on time for it to get in the iso's though
[14:42] <didrocks> maybe check with the release team if they are happy discarding autopkgtest results?
[14:43] <jbicha> infinity: ^ do you want to force gdm3 in now?
[14:44] <infinity> jbicha: We're on it.
[14:58] <Laney> Trevinho: dunno
[14:59] <Laney> how come plymouth works?
[15:03] <Trevinho> using fb?
[15:13] <Laney> not the graphical splash no?
[15:37] <seb128> jbicha, ricotz, did you see that the SRU team had a question on bug #1782122?
[15:50] <Trevinho> ffffffffffffffffff  broke my kvm :(
[18:04] <bob91> Hi guys
[18:05] <bob91> anyone knows how to speed up gnome-shell performance with nvidia driver on ubuntu 18 ?
[18:39] <oSoMoN> bob91, that's a very vague question, are you seeing specific performance issues that you think a driver update might solve?
[18:40] <oSoMoN> note that we have people actively working on gnome-shell performance in general
[18:56] <willcooke> gnight all.  Laney I think I can come down tomorrow now, but probably not until just before lunch.
[18:56] <willcooke> Should see you tomorrow
[19:03] <oSoMoN> good evening all
[20:15] <Trevinho> Laney: world is strange indeed https://usercontent.irccloud-cdn.com/file/PFdG0Rz4/CanGraphical.png
[20:17] <Trevinho> And in fact here, with that gdm proposed change, it doesn't run. Because `sd_seat_can_graphical' will always return false.
[20:35] <kyrofa> Hey kenvandine, Trevinho can you two think of a CLI hello-world-type example that I can use as a test that the new glib extension works?
[20:36] <kyrofa> g_print hello world works with or without the desktop-launch stuff, so that's not quite enough to exercise it
[20:41] <Trevinho> kyrofa: by new extension you mean? like new functions?
[20:41] <kyrofa> Trevinho, new version of the desktop helpers
[20:43] <Trevinho> kyrofa: mh not sure I got it... You want to check if new version of desktop-helpers is running?
[20:43] <Trevinho> or in general if those are running?
[20:43] <kyrofa> Trevinho, but basically, my question could be rephrased as "can you think of a hello-world type simple CLI application that verifies that the desktop-glib part works" ?
[20:43] <Trevinho> kyrofa: ok.... things like checking mime types could be a way
[20:44] <kyrofa> Ah, let me give that a try, thank you
[20:44] <Trevinho> so using gfile maybe? Or a simple gtk app?
[20:44] <Trevinho> well gtk app as cmd line I mean
[20:44] <Trevinho> like just passing --help :)
[22:11] <Laney> Trevinho: think you need the latest version of the branch
[22:11] <Laney> but I'm saying (many times :P) that I'm not convinced the CanGraphical thing is the right place to be looking
[22:11] <Laney> UNLESS the reason it goes to =no is the same reason that it's breaking sometimes
[22:12] <Laney> I think andyrock was next going to investigate what makes it change to 'no'
[22:13] <andyrock> yeah I'll do that tomorrow
[22:14] <Laney> ♥