=== cpaelzer__ is now known as cpaelzer
cpaelzercjwatson: seeing you reminded me to ask for bug 182237009:39
ubottubug 1822370 in openssh (Ubuntu Disco) "19.04 beta openssh-client broken pipe" [Critical,Triaged] https://launchpad.net/bugs/182237009:39
cpaelzerthere was no further debian response that I'd have seen09:39
cpaelzerbut since we final freeze in 3 days I was wondering if you considered uploading that to Buster now (or not)09:40
cjwatsoncpaelzer: Yes I am considering it and was already looking at it before you pinged09:41
cjwatsonPlease stop asking for a while :)09:41
cpaelzer:_/ ok09:41
cpaelzereven my nose seems to slip out of my smiley face in shame09:42
dokocpaelzer, 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 welcome10:38
jamespagedoko: glance will need fixing - the errors look familiar10:41
jamespagethat ceph failure is odd10:41
* jamespage digs further10:41
rbasakcpaelzer: 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
ubottuLaunchpad bug 1822069 in xmltooling (Ubuntu) "SRU: Shibboleth SPv3 for bionic" [Undecided,New]10:44
dokojamespage: this is using ppa:ubuntu-toolchain-r/ppa10:45
jamespagedoko: the ceph failure is from the version in the release pocket rather than the -updates pocket - was that intentional?10:53
dokojamespage: ahh crap, wrong name for the updates archive. my script didn't error out on a missing archive :-/11:03
jamespagedoko: I think the one in the release pockets probably already FTBFS - ceph got stuck in proposed for most of that cycle11:08
jamespagethe glance failures look familiar as well11:08
jamespagebug 180060111:08
ubottubug 1800601 in glance (Ubuntu Disco) "[SRU] Infinite recursion in Python 3" [Critical,Fix released] https://launchpad.net/bugs/180060111:08
jamespageyeah that was done as an SRU post cosmic release11:09
dokonow regenerated http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190404-gcc8-cosmic.html11:11
dokothere are no regressions with the planned toolchain updates :-)11:11
dokosorry for the noise11:11
=== waveform_ is now known as waveform
cpaelzerrbasak: I had nothing to do with the bug that you listed11:31
cpaelzerwas it the right bug number?11:31
cpaelzerrbasak: do you know https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1823665 which doko was asking about above?11:32
ubottuLaunchpad bug 1823665 in mysql-5.7 (Ubuntu) "mysql-5.7 ftbfs with cosmic toolchain updates (amd64, i386 only)" [High,New]11:32
rbasakcpaelzer: 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:34
rbasakSkuggen: could you take a look at bug 1823665 please?11:35
ubottubug 1823665 in mysql-5.7 (Ubuntu) "mysql-5.7 ftbfs with cosmic toolchain updates (amd64, i386 only)" [High,New] https://launchpad.net/bugs/182366511:35
dokocpaelzer, rbasak: that's fixed in -updates. my bad11:40
rbasakAh, no worries.11:41
rbasakSkuggen: cancel the above please :)11:41
dokoso just one symbols file regression with the proposed updates. better than expected11:48
=== ricab is now known as ricab|lunch
=== chrisccoulson_ is now known as chrisccoulson
SkuggenBest kind of issue; The kind that's fixed before I become aware of their existence12:54
tsimonq2cyphermox, 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:17
cjwatsonOh is that what that is13:21
cjwatsontsimonq2: If you're doing that could you also chase it with Debian?13:22
cjwatsonAssuming LUKS2 being the default explains the various reports I've seen about buster13:22
cjwatsonOr maybe it should be done in partman-crypto instead?13:23
cjwatsonThough 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 sense13:23
ubottuDebian bug 919725 in cryptsetup "cryptsetup: switch to LUKS2 by default for new installs" [Wishlist,Fixed]13:23
cjwatsonI think Debian must have the same problem and it's surely release-critical13:24
cjwatsonhttps://savannah.gnu.org/bugs/?55093 too13:25
tsimonq2cjwatson: ack, Ubuntu's release is sooner though :)13:32
tsimonq2I'll happily file a bug there too13:32
infinityDisturbingly soon for this to be "just" coming up as a thing.13:32
tsimonq2Better than release week.13:32
cjwatsonit became the default last month or so I think?13:32
cjwatsonthe 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 least13:33
infinityIs there a bug filed detailing the interactions here between cryptsetup, installers, grub, what needs changing, how to make sure they all agree?13:33
tsimonq2No, just a feature request in GRUB upstream.13:33
infinityWill flipping cryptsetup back make everything just go back to how it was in cosmic?13:33
cjwatsonPretty sure what needs changing is "configure cryptsetup with --with-default-luks-format=LUKS1"13:33
infinityCause +1 on that, if so.13:34
cjwatsonBut obviously wants testing13:34
tsimonq2cjwatson: Exactly.13:34
cjwatsonI think the cryptsetup people in Debian just forgot that GRUB parsing LUKS is a thing13:34
tsimonq2I'll be happy to look this afternoon and file a block-proposed bug, unless either of you volunteer.13:34
infinitytsimonq2: Please make it so.13:34
infinity"LUKS1 can be in-place-converted to LUKS2 in most cases."13:37
infinitySo, users are going to do this to themselves?13:38
LeoBcpaelzer, 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:39
cjwatsonYeah, now that I've realised this is a problem I may see if I can manage an implementation in GRUB13:40
cjwatsonThe LUKS1 code is only 485 lines13:40
LeoBcpaelzer, *test a patch13:47
TJ-infinity: cjwatson There's a related initramfs-tools issue too, for LUKS2: Bug #181329513:49
ubottubug 1813295 in cryptsetup (Ubuntu) "initramfs-tools MODULES=dep causes LUKSv2 unlock to fail" [Undecided,Confirmed] https://launchpad.net/bugs/181329513:49
cjwatsonOK, at least that's different in kind because that doesn't involve another LUKS parser :)13:50
=== ddstreet_away is now known as ddstreet
TJ-:) I like to make life easy for you13:54
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.13:56
cyphermoxI thought we'd already changed that to MODULES=most14:20
cyphermoxah maybe not14:24
jamespageroaksoax: https://bugs.launchpad.net/ubuntu/+source/python-libmaas/+bug/1823718 ;)15:03
ubottuLaunchpad bug 1823718 in python-libmaas (Ubuntu) "Installation fails with Python3.7 SyntaxError on Ubuntu Disco" [Undecided,New]15:03
ubottucyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.15:07
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-time15:09
=== Orphis_ is now known as Orphis
=== tdaitx_ is now known as tdaitx
xnoxtsimonq2, cjwatson, cyphermox - no, we should default to luks2.19:38
xnoxtsimonq2, 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:38
xnoxtsimonq2, 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
tsimonq2xnox: When's the last time you checked that?19:39
tsimonq2Also, that doesn't apply on BIOS.19:39
xnoxtsimonq2, cjwatson, cyphermox - also we will be requiring and using luks2 in core20.19:39
wxlhopefully 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
xnoxtsimonq2, 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
tsimonq2TJ-: Have you checked with Disco?19:40
xnoxtsimonq2, disco uses luks2 by default, and there is no luks2 support in grub yet. end of story =)19:41
tsimonq2No, not end of story. :)19:41
tsimonq2That's called a regression.19:41
xnoxtsimonq2, are you telling that we should downgrade default security of all Ubuntu installations because of Lubuntu on bios?19:41
tsimonq2LUKS as implemented by default in Ubuntu worked with GRUB in Cosmicm19:41
tsimonq2No, I'm not saying that.19:42
xnoxtsimonq2, and still does. for /, and we do require separate unencrypted /boot.19:42
xnoxas we did before, and still do.19:42
xnoxunless i am missing something, and we started to encrypt /boot somewhere.19:42
tsimonq2Are you suggesting Lubuntu downgrades security because Ubuntu is too fast in switching to LUKS2?19:42
xnoxi don't believe neither partman, ubiquity, or subiquity do that.19:42
cyphermoxthere's a simpler story to this right now, i think19:42
xnoxtsimonq2, luks2 support was added in bionic, and make default in disco. Sounds the right speed, as any bionic system can luks2-unlock.19:43
wxlwhat *requirement* is there for luks2 at this point? besides "it's nicer"19:43
xnoxs/make/was made/19:43
tsimonq2wxl: +119:43
tsimonq2I'm not saying we carve out support.19:43
wxlmaking luks1 the default does not remove the ability to use luks219:44
xnoxwxl, 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 script19:44
tsimonq2infinity: You were involved in this discussion as well. ^19:44
wxlxnox: that all falls under "it's nicer"19:44
cyphermoxxnox: tsimonq2: TJ-: the partitioning schemes we currently support on everything but calamares are such that grub doesn't need to read luks19:44
cyphermoxie. "supported installs with disk encryption" are where there's a separate /boot that is unencrypted, for better or for worse, at the moment19:45
cyphermoxthe way I see this, calamares doing this differently is not sufficient rationale for changing the default to luks1 everywhere, especially this late in the cycle19:46
cyphermoxthe way I see this, it's more like rationale to patch calamares to specify it wants luks1, somehow19:46
cyphermox(this may or may not require some work in luks to let you set that, I don't know)19:46
xnoxtsimonq2, 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
tsimonq2Upstream has rejected that, Manjaro and Fedora are facing the same issue.19:46
wxlof course an unencrypted /boot can lead to exposed keys, no?19:47
xnoxwxl, how?19:47
cyphermoxxnox: you could potentially have a compromised initrd.19:47
xnoxwxl, in bios you have compromised grub19:47
cyphermoxtsimonq2: upstream has rejected what?19:47
xnoxcyphermox, yeah, but i don't see how it could be protected. cause grub is still unencrypted.19:48
tsimonq2cyphermox: Explicitly defining LUKS1.19:48
cyphermoxtsimonq2: sure, but we can distro patch that19:48
wxldistro patching for something that's not entirely necessary is a bit of a pain19:49
cyphermoxtsimonq2: what I'm advocating for is "reducing the security" where it potentially makes the least damage19:49
cyphermoxwxl: I'd like to hear the security team on this, but I don't believe moving back to luks1 everywhere is necessarily better19:50
cyphermoxI understand it's a recent change, so YMMV19:50
wxlyeah i would, too19:50
xnoxluks1 doesn't support persistent encryption / paes / zkey on s390x.19:50
wxlperhaps that's the next step19:50
wxli won't argue that luks2 has advantages19:50
wxli mean it does19:50
cyphermoxwhat 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
xnoxtsimonq2, 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:51
cyphermoxwxl: tsimonq2: TJ-: then once grub has support for dealing with LUKS2 in E; we can remove that patch19:52
xnoxand if lubuntu defaults luks1, when ubuntu enables tpm2 / secureboot / measured boot -> it wouldn't work on lubuntu installs.19:52
xnoxto counter cyphermox's proposal, i'd rather have calamares create unencrypted /boot, until grub2 gains luks2 support.19:53
wxlwait 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
xnoxwxl, no. as it's not just ubiquity.19:53
wxlthus "et al"19:53
cyphermoxwxl: we could, but that's still changing "every install" rather than limiting the change to lubuntu19:53
TJ- mad idea but... could GRUB be side-stepped for the specific LUKSv1 scenario in favour of a direct SecureBoot of vmlinuz ?19:53
xnoxwxl, 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
cyphermoxTJ-: only if you want to keep all three pieces19:54
wxlcyphermox: but that would be a minor change and one that even with luks2 as the default would not likely make any difference19:54
cyphermoxTJ-: it's "possible", but it imposes a lot of work on your users19:54
TJ-cyphermox: yeah, I did say it was mad :D19:54
cyphermoxwxl: I'm not sure I follow19:54
xnoxTJ-, 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:54
tsimonq2Lubuntu 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 team19:55
TJ-xnox: true too :)19:55
tsimonq2in 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
wxlcyphermox: there's two ways to essentially toggle between luks1/2.. compile cryptsetup with the default you want.. or call cryptsetup with the explicit version19:55
xnoxTJ-, also one would loose grub benefits of fallbacks / recordfail which are standard on *buntu.19:55
tsimonq2It's too late in the game for Lubuntu to switch back to Ubiquity.19:55
TJ-xnox: yes, I was just trying to come up with a novel sneaky way past the issue19:56
cyphermoxwxl: yes19:56
cyphermoxwxl: changing one installer or another is relatively equivalent19:56
xnoxtsimonq2, 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
wxlcyphermox: so the installers could simply call cryptsetup with the explicit version call, regardless of what the default version is19:56
xnoxwxl, sure, but sensible defaults should always be there. Otherwise systems become unusable.19:57
wxlmoreover, if luks2 became the default, the explicit call wouldn't need to be fixed.. it would still work19:57
xnoxwxl, 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
cyphermoxpersonally, I'm naking the change based on 'it's better to affect a single flavour with a change than all of them'19:57
cyphermoxwxl: again, I got lost. isn't the default luks2 now?19:58
tsimonq2xnox: Yes, it was.19:58
cyphermoxand installers all DTRT with default calls?19:58
xnoxtsimonq2, 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
tsimonq2GRUB2 supports LUKS1.19:58
wxlcyphermox: right. and we're asking for luks1 to be the default.19:58
cyphermoxexcept calamares, because it partitions things differently than all the other installers19:58
xnoxwxl, what you are really asking is for /boot to be luks119:58
xnoxwxl, imho, the best thing for calamares to do is unencrypted bios or ESP, then luks1 /boot, then luks2 for the rest.19:59
cyphermoxxnox: /boot is no different than / in their setup I think.19:59
cyphermoxand moving things around is even more work.19:59
cyphermox(and even more uncertainty)19:59
xnoxsure sure, but well quickly write luks2 support partch into grub, is not gonna happen before release.20:00
tsimonq2xnox: https://cgit.kde.org/kpmcore.git/tree/ is the backend Calamares uses for partitioning.20:00
tsimonq2I'd be curious to see where that flag is.20:00
cyphermoxxnox: I don't think splitting up a disk encryption scheme and moving files around is much more realistic20:00
cyphermoxxnox: that's why I think changing one cryptsetup call is simple.20:01
xnoxtsimonq2, i see clearly there luks2 and luks1.... and i clearly see it passing --type luks120:01
xnoxtsimonq2, i see clearly there --type luks2 in luks2 "formatting method"20:02
tsimonq2Calamares certainly hasn't changed, cryptsetup did.20:02
tsimonq2What would cause the explicit calls for each type to be ignored?20:02
cyphermoxtsimonq2: wha?20:03
cyphermoxtsimonq2: I don't think there is anything ignored?20:04
wxlwait, we have to modify kpmcore here?20:05
cyphermoxat least, it doesn't look so, the code is just a bit confusing.20:05
wxlbecause if we do that could be problematic20:05
tsimonq2Alright, so here is the partition module of Calamares: https://github.com/calamares/calamares/tree/master/src/modules/partition20:06
xnoxtsimonq2, wxl - i was pointed to kpmcore code, i opened it, and it has explicit types for luks1 and luks2.20:06
xnoxtsimonq2, 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
xnoxthat's all.20:07
wxlbut kpmcore has the potential more far reaching effects/conflicts20:08
cyphermoxwxl: tsimonq2: do you know where the automated partitioning is defined?20:11
xnoxwxl, 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
xnoxwxl, tsimonq2 - or simply forse to use FileSystem::Luks1 in the FileSystemFactory::create( call20:12
xnoxwxl, tsimonq2 and check if the luks1/luks2 kpmcore is in disco.....20:12
xnoxwxl, 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:13
LeoBHello, doing 'fakeroot debian/rules binary' on any source package is enough to build it ?20:16
xnoxLeoB, not always, sometimes you may need to call 'fakeroot debian/rules clean binary' to be sure.20:24
xnoxas sometimes clean target generates things.20:24
xnoxand well install build-dependencies: sudo apt build-dep ./20:24
xnoxand well be on a matching distro/chroot20:24
LeoBi am on the same distro (bionic ppc64el), did the build-dep and 'fakeroot debian/rules clean binary' . It fails on building libvirt packages20:29
xnoxLeoB, well, use paste.ubuntu.com to show your log.20:31
xnoxLeoB, where did you get the source from? Ubuntu? with like $ pull-lp-source libvirt bionic ?20:32
xnoxLeoB, 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:ppc64el20:32
rbasakLeoB: 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
rbasakLeoB: and sbuild will get you closer.20:33
xnoxLeoB, you can try ./debian/rules binary-arch -> that one will not build arch:all things20:33
LeoBi tried  pull-lp-source, apt-get source, and this git repository: https://git.launchpad.net/ubuntu/+source/libvirt20:35
LeoBall of them failed. I also tried without fakeroot. Now I will try './debian/rules binary-arch' as you suggested20:36
xnoxLeoB, can you please givve us the paste showing as to why it failed and how?20:36
xnoxLeoB, it's hard to guess...20:36
xnoxLeoB, using paste.ubuntu.com or somewhere similar?20:37
LeoByes, sure, I am just rebuilding to get the error message20:37
xnoxLeoB, ideally the full log &> log.txt is nice.20:37
LeoBIs it better if I open a bug on that issue?20:37
xnoxfrom start to finish.20:37
xnoxLeoB, not really. cause you don't sound like you are doing a clean build with sbuild, in a pristine environment.20:38
LeoBok then20:39
xnoxLeoB, 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
xnoxLeoB, or just ask somebody else, there are plenty of people around to help out, once you can show a build log.20:42
LeoBok, thanks xnox20:43
infinityLeoB: 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:16
infinityLeoB: 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:17
LeoBthanks infinity21:23
LeoBinfinity, "dpkg-buildpackage -b" also fails on https://git.launchpad.net/ubuntu/+source/libvirt21:36
infinityLeoB: 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:39
infinity(Ubuntu isn't built from git, random git imports are built from Ubuntu)21:40
infinityLeoB: 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:41
LeoBorigin/ubuntu/bionic-devel, https://paste.ubuntu.com/p/gWJ4Fh6zmj/21:45
infinityAnd you didn't alter virt-aa-helper.c in any way?21:47
tsimonq2xnox, 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
infinityAnd you're building on bionic?21:47
LeoByes, and yes21:48
infinitygcc --version21:49
LeoBgcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.021:50
infinityCause that source built fine on bionic on ppc64el just a few weeks ago.21:51
LeoBNow I could build with pull-lp-source and sbuind, but not with dkpg-buildpackage21:53
LeoBon the git repo21:53
infinityAhh, well, if the git repo is broken, that's less interesting to me. :P21:53
infinityLike I said, that's not the source.  The source packages from the archive are the source.21:54
LeoBOk, when people try to backport patches, what do they use, that is synced with the source packages?21:55
infinityThat said, looking at the official build, that same error is there, it's just emitted as a warning, not an error.21:56
infinityDo you have explicity -Wall CFLAGS in your environment or anything similarly silly?21:56
infinityOr -Werror, I should say.21:56
infinityThis doesn't look like a bug with the source, but a bug with how you're building it.21:56
infinitysbuild gives you a clean enviornment and warns on that enum issue, your more manual build is upgrading that warning to an error.21:57
cjwatsonxnox: 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:58
tsimonq2cjwatson: Correct.21:59
infinitycjwatson: 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. :P21:59
cjwatsonFor the SB case, sure.21:59
* infinity nods.21:59
cjwatsonIt's a problem in Debian buster because people are being upgraded from non-SB to SB.22:00
LeoBinfinity, running sbuild over the git repo doesn't seem to work also22:00
mwhudsoninfinity: comments on https://github.com/CanonicalLtd/subiquity/pull/445 welcome22:00
cjwatson(I think)22:00
infinityLeoB: 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
infinityLeoB: 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:01
LeoBok then22:02
cjwatson(aren't universally developed in git; many are of course)22:02
LeoBI redo my patch over this source package. Thanks22:02
LeoBinfinity, ^22:02
infinitycjwatson: I should have said s/developed in/built from/ :P22:03
infinityUltimately, all Ubuntu binary builds come from a source package upload.22:03
infinityWhat happens before that upload is irrelevant and, quite often, doesn't match.22:03
infinityBecause reasons.22:03
infinitycjwatson: Hrm, do I take your openssh sync from 9m ago, or the one LocutusOfBorg beat you to by 50m?22:05
cjwatsonOh, I'm not precious about it22:06
cjwatsonFlip a coin22:07
LeoBinfinity, 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 now22:07
infinityLeoB: Right, so we're back to the "it's how you're building it" argument.22:07
infinityLeoB: If you can make one work and not the other, you're driving one wrong.22:07
infinityLeoB: And it's pretty clear that one of those builds has -Werror and the other doesn't.22:08
* infinity shrugs.22:08
infinityI can't really say more without driving your computer for you.22:09
infinityWell, "has -Werror" or "is using a different gcc that upgraded that warning to an error" or whatever.22:09
LeoBI have a clean checkout of the repository, no change at all, and I just do the same sbuild command from pull_lp_source22:10
infinityI mean, it can't be "the same sbuild command", unless you're skipping some steps.22:11
infinityDo you build the source package from the git repo with "dpkg-buildpackage -S"?22:12
infinityAnd then feed the .dsc to sbuild?22:12
infinityEither way, looking at the build log on the buildd and your pasted on, it's clear:22:12
infinityconfigure:        Use -Werror: no22:12
infinityconfigure:        Use -Werror: yes22:12
LeoBit seems the git repo is different from the build packageq22:16
LeoBsource package22:16
cjwatsonThat's easy enough to check - unpack the package and diff it against the git tree you have22:16
LeoBthat's what i did22:17
cjwatsonAs a bonus that will tell you what the differences actually are and then you can iterate from there22:17
LeoBin order to say it is different22:17
cjwatsonOK, so now you have the information needed to narrow it down22:17
cjwatsonThat said, I wonder if you actually need applied/ubuntu/bionic-devel rather than just ubuntu/bionic-devel22:19
cjwatsonSince unpacking the source package gives you the version with patches applied, so that's what you'd need if you're diffing22:20
cjwatsonAnd sbuild would usually be run on a patches-applied tree22:21
cjwatson(Shouldn't matter actually, but I guess could)22:22
infinityWill dpkg-buildpackage apply series if it's unapplied?22:22
cjwatsonBecause sbuild would build a source package first and dpkg-source should DTRT22:23
cjwatsondpkg-buildpackage won't, I think22:23
infinityRight, that.22:23
infinityUnless sbuild grew support for directly abusing source trees without the middle step.22:23
cjwatson(Anyway this is an overcomplicated digression)22:23
infinityBut I haven't noticed such a feature.22:23
infinityNot that I'd be looking for it.22:24
LeoBwith this 'applied' branch, it could build from git. Thanks for explaining what it means22:29
LeoBthanks cjwatson infinity ^22:30

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!