[00:51] <teward> i think i discovered an evil in the tar package in Bionic, in that later gitbuildpackage pristine-tar generated items with Tar 1.30+ fail to work with < 1.30
[00:51] <teward> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897653 is the relevant report in Debian, just hit this for something that the STudio team is working on
[00:51] <ubottu> Debian bug 897653 in tar "tar 1.30 breaks pristine-tar" [Grave,Fixed]
[00:52] <Unit193> I have 1.30+dfsg-5, it would seem.
[00:54] <cjwatson_> From that bug it looks more like we need to upgrade pristine-tar a bit (>=1.44 maybe?)
[00:55] <cjwatson_> Oh also tar 1.30 isn't in bionic I see
=== cjwatson_ is now known as cjwatson
[00:55] <bryce> we ran into that tar / pristine-tar incompatibility too
[00:55] <bryce> our packages set up with pristine tar on eoan couldn't be built on bionic
[11:22] <xnox> ginggs:  it's not just the resourcewarnings, which are harmless there are really test case failures with 3.7 and 3.8 too, which appear to be triggered with a rebuild.
[11:22] <xnox> ginggs:  note that autopkgtest, with patched testsuite against previous build passed locally for me =)
[11:23] <xnox> ginggs:  it's all forwarded upstream, opened an issue and a pull request with CI changes to show the issue.
[11:23] <xnox> mwhudson:  pyfffffffffftw does use dask
[11:28] <ginggs> xnox: thanks
[11:37] <xnox> ginggs: mwhudson: i'm not sure, but dask might be passing under python3.8 but not under python3.7
[11:42] <ginggs> Testing with python3.8
[11:42] <ginggs> = 6312 passed, 395 skipped, 32 xfailed, 4 xpassed, 20 warnings in 810.41 seconds =
[11:43] <ginggs> Testing with python3.7
[11:44] <ginggs> = 6317 passed, 390 skipped, 32 xfailed, 4 xpassed, 20 warnings in 855.78 seconds =
[11:46] <xnox> hm
[11:46] <xnox> so no failed with either?!
[11:47] <ginggs> looks that way, but this is dask itself
[11:49]  * xnox just read "Error: Quosures can only be unquoted within a quasiquotation context." in the autopkgtest of r-cran-sf and I think I need more coffee. This is worse than ruby's twiddle-wakka and python's walrus operators
[11:49] <xnox> ah
[11:49]  * xnox was in pyfftw contex
[11:49]  * xnox was in pyfftw context
[11:51] <xnox> nah, pyfftw really fails with python3.8
[11:52] <ginggs> xnox: did you see pyfftw armhf fails in other exciting ways? probably #917095
[11:59] <xnox> ginggs:  lovely
=== ricab is now known as ricab|lunch
=== dannf` is now known as dannf
=== ricab|lunch is now known as ricab
[14:48] <mdeslaur> tseliot_: hi! I'm looking at bug 1852315...it seems those three CVEs are for the vGPU software...is that actually packaged in our driver packages? is it the same thing?
[14:48] <ubottu> bug 1852315 in nvidia-graphics-drivers-435 (Ubuntu Eoan) "CVE‑2019‑5696 5697 5698" [Undecided,New] https://launchpad.net/bugs/1852315
[16:46] <teward> can anyone assist the Studio team with an oddness?  They've got a lintian ERROR which triggers a fail on an unsafe symlink which they've tried to adjust/patch the change in here in their repository, but dpkg-source barfs.  They are trying to change a symlink's target by editing a symlink, not sure if there's a workaround for that.  As such, however, I can't sign/build/upload the code that Eickmeyer wants uploaded (raysession).
[16:47] <teward> if anyone has a few moments to poke and see if they can eve do their symlink patch fix, that'd be great.  https://code.launchpad.net/raysession is where the code is, everything's in master (and you can get the pristine-tar for 0.8.1 but you'll need tar >= 1.30 to make it work)
[16:48] <teward> cjwatson: if we backport 1.30 into Bionic it'd work, I think.  I did this backport from Eoan in a PPA and made it work for pristine-tar in Bionic.  So the issue is the tar package :P  (wrt the tar version and pristine-tar)
[16:49] <teward> i'm still working on the whole Backports thing with Laney but that's a task for 2020 at this point - helping Studio during dev cycle's taking a bunch of my cycles.  Also working with a few clients as a consultant on things :P
[16:50] <cjwatson> raysession could fix up the symlink in debian/rules build and restore it to the as-in-orig-tarball state in debian/rules clean.  That's the usual workaround for this sort of thing.
[16:50] <teward> Eickmeyer: ^
[16:51] <cjwatson> Or even just put the right thing in place after the upstream 'make install' or equivalent runs, depending on whether it's used during build.
[16:52] <cjwatson> In fact in that case you could just use dh_link to do it.
[16:53] <cjwatson> Haven't looked at this package in any detail, but that's the general range of options available.
[16:56] <Eickmeyer> cjwatson, teward: Thanks. Honestly, not sure how to do that. Do I make a debian/raysession.links and use dh_install_override to remove the bad link?
[16:56] <cjwatson> dh_link removes anything that's already there all by itself
[16:56] <Eickmeyer> cjwatson: Ok, excellent. I'll go that route then. Thanks!
[16:57] <cjwatson> np
[16:57] <teward> thanks cjwatson
[16:57] <teward> as for the pristine-tar issue the issue DOES trace back to `tar` unless we need to patch gbp / pristine-tar, but simply backporting tar seemed to fix my issues.