[01:11] <arraybolt3> OK, this may be a bit overkill for copyright file checking, but I'm using exiftool on image files to extract copyright and license info from them. Apparently there are a couple of files in lxqt-runner that include an embedded color profile that is copyrighted by HP, but no licensing information is included in the exiftool output. Do I pursue finding the license info, or is this a standard
[01:11] <arraybolt3> piece of data that I can just safely ignore copyright considerations with?
[01:12] <arraybolt3> This is actually somewhat important as the ICC profile apparently comes from Adobe Photoshop despite the fact that it is copyrighted by HP.
[01:12] <arraybolt3> And the license, https://www.adobe.com/support/downloads/iccprofiles/icc_eula_win_end.html, is not DFSG-compatible.
[01:13] <arraybolt3> The two offending files are lxqt-runner-1.2.0/vbox-icons/state_running_16px.png and lxqt-runner-1.2.0/vbox-icons/vrdp_16px.png.
[01:15] <arraybolt3> Both of them are extremely tiny (16x16, I believe) icon files.
[01:16] <arraybolt3> Meh, I think I'm answering my own question here. I should probably strip the ICC profile from both files, manually repack the tarball, and file a bug report.
[01:16] <sarnold> won't the images look all funny afterwards?
[01:17] <arraybolt3> Good question, only one way to find out :D
[01:17] <arraybolt3> Perhaps there's an open source ICC profile that can replace it.
[01:17] <arraybolt3> (FWIW no other image file in the whole entire repo has an ICC profile, and there are quite a few image files in it.)
[01:18] <arraybolt3> Yeah, GIMP has a builtin sRGB profile.
[01:20] <sarnold> doesn't the profile represent the monitor where the image was manipulated?
[01:21] <arraybolt3> I think so.
[01:21] <arraybolt3> I'm not entirely sure how all this works :P all I know is we have a potentially non-DFSG-compliant ICC profile in our repo and it. Must. Get. Out.
[01:48] <arraybolt3> Currently my wonder is if it's legal to just convert the profile rather than stripping it.
[01:48] <arraybolt3> Looks like I can.
[12:54] <adrien> is anyone around interested in ocaml? I'm asking now specifically due to the number of ocaml packages that show up in the excuses list (I haven't looked if these are simply going to migrate by themselves; there was maybe a new compiler version)
[13:17] <adrien> can someone re-trigger https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=arm64&package=ocaml-sedlex&trigger=ocaml-sedlex%2F3.0-1build1 ?
[13:21] <adrien> while I'm at it, can someone also re-trigger https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=s390x&package=gsasl&trigger=gnutls28%2F3.7.8-5ubuntu1 and https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=apt&trigger=gnutls28%2F3.7.8-5ubuntu1 ? thanks
[14:26] <schopin> adrien: done.
[14:33] <adrien> thanks!
[18:48] <danilogondolfo> Anybody available to review and sponsor a merge? https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2008123
[18:48] -ubottu:#ubuntu-devel- Launchpad bug 2008123 in curl (Ubuntu) "Please merge 7.88.1-1 into lunar" [Undecided, New]
[23:30]  * mwhudson glares at https://autopkgtest.ubuntu.com/packages/u/ubuntu-image/lunar/amd64
[23:31] <mwhudson> jawn-smith: do you know what's going on here?
[23:33] <bdmurray> Oh, I did see some of those timing out the other day
[23:34] <mwhudson> yeah passing in 30mins to failing in 3h30 is some kind of change
[23:34] <mwhudson> not unprecendented but something definitely seems to have gotten worse around the 16th
[23:48] <arraybolt3> Could someone trigger an autopkgtest retry for me ? https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=apport&trigger=qterminal%2F1.2.0-2ubuntu1
[23:48] <arraybolt3> (Currently holding up QTerminal, but there's no reason any change made should cause an apport regression AFAIK.)
[23:50] <bdmurray> done
[23:50] <arraybolt3> Thanks!