[01:17] <duflu> jamesh, one IRC server short?
[01:17] <jamesh> hmm?
[01:19] <duflu> I had not tried turning of and on again :)
[01:19] <duflu> -of +off
[05:30] <oSoMoN> good morning desktoppers
[05:30] <duflu> Morning oSoMoN
[05:34] <Wimpress> Morning oSoMoN duflu o/
[05:35] <duflu> Hi Wimpress
[06:09] <oSoMoN> hey duflu, Wimpress
[06:14] <jibel> hi all
[06:14] <oSoMoN> salut jibel
[06:14] <didrocks> good morning
[06:14] <oSoMoN> salut didrocks
[06:17] <Mirv> morning ubuntudesktopers
[06:18] <oSoMoN> good morning Mirv
[06:19] <oSoMoN> how are things?
[06:19] <didrocks> good morning oSoMoN, Mirv
[06:19] <Mirv> hello oSoMoN, didrocks
[06:20] <Mirv> oSoMoN: still calling 'apt' on my SUSE, luckily they've a compatibility wrapper to zypper which works :D
[06:20] <oSoMoN> :)
[06:20] <oSoMoN> muscle memory… I sometimes find myself typing "bzr" instead of "git"…
[06:20] <Mirv> life's good, it's nice to maintain things in multiple distros a bit
[06:26] <jamesh> oSoMoN: I know the feedback is kind of late, but do you have any thoughts on what I wrote here: https://forum.snapcraft.io/t/how-to-expose-desktop-files-created-by-snaps-to-the-de/2853/14?u=jamesh ?
[06:33] <mvo> against what package should I report a bug that in eoan after a login I need to go to sound settings and switch to the right output-device before I get audio? is that gnome-settings?
[06:36] <oSoMoN> jamesh, I'll make sure to reply to your post later today
[06:37] <jamesh> mvo: it's probably pulseaudio, I'd think
[06:38] <mvo> jamesh: thanks, I will report there then. anyone in particular in the team who knows about this?
[06:38] <jamesh> oSoMoN: I don't know when I'll have time to look at it, but it'd be good to know whether there's anything specific to Chrome's requirements
[06:38] <jamesh> mvo: maybe duflu?
[06:43] <mvo> jamesh: thank you! I report it and see what happens, after a couple of days of switching the output manually every day I will start pestering someone here again :)
[06:44] <jamesh> mvo: what sort of sound devices is it bouncing between?
[06:44] <jibel> mvo, do you have the bug #? i've had this bug for a while and couldn't find the one I filed. I'll confirm it
[06:47] <duflu> Morning didrocks, Mirv
[06:47] <duflu> mvo: Device selection is pulseaudio
[06:48] <mvo> jamesh: its a "line-out" and a "hdmi/display-port"
[06:48] <mvo> jibel: I am just now creating one, got distracted in a different channel in the middle of typing it :)
[06:48] <mvo> duflu: thanks for confirming, I will file it there
[06:49] <Mirv> morning duflu, and thank you for all the performance love you are spreading now to (at least) 3rd desktop environment.
[06:50] <duflu> Mirv, no problem...
[06:56] <mvo> jibel: bug 1847570 (I rambled a bit in the middle of the report because I feel like that finding the right setting could be easier too but I digress :)
[07:00] <mvo> hrm, it does not even remember when I just logout/login oh well
[07:03] <jibel> and also resume from suspend
[07:05] <seb128> goood morning desktopers
[07:13] <duflu> Morning seb128
[07:13] <seb128> hey duflu, how are you today?
[07:13] <didrocks> hey duflu, seb128
[07:14] <seb128> lut didrocks, en forme aujourd'hui ?
[07:14] <duflu> seb128, Kind of average but there is plenty of time for the day to improve. You?
[07:15] <didrocks> seb128: c'est ok, et toi ?
[07:15] <seb128> duflu, I think I'm fine but I'm not fully awake yet :)
[07:15] <seb128> didrocks, ça va aussi
[07:15] <seb128> let see if it's another day, another installer/release brekage!
[07:41] <seb128> Trevinho, hey, we got a report that the .1 updates broke night mode/color profiles
[07:42] <duflu> I think it's already bisected upstream
[07:42] <duflu> Just need Jonas to look
[07:42] <duflu> since it was his commit
[07:43] <seb128> right
[07:43] <seb128> still probably a release blocker so I prefer to mention it so people are aware
[07:43] <seb128> do you know if anyone directly pinged Jonas about it yet?
[07:43] <Trevinho> morning
[07:44] <duflu> In the upstream bug yes. But he likely hasn't been awake since it was logged
[07:44] <Trevinho> seb128: ok thanks... I read, let's see what upstream does and in case I look at more closely
[07:44] <seb128> hey Trevinho, how is UbuCon?
[07:44] <seb128> Trevinho, just nag Jonas, he's goin to fix it right? ;)
[07:45] <Trevinho> Yes not sure if with rush though
[07:45] <Trevinho> Good, but still to start the real one...
[07:52] <seb128> brb, going back before u.k start their day
[08:01] <Laney> yo
[08:01] <willcooke> yo yo yo
[08:02] <duflu> sup willcooke and Laney
[08:02] <willcooke> what up duflu
[08:13] <mvo> duflu, jibel fwiw, I was just testing a 19.04 live session on the same system and I get the right output device there by default, not sure if its random but if its not that feels like an eoan regression
[08:14] <duflu> mvo, Thanks. We have done no customization this cycle but have got a new upstream release
[08:14] <duflu> so many things can change
[08:16] <mvo> duflu: I can boot a couple of times to see if its random or not if that helps. just let me know :)
[08:17] <duflu> mvo, I can't find a good matching upstream bug so suggest logging one: https://gitlab.freedesktop.org/pulseaudio/
[08:17] <didrocks> &hey Laney, willcooke
[08:17] <duflu> That is unless it's caused by one of those modules we patch in for Ubuntu
[08:17] <seb128> hey Laney willcooke
[08:18] <Laney> hey duflu didrocks seb128 willcooke
[08:19] <mvo> duflu: fwiw, in 19.04 I changed my output to hdmi, logout/login and still have hdmi so something apparently changed
[08:19] <Trevinho> Hi Ianus
[08:19] <mvo> (and it may not be not the bug from 2016 that my report got dupped to)
[08:19] <duflu> Yeah I just wrote that
[08:20] <mvo> duflu: aha, cool, thank you. sorry, now read backlog. I will report a upstream bug a bit later
[08:23] <seb128> mvo, if you changge to the other output in disco does it remember? or does it just happen to prefer hdmi there?
[08:23] <seb128> like does it restore the previously selected one
[08:23] <seb128> or just go back to hdmi (which is the one you prefer as well)?
[08:30] <mvo> seb128: I only have two outputs, analog and hdmi. it seems to not remember in eoan if I switch. I want analog and it always goes to hdmi for me on login
[08:33] <willcooke> do you a dock or anything like that?  I think c_hrisccoulson reported something similar, and his was when he docked
[08:33] <willcooke> you *have a doc#
[08:33] <willcooke> dock
[08:36] <duflu> Yes that would (should) cause a switch in outputs. If you want to change that you will need to edit /etc/pulse/default.pa
[08:38] <duflu> Probably comment out: load-module module-switch-on-port-available
[09:00] <didrocks> does anyone have a secure boot machine nearby?
[09:00] <seb128> I think the inspiron 11 does secure boot?
[09:01] <didrocks> hum, is it enabled and you have a working installation with it?
[09:01] <didrocks> we need to know the kernel names in /boot
[09:01] <didrocks> like, do they have .efi.signed
[09:01] <seb128> well, I've a current eoan, unsure how to check if secure boot is active or not though
[09:01] <seb128> let me boot it
[09:02] <didrocks> sudo mokutil --sb-state​
[09:02] <Laney> this laptop i'm on now is secure booted
[09:03] <didrocks> Laney: do you mind checking the kernel file names?
[09:03] <seb128> SecureBoot disabled on my inspiron
[09:03] <seb128> sorry
[09:04] <Laney> what are you afteR?
[09:04] <Laney> just ls /boot?
[09:04] <didrocks> yep
[09:06] <willcooke> didrocks, I can reinstall in secure boot here, just say the word
[09:06] <didrocks> willcooke: if Laney can just ls, let's see
[09:06] <dupondje> $ sudo mokutil --sb-state
[09:06] <dupondje> SecureBoot enabled
[09:07] <dupondje> tell me what you need :)
[09:07] <Laney> hahah
[09:07] <Laney> everyone is joining in
[09:07] <Laney> i'm getting it
[09:07] <didrocks> Laney is on the case :)
[09:07] <jibel> ls is hard early in the morning ;)
[09:08] <dupondje> :D
[09:08] <Laney> https://paste.ubuntu.com/p/3vgv5fSmDZ/
[09:08] <didrocks> ok, that explains
[09:08] <didrocks> thanks Laney
[09:08] <Laney> busy uploading desktop-icons at the same time
[09:08] <didrocks> so, we have a lot of code in both ubiquity and grub to deal with .efi.signed
[09:08] <didrocks> for signed use case
[09:08] <didrocks> but it seems that we never have .efi.signed
[09:08] <didrocks> (extension)
[09:09] <didrocks> so, we only have a signed grub, but not a signed kernel?
[09:09] <didrocks> (it explains why some people can't be on zfs, because in grub, we are filtering "compatible" kernels)
[09:10] <didrocks> or what we thought was compatible
[09:11] <seb128> Laney, just press the button! :)
[09:11] <seb128> Marco has it in a silo
[09:11] <Trevinho> yeah, that should be enough for dock
[09:12] <Laney> yes thanks
[09:12] <Laney> I am on it, it's ok, don't worry
[09:13] <Trevinho> Be happy... Don't worry.. tu, tururu...
[09:13] <seb128> k, sorry :)
[09:16] <Laney> :-)
[09:16] <Laney> didrocks: I don't think kernels are signed efi binaries like that
[09:17] <Laney> you can see their sigs with sbverify --list tho
[09:17] <didrocks> Laney: on https://wiki.ubuntu.com/UEFI/SecureBoot, I see:
[09:17] <didrocks> "Official Ubuntu kernels being signed by the Canonical UEFI key, they are successfully validated, and control is handed over to the kernel. Initrd images are not validated."
[09:18] <Laney> right, that is true, but they aren't *efi binaries*
[09:18] <Laney> aiui anyway (I am a bit sketch on this)
[09:18] <Laney> sketchy
[09:19] <didrocks> ahhhh
[09:19] <didrocks> I think I understand what you mean
[09:19] <didrocks> like, can't be directly booted by UEFI (without grub)
[09:19] <mvo> Laney: I remember plans at least to use pe executables as kernels so that shim can verify them
[09:19] <mvo> iirc it just for the signatures
[09:19] <didrocks> weird that we have all that code to prefer .efi.signed in grub though
[09:20] <didrocks> (and in ubiquity, we deal with potential .efi.signed)
[09:20] <Laney> mvo: interesting
[09:21] <didrocks> ok, so https://packages.ubuntu.com/search?searchon=contents&keywords=efi.signed&mode=&suite=eoan&arch=any
[09:21] <didrocks> Laney: I guess you're right
[09:22] <didrocks> so, we need to unteach grub, in zfs case about this special case (when we tried to mirror 10_linux_zfs)
[09:22] <didrocks> refresh the testsuite
[09:22] <didrocks> this is going to take the day to migrate
[09:22] <Laney> v_orlon and/or c_yphermox would be more expert of course :-)
[09:23] <didrocks> yes
[09:24] <mvo> Laney: fwiw, if I run "binwalk" over my eoan kernel it tells me that it as a PE header so I think we already masquerade our kernel as a PR exe for shim. not sure if I'm stating the obvious here though :) (if so, sorry!)
[09:28] <Laney> mvo: ah, yeah, I think that I heard about something where the firmware can directly load the kernel image
[09:29] <mvo> s/PR exe/PE exe/
[09:29] <Laney> should read something about how this all fits together
[09:29] <Laney> not sure how shim would be involved if that was happening
[09:30] <didrocks> jibel: ack on https://paste.ubuntu.com/p/QRT988gXfQ/ ?
[09:30] <mvo> Laney: shim will verify the signature of the kernel, it only understands PE executables AIUI. which (again AIUI) is the reason we make the kernel look like a pe executable
[09:31] <mvo> Laney: I'm not sure we actually have good docs on this :/ I learned what I know mostly by listening to steve :)
[09:31] <jibel> didrocks, it's weird to have a case structure with a single statement
[09:31] <mvo> (and I may still have an incomplete picture)
[09:31] <didrocks> I wonder why we have patches for .efi.signed
[09:31] <jibel> it's equivalent to an if
[09:31] <didrocks> jibel: want to be more adventurous and changing it? :p
[09:32]  * didrocks is thus going to us test
[09:32] <jibel> didrocks, it's ok with a comment then
[09:34] <didrocks> let's remove the *) as well
[09:34] <didrocks> case with one select only is livecd-rootfs style ;)
[09:52] <duflu> seb128, did you see how unlucky we were with bluez 5.51 timing?
[09:52] <duflu> Nevermind, aim for 20.04
[09:52] <seb128> duflu, yeah, it's out for a few weeks but we missed feature freeze
[09:52] <duflu> Also it was the day I went on vacation
[09:52] <seb128> I didn't push for it since it seemed like it would be ok to wait for next cycle
[09:55] <duflu> seb128, yeah there is a lot of value in having a mature package
[09:55] <duflu> particularly at the end of cycle
[09:56] <seb128> right, sometime there is a nice new feature/set of change that balances that but it didn't seem the case there
[09:57] <duflu> Not really an option with bluez since adding 0.01 to the version number can mean huge changes
[09:58] <duflu> At least we know what GNOME means by adding 0.0.1
[09:58] <popey> Is there a known "good" image of 19.10 with zfs I can test?
[09:59] <didrocks> popey: latest works without secure boot enabled
[09:59] <didrocks> there is a grub2 in UNAPPROVED to fix the secure boot enablement issue
[09:59] <popey> ah okay
[09:59] <popey> will that be tomorrow's iso?
[10:00] <didrocks> hoping so… grub2 has a lot of autopkgtests and takes time to migrate, so depends on when it's accepted by the release team (hence the ping)
[10:00] <didrocks> but I think that should be ok
[10:00] <popey> ok, I've set aside some time tomorrow for testing.
[10:00] <didrocks> nice ;)
[10:09] <Laney> tkamppeter: had a bit of a bumpy time with cups-filters? ;-)
[10:11] <Trevinho> I think it's more the printing dialog backend nowadays!
[10:11] <Laney> 3 new releases in the queue within a few hours
[10:27] <Trevinho> seb128: anything I should particularly look at?
[10:28] <Trevinho> I want to check that valgrind thing
[10:28] <Trevinho> plus, probably do tracker 2.3.1 (miners are not needed as only tests changed)
[10:30] <Trevinho> mh, no archive released but git release is there mhmh
[10:31] <Trevinho> mh not either a tag though, I think i will skip this
[10:32] <seb128> Trevinho, nothing I can think of atm
[10:33] <seb128> if someone could check if valgrind if picking glib/gtk dbg symbols or not for them it would be nice
[10:33] <seb128> it's definitively not working on gnome-calendar for me which is weird
[10:33] <Laney> do some reviews for Daniel ;-)
[10:33] <seb128> (but I saw a few gtk symbols in other calls so it's weird)
[10:33] <seb128> or that :)
[10:34] <seb128> Trevinho, you also have some bugs still open on http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ee-tracking-bug-tasks.html
[10:34] <seb128> (bbiab lunch outside)
[10:35] <ogra> they dont let you eat indoors ? how rude !
[10:37] <Laney> ah buggy report
[10:37] <Laney> that only shows on the hub thing for bionic
[10:37] <Laney> or was that the intent?
[10:46] <danboid> Can zsys or another tool create ZFS/GRUB boot environments under eoan yet?
[10:52] <Trevinho> seb128: well, I can look at the OSK one while for the touch one is not trivial and involves more changes I think
[10:53] <ricotz> hello desktopers
[10:54] <Laney> yeah not sure those are really rls for eoan, rather trello for freaky if anything no?
[10:58] <oSoMoN> hello ricotz
[11:00] <Trevinho> seb128: sooo... for that calendar thing, I just ran calendar from valgrind, added a new agoogle account from control-center, but... all worked
[11:27] <Laney> ANOTHER cups-filters
[11:27] <Laney> what is going on
[11:36] <Trevinho> new printers get released any second!
[11:39] <Trevinho> seb128: tried again, no shell hang, but I did get a calendar crash or smth like that
[11:41] <ricotz> oSoMoN, hi
[11:42] <ricotz> oSoMoN, the upstream fix for the firefox translation issue, is fixing even more regression in current trunk builds ;)
[11:59] <ricotz> jbicha, could you do a swell-foop no-change rebuild?
[12:01] <jibel> didrocks, the grub entry is correct with grub from -proposed. Tested with secure boot + zfs.
[12:01] <jibel> didrocks, and bonus points: the system boots
[12:01] <Laney> haha
[12:01] <Laney> correct ordering of which point is bonus / not-bonus there
[12:05] <danboid> didrocks, I emailed you earlier asking if there is a command to create ZFS boot environments yet?
[12:24] <didrocks> danboid: well, you emailed me an hour ago. Those kind of discussions are better on the ubuntu discourse topic so that it can benefit for everyone
[12:25] <didrocks> danboid: you can use the ZFS topic https://discourse.ubuntu.com/t/enhancing-our-zfs-support-on-ubuntu-19-10-an-introduction/12130
[12:25] <didrocks> also, I'm unsure what you mean by creating ZFS boot environments. You can install from ubiquity which install a system on ZFS
[12:25] <didrocks> grub doesn't install a system
[12:27] <didrocks> jibel: thanks for testing and great for the bonus point :)
[12:29] <didrocks> let's see once it migrates, I've relaunched the tests with grubzfs-testsuite 0.4.4
[12:29] <danboid> didrocks, FreeBSD had beadm (now bectl) which adds new boot environments to the FreeBSD bootloader menu. They are essentially bootable system snapshots. There is a Linux / GRUB equivalent called zedenv
[12:30] <didrocks> danboid: this is what will be zsys in the future: https://github.com/ubuntu/zsys
[12:30] <danboid> didrocks, https://github.com/johnramsden/zedenv
[12:31] <didrocks> danboid: in the coming weeks, we'll publish some blog posts about it and what's our future plan, but yeah, that's in a nutshell what is going to manage ZFS systems, with autosnapshots and such
[12:32] <didrocks> (the grub version we have in eoan is already compatible with it)
[12:35] <danboid> didrocks, I'd recommend you have a play with bectl under FreeBSD to see how that handles boot environments. The other option is installing Arch Linux using ALEZ, which is the easiest way to test zedenv
[12:36] <danboid> didrocks, https://github.com/danboid/ALEZ
[12:37] <danboid> I think zedenv would need some tweaking to work with Ubuntu's dual pool and specific dataset config
[12:39] <didrocks> danboid: will play with them!
[12:39] <ricotz> marcustomlinson, hi, please push your libreoffice 1:6.3.2-0ubuntu2 to git
[12:40] <danboid> didrocks, Great! Boot environments are my fave ZFS feature for sure
[12:40] <marcustomlinson> okidokes
[12:41] <danboid> didrocks, OpenSolaris had them first, but I've never really used Solaris much
[12:41] <marcustomlinson> ricotz: k done
[12:43] <didrocks> ack
[12:43] <ricotz> marcustomlinson, thank you
[12:45] <seb128> Trevinho, @valgrind, ack, thanks for testing
[12:48] <oSoMoN> ricotz, that's good news, thanks for catching the regression in time!
[12:51] <Trevinho> seb128: you get into that again let's try son thing like tmate so I can check myself
[12:54] <seb128> Trevinho, I will lend you the laptop on monday so you can debug ;)
[12:56] <Trevinho> seb128: oh... Right. I always forget you'll be so close very soon
[13:12] <ricotz> seb128, hi, is something blocking vala from transitioning? https://launchpad.net/ubuntu/+source/vala/0.44.9-0ubuntu1
[13:17] <ricotz> could someone retry vala armhf autopkgtest?
[13:31] <seb128> ricotz, seems to be automake-1.16/armhf failed I retried it now
[13:37] <ricotz> seb128, ok
[14:22] <Trevinho> deskoppers, anyone has noticed https://imgur.com/Lvf4CrI.png (windows disposed as there was more space in the bottom)
[14:23] <didrocks> don't have that immediately, but I may have seen that once or twice
[14:23] <didrocks> I don't go to the expose mode much though
[14:23] <mgedmin> I see this right now on 19.04
[14:26] <hellsworth> good morning everyone
[14:26] <Trevinho> mgedmin: ok, do you also have errors mentioning workspace.js into your journalctl
[14:27] <Trevinho> that are actually coming all the times?
[14:27] <didrocks> hey hellsworth
[14:27] <Trevinho> like, using journalctl -f
[14:27] <Trevinho> hi hellsworth
[14:27] <hellsworth> hio!
[14:27] <mgedmin> there's a gnome-shell[3310]: JS ERROR: TypeError: this._workspacesViews[i] is undefined with a traceback
[14:28] <mgedmin> it's not getting repeated when I trigger the overview a couple of times while having journalctl -f running
[14:29] <jibel> Trevinho, I have the same issue with this message in journal
[14:29] <jibel> oct. 10 16:28:39 herm gnome-shell[4471]: JS ERROR: Error: DANMED YOU SHELL
[14:29] <jibel> :)
[14:29] <mgedmin> the timestamp of that error is 17:23, right when I replicated the bug and mentioned that here on IRC
[14:29] <Laney> hahah
[14:30] <Trevinho> ok easy reproducer
[14:30] <jibel> and a typo in the error message BTW
[14:30] <Trevinho> just close a view from the overview... and tadaaaaaaaaaaa
[14:30]  * Trevinho celebrates the reproducer dance
[14:30]  * Trevinho hides into the darkness of js
[14:31] <Laney> good that you found something to do other than reviews ;-)
[14:32] <Trevinho> hehe, I had already crazy ideas for loosing time, don't worry :-D
[14:35] <seb128> Trevinho, bug #1834967 ?
[14:39] <Trevinho> seb128: effect is the same indeed, let me see how dock affects that though as locally IIRC was happening even without...
[14:40] <seb128> Trevinho, I don't think anyone confirmed it was due to the dock
[14:40] <seb128> Trevinho, it's just if you needed a bug reference to use
[14:43] <Trevinho> seb128: ok, so indeed is the dock though, disabling the extension there's not such problem, the JS error stays though, but that's another story
[14:43] <seb128> :(
[16:08] <ricotz> seb128, did the automake-1.16 test for vala fail again, or was the retry not ran yet?
[16:09] <ricotz> anyway, this is not related to vala, so can it be forced to transition?
[16:33] <seb128> ricotz, ask on #ubuntu-release
[16:33] <seb128> ricotz, http://autopkgtest.ubuntu.com/packages/a/automake-1.16/eoan/armhf ... retried worked for glib but didn't finish for vala yet, they take hours
[16:37] <ricotz> seb128, I see, thanks, I hope forcing it is possible regardless
[16:38] <infinity> jibel, Laney, seb128: Is it too late for me to whine about zfs-in-ubiquity implementation details?
[16:38] <seb128> you can always whine, unsure we will change much at this point though
[16:38] <seb128> also patches are welcome if you have improvements idea, we can probably help with reviews
[16:39] <infinity> seb128: The big complaint is that, unlike every other fs/storage implementation, which keeps tools on-demand, we're adding zfsutils to every desktop seed.
[16:39] <infinity> seb128: And maybe that was to work around the autoremoval ubiquity bug, but mwhudson fixed that.
[16:40] <seb128> is that the question you asked jibel about yesterday?
[16:40] <seb128> (I don't know if he replied to that)
[16:40] <infinity> seb128: Yeah.  I didn't see a reply, unless my IRC client lied to me.
[16:40] <seb128> didrocks, ^ do you know why we did it this way?
[16:41] <didrocks> there was part of the autoremoval ubiquity bug and the late review (the MP has been opened for a while upstream). I think the concern is valid and we should have zfsutils-linux in the pool, unsure we have time now for the release though
[16:41] <didrocks> (and so, only install it on demand)
[16:42] <infinity> If it was installed on demand from the pool, the autoremoval bug wouldn't triggre anyway.
[16:42] <didrocks> however, we need the tool in the live sesion, or ensure the module is loaded before starting the partitionning
[16:42] <didrocks> session*
[16:42] <infinity> The bug was for things in the live task (which is how ubiquity gets all its tools)
[16:42] <didrocks> ok, so only removing it from the blacklist
[16:43] <didrocks> and having it removed on demand
[16:43] <infinity> But to be congruent with lvm, btrfs, etc, it should be in the live layer, and then marked for keep.
[16:44] <didrocks> I think this is valid, unsure if there is time or if it's too late. I think seb128 is correct and if anyone has time to tackle it before release
[16:44] <didrocks> we can review/retest
[16:44] <infinity> I just don't feel it's appropriate to pull it in as a recommends on all upgrades and installs unless we expect a vast majority of systems to be zfs overnight, which I think isn't a reasonable thing to assume.
[16:44] <infinity> (And if we did assume that, it belongs in a lower seed, not all the desktop seeds)
[16:45] <infinity> So, I'd be happy to take changes to this over between now and, say, Tuesday.  I'd rather get it right than have one release where it came in from desktop seeds and then worrying about it being autoremoved when we drop it from the same seeds later.
[16:45] <infinity> (Or be stuck having it there forever to avoid that)
[16:46] <infinity> So, at the very least, it should be marked manual if an install is zfs, regardless of how we're shipping it.
[16:46] <infinity> To avoid it being removed in a year by accident.
[16:47] <infinity> And once we fix it to mark manual, then moving it from desktop to live-common is basically a no-brainer non-change.
[16:49] <didrocks> let's see with jibel tomorrow, I'm unsure there is time for more than marking manual for now
[16:49]  * didrocks -> eod
[16:49] <seb128> didrocks, have a nice evening!
[16:49] <seb128> jibel, ^ can you comment on that when you are around?
[16:50] <seb128> infinity, does it create any problem in practice? I think the least we have to change at this point the better
[16:50] <seb128> like how much do we want to fix that?
[16:50] <infinity> I'm happy to help with this once I land in London as well.  Not just going to yell and make demands on others' time.
[16:51] <infinity> seb128: So, not having it marked manual is a real problem.  If we fix that, then which seed it's in is less of a problem and more of a bizarre/gross oddity, cause we can drop it from the seed later and people not using it will just get it removed.
[16:51] <infinity> But I'd certainly rather they didn't get it to start with (and that the design in ubiquity was consistent as a result)
[16:51] <seb128> k
[16:51] <seb128> when are you going to be in London?
[16:52] <seb128> we don't have the people needed around anymore today
[16:52] <infinity> I get in mid-day Sunday.
[16:52] <seb128> so probably for tomorrow or monday if that's still ok
[16:52] <seb128> k, sounds like a monday thing then
[16:52] <seb128> works for you?
[16:52] <infinity> I'll also be around tomorrow, but timezone skewed from you lot, cause I'm in LA right now.
[16:52] <seb128> let's see if jibel replies before your tomorrow
[16:52] <seb128> if not it's for monday I guess
[16:52] <infinity> But yeah, I think we can get this sorted Monday.
[16:53] <seb128> great
[16:53] <infinity> Reuploading all the metas takes roughly zero time on a machine with a fast connection to the seeds, so it's really just about making sure the rest is sane.
[16:58] <Trevinho> infinity: sooo... I can't figure out easily that overview offset, I fixed the error meanwhile but the other needs some more study I might not finish by tonight. Considering also Ubucon.
[16:58] <Trevinho> Sorry infinity, meant to ping seb128
[16:58] <infinity> Trevinho: Good, cause I had exactly zero idea what the heck you were talking about. ;)
[16:59] <infinity> Trevinho: Oh! (yes, I should file a bug, but)... Remember that bug you fixed in compiz/unity7 for me years ago where maximizing/unmaximising windows over and over would slowly shrink them?  gnome-shell has the same bug.
[17:00] <seb128> Trevinho, no hurry don't worry, that's not a release bug
[17:00] <seb128> it's cosmetic
[17:00] <infinity> Trevinho: Most obvious in terminals that size by column/row instead of pixels (like gnome-terminal), cause it shrinks by a whole col/row on each iteration.
[17:00] <seb128> Trevinho, enjoy ubucon, we can talk bugs on monday :)
[17:01] <infinity> Trevinho: Just something to mull over in the back of your mind and see if you remember how it was broken in the previous window manager you fixed. :P
[17:04] <Trevinho> infinity: eheh... If you open a bug also find the old one as I've really no idea of how I fixed it :-D
[17:05] <infinity> Trevinho: I'll have to scour changelogs to figure out what release that was fixed in, but I can probably find it.
[17:06] <infinity> Trevinho: I think it had something to do with miscaculations due to max windows not having borders or some such (hand wavy).  And, of course, while the symptoms are the same, the bugs may be entirely different.
[17:18] <Laney> bloody glib
[17:18] <Laney> that failure on i386 is clearly real
[17:18] <Laney> will have to look into that on monday unless someone wants to tomorrow
[17:19] <Laney> it'd be OK for that update to become an SRU though
[17:20] <Laney> ciao, see you monday
[17:21] <willcooke> night Laney
[17:21] <seb128> Laney, enjoy the w.e!
[17:27] <marcustomlinson> Happy times Laney!
[17:27] <marcustomlinson> And with that I’m off too. Byyeee
[17:29] <willcooke> +
[17:29] <willcooke> oops
[17:36] <willcooke> night all
[18:12] <jibel> infinity, I'm fine with your proposal, I'll have a look tomorrow.