| mwhudson | vorlon: hmm | 00:29 |
|---|---|---|
| mwhudson | why is it so hard to find which isa an arm instruction belongs to! | 00:33 |
| mwhudson | i think that's a vfpv3 insn? so should be ok by default? | 00:34 |
| mwhudson | hmm seems to be vfp so should be ok | 00:48 |
| mwhudson | vorlon: i find all this stuff very confusing fwiw | 00:51 |
| mwhudson | whyyy does the cross compiler (arm-linux-gnueabi-gcc-11) default to -mfloat-abi=soft? | 00:55 |
| vorlon | mwhudson: so is it a bug in gcc that it's not being allowed by default? | 01:06 |
| mwhudson | vorlon: i don't know :/ | 01:06 |
| vorlon | heh | 01:06 |
| vorlon | doko: hi there ^^ | 01:06 |
| sarnold | iirc debian still has an armel release and that default may make more sense there | 01:06 |
| mwhudson | vorlon: yeah, see if you can get doko to explain it to you, then explain it to me :) | 01:06 |
| mwhudson | ah ffs | 01:07 |
| mwhudson | had the build failing in canonistack but erased the wrong schroot session :( | 01:07 |
| mwhudson | vorlon: it looks like as has a syntax for declaring in the .S file which fpu should be targeted | 01:23 |
| mwhudson | vorlon: this https://paste.ubuntu.com/p/wM3np3Wsbp/ seems to work for this file at least... | 01:26 |
| mwhudson | i don't know if that is "correct" though | 01:27 |
| mwhudson | i'll see if it lets the build finish at least :) | 01:28 |
| mwhudson | vorlon: relevant https://github.com/supertuxkart/stk-code/issues/4638 | 01:31 |
| ubottu | Issue 4638 in supertuxkart/stk-code "as_callfunc_arm_gcc.S:328: Error: selected FPU does not support instruction -- `vldmia.64 r10,{d0-d7}'" [Closed] | 01:31 |
| === pi3 is now known as Baytuch | ||
| seb128 | LocutusOfBorg, hey, for universe packages we rather add them to https://launchpad.net/ubuntu/+source/lto-disabled-list/ instead of adding delta to disable lto I think | 08:48 |
| schopin | Hi! I'm trying to figure out why glew isn't migrating, and it seems to be caused by this package : https://autopkgtest.ubuntu.com/packages/open3d/jammy/amd64 | 08:55 |
| schopin | Anyone know why the tests are "neutral" and not plain OK ? | 08:56 |
| ginggs | schopin: it's "neutral" because it only has superficial tests | 09:01 |
| schopin | I'm afraid I fail to see the point of differenciating superficial tests vs the "normal" ones. Aren't we just interested in failures anyway? | 09:04 |
| ginggs | in debian, a package is blocked if a superficial test fails, and it doesn't get quick migratation. i don't think it makes a difference in ubuntu | 09:04 |
| ginggs | *it doesn't get quick migratation if it passes | 09:05 |
| schopin | Oh, OK. If a superficial test fails it's the old "10-days and no RC" rule. | 09:05 |
| ginggs | if a superficial test regresses, the package cannot migrate | 09:06 |
| ginggs | if a package only has superficial tests, it can only migrate after 5 days | 09:07 |
| schopin | Do they also test rdeps or is it just a Ubuntu thing? | 09:12 |
| ginggs | they also test rdeps | 09:15 |
| ginggs | schopin: btw, glew is not migrating because of the "not considered" packages, like pymol | 09:29 |
| schopin | yeah, figured that out in the meantime :) | 09:29 |
| ginggs | the autopkgtests results are listed under Additional info | 09:29 |
| doko | mwhudson, arm-linux-gnueabi-gcc-11 is the soft-float compiler ... you may want to use arm-linux-gnueabihf-gcc-11 ... | 09:38 |
| doko | mwhudson, vorlon: the fpu flags, plus other extension flags are going away. extensions now need to be encoded in the architecture string, e.g. -arch=armv7-a+fp | 09:39 |
| LocutusOfBorg | seb128, I don't add to that list, because packages won't ever be removed from there :D | 13:41 |
| LocutusOfBorg | the reason for disabling lto is a gcc bug, and the gcc fix is already pending review on gcc list | 13:41 |
| LocutusOfBorg | so, once accepted, the package will be syncable again with no extra delta | 13:41 |
| seb128 | k | 13:41 |
| LocutusOfBorg | if we add to that list, it won't use lto "forever" because (I) won't care to check if the lto delta is needed or not | 13:41 |
| seb128 | I disagree with the initial statement though | 13:41 |
| LocutusOfBorg | how can we know? my approach is usually "sync first, prepare the merge, upload if the sync fails to build" | 13:42 |
| seb128 | the archive shouldn't act as your personal todolist at the cost of creating work for the project | 13:42 |
| seb128 | having to merge packages has a cost | 13:42 |
| LocutusOfBorg | sure, but I usually upstream the delta to debian, and try to have gcc bugs fixed whenever possible | 13:43 |
| LocutusOfBorg | and this is one case I checked before disabling lto | 13:43 |
| seb128 | yes, that's fine, I was just arguing against the 'delta is better than blacklisting because it's more visible to LocutusOfBorg' | 13:43 |
| LocutusOfBorg | doko, if you want to care about this patch https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 | 13:44 |
| ubottu | gcc.gnu.org bug 102059 in gcc "Incorrect always_inline diagnostic in LTO mode with #pragma GCC target('cpu=power10')" [Normal, Assigned] | 13:44 |
| LocutusOfBorg | seb128, I could have wrote that sentence really in a better way :) | 13:44 |
| seb128 | :-) | 13:44 |
| LocutusOfBorg | thanks for the hint about that list, I wasn't aware since today :D | 13:44 |
| seb128 | anyway, I didn't mean to argue about that, I was just pointing out the backlist package in case you did'nt know about it | 13:45 |
| seb128 | yw! | 13:45 |
| LocutusOfBorg | thanks for that, I hope one day lto will be default in Debian too, and in the meanwhile ppc64el specific bugs will be something fixed | 13:45 |
| LocutusOfBorg | doko, ^^^ should we prod that patch? its 2 months old | 13:46 |
| === genii-core is now known as genii | ||
| schopin | Is it a good/bad idea to send an apport bug report when a program uses Python exceptions as its user-facing error reporting mechanism? e.g. gbp couldn't find d/changelog and notified me via an exception, which made apport mad. | 18:11 |
| vorlon | doko: right; the question from my side was, is it a gcc bug that this instruction was not accepted without manually passing such an argument | 18:28 |
| vorlon | ginggs, schopin: wrt glew, I'm currently holding back no-change rebuilds for the libpoppler transition because the two would be entangled via gambas3 | 18:29 |
| seb128 | vorlon, I didn't test every rdepends but at least extractpdfmark, gdcm, xpdf and pdf2djvu need code fixes for the new poppler. Or said differently best to not throw untested no change rebuilds to the archive | 18:50 |
| vorlon | seb128: if they need code changes but the problem is not caught by either build time tests or autopkgtests, I argue the bug is not in the throwing no-change rebuilds at the archive ;) | 18:51 |
| vorlon | anyway, 'sfine, glew isn't moving yet - I was mostly meaning to caution other people not to do no-change uploads for poppler until glew has cleared | 18:52 |
| seb128 | vorlon, I'm rather seeing that as 'what's the point throwing things that will fail to build to the archive' | 18:52 |
| vorlon | seb128: one point is that it makes it more obvious from looking at update_excuses and the state of proposed what work needs to be done | 18:52 |
| seb128 | unless you consider the archive as a test build env ;) | 18:52 |
| seb128 | sort of I guess, without upload you know what packages need work though, just you don't know if that's a rebuild or more. but the same way a build failure isn't going to tell you if the fix is easy or not... | 18:54 |
| LocutusOfBorg | bryyce, hello, what about syncpackage -f php8.1? | 19:01 |
| ddstreet | slyon re: https://code.launchpad.net/~slyon/ubuntu/+source/systemd/+git/systemd/+merge/411528 I'd rather not revert that as it does cause real problems of leaking scopes/sessions that have real impacts on users, epecially those using k8s on bionic | 19:32 |
| ddstreet | the lp:#1949089 bug seems to be an issue of the snap mount unit being restarted (or stopped/started) during a daemon-reload, is that right? | 19:33 |
| ubottu | Launchpad bug 1949089 in systemd (Ubuntu Bionic) "systemd randomly fails to activate mount units in Ubuntu Core 18" [Undecided, New] https://launchpad.net/bugs/1949089 | 19:33 |
| vorlon | juliank: request.cgi seems to not be answering | 19:39 |
| juliank | vorlon: looking | 19:39 |
| juliank | vorlon: so it sent to me SSO successfully but hangs now | 19:40 |
| juliank | vorlon: i see several hanging processes | 19:41 |
| juliank | (request.cgi ones) | 19:41 |
| vorlon | at least 3 are mine ;) | 19:41 |
| juliank | [Tue Nov 09 19:38:43.744034 2021] [cgi:warn] [pid 2692518] [client 10.15.102.10:56674] AH01220: Timeout waiting for output from CGI script /var/lib/juju/agents/unit-autopkgtest-web-1/charm/webcontrol/request.cgi, referer: https://people.canonical.com/ | 19:42 |
| juliank | vorlon: hmm no gdb on the machine, would installing it mess stuff up? | 19:43 |
| vorlon | I don't believe it would | 19:43 |
| juliank | Basically it hangs in a recvfrom() | 19:43 |
| vorlon | but also maybe you just need to restart rabbit | 19:43 |
| juliank | most likely yes | 19:44 |
| juliank | restart started | 19:44 |
| juliank | not sure if it will restart :D | 19:45 |
| juliank | vorlon: yup, that did the trick | 19:46 |
| juliank | should setup monthly service restart timer | 19:46 |
| bryyce | <LocutusOfBorg> if you'd like, that'd be fine, just doublecheck the -mfpu=vfpv3-d16 fix we did for ubuntu2 is included | 19:49 |
| juliank | cpu usage on rabbitmq is now much nicer | 19:50 |
| LocutusOfBorg | bryyce, * Disable Zend fiber asm on armhf (FTBFS) | 19:51 |
| LocutusOfBorg | this is the changelog in debian. | 19:51 |
| LocutusOfBorg | I suspect they didn't include the vfpv3 change and disabled the feature? | 19:51 |
| LocutusOfBorg | do you think we should ask debian to add again the feature and the armhf flag? | 19:53 |
| LocutusOfBorg | bryyce, I asked here https://salsa.debian.org/php-team/php/-/commit/016bd26c99b6f3e0c02d56ac915069808d4463c1 | 19:56 |
| ubottu | Commit 016bd26 in php-team/php "Disable Zend fiber asm on armhf (FTBFS)" | 19:56 |
| === klebers_ is now known as klebers | ||
| === mnepton is now known as mneptok | ||
| === toabctl_ is now known as toabctl | ||
| === franksmcb_ is now known as franksmcb | ||
| === genii-core is now known as genii | ||
| === coetzeer_ is now known as coetzeer | ||
| mwhudson | doko: oh yes, how could i possible get confused by arm triplets!! | 20:10 |
| bryyce | LocutusOfBorg, interesting -- is debian's "armhf" different from ubuntu's "armhf"? | 20:16 |
| bryyce | LocutusOfBorg, well, worst case we can re-patch our change if needed. Only thing I'm a bit worried about is if it disrupts the transition's progress | 20:19 |
| bryyce | sergiodj, you were the one that figured out -mfpu=vfpv3-d16 to get php8.1 passing for us; can you take a peek at https://salsa.debian.org/php-team/php/-/commit/016bd26c99b6f3e0c02d56ac915069808d4463c1? | 20:23 |
| ubottu | Commit 016bd26 in php-team/php "Disable Zend fiber asm on armhf (FTBFS)" | 20:23 |
| sergiodj | bryyce: looking | 20:26 |
| mwhudson | doko: so is http://launchpadlibrarian.net/567930383/supertuxkart_1.3+dfsg1-2_1.3+dfsg1-2ubuntu1.diff.gz the right sort of thing to do or wrong headed? would .arch armv7-a+fp be better? | 20:29 |
| sergiodj | bryyce: left a comment there, hopefully it's helpful | 20:43 |
| bryyce | @sergiodj, thanks! | 20:43 |
| bryyce | LocutusOfBorg, ok so let's hold on syncing the newer php8.1 for now, hopefully we can get through more of the transition with the rc4, as discussion continues on the armhf solution. | 20:45 |
| mwhudson | well https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#h5py is pretty angry | 20:49 |
| mwhudson | i think it's uninstallable packages mostly though? | 20:49 |
| === pizzaiolo is now known as pizza | ||
| slingamn | i'm looking into making a change to system-config-printer, specifically to how it makes http requests | 21:45 |
| slingamn | but i'm not sure about the relationship between the ubuntu package and this upstream: https://github.com/OpenPrinting/system-config-printer | 21:45 |
| slingamn | should i send the patch to upstream and then try to have it pulled back in by ubuntu? | 21:47 |
| dbungert | slingamn: generally that's preferable | 21:48 |
| slingamn | makes sense...is there a reason the launchpad repo has an incompatible git history? the commit messages say "Imported using git-ubuntu import." | 21:49 |
| rbasak | slingamn: git-ubuntu provides a unified git history for every package in Ubuntu that is imported (it's planned to eventually import them all). Regardless of whether Debian and/or upstream even use git or not. You don't have to use that view though. | 21:53 |
| slingamn | oh...is there an alternative git history available from launchpad that has the ubuntu packaging metadata and patches if applicable, but is based on upstream's git history? | 21:54 |
| mwhudson | slingamn: not in general no | 21:54 |
| slingamn | coo | 21:54 |
| slingamn | *cool | 21:54 |
| mwhudson | having said that, i have plenty of repos that have both the ubuntu import and upstream as remotes | 21:55 |
| mwhudson | cherry-pick and rebase don't care whether commits have shared ancestry after all | 21:55 |
| rbasak | Right - just add both remotes and then "git diff" works. I'm not sure I understand a use case that actually requires the upstream to be the commit ancestor. | 21:56 |
| rbasak | And like you say, you can just rebase to temporarily see that view. | 21:56 |
| rbasak | It's not possible to do universally for all packages because of various mismatches that are common along the way. For example upstream tarball releases, upon which packaging is often based, often is different from the contents of their own git trees. | 21:57 |
| mwhudson | rbasak: do you have any feel for how much disk space all the current imported branches take? | 22:00 |
| sarnold | eg https://github.com/erthink/libmdbx#never-use-tarballs-nor-zips-automatically-provided-by-github- | 22:00 |
| rbasak | mwhudson: that's more of a question for the Launchpad admins, sorry. | 22:22 |
| mwhudson | rbasak: fair enough | 22:22 |
| mwhudson | i wonder about mirroring them all locally, probably don't have a big enough hd for that yet :) | 22:22 |
| rbasak | There's work in progress to migrate to bigger disks. Currently the server storing the git repos is I'm told nearly full. | 22:22 |
| sarnold | I've also wodnered about storing them all locally ;) | 22:23 |
| rbasak | I'd really like someone to write a caching git proxy | 22:23 |
| rbasak | Being content addressed, this should be possible | 22:23 |
| rbasak | Then I wouldn't need a full local mirror but would benefit from packages I clone frequently without having to manage the local copies myself. | 22:23 |
| mwhudson | sarnold: well obviously you would be thinking about that ;-p | 22:25 |
| mwhudson | rbasak: for me it's more for the random packages i hit on +1 week | 22:25 |
| mwhudson | cloning is slow for me, thanks to latency if nothing else | 22:25 |
| rbasak | I think maybe it's not your distance and cloning is slow for everyone :) | 22:25 |
| cjwatson | We don't store repository sizes in our DB at the moment, so I don't have a straightforward way to answer that disk space question. | 22:26 |
| cjwatson | Disk migration (and indeed full service migration) is tomorrow morning, assuming all goes well ... | 22:29 |
| sarnold | \o/ good luck :D | 22:30 |
| mwhudson | rbasak: well it doesn't help :) | 22:48 |
| mwhudson | what do failures like this mean? https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/armhf/e/eckit/20211108_222709_385c9@/log.gz | 23:24 |
| keyke | yo | 23:24 |
| keyke | sup | 23:24 |
| sarnold | mwhudson: hah, did it really fall over due to this? /usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead. | 23:42 |
| mwhudson | sarnold: well i hope not | 23:49 |
| mwhudson | sarnold: current guess it that the extract is ooming or something | 23:49 |
| === WrathOfA1hilles is now known as WrathOfAchilles | ||
| sarnold | mwhudson: hmm looking at it again I see this right at the top where it's easy to overlook tee: /proc/self/fd/2: Permission denied | 23:51 |
| mwhudson | sarnold: don't all armhf autopkgtest runs have that? | 23:52 |
| sarnold | if *thats* the cause it'd sure be nice if it fell over way sooner :) but .. it's kinda thin on why it failed :( | 23:52 |
| sarnold | heh, dunno :( | 23:52 |
| mwhudson | this one passed and has the same message https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/armhf/e/eckit/20211106_125041_2c5b9@/log.gz | 23:52 |
| sarnold | oh nice, thanks | 23:55 |
| mwhudson | argl bargl this package no longer builds on armhf | 23:55 |
| rbasak | mwhudson: I wonder if you could comment on https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2021-November/019099.html please? | 23:55 |
| mwhudson | oh yeah that's something we should do but i have no idea how to :( | 23:56 |
| mwhudson | rbasak: i'll try to get something like that into a ticket at least | 23:56 |
| mwhudson | i am somewhat distressed to find that there are packages in ubuntu called "eckit" and "fckit" | 23:59 |
| mwhudson | someone thought they were being witty | 23:59 |
| mwhudson | (no dckit or gckit though, thankfully) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!