[07:49] tjaalton, https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/tree/8 merge request here please? [07:49] if they are in llvm-toolchain-snapshot, nice, so we don't have to keep them around on more branches [07:50] LocutusOfBorg: ok, will do [07:50] tjaalton, if you have them, please double check if they aren't in the one that is going uploaded probably today [07:50] https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/commit/42b7383d1a6f8b5df0a7e960a17bb5230ffec61f [07:50] 8.0 stable is out... [07:51] https://github.com/llvm/llvm-project/releases/tag/llvmorg-8.0.0 maybe your patches are already there [07:51] so we can just sync [07:58] LocutusOfBorg: they are these https://github.com/intel/opencl-clang/tree/ocl-open-80/patches/clang [07:58] I was told they were not queued for 8 [08:27] LocutusOfBorg: where do I get the tarball? [09:00] tjaalton, I guess when sylvestre uploads it [09:00] let me ask [09:46] oSoMoN: could you have a look at the libreoffice/s390x autopkg test failure? triggered by openjdk-8 (which isn't even installed in the test) [09:47] doko, looking [09:49] jdstrand, iptables still looks like it's unhapy, firewalld tests with 1.8.2-4ubuntu1 [09:49] autopkgtest firewalld[1362]: ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.8.2 (nf_tables): [09:49] line 4: RULE_REPLACE failed (No such file or directory): rule in chain INPUT [09:49] line 4: RULE_REPLACE failed (No such file or directory): rule in chain OUTPUT [10:10] doko, that looks like a flaky test, it previously failed with the same error on 2019-03-12 02:37:15 UTC, and was then retried by j_bicha and passed, I will need to look into that more closely but for now I just retried it [10:12] oSoMoN: I already did, but maybe you have better luck ;p [10:19] doko, yeah, I saw you had retried already, fingers crossed this time it passes [11:39] LocutusOfBorg: they applied on top of rc5, so I sent the merge request already [11:52] merged thanks [12:14] cool, thanks! === ricab is now known as ricab|lunch [13:39] juliank, seb128: i finalized the switch of lp:software-properties to git [13:39] i'm in the process of updating the precise and trusty git branches with synthetic commits [13:40] tjaalton, uploading right now [13:44] LocutusOfBorg: sweet [13:45] let me know if it works, next upload in debian will be syncable thanks to you :) [13:46] I think you should join the team, llvm and graphic people have a lot in common! [13:46] (I mean, you need patches mostly each llvm release) [13:46] btw next time please also update changelog in the merge request [13:49] well actually I rarely need patches, this was an exception :) [13:49] llvm upstream is a mystery, would be nice to have relnotes for point-releases for starters [14:02] rbalint, great, thx [14:05] thanks rbalint [14:24] rbasak: does debian's ci also trigger dep8 tests on reverse dependencies, like we do? Do you know? [14:26] I think so, but am not sure. [14:32] https://ci.debian.net/status/ is nice === ricab|lunch is now known as ricab [15:29] rharper: have you ever seen anything like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925126 on Ubuntu? [15:29] Debian bug 925126 in bcache-tools "bcache-tools: Load bcache kernel module *before* registering device" [Important,Open] [15:29] Apparently RUN{builtin} and RUN are separate lists in udev and ordering isn't guaranteed; the reporter is hitting the wrong ordering. [15:29] rbasak: I've not seen that before [15:31] I suspect that the normal path is that the initramfs will load the bcache module (even if the race still exists) [15:32] rbasak: I would be interested in confirmation of the run order [15:32] that does seem like lots of things could break (not just bcache) [15:34] rbasak: hello, if you have a chance today we'd like to see if we can get nova and swift into bionic-proposed for bug 1818069 [15:34] bug 1818069 in swift (Ubuntu Bionic) "[SRU] queens stable releases" [High,Triaged] https://launchpad.net/bugs/1818069 [16:18] doko: hi, does this ring a bell? [16:18] doko: Can't exec "gcc": No such file or directory at /usr/share/perl5/Dpkg/Arch.pm line 126. [16:18] doko: -: warning: cannot determine CC system type, falling back to default (native compilation) [16:18] started happening in a test [16:19] https://pastebin.ubuntu.com/p/H55y8JcMVw/ [16:22] it's not what failed the test, though [16:31] ahasenack: probably gcc is not installed [19:55] Snapcraft Live! starts in about 5 minutes - https://www.youtube.com/watch?v=X_U-pcvBFrU [23:08] tjaalton: intel-mediasdk appears to use the embedded googletest/googlemock source. [23:19] tjaalton: debian/copyright is incorrect; a bunch of files under samples/ are 3-clause BSD (copyright claims them as MIT), a handful of files (eg: wayland-drm-client-protocol.h) are neither BSD nor MIT and don't have their licence recorded in debian/copyright. [23:37] tjaalton: Possibly we should split contrib/ipp out and have an actual intel-performance-primitives library, but we don't currently have one. [23:37] tjaalton: A quick codesearch shows that there are at least 6 packages in Debian that would use an ipp library if it existed, so maybe it's time to bite that particular bullet? [23:40] if a package is 3.0 native format do you still use quilt patches to patch it, or is there a different mechanism for making changes? [23:40] (package in question is in universe but still a valid question)