| LocutusOfBorg | stgraber, LP: #1843383 pleeeeeeeeeeease^ | 07:45 |
|---|---|---|
| ubottu | Launchpad bug 1843383 in lxc (Ubuntu) "lxc, please bump epoch to 1" [Undecided,New] https://launchpad.net/bugs/1843383 | 07:45 |
| LocutusOfBorg | vorlon, ^^ | 07:45 |
| seb128 | could people stop doing retries on duplicity/ppc64el build? it's not going to work, the tests need to be fixed | 08:24 |
| cpaelzer | shame on me, why must x86 assembly always be so hard - does anyone know if the segement registers FS/GS are adapting size if e.g. in .code64 mode - are they still only 16bit there or bigger? | 09:58 |
| cpaelzer | there are all kind of uses of the regs https://codesearch.debian.net/search?q=pop%5Ba-z%5D%5Cs*%25fs&literal=0 but usually in .code16 or .code32 | 09:58 |
| cpaelzer | with the new gcc in eoan this particular one using quad words fails https://codesearch.debian.net/show?file=ipxe_1.0.0%2Bgit-20190125.36a4c85-1%2Fsrc%2Farch%2Fx86_64%2Fcore%2Fgdbidt.S&line=161 | 09:59 |
| cpaelzer | but it is in .code64 unlike most of the others | 09:59 |
| cpaelzer | gcc seems to be happy with popw and I now wonder if this is a false positive by gcc on FS/GS being 16bit or if this really never changes size | 09:59 |
| cpaelzer | what makes this more awkward in .code32 the pushl/popl (32bit) seem to be working | 10:00 |
| rafaeldtinoco | cpaelzer: amd did something to fs/gs in amd64, abandoning its original purpose since nobody used segmentation anylonger | 10:35 |
| rafaeldtinoco | im not sure what though | 10:35 |
| cpaelzer | I know that it is reused | 10:35 |
| cpaelzer | for cpu local storgae and such | 10:35 |
| cpaelzer | but I need the size | 10:35 |
| rafaeldtinoco | I see | 10:35 |
| cpaelzer | I might find the size if I read the related kernel source thou ... | 10:36 |
| rafaeldtinoco | cpaelzer: so... since you are here.. | 10:36 |
| rafaeldtinoco | have u ever seen a HW instruction that does not return | 10:36 |
| cpaelzer | yet so far - always I see code doing 1. switch to 16bit then 2. use small push/pop | 10:36 |
| rafaeldtinoco | and program counter stays in the same address | 10:36 |
| rafaeldtinoco | over and over after preempted by sched | 10:36 |
| cpaelzer | yes I have seen that | 10:36 |
| rafaeldtinoco | and it goes back to that pc and stays there | 10:36 |
| cpaelzer | which arch rafaeldtinoco? | 10:36 |
| rafaeldtinoco | etc etc | 10:36 |
| rafaeldtinoco | aarch64 | 10:36 |
| rafaeldtinoco | I think huawei microcode for cmpxchg is broken | 10:37 |
| rafaeldtinoco | :o) | 10:37 |
| cpaelzer | this is exactly the kind of instructions youd expect such a bug | 10:37 |
| rafaeldtinoco | => 0x0000aaaaaabd4110 <+32>: stlxr w2, w1, [x0] | 10:37 |
| cpaelzer | not on e.g. an add | 10:37 |
| rafaeldtinoco | if I move by hand the program counter | 10:37 |
| rafaeldtinoco | it moves and continues | 10:37 |
| rafaeldtinoco | until there is another instruction | 10:37 |
| rafaeldtinoco | of the same kind | 10:37 |
| rafaeldtinoco | :o) | 10:37 |
| rafaeldtinoco | i'll check w/ them in public bug | 10:37 |
| cpaelzer | rafaeldtinoco: https://community.arm.com/developer/tools-software/oss-platforms/f/dev-platforms-forum/5316/issue-with-stxr-in-armv8 | 10:38 |
| rafaeldtinoco | cpaelzer: somehow I was expecting a timeout to instruction generating an exception, NMI like | 10:39 |
| cpaelzer | there it only behaved that way when it was single stepping | 10:39 |
| rafaeldtinoco | cpaelzer: yep, ive read that | 10:39 |
| rafaeldtinoco | looks like STLXR has some peculiarities | 10:39 |
| rafaeldtinoco | and undefined behavior under certain conditions | 10:39 |
| rafaeldtinoco | but I was expecting some timeout/exception approach | 10:39 |
| cpaelzer | ok, then a public bug with the manufacturer seems right | 10:40 |
| rafaeldtinoco | yep, Ill read more about those peculiarities and ask them | 10:40 |
| rafaeldtinoco | thx | 10:40 |
| rafaeldtinoco | 0x0000aaaaaabd4108 <+24>: ldaxr w1, [x0] | 10:56 |
| rafaeldtinoco | 0x0000aaaaaabd410c <+28>: orr w1, w1, #0x1 | 10:56 |
| rafaeldtinoco | => 0x0000aaaaaabd4110 <+32>: stlxr w2, w1, [x0] | 10:56 |
| rafaeldtinoco | cpaelzer: does it look weird to you | 10:56 |
| rafaeldtinoco | ORring w1 in between ldaxr and stlxr ? | 10:56 |
| rafaeldtinoco | x0 is target address, w1 is the value to be written .. | 10:57 |
| rafaeldtinoco | so nope | 10:57 |
| rafaeldtinoco | its just a xor of the value read to be written | 10:57 |
| rafaeldtinoco | nm | 10:57 |
| rafaeldtinoco | and then a brunch if not success, got this | 10:58 |
| rafaeldtinoco | omg, armv8 docs have ~4pages for unpredictable errors for ldxar<->stlxr combination | 11:25 |
| * rafaeldtinoco goes for a coffee | 11:25 | |
| === cpaelzer__ is now known as cpaelzer | ||
| === ricab is now known as ricab|brb | ||
| === Wryhder is now known as Lucas_Gray | ||
| === grumble is now known as \emph{grumble} | ||
| ahasenack | rbasak: hi, we have some php deps in universe again: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php-defaults | 12:37 |
| ahasenack | php7.2-dev is in main, for example | 12:38 |
| === ricab is now known as ricab|lunch | ||
| rbasak | ahasenack: I think those binary packages are in mismatched components between src:php-defaults and src:php7.3 | 12:59 |
| ahasenack | rbasak: is this the report? https://people.canonical.com/~ubuntu-archive/component-mismatches | 12:59 |
| rbasak | ahasenack: if they're moved to match Disco then I think that'll resolve it | 12:59 |
| ahasenack | if yes, I don't understand its output: it just says "https://people.canonical.com/~ubuntu-archive/component-mismatches" for php7.3 (src) | 13:00 |
| rbasak | ahasenack: https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed | 13:00 |
| ahasenack | aha | 13:00 |
| * ahasenack updates bookmark | 13:00 | |
| rbasak | Both are relevant, but as packages we want are stuck in proposed, the proposed one is needed to make sense of it | 13:01 |
| ahasenack | looks like they are listed there | 13:01 |
| cpaelzer | ahasenack: I work on the list of FTBFS sent by doko - do you mind if i grab squid as you usually work on it? | 13:23 |
| ahasenack | cpaelzer: I have a branch for that already | 13:24 |
| ahasenack | but maybe your fix is nicer? I'm just dropping that include file, it's not used anymore in that file that failed the build | 13:24 |
| ahasenack | cpaelzer: https://code.launchpad.net/~ahasenack/ubuntu/+source/squid/+git/squid/+ref/eoan-squid-ftbfs-glibc-230 is my fix | 13:24 |
| ahasenack | I wanted to wait a bit for an upstream comment | 13:24 |
| ahasenack | ppa at https://launchpad.net/~ahasenack/+archive/ubuntu/squid-ftbfs-glibc-230 | 13:25 |
| === DarkTrick_ is now known as DarkTrick | ||
| cpaelzer | ahasenack: I haven't started on this one yet | 13:34 |
| cpaelzer | so my branch can't be nicer | 13:34 |
| cpaelzer | i have done dovecot-antispam (no issue), ipxe (fix in upstream review) and dnsmasq (MP is up for review) | 13:34 |
| cpaelzer | ahasenack: your fix looks ok to me | 13:36 |
| cpaelzer | waiting for upstream feedback seems right | 13:36 |
| cpaelzer | looking for another one in this list then ... | 13:36 |
| rafaeldtinoco | cpaelzer: i might need to 1:1 w/ you later today (after daily ?) | 13:53 |
| rafaeldtinoco | want to check if out-of-order have caused this issue | 13:53 |
| cpaelzer | before would be preferred | 13:53 |
| rafaeldtinoco | before ? | 13:53 |
| rafaeldtinoco | 30 min ? | 13:53 |
| cpaelzer | yes | 13:53 |
| cpaelzer | ok for me | 13:53 |
| rafaeldtinoco | good, will ping u tks | 13:53 |
| cpaelzer | in ~37 from now | 13:53 |
| rafaeldtinoco | +1 | 13:53 |
| === ricab|lunch is now known as ricab | ||
| rafaeldtinoco | HA.. I think I found the issue | 14:14 |
| rafaeldtinoco | #) | 14:14 |
| rafaeldtinoco | \o/ | 14:14 |
| rafaeldtinoco | cpaelzer: nm on 1:1, ill let u free | 14:17 |
| rafaeldtinoco | :o) I have to test a few things now | 14:17 |
| rafaeldtinoco | by re-generating the pkgs so.. | 14:18 |
| cpaelzer | hehe | 14:18 |
| rafaeldtinoco | wont bother u | 14:18 |
| cpaelzer | ok | 14:18 |
| rafaeldtinoco | https://bugs.launchpad.net/qemu/+bug/1805256/comments/14 | 14:18 |
| ubottu | Launchpad bug 1805256 in qemu (Ubuntu) "qemu-img hangs on high core count ARM system" [Medium,In progress] | 14:18 |
| rafaeldtinoco | if you want to read and review findings | 14:18 |
| rafaeldtinoco | if it makes sense etc | 14:18 |
| rafaeldtinoco | but only if you have extra time what you might not | 14:18 |
| rafaeldtinoco | i think we are missing "volatile" keyword | 14:18 |
| rafaeldtinoco | for some local variables being read_once() | 14:18 |
| rafaeldtinoco | :) | 14:18 |
| rafaeldtinoco | optimization made XOR instruction 0x1 always | 14:18 |
| rafaeldtinoco | when it might be 0x0 | 14:18 |
| rafaeldtinoco | changed by other thread | 14:18 |
| enyc | Hrrrrrrrm, anybody give me a $clue why ubuntu's libgnutls28-dev in 14/16/18.04 LTS seems to WORK for modern TLS negotiation with 'tf5' package client built against libgnutls-openssl-dev , whereas debian's similar libgnutls28-dev doesn't work right .... I may track down EVENUTALYL but wondered if anybody was aware that ubuntu patched gnutls defaults for openssl-header apps or | 14:27 |
| enyc | what-have-you! .... | 14:27 |
| rafaeldtinoco | cpaelzer: does qemu build ok in arm64 ? (ask you because of s390 firmware cross compilation thing) | 14:32 |
| rafaeldtinoco | how can I bypass the s390 stuff and still generate the builds ? | 14:33 |
| cpaelzer | rafaeldtinoco: you only need the arch part and not the indep part | 14:33 |
| cpaelzer | rafaeldtinoco: see the targets in d/rules | 14:33 |
| rafaeldtinoco | #) alright | 14:33 |
| rafaeldtinoco | yep yep | 14:33 |
| rafaeldtinoco | tks | 14:33 |
| cpaelzer | by design/chance indep today is run on x86 on LP and happens to work | 14:33 |
| cpaelzer | this and a few other packages would break if that would be different | 14:34 |
| cpaelzer | which is why the s390x bits use cross compile | 14:34 |
| rafaeldtinoco | gotcha | 14:34 |
| cpaelzer | the x86 bits of indep should use cross as well, then they would work everywhere | 14:34 |
| ahasenack | slashd: hi, is https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1843032 a duplicate of https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1843036 ? | 14:41 |
| ubottu | Launchpad bug 1843032 in net-snmp (Ubuntu) "Storage graph error" [Undecided,Incomplete] | 14:41 |
| ubottu | Launchpad bug 1843036 in net-snmp (Ubuntu Disco) "[regression] SNMP missing disks in hrStorageTable" [High,Fix committed] | 14:41 |
| slashd | ahasenack, yeah look like this bug is related to the regression I fixed (now found in -proposed) | 14:49 |
| ahasenack | slashd: ok, I'll point the user that way | 14:50 |
| slashd | ahasenack, tks | 14:50 |
| bryce | vorlon, I gathered from lp #1842969 that the django version should be removed? I filed #1843355, but wanted to get your confirmation on this course of action before proceeding. | 15:37 |
| ubottu | Launchpad bug 1842969 in python-django (Ubuntu) "python-django 2.2.4 not for eoan" [Undecided,Confirmed] https://launchpad.net/bugs/1842969 | 15:37 |
| vorlon | bryce: the block-proposed bug was filed to make sure it didn't accidentally make it into the eoan release, but post-eoan we would want the package still be in -proposed so that it can be released once its revdeps are sorted, without there having to be a new version uploaded to unstable | 16:00 |
| vorlon | ... in practice there has been a new version uploaded to unstable | 16:01 |
| vorlon | so we could just remove it | 16:01 |
| vorlon | and close the blocking bug | 16:01 |
| bryce | vorlon, ok, what can I do to help with removing it? | 16:07 |
| tpokorra | I am trying to request a sync of mono-complete from Debian unstable to Ubuntu. Now it seems that mono-complete lives from eaon in Universe, but I don't know how to specify that in the requestsync command. I tried: requestsync -d sid mono-complete "eoan universe" | 16:13 |
| cjwatson | tpokorra: you don't need to specify universe | 16:13 |
| tpokorra | cjwatson, but it tells me it is a new package then | 16:13 |
| tpokorra | https://packages.ubuntu.com/de/eoan/mono-complete says it is in universe | 16:14 |
| cjwatson | shouldn't - what's the full output? | 16:14 |
| cjwatson | oh, that's a binary package name | 16:14 |
| cjwatson | requestsync works on source package names | 16:14 |
| cjwatson | the source package name is 'mono' | 16:14 |
| cjwatson | tpokorra: ^- | 16:14 |
| cjwatson | also see https://bugs.launchpad.net/ubuntu/+source/mono/+bug/1841784 | 16:15 |
| ubottu | Launchpad bug 1841784 in mono (Ubuntu) "Update to 6.0.0.319 not this cycle" [Wishlist,Triaged] | 16:15 |
| cjwatson | ah, though that's for a newer version than is in unstable | 16:15 |
| tpokorra | cjwatson, yes. your hint with the package name solves my issue | 16:15 |
| tpokorra | yes I would like to get the latest version from unstable, with a little patch, into Ubuntu | 16:16 |
| cjwatson | looks like a reasonable set of changes to me | 16:19 |
| cjwatson | request the sync and I'll ack it | 16:19 |
| tpokorra | cjwatson, that would be great. somehow it is missing the dfsg-5.changelog, but there is only dfsg-4 in unstable | 16:21 |
| tpokorra | perhaps I need to wait, it is only since yesterday | 16:21 |
| cjwatson | tpokorra: it's recent enough that you'll have to wait a bit, yes | 16:21 |
| tpokorra | ok. I will come back soon :) | 16:21 |
| tpokorra | thanks you very much for your help, cjwatson! | 16:22 |
| cjwatson | will work as soon as https://launchpad.net/debian/+source/mono shows -5 | 16:22 |
| tpokorra | cjwatson, it seems that dsfg-4 has already been submitted to branch eoan-proposed. https://code.launchpad.net/~usd-import-team/ubuntu/+source/mono/+git/mono/+ref/ubuntu/eoan-proposed | 16:35 |
| tpokorra | so is the sync already happening? | 16:35 |
| doko | sforshee, apw: are riscv64 builds broken with 5.3? LP: #1843458 | 16:35 |
| ubottu | Launchpad bug 1843458 in cross-toolchain-base-ports (Ubuntu) "linux 5.3 breaks building glibc for riscv64" [High,Confirmed] https://launchpad.net/bugs/1843458 | 16:35 |
| rbasak | +1 for iptables revert FWIW. It's the job of the distribution to coordinate, and having it move "by accident" and then scramble is hardly coordination. | 16:38 |
| WoC | Which card would you recommend for OpenCL that has drivers that actually work and won't rape my wallet? pcie x16 | 16:48 |
| ahasenack | cjwatson: hi, openssh showed up in our server page as being stuck in migration: | 16:53 |
| ahasenack | openssh-server/amd64 unsatisfiable Depends: runit-helper (>= 2.8.14~) | 16:53 |
| ahasenack | that package is in universe | 16:53 |
| ahasenack | + dh-runit (>= 2.8.8), <-- was added in 8.0p1-5 | 16:53 |
| ahasenack | LocutusOfBorg: ^ you synced that from debian this past weekend? | 16:56 |
| WoC | Captain Picard, greetings;) | 16:58 |
| LocutusOfBorg | ahasenack, already discussed and MIR opened for runit... | 17:01 |
| ahasenack | LocutusOfBorg: ok, it showed up in our list at https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#ubuntu-server | 17:02 |
| ahasenack | LocutusOfBorg: https://bugs.launchpad.net/ubuntu/+source/dh-runit/+bug/1843236 right? | 17:02 |
| ubottu | Launchpad bug 1843236 in dh-runit (Ubuntu) "[MIR] runit-helper" [Undecided,New] | 17:02 |
| Odd_Bloke | WoC: Hi, this channel is for the development of Ubuntu itself, so isn't the right forum for that question. Perhaps try in #ubuntu? (I would also ask you to reconsider casual use of language pertaining to sexual assault, as a matter of basic decency.) | 17:14 |
| WoC | K ty | 17:14 |
| stgraber | xnox, juliank: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1843468 | 17:56 |
| ubottu | Launchpad bug 1843468 in iptables (Ubuntu) "nftables based iptables wrapper break userspace" [Critical,Triaged] | 17:56 |
| ahasenack | bryce: hi, I just filed https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1843474 which affects us too | 18:13 |
| ubottu | Launchpad bug 1843474 in fetchmail (Ubuntu) "/usr/bin/fetchmailconf not completely removed" [Undecided,New] | 18:13 |
| bryce | ahasenack, ok | 18:26 |
| juliank | Thanks stgraber | 19:09 |
| rbasak | I just saw wireguard enter eoan-proposed \o/ | 19:31 |
| sarnold | woot; do you know off-hand if we're getting the kernel config turned on too? | 19:39 |
| * rbasak doesn't know | 19:50 | |
| ahasenack | bryce: so about that horde error, | 20:14 |
| ahasenack | I found this: | 20:14 |
| ahasenack | /usr/share/php/Horde/Test/Case.php:class Horde_Test_Case extends PHPUnit\Framework\TestCase | 20:14 |
| ahasenack | that's where that class is being defined | 20:14 |
| bryce | ahasenack, right | 20:14 |
| ahasenack | yet I still got | 20:14 |
| ahasenack | /tmp/autopkgtest.y3OCQg/phpunit-stderr:PHP Fatal error: Uncaught Error: Class 'Horde_Test_Case' not found in /tmp/autopkgtest.y3OCQg/build.dRo/real-tree/Horde_Text_Filter-2.3.6/test/Horde/Text/Filter/LinkurlsTest.php:11 | 20:14 |
| bryce | ahasenack, what I found is if I added a require Horde/Test/Case.php; at the top of the file, then that error would be resolved (I guess?) | 20:15 |
| ahasenack | does this fail with php 7.2? | 20:15 |
| ahasenack | do we know that? | 20:15 |
| bryce | ahasenack, however then I got a slew of errors with all the other tests, that Horde_Text_filter not found | 20:15 |
| bryce | checking... | 20:16 |
| * ahasenack checks last green | 20:16 | |
| bryce | looks like it has been failing since before the transition | 20:17 |
| ahasenack | it passed with phpunit 7.5.3 | 20:17 |
| ahasenack | we now have 7.5.6 | 20:17 |
| bryce | yes you're right, phpunit all 7.5.3-1 | 20:18 |
| ahasenack | php-horde-test was the same | 20:18 |
| ahasenack | 2.6.3+debian0-3ubuntu1 | 20:19 |
| ahasenack | that's what is defining that class | 20:19 |
| bryce | phpunit_renamed_phpunit_classes.patch has: | 20:24 |
| bryce | -class Horde_Test_Case extends PHPUnit_Framework_TestCase | 20:24 |
| bryce | +class Horde_Test_Case extends PHPUnit\Framework\TestCase | 20:24 |
| bryce | ahasenack, aha think I know what needs done | 20:26 |
| bryce | (wish we had a better tool for managing trigger tweaks...) | 20:26 |
| ahasenack | what is it? | 20:26 |
| ahasenack | and that \ hurts my eyes, no idea what is going on with that replacement | 20:27 |
| bryce | the \ is php's namespacing mechanism | 20:27 |
| bryce | so it's moving from a simple class named "PHPUnit_Framework_TestCase" in the top level namespace, to a class called TestCase inside the Framework namespace, which is itself under PHPUnit | 20:28 |
| bryce | ahasenack, I've queued up -ansel/amd64 to test my theory, if it works I'll rebuild the rest | 20:30 |
| ahasenack | ok | 20:30 |
| ahasenack | bryce: by "queued", do you mean uploaded, or added as a test trigger or something? | 20:39 |
| ahasenack | this thing is failing in debian ci as well | 20:40 |
| ahasenack | also an error about an unknown class, just not the same one | 20:40 |
| ahasenack | bryce: the green runs of php-horde-ansel are using libapache2-mod-php7.3, whereas the red one is using libapache2-mod-php7.2 | 20:48 |
| ahasenack | libapache2-mod-php comes from php-defaults | 20:49 |
| ahasenack | the only red in php-defaults is our friend php-horde-text-filter | 20:50 |
| bryce | ahasenack, sorry, 'triggered' I suppose is the better term | 20:59 |
| bryce | ok looks like the test worked, I'll trigger the rest | 21:02 |
| bryce | interestingly, even though I only ran -ansel/amd64, everything switched to green which is weird, but I think false positive | 21:04 |
| ahasenack | bryce: hope it's better by tomorrow :) | 21:23 |
| ahasenack | I'm eod'ing, cya | 21:23 |
| bryce | cya | 21:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!