[07:06] <oSoMoN> good morning desktoppers
[07:06] <duflu> Morning oSoMoN
[07:15] <jibel> morning all
[07:20] <duflu> Hi jibel
[07:25] <oSoMoN> hey duflu, salut jibel
[07:28] <jamesh> tkamppeter: I gave some feedback on your CUPS thread here: https://forum.snapcraft.io/t/interface-request-cups-control-on-cups-snap-and-including-d-bus/15233/12?u=jamesh
[07:44] <didrocks> good morning
[07:46] <duflu> Hi didrocks
[07:49] <didrocks> hey duflu
[08:25] <oSoMoN> salut didrocks
[08:26] <didrocks> hello oSoMoN
[09:02] <Laney> yo yo yo
[09:06] <didrocks> hey Laney
[09:10] <seb128> goood morning desktopers!
[09:11] <Laney> moin didrocks seb128
[09:13] <seb128> hey Laney, how are you today?
[09:15] <Laney> alright, I stood outside in the sun for five minutes this morning
[09:15] <Laney> next door's cat came to say hi
[09:16] <Laney> this is life atm
[09:16] <Laney> you?
[09:18] <duflu> Morning Laney and seb128
[09:19] <oSoMoN> hey Laney, salut seb128
[09:22] <seb128> Laney, I'm good, just adventured a trip to the local supermarket to get some stock
[09:22] <seb128> hey duflu, how are you?
[09:22] <seb128> oSoMoN, salut, en forme ?
[09:22] <Laney> guten morgen duflu und oSoMoN
[09:22] <didrocks> good morning seb128
[09:22] <Laney> indiana seb128 jones with that trip
[09:23] <duflu> seb128, dazed by a few windowing regressions in 3.36.0 that came from the icon fade fix. Just doing final testing of the new fix now though
[09:23] <seb128> Laney, :)
[09:23] <seb128> lut didrocks
[09:23] <seb128> duflu, :-/
[09:23] <seb128> duflu, I guess you didn't have time for plymouth then?
[09:24] <duflu> seb128, that's less of a priority but it will be this week
[09:24] <seb128> didrocks, do you remember how you used the fsck mock in systemd?
[09:24] <seb128> I tried (bionic and focal) to sudo plymouthd --no-daemon --debug
[09:24] <seb128> and sudo ./fsck
[09:25] <seb128> but the splash screen doesn't display anything
[09:25] <seb128> I wonder if that was already broken in bionic?
[09:25] <seb128> or that way to start plymouth manually in debug is different from the boot mode
[09:25] <seb128> but it's weird because it shows the same screen and displaying message or the ask password entry works...
[09:36] <oSoMoN> seb128, ça va, et toi?
[09:36] <seb128> oSoMoN, ça va bien :)
[09:39] <Wimpress> Morning desktoppers o/
[09:42] <seb128> hey Wimpress, how are you?
[09:45] <Wimpress> All fine here.
[09:45] <duflu> Morning Wimpress
[09:45] <Wimpress> Typically, wonderful weather now we're confined to quarters.
[09:45] <Wimpress> duflu: Hi
[09:46] <Wimpress> Any luck debugging Plymouth?
[09:46] <duflu> Wimpress, no time for that today. Had to fix some issues in the new gnome-shell
[09:46] <oSoMoN> morning Wimpress
[09:46] <duflu> But will get back to plymouth this week
[09:47] <Wimpress> duflu: Understood.
[09:47] <Wimpress> OSoMoN o/
[09:47] <Wimpress> How is everyone? All well?
[09:51] <seb128> doing well indeed!
[09:52] <seb128> Wimpress, did you have a chance to try if you could see the fsck integration working? I tried on bionic with a force check and the mock didrocks pointed me at and it doesn't work here, I wonder if that's a local issue or if that has been not working for several cycles now
[10:03] <chihchun> Laney: ping
[10:04] <Laney> chihchun: eeeeek sorry
[10:04] <Laney> I'll be with you in a minute!
[10:07] <duflu> seb128, one thing I did not try yet was an older release than eoan
[10:07] <duflu> Although I should get dinner sorted instead of restarting on plymouth
[10:08] <seb128> duflu, hey, enjoy your evening! I tried on bionic without luck so far :-/
[10:09] <duflu> Oh that is odd
[10:09] <didrocks> seb128: IIRC, I was replacing the binary on the system and just call it via systemd-fsckd or directly on boot
[10:10] <didrocks> calling directly fsck won’t work because you miss the part which forward to plymouth
[10:10] <seb128> didrocks, ah. What do you mean by "call it via systemd-fsckd"? do you remember how one does that?
[10:11] <duflu> seb128, the only visual evidence I can find of it working last (Google Images) was 10.04 :)
[10:11] <didrocks> been some years, I don’t remember, let’s look at systemd autopkgtests
[10:12] <didrocks> (debian/tests/systemd-fsckd)
[10:12] <didrocks> the autopkgtests install fsck
[10:12] <didrocks> and reboots
[10:12] <duflu> Make that 12.10 and 14.04
[10:13] <didrocks> which is the easiest way to test
[10:13] <seb128> didrocks, I'm reading that autopkgtest as well now
[10:13] <didrocks> I remember to have run it directly while iterating
[10:14] <didrocks> but I don’t remember anymore how to do it easily, it was tricky because plymouth itself wasn’t showing the splash reliably at the time
[10:14] <seb128> yeah, plymouthd --no-daemon --debug doesn't work on my xenial
[10:14] <seb128> it sends me to a vt
[10:15] <seb128> works fine nowadays, on bionic/focal though
[10:15] <didrocks> seb128: maybe vm + reboot it easiest?
[10:15] <didrocks> however, I see now that we have /run/initramfs/fsck-root
[10:16] <didrocks> and I have it on my systemd
[10:16] <didrocks> system*
[10:16] <seb128> didrocks, it's slow iteration if you need to login, open text editor again, etc for each try
[10:16] <didrocks> someone added:
[10:16] <didrocks>     if os.path.exists('/run/initramfs/fsck-root'):
[10:16] <didrocks>         print('SKIP: root file system is being checked by initramfs already')
[10:16] <didrocks>         sys.exit(0)
[10:16] <didrocks> to the tests
[10:16] <didrocks> so maybe we are now running fsck on the initramfs without user feedback?
[10:16] <didrocks> (for the root at least)
[10:17] <seb128> that would explain why I'm not seeing anything on plymouth when I do a /forcefsck and reboot
[10:17] <didrocks> yeah
[10:17] <didrocks> I’m sure I didn’t write that, so it’s post our implementation
[10:18] <didrocks> I don’t remember to have seen fsck moving in the initramfs being announced anywhere
[10:18] <didrocks> or the impact to not have feedback discussed
[10:18] <jibel> tkamppeter, hey, printer discovery stopped working in focal and I get this crash https://bugs.launchpad.net/bugs/1868944
[10:20] <didrocks> (this was only for dracut at the time and we didn’t have it)
[10:20] <didrocks> I think one way would be at least to try with a vm with 2 disks
[10:20] <didrocks> (and the mock)
[10:21] <didrocks> at least to remove the "only one disk is skipped" idea
[10:21] <seb128> didrocks, it's unclear to me what the mock is useful for on that case/how to use it?
[10:21] <didrocks> seb128: it’s slowing down the fsck
[10:21] <didrocks> so that you have the time to see it
[10:21] <seb128> didrocks, just forcing a disk check should make it display the events on plymouth through normal system integration?
[10:22] <seb128> ah
[10:22] <didrocks> well slowing down by emulating what fsck prints
[10:22] <didrocks> but yeah, you need to force a check with multiple disks
[10:23] <seb128> didrocks, so how to I set up the mock? replace the systemd binary with the fsck from the test dir?
[10:24] <didrocks> seb128: not the systemd binary, your system fsck
[10:24] <seb128> ah
[10:24] <didrocks> /sbin/fsck
[10:24] <seb128> thx, let me try
[10:25] <didrocks> but yeah, 2 disks at least + /forcefsck
[10:33] <seb128> didrocks, so yeah, the skip was added in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782522
[10:33] <seb128> by Debian
[10:34] <didrocks> ack, so at least if you have multiple disks, the message should still be there
[10:34] <didrocks> for secondary ones
[10:35] <FourDollars> ./whois Laney:
[10:35] <FourDollars> ha
[10:35] <FourDollars> Laney: What do you want to do with oem-qemu-meta?
[10:37] <Laney> :D
[10:37] <Laney> FourDollars: We need a corresponding upload to Ubuntu to point the sources.list to the new archive layout
[10:39] <FourDollars> Laney: OK. What is the next step I can do?
[10:39] <FourDollars> Laney: Make a merge proposal?
[10:40] <Laney> FourDollars: diff / PPA package to upload
[10:40] <Laney> I guess you want to import this into your own vcs too
[10:41] <FourDollars> Laney: OK. Let me import it, make the change and then upload to my Launchpad Git repo.
[10:42] <Laney> thanks!
[10:42] <FourDollars> np
[10:46] <Laney> FourDollars: BTW you don't need to add "XB-Ubuntu-Kernel-Flavour: oem", that is the default
[10:47] <FourDollars> Laney: We want to make it clearer. Will it cause any problem?
[10:47] <Laney> bit of extra space used in the Packages file which is downloaded by everyone
[10:48] <Laney> but not hugely
[10:55] <FourDollars> OK. I will discuss it with others.
[10:59] <FourDollars> Laney: https://code.launchpad.net/~fourdollars/+git/oem-qemu-meta/+ref/master
[11:01] <Laney> great, thanks, I will look soon
[11:14] <xnox> seb128:  Wimpress: the fsck integration does work with the ubuntu-logo theme..... i can trigger it correctly with e.g. plymouth-x11 in userspace. I guess i need to record videos.
[11:18] <seb128> xnox, would help if you were giving us steps how to test it it, would help also working on fixing spinner
[11:19] <seb128> xnox, same for casper, if you have any debug hint on how to get in an env to be able to hack/iterate
[11:19] <seb128> xnox, also looks like / and /usr checks are done in initramfs nowadays and not showing on plymouth?
[11:20] <Saviq> Trevinho: hey, would that be an issue with the app indicator, or gnome-shell itself https://github.com/canonical/multipass/issues/1444 ?
[11:20] <gitbot> canonical issue 1444 in multipass "Difficult to navigate to Shell in long list of VMs" [Bug, Open]
[11:20] <xnox> seb128:  yeah, one needs like separate /home
[11:21] <xnox> seb128:  indeed checks for / and /usr are done in the initramfs, but for those too we should have pretty plymouth integration
[11:21]  * xnox is sad
[11:21] <seb128> xnox, 'should' like would be nice to add or like should be working today?
[11:21] <xnox> seb128:  bah =) "should one day" =)
[11:21] <seb128> because touch /forcefsck and reboot displays no fsck integration on bionic for me
[11:21] <seb128> k
[11:22] <seb128> xnox, so that integration is not working in most cases, I wouldn't consider the regression rc
[11:22] <xnox> seb128:  it should be there for the initrd-less boot right
[11:22]  * xnox ponders things
[11:22] <xnox> seb128:  but the casper one should work.
[11:22] <seb128> yes
[11:22] <seb128> the theme does support messages
[11:22] <xnox> seb128:  cause the casper integrety check uses the same fsck:*status messages
[11:22] <seb128> if I plymoutd --no-daemon --debug
[11:22] <xnox> which are not shown in spinner theme
[11:22] <seb128> and ssh to the box use plymouth --message it does display the string
[11:23] <xnox> one can run casper thing from userspace without booting anything, on a devel laptop, I'll take some videos
[11:23] <seb128> xnox, do you have any debugging hint how to test the fsck/md5 integration?
[11:23] <seb128> like start plymouth by end
[11:23] <seb128> ssh
[11:24] <seb128> and start the casper script?
[11:25] <xnox> pull-lp-source casper; make in casper-md5sum; mount iso in /cdrom, and execute ./casper-md5sum /cdrom /cdrom/md5sum.txt  => without plymouth that will be just text output
[11:25] <seb128> xnox, thx, that's useful
[11:25] <xnox> if one starts X11 plymouth, and controls it from a separate tty, does show spash, and execute casper-md5sum again it would show all the pretty stuff with three lines of messages
[11:26] <xnox> one line with fsck progress, one line with keycodes for skipping the check, and another one for any other messages / final message.
[11:26] <seb128> xnox, is plymouth x11 needed/more useful that real plymouth?
[11:26] <seb128> doing sudo plymouth --no-daemon --debug starts plymouth on a VT
[11:27] <seb128> with a ssh prompt that seems to work fine for debugging
[11:27] <seb128> unsure what else x11 provides?
[11:27] <xnox> seb128:  i like x11 plymouth, as i run it direct on my development laptop / host, without booting any VMs.
[11:27] <xnox> one can do all of that in a VM too using "real" plymouth, and like stopping gdm/gnome-shell over ssh first
[11:27] <xnox> if one prefers to have separate thing.
[11:28] <seb128> xnox, well, what I just described seems to do the same
[11:28] <xnox> i guess preference =) and how one did it first =)
[11:28] <seb128> I do that on my real laptop
[11:28] <seb128> or does x11 does windows mode in session?
[11:28] <xnox> if casper-md5sum can ping plymouth, it will push fsck messages to plymouth, but it doesn't do show-splash byitself, so any connection to any plymouth which is showing splash is good.
[11:29] <xnox> i find x11 backend a bit crap, compared to the DRM one. There is smething with clock synchronisation, one kind of has to wiggle mouse for it to progress.
[11:29] <xnox> besides this.
[11:30] <xnox> seb128:  is there any other patches/updates that i can test? i.e. have there been any gdm / shell / plymouth changes that improve any aspects of flickerness already? I saw some comment updates, but not sure if they are in teh Archive yet.
[11:31] <seb128> xnox, not at this point, only a new logo with better resolution in the archive
[11:31] <xnox> seb128:  cool, and the logo is in gdm, plymouth, or both?
[11:31] <seb128> gdm and plymouth
[11:31] <xnox> nice =)
[11:31]  * xnox should upgrade & reboot
[11:32] <xnox> seb128:  any more visual direction from design/ux/yaru? or more of do whatever?
[11:32] <seb128> xnox, not yet, but Wimpress has a catchup with design tomorrow
[11:32] <xnox> cool cool
[11:33] <seb128> xnox, good, your md5sum testing hint with
[11:33] <seb128> (need to sudo start it though)
[11:33] <seb128> it's going to make easier to debug
[11:33] <seb128> bah
[11:34] <seb128> xnox, doing that it shows the md5 messages on spinner/bgrt as well...
[11:35] <seb128> xnox, https://people.canonical.com/~seb128/plymouth/checksum.jpg
[11:36] <seb128> xnox, could it be also a case of files missing from the cache in casper like shutdown?
[11:41] <seb128> xnox, also https://people.canonical.com/~seb128/plymouth/new.jpg
[11:41] <xnox> seb128:  that's incomplete
[11:41] <xnox> there should be three lines
[11:42] <seb128> xnox, I saw the 3 lines earlier
[11:42] <xnox> "checking filepath" "Fsck in progress 1 of 1 (40% complete" "Press S to skip"
[11:42] <seb128> xnox, still it does show one line at least locally so I wonder why on the ISO it doesn't?
[11:42] <xnox> and the first two should smoothly update
[11:43] <xnox> one should always see the correct % progress, the filepath names scrolling, and the keycode message for how to skip if one got bored.
[11:43] <seb128> right, at least it makes easy to test/fix that
[11:43] <seb128> still the liveCD doesn't display anything
[11:43] <seb128> so there is another bug on that env ... any idea how to debug that one? could be missing cache in casper?
[11:45] <xnox> well fsck is on boot; so there shouldn't be anything missing from cache; things might be missing from the initrd. As if incomplete spinner theme copied into the casper initrd or somesuch?!
[11:45] <xnox> i guess again, we need to boot with debug plymouth log to see what is happening.
[11:45] <xnox> plus doesn't spinner theme like "delay" showing splash on boot? or is that a fedora only thing?
[14:16] <tkamppeter> seb128, debian bug 954885
[14:16] <seb128> tkamppeter, hey, I saw, you Cc-ed me on the email :)
[14:17] <tkamppeter> seb128, OK, hope they will answer soon.
[14:18] <seb128> tkamppeter, if not I will upload to Ubuntu this week, ok?
[14:18] <tkamppeter> seb128, OK, thanks.
[14:19] <hellsworth> good morning desktopers
[14:25] <didrocks> good morning hellsworth
[14:26] <hellsworth> hi didrocks !
[14:34] <mdeslaur> seb128: hi! what regressions were you seeing with webkit2gtk that required the ppc64el fix? I'm wondering if I need it for eoan and bionic too
[14:35] <seb128> mdeslaur, hey, the rendered just segfaulted on ppc64el, couldn't display any page in the MiniBrowser
[14:35] <seb128> mdeslaur, which got caught by the ruby-gnome autopkgtest failing
[14:36] <seb128> mdeslaur, https://bugs.webkit.org/show_bug.cgi?id=209236
[14:37] <mdeslaur> seb128: ah! I think I'm hitting that autopkgtest failure too, thanks for the info!
[14:37] <seb128> mdeslaur, np!
[15:02] <ijohnson> hey folks, after an update from focal-proposed this morning, I can no longer scale my monitors using Settings, when I try to hit Apply, gnome-control-c in the system journal complains with `Config not applicable: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Logical monitors overlap` and reverts back to 100% after the timeout (and my monitors are blank during this time)
[15:03] <ijohnson> is this a known bug, or is there something I can do to set the scaling for my monitors some other way? all my text is now very small :-)
[15:09] <ijohnson> (and if it helps I'm on x11 with default gnome window manager)
[15:23] <Trevinho> ijohnson: are you using experimental x11 scaling?
[15:23] <ijohnson> Trevinho: yes I was
[15:23] <ijohnson> well still am, it's just not scaled at all due to the issue I mentioned
[15:24] <Trevinho> ijohnson: yeah... Ok thanks, I'll look into this, there was a rewrite on the xrandr code that may have changed some aspect I wasn't aware of.
[15:24] <Trevinho> need to retry again in multimonitor the
[15:24] <Trevinho> need to retry again in multimonitor then
[15:24] <Trevinho> ijohnson: I suppose it works for you in single mode right?
[15:24] <ijohnson> Trevinho: not sure, let me check
[15:25] <Trevinho> ijohnson: also, do you have some logging from `journalctl /usr/bin/gnome-shell -b0` that may help?
[15:25] <ijohnson> Trevinho: nope still reverts to 100%, even with only one monitor connected
[15:25] <ijohnson> Trevinho: sure one moment I can pastebin it
[15:29] <ijohnson> Trevinho: https://pastebin.ubuntu.com/p/Pwyn7b9gHc/
[16:19] <Trevinho> ijohnson: that's weird as I've it working with one monitor locally... mhmhm
[16:20] <ijohnson> Trevinho: also if it makes a difference I am using proprietary nvidia drivers
[16:21] <Trevinho> ijohnson: it might, but it used to work fine with them as well
[16:21] <Trevinho> so... not sure
[16:21] <Trevinho> looks more a logic issue than driver one
[16:22] <ijohnson> happy to provide more debugging info if needed, I'm a bit busy right this moment, but will be more available in an hour or so
[16:22] <Trevinho> ijohnson: this looks to be the issue in your log Failed to read monitors config file '/home/ijohnson/.config/monitors.xml': Logical monitors not adjacent
[16:22] <Trevinho> ijohnson: no worries, open a bug once you've a sec
[16:22] <ijohnson> Trevinho: do you want that file ?
[16:22] <ijohnson> what project should I file the bug against ?
[16:23] <Trevinho> ijohnson: mutter
[16:23] <Trevinho> in ubuntu only though
[16:25] <ijohnson> Trevinho: ack running `apport-bug mutter` now
[16:25] <Trevinho> thanks
[16:26] <xnox> oSoMoN:  hey, firefox re-enabled TLS v1.0/v1.1 because of governments not supporting v1.2 for covid-19 information; have we done that in our firefox now as well? and if not, can we get that uploaded?
[16:29] <ijohnson> Trevinho: reported as https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1869042
[16:34] <oSoMoN> xnox, I'm not seeing any new builds of firefox 74, i wonder how that revert works
[16:34] <JanC> xnox: what governments are that?
[16:35] <xnox> oSoMoN:  let me find that.
[16:36] <xnox> JanC:  i don't know, but Chrome & Firefox rolled back and enabled TLSv1.0/v1.1
[16:36] <xnox> *re-enabled
[16:36] <JanC> maybe they'd better offered help to those governments to fix their servers...  :-/
[16:37] <Trevinho> ijohnson: I've just tried in my focal system with various configurations though, and it all works fine there....
[16:37] <Trevinho> quite weird then, *might* be somewhat related to nvidia but can't be sure
[16:37] <ijohnson> hmm, do you want that monitors.xml file ?
[16:37] <oSoMoN> xnox, that appears to be https://bugzilla.mozilla.org/show_bug.cgi?id=1623534
[16:37] <Trevinho> yeah, could help
[16:37] <Trevinho> ijohnson: weird that apport didn't attach that
[16:38] <Trevinho> ijohnson: also your gnome-control-center version may make a difference
[16:38] <ijohnson> I'll put it in the bug actually
[16:38] <oSoMoN> xnox, if this is using Normandy, then there's nothing needed on our side, the pref is applied remotely
[16:40] <ijohnson> Trevinho: how do I check the gnome-control-center version ?
[16:40] <ijohnson> (also attached the monitors.xml in the bug)
[16:42] <seb128> ijohnson, dpkg -l | grep gnome-control-center
[16:43] <ijohnson> thanks seb128, Trevinho looks like I have `1:3.36.0-0ubuntu3`
[16:43] <seb128> ijohnson, also a known issue is that sometime the monitors do overlap on the graphical view of the settings panel, did you try to move them to make there they are snapped/correctly aligned?
[16:43] <ijohnson> seb128: yes I tried to move them around to make them snap together/correctly aligned
[16:43] <ijohnson> (in the settings window that is)
[16:43] <seb128> k
[16:46] <xnox> oSoMoN:  I think, yes.
[16:46] <xnox> oSoMoN:  what is Normandy? =)
[16:46] <xnox> oSoMoN:  i thought there was code fix too on tip, for when normandy is not involved, such that we can out of the box be correct too.
[16:48] <oSoMoN> xnox, https://wiki.mozilla.org/Firefox/Normandy/PreferenceRollout
[16:52] <xnox> hm
[16:52] <xnox> oSoMoN:  I'm reading this https://github.com/mozilla/gecko-dev/commit/506fbc64931400548cfaa88b552cbe1d99562fdd
[16:52] <xnox> so it set security.tls.version.min to 3 only in nightly builds; but it remained as 1 in release builds?
[16:53] <xnox> such that switch to v1.2 as minimum, in release, was only done via Normandy, and reverted in Normandy, right?
[16:54] <xnox> oSoMoN:  because in our firefox, I see that: pref("security.tls.version.min", 3); in ./modules/libpref/init/all.js meaning we have tls v1.0/v1.1 disabled
[17:01] <oSoMoN> xnox, no, it was set to 3 in release builds, and that's the default value we ship, but normandy overrides it with 1
[17:01] <oSoMoN> just tested in a bionic VM, the value is initially 3, but gets overridden to 1
[17:02] <oSoMoN> (use about:config to inspect the value)
[17:07] <xnox> oSoMoN:  it should be initially 1
[17:07] <xnox> oSoMoN:  can we patch that? (i.e. such that if one cannot talk to normandy, but can talk to whitlisted gov.* websites, tls v1.0/v1.1 is enabled, and it works correctly)
[17:08] <xnox> oSoMoN:  shall i file a bug for it?
[17:11] <oSoMoN> xnox, normandy is an essential component of firefox's preferences system, if one cannot talk to it that's bad luck but I don't think that warrants rebuilding firefox and pushing updates for everyone
[17:12] <oSoMoN> at the very least this would require a report of such a thing actually happening in the wild
[17:20] <xnox> oSoMoN:  we will rebuild firefox right? so how can this change be staged for the next rebuild of firefox?
[17:20] <xnox> i'll open a bug report.
[17:22] <oSoMoN> xnox, we will rebuild if there's a new point release, or when 75 is released, but we shouldn't change the default value from upstream, because if/when they decide to switch it back via normandy, the default value should match with their expectation
[18:00] <xnox> oSoMoN:  ok. I wonder if i can find the source code for the 74 branch, to see what they have committed upstream.
[18:13] <ricotz> oSoMoN, hi, I have pushed the firefox branches
[18:13] <ricotz> oSoMoN, the python3 port should be good for 76
[18:14] <ricotz> oSoMoN, did we agree on targetting nasm 2.14 for 75 already? I haven't transitioned bionic yet, this can be done with beta 9
[18:39] <oSoMoN> ricotz, yeah, that's fine by me
[18:41] <oSoMoN> good night all
[20:14] <kenvandine> hellsworth: amd64 build of gnome-3-34-1804-sdk is in candidate