cpaelzerFYI 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 hints06:31
cpaelzerinitial problem: I have some bits that are (once built) architecture neutral and can be used everywhere - so they should be architecture:all06:31
cpaelzerbut I have some of them which only build on x86 and others which only build on s390x06:31
cpaelzerthe x86 bits are ok as they build in build-indep06:32
cpaelzerbut the s390x bits are missing there obviously06:32
cpaelzerI 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 nothing06:33
cpaelzercjwatson: 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 correctly06:34
cpaelzerI'd want XB-Build-Indep-Architecture but not at the first stanza but per binary package06:35
cpaelzerunfortunately documentation on it is very thin (I found none)06:35
cpaelzerTL;DR: any hints if I could control to build two architetcure:all from one src, but one on x86 and one on s390x?06:35
cpaelzerrbasak: ^^ this is the build-indep *fun* that I mentioned briefly06:40
cpaelzermaybe a deeper understanding of foreign as an alternative would help, reading more docs ...06:48
infinitycpaelzer: You can't do what you want.08:00
infinitycpaelzer: You'll have to think slightly outside the box.08:00
infinitycpaelzer: Options like:08:00
infinitycpaelzer: 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
infinitycpaelzer: Or:08:01
infinitycpaelzer: 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:01
cpaelzerthanks infinity, that confirms what I was afraid of08:03
infinitycpaelzer: 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.deb08:04
cpaelzerfor now I've started to try cross building it properly08:04
cpaelzerI 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:all08:04
infinitycpaelzer: Oh, crossing is also valid if it doesn't have a bunch of external deps.08:04
infinitycpaelzer: What is the theoretical thing in question?08:04
cpaelzervarios qemu FW roms08:05
infinitycpaelzer: Oh!  Crossing is totally a valid option, then.08:05
infinitycpaelzer: firmware pretty much by definition has no external deps, so a working toolchain should be all you need.08:05
cpaelzeryeah should be, if it would not fall apart all the time :-)08:05
infinityFall apart, how?08:05
cpaelzerlast time I looked at it (long ago) and recently when the Debian maintainer looked at it it failed to cross build08:06
infinityI mean, barring really bad makefiles, CC=s390x-linux-gnu-gcc should be enough.08:06
cpaelzerI just threw away all old stuff we had and started all over again to take a fresh look08:06
infinityI've definitely taken this route in the past for PPC stuff.08:06
cpaelzerjust setting CC=arch-cc-string and give it another chance08:06
infinityAnd, indeed, since we dropped the 32-bit PPC port, we HAVE to cross some FW bits for ppc64el.08:06
infinityBecause reasons.08:06
cpaelzerI might ping later for some silly cross-build issue - but that certainly seems the way to go if I can make it work08:07
cpaelzerthanks infinity08:07
infinitycpaelzer: 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:07
infinitycpaelzer: 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:08
cpaelzerit should be pure Make in this case08:09
infinitycpaelzer: For bonus points, I'd make all the x86 stuff crossable too, so the arch-indep arch legit stops being meaningful. :P08:09
cpaelzerit's not even looking like the worst case to cross compile, it is just an area I have only touched slightly in the past08:09
infinityAnd fixes to make that work should probably be very upstreamable.08:09
infinitycpaelzer: 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
infinityOr, at least, disassembly-identical, if they're not reproducible-friendly.08:10
cpaelzeryeah that would be a great cross-check thanks for the hint08:11
infinitycpaelzer: Note that you'll need gcc-multilib (which also has a cross-equivalent meta) if it builds any -m31 crap.08:15
cpaelzerI 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 capabilties10:06
cpaelzerI don't need to make the build env like multi-arch or so right?10:06
cpaelzerwhat is the trick to usually get around all the linking issues to the libs of the foreign arch?10:07
cpaelzerinfinity: in case you are still around ^^10:07
cjwatsoncpaelzer: As infinity said, "If it's autotools, you sometimes have to preseed some values it can't determine"10:19
cjwatsoncpaelzer: Find the cache variable name that it's setting and set it on the configure command line10:19
cjwatsonAssuming that it can be expected to have a reasonably constant value in an Ubuntu environment, anyway10:20
cpaelzerit's missing various libraries - essentially ...-dev as I only have e.g. libglib2.0-dev:amd6410:36
cpaelzerbut not the same :s390x10:37
cpaelzerthat is where I wonder if I need an multiarch env here10:37
cpaelzerno configure.ac or similar here10:38
cpaelzerso I doubt it autotools vars are a reason here10:38
cpaelzerI'd mostly want a) probably all my build-deps also as :s390x or b) better understand what I want :-)10:43
cpaelzerfor 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 going10:46
cjwatsonYou can't have a multiarch env.10:46
cjwatsonFind another answer :)10:47
cpaelzercjwatson: another answer than "installing the dependencies I need" :-)10:47
cpaelzerthat sounds like it will make it even more complex :-/10:48
cjwatsonIf 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:50
cpaelzerWhat I eventually want to build will be fine without all those deps10:52
cpaelzerjust the configure wants to check for all of it10:52
cjwatsonThen override the configure checks somehow10:52
cpaelzerI 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 case10:53
cpaelzercjwatson: yeah overrides like that are what I'm leaning to atm10:53
cjwatsonvorlon: 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 bionic12:02
=== ricab is now known as ricab|lunch
rbasakxnox: 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
ubottubug 1717014 in bind9 (Ubuntu) "host stops searching domains when it gets back NSEC record" [Undecided,New] https://launchpad.net/bugs/171701413:46
rbasakI'm not current with the DNS stack involving resolved nowadays :-/13:46
brainwashcan one of the ubuntu devs take a look at bug 1801629 please?14:35
ubottubug 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/180162914:35
brainwashit'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 list14:39
brainwashbug appeared in 18.1014:40
=== ricab|lunch is now known as ricab
rbasakbrainwash: does it affect the Ubuntu (default) flavor?15:14
rbasakThank you for bringing it up. I just don't know who to ping!15:14
brainwashrbasak: I guess it does not, otherwise there would be more buzz around this bug15:20
brainwashand kubuntu is the only flavour that explicitly depends on cryptsetup and lvm215:22
rbasakbrainwash: perhaps we need to bring it to the attention of the flavor leads then?15:43
brainwashrbasak: xubuntu and ubuntu mate are tagged via the bug report already, and the xubuntu lead is subscribed to the report15:47
brainwashit would help to know what has changed from 18.04 to 18.1015:48
brainwashinstead of just adding these packages as dependencies15:48
rbasakbrainwash: something changed about what gets marked automatically installed I think.16:06
rbasakI don't remember the details.16:06
rbasakMaybe juliank knows?16:06
juliankyes, what's up?16:07
juliankOh, that seems unfortunate.16:07
rbasakjuliank: bug 1801629 - I think brainwash is looking for some background on the underlying change16:07
ubottubug 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/180162916:07
juliankIt might be related to the work I did - it traversed the dpeendencies of all metapackages and marked them as automatically installed16:07
juliankSo it _should_ be safe, but it might be missing corner cases where a metapackage was removed in ubiquity during install16:08
rbasakI guess we need to ensure that when the installer is done cryptsetup et al are marked as manually installed?16:08
juliankWe can look at the log file and see what marked them automatic in the first place16:08
rbasakThat ought to be a test case for encrypted installs now I guess.16:08
juliankat the image build log16:08
juliankWe just need to get the build log for xubuntu 18.10, amd64 image16:09
juliankI think I found logs once, but I don't remember where16:10
juliankmaybe vorlon or cjwatson know where to find the image build log?16:10
cjwatsonStart from https://people.canonical.com/~ubuntu-archive/cd-build-logs/16:11
juliankcjwatson: the livecd-rootfs logs, actually16:12
juliankI think those are  debian-cd logs?16:12
cjwatsonjuliank: if you look at the appropriate cd-build-logs log you'll find a link to the corresponding livefs build on LP16:13
cjwatsonand you'll find a livefs build log there16:14
juliankAh I see, thanks16:14
=== cpaelzer_ is now known as cpaelzer
seb128juliank, 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:15
* cjwatson fixes cd-build-logs to be served as text/plain16:16
juliankrbasak, 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 marked16:17
juliankI did not add the reason into the log, though16:19
juliankso it's hard to follow the trail16:19
* juliank made the algorithm iterative rather than recursive and did not keep a stack16:20
juliankso, one of these depends on dmsetup which depends on lvm2: https://paste.ubuntu.com/p/ydGwDMckhm/16:21
juliank(or recommends it)16:21
juliankthat is libdevmapper1.02.116:23
juliankSo ubuntu-minimal -> eject -> libdevmapper1.02.1 -> dmsetup -> lvm2 (where -> is Depends or Recommends)16:24
juliankso lvm2 should not be possible to autoremove16:25
juliankhmm, seems I have a bug in my procedure16:31
juliankah, ubiquity -> dmeventd -> lvm216:33
juliankthat's why it's marked as auto16:33
juliankbut not sure how we got to ubiquity as auto16:34
juliankGotta extend the log with some tracing info I guess16:36
juliankin 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 installed16:37
juliankseb128: see, I don't like this whole thing, it does not even handle trusted.gpg.d properly IIRC16:47
seb128juliank, right, it could use a maintainer and fixes, but working and suboptimal is still better than not working :)17:02
brainwashjuliank: thanks for looking into this17:05
juliankI think we should have a simple PPA management tool instead for some PPA things17:05
juliankThey now follow better conventions so you can easily add/remove ppas17:05
juliankbrainwash: will do some more digging tomorrow17:05
seb128juliank, 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:07
rbasakjuliank: 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.17:09
juliankseb128: I'll think about it tomorrow18:17
juliankrbasak: Its part of software- properties-common18:18
seb128juliank, thx18:34
rbasakjuliank: yes, though I imagine some refactoring would be needed18:58
ahasenackdo 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
ahasenacksysv services usually define a RUN variable in /etc/default/<service>, that defaults to "no"19:34
ahasenackbut with systemd, how to accomplish the same thing?19:35
ahasenackthe job sources /etc/default/<service>, but how to treat this RUN variable?19:35
ahasenackcase in point: https://git.launchpad.net/ubuntu/+source/freeipmi/tree/debian/freeipmi-ipmidetect.ipmidetectd.init#n7019:36
ahasenackhow 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:36
juliankstgraber: FYI: I forwarded your autopkgtest changes for lxd upstream 4 hours ago, they got merged 2.5 hours ago. Woohoo19:52
juliankNow we can sync that beast once the next version is out19:53
juliankThis will also fix qemu backend which is broken in disco right now due to python 3.7 incompatibilities19:53
stgraberI thought I sent it to Martin back then but maybe I forgot19:53
juliankor maybe he was too busy with other stuff, who knows19:54
juliankin any case, it's merged now19:54

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