| === opal changed the topic of #ubuntu-devel to: .-. | ||
| === opal changed the topic of #ubuntu-devel to: (. .)__,') | ||
| === opal changed the topic of #ubuntu-devel to: / V ) | ||
| === opal changed the topic of #ubuntu-devel to: \ ( \/ Lovelypenisbird | ||
| === opal changed the topic of #ubuntu-devel to: `._`._ \ =============== | ||
| === opal changed the topic of #ubuntu-devel to: 8===<<==`'==D | ||
| === Unit193 changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of trusty-artful | #ubuntu-app-devel for app development on Ubuntu | ||
| tsimonq2 | tjaalton: When you get the chance, could you please do a review of this? https://salsa.debian.org/xorg-team/debian/xorg/merge_requests/2 I'd like it to land for 18.04, and imho it qualifies as a bugfix. | 05:34 |
|---|---|---|
| tjaalton | tsimonq2: you need to rebase with current git, which added the changes from latest upload.. | 05:35 |
| tsimonq2 | tjaalton: Sure. | 05:36 |
| tsimonq2 | tjaalton: Done. | 05:39 |
| alkisg | flexiondotorg: the file /usr/share/mate/desktop-directories/mate-network.directory is not localized in 32bit builds. Everything else is properly localized, including that same file in 64bit builds. Would that be a MATE issue, or an issue with the builders langpack mangling? | 07:47 |
| alkisg | I.e. the Applications > Internet menu is not localized to "Διαδίκτυο" specifically on 32bit builds... | 07:48 |
| flexiondotorg | alkisg: I'd have to have a poke around and see where that translation comes from. | 07:49 |
| * alkisg checks the mate-menus source code... | 07:50 | |
| alkisg | Everything seems fine, trying to build locally to see if the result is fine too (which would mean the problem is in the builders...) | 08:00 |
| alkisg | Everyone, flexiondotorg: I rebuilt mate-menus locally, and /usr/share/mate/desktop-directories/mate-network.directory is indeed properly localized. So I believe the problem is in the builders. | 08:17 |
| alkisg | The two related build logs are: | 08:22 |
| alkisg | 32bit: https://launchpadlibrarian.net/356151086/buildlog_ubuntu-bionic-i386.mate-menus_1.20.0-0ubuntu1_BUILDING.txt.gz | 08:22 |
| alkisg | 64bit: https://launchpadlibrarian.net/356151076/buildlog_ubuntu-bionic-amd64.mate-menus_1.20.0-0ubuntu1_BUILDING.txt.gz | 08:22 |
| alkisg | Both say "Merging translations into mate-network.directory."... it might be a race condition somewhere in the builders tools... could someone issue a rebuild, to test? | 08:23 |
| flexiondotorg | Thanks for the feedback alkisg. | 08:47 |
| alkisg | np, thanks for all the hard work | 08:48 |
| rbasak | tsimonq2: thank you for the update. That's very helpful. | 09:46 |
| === mhcerri_ is now known as mhcerri | ||
| LocutusOfBorg | infinity, the problem for openshot is pkgbinarymangler, specifically dh_builddeb. I can say, doing a mv dh_builddeb.pkgbinarymangler to dh_builddeb makes the problem disappear /cc tsimonq2 alkisg | 11:10 |
| LocutusOfBorg | I'm doing some perl debug, but I don't speak perl :p and it is a 20 lines of stuff, should be somewhat easy to trace it down | 11:11 |
| alkisg | LocutusOfBorg: thanks; I found another unrelated issue with the builders, i.e. localization of some failing failing randomly, see above, I don't know if you're the correct person for this or if I should file a bug, and where, in soyuz...? | 11:11 |
| alkisg | *of some files | 11:11 |
| cjwatson | alkisg: if parallelisation is causing random failures, that's a bug in the package | 11:12 |
| alkisg | cjwatson: in the mate-menus package itself, or in some of the packages that take care of localization like intltool etc? | 11:12 |
| cjwatson | if you file a bug against anything Launchpadish then I shall reassign it :) | 11:12 |
| cjwatson | alkisg: probably in mate-menus itself, but I haven't looked deeply | 11:13 |
| cjwatson | it could serialise the relevant bits of its build to avoid invoking the tools in question in parallel | 11:13 |
| alkisg | cjwatson: thank you, at least that means that whatever issue won't be widespread | 11:13 |
| alkisg | flexiondotorg: please see above ^, I'll file a bug report in mate-menus as well | 11:13 |
| cjwatson | alkisg: you can probably reproduce it locally with sbuild -j4 or similar | 11:14 |
| alkisg | Gotcha, I'll try it | 11:14 |
| cjwatson | (maybe with a few attempts, since it's no doubt racy) | 11:14 |
| alkisg | flexiondotorg: https://bugs.launchpad.net/ubuntu/+source/mate-menu/+bug/1752063 | 11:25 |
| ubottu | Launchpad bug 1752063 in mate-menu (Ubuntu) "Random localization issues probably due to build parallelization" [Undecided,New] | 11:25 |
| alkisg | Meh, that should be mate-menus, not mate-menu, I thought I changed that :/ | 11:25 |
| LocutusOfBorg | infinity, cjwatson, can you please give me a quick perl hint? seb128 ? | 11:26 |
| LocutusOfBorg | https://paste.ubuntu.com/p/55qsWdj2tf/ | 11:26 |
| alkisg | Fixed | 11:26 |
| LocutusOfBorg | the problem of the spurious /foo installed inside the rootfs comes from this line | 11:26 |
| LocutusOfBorg | my $dir = tempdir( CLEANUP => 1 ); | 11:26 |
| LocutusOfBorg | this creates a /temp directory that goes into the final package... | 11:27 |
| LocutusOfBorg | maybe the dh_builddeb is called *before* deleting it? | 11:27 |
| cjwatson | LocutusOfBorg: what's the full source package name - openshot-qt? | 11:29 |
| alkisg | cjwatson: yes, e.g. https://packages.ubuntu.com/bionic/all/openshot-qt/filelist => /v8QpiHa9tC/xb59dA3xKQ | 11:30 |
| cjwatson | LocutusOfBorg: (I have some theories but I want to check a bit before confusing other people with them) | 11:30 |
| LocutusOfBorg | cjwatson, yes, for the first answer | 11:30 |
| LocutusOfBorg | race condition seems not, because it is fully reproducible, every-single-time | 11:31 |
| LocutusOfBorg | i added an rmdir but I don't know if this is the best thing to do :p | 11:31 |
| cjwatson | almost certainly not | 11:34 |
| LocutusOfBorg | yes, it isn't working | 11:34 |
| cjwatson | give me a minute to download this thing :) | 11:34 |
| LocutusOfBorg | sure, I don't want to steal too much of your time ;) | 11:34 |
| LocutusOfBorg | BTW NO_PKG_MANGLE=1 makes no difference, just to avoid some time | 11:36 |
| cjwatson | so the problem is that openshot-qt/debian/rules exports TMPDIR, which means that File::Temp creates the temporary directory/file inside debian/openshot-qt/, while ordinarily it'd be in /tmp or similar | 11:38 |
| LocutusOfBorg | LOL | 11:39 |
| cjwatson | give me a moment to work out a reasonable workaround | 11:39 |
| LocutusOfBorg | damn, I even read the rules file, but I couldn't find it :/ | 11:39 |
| cjwatson | is pkgbinarymangler in git these days? | 11:40 |
| * cjwatson fails to find it | 11:41 | |
| cjwatson | LocutusOfBorg: OK, anyway, I think https://paste.ubuntu.com/p/YXq2mKkwfF/ is probably the right fix | 11:42 |
| cjwatson | LocutusOfBorg: maybe with a comment to explain that this is in order to ignore any setting of TMPDIR in the environment | 11:42 |
| LocutusOfBorg | can I upload then? I'll give you credits in the changelog, of course :) | 11:43 |
| cjwatson | LocutusOfBorg: be my guest, assuming it works - I haven't tested this at all | 11:44 |
| * LocutusOfBorg is already testing | 11:44 | |
| cjwatson | beyond checking that File::Spec->tmpdir's value isn't conditional on $TMPDIR | 11:44 |
| cjwatson | interesting subtle bug though | 11:46 |
| alkisg | I think I've seen 5-6 files in / in the past as well, but I haven't bothered reporting them at that time... so it might have affected more packages in the past | 11:47 |
| cjwatson | could be from the same thing, could be something else; I've seen ad-hoc bugs with that symptom | 11:47 |
| cjwatson | wouldn't be a bad idea to scan Contents though | 11:47 |
| Laney | https://perldoc.perl.org/File/Spec.html says it looks at TMPDIR | 11:49 |
| cjwatson | $ TMPDIR=/ perl -MFile::Spec -le 'print File::Spec->tmpdir' | 11:50 |
| cjwatson | /tmp | 11:50 |
| cjwatson | odd | 11:50 |
| LocutusOfBorg | it is not fixing... | 11:51 |
| Laney | needs to be writable I think | 11:51 |
| cjwatson | oh yes | 11:51 |
| cjwatson | bah | 11:51 |
| cjwatson | probably best to just hardcode DIR => '/tmp' then | 11:51 |
| LocutusOfBorg | my $dir = tempdir( DIR => '/tmp', CLEANUP => 1 ); | 11:52 |
| cjwatson | yep | 11:52 |
| cjwatson | with a comment of course | 11:52 |
| * LocutusOfBorg checks | 11:52 | |
| LocutusOfBorg | # avoid using default TMPDIR because it might be used already by debian/rules | 11:52 |
| LocutusOfBorg | # package file, and point to a wrong location | 11:52 |
| LocutusOfBorg | this is what I wrote | 11:53 |
| LocutusOfBorg | do we run lintian over the archive? such files are spot by this tag https://lintian.debian.org/tags/file-in-unusual-dir.html | 11:53 |
| LocutusOfBorg | https://codesearch.debian.net/search?q=TMPDIR+path%3Adebian%2Frules%24 | 11:54 |
| LocutusOfBorg | lots | 11:54 |
| cjwatson | I not systematically AFAIK | 11:55 |
| cjwatson | s/^I // | 11:55 |
| LocutusOfBorg | tsimonq2, alkisg we should be finally good in two hours :) | 12:08 |
| === mwsb is now known as chu | ||
| tjaalton | LocutusOfBorg: do you maintain virtualbox? | 12:37 |
| s1aden | slangasek: https://github.com/psifidotos/Latte-Dock/issues/884 what's your preferred solution? | 12:44 |
| s1aden | slangasek: the font is being runtime loaded, and doesn't appear to be being derived-from | 12:45 |
| === s1aden is now known as sladen | ||
| sladen | slangasek: ie. is it the linking. Or is it OPL is non-free and needs to go in multiverse? | 12:45 |
| sladen | slangasek: (in which case can go in a separate package, and the app can fallback to $any cursive looking font, or serif | 12:46 |
| tsimonq2 | sladen: I'm the uploader for that; he rejected it last night on those grounds. | 13:26 |
| sladen | tsimonq2: well, lets try and find out the hard facts from slangasek, then everyone is in a better situation to have a discussion and see what the solutions might be | 13:28 |
| tsimonq2 | sladen: Works for me. | 13:28 |
| tsimonq2 | rbasak: Nice, I'm glad the update was useful | 13:29 |
| tsimonq2 | LocutusOfBorg: \o/ | 13:29 |
| xnox | tsimonq2, what does the reject email say? | 13:32 |
| tsimonq2 | xnox: "Source embeds and uses at runtime a GPL-incompatible (OPL-licensed) font; needs an upstream license exception statement or a patch to not special-case the font" | 13:32 |
| xnox | ah, i see the issue on github now. | 13:32 |
| xnox | tsimonq2, tah. | 13:32 |
| tsimonq2 | There's also https://marc.info/?l=kde-devel&m=151973598814829&w=2 | 13:32 |
| xnox | tsimonq2, yeah, he is wrong. | 13:38 |
| tsimonq2 | xnox: Steve or Jon? | 13:39 |
| xnox | tsimonq2, riddell | 13:39 |
| tsimonq2 | xnox: OK; how so? | 13:39 |
| xnox | tsimonq2, GPL does not discriminate against binary blobs that are loaded by the program, and thus linked into it at runtime. same as dlopening() libssl, needs a GPL openssl linking exception. | 13:40 |
| tsimonq2 | xnox: ah ok | 13:41 |
| xnox | tsimonq2, the request here is not to drop the usage of the font, but to provide linking exception, to state that it is not the intention of Latte-Dock to upconvert the OPL font into a GPL thing and force the font to be released under GPL. Thus, we, Latte Dock are gpl, but gpl should not apply to the font we load. | 13:41 |
| tsimonq2 | xnox: OK, I'm not an expert here but that sounds sane :) | 13:43 |
| sladen | xnox: can you help me understand this 'linking to a font' bit | 14:56 |
| sladen | xnox: (ideally with a comparison to what eg. Inkscape does) | 14:57 |
| alkisg | (02:08:20 μμ) LocutusOfBorg: tsimonq2, alkisg we should be finally good in two hours :) ==> yey! much appreciated! :) | 15:02 |
| === mhcerri_ is now known as mhcerri | ||
| LocutusOfBorg | tjaalton, yep | 15:12 |
| tjaalton | LocutusOfBorg: the dkms doesn't build with 4.15 | 15:13 |
| tjaalton | or at least seems not | 15:14 |
| xnox | sladen, inkscape / evince load all/any system fonts, for display of a document / editor; and they do so optionally, if a particular document needs it or a user chooses a particular content. | 15:20 |
| xnox | sladen, that dock, appears to require and load a specific font, and dynamically create and render, the UI components of the application using a specific free-but-license-incompatible font. | 15:21 |
| sladen | xnox: how can the code be changed so that situation (1) is absolutely clear? | 15:23 |
| xnox | sladen, e.g. all .svg / .png shipped in an app, must be free and license compatible, with the app that uses said icons. That's why e.g. we had to remove skype logo icons from many packages from the archive in th epast. so it is not without the presedence. | 15:23 |
| xnox | sladen, use a free font; use a default system/toolkit font; without specifying one. | 15:23 |
| xnox | sladen, add a license exception. | 15:23 |
| xnox | sladen, make it such that, a particular font, is neither preferred nor required. | 15:24 |
| sladen | xnox: well, lets try and find a clear example/solution that doesn't require adding a licence-exception, otherwise we're going to have an enormous amount of archive work to remove/fix other applications, eh? | 15:24 |
| sladen | xnox: so, focusing on the exact problem | 15:25 |
| xnox | sladen, you are extrapolating. most apps do not do what this app does. | 15:25 |
| sladen | xnox: right, so focusing on this exact problem | 15:25 |
| xnox | sladen, it's like github.com loading a custom proprietary webfont, to load all the icons as text. Such that all the UI of github.com is completely unusable, if one blocks loading their proprietary webfont =/ | 15:25 |
| sladen | xnox: how do we make this application do what "most apps do" ? | 15:25 |
| xnox | sladen, sorry, i'm not going to code that app, as i'm busy with other things. I gave you specific guidance "use a free font; use a default system/toolkit font; without specifying one." is that not sufficient for you? | 15:26 |
| sladen | xnox: not convinced that is the case here... sounds like "extrapolating" | 15:26 |
| xnox | sladen, most apps do not reference, nor ship, nor embedd license incompatible fonts. | 15:26 |
| sladen | xnox: this is not sufficient information. hence asking for me | 15:27 |
| xnox | as part of the combined work. | 15:27 |
| xnox | nor via dependencies. | 15:27 |
| sladen | xnox: and trying to understand what *exactly* is trigging the issue (ie. what is the issue, precisely) | 15:27 |
| sladen | xnox: my understanding is that the rejection came from slangasek. So it would be interesting to learn what information you have, and whether it is the same understanding as slangasek (who made the rejection), or another opinion (which may/may not be the same) | 15:28 |
| xnox | sladen, license incompatibility of the combined work which is consists of two things licensed under a free license. | 15:28 |
| sladen | xnox: yes, and we work very very hard together on licencing and what is compatible (which is also different in Debian and Ubuntu) | 15:28 |
| xnox | sladen, i have no information, but i simply, independently came to the same conclusion. | 15:28 |
| sladen | xnox: right | 15:28 |
| sladen | tsimonq2: sounds like we need to wait for slangasek | 15:29 |
| xnox | sladen, look, the package claims to be GPL, yet it ships ./shell/package/contents/fonts/tangerine.ttf which is not gpl, and uses that to render itself in | 15:29 |
| xnox | ./app/packageplugins/shell/dockpackage.cpp: package->addFileDefinition("tangerineFont", QStringLiteral("fonts/tangerine.ttf"), i18n("Tangerine Font")); | 15:30 |
| xnox | ./app/dockcorona.cpp: QFontDatabase::addApplicationFont(kPackage().filePath("tangerineFont")); | 15:30 |
| sladen | xnox: yes. | 15:30 |
| xnox | sladen, but Latte-Dock are not copyright holders, and cannot relicense tangerine.ttf from OFL -> GPL. | 15:30 |
| sladen | xnox: can't see anything here that is proposing to relicense a font from *OPL* to GPL | 15:30 |
| tsimonq2 | sladen: No problem | 15:30 |
| xnox | sladen, instead they should sate, in the License file "everything is covered by gpl, but we allow linking OFL fonts and our GPL code, does not affect nor change license of the loaded tangerine.ttf" | 15:30 |
| xnox | s/sate/state/ | 15:31 |
| sladen | xnox: (Open Font License != Open Public Licence) | 15:31 |
| xnox | sladen, this is the same bullshit, as including embeded copy of openssl, dropp-in SSL license text, and shipping the whole tarball as GPL. | 15:31 |
| xnox | sladen, the bit that matter is that GPL is more restrictive than OFL, and that one is not allowed to relicense OFL as GPL. | 15:31 |
| xnox | sladen, and pretending life is wonderful because openssl license is included in the tarball. | 15:32 |
| sladen | xnox: still can't see any proposal to relicence anything from either Open Font License (OFL), nor Open Public License (OPL) to GPL | 15:32 |
| xnox | sladen, please read the text of GPL. | 15:32 |
| sladen | xnox: I suspect many of us have, many times. Is there a particular font which is specifically relevant here, and which does not apply to all other applications dynamically loading non-code assets | 15:33 |
| sladen | s/particular font/particular part/ | 15:33 |
| xnox | sladen, in ./Latte-Dock/COPYING stating that these terms apply to everything in this tarball, and things that are linked.... of which the included .ttf font is one of the things. | 15:33 |
| xnox | sladen, .ttf font in this case, is no different from a glade ui xml file. | 15:34 |
| sladen | xnox: so debian/copyright needs adjusting/clarifying? | 15:34 |
| xnox | sladen, no, because the upstream states that "You may modify your copy or copies of the Program or any portion | 15:35 |
| xnox | of it, thus forming a work based on the Program, and copy and | 15:35 |
| xnox | distribute such modifications or work under the terms of Section 1 | 15:35 |
| xnox | above" | 15:35 |
| xnox | sladen, the upstream, need to change their copying text to give a linking exception. | 15:35 |
| sladen | xnox: with hard information to go back to upstream, I'm sure this can be clarified | 15:36 |
| xnox | sladen, saying that the GPL terms imposed by Latte-Dock on the programm, do not include imposing these terms on the .ttf font. | 15:36 |
| xnox | sladen, a debian maintainer, is not docker-latte copyright holder, and thus cannot change the terms of the whole upstream release. | 15:36 |
| sladen | xnox: yes. we know that | 15:37 |
| xnox | sladen, debian maintainer, can only create a +dfsg tarball, exclude the font, and patch the software to not load said font. | 15:37 |
| sladen | xnox: and normally we collectively communicate and forth any clarifications or problems, once they are understood | 15:37 |
| xnox | as it is clear that Latte-Dock is not copyright holder of the ttf font, and is wrongly trying to impersonate the original copyright holder of the font, and incompatibly relicense it. | 15:38 |
| sladen | xnox: this this case, the precise issue of an application (any GPL application) causing a non-code asset to be loaded does not appear yet understood | 15:38 |
| sladen | xnox: which makes it difficult to go back to upstream (or ask anyone else to go back to upstream) with a request for clarification | 15:38 |
| xnox | there are softare, the very permissive licenses, that do allow relicing. ANd e.g. there are forks of such codes embedded in gpl software, with forks becoming gpl-only. | 15:38 |
| * sladen can't see any proposals to do any relicensing | 15:40 | |
| sladen | xnox: the application runs fine with the .ttf deleted/not present => not dependency | 15:40 |
| xnox | sladen, no. just because an app loads with broken icons, doesn't mean that the icons shipped in the package can be of an incompatible license. | 15:41 |
| xnox | sladen, "can't see any proposals to do any relicensing" -> you do understand the terms of GPL, right? and how GPL poisoning works? | 15:42 |
| sladen | xnox: hopefully. But always interesting to learn more, particularly in respect of the exact, precise, situation under discussion so that it is realistic to make a proposal/recommendation to pass on to others to pass on to upstream | 15:43 |
| xnox | sladen, please explain to me how GPL license poisoning works / copyleft? | 15:43 |
| sladen | xnox: what precisely would you like to know/ | 15:45 |
| xnox | sladen, I created a software tarball and release it under gpl v2, which includes a patched Apache v2 subcomponent. Can I do it? and under what terms? | 15:46 |
| xnox | Apache v2 is quite a permissive license. | 15:47 |
| sladen | xnox: are the copyright holder of all the code, and/or hold a CLA from the copyright holder of all the code? | 15:49 |
| xnox | sladen, i am copyright hold of my software tarball, the patch to the apache v2 subcomponenet, but not the original subcomponenet code which i got externally without cla. | 15:50 |
| xnox | (software tarball aka everything else) | 15:50 |
| cjwatson | As I understand it the point here is that the font is more intimately associated with the program than is usual for fonts: this specific font is used for a *functional* purpose rather than being an interchangeable choice of text rendering, and so the argument is that it must be distributable under the terms of the GPL. | 15:51 |
| cjwatson | (I haven't looked into this example in any detail, but the two of you seem to be talking past each other.) | 15:51 |
| xnox | ./app/packageplugins/shell/dockpackage.cpp: package->addFileDefinition("tangerineFont", QStringLiteral("fonts/tangerine.ttf"), i18n("Tangerine Font")); | 15:51 |
| xnox | ./app/dockcorona.cpp: QFontDatabase::addApplicationFont(kPackage().filePath("tangerineFont")); | 15:51 |
| cjwatson | (I'm also not sure I necessarily agree, but I think this is what xnox is arguing ...) | 15:52 |
| xnox | $ find . -name tangerine.ttf | 15:52 |
| xnox | ./shell/package/contents/fonts/tangerine.ttf | 15:52 |
| xnox | cjwatson, (yes) | 15:52 |
| xnox | or, instead of distributing under the terms of the GPL, an exception granted, which is easier to do. | 15:53 |
| cjwatson | Right, relicensing is only one of several ways to cure an unsatisfied requirement to distribute a component of a work under the terms of the GPL. | 15:54 |
| sladen | changing the licence (adding an exception) requires going back to the upstream original author with a clear request/proposal for clarification. Equally with a better understanding of the precise concern, some alternative can likely be suggested/recommend/proposed | 15:55 |
| sladen | in this case it would be just to nuke the font from the tarball, as it appears to serve no functional purpose of the licence is clearly being mis-represented | 15:56 |
| sladen | s/of the licence/and the licence/ | 15:56 |
| xnox | sladen, the same terms apply to containment/package/contents/icons/splitter.png as they do for containment/package/contents/ui/ParabolicManager.qml containment/package/contents/images/panel-west.png and icons/org.kde.latte.plasmoid.svg and shell/package/contents/fonts/tangerine.ttf because that is what the header of ./app/packageplugins/shell/dockpackage.cpp requires and ellaborated in ./COPYING | 15:57 |
| xnox | sladen, if you understand what license terms containment/package/contents/icons/splitter.png should be compatible with, you can extend what license terms the rest of files must be compatible with. | 15:58 |
| LocutusOfBorg | tjaalton, I know... is 4.15 planned for bionic? | 16:34 |
| LocutusOfBorg | anyhow, I'll fix in case | 16:34 |
| xnox | LocutusOfBorg, as in the kernel? we are already at 4.15.... | 16:35 |
| LocutusOfBorg | xnox probably some minor update broke it | 16:36 |
| LocutusOfBorg | virtualbox-guest, 5.2.6, 4.15.0-10-generic, x86_64: installed (WARNING! Diff between built and installed module!) | 16:38 |
| LocutusOfBorg | E: not installed | 16:38 |
| LocutusOfBorg | mmmm maybe something different? | 16:38 |
| LocutusOfBorg | apw, might be the usual "hey kernel already has the same version, don't install it" issue, in that case ignoring the test would be fine | 16:40 |
| tjaalton | LocutusOfBorg: that's why the autopkgtest failed :) | 16:53 |
| LocutusOfBorg | so, apw please ignore the results! | 17:00 |
| jbicha | cjwatson: wgrant: it looks like LP stopped importing Debian unstable uploads on Sunday, don't know if it's on Debian's end or LP | 17:01 |
| cjwatson | jbicha: Well, we did move the importer to another machine because the original one ran out of space, but I thought it had been tested. Let's see | 17:02 |
| tjaalton | LocutusOfBorg: hmm sorry, so it actually did build | 17:03 |
| cjwatson | ah, debmirror is sad, let's see what's going on there | 17:03 |
| cjwatson | jbicha: Can't quite tell from the current logs, unfortunately. I've committed a more helpful error message upstream and asked for that to be cowboyed so that I can see what the problem is | 17:16 |
| tjaalton | sigh, installed my laptop with luks root and a separate /boot which for some reason is just 200MB.. how impossible is it to resize the luks root? | 18:15 |
| tjaalton | found some docs | 18:17 |
| rbasak | luks is quite resizeable | 18:17 |
| rbasak | The header at the start is agnostic of the partition's size IIRC | 18:17 |
| rbasak | So it's the same as resizing a partition without luks | 18:17 |
| rbasak | Make the partition bigger, luksOpen it, and ask the filesystem to grow | 18:18 |
| tjaalton | I need to shrink, but looks like it's not much different | 18:18 |
| rbasak | Yeah it's basically the same in reverse | 18:18 |
| rbasak | You just need to know the size of the LUKS overhead to know how much to finally shrink the partition by. | 18:18 |
| rbasak | It might be easier (safer) to make the filesystem much smaller, make the partition a little smaller, and then ask the filesystem to resize to the size of the available space again. | 18:19 |
| tjaalton | hmm, actually it's probably easier to shrink the windows partition :P | 18:19 |
| alkisg | tjaalton: resizing the start of a windows partition is ricky; resizing the end isn't :) From a lot of personal experience. | 18:20 |
| tjaalton | yeah, looks like it went well.. don't dare to boot until I have a usb stick handy :P | 18:26 |
| slangasek | sladen: my preferred solution is for upstream to explicitly state "yes, we think it's ok to ship this as a binary, even though the GPL doesn't unambiguously allow that". Yes, this is a "linking" question. The GPL doesn't care about dynamic vs static linking, and it doesn't care if the bits you're pulling in are C code or something else; if you make your work rely on that object, and you do not | 18:42 |
| slangasek | have the same distribution rights on that object that the GPL requires you to have for the work as a whole, the GPL does not give permission to distribute the binaries | 18:42 |
| slangasek | sladen: the font would be fine to package separately, if latte-dock didn't then depend on it. But I'm not sure why we should take this font into Ubuntu as a separate package if the only thing that wants it is latte-dock, and latte-dock isn't allowed by license to depend on it :) | 18:43 |
| slangasek | sladen: enormous amount of archive work> what other GPL packages are hard-coding preferences for GPL-incompatible fonts? | 18:44 |
| bdmurray | tseliot: what do I need to do to fix my system for bug 1752053? | 18:45 |
| ubottu | bug 1752053 in nvidia-graphics-drivers-390 (Ubuntu) "nvidia-390 fails to boot graphical display" [Undecided,Confirmed] https://launchpad.net/bugs/1752053 | 18:45 |
| tsimonq2 | slangasek: Upstream says that they are considering shipping it as a PNG then. Would a screenshot of a font which (going with what you're saying here) doesn't comply with the GPL be fine to then license under the GPL and ship in place of that? | 18:46 |
| tsimonq2 | ("it" being the logo) | 18:46 |
| bdmurray | tseliot: I installed libglvnd0 and xserver-xorg-core from -proposed but I'm still getting an error | 18:47 |
| slangasek | tsimonq2: assuming the font license doesn't "taint" the png, and the png itself can then be licensed under the GPL (which seems likely), then the answer is yes | 18:50 |
| tsimonq2 | slangasek: What do you mean by "assuming the font license doesn't "taint" the png"? | 18:50 |
| slangasek | tsimonq2: I haven't reviewed the text of the SIL Open Font License to see if the license claims to attach to derivative works | 18:50 |
| tsimonq2 | slangasek: OK | 18:51 |
| tseliot | bdmurray: can I see your /var/log/Xorg.0.log and your dmesg, please? | 18:57 |
| bdmurray | tseliot: sure, it'll be a moment | 18:58 |
| slangasek | infinity, kees, mdeslaur, stgraber: TB meeting? | 19:59 |
| mdeslaur | slangasek: ack! | 19:59 |
| tsimonq2 | slangasek, sladen: https://github.com/psifidotos/Latte-Dock/issues/884#issuecomment-369007487 | 20:05 |
| tsimonq2 | There we go | 20:05 |
| nacc | ugh, this seems like a step backwards | 20:32 |
| nacc | https://paste.ubuntu.com/p/jb76TmdG3V/ | 20:32 |
| nacc | I assume that's the new c-n-f | 20:32 |
| nacc | which is now completely unhelpful to new users | 20:32 |
| sarnold | nacc: agreed. that needs wordsmithing. | 20:39 |
| nacc | sarnold: it isn't happening for all packages/command,s though | 20:39 |
| nacc | sarnold: i wonder if it's snap-sensitive | 20:39 |
| nacc | mvo: --^ | 20:40 |
| nacc | this is quite sad | 20:41 |
| nacc | mvo: it just needs refactoring, it looks like and i don't know why you wouldn't give a `snap install` command line like we do for pat | 20:42 |
| nacc | *apt | 20:43 |
| mvo | nacc: feel free to make suggestions! https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1749777 is the relevant bug | 20:44 |
| ubottu | Launchpad bug 1749777 in command-not-found (Ubuntu) "Syntax tweaks for snap-friendly output" [Critical,In progress] | 20:44 |
| nacc | mvo: yes i will :) | 20:44 |
| mvo | nacc: thank you :) I'm actively working on this right now, hopefully tomorrow the output from the bugreport will be there (except the version numbers those need some server side tweaks first) | 20:45 |
| nacc | mvo: i'm putting a comment in :) | 20:47 |
| sladen | slangasek: any application that directly refers to any specific font. any application that refers to any SVG that refers to any specific font. where(licence(app) != licence(font) != licence(svg)) | 20:51 |
| slangasek | infinity, stgraber: hmph, edit-acl create prompts for a description, where do I /query/ existing descriptions for comparison? | 20:51 |
| stgraber | slangasek: I have them somewhere | 20:51 |
| stgraber | slangasek: http://people.canonical.com/~ubuntu-archive/packagesets/bionic/ | 20:52 |
| sladen | slangasek: ...any included/generated developer documentation (eg. PDF) that references specific images, or PDFs. that reference specific fonts. etc | 20:52 |
| slangasek | sladen: ok, so I'm perfectly willing to be shown that my reject is inconsistent with existing practice because there is a non-empty set of packages in that situation (and it must be more than just "unequal licenses", the issue is only with strong copyleft licenses, i.e. GPL) | 20:53 |
| nacc | sarnold: effective jinx :) | 20:53 |
| sarnold | nacc: I can't help myself :) I follow every patch / issue / link ... | 20:54 |
| nacc | sarnold: it's good, makes me feel less alone :) | 20:54 |
| nacc | slangasek: fyi, i think the removal of s2tc has made steam uninstallable on bionic | 21:08 |
| slangasek | nacc: hmm | 21:12 |
| slangasek | nacc: do you want to re-upload s2tc to Ubuntu? | 21:12 |
| slangasek | or get someone else to :) | 21:12 |
| nacc | slangasek: i only pointed it out as being a regression and you removed it :) | 21:14 |
| nacc | slangasek: i can re-upload it, if htat's the 'right' solution; i'm not sure how multiverse works in this regard :) | 21:14 |
| slangasek | nacc: yes, packages removed from Debian are also removed from Ubuntu "semi-automatically" when there is nothing holding them in; but Ubuntu developers should feel free to revert removals when appropriate | 21:17 |
| slangasek | nacc: they simply need to do so in a way that makes it clear that Ubuntu is taking responsibility for the package now, rather than it being a Debian sync | 21:17 |
| nacc | slangasek: would update-maintainer be sufficient (and I guess a new version string)? | 21:19 |
| slangasek | nacc: yep | 21:21 |
| nacc | slangasek: ack, will do it now | 21:21 |
| cjwatson | sladen,slangasek: FWIW I think the situation is qualitatively different if a document has some preferences but is happy to fall back to some other more-or-less-interchangeable font, than if an application tries to load a single font and is in a somewhat broken state if it's missing (I had the impression that this case was more like the latter, but I may be mistaken) | 21:25 |
| slangasek | cjwatson: yes; in this context, the code looks for a specific font in order to render its logo, with no fallback. I haven't tested what the code does if the font is absent; maybe it works but has a broken logo, maybe it crashes; but ideally we would deliver what upstream /wants/ the user to experience, so I'm glad to see upstream has given us a license exception statement now in this case | 21:27 |
| xevious | nacc: What would the best way to update php-codesniffer be? It just needs uscan & uupdate run. Should I try to get in touch wih the Debian maintainer? | 22:19 |
| nacc | xevious: you can file a bug in debian and a bug in ubuntu; i can do the one in ubuntu | 22:47 |
| === mwsb is now known as chu | ||
| tsimonq2 | slangasek: Would this be satisfactory? https://github.com/psifidotos/Latte-Dock/compare/db58a240400e4dbf6c87dac0c7ab04acb881e813...1a6fbcdfe0811436f39fc189b1a0eea707de3c60 | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!