| 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:31 |
| cpaelzer | the x86 bits are ok as they build in build-indep | 06:32 |
| cpaelzer | but the s390x bits are missing there obviously | 06:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| cpaelzer | rbasak: ^^ this is the build-indep *fun* that I mentioned briefly | 06:40 |
| cpaelzer | maybe a deeper understanding of foreign as an alternative would help, reading more docs ... | 06:48 |
| 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:00 |
| 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:01 |
| cpaelzer | thanks infinity, that confirms what I was afraid of | 08:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| cpaelzer | yeah that would be a great cross-check thanks for the hint | 08:11 |
| infinity | cpaelzer: Note that you'll need gcc-multilib (which also has a cross-equivalent meta) if it builds any -m31 crap. | 08:15 |
| 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:06 |
| 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:07 |
| 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:19 |
| cjwatson | Assuming that it can be expected to have a reasonably constant value in an Ubuntu environment, anyway | 10:20 |
| cpaelzer | it's missing various libraries - essentially ...-dev as I only have e.g. libglib2.0-dev:amd64 | 10:36 |
| cpaelzer | but not the same :s390x | 10:37 |
| cpaelzer | that is where I wonder if I need an multiarch env here | 10:37 |
| cpaelzer | no configure.ac or similar here | 10:38 |
| cpaelzer | so I doubt it autotools vars are a reason here | 10:38 |
| cpaelzer | I'd mostly want a) probably all my build-deps also as :s390x or b) better understand what I want :-) | 10:43 |
| 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:46 |
| cjwatson | Find another answer :) | 10:47 |
| cpaelzer | cjwatson: another answer than "installing the dependencies I need" :-) | 10:47 |
| cpaelzer | that sounds like it will make it even more complex :-/ | 10:48 |
| 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:50 |
| 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:52 |
| 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 | 10:53 |
| 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 | 12:02 |
| === ricab is now known as ricab|lunch | ||
| 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 |
| ubottu | bug 1717014 in bind9 (Ubuntu) "host stops searching domains when it gets back NSEC record" [Undecided,New] https://launchpad.net/bugs/1717014 | 13:46 |
| rbasak | I'm not current with the DNS stack involving resolved nowadays :-/ | 13:46 |
| brainwash | can one of the ubuntu devs take a look at bug 1801629 please? | 14:35 |
| ubottu | 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:35 |
| 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:39 |
| brainwash | bug appeared in 18.10 | 14:40 |
| === ricab|lunch is now known as ricab | ||
| 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:14 |
| brainwash | rbasak: I guess it does not, otherwise there would be more buzz around this bug | 15:20 |
| brainwash | and kubuntu is the only flavour that explicitly depends on cryptsetup and lvm2 | 15:22 |
| rbasak | brainwash: perhaps we need to bring it to the attention of the flavor leads then? | 15:43 |
| brainwash | rbasak: xubuntu and ubuntu mate are tagged via the bug report already, and the xubuntu lead is subscribed to the report | 15:47 |
| 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 | 15:48 |
| 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:06 |
| 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 |
| ubottu | 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 |
| juliank | It might be related to the work I did - it traversed the dpeendencies of all metapackages and marked them as automatically installed | 16:07 |
| 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:08 |
| juliank | We just need to get the build log for xubuntu 18.10, amd64 image | 16:09 |
| 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:10 |
| cjwatson | Start from https://people.canonical.com/~ubuntu-archive/cd-build-logs/ | 16:11 |
| juliank | cjwatson: the livecd-rootfs logs, actually | 16:12 |
| juliank | I think those are debian-cd logs? | 16:12 |
| 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:13 |
| cjwatson | and you'll find a livefs build log there | 16:14 |
| juliank | Ah I see, thanks | 16:14 |
| === cpaelzer_ is now known as cpaelzer | ||
| 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:15 |
| * cjwatson fixes cd-build-logs to be served as text/plain | 16:16 | |
| 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:17 |
| juliank | I did not add the reason into the log, though | 16:19 |
| juliank | so it's hard to follow the trail | 16:19 |
| * juliank made the algorithm iterative rather than recursive and did not keep a stack | 16:20 | |
| 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:21 |
| juliank | that is libdevmapper1.02.1 | 16:23 |
| juliank | So ubuntu-minimal -> eject -> libdevmapper1.02.1 -> dmsetup -> lvm2 (where -> is Depends or Recommends) | 16:24 |
| juliank | so lvm2 should not be possible to autoremove | 16:25 |
| juliank | hmm, seems I have a bug in my procedure | 16:31 |
| juliank | ah, ubiquity -> dmeventd -> lvm2 | 16:33 |
| juliank | that's why it's marked as auto | 16:33 |
| juliank | but not sure how we got to ubiquity as auto | 16:34 |
| juliank | Gotta extend the log with some tracing info I guess | 16:36 |
| 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:37 |
| juliank | seb128: see, I don't like this whole thing, it does not even handle trusted.gpg.d properly IIRC | 16:47 |
| seb128 | juliank, right, it could use a maintainer and fixes, but working and suboptimal is still better than not working :) | 17:02 |
| 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:05 |
| 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:07 |
| 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. | 17:09 |
| juliank | seb128: I'll think about it tomorrow | 18:17 |
| juliank | rbasak: Its part of software- properties-common | 18:18 |
| seb128 | juliank, thx | 18:34 |
| rbasak | juliank: yes, though I imagine some refactoring would be needed | 18:58 |
| 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:34 |
| 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:35 |
| 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:36 |
| juliank | stgraber: FYI: I forwarded your autopkgtest changes for lxd upstream 4 hours ago, they got merged 2.5 hours ago. Woohoo | 19:52 |
| 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:53 |
| juliank | or maybe he was too busy with other stuff, who knows | 19:54 |
| juliank | in any case, it's merged now | 19:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!