Am Freitag, dem 12.03.2021 um 00:50 +0100 schrieb Klaumi Klingsporn: > Am / On Thu, 11 Mar 2021 17:38:55 +0100 > schrieb / wrote Daniel Leidert <dleidert@debian.org>: > > > I've checked the current sources. Here are some hints: > > Dear Daniel, > > I hopefully followed all your hints and also reverted the > link-building to libruby2.7-files except the ones that are > links themselves. > > > debian/copyright: > > ... > > data/webgen/passive_sources/stylesheets/coderay-default.css > > very probematic A) The COPYING file only says "LGPL" > > without any specific version, B) it actually says that > > this file was created > > I don't see the problem. Of cause it's created, as all the > source-files are. Nope. This is not the definition of source files. For the same reason minified JS is not considred "source" in Debian. I can only tell you what the FRP masters might complain about. > The important thing he says in > COPYING is that the file > "has been generated with the coderay_stylesheet binary and > falls under the LGPL." Unfortunately this is not specific enough. A user must know which license applies to the file. [..] > The 'coderay_stylesheet binary' this statement means > is the binary in the ruby-coderay package. Coderay now seems > to be licensed with MIT licence, although the debian > copyright file still declares it LGPL-2.1. But at least in > 2009 it was LGPL licensed. When the stylesheet has been created then it fell under the LGPL-2.1. > I don't know why Thomas Leitner wanted the coderay produced > css file also licensed by LGPL but he wanted it. LGPL > exists since 1991 and started with version 2.0. Since 1999 > exists version 2.1 and since 2007 also version 3.0. So I > think it's o.k. to assume that in 2009 this statement means > at least version 2.1. > > So I changed my copyright passage to: > > Files: > data/webgen/passive_sources/stylesheets/coderay-default.css > Copyright: © 2003-2021 Thomas Leitner (This file has been > generated with the coderay_stylesheet binary and falls > under the LGPL) > License: LGPL-2.1 Please: Files: .. Copyright: .. License: LGPL-2.1 Comment: The file has been produced and added to the project in 20xx by the coderay_stylesheet binary, which was distributed under the LGPL-2.x license then. > Hopefully this works and lintian will not grumble about it. It is more about if the FTP masters will grumble about it. > If not from my point of view the package would be ready. > > Oh, I just see: The reprotest job failed once more because > in the second build there was a test-error, which I > literally don't understand (my French fails): > > " 1) Failure: > TestTidy#test_static_call > [/tmp/reprotest.Xp4Lp0/build-experiment-1/build-experiment-1/test/webgen/content_processor/test_tidy.rb:32]: > Expected /inserting missing/ to match "W, > [2022-02-22T18:40:46.634660 #18048] WARN -- : Tidy > reported problems for </test>: Ligne: 1 Col: 1 - > Avertissement:ajout d'un élément 'title' manquant\nW, > [2022-02-22T18:40:46.870987 #18048] WARN -- : Tidy > reported problems for </test>: Ligne: 1 Col: 1 - > Avertissement:déclaration <!DOCTYPE> manquante\nW, > [2022-02-22T18:40:46.871083 #18048] WARN -- : Tidy > reported problems for </test>: Ligne: 1 Col: 1 - > Avertissement:texte brut n'est pas permis dans les éléments > <head>\nW, [2022-02-22T18:40:46.871102 #18048] WARN -- : > Tidy reported problems for </test>: Ligne: 1 Col: 1 - > Avertissement:insertion implicite de <body>\nW, > [2022-02-22T18:40:46.871114 #18048] WARN -- : Tidy > reported problems for </test>: Ligne: 1 Col: 1 - > Avertissement:ajout d'un élément 'title' manquant\n"." > > Any Idea? The test relies on an English locale it seems, but the locale is varied in reprotest. In this case a French locale is used and the error message by tidy is in French. So the assertion assert_log_match(/inserting missing/) actually fails. I guess Avertissement:insertion implicite de <body>\nW, would be something like "inserting missing" in an English environment. Three options: 1) Set LC_ALL to C or C.UTF-8 in this specific test. 2) More generic: Set this in debian/ruby-tests.rake. 3) Disable the test. Personally I think going 1) is optial. Going 3) and reporting this issue to upstream is perfectly acceptable as well. If the test requires an English locale the test should make sure that such a locale is used. I had a similar issue once: https://salsa.debian.org/ruby-team/puma/-/blob/debian/experimental/debian/patches/0013-fix-test-term-not-accepts-new-connections.patch > A little bit frustrated You are doing good! Regards, Daniel -- Regards, Daniel Leidert <dleidert@debian.org> | https://www.wgdd.de/ GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78 If you like my work consider sponsoring me via https://www.patreon.com/join/dleidert
Attachment:
signature.asc
Description: This is a digitally signed message part