[05:20] <_ruben> nebuchadnezzar: interesting! seems i got me some testing to do :)
[08:51] <flexiondotorg> cyphermox, Just tested your oem-config fixes on my VM at work. Brilliant! Well done you :)
[10:45] <nebuchadnezzar> _ruben: sure, I need to rebase my work a little and this will break history and hope for integration into hands-off
[10:46] <nebuchadnezzar> _ruben: making partman preseed easier is quite hard but I think my system based on hands-off help a lot, you can “subclass” a previous partitionning model or write one from scratch
[12:19] <flexiondotorg> cjwatson, How do the ship and ship-live seeds differ?
[12:30] <cjwatson> Both are used to construct package pools on images that aren't installed by default but that are available for opportunistic or conditional installation during the initial install.  ship is for d-i-based ("alternate") CDs; ship-live is for live ("desktop") CDs.
[12:30] <cjwatson> You only build desktop CDs, so you probably don't need ship.
[12:30] <flexiondotorg> cjwatson, OK, because this is still as issue - https://bugs.launchpad.net/ubuntu-mate/+bug/1426905
[12:31] <flexiondotorg> cjwatson, That I can not reproduce. But then again I do not have any EFI hardware.
[12:31] <cjwatson> You should get installer logs from them.
[12:31] <flexiondotorg> cjwatson, I was wondering if adding some of the same packages (grub-pc, dmraid, etc) to ship-live might help?
[12:32] <cjwatson> grub-pc is already in your ship-live.
[12:33] <cjwatson> Anyway, I don't think that's it - this isn't about whether the package is available for installation
[12:33] <flexiondotorg> cjwatson, https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1429385
[12:33] <flexiondotorg> cjwatson, There are many dupes. That one has some installer logs ^^^^^
[12:34] <cjwatson> You know I'm not really doing installer work any more, right? :)
[12:34] <flexiondotorg> cjwatson, I know, but you're very helpful ;)
[12:34] <cjwatson> I can advise on seed layout, but I'm afraid I really don't have time to be pulled into a lengthy debugging exercise
[12:34] <flexiondotorg> cjwatson, I was up until 1am helping test stuff for cyphermox.
[12:34] <flexiondotorg> cjwatson, OK understood.
[12:35] <cjwatson> 1429385 is from ages ago so could be no longer relevant; I'd suggest getting current logs
[12:35] <cjwatson> Otherwise you can end up debugging already-fixed problems that happen to have similar symptoms
[12:36] <cjwatson> We don't always surface the exact error very clearly, so users often report that something is the "same thing" when it's quite different underneath
[12:36] <flexiondotorg> cjwatson, OK. I'll see if I can persuade an EFI VBox without network connection to fail for me.
[12:42] <cjwatson> flexiondotorg: If it's still "dpkg: error processing package grub-pc (--purge):" "subprocess installed pre-removal script returned error exit status 10", then that's debconf's "bad parameters" error code; you want to get a log with "debug-ubiquity" on the kernel command line to see what's actually going on there
[12:42] <cjwatson> (which gives a full debconf trace of everything)
[12:54] <flexiondotorg> cjwatson, I simply can not coerce my VM or actual hardware to fail :(
[12:54] <flexiondotorg> cjwatson, I've requested logs.
[14:06] <cyphermox> flexiondotorg: what's with the seeds?
[14:06] <flexiondotorg> cyphermox, ?
[14:06] <cyphermox> I was reading backlog
[14:06] <flexiondotorg> cyphermox, First things first. You're oem-config fixed work. Really nice!
[14:07] <cyphermox> thanks for testing that. I confirmed it looked as good as it should on mate, kubuntu, and ubuntu
[14:07] <flexiondotorg> cyphermox, I was just trying to understand the nature of some of the different seeds to see if there was a potential fix for an issue.
[14:07] <cyphermox> ok
[14:07] <flexiondotorg> cyphermox, The seeds are fine :)
[14:08] <flexiondotorg> cyphermox, And I can't reproduce the error being reported. And fairly sure cjwatson and infinity helped me fix it a week or so back.
[14:08] <flexiondotorg> cyphermox, So, when will the new Ubiquity hit the repos? :)
[14:08] <cyphermox> I should upload in a bit
[14:08] <cyphermox> I'm finishing up the testing
[14:09] <cyphermox> qemu tends to crash a lot
[14:12] <flexiondotorg> cyphermox, Yes. I think the issue I had at home lastnight was just Vbox being, well, Vbox.
[14:14] <cyphermox> ack
[15:37] <infinity> cyphermox: Are you getting enough enthusiastic review from xnox that you don't need mine too? :P
[15:39] <cyphermox> infinity: well, it really should be discussed ;)
[15:39] <cyphermox> xnox: here?
[15:39] <cyphermox> I know the sleep isn't great, and probably doesn't need to stick given using a separate target
[15:41] <cyphermox> and tbh I didn't try linking the targets because it means other dependency fun, like precisely what was happening before, where when you remove oem-config package it removes the .service, so there is nothing anymore to block display-manager from starting way too early for its own good
[15:41] <infinity> cyphermox: Could fix targets a bit, or could loop over 'pgrep -u oem'
[15:41] <xnox> cyphermox: yeah.
[15:41] <cyphermox> ie. before oem-config-firstboot is finished removing the oem user
[15:41] <cyphermox> infinity: given the targets we probably don't need the sleep and extra pkill.
[15:41] <infinity> cyphermox: Any time you're sleeping due to hardware not being fast enough, you'll never get it right for all hardware.  And by the time you do, you're sleeping for an hour.
[15:41] <cyphermox> (or any pkill at all, for that matter)
[15:42] <cyphermox> infinity: I know :)
[15:42] <cyphermox> that's exactly what I keep telling people when they suggest timeout and delays and whatnot in NM
[15:43] <infinity> Anyhow, discuss with xnox if there's an entirely better way to do this, as he seems to think there is, but if you decide to keep the current code, turn the sleep into a while pgrep loop instead.  Will be much faster for 99% of us and 100% correct for the slow cases.
[15:44] <cyphermox> infinity: like I said, I think it can all be dropped instead :)
[15:45] <infinity> Which is even better, agreed.
[15:45] <cyphermox> there shouldn't be anything from the oem user if graphical.target isn't getting started
[15:46] <cyphermox> xnox: so what were you suggesting re: having oem-config.target wantedby graphical.target?
[15:46] <cyphermox> I haven't tried but it still concerns me that as soon as the file disappears graphical.target will continue starting and it basically won't change a thing :)
[15:47] <cyphermox> fwiw, before that oem-config.service was a dependency of multi-user, not graphical.
[15:48] <xnox> infinity: cyphermox: imho cyphermox's code is good to go in as is.
[15:48] <xnox> doing "wantedby" magic is "better" but for later.
[15:50] <cyphermox> then I'll drop the extra sleep and pkill, and dch -r.
[18:02] <cyphermox> xnox: sounds like you know systemd units pretty well?