=== tomreyn_ is now known as tomreyn [07:13] Hey, tjaalton: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1845317 is already fixed in eoan, right? [07:13] Launchpad bug 1845317 in mesa (Ubuntu Bionic) "Add new pci-id's for CML-S, ICL" [Undecided,New] [07:15] RAOF: bah no.. forgot to add it to the new version.. will fix in -1u2 [07:16] hmm actually [07:16] the new pci-id's are there [07:17] just the marketing name changes are missing, which isn't critical for this bug [07:23] RAOF: nope, some cfl id's are missing, I'll upload -1u2 [07:23] Ta [07:33] RAOF: will you still accept it? projects are waiting for the update [07:34] tjaalton: Sure, if the fix is heading to eoan shortfly. [07:34] great, thanks [07:39] uploaded === fenris is now known as Guest74057 [11:10] rbalint hi, i'm wondering why you added this https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?h=ubuntu-eoan&id=053719c8971705307aa8cb5cbcd679defa89f70a [11:10] is there something i'm missing? [11:37] ddstreet, it was added in https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?h=ubuntu-eoan&id=b09b6ed4682 and when i merged 241 i accidentally merged it away making the script using ret=1-s and fail-s [11:38] rbalint but why did you add it back? it's not needed, in fact it makes things worse [11:38] ddstreet, to keep it consistent i readded it, but we can drop the whole ret=... part and use only fails [11:39] well it skips calling fail() which gathers info [11:39] which can be useful debugging failures [11:39] i'm just not seeing the benefit of adding it as an ubuntu-specific patch... [11:41] ddstreet, i agree, let's convert all the ret=... parts to fail ... [11:41] rbalint honestly i'd prefer if the entire boot-smoke test was pulled from debian, there are various other issues in the one we carry [11:46] ddstreet, looking at the (salsa)/master..ubuntu-eoan delta we have extra checks, but if all of those are found to be obsolete then sure, carrying less delta is better [11:48] ddstreet, i see open PR-s on https://salsa.debian.org/systemd-team/systemd/merge_requests and mine does not progress, so i did not look into trying to push delta pieces to Debian more actively [12:08] good morning [12:26] ddstreet, i'm dropping the ret=... parts with 243, it is a bit late for 242 if you don't mind [12:26] yep that's fine, not really a big deal either way [12:29] ddstreet, i'm prepping next 242 upload in ppa:ci-train-ppa-service/3797 , if you have something urgent for eoan, please ping me === ricab is now known as ricab|lunch [14:26] launchpad git down? [14:26] It was (short notice scheduled outage) but was reported to be back now. [14:26] Check #launchpad [14:27] ah === ricab|lunch is now known as ricab [14:27] still getting 'fatal: Could not read from remote repository.' for some kernel repos [14:27] but I'll wait if it'll settle down [14:28] Might be a bit overloaded since it's trying to page stuff back in [14:29] My clones of LP itself are going super-slowly [14:29] Oh, and it's recipe-o-clock, one moment [14:30] worked this time [14:30] Cancelling some recipe builds which should help as well [15:44] what is the difference between binutils and binutils-multiarch? [15:49] i am trying to build a cross-toolchain that targets debian-style multiarch [15:52] i built gcc with --enable-multiarch but then when linking, this happens: https://paste.ubuntu.com/p/bBcJJDhphC/ [15:52] strace output at the bottom shows tha binutils is not searching the multiarch paths, ie it searches $SYSROOT/lib but not $SYSROOT/lib/arm-linux-gnueabihf [15:57] so my question is what do i need to do to binutils to make this work? [15:57] i assume it is something done at build time due to the existence of the two binutils packages [16:00] i see in debianrules it is configured with "--libdir=/$(PF)/lib/$(DEB_HOST_MULTIARCH)" - i should probably do something like that? [16:13] or maybe 129_multiarch_libpath.patch is the key? === ricab_ is now known as ricab === led_dark_2 is now known as led_dark_1 === led_dark_2 is now known as led_dark_1 [17:42] ahasenack: sssd 2.2.2 in debian, btw [17:43] yeah, but FF :( [17:44] ali1234: https://wiki.debian.org/Multiarch/HOWTO [17:44] might help you [17:45] and https://wiki.debian.org/CrossToolchains [17:56] already read it.it doesn't explain what debian did to binutils [18:38] ali1234: well, without too much of reading (output) id say your linker (for another arch) can't find the libs (made for that arch) [18:38] nope [18:39] if it was run time the variable LD_LIBRARY_PATH would be the one checked by the linker (statically set in the ELF) and check for the shared libraries etc [18:39] the problem is my linker doesnt have 129_multiarch_libpath.patch which makes it search the multiarch directories [18:39] since this is link time, I think LIBRARY_PATH only is the env variable you would need [18:39] but I prefer doing that inside lxc containers using qemu-user-static [18:39] what i dont understand is why gcc has multiarch support upstream but binutils needs a patch [18:39] ali1234: great. [18:40] and also i don't know how to apply the required patch because i am building the toolchain with abe [18:40] and also i don't know if there are other patches required in other tools [18:40] ali1234: you can open a bug to the package in question [18:40] and suggest the patch [18:40] and explain how to reproduce in a simple example [18:40] what, binutils upstream? [18:40] so someone else can merge it [18:41] i kind of assumed that it had already been proposed, i mean that patch has been around for as long as multiarch [18:41] so like 10+ years [18:41] i kind of figured there's a reason it hasn't been merged upstream [18:42] also you can't reproduce it in a simple example - it requires that you have a multiarch compiler and multiarch libs installed [18:42] ali1234: https://wiki.dlang.org/GDC/Cross_Compiler/Existing_Sysroot [18:42] yes, that [18:43] gives as example doko's url on that patch [18:43] http://bazaar.launchpad.net/~doko/binutils/pkg-2.24-debian/view/head:/patches/129_multiarch_libpath.patch [18:43] yes [18:43] so then that seems to indicate that it is only that one patch required [18:44] there is a mistake in those instructions though - they don't build gcc with --enable-multiarch so they will have the exact opposite problem that i have [18:44] binutils supports multiarch but gcc doesn't [18:45] yep, when debugging readelf has to be the binary for the arch being debugged [18:45] i get the feeling that there are no more than 5 people in the whole world who actually understand the problem :( [18:45] as multiarch is not compiled [18:46] just 1 example ^ [18:46] i don't know what that means [18:46] gcc has a configure switch "--enable-multiarch" which appends the extra directories to the search path. identical to what the patch does for binutils. except it is in the upstream source [18:47] if you don't turn it on, then gcc won't be able to find your libs [18:47] if you don't patch binutils then it wont be able to find your libs [18:47] so you need both, or neither [18:48] it doesn't even really have anything to do with architectures, it is just that the libraries are in a different directory to normal [18:48] ali1234: arent u mixing up multiarch term with cross compiling ? [18:48] you can have this problem with a native compiler [18:48] no, i'm not [18:49] they are two different things [18:49] i know they are =) [18:49] you can have a native multiarch compiler [18:49] multiarch just means that libs are in /lib/$arch-triplet instead of /libs and this means all search paaths have to be adjusted, or your compiler will not be able to find anything [18:49] right [18:50] so my pain point is that the support for this exists upstream in gcc and enabling it is a compile time switch, but for binutils you have to apply a patch [18:50] which seems insane given how closely related they are. you would think they'd both have it [18:50] I see what you mean now [18:51] if you have a system where one of them supports it and the other doesn't, you will have a bad time [18:52] ali1234: when you say binutils, you mean only ld ? [18:52] or all binaries ? [18:52] well the atch applies to the binutils source [18:52] it only seems to touch ld and gold [18:52] but binutils is binutils [18:53] this page covers lots of stuff about this: [18:53] https://wiki.debian.org/Multiarch/LibraryPathOverview [18:54] This requires modifications to glibc's ld.so loader (can possibly be provided via platform back-end changes). Backwards compatibility most likely requires that both the new multiarch location and the old location are searched. [18:54] According to the primary multiarch assumption, the system library search paths are modified to include the multiarch target string: [18:54] sure. i'm not compiling glibc though [18:54] its the same case though [18:54] yes [18:54] its basically saying you will have a problem with the linker [18:55] depending on LIBRARY_PATH [18:55] ld.so, yes, but i'm not compiling that either [18:55] i'm trying to make a toolchain that targets an existing debian sysroot [18:55] i see, for it to coexist [18:55] so it already has all the runtime stuff [18:56] so you can generate armhf packages lets say [18:56] right, and link against packaged libraries that already exist [18:56] using the second toolchain (cross compiling) [18:56] etc [18:56] exactly [18:56] yep , i used to work @ linaro [18:56] i used armhf containers for that [18:56] or arm64 [18:56] etc [18:56] containers are so slow though [18:56] its a good idea [18:56] this is for raspbian [18:56] yep, depending on qemu-user-static isnt good [18:56] linaro bootstrapped their original cross compiler [18:56] because its not multi threaded also [18:57] but it's now horribly out of date, and nobody at rpi-foundation knows how to make a new one [18:57] gotcha [18:57] ali1234: and why gcc6 ? [18:57] not gcc6 [18:57] not 6 from your output ? [18:57] ive been working on this for literally years [18:58] gcc6 was the default for raspbian stretch [18:58] gcc version 6.4.1 20180425 [linaro-6.4-2018.05 revision 7b15d0869c096fe39603ad63dc19ab7cf035eb70] (Linaro GCC 6.4-2018.05) [18:58] gotcha [18:58] but i want to be able to target current raspbian, which is 8.3 [18:58] and then whatever the next one is... and so on [18:58] so your will at the end is to cross compile [18:58] all raspbian [18:58] yes [18:58] in a fast way [18:59] no [18:59] so you dont depend on actual hw ? [18:59] i dont want to cross compile anything that already exists in raspbian [18:59] or to have multiple toolchains [18:59] i want to cross compile things that don't exist in raspbian, using the raspbian libraries that do exist [18:59] hum. i see [19:00] compiling raspbian itself ain't my problem. afaik they have some arm servers to do it [19:00] yep [19:00] i was about to point you https://www.socionext.com/en/products/assp/SynQuacer/Edge/ [19:00] but as you said, its likely something to allow others as well [19:00] to contribute generating new packages [19:01] without having necessarily the arch [19:01] yeah i bet that is still slower than cross compiling [19:01] its not =) [19:01] Linux firewall 5.0.0-30-generic #32-Ubuntu SMP Wed Sep 18 00:24:43 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux [19:01] $ nproc [19:01] 24 [19:01] its not super fast [19:01] but its ok [19:01] how much does it cost? [19:02] ~ $1k [19:02] 1.2k i suppose [19:02] hmm that's actually kind of reasonable for 24 core [19:02] ARMv8 rev 1 [19:02] you can run armhf kvm guests [19:02] or lxd guests [19:02] like I do [19:02] I do ubuntu armhf/arm64 debugs on that machine [19:02] actually [19:02] still, the lack of cross compiler annoys me, and i'm not the only one [19:02] yep yep [19:03] orthogonal things [19:03] just for you to have in mind ^ [19:03] so the problem i have now is that i built the compiler i have now with linaro abe [19:04] just get a Pi4 4GB, a fast USB3 SSD and be done ... my builds on that HW run as fast/slow as on launchpad [19:04] lol, launchpad is really slow [19:04] i have seen and done slower arm builds :) [19:04] anyway, abe lets you set gcc configure options (and binutils configure options) so i was able to enable multiarch for gcc, cos it is upstream. but it has no way to apply a patch to binutils [19:05] * ogra did the original ubuntu arm port bootstrapping on an nslu2 ;) [19:05] ogra: #) =) [19:05] how many times did you have to run "make" before it worked? [19:06] * rafaeldtinoco gets back to eoan installer problem [19:06] as BETA is broken [19:06] endless times :) [19:06] ali1234: let me know your findings [19:06] not many people know though that we actually supported ARMv5 for one release [19:06] (jaunty IIRC) [19:22] okay a question: the binutils-source package: is the tarball inside it pre-patched? [19:22] same question for gcc-8-source [19:23] ali1234: if the tarball name includes 'dfsg' in it, that's a clear sign that it has been; otherwise it's harder to tell [19:25] i'm not talking about the source package [19:25] ahhhhhh [19:25] binutils-source is a "binary" package that installs /usr/src/binutils/binutils-2.31.1.tar.xz [19:26] (or whatever version) [19:30] thing is... it also installs a "patches" subdir so i am wondering if i need to apply those manually? [19:31] ali1234: you should read a bit about debian packaging [19:31] this isn't a source package >.< [19:31] ah [19:31] lol [19:31] ok [19:31] :P [19:51] Hey folks, I've got a package postinst script that takes certain cleanup actions based on determining the Ubuntu series based on contents of /etc/os-release. If a system is performing a do_release_upgrade, can we rely on etc/os-release to contain the target series when a new series package is upgraded? [19:51] I am presuming that /etc/os-release would be updated to the target "upgraded" ubuntu release name/content prior to upgrading to the packages for that release because packaging may have release-specific configuration behavior. So, for our postinst scripts, we're going to assume the upgraded xenial content is present in /etc/os-release prior to upgrading to any of the other xenial deb packages. [19:51] *do-release-upgrade* rather [19:54] Is that the correct assumption that /etc/os-release will be present during a do-release-upgrade before upgrading 3rd party debs? Or is there a potential race we need to worry about. [19:55] what if /etc/os-release is updated but nothing else on the system is? [19:55] blackboxsw: I believe if you need to go this route, you'll need to declare Pre-Depends: checks https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends [19:56] blackboxsw: those tend to add brittleness though so it'd probably be worth exploring alternatives further [19:57] sarnold: in our case, and alternative would be for our postinst to look at the previous package version $2 when running "configure" an 'know' that it came from a different series during an upgrade path. So, we could explore that as an option [19:58] then our new package would know it's upgrading across a release [19:58] blackboxsw: at least there's loads of those in the archive to crib off of :) it's a bit more effort to keep track of the allowed upgrade paths, but feels more likely to be reliable to me [19:58] ali1234: in our case, we have only package-specific config changes that are made based on values in /etc/os-release. So, no external dependencies beyond that [19:59] thanks for the suggestions [19:59] well, why do you need to know the release at install time then? [20:03] or are you just trying to figure out that the release has changed? [20:56] If anyone cares about wayland and wxgtk, https://packages.qa.debian.org/w/wxwidgets3.0/news/20191002T204524Z.html fixes two-finger touchpad scrolling. [20:58] https://salsa.debian.org/freewx-team/wx/commit/9fe0c523faa50746099444ed7b50fccf7bbda136.patch is actually surprisingly small.. [21:23] is anyone going to KubeCon ? I'd love to catch up with some of my old ubuntu peoples. [21:34] hm, I have a postinst calling gpg, and am wondering if I should add gpg (or gnupg) to d/control's Depends [21:34] the package is flagged as optional in bionic [21:34] and important on trusty [21:38] haven't seen a system without /usr/bin/gpg, but looks like it's possible [22:08] ahasenack: apt-cache show gnupg | grep ^Essential [22:08] ahasenack: If that doesn't return anything (compare to, say, "apt-cache show coreutils | grep ^Essential"), then you need a dependency. [22:08] ahasenack: Relying on "I think most people have this installed" isn't the way to go. :) [22:09] yep, I'm adding it, I checked Priority before [22:09] and there is no "Essential" as you said [23:17] some gpgv* is guaranteed to be there [23:17] because apt [23:17] but not everything [23:18] Package: gpgv, Priority: important, Build-Essential: yes. So it's somewhat important, one might say. [23:19] (Note that you really should still depend on it, if you need it, though.)