=== infinity0 is now known as Guest60030 === infinity0_ is now known as infinity0 === el is now known as hel === hel is now known as el [08:33] infinity: the only armv8 server soc i'm aware you can actually buy right now doesn't implement aarch32 though [08:33] unless i'm confused about one or more things [08:53] Now that the bionic archive is open for development, has the automatic sync of packages from Debian started? I see a couple, like https://tracker.debian.org/pkg/eclipselink, which doesn't seem to have synced a newer version. [08:54] I suppose bionic might sync from testing instead of unstable since its a planned LTS, but the newer version of eclipselink is available in testing too. [08:58] hjd: autosync won't be enabled until after we've finished a manual transition or two. [08:59] hjd: It'll be Soon(tm). [09:07] infinity: Ok, sounds good :) Got disconnected for a second there, but got your soon(tm) message. Will check back later. [11:41] infinity, do you have any clue about what toolchain change might have regressed casablanca testsuite on arm64 and ppc64el but not elsewhere? [11:41] https://launchpad.net/ubuntu/+source/casablanca/2.10.0-1~build1 [11:41] I tried the old version and fails too... [11:42] http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ [11:42] this is where they took the code [11:55] LocutusOfBorg: Not sure off the top of my head. Could be the switch in the combination of gcc-7 and glibc-2.26 to use float128, which would give higher precision, and mess people up who are making precision assumptions. [12:29] infinity, debian has older glib and it failed there too https://buildd.debian.org/status/fetch.php?pkg=casablanca&arch=arm64&ver=2.10.0-1~exp1&stamp=1509122627&raw=0 [12:29] I think I'll disable that test for now [12:29] if you agree [13:40] this'll sound like a stupid question, but I assume that we're able to upload to Bionic now? [13:40] push updates and such, that sort of thing? [13:41] (I'm not awake yet hence asking) [13:50] yes but please don't upload unless you're awake 😉 [13:52] :P [13:52] jbicha: i'm awake enough to know when i have a package ready to push in to update nginx :P [13:52] i'm also sufficiently awake to communicate in a coherent manner. [13:53] Can't say anything about my mannerisms if someone decides to make my life hell, had to deal with noisy neighbors partying until after 1AM and as such I didn't sleep very well [13:53] the party stopped when the police I called came by and shut it down, but... [13:53] still doesn't mean I slept well. [13:54] new nginx should have TLS 1.3 support so yay from me :) [13:54] jbicha: if and only if OpenSSL has the support [13:55] we'd need latest OpenSSL for that, and I'm not sure what the state of that is. [13:55] oh [13:55] jbicha: remember that NGINX just interacts with the SSL libraries available for it at compile time [13:55] whether that be OpenSSL or LibreSSL or some other library alternative that NGINX works with. [13:56] in our case, it's OpenSSL, so I'd have to ask mdeslaur or the Security team what the state of the OpenSSL transition is, if there's gonna be one. [13:56] just like Apache too, if Apache code had TLS1.3 support, but OpenSSL was, say, Xenial's version, it'd not have TLS1.3 [13:57] yeah, the transition might be after bionic (chaotic, if you will…) [13:57] jbicha: yeah, when the OpenSSL transition happens, either everything'll need a build rerun, or I'll have to add a build-only version bump to force an nginx rebuild [13:58] though by that point, I'd expect there to be yet another NGINX update I"d have to push [13:59] my guess is that a full rebuild run will be run against the OpenSSL transition to find what builds and what doesn't. [14:01] https://release.debian.org/transitions/html/openssl1.0-rm.html [14:09] jbicha: yeah, that's an evil sign ain't it. [14:09] jbicha: i know that mdeslaur and others had held back on OpenSSL migration for some time but not sure what the state is still [14:10] i could ask but I don't care at the moment :) [18:15] hi all [18:16] Is this the right channel to ask to sync a debian package's version? [18:26] joelkraehemann: yes, but you can also run the syncpackage script from ubuntu-dev-tools to file a bug that sponsors will see [18:27] jbicha: great thank you [18:27] https://tracker.debian.org/pkg/gsequencer [18:27] Where can I read more about the process of getting a sponsor? [18:28] https://wiki.ubuntu.com/SponsorshipProcess [18:28] you are awesome [18:29] https://launchpad.net/ubuntu/+source/gsequencer [18:29] ^^ there was once an old package [18:31] What version of ubuntu should I use to build the package? [18:31] 17.10? [18:33] if synced, it will end up in bionic (18.04) [19:01] jbicha: I think people with sponsoring need need to use requestsync, not syncpackage [19:02] Correct, juliank. [19:02] joelkraehemann: ^ [19:04] Good to know [19:04] I just compile the source code on ubuntu [19:05] and run the integration tests [19:05] note: they are disabled on debian [19:08] ^^ by a patch [19:39] all tests passed [20:01] https://bugs.launchpad.net/ubuntu/+source/gsequencer/+bug/1728294 [20:01] Launchpad bug 1728294 in gsequencer (Ubuntu) "Sync gsequencer 1.1.4-1 (universe) from Debian unstable (main)" [Undecided,New] [20:02] Just recognized that there was introduced ld --as-needed [20:03] Might be I am going to use it [20:03] , too [20:04] Note you should consider running functional tests in order to use this flag [20:12] just commented what I was telling you [20:44] zul, jamespage: Is it OK to sync python-os-api-ref and python-pbr from Debian? The current versions are incompatible with Sphinx 1.6 and blocking its migration. [20:44] Otherwise please merge them, because I could not figure out what delta needs to be kept.