| === tomreyn_ is now known as tomreyn | ||
| RAOF | Hey, tjaalton: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1845317 is already fixed in eoan, right? | 07:13 |
|---|---|---|
| ubottu | Launchpad bug 1845317 in mesa (Ubuntu Bionic) "Add new pci-id's for CML-S, ICL" [Undecided,New] | 07:13 |
| tjaalton | RAOF: bah no.. forgot to add it to the new version.. will fix in -1u2 | 07:15 |
| tjaalton | hmm actually | 07:16 |
| tjaalton | the new pci-id's are there | 07:16 |
| tjaalton | just the marketing name changes are missing, which isn't critical for this bug | 07:17 |
| tjaalton | RAOF: nope, some cfl id's are missing, I'll upload -1u2 | 07:23 |
| RAOF | Ta | 07:23 |
| tjaalton | RAOF: will you still accept it? projects are waiting for the update | 07:33 |
| RAOF | tjaalton: Sure, if the fix is heading to eoan shortfly. | 07:34 |
| tjaalton | great, thanks | 07:34 |
| tjaalton | uploaded | 07:39 |
| === fenris is now known as Guest74057 | ||
| ddstreet | 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 |
| ddstreet | is there something i'm missing? | 11:10 |
| rbalint | 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:37 |
| ddstreet | rbalint but why did you add it back? it's not needed, in fact it makes things worse | 11:38 |
| rbalint | ddstreet, to keep it consistent i readded it, but we can drop the whole ret=... part and use only fails | 11:38 |
| ddstreet | well it skips calling fail() which gathers info | 11:39 |
| ddstreet | which can be useful debugging failures | 11:39 |
| ddstreet | i'm just not seeing the benefit of adding it as an ubuntu-specific patch... | 11:39 |
| rbalint | ddstreet, i agree, let's convert all the ret=... parts to fail ... | 11:41 |
| ddstreet | 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:41 |
| rbalint | 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:46 |
| rbalint | 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 | 11:48 |
| ahasenack | good morning | 12:08 |
| rbalint | ddstreet, i'm dropping the ret=... parts with 243, it is a bit late for 242 if you don't mind | 12:26 |
| ddstreet | yep that's fine, not really a big deal either way | 12:26 |
| rbalint | ddstreet, i'm prepping next 242 upload in ppa:ci-train-ppa-service/3797 , if you have something urgent for eoan, please ping me | 12:29 |
| === ricab is now known as ricab|lunch | ||
| tjaalton | launchpad git down? | 14:26 |
| rbasak | It was (short notice scheduled outage) but was reported to be back now. | 14:26 |
| rbasak | Check #launchpad | 14:26 |
| tjaalton | ah | 14:27 |
| === ricab|lunch is now known as ricab | ||
| tjaalton | still getting 'fatal: Could not read from remote repository.' for some kernel repos | 14:27 |
| tjaalton | but I'll wait if it'll settle down | 14:27 |
| cjwatson | Might be a bit overloaded since it's trying to page stuff back in | 14:28 |
| cjwatson | My clones of LP itself are going super-slowly | 14:29 |
| cjwatson | Oh, and it's recipe-o-clock, one moment | 14:29 |
| tjaalton | worked this time | 14:30 |
| cjwatson | Cancelling some recipe builds which should help as well | 14:30 |
| ali1234 | what is the difference between binutils and binutils-multiarch? | 15:44 |
| ali1234 | i am trying to build a cross-toolchain that targets debian-style multiarch | 15:49 |
| ali1234 | i built gcc with --enable-multiarch but then when linking, this happens: https://paste.ubuntu.com/p/bBcJJDhphC/ | 15:52 |
| ali1234 | 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:52 |
| ali1234 | so my question is what do i need to do to binutils to make this work? | 15:57 |
| ali1234 | i assume it is something done at build time due to the existence of the two binutils packages | 15:57 |
| ali1234 | i see in debianrules it is configured with "--libdir=/$(PF)/lib/$(DEB_HOST_MULTIARCH)" - i should probably do something like that? | 16:00 |
| ali1234 | or maybe 129_multiarch_libpath.patch is the key? | 16:13 |
| === 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 | ||
| tjaalton | ahasenack: sssd 2.2.2 in debian, btw | 17:42 |
| ahasenack | yeah, but FF :( | 17:43 |
| rafaeldtinoco | ali1234: https://wiki.debian.org/Multiarch/HOWTO | 17:44 |
| rafaeldtinoco | might help you | 17:44 |
| rafaeldtinoco | and https://wiki.debian.org/CrossToolchains | 17:45 |
| ali1234 | already read it.it doesn't explain what debian did to binutils | 17:56 |
| rafaeldtinoco | 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 |
| ali1234 | nope | 18:38 |
| rafaeldtinoco | 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 |
| ali1234 | the problem is my linker doesnt have 129_multiarch_libpath.patch which makes it search the multiarch directories | 18:39 |
| rafaeldtinoco | since this is link time, I think LIBRARY_PATH only is the env variable you would need | 18:39 |
| rafaeldtinoco | but I prefer doing that inside lxc containers using qemu-user-static | 18:39 |
| ali1234 | what i dont understand is why gcc has multiarch support upstream but binutils needs a patch | 18:39 |
| rafaeldtinoco | ali1234: great. | 18:39 |
| ali1234 | and also i don't know how to apply the required patch because i am building the toolchain with abe | 18:40 |
| ali1234 | and also i don't know if there are other patches required in other tools | 18:40 |
| rafaeldtinoco | ali1234: you can open a bug to the package in question | 18:40 |
| rafaeldtinoco | and suggest the patch | 18:40 |
| rafaeldtinoco | and explain how to reproduce in a simple example | 18:40 |
| ali1234 | what, binutils upstream? | 18:40 |
| rafaeldtinoco | so someone else can merge it | 18:40 |
| ali1234 | i kind of assumed that it had already been proposed, i mean that patch has been around for as long as multiarch | 18:41 |
| ali1234 | so like 10+ years | 18:41 |
| ali1234 | i kind of figured there's a reason it hasn't been merged upstream | 18:41 |
| ali1234 | also you can't reproduce it in a simple example - it requires that you have a multiarch compiler and multiarch libs installed | 18:42 |
| rafaeldtinoco | ali1234: https://wiki.dlang.org/GDC/Cross_Compiler/Existing_Sysroot | 18:42 |
| ali1234 | yes, that | 18:42 |
| rafaeldtinoco | gives as example doko's url on that patch | 18:43 |
| rafaeldtinoco | http://bazaar.launchpad.net/~doko/binutils/pkg-2.24-debian/view/head:/patches/129_multiarch_libpath.patch | 18:43 |
| ali1234 | yes | 18:43 |
| ali1234 | so then that seems to indicate that it is only that one patch required | 18:43 |
| ali1234 | 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 |
| ali1234 | binutils supports multiarch but gcc doesn't | 18:44 |
| rafaeldtinoco | yep, when debugging readelf has to be the binary for the arch being debugged | 18:45 |
| ali1234 | i get the feeling that there are no more than 5 people in the whole world who actually understand the problem :( | 18:45 |
| rafaeldtinoco | as multiarch is not compiled | 18:45 |
| rafaeldtinoco | just 1 example ^ | 18:46 |
| ali1234 | i don't know what that means | 18:46 |
| ali1234 | 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:46 |
| ali1234 | if you don't turn it on, then gcc won't be able to find your libs | 18:47 |
| ali1234 | if you don't patch binutils then it wont be able to find your libs | 18:47 |
| ali1234 | so you need both, or neither | 18:47 |
| ali1234 | 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 |
| rafaeldtinoco | ali1234: arent u mixing up multiarch term with cross compiling ? | 18:48 |
| ali1234 | you can have this problem with a native compiler | 18:48 |
| ali1234 | no, i'm not | 18:48 |
| ali1234 | they are two different things | 18:49 |
| rafaeldtinoco | i know they are =) | 18:49 |
| ali1234 | you can have a native multiarch compiler | 18:49 |
| ali1234 | 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 |
| rafaeldtinoco | right | 18:49 |
| ali1234 | 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 |
| ali1234 | which seems insane given how closely related they are. you would think they'd both have it | 18:50 |
| rafaeldtinoco | I see what you mean now | 18:50 |
| ali1234 | if you have a system where one of them supports it and the other doesn't, you will have a bad time | 18:51 |
| rafaeldtinoco | ali1234: when you say binutils, you mean only ld ? | 18:52 |
| rafaeldtinoco | or all binaries ? | 18:52 |
| ali1234 | well the atch applies to the binutils source | 18:52 |
| ali1234 | it only seems to touch ld and gold | 18:52 |
| ali1234 | but binutils is binutils | 18:52 |
| rafaeldtinoco | this page covers lots of stuff about this: | 18:53 |
| rafaeldtinoco | https://wiki.debian.org/Multiarch/LibraryPathOverview | 18:53 |
| rafaeldtinoco | 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 |
| rafaeldtinoco | According to the primary multiarch assumption, the system library search paths are modified to include the multiarch target string: | 18:54 |
| ali1234 | sure. i'm not compiling glibc though | 18:54 |
| rafaeldtinoco | its the same case though | 18:54 |
| ali1234 | yes | 18:54 |
| rafaeldtinoco | its basically saying you will have a problem with the linker | 18:54 |
| rafaeldtinoco | depending on LIBRARY_PATH | 18:55 |
| ali1234 | ld.so, yes, but i'm not compiling that either | 18:55 |
| ali1234 | i'm trying to make a toolchain that targets an existing debian sysroot | 18:55 |
| rafaeldtinoco | i see, for it to coexist | 18:55 |
| ali1234 | so it already has all the runtime stuff | 18:55 |
| rafaeldtinoco | so you can generate armhf packages lets say | 18:56 |
| ali1234 | right, and link against packaged libraries that already exist | 18:56 |
| rafaeldtinoco | using the second toolchain (cross compiling) | 18:56 |
| rafaeldtinoco | etc | 18:56 |
| ali1234 | exactly | 18:56 |
| rafaeldtinoco | yep , i used to work @ linaro | 18:56 |
| rafaeldtinoco | i used armhf containers for that | 18:56 |
| rafaeldtinoco | or arm64 | 18:56 |
| rafaeldtinoco | etc | 18:56 |
| ali1234 | containers are so slow though | 18:56 |
| rafaeldtinoco | its a good idea | 18:56 |
| ali1234 | this is for raspbian | 18:56 |
| rafaeldtinoco | yep, depending on qemu-user-static isnt good | 18:56 |
| ali1234 | linaro bootstrapped their original cross compiler | 18:56 |
| rafaeldtinoco | because its not multi threaded also | 18:56 |
| ali1234 | but it's now horribly out of date, and nobody at rpi-foundation knows how to make a new one | 18:57 |
| rafaeldtinoco | gotcha | 18:57 |
| rafaeldtinoco | ali1234: and why gcc6 ? | 18:57 |
| ali1234 | not gcc6 | 18:57 |
| rafaeldtinoco | not 6 from your output ? | 18:57 |
| ali1234 | ive been working on this for literally years | 18:57 |
| ali1234 | gcc6 was the default for raspbian stretch | 18:58 |
| rafaeldtinoco | gcc version 6.4.1 20180425 [linaro-6.4-2018.05 revision 7b15d0869c096fe39603ad63dc19ab7cf035eb70] (Linaro GCC 6.4-2018.05) | 18:58 |
| rafaeldtinoco | gotcha | 18:58 |
| ali1234 | but i want to be able to target current raspbian, which is 8.3 | 18:58 |
| ali1234 | and then whatever the next one is... and so on | 18:58 |
| rafaeldtinoco | so your will at the end is to cross compile | 18:58 |
| rafaeldtinoco | all raspbian | 18:58 |
| ali1234 | yes | 18:58 |
| rafaeldtinoco | in a fast way | 18:58 |
| ali1234 | no | 18:59 |
| rafaeldtinoco | so you dont depend on actual hw ? | 18:59 |
| ali1234 | i dont want to cross compile anything that already exists in raspbian | 18:59 |
| rafaeldtinoco | or to have multiple toolchains | 18:59 |
| ali1234 | i want to cross compile things that don't exist in raspbian, using the raspbian libraries that do exist | 18:59 |
| rafaeldtinoco | hum. i see | 18:59 |
| ali1234 | compiling raspbian itself ain't my problem. afaik they have some arm servers to do it | 19:00 |
| rafaeldtinoco | yep | 19:00 |
| rafaeldtinoco | i was about to point you https://www.socionext.com/en/products/assp/SynQuacer/Edge/ | 19:00 |
| rafaeldtinoco | but as you said, its likely something to allow others as well | 19:00 |
| rafaeldtinoco | to contribute generating new packages | 19:00 |
| rafaeldtinoco | without having necessarily the arch | 19:01 |
| ali1234 | yeah i bet that is still slower than cross compiling | 19:01 |
| rafaeldtinoco | its not =) | 19:01 |
| rafaeldtinoco | 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 |
| rafaeldtinoco | $ nproc | 19:01 |
| rafaeldtinoco | 24 | 19:01 |
| rafaeldtinoco | its not super fast | 19:01 |
| rafaeldtinoco | but its ok | 19:01 |
| ali1234 | how much does it cost? | 19:01 |
| rafaeldtinoco | ~ $1k | 19:02 |
| rafaeldtinoco | 1.2k i suppose | 19:02 |
| ali1234 | hmm that's actually kind of reasonable for 24 core | 19:02 |
| rafaeldtinoco | ARMv8 rev 1 | 19:02 |
| rafaeldtinoco | you can run armhf kvm guests | 19:02 |
| rafaeldtinoco | or lxd guests | 19:02 |
| rafaeldtinoco | like I do | 19:02 |
| rafaeldtinoco | I do ubuntu armhf/arm64 debugs on that machine | 19:02 |
| rafaeldtinoco | actually | 19:02 |
| ali1234 | still, the lack of cross compiler annoys me, and i'm not the only one | 19:02 |
| rafaeldtinoco | yep yep | 19:02 |
| rafaeldtinoco | orthogonal things | 19:03 |
| rafaeldtinoco | just for you to have in mind ^ | 19:03 |
| ali1234 | so the problem i have now is that i built the compiler i have now with linaro abe | 19:03 |
| ogra | 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 |
| ali1234 | lol, launchpad is really slow | 19:04 |
| ogra | i have seen and done slower arm builds :) | 19:04 |
| ali1234 | 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:04 |
| * ogra did the original ubuntu arm port bootstrapping on an nslu2 ;) | 19:05 | |
| rafaeldtinoco | ogra: #) =) | 19:05 |
| ali1234 | how many times did you have to run "make" before it worked? | 19:05 |
| * rafaeldtinoco gets back to eoan installer problem | 19:06 | |
| rafaeldtinoco | as BETA is broken | 19:06 |
| ogra | endless times :) | 19:06 |
| rafaeldtinoco | ali1234: let me know your findings | 19:06 |
| ogra | not many people know though that we actually supported ARMv5 for one release | 19:06 |
| ogra | (jaunty IIRC) | 19:06 |
| ali1234 | okay a question: the binutils-source package: is the tarball inside it pre-patched? | 19:22 |
| ali1234 | same question for gcc-8-source | 19:22 |
| sarnold | 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:23 |
| ali1234 | i'm not talking about the source package | 19:25 |
| sarnold | ahhhhhh | 19:25 |
| ali1234 | binutils-source is a "binary" package that installs /usr/src/binutils/binutils-2.31.1.tar.xz | 19:25 |
| ali1234 | (or whatever version) | 19:26 |
| ali1234 | thing is... it also installs a "patches" subdir so i am wondering if i need to apply those manually? | 19:30 |
| rafaeldtinoco | ali1234: you should read a bit about debian packaging | 19:31 |
| ali1234 | this isn't a source package >.< | 19:31 |
| rafaeldtinoco | ah | 19:31 |
| rafaeldtinoco | lol | 19:31 |
| rafaeldtinoco | ok | 19:31 |
| rafaeldtinoco | :P | 19:31 |
| blackboxsw | 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 |
| blackboxsw | 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 |
| blackboxsw | *do-release-upgrade* rather | 19:51 |
| blackboxsw | 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:54 |
| ali1234 | what if /etc/os-release is updated but nothing else on the system is? | 19:55 |
| sarnold | 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:55 |
| sarnold | blackboxsw: those tend to add brittleness though so it'd probably be worth exploring alternatives further | 19:56 |
| blackboxsw | 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:57 |
| blackboxsw | then our new package would know it's upgrading across a release | 19:58 |
| sarnold | 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 |
| blackboxsw | 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:58 |
| blackboxsw | thanks for the suggestions | 19:59 |
| ali1234 | well, why do you need to know the release at install time then? | 19:59 |
| ali1234 | or are you just trying to figure out that the release has changed? | 20:03 |
| Unit193 | If anyone cares about wayland and wxgtk, https://packages.qa.debian.org/w/wxwidgets3.0/news/20191002T204524Z.html fixes two-finger touchpad scrolling. | 20:56 |
| Unit193 | https://salsa.debian.org/freewx-team/wx/commit/9fe0c523faa50746099444ed7b50fccf7bbda136.patch is actually surprisingly small.. | 20:58 |
| chiluk | is anyone going to KubeCon ? I'd love to catch up with some of my old ubuntu peoples. | 21:23 |
| ahasenack | hm, I have a postinst calling gpg, and am wondering if I should add gpg (or gnupg) to d/control's Depends | 21:34 |
| ahasenack | the package is flagged as optional in bionic | 21:34 |
| ahasenack | and important on trusty | 21:34 |
| ahasenack | haven't seen a system without /usr/bin/gpg, but looks like it's possible | 21:38 |
| infinity | ahasenack: apt-cache show gnupg | grep ^Essential | 22:08 |
| infinity | ahasenack: If that doesn't return anything (compare to, say, "apt-cache show coreutils | grep ^Essential"), then you need a dependency. | 22:08 |
| infinity | ahasenack: Relying on "I think most people have this installed" isn't the way to go. :) | 22:08 |
| ahasenack | yep, I'm adding it, I checked Priority before | 22:09 |
| ahasenack | and there is no "Essential" as you said | 22:09 |
| mwhudson | some gpgv* is guaranteed to be there | 23:17 |
| mwhudson | because apt | 23:17 |
| mwhudson | but not everything | 23:17 |
| Unit193 | Package: gpgv, Priority: important, Build-Essential: yes. So it's somewhat important, one might say. | 23:18 |
| Unit193 | (Note that you really should still depend on it, if you need it, though.) | 23:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!