=== tomreyn_ is now known as tomreyn
RAOFHey, tjaalton: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1845317 is already fixed in eoan, right?07:13
ubottuLaunchpad bug 1845317 in mesa (Ubuntu Bionic) "Add new pci-id's for CML-S, ICL" [Undecided,New]07:13
tjaaltonRAOF: bah no.. forgot to add it to the new version.. will fix in -1u207:15
tjaaltonhmm actually07:16
tjaaltonthe new pci-id's are there07:16
tjaaltonjust the marketing name changes are missing, which isn't critical for this bug07:17
tjaaltonRAOF: nope, some cfl id's are missing, I'll upload -1u207:23
tjaaltonRAOF: will you still accept it? projects are waiting for the update07:33
RAOFtjaalton: Sure, if the fix is heading to eoan shortfly.07:34
tjaaltongreat, thanks07:34
=== fenris is now known as Guest74057
ddstreetrbalint hi, i'm wondering why you added this https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?h=ubuntu-eoan&id=053719c8971705307aa8cb5cbcd679defa89f70a11:10
ddstreetis there something i'm missing?11:10
rbalintddstreet, 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-s11:37
ddstreetrbalint but why did you add it back?  it's not needed, in fact it makes things worse11:38
rbalintddstreet, to keep it consistent i readded it, but we can drop the whole ret=... part and use only fails11:38
ddstreetwell it skips calling fail() which gathers info11:39
ddstreetwhich can be useful debugging failures11:39
ddstreeti'm just not seeing the benefit of adding it as an ubuntu-specific patch...11:39
rbalintddstreet, i agree, let's convert all the ret=... parts to fail ...11:41
ddstreetrbalint honestly i'd prefer if the entire boot-smoke test was pulled from debian, there are various other issues in the one we carry11:41
rbalintddstreet, 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 better11:46
rbalintddstreet, 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 actively11:48
ahasenackgood morning12:08
rbalintddstreet, i'm dropping the ret=... parts with 243, it is a bit late for 242 if you don't mind12:26
ddstreetyep that's fine, not really a big deal either way12:26
rbalintddstreet, i'm prepping next 242 upload in ppa:ci-train-ppa-service/3797 , if you have something urgent for eoan, please ping me12:29
=== ricab is now known as ricab|lunch
tjaaltonlaunchpad git down?14:26
rbasakIt was (short notice scheduled outage) but was reported to be back now.14:26
rbasakCheck #launchpad14:26
=== ricab|lunch is now known as ricab
tjaaltonstill getting 'fatal: Could not read from remote repository.' for some kernel repos14:27
tjaaltonbut I'll wait if it'll settle down14:27
cjwatsonMight be a bit overloaded since it's trying to page stuff back in14:28
cjwatsonMy clones of LP itself are going super-slowly14:29
cjwatsonOh, and it's recipe-o-clock, one moment14:29
tjaaltonworked this time14:30
cjwatsonCancelling some recipe builds which should help as well14:30
ali1234what is the difference between binutils and binutils-multiarch?15:44
ali1234i am trying to build a cross-toolchain that targets debian-style multiarch15:49
ali1234i built gcc with --enable-multiarch but then when linking, this happens: https://paste.ubuntu.com/p/bBcJJDhphC/15:52
ali1234strace output at the bottom shows tha binutils is not searching the multiarch paths, ie it searches $SYSROOT/lib but not $SYSROOT/lib/arm-linux-gnueabihf15:52
ali1234so my question is what do i need to do to binutils to make this work?15:57
ali1234i assume it is something done at build time due to the existence of the two binutils packages15:57
ali1234i see in debianrules it is configured with "--libdir=/$(PF)/lib/$(DEB_HOST_MULTIARCH)" - i should probably do something like that?16:00
ali1234or 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
tjaaltonahasenack: sssd 2.2.2 in debian, btw17:42
ahasenackyeah, but FF :(17:43
rafaeldtinocoali1234: https://wiki.debian.org/Multiarch/HOWTO17:44
rafaeldtinocomight help you17:44
rafaeldtinocoand https://wiki.debian.org/CrossToolchains17:45
ali1234already read it.it doesn't explain what debian did to binutils17:56
rafaeldtinocoali1234: 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
rafaeldtinocoif 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 etc18:39
ali1234the problem is my linker doesnt have 129_multiarch_libpath.patch which makes it search the multiarch directories18:39
rafaeldtinocosince this is link time, I think LIBRARY_PATH only is the env variable you would need18:39
rafaeldtinocobut I prefer doing that inside lxc containers using qemu-user-static18:39
ali1234what i dont understand is why gcc has multiarch support upstream but binutils needs a patch18:39
rafaeldtinocoali1234: great.18:39
ali1234and also i don't know how to apply the required patch because i am building the toolchain with abe18:40
ali1234and also i don't know if there are other patches required in other tools18:40
rafaeldtinocoali1234: you can open a bug to the package in question18:40
rafaeldtinocoand suggest the patch18:40
rafaeldtinocoand explain how to reproduce in a simple example18:40
ali1234what, binutils upstream?18:40
rafaeldtinocoso someone else can merge it18:40
ali1234i kind of assumed that it had already been proposed, i mean that patch has been around for as long as multiarch18:41
ali1234so like 10+ years18:41
ali1234i kind of figured there's a reason it hasn't been merged upstream18:41
ali1234also you can't reproduce it in a simple example - it requires that you have a multiarch compiler and multiarch libs installed18:42
rafaeldtinocoali1234: https://wiki.dlang.org/GDC/Cross_Compiler/Existing_Sysroot18:42
ali1234yes, that18:42
rafaeldtinocogives as example doko's url on that patch18:43
ali1234so then that seems to indicate that it is only that one patch required18:43
ali1234there 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 have18:44
ali1234binutils supports multiarch but gcc doesn't18:44
rafaeldtinocoyep, when debugging readelf has to be the binary for the arch being debugged18:45
ali1234i get the feeling that there are no more than 5 people in the whole world who actually understand the problem :(18:45
rafaeldtinocoas multiarch is not compiled18:45
rafaeldtinocojust 1 example ^18:46
ali1234i don't know what that means18:46
ali1234gcc 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 source18:46
ali1234if you don't turn it on, then gcc won't be able to find your libs18:47
ali1234if you don't patch binutils then it wont be able to find your libs18:47
ali1234so you need both, or neither18:47
ali1234it doesn't even really have anything to do with architectures, it is just that the libraries are in a different directory to normal18:48
rafaeldtinocoali1234: arent u mixing up multiarch term with cross compiling ?18:48
ali1234you can have this problem with a native compiler18:48
ali1234no, i'm not18:48
ali1234they are two different things18:49
rafaeldtinocoi know they are =)18:49
ali1234you can have a native multiarch compiler18:49
ali1234multiarch 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 anything18:49
ali1234so 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 patch18:50
ali1234which seems insane given how closely related they are. you would think they'd both have it18:50
rafaeldtinocoI see what you mean now18:50
ali1234if you have a system where one of them supports it and the other doesn't, you will have a bad time18:51
rafaeldtinocoali1234: when you say binutils, you mean only ld ?18:52
rafaeldtinocoor all binaries ?18:52
ali1234well the atch applies to the binutils source18:52
ali1234it only seems to touch ld and gold18:52
ali1234but binutils is binutils18:52
rafaeldtinocothis page covers lots of stuff about this:18:53
rafaeldtinocoThis 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
rafaeldtinocoAccording to the primary multiarch assumption, the system library search paths are modified to include the multiarch target string:18:54
ali1234sure. i'm not compiling glibc though18:54
rafaeldtinocoits the same case though18:54
rafaeldtinocoits basically saying you will have a problem with the linker18:54
rafaeldtinocodepending on LIBRARY_PATH18:55
ali1234ld.so, yes, but i'm not compiling that either18:55
ali1234i'm trying to make a toolchain that targets an existing debian sysroot18:55
rafaeldtinocoi see, for it to coexist18:55
ali1234so it already has all the runtime stuff18:55
rafaeldtinocoso you can generate armhf packages lets say18:56
ali1234right, and link against packaged libraries that already exist18:56
rafaeldtinocousing the second toolchain (cross compiling)18:56
rafaeldtinocoyep , i used to work @ linaro18:56
rafaeldtinocoi used armhf containers for that18:56
rafaeldtinocoor arm6418:56
ali1234containers are so slow though18:56
rafaeldtinocoits a good idea18:56
ali1234this is for raspbian18:56
rafaeldtinocoyep, depending on qemu-user-static isnt good18:56
ali1234linaro bootstrapped their original cross compiler18:56
rafaeldtinocobecause its not multi threaded also18:56
ali1234but it's now horribly out of date, and nobody at rpi-foundation knows how to make a new one18:57
rafaeldtinocoali1234: and why gcc6 ?18:57
ali1234not gcc618:57
rafaeldtinoconot 6 from your output ?18:57
ali1234ive been working on this for literally years18:57
ali1234gcc6 was the default for raspbian stretch18:58
rafaeldtinocogcc version 6.4.1 20180425 [linaro-6.4-2018.05 revision 7b15d0869c096fe39603ad63dc19ab7cf035eb70] (Linaro GCC 6.4-2018.05)18:58
ali1234but i want to be able to target current raspbian, which is 8.318:58
ali1234and then whatever the next one is... and so on18:58
rafaeldtinocoso your will at the end is to cross compile18:58
rafaeldtinocoall raspbian18:58
rafaeldtinocoin a fast way18:58
rafaeldtinocoso you dont depend on actual hw ?18:59
ali1234i dont want to cross compile anything that already exists in raspbian18:59
rafaeldtinocoor to have multiple toolchains18:59
ali1234i want to cross compile things that don't exist in raspbian, using the raspbian libraries that do exist18:59
rafaeldtinocohum. i see18:59
ali1234compiling raspbian itself ain't my problem. afaik they have some arm servers to do it19:00
rafaeldtinocoi was about to point you https://www.socionext.com/en/products/assp/SynQuacer/Edge/19:00
rafaeldtinocobut as you said, its likely something to allow others as well19:00
rafaeldtinocoto contribute generating new packages19:00
rafaeldtinocowithout having necessarily the arch19:01
ali1234yeah i bet that is still slower than cross compiling19:01
rafaeldtinocoits not =)19:01
rafaeldtinocoLinux firewall 5.0.0-30-generic #32-Ubuntu SMP Wed Sep 18 00:24:43 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux19:01
rafaeldtinoco$ nproc19:01
rafaeldtinocoits not super fast19:01
rafaeldtinocobut its ok19:01
ali1234how much does it cost?19:01
rafaeldtinoco~ $1k19:02
rafaeldtinoco1.2k i suppose19:02
ali1234hmm that's actually kind of reasonable for 24 core19:02
rafaeldtinocoARMv8 rev 119:02
rafaeldtinocoyou can run armhf kvm guests19:02
rafaeldtinocoor lxd guests19:02
rafaeldtinocolike I do19:02
rafaeldtinocoI do ubuntu armhf/arm64 debugs on that machine19:02
ali1234still, the lack of cross compiler annoys me, and i'm not the only one19:02
rafaeldtinocoyep yep19:02
rafaeldtinocoorthogonal things19:03
rafaeldtinocojust for you to have in mind ^19:03
ali1234so the problem i have now is that i built the compiler i have now with linaro abe19:03
ograjust get a Pi4 4GB, a fast USB3 SSD and be done ... my builds on that HW run as fast/slow as on launchpad19:04
ali1234lol, launchpad is really slow19:04
ograi have seen and done slower arm builds :)19:04
ali1234anyway, 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 binutils19:04
* ogra did the original ubuntu arm port bootstrapping on an nslu2 ;)19:05
rafaeldtinocoogra: #) =)19:05
ali1234how many times did you have to run "make" before it worked?19:05
* rafaeldtinoco gets back to eoan installer problem19:06
rafaeldtinocoas BETA is broken19:06
ograendless times :)19:06
rafaeldtinocoali1234: let me know your findings19:06
ogranot many people know though that we actually supported ARMv5 for one release19:06
ogra(jaunty IIRC)19:06
ali1234okay a question: the binutils-source package: is the tarball inside it pre-patched?19:22
ali1234same question for gcc-8-source19:22
sarnoldali1234: if the tarball name includes 'dfsg' in it, that's a clear sign that it has been; otherwise it's harder to tell19:23
ali1234i'm not talking about the source package19:25
ali1234binutils-source is a "binary" package that installs /usr/src/binutils/binutils-2.31.1.tar.xz19:25
ali1234(or whatever version)19:26
ali1234thing is... it also installs a "patches" subdir so i am wondering if i need to apply those manually?19:30
rafaeldtinocoali1234: you should read a bit about debian packaging19:31
ali1234this isn't a source package >.<19:31
blackboxswHey 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
blackboxswI 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* rather19:51
blackboxswIs 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
ali1234what if /etc/os-release is updated but nothing else on the system is?19:55
sarnoldblackboxsw: 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-depends19:55
sarnoldblackboxsw: those tend to add brittleness though so it'd probably be worth exploring alternatives further19:56
blackboxswsarnold: 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 option19:57
blackboxswthen our new package would know it's upgrading across a release19:58
sarnoldblackboxsw: 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 me19:58
blackboxswali1234: 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 that19:58
blackboxswthanks for the suggestions19:59
ali1234well, why do you need to know the release at install time then?19:59
ali1234or are you just trying to figure out that the release has changed?20:03
Unit193If anyone cares about wayland and wxgtk, https://packages.qa.debian.org/w/wxwidgets3.0/news/20191002T204524Z.html fixes two-finger touchpad scrolling.20:56
Unit193https://salsa.debian.org/freewx-team/wx/commit/9fe0c523faa50746099444ed7b50fccf7bbda136.patch is actually surprisingly small..20:58
chilukis anyone going to KubeCon ? I'd love to catch up with some of my old ubuntu peoples.21:23
ahasenackhm, I have a postinst calling gpg, and am wondering if I should add gpg (or gnupg) to d/control's Depends21:34
ahasenackthe package is flagged as optional in bionic21:34
ahasenackand important on trusty21:34
ahasenackhaven't seen a system without /usr/bin/gpg, but looks like it's possible21:38
infinityahasenack: apt-cache show gnupg | grep ^Essential22:08
infinityahasenack: If that doesn't return anything (compare to, say, "apt-cache show coreutils | grep ^Essential"), then you need a dependency.22:08
infinityahasenack: Relying on "I think most people have this installed" isn't the way to go. :)22:08
ahasenackyep, I'm adding it, I checked Priority before22:09
ahasenackand there is no "Essential" as you said22:09
mwhudsonsome gpgv* is guaranteed to be there23:17
mwhudsonbecause apt23:17
mwhudsonbut not everything23:17
Unit193Package: 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!