[01:09] -queuebot:#ubuntu-release- New binary: gcc-9-cross-mipsen [ppc64el] (focal-proposed/universe) [3+c1ubuntu1] (no packageset)
[02:19] -queuebot:#ubuntu-release- Packageset: 6799 entries have been added or removed
[03:05] <handsome_feng> Hi, could someone in release team take a look at those ukui FFEs when you have time before Beta freeze? LP: #1868571 LP: #1868688 , Thanks in advance!
[03:05] <ubot5> Launchpad bug 1868571 in ukui-control-center (Ubuntu) "[FFe] Sync ukui-control-center 2.0.1.1-2 (universe) from Debian unstable(main)" [Undecided,New] https://launchpad.net/bugs/1868571
[03:05] <ubot5> Launchpad bug 1868688 in peony (Ubuntu) "[FFe] Sync peony 2.1.0 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1868688
[05:40] -queuebot:#ubuntu-release- New binary: gcc-9-cross-mipsen [amd64] (focal-proposed/universe) [3+c1ubuntu1] (no packageset)
[06:59] -queuebot:#ubuntu-release- New: accepted gcc-9-cross-mipsen [amd64] (focal-proposed) [3+c1ubuntu1]
[06:59] -queuebot:#ubuntu-release- New: accepted gcc-9-cross-mipsen [ppc64el] (focal-proposed) [3+c1ubuntu1]
[07:16] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (focal-proposed/main) [5.4.0-1006.6] (core, kernel)
[07:25] -queuebot:#ubuntu-release- New binary: gcc-defaults-mipsen [amd64] (focal-proposed/universe) [1.186.1] (no packageset)
[07:30] -queuebot:#ubuntu-release- New: accepted gcc-defaults-mipsen [amd64] (focal-proposed) [1.186.1]
[08:10] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (focal-proposed) [5.4.0-1006.6]
[08:50] <seb128> could someone review/merge https://code.launchpad.net/~seb128/britney/updated-graphite-version/+merge/381225
[08:51] <seb128> updating the i386 graphite hint to the build1 upload done recently
[09:07] <apw> seb128, is that not a candidate for force-reset-test ?
[09:08] <apw> seb128, as i assume we expect it to be bad until it gets better (which may not be expected)
[09:18] <seb128> apw, probably but I don't know how force-reset-test works so I did what I know :-)
[09:19] <seb128> apw, if you want to do the right thing (and tell me how I request a force-reset next itme) that would be welcome
[09:20] <apw> seb128, so it is the exact same syntax so "force-reset-test graphite2/1.3.13-11/i386"
[09:21] <apw> meaning this version marks a new baseline of always-failed, so fail is now acceptable until it succeeds
[09:21] <seb128> ah ok, I didn't know that was in the hints, I though that was a command to give to the state machine or something
[09:21] <seb128> apw, do you want me to update the mp?
[09:21] <apw> seb128, no it is a very new hint type, sure
[09:22] <apw> any kicking-the-can scenario should be consisdered for this
[09:24] <seb128> right, that makes sense
[09:26] <Laney> juliank: weren't you going to write down some documentation for the hint types somewhere?
[09:26] <seb128> are those thin documented... thanks Laney :)
[09:27] <juliank> Laney: hmm yeah
[09:31] <seb128> apw, https://code.launchpad.net/~seb128/britney/updated-graphite-version/+merge/381225 updated to be a foirce-reset-test now
[09:41] <seb128> apw, thanks, can you also merge for me? I don't have the right to push there
[09:42] <apw> seb128, done
[10:06] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (focal-proposed/main) [5.4.0-1007.7] (core, kernel)
[10:06] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (focal-proposed/main) [5.4.0-1006.6] (core, kernel)
[10:10] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (focal-proposed) [5.4.0-1007.7]
[10:10] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (focal-proposed) [5.4.0-1006.6]
[10:10] <seb128> apw, thanks
[10:24] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-94.95] (core, kernel)
[10:24] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1077.82] (kernel)
[10:26] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-94.95] (core, kernel)
[10:41] <doko> Reverse-Depends
[10:41] <doko> * ruby-marisa                   (for libruby2.5)
[10:41] <doko> * ruby-svn                      (for libruby2.5)
[10:41] <doko> * ruby-xapian                   (for libruby2.5)
[10:41] <doko> kanashiro: ^^^
[11:07] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1077.82]
[12:01] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1060.64] (kernel)
[12:03] <kanashiro> doko, those packages are still in proposed, I'll check the autopkgtest failures
[12:27] <kanashiro> doko, src:marisa and src:xapian-bindings just need to retrigger autopkgtest (they were executed against ruby2.5 not ruby2.7), but src:subversion is now blocked because of a src:mercurial failure in armhf
[12:28] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-94.95~16.04.1] (kernel)
[12:28] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-94.95~16.04.1] (kernel)
[12:28] <doko> kanashiro: mercurial fails way too often
[12:33] <kanashiro> doko, already requested retriggers for all of them
[12:46] <ahasenack> hi release team, anyone around? I have an FFe for libcbor, which is being MIRed, and which, together with libfido2 (already uploaded), will unblock openssh
[12:46] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/libcbor/+bug/1868609
[12:46] <ubot5> Ubuntu bug 1868609 in libcbor (Ubuntu) "FFe: update to 0.6.0 (MIR requirement)" [Undecided,New]
[12:55] <ahasenack> sil2100: apw: Laney: if you have a moment please
[13:25] <sil2100> ahasenack: I'll take a look
[13:51] <handsome_feng> Hi, release team, could you take a look at those ukui FFEs when you have time? LP: #1868571 LP: #1868688 , Thanks and sorry for bother.
[13:51] <ubot5> Launchpad bug 1868571 in ukui-control-center (Ubuntu) "[FFe] Sync ukui-control-center 2.0.1.1-2 (universe) from Debian unstable(main)" [Undecided,New] https://launchpad.net/bugs/1868571
[13:51] <ubot5> Launchpad bug 1868688 in peony (Ubuntu) "[FFe] Sync peony 2.1.0 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1868688
[13:52] -queuebot:#ubuntu-release- New source: python-django-pyscss2 (focal-proposed/primary) [3.0.0-0ubuntu1]
[13:52] -queuebot:#ubuntu-release- New source: python-pyscss2 (focal-proposed/primary) [2.0.0-0ubuntu1]
[14:23] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1060.64]
[14:23] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-94.95~16.04.1]
[14:23] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-94.95~16.04.1]
[14:25] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1037.41] (kernel)
[14:25] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1037.41~16.04.1] (kernel)
[14:55] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1037.41~16.04.1]
[14:57] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1037.41]
[14:58] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-94.95]
[14:58] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-94.95]
=== slyon_ is now known as slyon
[15:03] <cpaelzer> apw: sil2100: stgraber: Laney: I wanted to ask if one of you would have time for the qemu portion of the FFe in 1866866
[15:03] <cpaelzer> jfh: ^^ FYI
[15:03] -queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1057.60] (no packageset)
[15:05] <jfh> cpaelzer: I agree, since time is progressing, it would be good to get a decision from the release team on the affected qemu component in LP 1866866
[15:05] <ubot5> Launchpad bug 1866866 in qemu (Ubuntu) "[FFe] Please accept patches for secure guest feature" [High,New] https://launchpad.net/bugs/1866866
[15:07] -queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1057.60]
[15:26] <stgraber> so my personal opinion is that this is way too many changes way too late and that we should not do this
[15:26] <stgraber> but if another release team member wants to go through all the changes and convince themselves that it's safe, I won't stand in the way
[15:39]  * rbasak is looking at the containerd SRU in the Bionic queue
[15:51] <juliank> Laney: Rebuilding focal adt images
[15:51] <Laney> why?
[15:51] <juliank> Laney: because they had an issue and were not rebuild for two weeks, and cause all sort of kmod errors
[15:51] <juliank> Laney: I gotta check why
[15:52] <Laney> yeah, please debug why the daily script isn't working
[15:52] <juliank> Laney: I know we created two servers with the same name, and then it did not know which one to use :)
[15:53] <juliank> Laney: maybe it failed two weeks ago and did not clean up the failed instances
[15:53] <juliank> we'll see
[15:53] <Laney> if that's the case then some robustification is needed
[15:56] -queuebot:#ubuntu-release- Unapproved: accepted containerd [source] (bionic-proposed) [1.3.3-0ubuntu1~18.04.2]
[16:03] <jfh> stgraber: well, I agree that this is late - especially the qemu part - but that is the reason why there is this FFe at all
[16:03] <jfh> the kernel and the s390-tools side of things are done - now qemu is the missing piece ...
[16:04] <jfh> discussions on that started early - but it unfortunately took a while on getting it accepted - the almost all of the ocde is arch specific and is not active by default, an opt in is needed
[16:05] <juliank> Laney: So build-adt-image-all-clouds exits with 0 even if all builds failed
[16:05] <juliank> Laney: That's not super helpful
[16:06] <juliank> Laney: And I'm not sure the create-nova image thingy is failing correctly
[16:06] <juliank> Laney: Certainly setup-testbed is failing, I guess the | ssh pipes exits with 1, and the script is set -e?
[16:06] <juliank> so this needs two things
[16:07] <juliank> (1) build-adt-image-all-clouds needs to fail on failure
[16:07] <juliank> (2) the other thing needs to clean up instances it creates on exit
[16:10] <juliank> I guess for (1) maybe it could just check if the images it's supposed to create exist when it finishes
[16:11] <Laney> I did do some robustness fixes in the wip/mojo-juju-2 branch but I'm not sure how applicable they would be to master
[16:11] <Laney> there it's driven by a systemd unit called 'ensure-adt-image@'
[16:12] <rbalint> ubuntu-archive, please unblock kodi: LP: #1868499
[16:12] <ubot5> Launchpad bug 1868499 in kodi (Ubuntu) " Please remove s390x binaries for 2:18.5+dfsg1-0ubuntu3 with all reverse dependencies" [Undecided,New] https://launchpad.net/bugs/1868499
[16:13] <juliank> Laney: do we have monitoring for that yet?
[16:13] <Laney> for stg?
[16:14] <juliank> because um, we want to get notified about such failures I guess
[16:14] <Laney> or for build-adt-image on prod?
[16:14] <juliank> stg
[16:14] <Laney> ah, no, but as it happens I actually prodded the IS ticket about that today!
[16:14] <juliank> like, it's nice there's a service that fails, but if nothing tells us it's failing we are where we are now :)
[16:15] <juliank> ah good
[16:16] <Laney> If they do what I suggested then we'll get an ubuntu-release.kpi.ubuntu.com grafana thingy to upload metrics into
[16:21] <kanashiro> doko, ahasenack triggered the mercurial autopkgtest for me to make subversion migrate but it still fails, could you please take a look at it since you are the last uploader?
[16:21] <kanashiro> marisa and xapian-bindings already migrated to the release pocket btw
[16:31] <juliank> doko, Laney so we are up-to-date wrt autopkgtest images everywhere except amd64 on lgw which exceeded quotas
[16:32] <juliank> I'll try to run create-nova-image-new-release manually
[16:47] <juliank> take #2
[16:47] <juliank> ugh
[16:47] <juliank> running with -x now
[16:47] <juliank> it failed _somewhere_
[16:49] <juliank> with -x, i should at least know which line it stopped running at
[16:55] <juliank> heisenbug it seems
[16:57] <juliank> doko, Laney images should be fixed now
[18:31] <sforshee> doko, mwhudson: I'm seeing the glibc pwd/tst-getpw test fail in autopkgtest on arm64/armhf, is this a known issue?
[18:50] <ahasenack> ubuntu-archive: hi, if you could please let libcbor0.6 through, it's a new soname, hence the NEW package. FFe bug linked in the changelog
[19:00] <mwhudson> sforshee: i don't think so
[19:03] <sforshee> mwhudson: I'm seeing it when testing the focal-proposed kernel, but looking at the test I think it's unlikely to be a kernel regression
[19:04] <mwhudson> sforshee: well this version of glibc has passed several times: https://autopkgtest.ubuntu.com/packages/glibc/focal/arm64
[19:05] <sforshee> mwhudson: yes, I saw. I tried it on an arm64 box too and it passed with the -proposed kernel, so I'm not sure what to think about it
[19:06] <sforshee> unless it's some weird setup in autopkgtest where there's a user defined for all the ids it's testing
[19:11] <mwhudson> that would be pretty eccentric
[19:12] -queuebot:#ubuntu-release- New sync: gcc-10-cross-mipsen (focal-proposed/primary) [2+c1]
[19:12] <mwhudson> original exit status 223
[19:13] -queuebot:#ubuntu-release- New: accepted gcc-10-cross-mipsen [sync] (focal-proposed) [2+c1]
[19:13] <mwhudson> i wonder if the failing uid checks are setting errno
[19:15] <mwhudson> because 65535 - 30ish valid uids modulo 256==223 is kinda plausible
[19:16] <mwhudson> if only the test logged what errno was :)
[19:20] <mwhudson> sforshee: not sure how to debug this at this distance
[19:21] <mwhudson> sforshee: i guess i can patch the test to be more verbose, upload it, wait for it to build, run the test against my ppa...
[19:21] <mwhudson> alternatively might be able to reproduce in canonistack
[19:21] <sforshee> mwhudson: yeah, I was hoping to be able to reproduce it but no such luck
[19:23] <mwhudson> sforshee: certain people can run things in production infrastructure, i'm not one of them though
[19:24] <sforshee> Laney might be able to help
[19:24] <mwhudson> Laney, vorlon, juliank, none of them are around now i expect
[19:26] <bryce> ubuntu-archive: php7.3 can removed at your convenience - LP: #1869087.  I examined the rdepends and unless I'm doing it wrong there appear to be no rdepends remaining.  I suspect it's good to go at this point.
[19:27] <ubot5> Launchpad bug 1869087 in php7.3 (Ubuntu) "Remove "php7.3" from Focal, which has transitioned to php7.4" [Undecided,New] https://launchpad.net/bugs/1869087
[20:01] <doko> bryce: ta, nice!  can I pester you about the php-mockery autopkg test failures?
[20:05] <doko> php7.3 removed
[20:08] <bryce> doko, thanks, glad to see that gone
[20:09] <doko> could you look at php-mockery?
[20:09] <bryce> doko, hm, what does it need?
[20:10] <doko> ENOCLUE: http://autopkgtest.ubuntu.com/packages/p/php-mockery/focal/arm64
[20:10] <doko> on all archs
[20:10] <doko> Class 'DOMDocument' not found
[20:13] <bryce> doko, offhand that sounds like one of the issues that comes up from the phpunit transition.  I'd suggest retriggering php-mockery with phpunit/8.5.2-1ubuntu1 and sphinx/1.8.5-7ubuntu1
[20:13] <bryce> and maybe php-redis/5.1.1+4.3.0-1 too, looks like that's also in proposed
[20:18] <bryce> doko, if you'd like I can do those retriggers for you?
[20:25] <doko> bryce: now done
[20:36] <ahasenack> doko: are you able to help with a i386 badpkg issue? ruby-zip became a _all.deb in 2.0.0, and it's now failing i386 autopkgtests
[20:36] <ahasenack> we already edded Multi-Arch: foreign to it
[20:36] <ahasenack> no go in the bileto tries
[20:37] <ahasenack> https://bileto.ubuntu.com/excuses/3994/focal.html
[20:37] <ahasenack> is it a case for an all badtest on i386?
[20:37] <doko> ahasenack: no, requires ubuntu-release people
[20:37] <ahasenack> ok
[20:37] <ahasenack> kanashiro: ^
[20:38] <ahasenack> kanashiro: https://launchpad.net/~ubuntu-release/+members#active
[20:38] <kanashiro> all the packages under ruby-zip in excuses page are ignoring failures in i386
[20:39] <ahasenack> kanashiro: maybe prepare a branch in the meantime
[20:40] <ahasenack> to take advantage of timezone
[20:40] <kanashiro> ahasenack, makes sense
[20:46] <ahasenack> kanashiro: do you know where to do that?
[20:47] <kanashiro> ahasenack, hints-ubuntu repo, right? I just need to learn bzr again :)
[20:47] <ahasenack> I know that feeling
[20:47] <ahasenack> there is always a catch, the mp target is not the default
[20:48] <ahasenack> I always go back to an old mp to check
[20:48] <ahasenack> kanashiro: https://code.launchpad.net/~ahasenack/britney/hint-mysql8-arm64/+merge/379582
[20:48] <kanashiro> ahasenack, thanks, appreciated :)
[20:49] -queuebot:#ubuntu-release- Packageset: 6799 entries have been added or removed
[20:49] <ahasenack> if the diff is huge, the target is wrong :)
[20:50] <kanashiro> got it
[20:50] <ahasenack> bryce: was that php7.3?
[20:50] <bryce> ahasenack, sorry?
[20:50] <ahasenack> 6799 entries
[20:51] <ahasenack> don't panic :)
[20:51] <bryce> ah yeah lots of php7.3 packages sprouted daisies today
[20:51] <ahasenack> kanashiro: add a link to our bileto run
[20:52] <ahasenack> kanashiro: I'll leave it be
[20:52] <ahasenack> https://bileto.ubuntu.com/excuses/3994/focal.html
[20:52] <ahasenack> and explain we added multi-arch foreign in that run
[20:52] <kanashiro> ahasenack, ok
[20:52] <ahasenack> checking puppet now
[20:53] <ahasenack> I think it's still the old run
[20:53] <ahasenack> yeah, from 1553 utc
[21:11] <Eickmeyer> Archive Admins: I have an entirely NEW package in queue for Focal that has been sitting for about 3 days now. With Beta fast approaching, can this get pushed though?
[21:11] <kanashiro> ahasenack, here is the MP: https://code.launchpad.net/~lucaskanashiro/britney/hint-ruby-zip-i386/+merge/381275
[21:16] <juliank> sforshee: i retried against release pocket glibc, maybe it fails there too, it's possible something else regressed
[21:16] <juliank> sforshee: Unfortunately I'm out until Monday, so I won't be able to do much else
[21:20] <RAOF> Eickmeyer: that's dragonfly-reverb?
[21:20] <Eickmeyer> RAOF: Yes.
[21:20] <RAOF> I'll look at it this morning.
[21:21] <Eickmeyer> Sounds good. :)
[21:30] <ahasenack> sil2100: upstream libcbor released 0.6.1 with the soname change we adopted in 0.6.0
[21:31] <ahasenack> I'll see to it tomorrow
[21:31] <Ukikie> xnox: Thanks for asking #debian-ftp about the license issue.
[22:00] <mwhudson> https://code.launchpad.net/~mwhudson/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/381277 if there's a release team person around
[22:57] <RAOF> Eickmeyer: Why are you never uploading simple packages? 😛
[22:58] <Eickmeyer> RAOF: Ha! Believe it or not, this was one of the "simpler" ones. :P
[22:59] <Eickmeyer> You should've seen me a year ago with lsp-plugins.
[23:01] <RAOF> Maybe could the audio upstreams embed fewer fonts as strings in their C++ source files?
[23:03] <Eickmeyer> Sure would be nice, but I think people are paranoid about not having a "consistent" look by relying on a font as a dependency.
[23:04] <RAOF> Because I'm not sure whether doing that with an OFL font actually passes copyright muster?
[23:05] <Eickmeyer> I'm pretty sure it does. Not the first time NotoSans has distributed with a package.
[23:05] <RAOF> (One of the OFL clauses is “you cannot distribute a derivative under any other license”, which might be problematic)
[23:05] <RAOF> Could they just, you know, copy the font file to a known location and then load that?
[23:05] <RAOF> 🤷
[23:06] <Eickmeyer> I think when it comes to that, a derivitive of the font isn't what's being distributed. It's the actual font.
[23:06] <RAOF> It's absolutely clear that distributing NotoSans-Regular.ttf is fine by the license.
[23:07] <RAOF> It's less clear that taking NotoSans-Regular.ttf, encoding it as a char const*, embedding it in the output and then distributing that output is fine by the license.
[23:08] <RAOF> (Also, NotoSans_Regular.ttf.cpp is not exactly the preferred form of modification 😛)
[23:09] <Eickmeyer> Are they actually modifying the font itself?
[23:11] <RAOF> I don't know. I don't know how they've generated NotoSans_Regular.ttf.cpp (it does not appear to be generated by any of the build scripts?)
[23:12] <Eickmeyer> As I look at the file, it seems to just be the font renamed, but I could be wrong.
[23:12] <RAOF> Unless you mean modified in the copyright sense, then, yes, they have: they've taken the binary bytes of the .ttf file and encoded them as `0x…` hex in the cpp file.
[23:13] <RAOF> The cpp file is undoubtedly a derivative of the font file.
[23:13] <Eickmeyer> That's not good. I'll have to inform upstream.
[23:15] <RAOF> Well, “undoubtedly” is maybe a bit strong. I strongly suspect that it is, but I don't know, because I don't know what it's content is, other than 2MB of char const*.
[23:15] <RAOF> I'm just assuming based on the filename and variable name that it's an encoding of NotoSans-Regular.ttf ;)
[23:15] <Eickmeyer> Yeah, hard to tell.
[23:16] <Eickmeyer> I'm looking at their github issues to see if they have an open/closed issue about it, and there doesn't appear to be.
[23:16] <Eickmeyer> I can ask someone.
[23:18] <RAOF> I'll keep reviewing the package, but I'd need to ask around on the team before accepting it with this font weirdness.
[23:20] -queuebot:#ubuntu-release- New binary: what-is-python [amd64] (focal-proposed/main) [3] (no packageset)
[23:22] <RAOF> Huh. Why do the binary packages Provide: lv2-plugin, vst-plugin, etc?
[23:23] <Eickmeyer> RAOF: Because they are lv2 plugins and vst plugins. That can be removed, if necessary. You'd find that common in a lot of audio plugin packages.
[23:24] <Eickmeyer> Also, a bit of an answer on the Noto Sans issue: it might be actually Apache licensed?
[23:24] <Eickmeyer> RAOF: per https://fonts.google.com/specimen/Noto+Sans
[23:26] <Eickmeyer> RAOF: Here's how the .cpp file is generate: `xxd -i common/NotoSans/NotoSans-Regular.ttf`
[23:26] <Eickmeyer> We could, theoretically, patch to remove the file and regenerate it using debian/rules, but I feel like that's reinventing the wheel.
[23:27] <RAOF> We'd only do that if we were going to use the archive version of NotoSans rather than the shipped version.
[23:28] <Eickmeyer> Is that necessary?
[23:32] <Eickmeyer> RAOF: Per the Linux Audio Developers (#lad): xxd would qualify as a rather strict form of not being modified, it almost modifies the font data less than including it in an email attachment.
[23:38] <RAOF> It doesn't really matter whether or not the font is modified; the OFL is perfectly happy for you to modify the font.
[23:38] <Eickmeyer> Ok
[23:38] <RAOF> The question is whether embedding the font in the binary this way makes the binary a derivative of the font.
[23:39] <Eickmeyer> In the opinion of those I've talked to, the answer is no.
[23:40] <RAOF> Really? I'm not a lawyer by any means, but “thing is literally copied into your binary” seems pretty open-and-shut that you binary is a derivative work?
[23:41] <Eickmeyer> I'm asking.
[23:44] <Eickmeyer> RAOF: Per Dr. Robin Gareus (one of the main developers behind Ardour and x42-plugins): it's like statically linking against a lib. the compound inherits the license.derivative, no. compound, yes
[23:45] <RAOF> What does compound mean in this case? Because statically linking a lib definitely makes you a derivative work by the AA's understanding of copyright.
[23:46] <RAOF> (That's why the copyright of the libraries you use matters at all, as opposed to the “mere aggregation” involved in shipping a CD with a bunch of binary packages on it)
[23:47] <Eickmeyer> Audio plugins use static-linked libraries all the time as it's standard/commond practice when developing audio plugins. You'll see the same thing in x42-plugins.
[23:48] <RAOF> Yeah, that's fine. And they're derivative works of those libraries.
[23:48] <RAOF> Because the licenses are compatible.
[23:48] <RAOF> But the OFL's license states that you can only distribute derivatives under the OFL.
[23:48] <Eickmeyer> So, I've been linked to this particular entry of the OFL FAQ: https://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL-FAQ_web#2a57c6bb
[23:49] <Eickmeyer> I'm not 100% that's the question here though.
[23:50] <RAOF> Yeah, that's not quite the question.
[23:50] <RAOF> This would be 100% fine if they were shipping NotoSans_Regular.ttf.
[23:51] <RAOF> I'm not sure if it's still fine if they take NotoSans_Regular.ttf, and then embed it in their binary.
[23:52] <Eickmeyer> Look at the next question down (1.21). I think that's what is relevant here.
[23:53] <Eickmeyer> RAOF ^
[23:54] <RAOF> Maybe?
[23:55] <RAOF> I did see that; if anything, that suggests that maybe they should be renaming the fonts?
[23:56] <Eickmeyer>  "Alternatively if you directly add a font under the OFL to the font folder of your firmware without modifying or optimizing it you are simply bundling the font like with any other software collection, and do not need to make any further changes."
[23:56] <RAOF> Right, but that's what they're not doing.
[23:56] <Eickmeyer> It is what they're doing, if it's going unmodified into a .cpp file.
[23:57] <RAOF> They're not shipping it in a font folder (which I agree would be totally fine).
[23:57] <RAOF> Is a .cpp file a font folder? 😛
[23:58] <RAOF> It's not; they're (very slightly) changing the format, and it's now not separable from the binary.
[23:59] <Eickmeyer> That was just an example. The principle is shipping it unmodified inside a binary, such as firmware.