[07:45] <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, ^^
[08:24] <seb128> could people stop doing retries on duplicity/ppc64el build? it's not going to work, the tests need to be fixed
[09:58] <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:59] <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
[10:00] <cpaelzer> what makes this more awkward in .code32 the pushl/popl (32bit) seem to be working
[10:35] <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:36] <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:37] <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:38] <cpaelzer> rafaeldtinoco: https://community.arm.com/developer/tools-software/oss-platforms/f/dev-platforms-forum/5316/issue-with-stxr-in-armv8
[10:39] <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:40] <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:56] <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:57] <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:58] <rafaeldtinoco> and then a brunch if not success, got this
[11:25] <rafaeldtinoco> omg, armv8 docs have ~4pages for unpredictable errors for ldxar<->stlxr combination
[11:25]  * rafaeldtinoco goes for a coffee
=== 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}
[12:37] <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:38] <ahasenack> php7.2-dev is in main, for example
=== ricab is now known as ricab|lunch
[12:59] <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
[13:00] <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:01] <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:23] <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:24] <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:25] <ahasenack> ppa at https://launchpad.net/~ahasenack/+archive/ubuntu/squid-ftbfs-glibc-230
=== DarkTrick_ is now known as DarkTrick
[13:34] <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:36] <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:53] <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
=== ricab|lunch is now known as ricab
[14:14] <rafaeldtinoco> HA.. I think I found the issue
[14:14] <rafaeldtinoco> #)
[14:14] <rafaeldtinoco> \o/
[14:17] <rafaeldtinoco> cpaelzer: nm on 1:1, ill let u free
[14:17] <rafaeldtinoco> :o) I have to test a few things now
[14:18] <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:27] <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:32] <rafaeldtinoco> cpaelzer: does qemu build ok in arm64 ? (ask you because of s390 firmware cross compilation thing)
[14:33] <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:34] <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:41] <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:49] <slashd> ahasenack, yeah look like this bug is related to the regression I fixed (now found in -proposed)
[14:50] <ahasenack> slashd: ok, I'll point the user that way
[14:50] <slashd> ahasenack, tks
[15:37] <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
[16:00] <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:01] <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:07] <bryce> vorlon, ok, what can I do to help with removing it?
[16:13] <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:14] <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:15] <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:16] <tpokorra> yes I would like to get the latest version from unstable, with a little patch, into Ubuntu
[16:19] <cjwatson> looks like a reasonable set of changes to me
[16:19] <cjwatson> request the sync and I'll ack it
[16:21] <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:22] <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:35] <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:38] <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:48] <WoC> Which card would you recommend for OpenCL that has drivers that actually work and won't rape my wallet? pcie x16
[16:53] <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:56] <ahasenack> LocutusOfBorg: ^ you synced that from debian this past weekend?
[16:58] <WoC> Captain Picard, greetings;)
[17:01] <LocutusOfBorg> ahasenack, already discussed and MIR opened for runit...
[17:02] <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:14] <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:56] <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]
[18:13] <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:26] <bryce> ahasenack, ok
[19:09] <juliank> Thanks stgraber
[19:31] <rbasak> I just saw wireguard enter eoan-proposed \o/
[19:39] <sarnold> woot; do you know off-hand if we're getting the kernel config turned on too?
[19:50]  * rbasak doesn't know
[20:14] <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:15] <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:16] <bryce> checking...
[20:16]  * ahasenack checks last green
[20:17] <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:18] <bryce> yes you're right, phpunit all 7.5.3-1
[20:18] <ahasenack> php-horde-test was the same
[20:19] <ahasenack> 2.6.3+debian0-3ubuntu1
[20:19] <ahasenack> that's what is defining that class
[20:24] <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:26] <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:27] <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:28] <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:30] <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:39] <ahasenack> bryce: by "queued", do you mean uploaded, or added as a test trigger or something?
[20:40] <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:48] <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:49] <ahasenack> libapache2-mod-php comes from php-defaults
[20:50] <ahasenack> the only red in php-defaults is our friend php-horde-text-filter
[20:59] <bryce> ahasenack, sorry, 'triggered' I suppose is the better term
[21:02] <bryce> ok looks like the test worked, I'll trigger the rest
[21:04] <bryce> interestingly, even though I only ran -ansel/amd64, everything switched to green which is weird, but I think false positive
[21:23] <ahasenack> bryce: hope it's better by tomorrow :)
[21:23] <ahasenack> I'm eod'ing, cya
[21:43] <bryce> cya