[06:31] <cpaelzer> 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] <cpaelzer> 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] <cpaelzer> but I have some of them which only build on x86 and others which only build on s390x
[06:32] <cpaelzer> the x86 bits are ok as they build in build-indep
[06:32] <cpaelzer> but the s390x bits are missing there obviously
[06:33] <cpaelzer> 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] <cpaelzer> 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] <cpaelzer> I'd want XB-Build-Indep-Architecture but not at the first stanza but per binary package
[06:35] <cpaelzer> unfortunately documentation on it is very thin (I found none)
[06:35] <cpaelzer> 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] <cpaelzer> rbasak: ^^ this is the build-indep *fun* that I mentioned briefly
[06:48] <cpaelzer> maybe a deeper understanding of foreign as an alternative would help, reading more docs ...
[08:00] <infinity> cpaelzer: You can't do what you want.
[08:00] <infinity> cpaelzer: You'll have to think slightly outside the box.
[08:00] <infinity> cpaelzer: Options like:
[08:01] <infinity> 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] <infinity> cpaelzer: Or:
[08:01] <infinity> 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] <cpaelzer> thanks infinity, that confirms what I was afraid of
[08:04] <infinity> 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] <cpaelzer> for now I've started to try cross building it properly
[08:04] <cpaelzer> 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] <infinity> cpaelzer: Oh, crossing is also valid if it doesn't have a bunch of external deps.
[08:04] <infinity> cpaelzer: What is the theoretical thing in question?
[08:05] <cpaelzer> varios qemu FW roms
[08:05] <infinity> cpaelzer: Oh!  Crossing is totally a valid option, then.
[08:05] <infinity> cpaelzer: firmware pretty much by definition has no external deps, so a working toolchain should be all you need.
[08:05] <cpaelzer> yeah should be, if it would not fall apart all the time :-)
[08:05] <infinity> Fall apart, how?
[08:06] <cpaelzer> last time I looked at it (long ago) and recently when the Debian maintainer looked at it it failed to cross build
[08:06] <infinity> I mean, barring really bad makefiles, CC=s390x-linux-gnu-gcc should be enough.
[08:06] <cpaelzer> I just threw away all old stuff we had and started all over again to take a fresh look
[08:06] <infinity> I've definitely taken this route in the past for PPC stuff.
[08:06] <cpaelzer> just setting CC=arch-cc-string and give it another chance
[08:06] <infinity> And, indeed, since we dropped the 32-bit PPC port, we HAVE to cross some FW bits for ppc64el.
[08:06] <infinity> Because reasons.
[08:06] <cpaelzer> hehe
[08:07] <cpaelzer> 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] <cpaelzer> thanks infinity
[08:07] <infinity> 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] <infinity> 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] <cpaelzer> it should be pure Make in this case
[08:09] <infinity> 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] <cpaelzer> 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] <infinity> And fixes to make that work should probably be very upstreamable.
[08:10] <infinity> 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] <infinity> Or, at least, disassembly-identical, if they're not reproducible-friendly.
[08:11] <cpaelzer> yeah that would be a great cross-check thanks for the hint
[08:15] <infinity> cpaelzer: Note that you'll need gcc-multilib (which also has a cross-equivalent meta) if it builds any -m31 crap.
[10:06] <cpaelzer> 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] <cpaelzer> I don't need to make the build env like multi-arch or so right?
[10:07] <cpaelzer> what is the trick to usually get around all the linking issues to the libs of the foreign arch?
[10:07] <cpaelzer> infinity: in case you are still around ^^
[10:19] <cjwatson> cpaelzer: As infinity said, "If it's autotools, you sometimes have to preseed some values it can't determine"
[10:19] <cjwatson> cpaelzer: Find the cache variable name that it's setting and set it on the configure command line
[10:20] <cjwatson> Assuming that it can be expected to have a reasonably constant value in an Ubuntu environment, anyway
[10:36] <cpaelzer> it's missing various libraries - essentially ...-dev as I only have e.g. libglib2.0-dev:amd64
[10:37] <cpaelzer> but not the same :s390x
[10:37] <cpaelzer> that is where I wonder if I need an multiarch env here
[10:38] <cpaelzer> no configure.ac or similar here
[10:38] <cpaelzer> so I doubt it autotools vars are a reason here
[10:43] <cpaelzer> I'd mostly want a) probably all my build-deps also as :s390x or b) better understand what I want :-)
[10:46] <cpaelzer> 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] <cjwatson> You can't have a multiarch env.
[10:47] <cjwatson> Find another answer :)
[10:47] <cpaelzer> cjwatson: another answer than "installing the dependencies I need" :-)
[10:48] <cpaelzer> that sounds like it will make it even more complex :-/
[10:50] <cjwatson> 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] <cpaelzer> What I eventually want to build will be fine without all those deps
[10:52] <cpaelzer> just the configure wants to check for all of it
[10:52] <cjwatson> Then override the configure checks somehow
[10:53] <cpaelzer> 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] <cpaelzer> cjwatson: yeah overrides like that are what I'm leaning to atm
[12:02] <cjwatson> 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
[13:46] <rbasak> 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] <rbasak> I'm not current with the DNS stack involving resolved nowadays :-/
[14:35] <brainwash> can one of the ubuntu devs take a look at bug 1801629 please?
[14:39] <brainwash> 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] <brainwash> bug appeared in 18.10
[15:14] <rbasak> brainwash: does it affect the Ubuntu (default) flavor?
[15:14] <rbasak> Thank you for bringing it up. I just don't know who to ping!
[15:20] <brainwash> rbasak: I guess it does not, otherwise there would be more buzz around this bug
[15:22] <brainwash> and kubuntu is the only flavour that explicitly depends on cryptsetup and lvm2
[15:43] <rbasak> brainwash: perhaps we need to bring it to the attention of the flavor leads then?
[15:47] <brainwash> rbasak: xubuntu and ubuntu mate are tagged via the bug report already, and the xubuntu lead is subscribed to the report
[15:48] <brainwash> it would help to know what has changed from 18.04 to 18.10
[15:48] <brainwash> instead of just adding these packages as dependencies
[16:06] <rbasak> brainwash: something changed about what gets marked automatically installed I think.
[16:06] <rbasak> I don't remember the details.
[16:06] <rbasak> Maybe juliank knows?
[16:07] <juliank> yes, what's up?
[16:07] <juliank> Oh, that seems unfortunate.
[16:07] <rbasak> juliank: bug 1801629 - I think brainwash is looking for some background on the underlying change
[16:07] <juliank> It might be related to the work I did - it traversed the dpeendencies of all metapackages and marked them as automatically installed
[16:08] <juliank> So it _should_ be safe, but it might be missing corner cases where a metapackage was removed in ubiquity during install
[16:08] <rbasak> I guess we need to ensure that when the installer is done cryptsetup et al are marked as manually installed?
[16:08] <juliank> We can look at the log file and see what marked them automatic in the first place
[16:08] <rbasak> That ought to be a test case for encrypted installs now I guess.
[16:08] <juliank> at the image build log
[16:09] <juliank> We just need to get the build log for xubuntu 18.10, amd64 image
[16:10] <juliank> I think I found logs once, but I don't remember where
[16:10] <juliank> maybe vorlon or cjwatson know where to find the image build log?
[16:11] <cjwatson> Start from https://people.canonical.com/~ubuntu-archive/cd-build-logs/
[16:12] <juliank> cjwatson: the livecd-rootfs logs, actually
[16:12] <juliank> I think those are  debian-cd logs?
[16:13] <cjwatson> 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] <cjwatson> and you'll find a livefs build log there
[16:14] <juliank> Ah I see, thanks
[16:15] <seb128> 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] <juliank> 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] <juliank> I did not add the reason into the log, though
[16:19] <juliank> 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] <juliank> so, one of these depends on dmsetup which depends on lvm2: https://paste.ubuntu.com/p/ydGwDMckhm/
[16:21] <juliank> (or recommends it)
[16:23] <juliank> that is libdevmapper1.02.1
[16:24] <juliank> So ubuntu-minimal -> eject -> libdevmapper1.02.1 -> dmsetup -> lvm2 (where -> is Depends or Recommends)
[16:25] <juliank> so lvm2 should not be possible to autoremove
[16:31] <juliank> hmm, seems I have a bug in my procedure
[16:33] <juliank> ah, ubiquity -> dmeventd -> lvm2
[16:33] <juliank> that's why it's marked as auto
[16:34] <juliank> but not sure how we got to ubiquity as auto
[16:36] <juliank> Gotta extend the log with some tracing info I guess
[16:37] <juliank> 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] <juliank> seb128: see, I don't like this whole thing, it does not even handle trusted.gpg.d properly IIRC
[17:02] <seb128> juliank, right, it could use a maintainer and fixes, but working and suboptimal is still better than not working :)
[17:05] <brainwash> juliank: thanks for looking into this
[17:05] <juliank> I think we should have a simple PPA management tool instead for some PPA things
[17:05] <juliank> They now follow better conventions so you can easily add/remove ppas
[17:05] <juliank> brainwash: will do some more digging tomorrow
[17:05] <brainwash> okay
[17:07] <seb128> 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] <rbasak> 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] <juliank> seb128: I'll think about it tomorrow
[18:18] <juliank> rbasak: Its part of software- properties-common
[18:34] <seb128> juliank, thx
[18:58] <rbasak> juliank: yes, though I imagine some refactoring would be needed
[19:34] <ahasenack> 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] <ahasenack> sysv services usually define a RUN variable in /etc/default/<service>, that defaults to "no"
[19:35] <ahasenack> but with systemd, how to accomplish the same thing?
[19:35] <ahasenack> the job sources /etc/default/<service>, but how to treat this RUN variable?
[19:36] <ahasenack> case in point: https://git.launchpad.net/ubuntu/+source/freeipmi/tree/debian/freeipmi-ipmidetect.ipmidetectd.init#n70
[19:36] <ahasenack> 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] <juliank> stgraber: FYI: I forwarded your autopkgtest changes for lxd upstream 4 hours ago, they got merged 2.5 hours ago. Woohoo
[19:53] <juliank> Now we can sync that beast once the next version is out
[19:53] <stgraber> yay!
[19:53] <juliank> This will also fix qemu backend which is broken in disco right now due to python 3.7 incompatibilities
[19:53] <stgraber> I thought I sent it to Martin back then but maybe I forgot
[19:54] <juliank> or maybe he was too busy with other stuff, who knows
[19:54] <juliank> in any case, it's merged now