| === debfx_ is now known as debfx | ||
| jamespage | xnox: hello - I'm trying to figure out why ceph on armhf has suddenly decided it wants to link against libboost-random1.67.0 - all other archs don't which I find odd | 10:02 |
|---|---|---|
| jamespage | any ideas? | 10:03 |
| gpiccoli | Hi sil2100, vorlon - recently (~a month ago) mdadm was pushed to -proposed but it contains code that depends on kernel counter-part, from dannf. Kernel team is still figuring the proper solution to this raid0 layout stuff, so mdadm is block-proposed. Well...I need to release a mdadm version with a small patch, so discussed with dannf and kernel team, and we decided, if possible, to drop the current proposed and do my release first | 10:15 |
| gpiccoli | So, can I ask you to drop the current mdadm from proposed? ddstreet uploaded my mdadm version, it's all explained in LP #1847924 | 10:16 |
| ubottu | Launchpad bug 1847924 in mdadm (Ubuntu Eoan) "Introduce broken state parsing to mdadm" [Medium,In progress] https://launchpad.net/bugs/1847924 | 10:16 |
| gpiccoli | Tnx in advance sil2100 and vorlon | 10:16 |
| LocutusOfBorg | jamespage, https://launchpadlibrarian.net/460565614/buildlog_ubuntu-focal-armhf.ceph_14.2.5-3ubuntu2_BUILDING.txt.gz | 10:20 |
| LocutusOfBorg | "libboost_random" is used in some places | 10:20 |
| LocutusOfBorg | e.g. ceph-mon | 10:21 |
| LocutusOfBorg | ceph-dencoder | 10:21 |
| jamespage | LocutusOfBorg: yeah that's what's puzzling me - because all of the other arch builds do the same thing but don't end up with that as a depends | 10:23 |
| LocutusOfBorg | ldd /usr/bin/ceph-dencoder |grep random -> returns stuff on armhf | 10:25 |
| sil2100 | gpiccoli: hey! The mdadm upload that you have prepared, just to confirm - it's based on what was in updates rather than what was in -proposed, correct? | 10:28 |
| gpiccoli | Hi sil2100 o/ | 10:30 |
| gpiccoli | Exactly, it's based on -updates | 10:30 |
| gpiccoli | I've added an entry (as per ddstreet suggestion) related to dannf proposed stuff, and mentioned in my changelog that it was removed | 10:31 |
| gpiccoli | This is in order to have users better clarified on what's happened | 10:31 |
| * gpiccoli bbiab (~2h) | 10:31 | |
| jamespage | LocutusOfBorg: linking is wonky on that architecture - "lots of package could avoid a useless dependency" | 10:47 |
| LocutusOfBorg | yes I came to the same conclusion | 10:50 |
| LocutusOfBorg | linker is not stripping it | 10:50 |
| LocutusOfBorg | because objdump on armhf and amd64 shows the same symbols used on both archs, and none related to random | 10:50 |
| LocutusOfBorg | doko, ^^ this looks like more a binutils regression TBH | 10:53 |
| jamespage | I checked the previous armhf build and it does not appear to have the same issue | 10:54 |
| jamespage | looking into the logs now | 10:54 |
| LocutusOfBorg | https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/10936746/+listing-archive-extra | 10:55 |
| LocutusOfBorg | jamespage, ^^ | 10:55 |
| jamespage | ack | 10:57 |
| jamespage | only ref I can find in the source tree is to a test class so it might be needed for the build, but not for the binaries | 10:58 |
| infinity | boost_random is being explicitly placed on the linker line, I'm not sure you can blame binutils for doing as asked. | 10:58 |
| LocutusOfBorg | infinity, I blame binutils for not correctly stripping it with as-needed provided | 10:59 |
| LocutusOfBorg | and I blame it for correctly removing it on everywhere except armhf... | 10:59 |
| LocutusOfBorg | moreover, the last run on 22/12/2019 https://launchpad.net/ubuntu/+source/ceph/14.2.4-0ubuntu3/+build/18461332 had the same boost_random link, but no random library linked | 11:01 |
| infinity | So, further WTF, why is armhf built with clang and arm64 with g++? | 11:01 |
| infinity | * [6eddb32] Build with clang(++) on armhf mipsel armel. | 11:03 |
| LocutusOfBorg | #849657 | 11:03 |
| infinity | That's likely the cause of the behaviour difference. | 11:03 |
| infinity | And it's not needed for Ubuntu, I imagine, where our armhf buildds are beefy. | 11:03 |
| LocutusOfBorg | so clang is dumb? | 11:03 |
| infinity | clang might indeed be dumb. Even if it's not, it's really poor form to use different compilers on different arches, and a nightmare to debug the subtle binary differences. | 11:05 |
| infinity | jamespage: I'd recommend backing out that g++ -> clang++ change and see if it magically loves you. | 11:05 |
| infinity | (make it dependent on a dpkg-vendor is Debian check, if you want to upstream it and let Debian keep their braindead nonsense here) | 11:06 |
| jamespage | infinity: good spot | 11:06 |
| jamespage | thanks | 11:06 |
| LocutusOfBorg | infinity, maybe if you want to upstream the change in Debian, you can ask them to keep gcc and reduce parallelism on arm? | 11:07 |
| infinity | No idea if it was an OOM they were working around or hitting the 2G hard limit (but we don't build on 32-bit kernels, so our hard limit's a bit higher for individual userspace processes, or should be) | 11:10 |
| infinity | Either way, if it works with g++ on Ubuntu, my carefactor for what Debian does it low. | 11:10 |
| jamespage | I'll do the dpkg-vendor trick to exclude ubuntu | 11:10 |
| infinity | s/it/is/ | 11:10 |
| jamespage | happy to push that back to Debian - I'm working with the new maintainer to get things back in sync and still have git commit permissions | 11:11 |
| LocutusOfBorg | looks like they are already using max-parallel=2 on armhf | 11:11 |
| infinity | Also unnecessary for us. | 11:11 |
| infinity | Probably. | 11:12 |
| jamespage | you'd be surprised - ceph can hit the ceiling | 11:12 |
| infinity | Well, if it works with parallel=4 on other arches, it should on armhf too. :P | 11:12 |
| jamespage | of the builder memory size easily with any level of parallel | 11:12 |
| infinity | (note that armhf and arm64 buildds are literally identical VMs on identical hardware, and I refuse to believe the 64-bit builds use less RAM) | 11:12 |
| jamespage | infinity: whats the memory size? | 11:13 |
| jamespage | looking at notes I left myself in the past | 11:13 |
| infinity | I believe they're all 4 vCPU, 8G. I think. | 11:13 |
| jamespage | https://www.irccloud.com/pastebin/MmppuWX8/ | 11:13 |
| LocutusOfBorg | https://salsa.debian.org/ceph-team/ceph/commit/6eddb32731f4edda764eb5f4cd634599a8487ca7 | 11:13 |
| LocutusOfBorg | I think this commit needs to be relegated to just armel and mipsel | 11:13 |
| LocutusOfBorg | or probably only mipsel, I can't find any failure related to OOM in debian buildd logs | 11:14 |
| LocutusOfBorg | btw why not package the new release? | 11:14 |
| LocutusOfBorg | (funnily enough, all the mipsel hacks didn't work so far, the package still FTBFS there) | 11:15 |
| infinity | mipsel probably just needs to die in a fire. | 11:17 |
| infinity | Oh, but they're building it on shiny mips64 hardware/kernels now. So, WTF. | 11:18 |
| Laney | Drop it and see what happens. Worst case you have to revert, but yay for unstable being unstable. :) | 11:20 |
| LocutusOfBorg | what is the situation for htslib on s390x? debian removed it... | 11:20 |
| infinity | I am genuinely curious what horrifying things the ceph people are doing to OOM compilers like this. | 11:20 |
| infinity | LocutusOfBorg: It's fascinating to me that the upstream "we think there are endian issues" bug has been open for years, but the massive regression only happened, like, last month. | 11:32 |
| infinity | LocutusOfBorg: I'd suggest that bisecting where that went wrong would probably be trivial, but we can tear out the rdep stack too, whatever. | 11:32 |
| tarzeau | will 20.04 have python2 or not? | 13:03 |
| tarzeau | https://wiki.ubuntu.com/Python/3 not really up to date or? | 13:16 |
| ogra | tarzeau, there is a removal discussion on the ubuntu-dvel ML IIRC | 13:17 |
| ogra | *-devel | 13:17 |
| * tarzeau looks for the ml archive | 13:19 | |
| gpiccoli | sil2100, I'm back if you have anything to discuss about mdadm =) | 13:20 |
| tarzeau | https://lists.ubuntu.com/archives/ubuntu-devel/2020-January/thread.html | 13:20 |
| JackFrost | Given the timeframe, there's not enough time for https://people.canonical.com/~ubuntu-archive/transitions/html/python2-rm.html | 13:20 |
| JackFrost | https://ubottu.com/y/ff is the release schedule, if you wondered. | 13:22 |
| tarzeau | JackFrost: i'm aware of that still 40 days to get pkgs into 20.04 :) | 13:23 |
| tarzeau | i just don't know if 20.04 will have this or not: https://tracker.debian.org/pkg/gmic | 13:23 |
| JackFrost | It was already removed, so not if it isn't fixed. | 13:26 |
| JackFrost | !info gmic focal | 13:26 |
| ubottu | Package gmic does not exist in focal | 13:26 |
| tarzeau | i have a fix, but i don't like making nmus | 13:26 |
| tarzeau | you'll miss flowblade, sure you could make a snap of it | 13:27 |
| JackFrost | The maintainer is lowNMU, fwiw. | 13:27 |
| JackFrost | Did you see plugwash's work? | 13:27 |
| tarzeau | i know i even asked if he'd mind, and he doesn't, still i hate NMU (personal preference) | 13:28 |
| tarzeau | nope, where? | 13:28 |
| JackFrost | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922582#18 | 13:28 |
| ubottu | Debian bug 922582 in src:gmic "FTBFS against opencv 4.0.1 (exp)" [Serious,Open] | 13:28 |
| JackFrost | No I understand the distaste for NMUs. | 13:28 |
| tarzeau | yeah that's what i applied and given credit to bug reporter (hah, must fix): http://phd-sid.ethz.ch/debian/gmic/ | 13:29 |
| tarzeau | but then i'm not a fan of just fixing gmic, which is one year old, i'd rather have the latest 2.8.2 (for the next five years) | 13:29 |
| tarzeau | but oh well i run unreleased or sid anyways | 13:29 |
| JackFrost | I mean, Ubuntu *could* jump ahead I'd imagine. | 13:29 |
| tarzeau | i have never figured how to get something into ubuntu/or updated, still doing pkg into debian, waiting archive sync | 13:30 |
| tarzeau | and new queue/ debian/copyright is worse than finding dd-who-sponsors-dsc-links | 13:31 |
| JackFrost | If at all possible, Ubuntu hates to maintain deltas needlessly. | 13:31 |
| tarzeau | yeah i figured, and that's also great! | 13:31 |
| tarzeau | but now debian has fasttrack! | 13:31 |
| tarzeau | ok ubuntu has frankenPPA | 13:31 |
| JackFrost | Which...Isn't complete and doesn't precisely relate? :) | 13:31 |
| tarzeau | true, /me will stick to his reprepro (well not me, but user friends) | 13:32 |
| tarzeau | instead of deltas, what about allowing packages to circumvent debian new queue pkgs? | 13:33 |
| JackFrost | Some have done that, I don't know how frowned upon that is. | 13:33 |
| tarzeau | who is that some, and how did they do so? | 13:33 |
| JackFrost | (Also, some DDs don't like a dsc?) | 13:33 |
| tarzeau | because they prefer salsa git? | 13:34 |
| JackFrost | Basically by being the maintainer in Debian too. But they cheated with a 0build1 trick. | 13:34 |
| JackFrost | Ah. I like things being maintained in git, but dsc for sponsorship is nice. | 13:34 |
| tarzeau | is canonical doing HPC stuff? | 13:35 |
| tarzeau | (wrong channel to ask that?) | 13:35 |
| JackFrost | I'm not a Canonicalite. | 13:35 |
| JackFrost | tarzeau: https://salsa.debian.org/fasttrack-team/support/issues/10#note_123991 still isn't the most reassuring. | 13:41 |
| rafaeldtinoco | quick question on migrations | 14:01 |
| rafaeldtinoco | builddeps:/tmp/autopkgtest.9ZDytk/2-autopkgtest-satdep.dsc:i386 : Depends: wmnd-snmp:i386 but it is not installable | 14:01 |
| rafaeldtinoco | is i386 avoiding migrations currently ? | 14:01 |
| === ricab is now known as ricab|lunch | ||
| dannf | gpiccoli: thx! | 15:04 |
| gpiccoli | Thank you dannf, for letting me slip my upload first hehe =) | 15:05 |
| === ricab|lunch is now known as ricab | ||
| xnox | jamespage: fun! build log? Most likely something somehwere is missing, and normally the boost from inside ceph is used, instead of system one. Note that cmake&boost have weird integration now, such that "findboost" might be defaulting to system stuff now. | 15:29 |
| infinity | xnox: Check later context, his problem was almost certainy Debian switching armhf to clang, while other arches use gcc. | 15:56 |
| xnox | infinity: oh, ok. | 15:59 |
| tdaitx | so, is there a service I can trust to tell me if a given TZ table is actually wrong? in bug 1859217 the user complains that openjdk-8 has regressed on Istanbul TZ, but in fact openjdk-11 was only "working" (as per user description) because upstream didn't update it from tzdata2019b to tzdata2019c (while openjdk-8 did) | 16:19 |
| ubottu | bug 1859217 in openjdk-8 (Ubuntu) "openjdk8 update 8u232-b09-0ubuntu1~18.04.1 breaks Timestamp values for timezones that change DST observance" [Undecided,Confirmed] https://launchpad.net/bugs/1859217 | 16:19 |
| tdaitx | the latest security update for openjdk-11 now includes tzdata2019c and thus both openjdk-8 and openjdk-11 are now reporting the same values - which the user says that they are the wrong ones | 16:22 |
| tdaitx | so I need to check if the alleged "right" values are in fact the right ones | 16:22 |
| tdaitx | and yeah, I belive tzdata2019c is actually correct and the user is mistaken, but it would be good to check that somehow | 16:22 |
| tdaitx | sbeattie: fiy ^ | 16:22 |
| infinity | tdaitx: I mean, tzdata is the only authority on the topic, other than local governments and mystic divination. | 16:22 |
| infinity | tdaitx: On the other hand, 2019c didn't have changes to Istanbul AFAICT... | 16:25 |
| tdaitx | infinity: it did: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/8560bc534080 (that's the openjdk commit for it, it's the same as openjdk-11 and I suppose the same for upstream) | 16:26 |
| Laney | The announcement says it changed some historical data for Turkey | 16:27 |
| infinity | tdaitx: Oh, yeah, deep in the past. | 16:28 |
| tdaitx | yeah | 16:28 |
| infinity | If you want to check if they're right, Paul gives references in the comments. | 16:29 |
| infinity | But your user's bug is likely a non-bug. | 16:30 |
| tdaitx | infinity: sorry, which bug are you referring to? | 16:31 |
| infinity | tdaitx: The one you linked? | 16:32 |
| tdaitx | infinity: I don't see any comments from Paul | 16:33 |
| Laney | Paul is upstream of tzdata | 16:33 |
| infinity | tdaitx: Your user's complaint of regression is more just business as usual for tzdata. It's unfortunate that different Java versions will all disagree until they're all updated, but that's their own fault for bundling tzdata instead of using system zone files. :P | 16:33 |
| infinity | tdaitx: Oh, "the comments" being the comments in the zone files. Paul Eggert being Paul. When he changes things, he leaves comments referencing why (usually URLs to papers on the topic, etc) | 16:34 |
| infinity | tdaitx: But generally, I trust him to be right, as he's the de facto authority on timezones anyway. The world all uses tzdata as their authoritative set, so even if it's wrong, it's right. Until the next version, which is more right. | 16:35 |
| tdaitx | right, found it (it was the link for the commit, not a bug report, that's why I got confused) | 16:35 |
| tdaitx | ok, good to know | 16:35 |
| tdaitx | Laney: infinity: thanks | 16:36 |
| jamespage | xnox: figured it out - have an upload in testing atm | 16:40 |
| tdaitx | infinity: as for 'checking' the results, I used a simply "date --date='TZ="Europe/Istanbul" 1943-01-01 12:01:01' '+%s'" which confirms the openjdk output | 17:14 |
| === SuperKaramba is now known as BenderRodriguez | ||
| rafaeldtinoco | ahasenack: ping | 18:35 |
| ahasenack | rafaeldtinoco: hola | 18:35 |
| rafaeldtinoco | ahasenack: if you have ~5 min, could u check if it makes sense to add wmnd i386 test to britney hints file ? | 18:35 |
| rafaeldtinoco | both autopkgtests from it are mutual exclusive (wmnd and wmnd-snmp)... somehow autopkgtest can't handle test dependencies for i386 | 18:36 |
| rafaeldtinoco | not quite sure why | 18:36 |
| rafaeldtinoco | but everything is ok for i386 as well, Im afraid it will block its migration, and that is the last for net-snmp I believe | 18:36 |
| ahasenack | builddeps:/tmp/autopkgtest.WFivWM/1-autopkgtest-satdep.dsc:i386 : Depends: wmnd:i386 but it is not installable | 18:37 |
| ahasenack | have you tried installing that to see why it's uninstallable? | 18:37 |
| rafaeldtinoco | Broken builddeps:/tmp/autopkgtest.WFivWM/2-autopkgtest-satdep.dsc:i386 Depends on wmnd-snmp:i386:any < none @un H > | 18:37 |
| rafaeldtinoco | yep.. if I install locally generated .deb .. it passes test1 | 18:37 |
| ahasenack | well | 18:37 |
| ahasenack | no | 18:37 |
| ahasenack | I mean, on a amd64 host, add the i386 arch | 18:37 |
| ahasenack | and then try to install wmnd-snmp:i386 | 18:37 |
| ahasenack | you have wmnd in a ppa somewhere? | 18:38 |
| * rafaeldtinoco checks | 18:38 | |
| rafaeldtinoco | nope, will provide | 18:38 |
| rafaeldtinoco | ahasenack: https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1855943 | 18:57 |
| * ahasenack checks | 19:01 | |
| rafaeldtinoco | it does not work with add-architecture | 19:03 |
| rafaeldtinoco | it depends on having a full i386 env | 19:03 |
| rafaeldtinoco | it can't even find :i386 package | 19:03 |
| ahasenack | well, that ppa didn't build i386 | 19:04 |
| rafaeldtinoco | oh, yep | 19:05 |
| rafaeldtinoco | Intel x86 (i386) | 19:05 |
| ahasenack | https://launchpad.net/ubuntu/+source/wmnd/0.4.17-3ubuntu1 also didn't | 19:05 |
| rafaeldtinoco | it had default | 19:05 |
| rafaeldtinoco | yep | 19:05 |
| rafaeldtinoco | i guess its "deactivated | 19:05 |
| ahasenack | yes, not in the whitelist | 19:05 |
| rafaeldtinoco | that explains | 19:05 |
| ahasenack | vorlon: ping ^ | 19:05 |
| ahasenack | just a case for a badtest hint for wmnd/i386? | 19:05 |
| rafaeldtinoco | i believe so | 19:06 |
| rafaeldtinoco | its blocking net-snmp | 19:06 |
| rafaeldtinoco | which is blocking pcs | 19:06 |
| ahasenack | relax :) | 19:06 |
| ahasenack | many things are blocking many things in the archive at any given time :) | 19:06 |
| ahasenack | vor-lon might be mid-travel (sprint) | 19:07 |
| rafaeldtinoco | oh, true | 19:07 |
| rafaeldtinoco | https://media.giphy.com/media/5qoRdabXeT4GY/giphy.gif | 19:08 |
| rafaeldtinoco | =) | 19:08 |
| rafaeldtinoco | alright Ill shift context then | 19:08 |
| rafaeldtinoco | this one is almost there | 19:08 |
| ahasenack | you can propose an MP for the badtest, assuming that is the right thing | 19:10 |
| rafaeldtinoco | ahasenack: yep, will do it | 19:16 |
| rafaeldtinoco | tks | 19:16 |
| vorlon | ahasenack: hinted | 19:35 |
| ahasenack | rafaeldtinoco: ^ | 19:35 |
| ahasenack | vorlon: thanks! | 19:35 |
| vorlon | ahasenack: and yes, this is the correct course of action for any source packages not in the list I posted to ubuntu-devel | 19:36 |
| rafaeldtinoco | nice.. good to know | 19:36 |
| ahasenack | seconded | 19:36 |
| seb128 | vorlon, https://launchpad.net/ubuntu/+source/glib2.0/2.63.3-2 added a depends from the libglib2.0-tests to xdg-desktop-portal which is blocking migration since xdg-desktop-portal isn't available on i386. What's the recommended solution there? changing glib to not build the -tests package on i386? | 19:51 |
| ahasenack | vorlon: from https://pastebin.ubuntu.com/p/HmSd9xd7NN/, on an amd64 lxd with i386 added, I was able to install krb5-multidev:i386 libkrb5-dev:i386 and libkrad-dev:i386 just fine, but not build-essential. I don't even know why it's trying to install build-essential, the dep8 tests only require @ for the kinit test, and @, slapd, ldap-utils, libsasl2-modules-gssapi-mit for the slapd-gssapi test | 19:56 |
| ahasenack | and this passed before, lemme get the link | 19:56 |
| ahasenack | http://autopkgtest.ubuntu.com/packages/krb5/focal/i386 | 19:56 |
| ahasenack | build-essential amd64 was used the last time this i386 test passed | 19:57 |
| ahasenack | hmm, same this time | 19:58 |
| ahasenack | ah, if I enable proposed, then build-essential (amd64) becomes uninstallable | 19:59 |
| ahasenack | build-essential : Depends: libc6-dev but it is not going to be installed or | 19:59 |
| ahasenack | libc-dev | 19:59 |
| ahasenack | Depends: g++ (>= 4:9.2) but it is not going to be installed | 19:59 |
| ahasenack | linux-libc-dev (src:linux) 5.4.0-11.14 is in focal-proposed according to rmadison, but don't see it listed in https://launchpad.net/ubuntu/+source/linux (yet?) | 20:06 |
| ahasenack | https://launchpad.net/ubuntu/+source/linux/5.4.0-11.14 is a 404 | 20:07 |
| ahasenack | oh, there is a linux-5.4 source | 20:07 |
| ahasenack | https://launchpad.net/ubuntu/+source/linux-5.4 it tricks us | 20:08 |
| ahasenack | focal-specific | 20:08 |
| sarnold | ahasenack: I've found this helpful to try to keep track of the various kernel source packages https://kernel.ubuntu.com/sru/dashboards/web/kernel-stable-board.html | 20:08 |
| ahasenack | thanks | 20:10 |
| ahasenack | I'll wait for the kernel builds to settle a bit in proposed/migration | 20:12 |
| LocutusOfBorg | infinity, https://github.com/samtools/htslib/commit/418a183ef842a966afb00e783c09ac7fd7eaeb62 | 21:00 |
| LocutusOfBorg | does this ring a bell? | 21:00 |
| LocutusOfBorg | I git bisected it | 21:00 |
| LocutusOfBorg | and that is the first commit with s390x failing | 21:01 |
| vorlon | seb128: yes, I would say omit the glib-tests package | 21:17 |
| seb128 | vorlon, k, thanks | 21:17 |
| vorlon | ahasenack: build-essential:amd64 is installed because the way we're installing cross test deps leverages apt-get build-dep; so build-essential:native is always required by apt | 21:18 |
| ahasenack | I see | 21:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
