[00:10] mwhudson: You may be interested in 'parsedatetime' from experimental, adds python3 package. === JanC is now known as Guest104 === JanC_ is now known as JanC [09:45] xnox: Lots of apts uploaded. [09:45] apt apty apt apt [09:46] The .changes is getting a bit unreadable now, as it contains quite a few versions since {xenial,yakkety,zesty}-updates (we had about 3 fixup releases or so that were never part of the Ubuntu archive, but were released in the APT PPA) [09:47] But well, it should work now :) [09:52] Let's just say we probably should have slowed down the rates of SRU builds. [09:52] Oh, we fixed it. [09:52] Next day: Oh no, something was broken. === CRogers_________ is now known as CRogers === koza is now known as koza|away [14:52] cjwatson: I can't seem to find the postinst or udeb that populates /etc/default/grub... do you know where that's done? [14:54] psusi: ucf from grub-.postinst [14:54] A bit of optional mangling in grub-installer too. [14:55] at some point the latter should probably drop a file into /etc/default/grub.d/ instead [14:55] That's where quiet and splash are written. [14:55] that directory didn't exist when it was first implemented [14:56] cjwatson: How does .d work for CMDLINE stuff? Is it additive or an override? [14:56] Might not be entirely appropriate for the quiet/splash stuff if it's a hard override. [14:56] Oh, except that on a default install, those are the only bits in CMDLINE, so maybe that works. [14:57] sourced shell fragments so can mangle however it likes ... [14:57] Ahh, so could be CMDLINE="CMDLINE $splash" [14:58] And one snipper for splash, one for extra kopts passed from d-i, etc. [14:58] (in principle; might confuse various configurator-like tools ...) [14:58] snippet, too. [15:02] thanks... I'm looking into a bug where the tty7 option sounds like it is being set in the console only installs and it shouldn't be [15:04] that's probably more about the stuff in grub-installer (perhaps the one that copies options from d-i if they're provided after ---) [15:04] that is what I thought of first but I'm not seeing it in there [15:05] search for user-params [15:07] only one line: user_params=$(user-params) || true [15:07] hrm.. where's that sucker come from? [15:08] psusi: You mean the vt_handoff stuff? [15:09] infinity: yea [15:10] That's hardcoded in grub configs, but doesn't take effect if splash isn't on the commandline, which server preseeds out. [15:10] IIRC. [15:12] user-params is in debian-installer-utils [15:13] if [ "$vt_handoff" = 1 ]; then [15:13] for word in $GRUB_CMDLINE_LINUX_DEFAULT; do [15:13] if [ "$word" = splash ]; then [15:13] GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT \$vt_handoff" [15:13] fi [15:13] done [15:13] fi [15:13] Yeah, no splash, no handoff. === sergiusens_ is now known as sergiusens [16:02] infinity, cjwatson, apw - can we please drop all the vthandoff stuff and boot to vt1 by default everywhere? [16:02] * cjwatson recuses self [16:04] xnox, and lose all that prettiness for approx 1s of the boot, how would we cope [16:04] apw, the point is that our prettiness will be pitch perfect. [16:05] apw, you did notice that windows 10 boots with black background and a white spinny graphic at the bottom to achieve flickerless boot. [16:05] apw, and i thought booting to vt1 (and having graphical login on vt1) will make the whole vthandoff easier to do flickerless [16:06] xnox: gdm3 in Debian & Ubuntu already has login on vt1; robert_ancell was considering maybe doing that for lightdm [16:07] most distros now use vt1 for gdm, so I think the question is whether it's more important to match other distros (with their good reasons) or preserve tradition [16:15] I don't think Ubuntu is the appropriate distribution for a user who would care that X is now on vt1, unless there's an actual use case that it breaks. [16:16] it seems unlikely anyone would care where we put it [16:17] and being the same as everyone else is always nice in the sense of sharing the fixes [17:20] infinity: so the default is to add splash, but the server cd uses a preseed to prevent the default from kicking in, and the preseed omits splash? It sounds like maybe the default should be no splash, and maybe ubuntu-desktop being installed should trigger splash.... [17:21] psusi: Quite possibly, yes. [17:22] I can't remember the reason for the vt.handoff in the first place... does vt1 want to run at a different resolution, so we use vt7 to keep it at the same resolution that grub was in? [17:22] psusi: Or, as xnox points out, maybe we want to rethink this whole mess. [17:22] if so, why don't we just have vt1 use that same resolution? [17:22] It was all some misguided attempt to create a flicker-free boot. [17:22] Some of us are more fond of the solution than others. :P [17:22] yea, but I can't recall the cause of the flicker [17:23] I don't recall the specifics either. Colin or Andy might. [17:23] But it's worth revisiting regardless. [17:23] as long as vt1 is a graphical console instead of VGA mode, and uses the right resolution, there should be no flicker [17:24] we patched grub/kernel/plymouth/lightdm to not clear the screen and paint things in to the same hue of aubergine and never switch vts such that plymouth&desktop run on vt7 with handoff [17:24] right... but why did switching from vt1 to vt7 after X loaded make a flicker? is vt1 in a different mode? [17:24] all of that is semi-custom patched. the rest of the people decided to simply default to vt1 without any patches to achieve the same result [17:24] psusi, vt switches cause flicker, yes. [17:24] only if the two vts are different modes no? [17:24] because graphics drivers [17:25] psusi, that i do not know. but there was flicker / clearing of the screen, visibly. There are videos of that happening on various laptops. [17:25] I suspect any non-kms driver will flicker on vt switch. [17:25] heh, just leaving it on vt1 does seem a lot simpler ;) [17:25] But non-kms drivers will probably "flicker" when X comes up too, even without a vt switch. [17:26] But yeah, I entirely forget the specifics. [17:27] I think revisiting the vt switch is a sane plan. And if we decide it's still awesome, then maybe swapping the defaults so, as you say, only graphical installs get splash, instead of the server ISO being "special" would be reasonable. [17:27] yea, apparently the netinstall isn't "special" so it gets splash with a non X install [17:27] Though, in an ideal world, "splash" would work reasonably on servers too, but that would requite killing the handoff stuff, I think. Currently, it goes a bit wonky. [17:42] infinity, ooooh i also recall that we did do splash by default on server too / intentially / and then server complained and we reverted to non-splash on server [17:42] imho systemd boot log is pretty enough for non-quiet boot on server by default even. [17:42] the plan was to splash everywhere all the time. [17:42] in 11.10 or something [17:42] pre 12.04 [21:23] nacc, rbasak: @PyCon, certbot talk. there was a "thanks to the maintainers" on his last slide, including you [21:23] pitti: I see you accepted the previous SRU of borgbackup (LP: #1615380), there's another one with the same rationale; do you mind expanding on why you're confident in the upstream testsuite here? [21:23] Launchpad bug 1615380 in borgbackup (Ubuntu Yakkety) "[SRU] security issues on borgbackup" [Undecided,Fix released] https://launchpad.net/bugs/1615380 [21:32] doko: nice :) [21:32] doko: they've done most of the heavy lifting, I'd say :) [21:32] nacc: they didn't yet consider snapping the app ... [21:32] doko: yep, that's probably the next reasonable step at this point [21:34] ohh, and it's packaged using python 2.7 ...