=== cpaelzer__ is now known as cpaelzer
[09:39] <cpaelzer> cjwatson: seeing you reminded me to ask for bug 1822370
[09:39] <ubottu> bug 1822370 in openssh (Ubuntu Disco) "19.04 beta openssh-client broken pipe" [Critical,Triaged] https://launchpad.net/bugs/1822370
[09:39] <cpaelzer> there was no further debian response that I'd have seen
[09:40] <cpaelzer> but since we final freeze in 3 days I was wondering if you considered uploading that to Buster now (or not)
[09:41] <cjwatson> cpaelzer: Yes I am considering it and was already looking at it before you pinged
[09:41] <cjwatson> Please stop asking for a while :)
[09:41] <cpaelzer> :_/ ok
[09:42] <cpaelzer> even my nose seems to slip out of my smiley face in shame
[10:37] <doko> https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.tag=cc-tc-updates
[10:38] <doko> cpaelzer, jamespage, coreycb: while this is cosmic, these are the python 3.6.8, 3.7.3 and 2.7.16 updates also planned for bionic. Any comment which ones should be fixed, and which ones could be ignored would be welcome
[10:41] <jamespage> doko: glance will need fixing - the errors look familiar
[10:41] <jamespage> that ceph failure is odd
[10:41]  * jamespage digs further
[10:44] <rbasak> cpaelzer: were you involved in libapache2-mod-shib2 libcurl3/4 thing? Or was that ahasenack? Bug https://bugs.launchpad.net/ubuntu/+source/shibboleth-sp/+bug/1822069.
[10:44] <ubottu> Launchpad bug 1822069 in xmltooling (Ubuntu) "SRU: Shibboleth SPv3 for bionic" [Undecided,New]
[10:45] <doko> jamespage: this is using ppa:ubuntu-toolchain-r/ppa
[10:45] <jamespage> ack
[10:53] <jamespage> doko: the ceph failure is from the version in the release pocket rather than the -updates pocket - was that intentional?
[11:03] <doko> jamespage: ahh crap, wrong name for the updates archive. my script didn't error out on a missing archive :-/
[11:08] <jamespage> doko: I think the one in the release pockets probably already FTBFS - ceph got stuck in proposed for most of that cycle
[11:08] <jamespage> the glance failures look familiar as well
[11:08] <jamespage> bug 1800601
[11:08] <ubottu> bug 1800601 in glance (Ubuntu Disco) "[SRU] Infinite recursion in Python 3" [Critical,Fix released] https://launchpad.net/bugs/1800601
[11:09] <jamespage> yeah that was done as an SRU post cosmic release
[11:11] <doko> now regenerated http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190404-gcc8-cosmic.html
[11:11] <doko> there are no regressions with the planned toolchain updates :-)
[11:11] <doko> sorry for the noise
=== waveform_ is now known as waveform
[11:31] <cpaelzer> rbasak: I had nothing to do with the bug that you listed
[11:31] <cpaelzer> was it the right bug number?
[11:32] <cpaelzer> rbasak: do you know https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1823665 which doko was asking about above?
[11:32] <ubottu> Launchpad bug 1823665 in mysql-5.7 (Ubuntu) "mysql-5.7 ftbfs with cosmic toolchain updates (amd64, i386 only)" [High,New]
[11:34] <rbasak> cpaelzer: no I know that's a new bug - but it's connected to the previous work on libapache2-mod-shib2 and libcurl3/4 which I think someone was dealing with - hence my question.
[11:35] <rbasak> Skuggen: could you take a look at bug 1823665 please?
[11:35] <ubottu> bug 1823665 in mysql-5.7 (Ubuntu) "mysql-5.7 ftbfs with cosmic toolchain updates (amd64, i386 only)" [High,New] https://launchpad.net/bugs/1823665
[11:40] <doko> cpaelzer, rbasak: that's fixed in -updates. my bad
[11:41] <rbasak> Ah, no worries.
[11:41] <rbasak> Skuggen: cancel the above please :)
[11:48] <doko> so just one symbols file regression with the proposed updates. better than expected
=== ricab is now known as ricab|lunch
=== chrisccoulson_ is now known as chrisccoulson
[12:54] <Skuggen> Best kind of issue; The kind that's fixed before I become aware of their existence
[13:17] <tsimonq2> cyphermox, xnox: Currently GRUB2 doesn't support LUKS2, as enabled by default in the recent cryptsetup release. I understand investigations are still being done into true FDE with Ubiquity, but in Lubuntu and very likely most custom installations, this simply won't work. Would either of you object to me building cryptsetup with LUKS1 as default until GRUB2 gets support?
[13:21] <cjwatson> Oh is that what that is
[13:22] <cjwatson> tsimonq2: If you're doing that could you also chase it with Debian?
[13:22] <cjwatson> Assuming LUKS2 being the default explains the various reports I've seen about buster
[13:23] <cjwatson> Or maybe it should be done in partman-crypto instead?
[13:23] <cjwatson> Though https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919725 has a comment about wanting d-i's default to match cryptsetup's, which makes sense
[13:23] <ubottu> Debian bug 919725 in cryptsetup "cryptsetup: switch to LUKS2 by default for new installs" [Wishlist,Fixed]
[13:24] <cjwatson> I think Debian must have the same problem and it's surely release-critical
[13:25] <cjwatson> https://savannah.gnu.org/bugs/?55093 too
[13:32] <tsimonq2> cjwatson: ack, Ubuntu's release is sooner though :)
[13:32] <tsimonq2> I'll happily file a bug there too
[13:32] <infinity> Disturbingly soon for this to be "just" coming up as a thing.
[13:32] <tsimonq2> Better than release week.
[13:32] <cjwatson> it became the default last month or so I think?
[13:33] <cjwatson> the spec (https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/on-disk-format-luks2.pdf) looks vaguely tractable but I won't have time to even think about it for a week or two at least
[13:33] <infinity> Is there a bug filed detailing the interactions here between cryptsetup, installers, grub, what needs changing, how to make sure they all agree?
[13:33] <tsimonq2> No, just a feature request in GRUB upstream.
[13:33] <infinity> Will flipping cryptsetup back make everything just go back to how it was in cosmic?
[13:33] <cjwatson> Pretty sure what needs changing is "configure cryptsetup with --with-default-luks-format=LUKS1"
[13:34] <infinity> Cause +1 on that, if so.
[13:34] <cjwatson> But obviously wants testing
[13:34] <tsimonq2> cjwatson: Exactly.
[13:34] <cjwatson> I think the cryptsetup people in Debian just forgot that GRUB parsing LUKS is a thing
[13:34] <tsimonq2> I'll be happy to look this afternoon and file a block-proposed bug, unless either of you volunteer.
[13:34] <infinity> tsimonq2: Please make it so.
[13:35] <tsimonq2> Alright.
[13:37] <infinity> "LUKS1 can be in-place-converted to LUKS2 in most cases."
[13:38] <infinity> So, users are going to do this to themselves?
[13:38] <infinity> Excellent.
[13:39] <LeoB> cpaelzer, hello! I need to build libvirt packages for a ppc64el machine, in order to test it, but it fails when I try building on ppc64le. Error message https://paste.ubuntu.com/p/M5dwXvjbFF/
[13:40] <cjwatson> Yeah, now that I've realised this is a problem I may see if I can manage an implementation in GRUB
[13:40] <cjwatson> The LUKS1 code is only 485 lines
[13:47] <LeoB> cpaelzer, *test a patch
[13:49] <TJ-> infinity: cjwatson There's a related initramfs-tools issue too, for LUKS2: Bug #1813295
[13:49] <ubottu> bug 1813295 in cryptsetup (Ubuntu) "initramfs-tools MODULES=dep causes LUKSv2 unlock to fail" [Undecided,Confirmed] https://launchpad.net/bugs/1813295
[13:50] <cjwatson> OK, at least that's different in kind because that doesn't involve another LUKS parser :)
=== ddstreet_away is now known as ddstreet
[13:54] <TJ-> :) I like to make life easy for you
[13:56] <TJ-> FYI, I'm managing LUKS systems with separate /boot/ and LVM, and learned (last August) the hard way that /boot/ has to be LUKS1 whilst LVM can be LUKS2 ! I thought I reported a bug on it but cannot find it now.
[14:20] <cyphermox> I thought we'd already changed that to MODULES=most
[14:24] <cyphermox> ah maybe not
[15:03] <jamespage> roaksoax: https://bugs.launchpad.net/ubuntu/+source/python-libmaas/+bug/1823718 ;)
[15:03] <ubottu> Launchpad bug 1823718 in python-libmaas (Ubuntu) "Installation fails with Python3.7 SyntaxError on Ubuntu Disco" [Undecided,New]
[15:07] <sil2100> !dmb-ping
[15:07] <ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
[15:09] <TJ-> cyphermox: re: MODULES=most, yes that is the default, but I prefer to use 'dep' since the initrd.img does not need almost every module and supporting firmware image (combined with my own pruning code it reduces initrd.img from ~60MB to ~15MB - a nice saving in both build and boot-time
=== Orphis_ is now known as Orphis
=== tdaitx_ is now known as tdaitx
[19:38] <xnox> tsimonq2, cjwatson, cyphermox - no, we should default to luks2.
[19:38] <xnox> tsimonq2, cjwatson, cyphermox - grub has luks1 support, but we don't build that module into grub-signed, therefore on secureboot systems currently on Ubuntu one cannot have encrypted /boot.
[19:39] <xnox> tsimonq2, cjwatson, cyphermox - thus in ubuntu, there is no regression w.r.t. luks1->luks2 switch. Luks2 is better, and has better defaults for key derivation functions. it is more logical to request/implement luks2 in grub.
[19:39] <tsimonq2> xnox: When's the last time you checked that?
[19:39] <tsimonq2> Also, that doesn't apply on BIOS.
[19:39] <xnox> tsimonq2, cjwatson, cyphermox - also we will be requiring and using luks2 in core20.
[19:40] <wxl> hopefully grub will be compatible by then :/
[19:40] <TJ-> tsimonq2: what xnox says affects all my systems (signed GRUB not including the luks/cryptodisk/gcry_* modules)
[19:40] <xnox> tsimonq2, cjwatson, cyphermox - also there are trivial options you can pass to force luks1 if you want to downgrade security/crackability of the default fde setup.
[19:40] <tsimonq2> TJ-: Have you checked with Disco?
[19:41] <xnox> tsimonq2, disco uses luks2 by default, and there is no luks2 support in grub yet. end of story =)
[19:41] <tsimonq2> No, not end of story. :)
[19:41] <tsimonq2> That's called a regression.
[19:41] <xnox> tsimonq2, are you telling that we should downgrade default security of all Ubuntu installations because of Lubuntu on bios?
[19:41] <tsimonq2> LUKS as implemented by default in Ubuntu worked with GRUB in Cosmicm
[19:41] <tsimonq2> *Cosmic.
[19:42] <tsimonq2> No, I'm not saying that.
[19:42] <xnox> tsimonq2, and still does. for /, and we do require separate unencrypted /boot.
[19:42] <xnox> as we did before, and still do.
[19:42] <xnox> unless i am missing something, and we started to encrypt /boot somewhere.
[19:42] <tsimonq2> Are you suggesting Lubuntu downgrades security because Ubuntu is too fast in switching to LUKS2?
[19:42] <xnox> i don't believe neither partman, ubiquity, or subiquity do that.
[19:42] <tsimonq2> Nope.
[19:42] <cyphermox> there's a simpler story to this right now, i think
[19:43] <xnox> tsimonq2, luks2 support was added in bionic, and make default in disco. Sounds the right speed, as any bionic system can luks2-unlock.
[19:43] <wxl> what *requirement* is there for luks2 at this point? besides "it's nicer"
[19:43] <xnox> s/make/was made/
[19:43] <tsimonq2> wxl: +1
[19:43] <tsimonq2> I'm not saying we carve out support.
[19:44] <wxl> making luks1 the default does not remove the ability to use luks2
[19:44] <xnox> wxl, it's harder to crack open; and it stores more info/parameters about the volume in the header (with bigger header), thus it's easier to unlock it correctly without destroying data without having a matching crypttab.
[19:44] <TJ-> tsimonq2: No, not tested with Disco - It looks like disco-devel does include the modules from the debian/build-efi-images script
[19:44] <tsimonq2> infinity: You were involved in this discussion as well. ^
[19:44] <wxl> xnox: that all falls under "it's nicer"
[19:44] <cyphermox> xnox: tsimonq2: TJ-: the partitioning schemes we currently support on everything but calamares are such that grub doesn't need to read luks
[19:45] <cyphermox> ie. "supported installs with disk encryption" are where there's a separate /boot that is unencrypted, for better or for worse, at the moment
[19:46] <cyphermox> the way I see this, calamares doing this differently is not sufficient rationale for changing the default to luks1 everywhere, especially this late in the cycle
[19:46] <cyphermox> the way I see this, it's more like rationale to patch calamares to specify it wants luks1, somehow
[19:46] <cyphermox> (this may or may not require some work in luks to let you set that, I don't know)
[19:46] <xnox> tsimonq2, i kind of fail to see the poing of encrypting /boot, when ESP is not encrypted. and if calamares really only wants to manage a single encrypted volume, put the grub.cfg vmlinuz and initrd on the ESP.
[19:46] <tsimonq2> Upstream has rejected that, Manjaro and Fedora are facing the same issue.
[19:47] <wxl> of course an unencrypted /boot can lead to exposed keys, no?
[19:47] <xnox> wxl, how?
[19:47] <cyphermox> xnox: you could potentially have a compromised initrd.
[19:47] <xnox> wxl, in bios you have compromised grub
[19:47] <cyphermox> tsimonq2: upstream has rejected what?
[19:48] <xnox> cyphermox, yeah, but i don't see how it could be protected. cause grub is still unencrypted.
[19:48] <tsimonq2> cyphermox: Explicitly defining LUKS1.
[19:48] <cyphermox> tsimonq2: sure, but we can distro patch that
[19:49] <wxl> distro patching for something that's not entirely necessary is a bit of a pain
[19:49] <cyphermox> tsimonq2: what I'm advocating for is "reducing the security" where it potentially makes the least damage
[19:50] <cyphermox> wxl: I'd like to hear the security team on this, but I don't believe moving back to luks1 everywhere is necessarily better
[19:50] <cyphermox> I understand it's a recent change, so YMMV
[19:50] <wxl> yeah i would, too
[19:50] <xnox> luks1 doesn't support persistent encryption / paes / zkey on s390x.
[19:50] <tsimonq2> +1
[19:50] <wxl> perhaps that's the next step
[19:50] <wxl> i won't argue that luks2 has advantages
[19:50] <wxl> i mean it does
[19:51] <cyphermox> what I'm saying is: right now it kinda looks like it's easier/safer to patch calamares and only affect calamares, than change a default and affect every install of 19.04.
[19:51] <xnox> tsimonq2, wxl - to me it seems like an oversight, that calamares was using/relying on partitioning setups that no ubuntu flavours ever did, or were supported by ubuntu/foundations.
[19:52] <cyphermox> wxl: tsimonq2: TJ-: then once grub has support for dealing with LUKS2 in E; we can remove that patch
[19:52] <xnox> and if lubuntu defaults luks1, when ubuntu enables tpm2 / secureboot / measured boot -> it wouldn't work on lubuntu installs.
[19:53] <xnox> to counter cyphermox's proposal, i'd rather have calamares create unencrypted /boot, until grub2 gains luks2 support.
[19:53] <wxl> wait a minute.. since building the luks1 as default means luks2 is available, couldn't we rework ubiquity et al to call cryptsetup to use luks2 explicityly and all would be fine?
[19:53] <xnox> wxl, no. as it's not just ubiquity.
[19:53] <wxl> thus "et al"
[19:53] <cyphermox> wxl: we could, but that's still changing "every install" rather than limiting the change to lubuntu
[19:53] <TJ->  mad idea but... could GRUB be side-stepped for the specific LUKSv1 scenario in favour of a direct SecureBoot of vmlinuz ?
[19:54] <xnox> wxl, it's udisks2, gnome-disks, partman-crypto, ubiquity, s390-tools zkey, and many 3rd party disk encrptyion and key escort tools (floss and proprietary).
[19:54] <cyphermox> TJ-: only if you want to keep all three pieces
[19:54] <wxl> cyphermox: but that would be a minor change and one that even with luks2 as the default would not likely make any difference
[19:54] <cyphermox> TJ-: it's "possible", but it imposes a lot of work on your users
[19:54] <TJ-> cyphermox: yeah, I did say it was mad :D
[19:54] <cyphermox> wxl: I'm not sure I follow
[19:54] <xnox> TJ-, our vllinuz is signed with canonical key, so you'd need to mess with MOK to enroll canonical's keys into secureboot.... which at the mometn has ugly ux, but doable.
[19:55] <tsimonq2> Lubuntu is between a rock and  a hard place here. Upstream won't default to LUKS1 as default, and says "build cryptsetup differently downstream." Both of you are NACKing it, even though it shipped this way in every supported stable Ubuntu release. If there's a security problem here, it should be in all releases of Ubuntu, not just Disco. Lubuntu has had repeated conversations with the release team
[19:55] <TJ-> xnox: true too :)
[19:55] <tsimonq2> in which it was understood that Foundations couldn't support Calamares, but we're welcome to fix our own stuff. This isn't even a Calamares issue as much as it's a GRUB issue; if someone does custom partitioning, they'll likely face this as well.
[19:55] <wxl> cyphermox: there's two ways to essentially toggle between luks1/2.. compile cryptsetup with the default you want.. or call cryptsetup with the explicit version
[19:55] <xnox> TJ-, also one would loose grub benefits of fallbacks / recordfail which are standard on *buntu.
[19:55] <tsimonq2> It's too late in the game for Lubuntu to switch back to Ubiquity.
[19:56] <TJ-> xnox: yes, I was just trying to come up with a novel sneaky way past the issue
[19:56] <cyphermox> wxl: yes
[19:56] <cyphermox> wxl: changing one installer or another is relatively equivalent
[19:56] <xnox> tsimonq2, i do not believe for a second, that changing a cryptsetup command in calamares to '--format=luks" or changeing the default recipy to have '/boot' in calamares, as a distro patch, is somehow "non-trivial"
[19:56] <xnox> *luks1 that is.
[19:56] <wxl> cyphermox: so the installers could simply call cryptsetup with the explicit version call, regardless of what the default version is
[19:57] <xnox> wxl, sure, but sensible defaults should always be there. Otherwise systems become unusable.
[19:57] <wxl> moreover, if luks2 became the default, the explicit call wouldn't need to be fixed.. it would still work
[19:57] <xnox> wxl, and relying on luks1 in grub, is well, not a sensible thing. plus what did calamares do before? because surely luks1 was not in grub in like bionic? was it?
[19:57] <cyphermox> personally, I'm naking the change based on 'it's better to affect a single flavour with a change than all of them'
[19:58] <cyphermox> wxl: again, I got lost. isn't the default luks2 now?
[19:58] <tsimonq2> xnox: Yes, it was.
[19:58] <cyphermox> and installers all DTRT with default calls?
[19:58] <xnox> tsimonq2, ack.
[19:58] <TJ-> wxl: yes; that's how I recovered the two times this bit me last year before I had it in my mind to always force LUKSv1 for /boot/
[19:58] <tsimonq2> GRUB2 supports LUKS1.
[19:58] <wxl> cyphermox: right. and we're asking for luks1 to be the default.
[19:58] <cyphermox> except calamares, because it partitions things differently than all the other installers
[19:58] <xnox> wxl, what you are really asking is for /boot to be luks1
[19:59] <xnox> wxl, imho, the best thing for calamares to do is unencrypted bios or ESP, then luks1 /boot, then luks2 for the rest.
[19:59] <cyphermox> xnox: /boot is no different than / in their setup I think.
[19:59] <cyphermox> and moving things around is even more work.
[19:59] <cyphermox> (and even more uncertainty)
[20:00] <xnox> sure sure, but well quickly write luks2 support partch into grub, is not gonna happen before release.
[20:00] <wxl> exactly
[20:00] <tsimonq2> xnox: https://cgit.kde.org/kpmcore.git/tree/ is the backend Calamares uses for partitioning.
[20:00] <tsimonq2> I'd be curious to see where that flag is.
[20:00] <cyphermox> xnox: I don't think splitting up a disk encryption scheme and moving files around is much more realistic
[20:01] <xnox> heh
[20:01] <cyphermox> xnox: that's why I think changing one cryptsetup call is simple.
[20:01] <xnox> tsimonq2, i see clearly there luks2 and luks1.... and i clearly see it passing --type luks1
[20:02] <xnox> tsimonq2, i see clearly there --type luks2 in luks2 "formatting method"
[20:02] <tsimonq2> Calamares certainly hasn't changed, cryptsetup did.
[20:02] <tsimonq2> What would cause the explicit calls for each type to be ignored?
[20:03] <cyphermox> tsimonq2: wha?
[20:04] <cyphermox> tsimonq2: I don't think there is anything ignored?
[20:05] <wxl> wait, we have to modify kpmcore here?
[20:05] <cyphermox> no
[20:05] <cyphermox> at least, it doesn't look so, the code is just a bit confusing.
[20:05] <wxl> because if we do that could be problematic
[20:06] <cyphermox> yup
[20:06] <tsimonq2> Alright, so here is the partition module of Calamares: https://github.com/calamares/calamares/tree/master/src/modules/partition
[20:06] <xnox> tsimonq2, wxl - i was pointed to kpmcore code, i opened it, and it has explicit types for luks1 and luks2.
[20:07] <xnox> tsimonq2, wxl - so at least kpmcore does what you want. very explicit about which luks* to use, and forcing cryptsetup to use the one that is asked.
[20:07] <xnox> that's all.
[20:08] <wxl> but kpmcore has the potential more far reaching effects/conflicts
[20:11] <cyphermox> wxl: tsimonq2: do you know where the automated partitioning is defined?
[20:11] <wxl> nope
[20:12] <xnox> wxl, tsimonq2 - so looking at https://github.com/calamares/calamares/blob/master/src/modules/partition/core/KPMHelpers.cpp#L140 it seems like you do want PartitionRole Luks1 Luks2, instead of just Luks => to match kpm.
[20:12] <xnox> wxl, tsimonq2 - or simply forse to use FileSystem::Luks1 in the FileSystemFactory::create( call
[20:12] <xnox> wxl, tsimonq2 and check if the luks1/luks2 kpmcore is in disco.....
[20:13] <xnox> wxl, tsimonq2 - also my teeth are in pain now, and i shouldn't be looking into that.... and it looks like your upstream are working well to support luks1 and luks2, at least in kpmcore.
[20:13] <xnox> (irrespective of availability / what is the default in cryptsetup)
[20:15] <tsimonq2> ok
[20:16] <LeoB> Hello, doing 'fakeroot debian/rules binary' on any source package is enough to build it ?
[20:24] <xnox> LeoB, not always, sometimes you may need to call 'fakeroot debian/rules clean binary' to be sure.
[20:24] <xnox> as sometimes clean target generates things.
[20:24] <xnox> and well install build-dependencies: sudo apt build-dep ./
[20:24] <xnox> and well be on a matching distro/chroot
[20:29] <LeoB> i am on the same distro (bionic ppc64el), did the build-dep and 'fakeroot debian/rules clean binary' . It fails on building libvirt packages
[20:31] <xnox> LeoB, well, use paste.ubuntu.com to show your log.
[20:32] <xnox> LeoB, where did you get the source from? Ubuntu? with like $ pull-lp-source libvirt bionic ?
[20:32] <xnox> LeoB, cause $ pull-lp-source libvirt bionic -> is the one that should build packages correctly. Not sure if it would be able to build all of arch:all packages or not though, it might only be able to build arch:ppc64el
[20:33] <rbasak> LeoB: I mentioned this before: after the clean, try the build target _without_ fakeroot. That is more accurate to how packages are really built.
[20:33] <rbasak> LeoB: and sbuild will get you closer.
[20:33] <xnox> LeoB, you can try ./debian/rules binary-arch -> that one will not build arch:all things
[20:35] <LeoB> i tried  pull-lp-source, apt-get source, and this git repository: https://git.launchpad.net/ubuntu/+source/libvirt
[20:36] <LeoB> all of them failed. I also tried without fakeroot. Now I will try './debian/rules binary-arch' as you suggested
[20:36] <xnox> LeoB, can you please givve us the paste showing as to why it failed and how?
[20:36] <xnox> LeoB, it's hard to guess...
[20:37] <xnox> LeoB, using paste.ubuntu.com or somewhere similar?
[20:37] <LeoB> yes, sure, I am just rebuilding to get the error message
[20:37] <xnox> LeoB, ideally the full log &> log.txt is nice.
[20:37] <LeoB> Is it better if I open a bug on that issue?
[20:37] <xnox> from start to finish.
[20:38] <xnox> LeoB, not really. cause you don't sound like you are doing a clean build with sbuild, in a pristine environment.
[20:39] <LeoB> ok then
[20:42] <xnox> LeoB, i'm gonna go away for a while, but will be back tomorrow. if you don't idle on irc with a bouncer, feel free to $ report-bug libvirt -> and then at least i'll be able to look it up and respond. Might be easier for you to attach build logs there.
[20:42] <xnox> LeoB, or just ask somebody else, there are plenty of people around to help out, once you can show a build log.
[20:43] <LeoB> ok, thanks xnox
[21:16] <infinity> LeoB: For the record, "dpkg-buildpackage -b" is what the buildds (and sbuild) call, which takes care of getting the right rootness for debian/rules targets, and makes sure you have build-deps satisfied, etc.
[21:17] <infinity> LeoB: Randomly calling debian/rules target is, indeed, the internal interface that gets the job done, but higher level tools are much less error-prone.
[21:23] <LeoB> thanks infinity
[21:36] <LeoB> infinity, "dpkg-buildpackage -b" also fails on https://git.launchpad.net/ubuntu/+source/libvirt
[21:39] <infinity> LeoB: I can't speak to that git repository, or its buildability.  The canonical source packages are the ones you get from the archive mirrors.
[21:40] <infinity> (Ubuntu isn't built from git, random git imports are built from Ubuntu)
[21:41] <infinity> LeoB: But also, pointing at a git repository doesn't really say which tag you tried to build, on which release you're building, how it failed, etc.
[21:45] <LeoB> origin/ubuntu/bionic-devel, https://paste.ubuntu.com/p/gWJ4Fh6zmj/
[21:47] <infinity> And you didn't alter virt-aa-helper.c in any way?
[21:47] <tsimonq2> xnox, wxl: So, I originally thought both of you were correct about it being in Calamares itself, but it's actually a kpmcore thing. The URL I linked earlier is master, and the version currently in the archive doesn't have `--type luks1` in the arguments for LUKS. Testing that, and if it works, I'll upload.
[21:47] <infinity> And you're building on bionic?
[21:48] <LeoB> yes, and yes
[21:49] <infinity> gcc --version
[21:50] <LeoB> gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
[21:51] <infinity> Cause that source built fine on bionic on ppc64el just a few weeks ago.
[21:53] <LeoB> Now I could build with pull-lp-source and sbuind, but not with dkpg-buildpackage
[21:53] <LeoB> on the git repo
[21:53] <infinity> Ahh, well, if the git repo is broken, that's less interesting to me. :P
[21:54] <infinity> Like I said, that's not the source.  The source packages from the archive are the source.
[21:55] <LeoB> Ok, when people try to backport patches, what do they use, that is synced with the source packages?
[21:56] <infinity> That said, looking at the official build, that same error is there, it's just emitted as a warning, not an error.
[21:56] <infinity> Do you have explicity -Wall CFLAGS in your environment or anything similarly silly?
[21:56] <infinity> Or -Werror, I should say.
[21:56] <infinity> This doesn't look like a bug with the source, but a bug with how you're building it.
[21:57] <infinity> sbuild gives you a clean enviornment and warns on that enum issue, your more manual build is upgrading that warning to an error.
[21:58] <cjwatson> xnox: I think I missed most of this discussion, but it's news to me that we don't build luks into grub2-signed.  I fixed that in Debian in -10, and AFAIK that was merged in disco.
[21:59] <tsimonq2> cjwatson: Correct.
[21:59] <infinity> cjwatson: Yeah, I believe we all decided he was mistaken.  On the other hand, "merged in disco" makes it pretty hard to argue that disco has a regression in grub-vs-luks handling. :P
[21:59] <cjwatson> For the SB case, sure.
[21:59]  * infinity nods.
[22:00] <cjwatson> It's a problem in Debian buster because people are being upgraded from non-SB to SB.
[22:00] <LeoB> infinity, running sbuild over the git repo doesn't seem to work also
[22:00] <mwhudson> infinity: comments on https://github.com/CanonicalLtd/subiquity/pull/445 welcome
[22:00] <cjwatson> (I think)
[22:01] <infinity> LeoB: Okay?  I mean, I geniunely don't know what you're doing, and you've proven yourself that the source from the archive build, so you have your way forward.
[22:01] <infinity> LeoB: Ubuntu packages aren't developed in git.  Some people prefer to muck about in that direction as its familiar tooling, but if you're going to submit fixes, it'll be patches against a source package, not git MPs against a non-authoritative branch.
[22:02] <LeoB> ok then
[22:02] <cjwatson> (aren't universally developed in git; many are of course)
[22:02] <LeoB> I redo my patch over this source package. Thanks
[22:02] <LeoB> infinity, ^
[22:03] <infinity> cjwatson: I should have said s/developed in/built from/ :P
[22:03] <infinity> Ultimately, all Ubuntu binary builds come from a source package upload.
[22:03] <infinity> What happens before that upload is irrelevant and, quite often, doesn't match.
[22:03] <infinity> Because reasons.
[22:05] <infinity> cjwatson: Hrm, do I take your openssh sync from 9m ago, or the one LocutusOfBorg beat you to by 50m?
[22:06] <cjwatson> Oh, I'm not precious about it
[22:07] <cjwatson> Flip a coin
[22:07] <LeoB> infinity, according to <cpaelzer> https://code.launchpad.net/~usd-import-team/ubuntu/+source/libvirt/+git/libvirt/+ref/ubuntu/bionic-devel should match what "pull-lp-source libvirt bionic" gives you right now
[22:07] <infinity> LeoB: Right, so we're back to the "it's how you're building it" argument.
[22:07] <infinity> LeoB: If you can make one work and not the other, you're driving one wrong.
[22:08] <infinity> LeoB: And it's pretty clear that one of those builds has -Werror and the other doesn't.
[22:08]  * infinity shrugs.
[22:09] <infinity> I can't really say more without driving your computer for you.
[22:09] <infinity> Well, "has -Werror" or "is using a different gcc that upgraded that warning to an error" or whatever.
[22:10] <LeoB> I have a clean checkout of the repository, no change at all, and I just do the same sbuild command from pull_lp_source
[22:11] <infinity> I mean, it can't be "the same sbuild command", unless you're skipping some steps.
[22:12] <infinity> Do you build the source package from the git repo with "dpkg-buildpackage -S"?
[22:12] <infinity> And then feed the .dsc to sbuild?
[22:12] <infinity> Either way, looking at the build log on the buildd and your pasted on, it's clear:
[22:12] <infinity> buildd:
[22:12] <infinity> configure:        Use -Werror: no
[22:12] <infinity> yours:
[22:12] <infinity> configure:        Use -Werror: yes
[22:16] <LeoB> it seems the git repo is different from the build packageq
[22:16] <LeoB> source package
[22:16] <cjwatson> That's easy enough to check - unpack the package and diff it against the git tree you have
[22:17] <LeoB> that's what i did
[22:17] <cjwatson> As a bonus that will tell you what the differences actually are and then you can iterate from there
[22:17] <LeoB> in order to say it is different
[22:17] <cjwatson> OK, so now you have the information needed to narrow it down
[22:19] <cjwatson> That said, I wonder if you actually need applied/ubuntu/bionic-devel rather than just ubuntu/bionic-devel
[22:20] <infinity> Probably.
[22:20] <cjwatson> Since unpacking the source package gives you the version with patches applied, so that's what you'd need if you're diffing
[22:21] <cjwatson> And sbuild would usually be run on a patches-applied tree
[22:22] <cjwatson> (Shouldn't matter actually, but I guess could)
[22:22] <infinity> Shouldn't?
[22:22] <infinity> Will dpkg-buildpackage apply series if it's unapplied?
[22:23] <cjwatson> Because sbuild would build a source package first and dpkg-source should DTRT
[22:23] <infinity> Oh.
[22:23] <cjwatson> dpkg-buildpackage won't, I think
[22:23] <infinity> Right, that.
[22:23] <infinity> Unless sbuild grew support for directly abusing source trees without the middle step.
[22:23] <cjwatson> (Anyway this is an overcomplicated digression)
[22:23] <infinity> But I haven't noticed such a feature.
[22:24] <infinity> Not that I'd be looking for it.
[22:29] <LeoB> with this 'applied' branch, it could build from git. Thanks for explaining what it means
[22:30] <LeoB> thanks cjwatson infinity ^
[22:30] <LeoB> ls
[22:32] <cjwatson> np