=== deltab_ is now known as deltab [04:15] doko: thanks for the info, I thought I checked all new things (the gtk change brought a lot), will take a look at capstone if it will be a MIR or a drop of the Dep [04:19] ok checked, I'll do both after breakfast === maclin1 is now known as maclin === maclin1 is now known as maclin === maclin1 is now known as maclin [08:20] doko, boost1.67 is accepted in debian, should i be preparing and uploading boost-defaults update? === maclin1 is now known as maclin [09:58] xnox: yes please, the tracker already is there. please wait with the binNMUs for the gcc-defaults upload [10:08] doko, ok, will do that. [11:30] bdmurray, doko: apport's tests eventually passed after several retries [11:42] ginggs: the failing tests have a timeout() and so, are racy IMHO [11:43] ginggs: bug #1780767 [11:43] bug 1780767 in apport (Ubuntu) "Some tests are flaky due to timeout" [Undecided,New] https://launchpad.net/bugs/1780767 === abeato_ is now known as abeato [16:08] doko, libquadmath0 is available on ppc64el, but it is not a dependency of libgfortran [16:08] doko, does fortran need to be built with quadmath enabled? or is that not available? [16:09] doko, imho https://paste.ubuntu.com/p/9DtqmSmfqT/ [16:09] note the "without architecutres are on amd64, i386, ppc64el" which imho should be the case across the board for all of these, no? [16:12] hmm, it's enabled ... [16:18] doko, well, in gfortran i see that quadmath usage appears to be guarded with #if defined(GFC_REAL_16_IS_FLOAT128) [16:18] which might be not true on ppc64el or somesuch? [16:19] basically, i looks like i need to redo my meson fix to exclude ppc64el, wince quadmath is available, but currently not in use by libgfortran on ppc64el. [16:20] slangasek, cjwatson We got a wishlist bug in Debian about adding support for zchunk, a chunked compression format thingy to apt. My understanding is that our problem with pdiffs is that we update too ften for them to work, but I just thought zchunk might be something that works for us [16:21] It's what Fedora plans to use for its repo metadata [16:23] It would be complicated since it relies on range requests and stuff [16:23] and I think, us storing the files unmodified and compressed in apt's list dir [16:24] xnox: libgcc-8-dev depends on libquadmath0, but libgfortran doesn't need it apparently [16:26] doko, https://packages.ubuntu.com/cosmic/libgfortran5 [16:26] doko, libquadmath0 (>= 4.6) [amd64, i386] [16:26] doko, or you mean it doesn't need it on ppc64el only? [16:27] It does sound interesting, tough [16:30] xnox: it's linked, but apparently not needed: -lquadmath -lz -lm -Wl,-z -Wl,relro -Wl,-z -Wl,relro -Wl,--version-script=../../../src/libgfortran/gfortran.map -shared-libgcc -Wl,-soname -Wl,libgfortran.so.5 -o .libs/libgfortran.so.5.0.0 [16:30] O_o [16:31] i don't know how to detect this correctly in meson terms; so i'm hardcoding to use -lquadmath with fortran under special flags on ubuntu on intel-only then. [16:31] cause -lquadmath on any arch, unconditionally is then wrong. [18:34] Hey id like to have a page on ubuntu.com scrubbed that contains my contact info. Its cuasing me issues. https://wiki.ubuntu.com/community/Kivi === JanC_ is now known as JanC [19:05] I found bugs in systemd-networkd which breaks DHCPv6 Prefix Delegation. Fixes are easy to patch, is it possible to request to get backported 2 commits from systemd master into ubuntu's packages 237 version? [19:19] I found a bug in systemd causing DHCPv6 Prefix Deletion not to work, is it posible to get commits backported from upstream master to 237 ubuntu package? Small changes needed in order for this to work. [19:20] halvors: take a look at https://wiki.ubuntu.com/StableReleaseUpdates for a guide on getting fixes into a release [19:22] So basically this would take mounths full time to get fixed? [19:22] sarnold: Sadly seems to be so much work that i'm better of just patching it myself and not to share it with the community :( [19:24] sarnold: I'm not an ubuntu developer. [19:25] halvors: One week minimum. [19:25] Not months. [19:25] And really, if you're willing to test, it's just putting patches in a idrectory. [19:25] *directory [19:25] If it get's fixed in debian, will it downstream to ubuntu stable? [19:25] Not to Ubuntu stable. [19:25] tsimonq2: Not patches, links to git commits. [19:26] Are you willing to backport the commits yourself? [19:26] It's not too hard if you know the codebase, I'd say. [19:26] Here's a handy guide: https://raphaelhertzog.com/2012/08/08/how-to-use-quilt-to-manage-patches-in-debian-packages/ [19:26] tsimonq2: I don't know the codebase, i'm as i said not an ubuntu developer. [19:27] halvors: I'm an Ubuntu Developer and I don't know the systemd codebase well. ;) [19:27] It's not a matter of backporting actually, just [19:27] tsimonq2: applying commits to the codebase manually from git upstream? [19:27] Sorta. [19:28] The way we do it is put the patch files in debian/patches and then list the patch files in debian/patches/series. [19:28] All you have to do is get the patch to apply and put a DEP-3 header there. [19:28] That link I pasted earlier has a lot of details. [19:29] I'm willing to help you through submitting a patch through a bug if you can test your changes and do the backporting work :) [19:29] tsimonq2: I'm not familiar with that tool, but i could use dpkg-source --commit as well? [19:29] halvors: I've never used that myself. [19:29] tsimonq2: Nice :) [19:30] tsimonq2: Think that is a tool for adding a patch to /debian/patches after getting source from apt source systemd [19:30] "apt source systemd" command [19:30] Right [19:30] That'll grab the packaging, grab the source, and extract it in a nice way. [19:31] tsimonq2: Will do, just need to get one more fix commited to upstream systemd. [19:32] halvors: OK, feel free to keep in touch with me either here or via tsimonq2@ubuntu.com [19:32] halvors: Thanks for your interest in helping :) [19:33] tsimonq2: Nice :) Ofcourse, really hate experiencing bugs that i know is fixed in upstream version of packages ;) [19:35] halvors: I do too, but there's only so many of us... [19:35] tsimonq2: Yeah.