[06:31] FYI the architecture:all issue we discussed a few days ago still persists - the workaround does not work, let me explain again - maybe there are other hints [06:31] initial problem: I have some bits that are (once built) architecture neutral and can be used everywhere - so they should be architecture:all [06:31] but I have some of them which only build on x86 and others which only build on s390x [06:32] the x86 bits are ok as they build in build-indep [06:32] but the s390x bits are missing there obviously [06:33] I tried to create an extra architecture:all for the s390x bits and build them on s390x - they build, but due to architecture:all it uses the x86 build of the package to crate a ..._all.deb which does contain nothing [06:34] cjwatson: suggested XB-Build-Indep-Architecture but explained that it is global (not per package) so I can only decide to have either x86 or s390x bits build correctly [06:35] I'd want XB-Build-Indep-Architecture but not at the first stanza but per binary package [06:35] unfortunately documentation on it is very thin (I found none) [06:35] TL;DR: any hints if I could control to build two architetcure:all from one src, but one on x86 and one on s390x? [06:40] rbasak: ^^ this is the build-indep *fun* that I mentioned briefly [06:48] maybe a deeper understanding of foreign as an alternative would help, reading more docs ... [08:00] cpaelzer: You can't do what you want. [08:00] cpaelzer: You'll have to think slightly outside the box. [08:00] cpaelzer: Options like: [08:01] cpaelzer: 1) Have source A produce a foo-source binary package, then source B build-deps on that and builds the s390x arch all bits. [08:01] cpaelzer: Or: [08:01] cpaelzer: 2) Have source A build the s390x bits as an s390x deb, then source B build-deps on that deb and spits out an arch all. [08:03] thanks infinity, that confirms what I was afraid of [08:04] cpaelzer: Option 2 seems a not entirely unreasonable workaround, at least. So, foo produces foo-native_s390x.deb, then foo-repack is Build-Indep-Architecture:s390x, build-deps on foo-native, and spits out foo_all.deb [08:04] for now I've started to try cross building it properly [08:04] I think it is unlikely, but if that would work it woudl resolve all of that as I could build it on x86 into the arch:all [08:04] cpaelzer: Oh, crossing is also valid if it doesn't have a bunch of external deps. [08:04] cpaelzer: What is the theoretical thing in question? [08:05] varios qemu FW roms [08:05] cpaelzer: Oh! Crossing is totally a valid option, then. [08:05] cpaelzer: firmware pretty much by definition has no external deps, so a working toolchain should be all you need. [08:05] yeah should be, if it would not fall apart all the time :-) [08:05] Fall apart, how? [08:06] last time I looked at it (long ago) and recently when the Debian maintainer looked at it it failed to cross build [08:06] I mean, barring really bad makefiles, CC=s390x-linux-gnu-gcc should be enough. [08:06] I just threw away all old stuff we had and started all over again to take a fresh look [08:06] I've definitely taken this route in the past for PPC stuff. [08:06] just setting CC=arch-cc-string and give it another chance [08:06] And, indeed, since we dropped the 32-bit PPC port, we HAVE to cross some FW bits for ppc64el. [08:06] Because reasons. [08:06] hehe [08:07] I might ping later for some silly cross-build issue - but that certainly seems the way to go if I can make it work [08:07] thanks infinity [08:07] cpaelzer: Our cross toolchains are pretty mature, so any failure is going to be in the build system in question. Happy to help look if you stumble. [08:08] cpaelzer: If it's autotools, you sometimes have to preseed some values it can't determine, if it's pure Make, you just have to scrub it of any hardcoded stupid, etc. [08:09] it should be pure Make in this case [08:09] cpaelzer: For bonus points, I'd make all the x86 stuff crossable too, so the arch-indep arch legit stops being meaningful. :P [08:09] it's not even looking like the worst case to cross compile, it is just an area I have only touched slightly in the past [08:09] And fixes to make that work should probably be very upstreamable. [08:10] cpaelzer: As in, a solid goal would be to build the package on s390x and amd64 and have both the s390x and amd64 firmware come out byte-identical. [08:10] Or, at least, disassembly-identical, if they're not reproducible-friendly. [08:11] yeah that would be a great cross-check thanks for the hint [08:15] cpaelzer: Note that you'll need gcc-multilib (which also has a cross-equivalent meta) if it builds any -m31 crap. [10:06] I needed gcc-multilib-s390x-linux-gnu and also pkg-config-s390x-linux-gnu , but it still seems to me that the configure I need to run tries way to mcuh link/execute to check capabilties [10:06] I don't need to make the build env like multi-arch or so right? [10:07] what is the trick to usually get around all the linking issues to the libs of the foreign arch? [10:07] infinity: in case you are still around ^^ [10:19] cpaelzer: As infinity said, "If it's autotools, you sometimes have to preseed some values it can't determine" [10:19] cpaelzer: Find the cache variable name that it's setting and set it on the configure command line [10:20] Assuming that it can be expected to have a reasonably constant value in an Ubuntu environment, anyway [10:36] it's missing various libraries - essentially ...-dev as I only have e.g. libglib2.0-dev:amd64 [10:37] but not the same :s390x [10:37] that is where I wonder if I need an multiarch env here [10:38] no configure.ac or similar here [10:38] so I doubt it autotools vars are a reason here [10:43] I'd mostly want a) probably all my build-deps also as :s390x or b) better understand what I want :-) [10:46] for the record - I can add "deb [arch=s390x] http://ports.ubuntu.com/ubuntu-ports/ disco main universe" run apt update and then install libglib2.0-dev:s390x which gets it going [10:46] You can't have a multiarch env. [10:47] Find another answer :) [10:47] cjwatson: another answer than "installing the dependencies I need" :-) [10:48] that sounds like it will make it even more complex :-/ [10:50] If you can only build this thing by linking against libglib, then it's not just a matter of configure capability checks as you said above, right? [10:52] What I eventually want to build will be fine without all those deps [10:52] just the configure wants to check for all of it [10:52] Then override the configure checks somehow [10:53] I might need to check if this congirue has (or add it) any way of don't check for all the stuff I don't need in this case [10:53] cjwatson: yeah overrides like that are what I'm leaning to atm [12:02] vorlon: How likely are the various livecd-rootfs SRUs to land in the nearish future? I'd like to explore getting my various buildd image production changes into xenial and bionic === ricab is now known as ricab|lunch [13:46] xnox: around? Any opinion on bug 1717014 please? Given it affects ping, it presumably affects "getent hosts" so isn't bind9-specific. I suspect you might immediately know where the bug belongs? [13:46] bug 1717014 in bind9 (Ubuntu) "host stops searching domains when it gets back NSEC record" [Undecided,New] https://launchpad.net/bugs/1717014 [13:46] I'm not current with the DNS stack involving resolved nowadays :-/ [14:35] can one of the ubuntu devs take a look at bug 1801629 please? [14:35] bug 1801629 in xubuntu-meta (Ubuntu) "xubuntu-core needs to depend on cryptsetup and lvm2 or 'apt autoremove' will make a LUKS+LVM encrypted root partition non-bootable" [Undecided,Confirmed] https://launchpad.net/bugs/1801629 [14:39] it's a critical bug I'd think, and I assume that it needs to be fixed for every ubuntu flavour either separately or via a shared dependency list [14:40] bug appeared in 18.10 === ricab|lunch is now known as ricab [15:14] brainwash: does it affect the Ubuntu (default) flavor? [15:14] Thank you for bringing it up. I just don't know who to ping! [15:20] rbasak: I guess it does not, otherwise there would be more buzz around this bug [15:22] and kubuntu is the only flavour that explicitly depends on cryptsetup and lvm2 [15:43] brainwash: perhaps we need to bring it to the attention of the flavor leads then? [15:47] rbasak: xubuntu and ubuntu mate are tagged via the bug report already, and the xubuntu lead is subscribed to the report [15:48] it would help to know what has changed from 18.04 to 18.10 [15:48] instead of just adding these packages as dependencies [16:06] brainwash: something changed about what gets marked automatically installed I think. [16:06] I don't remember the details. [16:06] Maybe juliank knows? [16:07] yes, what's up? [16:07] Oh, that seems unfortunate. [16:07] juliank: bug 1801629 - I think brainwash is looking for some background on the underlying change [16:07] bug 1801629 in xubuntu-meta (Ubuntu) "xubuntu-core needs to depend on cryptsetup and lvm2 or 'apt autoremove' will make a LUKS+LVM encrypted root partition non-bootable" [Undecided,Confirmed] https://launchpad.net/bugs/1801629 [16:07] It might be related to the work I did - it traversed the dpeendencies of all metapackages and marked them as automatically installed [16:08] So it _should_ be safe, but it might be missing corner cases where a metapackage was removed in ubiquity during install [16:08] I guess we need to ensure that when the installer is done cryptsetup et al are marked as manually installed? [16:08] We can look at the log file and see what marked them automatic in the first place [16:08] That ought to be a test case for encrypted installs now I guess. [16:08] at the image build log [16:09] We just need to get the build log for xubuntu 18.10, amd64 image [16:10] I think I found logs once, but I don't remember where [16:10] maybe vorlon or cjwatson know where to find the image build log? [16:11] Start from https://people.canonical.com/~ubuntu-archive/cd-build-logs/ [16:12] cjwatson: the livecd-rootfs logs, actually [16:12] I think those are debian-cd logs? [16:13] juliank: if you look at the appropriate cd-build-logs log you'll find a link to the corresponding livefs build on LP [16:14] and you'll find a livefs build log there [16:14] Ah I see, thanks === cpaelzer_ is now known as cpaelzer [16:15] juliank, hey, I would like to have your input on https://code.launchpad.net/~silhusk/software-properties/lp1656100-remove-signing-keys/+merge/361160 , I did a review because it was sitting in the sponsoring queue but you probably know better than me about the apt-key questions I asked there and maybe you can help? [16:16] * cjwatson fixes cd-build-logs to be served as text/plain [16:17] rbasak, brainwash So I've been looking at the xubuntu build log for 20181017, which seems to be the release build or closes to it, and I don't see cryptsetup in there. I do see lvm2 being marked [16:19] I did not add the reason into the log, though [16:19] so it's hard to follow the trail [16:20] * juliank made the algorithm iterative rather than recursive and did not keep a stack [16:21] so, one of these depends on dmsetup which depends on lvm2: https://paste.ubuntu.com/p/ydGwDMckhm/ [16:21] (or recommends it) [16:23] that is libdevmapper1.02.1 [16:24] So ubuntu-minimal -> eject -> libdevmapper1.02.1 -> dmsetup -> lvm2 (where -> is Depends or Recommends) [16:25] so lvm2 should not be possible to autoremove [16:31] hmm, seems I have a bug in my procedure [16:33] ah, ubiquity -> dmeventd -> lvm2 [16:33] that's why it's marked as auto [16:34] but not sure how we got to ubiquity as auto [16:36] Gotta extend the log with some tracing info I guess [16:37] in any case, we might want get a list of all autoremovable stuff at the end of the ubiquity run and then mark those as manually installed [16:47] seb128: see, I don't like this whole thing, it does not even handle trusted.gpg.d properly IIRC [17:02] juliank, right, it could use a maintainer and fixes, but working and suboptimal is still better than not working :) [17:05] juliank: thanks for looking into this [17:05] I think we should have a simple PPA management tool instead for some PPA things [17:05] They now follow better conventions so you can easily add/remove ppas [17:05] brainwash: will do some more digging tomorrow [17:05] okay [17:07] juliank, still do you think it makes sense to display 16 chars key ids in the UI or should we do like the apt-key list command and have 8? [17:09] juliank: add-apt-repository seems to have evolved into the CLI version of such a tool. It does removals as well, and component enablement/disablement. Perhaps there's scope for some code sharing there. [18:17] seb128: I'll think about it tomorrow [18:18] rbasak: Its part of software- properties-common [18:34] juliank, thx [18:58] juliank: yes, though I imagine some refactoring would be needed [19:34] do we have a pattern for services which require configuration before they start, but can't have one supplied by default in the package? [19:34] sysv services usually define a RUN variable in /etc/default/, that defaults to "no" [19:35] but with systemd, how to accomplish the same thing? [19:35] the job sources /etc/default/, but how to treat this RUN variable? [19:36] case in point: https://git.launchpad.net/ubuntu/+source/freeipmi/tree/debian/freeipmi-ipmidetect.ipmidetectd.init#n70 [19:36] how to make https://git.launchpad.net/ubuntu/+source/freeipmi/tree/debian/freeipmi-ipmidetect.ipmidetectd.service respect that RUN variable? Or should it be installed masked by default? [19:52] stgraber: FYI: I forwarded your autopkgtest changes for lxd upstream 4 hours ago, they got merged 2.5 hours ago. Woohoo [19:53] Now we can sync that beast once the next version is out [19:53] yay! [19:53] This will also fix qemu backend which is broken in disco right now due to python 3.7 incompatibilities [19:53] I thought I sent it to Martin back then but maybe I forgot [19:54] or maybe he was too busy with other stuff, who knows [19:54] in any case, it's merged now