=== freyes_ is now known as freyes
=== Nafallo_ is now known as Nafallo
[09:14] <sil2100> abeato: hey! I'll try to review  your PR today :)
[09:18] <abeato> sil2100, cool, thanks :)
[10:54] <doko> tsimonq2: https://launchpad.net/ubuntu/+source/metview/5.1.1-1/+build/15233178  version mismatch with Debian?
[11:01] <doko> jamespage, coreycb: openstack related MIRs needed: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[11:02] <jamespage> doko: ta - on those this week
[11:21] <doko> xnox: finalrd: why do we need to handle lib64?
[12:25] <doko> FAIL: misc/tst-preadvwritev2
[12:25] <doko> FAIL: misc/tst-preadvwritev64v2
[12:26] <doko> infinity: ^^^ glibc autopkg test failures triggered by binutils branch update. could you have a look?
[12:38] <ricotz> doko, regarding "gdb 8.1-0ubuntu6" there seems to be source packages which build-dep on gdb, but build-conflict with gdb-minimal
[12:47] <ricotz> juliank, hi, https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1762384
[12:47] <ubottu> Launchpad bug 1762384 in gpgme1.0 (Ubuntu) "libgpgme-dev installs libgpgme-pthread.so in /usr/lib/${DEB_HOST_MULTIARCH}, literally" [Undecided,Confirmed]
[12:48] <juliank> ricotz: ack
[12:49] <juliank> maybe MoM stripped an x bit or something
[12:50] <juliank> ricotz: hmm, libgmpg11.links is executable for me
[12:50] <juliank> so I wonder why it's not working
[12:50] <ricotz> juliank, this effects bionic too
[12:51] <ricotz> juliank, thanks for looking
[12:51] <juliank> Ah no
[12:51] <juliank> I looked at the wrong file
[12:51] <juliank> libgpgme-dev.links is missing the executable bit
[12:52] <ricotz> juliank, is this link actually needed?
[12:53] <juliank> If something passes -lgpgme-pthread
[12:53] <ricotz> while this is suppose to fix some kde build failures? this wouldn't worked so far?
[12:54] <juliank> I don't know if it fixes anything or not
[12:54] <juliank> I fixed cosmic now
[12:55] <juliank> will do bionic shortly
[12:55] <ricotz> thanks
[12:56] <juliank> ricotz: this unfortunately does not show up in debdiffs :(
[12:56] <juliank> need to enhance debdiff!
[12:59] <doko> ricotz: ?
[13:01] <ricotz> doko, meaning while gdb provides gdb-minimal, such source packages will fail to build and will require an ubuntu-delta
[13:02] <ricotz> just ran in to debian's rustc which does have those gdb build-deps/conflicts
[13:03] <doko> then file a bug report against rustc
[13:03] <ricotz> afaics a real empty arch-all package would not cause such an issue
[13:03] <doko> there's no reason for that conflict
[13:04] <ricotz> rustc won't be synced, jfyi that this might cause problems
[13:12] <doko> chrisccoulson: ^^^ please fix rustc
[13:26] <juliank> ricotz: unfortunately ftbfs /bin/bash: line 1: /usr/bin/python3.7: No such file or directory
[13:27] <juliank> it only has a python3-dev dep, but needs python3-all-dev ugh
[13:36] <tsimonq2> doko: ack, will fix later unless you want to JFDI.
[14:40] <psusi> sil2100: I thought you were going to simply change grub-install to switch to grub-pc instead of grub-efi in the case of no ESPs, but instead, if I am reading this correctly, you made the installer simply refuse to offer to do a side-by-side install with a bios mode install but booted in EFI mode?
[14:42] <psusi> if so that seems like bad ux; they should be able to do a side by side install and simply have it work.
[14:43] <sil2100> psusi: where did you read that?
[14:44] <psusi> ohh, right... re-use means re-use the existing partition with no partition table changes and replace the existing OS there
[14:44] <psusi> as opposed to side-by-side... I think I see now.. bug @1766945
[14:45] <sil2100> psusi: yes, that's the only case that's not being offered as it would require doing partition changes in an option which, by definition, shouldn't do any partition changes
[14:45] <psusi> wait... this still doesn't sound right... side-by-side creates an ESP, causing the computer to switch to booting in EFI mode, then that break's the existing bios booting install
[14:45] <sil2100> As re-use partition means: 'use the very exact partition and install ubuntu on it', as it would result in no ESP and not being able to boot into the system in the current mode
[14:46] <sil2100> It shouldn't break BIOS booting, the ESP partition is simply appended to the partition table
[14:47] <psusi> and of course, creating an ESP on an MBR disk that also already has an existing OS in it is going to be a twisted mess what with the 4 primary partition limit
[14:47] <psusi> yes, but if grub-efi takes over the boot process, you can not chainload the existing bios mode OS
[14:48] <sil2100> Did you you just reproduce such an issue?
[14:48] <psusi> no
[14:48] <juliank> Isn't grub capable of chainloading bios files in EFI as long as the compat thingy is enabled in EFI
[14:48] <juliank> ?
[14:49] <psusi> I don't think son
[14:49] <psusi> once the computer starts in EFI mode, there is no BIOS
[14:49] <psusi> or at least... you can't count on it being there... maybe current implementations don't bother getting rid of it?
[14:50] <psusi> but I'm pretty sure the last time I looked at the grub code, grub-efi's chainload command is expecting to load a .efi program
[14:54] <juliank> ok
[15:22] <psusi> sil2100: did you test a side by side install with freedos or Windows?  Because I'm pretty sure those will fail... with another bios mode install of Ubuntu it is fine because grub-efi doesn't chainload grub-pc; grub-efi just imports the menu entries to load the other install's kernel
[15:30] <sil2100> psusi: I personally didn't test that case, but I think jibel did as part of some point-release related testing
[15:30] <sil2100> jibel: ^
[15:33] <psusi> I'm not sure if Windows still puts its EFI loader on the disk when installed in bios mode ( what release of Windows even supported EFI?  Windows 7?  I guess XP is too old to worry about )... but I'll bet dollars to doughnuts that you won't be able to boot FreeDOS after doing this
[15:34] <psusi> though I suppose that may be a small enough of a concern to not worry about too... who really uses freedos?
[15:34] <sil2100> If that's the case then it's certainly a bug worth filling in
[15:35] <psusi> where is the windows efi boot loader?  isn't it c:\BCD\something?
[15:37] <psusi> ahh, here we go... EFI/MICROSOFT/BOOT/bootmgfw.efi
[15:37] <psusi> so yea, looks like it is on the ESP, which you don;'t have if installed in bios mode, so a side-by-side mode install with windows already in bios mode will break it
[15:41] <psusi> ohh, look at that... I just searched this bios mode windows system and it has a copy under C:\Windows\Boot\EFI... so maybe you could chainload that and get it to boot, but I don't think that's where grub-probe currently looks for it
[16:37] <teward> anyone know whether there's a way to delay a systemd unit from starting until after both IPv4 and IPv6 networking are 'up' and 'configured' on a system?  got an nginx bug that looks like a race condition between nginx starting and network being 'up', and it's being problematic as a result...
[16:37] <teward> so i'm trying to see if there's a way to alter the systemd service/unit to wait until v4 and v6 are up
[16:38] <teward> (even if it's just local/link-only v6)
[16:46] <cyphermox> psusi: side-by-side install would create a new ESP, but only if the system was previously booting in BIOS and now booted EFI -- that's already a tiny minority of cases. Furthermore, grub will still run os-prober and detect the other Linux installs, and should be able to boot them still, up until we enforce that kernels are signed
[16:46] <cyphermox> as for Windows, any recent windows will already have an EFI bootloader
[16:46] <cyphermox> old Windows do chainload fine
[16:47] <cyphermox> and the new Windows would, too
[16:48] <psusi> cyphermox: it is not a tiny minority of cases.. we get hundreds of apport crash reports every month of people doing just that.  You can not chain load bios booting OS from EFI grub
[16:48] <cyphermox> (windows already gets chainloaded by grub using bootmgfw.efi, and that validates because the right keys are in firmware)
[16:49] <psusi> only if bootmgfw.efi is found on the ESP... if it was a bios mode install of Windows, it won't be
[16:49] <cyphermox> you can't chain load, but you absolutely can load the kernels for linux installs, up until we disable fallback to unsigned.
[16:49] <psusi> yes.. linux installs.. but not freedos or windows
[16:49] <cyphermox> and the issue you're refering to for Windows is an os-prober bug
[16:50] <cyphermox> there's nothing stopping os-prober from detecting bootmgfw.efi from elsewhere than /EFI/Microsoft/whatever
[16:50] <psusi> yea, if os-prober was smart enough it probably could find the copy of the windows EFI boot loader and chainload it even if there is no ESP and that *probably* will work
[16:50] <cyphermox> freedos would chainload just as fine.
[16:50] <psusi> no it won't... you can not chainload a bios OS from grub-efi
[16:51] <cyphermox> psusi: you're free to disable Secure Boot.
[16:51] <psusi> I'm not even talking about secure boot
[16:51] <cyphermox> psusi: of course unsigned things don't load if you expect Secure Boot to be enforced, but chainloading is chainloading
[16:51] <cyphermox> maybe there's a bug, I don't know
[16:52] <psusi> no... chainloading in grub-efi means load and execute another PE EFI image in EFI mode
[16:52] <psusi> grub-efi can not chainload a bios MBR
[16:53] <cyphermox> psusi: there's no way around the fact that it's possible for some things to break if people are changing their firmwares
[16:53] <psusi> they don't *want* to change their firmware... they don't even know the difference
[16:53] <JanC> I wonder: is that a GRUB limitation or a UEFI limitation?
[16:53] <psusi> they just have a working bios mode install and accidentally booted the ubuntu installer in EFI mode
[16:54] <cyphermox> psusi: how do you accidentally boot the ubuntu installer in EFI mode?
[16:54] <psusi> JanC: UEFI... if you boot in UEFI mode, there is no bios, you can't switch back to real mode and make interrupt calls
[16:54] <psusi> cyphermox: because they don't know the difference?  they just hit whatever it takes to get the cd to boot
[16:54] <psusi> and in most firmwares, it is not clear which mode yuo are booting in
[16:54] <cyphermox> psusi: to qualify this; how do you do so and then be completely unable to boot back in BIOS?
[16:55] <psusi> unless you know the subtle little difference to look for... like the fact that it actually calls it "ubnuntu" in efi mode, isntead of just "boot from usb"
[16:55] <cyphermox> yes. you'll get varying things in a boot menu. that means you'll still be able to boot your device in "legacy" mode should you choose to.
[16:55] <psusi> they could figure out how to force the machine to boot in bios mode maybe, but by default, we will configure it to boot in EFI mode, and it will do so.. and once grub-efi is booted, it can no longer chainload back into bios mode
[16:56] <cyphermox> but we should also take care to help users transition from legacy to UEFI, which is what sil2100's changes are doing.
[16:57] <psusi> except that the transition doesn't really work for them unless we can manage to have a working grub menu entry that still boots their old os
[16:57] <cyphermox> psusi: my point is, if you accidentally booting in UEFI; you can also accidentally boot in legacy mode, and grub installs both to a MBR and to ESP; if one fails they will try another one
[16:58] <psusi> you can't really accidentally boot in MBR mode from your hard disk... once the EFI variables are in place to boot in EFI mode, that's what the system is going to do.. it's only when people are trying to boot from install media that they can get the mode wrong
[16:59] <psusi> then if we install in efi mode they won't get a grub entry to boot windows any more
[16:59] <psusi> and will have to figure out how to go into their firmware and demand that it boot in legacy mode to get into windows
[17:00] <psusi> heck, if we also install grub to the MBR even that won't work
[17:00] <psusi> since our grub.cfg won't have a chainloader +1 stanza because that is only generated if os-prober is run not in EFI mode
[17:01] <cyphermox> psusi: you're missing the fact that if they managed to have both the legacy and UEFI options, their firmware is UEFI pretending to be BIOS. There's only so much we can do; being able to install to MBR and ESP simultaneously is about as much as you can do, and then deal with those who don't understand, did it wrong, and tell them how to switch back to legacy (if necessary)
[17:02] <psusi> well as things stand now the only thing they will be able to do to get back into their windows is to boot the windows install cd ( if they even have one ), and run FIXMBR to dig grub out of the MBR and put the MS loader back
[17:02] <cyphermox> we're not actively trying to break anyone's computer; mistakes happen, but most things already understand EFI, and some will in fact insist on it (hello Windows)
[17:03] <cyphermox> psusi: I suggest you file a bug, and possibly include a patch to let os-prober detect the Microsoft bootloader from its alternate location?
[17:04] <cyphermox> that would at least deal with that BCD copy for Windows 10.
[17:04] <psusi> yea... but the only way to deal with freedos is to not force the machine to efi mode and just install grub-pc
[17:05] <cyphermox> tough luck for freedos I guess, for one thing there's nothing really stopping them from supporting EFI
[17:05] <psusi> sure there is... it's DOS..
[17:05] <psusi> it kind of runs in real mode with bios by definition
[17:06] <cyphermox> and their kernel can't emulate interrupts?
[17:07] <psusi> well now you are talking about just running dosemu under linux with freedos installed in the emulator
[17:07] <psusi> of course one of the reasons people use freedos on bare metal is to be able to run bios update utilities that many vendors still only support from dos
[17:08] <psusi> at least they did the last time I looked
[17:08] <psusi> maybe they have finally all gotten with the times, I dunno...
[17:09] <cyphermox> not all manufacturers have, but some never will, that doesn't mean freedos can't ever do its thing by booting in EFI and say, remaining in BootServices.
[17:10] <psusi> it would have to actually run in protected mode then use v86 mode to emulate bios to run the applications
[17:14] <cyphermox> in any case, you can still boot with CSM to load legacy things.
[17:16] <psusi> yea, but if we also installed grub-pc, then you still get grub with no windows menu entry
[17:18] <cyphermox> we install grub-pc, if people manage to start grub-pc, then they will get grub-pc, and a windows with no EFI loader will work.
[17:22] <psusi> their grub.cfg won't have a windows option in it
[17:22] <psusi> unless they boot ubuntu in bios mode and run update-grub
[17:23] <psusi> so I guess that's a way out... force firmware to boot in legacy mode... load ubuntu, run update-grub, then you can reboot and get into either
[17:23] <psusi> but why are we making them go through all of that instead of just sticking with grub-pc only?
[17:26] <cyphermox> because the installer booted in UEFI, and you can't know whether it's an error or intended, so we install both bootloaders, and users will decide via what way they boot the devices
[17:27] <cyphermox> if it so happens that they boot everything with CSM enabled, but somehow their firmware can only do UEFI for USB keys or CDROM, then things will keep working.
[17:28] <cyphermox> we don't need to actively break the installer, fail the install, or write a cryptic message telling the user that "this might not work". They're installing Ubuntu, we're doing our best to give them an installation of Ubuntu that works, and doing our best to keep all the other things working too.
[17:29] <psusi> of course not... that message needed to go... but we should just assume that they don't want us to change their boot mode and stick with grub-pc
[17:29] <psusi> since you know that will boot both operating systems correctly
[17:31] <cyphermox> no, it does not. It's actively going against people who genuinely decide to boot in UEFI and install in UEFI.
[17:31] <psusi> anyone who actually wants to switch should format the drive and do a clean install of Windows *before* installing Ubuntu
[17:32] <psusi> not install Ubuntu and then no longer be able to boot their Windows
[19:01] <slangasek> infinity: hi, are you running the TB meeting?
[22:53] <sarnold> Unit193: congratulations on getting privileges I assumed you already had :D
[23:05] <Unit193> sarnold: Hah, thank you very much!
[23:13] <Unit193> sarnold: FYI, I'm not a DD (yet) either. :>
[23:13] <sarnold> Unit193: that's is *also* a surprise :)
[23:13] <Unit193> In process of, though.
[23:13] <sarnold> even though I think I've been told both of these things before
[23:13] <sarnold> also did you realize it's august?
[23:14] <Unit193> My sister's birthday was the 1st, I did realize.  Not sure what context I'm supposed to realize it in though. >_>
[23:16] <rbasak> Is your sister Unit192 or Unit194? :-P
[23:16] <Unit193> Paha.
[23:17] <Unit193> Arguably 192, but I usually claim to have superseded prior versions.
[23:19] <sarnold> well I meant  in the general "things that surprise me but don't surprise other people" sense :)
[23:19] <sarnold> but good on you for re3mmebering your sister's birthday :D
[23:20] <Unit193> (I don't know when the other's is.)  Ah!  Well I nearly missed the DMB meeting, only saw it because of the factoid use here.  I was busy dealing with spam. :P
[23:56] <sarnold> :(