[07:13] <RAOF> Hey, tjaalton: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1845317 is already fixed in eoan, right?
[07:15] <tjaalton> RAOF: bah no.. forgot to add it to the new version.. will fix in -1u2
[07:16] <tjaalton> hmm actually
[07:16] <tjaalton> the new pci-id's are there
[07:17] <tjaalton> just the marketing name changes are missing, which isn't critical for this bug
[07:23] <tjaalton> RAOF: nope, some cfl id's are missing, I'll upload -1u2
[07:23] <RAOF> Ta
[07:33] <tjaalton> RAOF: will you still accept it? projects are waiting for the update
[07:34] <RAOF> tjaalton: Sure, if the fix is heading to eoan shortfly.
[07:34] <tjaalton> great, thanks
[07:39] <tjaalton> uploaded
[11:10] <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:37] <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:38] <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:39] <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:41] <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:46] <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:48] <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
[12:08] <ahasenack> good morning
[12:26] <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:29] <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
[14:26] <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:27] <tjaalton> ah
[14:27] <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:28] <cjwatson> Might be a bit overloaded since it's trying to page stuff back in
[14:29] <cjwatson> My clones of LP itself are going super-slowly
[14:29] <cjwatson> Oh, and it's recipe-o-clock, one moment
[14:30] <tjaalton> worked this time
[14:30] <cjwatson> Cancelling some recipe builds which should help as well
[15:44] <ali1234> what is the difference between binutils and binutils-multiarch?
[15:49] <ali1234> i am trying to build a cross-toolchain that targets debian-style multiarch
[15:52] <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:57] <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
[16:00] <ali1234> i see in debianrules it is configured with "--libdir=/$(PF)/lib/$(DEB_HOST_MULTIARCH)" - i should probably do something like that?
[16:13] <ali1234> or maybe 129_multiarch_libpath.patch is the key?
[17:42] <tjaalton> ahasenack: sssd 2.2.2 in debian, btw
[17:43] <ahasenack> yeah, but FF :(
[17:44] <rafaeldtinoco> ali1234: https://wiki.debian.org/Multiarch/HOWTO
[17:44] <rafaeldtinoco> might help you
[17:45] <rafaeldtinoco> and https://wiki.debian.org/CrossToolchains
[17:56] <ali1234> already read it.it doesn't explain what debian did to binutils
[18:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:50] <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:51] <ali1234> if you have a system where one of them supports it and the other doesn't, you will have a bad time
[18:52] <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:53] <rafaeldtinoco> this page covers lots of stuff about this:
[18:53] <rafaeldtinoco> https://wiki.debian.org/Multiarch/LibraryPathOverview
[18:54] <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:55] <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:56] <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:57] <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:58] <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:59] <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
[19:00] <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:01] <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:02] <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:03] <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:04] <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:05]  * 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:06]  * 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:22] <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:23] <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:25] <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:26] <ali1234> (or whatever version)
[19:30] <ali1234> thing is... it also installs a "patches" subdir so i am wondering if i need to apply those manually?
[19:31] <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:51] <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:54] <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:55] <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:56] <sarnold> blackboxsw: those tend to add brittleness though so it'd probably be worth exploring alternatives further
[19:57] <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:58] <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:59] <blackboxsw> thanks for the suggestions
[19:59] <ali1234> well, why do you need to know the release at install time then?
[20:03] <ali1234> or are you just trying to figure out that the release has changed?
[20:56] <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:58] <Unit193> https://salsa.debian.org/freewx-team/wx/commit/9fe0c523faa50746099444ed7b50fccf7bbda136.patch is actually surprisingly small..
[21:23] <chiluk> is anyone going to KubeCon ? I'd love to catch up with some of my old ubuntu peoples.
[21:34] <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:38] <ahasenack> haven't seen a system without /usr/bin/gpg, but looks like it's possible
[22:08] <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:09] <ahasenack> yep, I'm adding it, I checked Priority before
[22:09] <ahasenack> and there is no "Essential" as you said
[23:17] <mwhudson> some gpgv* is guaranteed to be there
[23:17] <mwhudson> because apt
[23:17] <mwhudson> but not everything
[23:18] <Unit193> Package: gpgv, Priority: important, Build-Essential: yes.  So it's somewhat important, one might say.
[23:19] <Unit193> (Note that you really should still depend on it, if you need it, though.)