Bug#982849: Occasional t/exception.t test failure

[Sandro Mani]

Package: licensecheck
Version: 3.1.1

t/exception.t occasionally fails as follows

# Failed test 'detect licensing "(GPL-2+ and/or LGPL-2.1+) with SDC 
exception" for sdc.py'

# at t/exception.t line 179.
# +-++-+
# | GOT | OP | CHECK   |
# +-++-+
# | (GPL-2+ and/or LGPL-2.1) with S | eq | (GPL-2+ and/or LGPL-2.1+) with  |
# | DC exception    |    | SDC exception   |
# +-++-+
# Seeded srand with seed '20210215' from local date.
t/exception.t .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/44 subtests

To reproduce:

cd App-Licensecheck-v3.1.1
while true; do PERL_DL_NONLAZY=1 "/usr/bin/perl" 
"-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef 
*Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" 
t/exception.t || break; done


This on a current Fedora Rawhide with:

perl-interpreter-4:5.32.1-471.fc34.x86_64
perl-generators-0:1.12-1.fc35.noarch
perl-Array-IntSpan-0:2.004-4.fc34.noarch
perl-autodie-0:2.34-2.fc34.noarch
perl-Carp-0:1.50-458.fc34.noarch
perl-Encode-4:3.08-459.fc34.i686
perl-Encode-4:3.08-459.fc34.x86_64
perl-Encode-Locale-0:1.05-19.fc34.noarch
perl-experimental-0:0.022-4.fc34.noarch
perl-Exporter-0:5.74-459.fc34.noarch
perl-ExtUtils-MakeMaker-2:7.58-2.fc34.noarch
perl-Fcntl-0:1.13-471.fc34.x86_64
perl-File-BaseDir-0:0.08-10.fc34.noarch
perl-File-Basename-0:2.85-471.fc34.noarch
perl-Getopt-Long-Descriptive-0:0.105-4.fc34.noarch
perl-List-SomeUtils-0:0.58-5.fc34.noarch
perl-Log-Any-0:1.708-6.fc34.noarch
perl-Log-Any-Adapter-Screen-0:0.140-8.fc34.noarch
perl-Moo-0:2.004004-2.fc34.noarch
perl-MooX-Role-Logger-0:0.005-6.fc34.noarch
perl-MooX-Struct-0:0.020-4.fc34.noarch
perl-namespace-clean-0:0.27-16.fc34.noarch
perl-Path-Iterator-Rule-0:1.014-10.fc34.noarch
perl-Path-Tiny-0:0.118-1.fc34.noarch
perl-Pod-Constants-0:0.19-16.fc34.noarch
perl-open-0:1.12-471.fc34.noarch
perl-Regexp-Pattern-0:0.2.14-4.fc34.noarch
perl-Regexp-Pattern-License-0:3.4.0-4.fc34.noarch
perl-Sort-Key-0:1.33-20.fc34.x86_64
perl-Software-License-0:0.103014-10.fc34.noarch
perl-libs-4:5.32.1-471.fc34.i686
perl-libs-4:5.32.1-471.fc34.x86_64
perl-strictures-0:2.06-10.fc34.noarch
perl-String-Copyright-0:0.003006-8.fc34.noarch
perl-String-Escape-0:2010.002-33.fc34.noarch
perl-Test-Simple-3:1.302183-2.fc34.noarch
perl-Test2-Suite-0:0.000139-2.fc34.noarch
perl-Test2-Suite-0:0.000139-2.fc34.noarch
perl-Test2-Suite-0:0.000139-2.fc34.noarch
perl-Test2-Suite-0:0.000139-2.fc34.noarch
perl-Test-Command-Simple-0:0.05-4.fc34.noarch
perl-Try-Tiny-0:0.30-11.fc34.noarch
perl-libs-4:5.32.1-471.fc34.i686
perl-libs-4:5.32.1-471.fc34.x86_64
perl-version-7:0.99.28-2.fc34.x86_64

Bug#973775: licensecheck returns incorrect license

[Sandro Mani]

On 05.11.20 03:56, Jonas Smedegaard wrote:

Quoting Sandro Mani (2020-11-04 22:54:56)

Package: licensecheck
Version: 3.1.1

I'm reporting this downstream issue [1], for your evaluation:

Description of problem:

$ licensecheck COPYING
COPYING: Expat License GNU Lesser General Public License, Version 3

Perhaps a bit of a pathological case.

Version-Release number of selected component (if applicable):
licensecheck-3.1.1-3.fc33.noarch
perl-Regexp-Pattern-License-3.4.0-3.fc33.noarch


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1866603

Sorry, I don't understand what is the issue here?

Could you please elaborate - I fail to parse the above "Description of
problem" and fail to find more info at the referenced bugzilla report.
Could very well be me simply missing something obvious - please help me
out...
Looking at the attached COPYING file, I suppose the original reporter 
expected the license to be reported just as


 GNU Lesser General Public License, Version 3

But I'll ask him to provide more info here.

Best
Sandro

Bug#973775: licensecheck returns incorrect license

[Sandro Mani]

Package: licensecheck
Version: 3.1.1

I'm reporting this downstream issue [1], for your evaluation:

Description of problem:

$ licensecheck COPYING
COPYING: Expat License GNU Lesser General Public License, Version 3

Perhaps a bit of a pathological case.

Version-Release number of selected component (if applicable):
licensecheck-3.1.1-3.fc33.noarch
perl-Regexp-Pattern-License-3.4.0-3.fc33.noarch


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1866603

DMTCP (and the included MTCP) is free software; you can redistribute it
and/or modify it under the terms of the GNU Lesser General Public License
(LGPL) as published by the Free Software Foundation; either version 3 of the
License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of  MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License
for more details.

A copy of the LGPL license is contained in the COPYING.LESSER file.

The file include/dmtcp.h is released under MIT/BSD dual license. The user is
allowed to use these files under either license.

Files found in the directory src are Copyright (C) 2006-2014 by Jason
Ansel, Kapil Arya, and Gene Cooperman, except:
- files src/trampolines.* are Copyright (C) 2006-2013 by Tyler Denniston, and
  Kapil Arya
- files plugin/ipc/event/eventwrappers.* are Copyright (C) 2012 by Kapil Arya,
  Gene Cooperman and Rohan Garg.

Files src/mtcp/mtcp_sys.h and src/mtcp/mtcp_util.ic are Copyright (C) 2006-2014 
by Michael Rieker, Gene Cooperman, and Kapil Arya.

Files found in the directory src/jalib are Copyright (C) 2005-2008 by Jason 
Ansel.

Files found in the directory jalib are Copyright (C) 2005-2008 by Jason Ansel.

The contents of files src/mtcp/sysdep-*, src/mtcp/NOTES-x86_64/*.[hS] and
src/glibcsystem.cpp are taken from glibc and is Copyright (C)
1991-2000,2002,2003,2005,2007 Free Software Foundation, Inc.

The contents of the file include/dmtcpalloc.h are Copyright (C) 2002 by
Pete Isensee.

Files found in the directory plugin/ptrace are Copyright (C) 2005-2013 by
Ana-Maria Visan, Kapil Arya, and Gene Cooperman.

Files found in the directory plugin/batch-queue are Copyright (C) 2012-2013 by
Artem Y. Polyakov.

Files found in a subdirectory of the contrib directory are Copyright (C) by the
author of that subdirectory.

File test/syscall-tester.c is Copyright (C) Copyright (C) 1990-2007, Condor
Team, Computer Sciences Department, University of Wisconsin-Madison, WI.

Any remaining files (for building and testing) are Copyright (C) 2006-2008,
2012-2013 Jason Ansel, Kapil Arya, and Gene Cooperman.

Bug#951186: Please reconsider usage of perl-Array-IntSpan in licensecheck

[Sandro Mani]

So the current Array::IntSpan maintainer managed to track down the 
original author, which has agreed to relicense to Artistic-2.0, which 
resolves this issue.

Bug#951186: Please reconsider usage of perl-Array-IntSpan in licensecheck

[Sandro Mani]

On 24.02.20 15:14, Jonas Smedegaard wrote:

Quoting Sandro Mani (2020-02-24 14:29:41)

On 24.02.20 13:16, Jonas Smedegaard wrote:

I'll go with applying the patch, and make a note in the rpm specfile

that it is a temporary hack and causes the deficiencies you
describe.

Your call :-)

Could you confirm whether the temporary hack would result in the same
level of accuracy licensecheck-3.0.39 had (before the dependency on
Array-IntSpan was added), or whether the Array-IntSpan logic replaced
previous logic, and hence the patch would result in worse accuracy
than 3.0.39?

No, I won't do any detailed research on your fork of my project, nor
will I do any detailed research into the exact effective delta for
historic releases of my project: Enough on my plate only moving forward.
Sheesh, that was just an honest question, "sorry I'm not sure about 
that" would have been sufficient as an answer...

Bug#951186: Please reconsider usage of perl-Array-IntSpan in licensecheck

[Sandro Mani]

On 24.02.20 13:16, Jonas Smedegaard wrote:

I'll go with applying the patch, and make a note in the rpm specfile

that it is a temporary hack and causes the deficiencies you describe.

Your call :-)


Could you confirm whether the temporary hack would result in the same 
level of accuracy licensecheck-3.0.39 had (before the dependency on 
Array-IntSpan was added), or whether the Array-IntSpan logic replaced 
previous logic, and hence the patch would result in worse accuracy than 
3.0.39?


Thanks
Sandro

Bug#951186: Please reconsider usage of perl-Array-IntSpan in licensecheck

[Sandro Mani]

On 24.02.20 12:21, Jonas Smedegaard wrote:



If you do choose to carry this patch, then I kindly request that you
document clearly that you are effectively distributing a fork of the
code, so that your users do not get the false impression that the
quality of your licensecheck is on par with that of licensecheck
released by me.

I just need a short-term solution to get licensecheck working again
(currently it is completely broken). If there are better solutions,
I'm happy to go for whatever works!

Here are some options I can see:

   * Roll back to an older release not depending on Array::IntSpan
 (and roll back Regexp::Pattern::License as well)
   * Wait for me to find a replacement for Array::IntSpan
   * Apply your patch and document its deficiencies as I request above


Rolling back would involve "Epoch" bumps in the package which are kinda 
ugly because they'll stay there for the lifetime of the package, so I'd 
rather avoid them.


I'll go with applying the patch, and make a note in the rpm specfile 
that it is a temporary hack and causes the deficiencies you describe.


Thanks
Sandro

Bug#951186: Please reconsider usage of perl-Array-IntSpan in licensecheck

[Sandro Mani]

Hi Jonas

On 24.02.20 11:58, Jonas Smedegaard wrote:

Hi Sandro,

Quoting Sandro Mani (2020-02-24 10:12:50)

Since I need to update the package in Fedora (it is currently broken),
I've prepared the patch below to remove the dependency. Can you
perhaps confirm that it does not fundamentally break licensecheck in
some way?
  From my tests, it appears to work.

Uhm, it won't _fundamentally_ break, but it will find multiple related
licenses where only one exist - e.g. detect fulltext of AGPL as either
AGPL or GPL because it mentions GPL.

Thanks, that explains the one test failure I'm seeing.


If you do choose to carry this patch, then I kindly request that you
document clearly that you are effectively distributing a fork of the
code, so that your users do not get the false impression that the
quality of your licensecheck is on par with that of licensecheck
released by me.
I just need a short-term solution to get licensecheck working again 
(currently it is completely broken). If there are better solutions, I'm 
happy to go for whatever works!


I _do_ intend to fix this issue, just haven't gotten around to it yet,
and a proper fix involved _replacing_ Array::IntSpan, not simply
stripping it.


Thanks, unfortunately my perl knowledge is pretty much zero, so sorry 
for not being able to help more.


Sandro

Bug#951186: Please reconsider usage of perl-Array-IntSpan in licensecheck

[Sandro Mani]

Hi Jonas

Since I need to update the package in Fedora (it is currently broken), 
I've prepared the patch below to remove the dependency. Can you perhaps 
confirm that it does not fundamentally break licensecheck in some way? 
From my tests, it appears to work.


Thanks

Sandro



diff -rupN App-Licensecheck-v3.0.45/lib/App/Licensecheck.pm 
App-Licensecheck-v3.0.45-new/lib/App/Licensecheck.pm
--- App-Licensecheck-v3.0.45/lib/App/Licensecheck.pm    2020-02-21 
16:24:52.0 +0100
+++ App-Licensecheck-v3.0.45-new/lib/App/Licensecheck.pm 2020-02-23 
17:29:05.277245643 +0100

@@ -12,7 +12,6 @@ use Path::Tiny;
 use Try::Tiny;
 use Fcntl qw(:seek);
 use Encode;
-use Array::IntSpan;
 use Regexp::Pattern::License 3.1.102;
 use Regexp::Pattern 0.2.12 (
 're',
@@ -601,7 +600,6 @@ sub parse_license
 my @gpl  = qw(gpl gpl_1 gpl_2 gpl_3);
 my @lgpl = qw(lgpl lgpl_2 lgpl_2_1 lgpl_3);

-    my $coverage = Array::IntSpan->new();
 my %match;
 my ( %grant, %license );

@@ -697,27 +695,16 @@ sub parse_license
     );
     my $license = pop @licenses;
     next unless ($license);
-        next
-            if defined(
-            $coverage->get_range( $pos, $pos_license{$pos}{$license} )
-                ->get_element(0) );
     $self->log->tracef(
         'detected and flagged well-formed license fulltext: %s: %s 
[%s]',

         $license, $pos, $file
     );
-        $coverage->set_range( $pos, $pos_license{$pos}{$license}, 
$license );

     $license{$license} = 1;
 }

 foreach my $trait (qw(license_label_trove license_label 
licensed_under)) {

     next unless ( $licensetext =~ /$RE{"TRAIT_$trait"}/ );
     while ( $licensetext =~ /$RE{"TRAIT_GLOBAL_$trait"}/g ) {
-            next
-                if (
-                defined(
-                    $coverage->get_range( $-[0], $+[0] )->get_element(0)
-                )
-                );
         push @clues, Trait [ $trait, $-[0], $+[0] ];
     }
 }
@@ -766,11 +753,6 @@ sub parse_license

     if (    $name
         and $match{$name}{name}{$pos_name}
-            and !defined(
-                $coverage->get_range(
-                    $pos_name, $match{$name}{name}{$pos_name}
-                )->get_element(0)
-            )
         and grep { $_ eq $name } @L_tidy
         )
     {
@@ -1187,11 +1169,7 @@ sub parse_license
     next if ( $match{$id}{custom} );
     next if ( $license{$id} );
     if ( $RE{"GRANT_$id"} ) {
-            if ($licensetext =~ $RE{"GRANT_$id"}
-                and !defined(
-                    $coverage->get_range( $-[0], $+[0] )->get_element(0)
-                )
-                )
+            if ($licensetext =~ $RE{"GRANT_$id"})
         {
             $self->log->tracef(
                 'detected versioned grant/license: %s: [%s]',
@@ -1246,11 +1224,7 @@ sub parse_license

     if (   $license{$id}
         or $grant{$id}
-            or ($licensetext =~ $RE{"GRANT_$id"}
-                and !defined(
-                    $coverage->get_range( $-[0], $+[0] )->get_element(0)
-                )
-            )
+            or $licensetext =~ $RE{"GRANT_$id"}
         )
     {
         $self->log->tracef(

Bug#951186: Please reconsider usage of perl-Array-IntSpan in licensecheck

[Sandro Mani]

Package: licensecheck
Version: 3.0.41

The perl Array-IntSpan module is licensed Artistic v1 [1], but this 
license is considered a non-free license [2] and not allowed in Fedora [3].


As such, Fedora won't be able to ship newer versions of licensecheck as 
long as there is a dependency on this module. Could it's use please be 
reconsidered? Thanks.


[1] https://metacpan.org/release/Array-IntSpan
[2] https://www.gnu.org/licenses/license-list.html#ArtisticLicense
[3] 
https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Bad_Licenses 

Bug#926392: licensecheck chokes on long lines

[Sandro Mani]

Package: licensecheck
Version: 3.0.36

As reported downstream at [1]:


$ wget 
https://files.pythonhosted.org/packages/source/x/xonsh/xonsh-0.8.12.tar.gz

$ tar xf xonsh-0.8.12.tar.gz
$ licensecheck xonsh-0.8.12/xonsh/parser_table.py

=> Licensecheck hangs eating cpu cycles (the file has lines with 33k and 
71k characters).



[1] https://bugzilla.redhat.com/show_bug.cgi?id=1695680

Bug#902639: Use of uninitialized value $3 in concatenation (.) or string at /usr/share/perl5/vendor_perl/App/Licensecheck.pm

[Sandro Mani]

Package: licensecheck
Version: 3.0.36

As reported downstream at 
https://bugzilla.redhat.com/show_bug.cgi?id=1595880:


When running licensecheck on OpenJDK sources[1] I'm getting this:
Use of uninitialized value $3 in concatenation (.) or string at 
/usr/share/perl5/vendor_perl/App/Licensecheck.pm line 678, <$fh> line 61.


On that line I see:
$gen_license->( 'apache', $1, $2, "bsd_${3}_clause" );

Changing it to:
$gen_license->( 'apache', $1, $2, $3 ? "bsd_${3}_clause" : "" );

makes it work.

Steps to Reproduce:
1. $ licensecheck dynalink.operation.copyright.txt (see attachment)

Note: downstream bug is against 3.0.33, but also applies with 
licensecheck-3.0.36-1.fc29.noarch as packaged in Fedora Rawhide.


/*
 * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.  Oracle designates this
 * particular file as subject to the "Classpath" exception as provided
 * by Oracle in the LICENSE file that accompanied this code.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

/*
 * This file is available under and governed by the GNU General Public
 * License version 2 only, as published by the Free Software Foundation.
 * However, the following notice accompanied the original version of this
 * file, and Oracle licenses the original version of this file under the BSD
 * license:
 */
/*
   Copyright 2015 Attila Szegedi

   Licensed under both the Apache License, Version 2.0 (the "Apache License")
   and the BSD License (the "BSD License"), with licensee being free to
   choose either of the two at their discretion.

   You may not use this file except in compliance with either the Apache
   License or the BSD License.

   If you choose to use this file in compliance with the Apache License, the
   following notice applies to you:

   You may obtain a copy of the Apache License at

   http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
   implied. See the License for the specific language governing
   permissions and limitations under the License.

   If you choose to use this file in compliance with the BSD License, the
   following notice applies to you:

   Redistribution and use in source and binary forms, with or without
   modification, are permitted provided that the following conditions are
   met:
   * Redistributions of source code must retain the above copyright
 notice, this list of conditions and the following disclaimer.
   * Redistributions in binary form must reproduce the above copyright
 notice, this list of conditions and the following disclaimer in the
 documentation and/or other materials provided with the distribution.
   * Neither the name of the copyright holder nor the names of
 contributors may be used to endorse or promote products derived from
 this software without specific prior written permission.

   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
   IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
   TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
   PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL COPYRIGHT HOLDER
   BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
   CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
   SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
   BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
   WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
   OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
   ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/

Bug#853795: dpkg: Unable to disable .buildinfo generation

[Sandro Mani]

As a workaround, I figured out I can pass to debuild

--buildinfo-option="-O"

which makes dpkg-genbuildinfo send the contents of the buildinfo file to 
stdout instead of creating the file, which means that it does not appear 
in the .changes file either.

Bug#830115: licensecheck invokes find with -follow

[Sandro Mani]

On 06.07.2016 10:25, Jonas Smedegaard wrote:

Quoting Sandro Mani (2016-07-06 09:56:36)

Following is a trimmed version of the downstream bug at [1], already
reported for devscripts at [2].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1350021
[2] http://bugs.debian.org/828088

Thanks, but please check for duplicates before reporting: This bug was
already reported as bug#828088, as you mention yourself.  Proper action
for bugs in licensecheck filed against devscripts is to request (by
simply emailing to it) that the old bug be reassigned to licensecheck -
which already happened in this case. :-)
Sorry, missed it (admittedly not overly experienced with working with 
the debian BTS).

Bug#830116: licensecheck doesn't distinguish LBNL BSD

[Sandro Mani]

Package: licensecheck
Version: 3.0.1

Following is reported downstream at [1]:

licensecheck detects a LBNLBSD [2] header as BSD (3 clause).

The reported of the downstream bug asks whether licensecheck should be 
able to distinguish them.



[1] https://bugzilla.redhat.com/show_bug.cgi?id=1352025
[2] https://fedoraproject.org/wiki/Licensing:LBNLBSD?rd=Licensing/LBNLBSD

Bug#830115: licensecheck invokes find with -follow

[Sandro Mani]

Package: licensecheck
Version: 3.0.1

Following is a trimmed version of the downstream bug at [1], already 
reported

for devscripts at [2].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1350021
[2] http://bugs.debian.org/828088

Description of problem:
When licensecheck ran, it reported:

find: File system loop detected; ‘./src/giac’ is part of the same file 
system loop as ‘./src’.

Can't close(GLOB(0x668db0)) filehandle: '' at /usr/bin/licensecheck line 387

There are two bugs here: licensecheck tries to close a file handle on 
line 387
even when the handle is already closed due to find exiting with an 
error, and

licensecheck invokes find with the -follow option.

The find man page says that -follow is deprecated and -L should be used 
instead, by the way.
But I can't conceive of any situation where using -follow/-L is the 
right thing to do.

I think it should be removed, for three reasons.
Reason 1: self loops like the one in giac make find, and therefore 
licensecheck, fail.
Reason 2: symlinks can point anywhere.  Do you really want to let 
licensecheck run over arbitrary parts of the filesystem?
Reason 3: every file in a package *should* be reachable without 
traversing symlinks at all.  (If fedora-review doesn't have a check for 
that, it probably should.)


Steps to Reproduce:
1. mkdir loop
2. ln -s . loop/loop
3. licensecheck -r -v loop

Actual results:
The error messages reported above, and no license output.

Expected results:
A report on licenses.

Additional info:
The filesystem type might have something to do with this.  I do NOT see 
this behavior if I create the loop under /tmp (tmpfs), but I do see it 
if the loop is under my /home directory (ext4).

Bug#829667: License headers

[Sandro Mani]

On 05.07.2016 21:35, Jonas Smedegaard wrote:


Quite interesting - assuming you did in fact check the --help option.

What does "licensecheck --version | head -n 1" say?
Never mind, I was using licensecheck from devscripts-2.16.5. So all 
good, thanks for your responsiveness!

Bug#829667: License headers

[Sandro Mani]

On 05.07.2016 15:09, Jonas Smedegaard wrote:

Quoting Sandro Mani (2016-07-05 14:15:26)

On 05.07.2016 12:56, Jonas Smedegaard wrote:

Thanks for elaborating on how Fedora uses licensecheck for quality
assurance.  I appreciate your contacting upstreams to ensure that
licensing statements are unambiguous and embedded in each file where
copyright is claimed.  But instead of suggesting upstreams to
conform to the more strict principle of putting licensing statements
at the top of each file, I recommend that instead Fedora considers
adjusting its quality assureance process to scan whole files instead
of only the header.

Well, I suppose it is licensecheck itself which only scans the
headers?
It is not a Fedora policy of any sort to only scan the headers of the
files, but we are actually relying on the licensecheck script to
detect the license of the various files in the source tarball. And in
this particular case:

$ licensecheck App-Licensecheck-v3.0.1/bin/licensecheck
App-Licensecheck-v3.0.1/lib/App/Licensecheck.pm
App-Licensecheck-v3.0.1/bin/licensecheck: UNKNOWN
App-Licensecheck-v3.0.1/lib/App/Licensecheck.pm: UNKNOWN


(But I don't want to be annyoing or anything, just following our
guidelines ;) )

You are not annoying, not at all!

If you do "licensecheck --help" you will see that there are options to
either check the whole file (--lines 0) or bottom in addition to top
(--tail N).

I recommend to scan the whole file.


Hmm,

$ licensecheck -r --lines 0 App-Licensecheck-v3.0.1
App-Licensecheck-v3.0.1/bin/licensecheck: UNKNOWN
App-Licensecheck-v3.0.1/lib/App/Licensecheck.pm: UNKNOWN
[...]

Bug#829667: License headers

[Sandro Mani]

On 05.07.2016 12:56, Jonas Smedegaard wrote:

Quoting Sandro Mani (2016-07-05 11:43:22)

Hi Jonathan

My name is Jonas (but not offended at all - not to worry :-) )

Uh, no idea how I managed this confusion?! Sorry!




For reviews, we have a tool (fedora-review) which runs licensecheck
recursively in the source tree. Fedora-review then prints out the
detected licenses in the license headers of the files and the
reviewer/packager is asked to compare these licenses with the actual
license declared by the project resp. in the package metadata (i.e.
the spec file).

So I suppose that typically people expect that each source file
contains a license header (from my point of view this also makes sense
if individual files are reused outside of the project). But it is not
a review-blocking issue, our guidelines simply ask us to raise the
issue upstream.

I disagree with your statement that "people expect that each source file
contains a license header".

Im my understanding, people (in the FLOSS community at large) expect
license statements to be explicit and included with the released project
(rather than abbreviated or rerefenced from an online resource), and
preferrably embedded in each source file.  CPAN projects generally, and
the App::Licensecheck project specifically, embeds licensing statements
in each source file, just not at the top which you seem to impose as a
general expectation.

Thanks for elaborating on how Fedora uses licensecheck for quality
assurance.  I appreciate your contacting upstreams to ensure that
licensing statements are unambiguous and embedded in each file where
copyright is claimed.  But instead of suggesting upstreams to conform to
the more strict principle of putting licensing statements at the top of
each file, I recommend that instead Fedora considers adjusting its
quality assureance process to scan whole files instead of only the
header.
Well, I suppose it is licensecheck itself which only scans the headers? 
It is not a Fedora policy of any sort to only scan the headers of the 
files, but we are actually relying on the licensecheck script to detect 
the license of the various files in the source tarball. And in this 
particular case:


$ licensecheck App-Licensecheck-v3.0.1/bin/licensecheck 
App-Licensecheck-v3.0.1/lib/App/Licensecheck.pm

App-Licensecheck-v3.0.1/bin/licensecheck: UNKNOWN
App-Licensecheck-v3.0.1/lib/App/Licensecheck.pm: UNKNOWN


(But I don't want to be annyoing or anything, just following our 
guidelines ;) )

Bug#829667: License headers

[Sandro Mani]

Hi Jonathan

For reviews, we have a tool (fedora-review) which runs licensecheck 
recursively in the source tree. Fedora-review then prints out the 
detected licenses in the license headers of the files and the 
reviewer/packager is asked to compare these licenses with the actual 
license declared by the project resp. in the package metadata (i.e. the 
spec file).


So I suppose that typically people expect that each source file contains 
a license header (from my point of view this also makes sense if 
individual files are reused outside of the project). But it is not a 
review-blocking issue, our guidelines simply ask us to raise the issue 
upstream.


Thanks

Sandro


On 05.07.2016 11:40, Jonas Smedegaard wrote:

Hi Sandro,

Thanks for the bugreport, and thanks a lot for packaging licensecheck
for Fedora - moving it to CPAN was done *exactly* to ease redistribution
also outside of Debian :-D

Comments below the quote...

Quoting Sandro Mani (2016-07-05 09:24:31)

Package: licensecheck
Version: 3.0.1

The following issue was raised during review of the Fedora package [1]:

  These source files are without license headers:
  App-Licensecheck-v3.0.1/bin/licensecheck
  App-Licensecheck-v3.0.1/lib/App/Licensecheck.pm
  Please, ask to upstream to confirm the
  licensing of code and/or content/s, and ask to add license headers
  
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#License_Clarification


COPYRIGHT states clearly that bin/licensecheck and lib/App/Licensecheck.pm are 
GPL-3.0, but it would not harm to add license headers also?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1352667#c5

The issue you raise here puzzles me, however: What licensing information
more specifically do you (or others in Fedora) believe is missing from
those three files?

Is it perhaps that you/they feel that licensing statements in a _header_
comment are somehow superior to statements embedded in POD (commonly
placed near the bottom for Perl modules)?

NB! Please beware that license scanners - both licensecheck and (it
seems, but I am only guessing) rpmlint - can be only advisory, and if in
doubt you should read the actual code yourself.


Regards,

  - Jonas

Bug#829667: License headers

[Sandro Mani]

Package: licensecheck
Version: 3.0.1

The following issue was raised during review of the Fedora package [1]:

These source files are without license headers:
App-Licensecheck-v3.0.1/bin/licensecheck
App-Licensecheck-v3.0.1/lib/App/Licensecheck.pm
Please, ask to upstream to confirm the
licensing of code and/or content/s, and ask to add license headers

https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#License_Clarification


COPYRIGHT states clearly that bin/licensecheck and lib/App/Licensecheck.pm are 
GPL-3.0, but it would not harm to add license headers also?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1352667#c5

Bug#828088: licensecheck invokes find with -follow

[Sandro Mani]

Package: devscripts
Version: devscripts-2.16.5

Following is a trimmed version of the downstream bug at 
https://bugzilla.redhat.com/show_bug.cgi?id=1350021 :

Description of problem:
When licensecheck ran, it reported:

find: File system loop detected; ‘./src/giac’ is part of the same file system 
loop as ‘./src’.
Can't close(GLOB(0x668db0)) filehandle: '' at /usr/bin/licensecheck line 387

There are two bugs here: licensecheck tries to close a file handle on line 387 
even when the handle is already closed due to find exiting with an error, and 
licensecheck invokes find with the -follow option.

The find man page says that -follow is deprecated and -L should be used 
instead, by the way.  But I can't conceive of any situation where using 
-follow/-L is the right thing to do.  I think it should be removed, for three 
reasons.  Reason 1: self loops like the one in giac make find, and therefore 
licensecheck, fail.  Reason 2: symlinks can point anywhere.  Do you really want 
to let licensecheck run over arbitrary parts of the filesystem?  Reason 3: 
every file in a package *should* be reachable without traversing symlinks at 
all.  (If fedora-review doesn't have a check for that, it probably should.)

Steps to Reproduce:
1. mkdir loop
2. ln -s . loop/loop
3. licensecheck -r -v loop

Actual results:
The error messages reported above, and no license output.

Expected results:
A report on licenses.

Additional info:
The filesystem type might have something to do with this.  I do NOT see this 
behavior if I create the loop under /tmp (tmpfs), but I do see it if the loop 
is under my /home directory (ext4).

Bug#801398: [Patch] Replace Dpkg::IPC::spawn with IPC::Run::run

[Sandro Mani]

On 10.10.2015 10:16, Osamu Aoki wrote:

Hi,

On Fri, Oct 09, 2015 at 07:36:21PM +0200, Salvatore Bonaccorso wrote:

Hi,

On Fri, Oct 09, 2015 at 05:22:16PM +0200, Sandro Mani wrote:

Some time back licensecheck grew a dependency on Dpkg::IPC [1], which on
Fedora causes the "devscripts-minimal" package (which includes licensecheck)
to pull in dpkg. I'd like to propose the patch below to reduce the
dependency load:

[...]

If this is changed, one needs to make sure that CVE-2015-5705 /
#794365 isn't reintroduced (argument injection vulnerability).

I understand back-tick is problematic as CVE-2015-5705.  (hmmm ...
something to keep in mind :-)  Avoiding it was a good idea.

Both Dpkg::IPC and IPC::Run seem to offer similar functionality and
similar security protection by using the list of strings instead of a
long shell interpreted command string.  So this change itself looks like
neutral for the concern raised by Salvatore.(In-depth evaluation may be
a good idea.  Feed back on this aspect from Sandro is appreciated.)

But before digging that deep for such security feature differences, I
fail to understand the rationale of switching from Dpkg::IPC to IPC::Run
for devscripts as presented.

I do not know how OP wishes to use this code on Fedora but if we look at
the devscripts package as a whole, the OP's claim "grew a dependency"
does not make sense.  The use of Dpkg::IPC was meant to avoid growing
dependency.
Ok I see that this is the case on debian. On Fedora, licensecheck ended 
up pulling in the entire dpkg through Dpkg::IPC (which in Fedora is 
packaged as dpkg-perl), and people complained:


https://bodhi.fedoraproject.org/updates/FEDORA-2015-e0237fcd94

On debian it might indeed be the other way round: dpkg is installed 
anyway, so not much changes by having licensecheck depend on Dpkg::IPC.


I'm proposing this patch upstream because of our policy to do so, but if 
it does not make sense for you, I'll just mark the patch as 
non-upstreamable and carry it downstream.



Thanks
Sandro

Bug#801398: [Patch] Replace Dpkg::IPC::spawn with IPC::Run::run

[Sandro Mani]

Package: devscripts
Version: 2.15.9

Some time back licensecheck grew a dependency on Dpkg::IPC [1], which on 
Fedora causes the "devscripts-minimal" package (which includes 
licensecheck) to pull in dpkg. I'd like to propose the patch below to 
reduce the dependency load:



diff -rupN devscripts-2.15.9/scripts/licensecheck.pl 
devscripts-2.15.9-new/scripts/licensecheck.pl
--- devscripts-2.15.9/scripts/licensecheck.pl2015-10-06 
03:00:34.0 +0200
+++ devscripts-2.15.9-new/scripts/licensecheck.pl2015-10-09 
12:51:12.425215534 +0200

@@ -157,7 +157,7 @@ use warnings;
 use warningsqw< FATAL  utf8 >;
 use Encode qw/decode/;

-use Dpkg::IPC qw(spawn);
+use IPC::Run qw(run);
 use Getopt::Long qw(:config gnu_getopt);
 use File::Basename;

@@ -337,11 +337,7 @@ while (@files) {

 # Encode::Guess does not work well, use good old file command to 
get file encoding

 my $mime;
-spawn(exec => ['file', '--brief', '--mime', '--dereference', '--', 
$file],

-  to_string => \$mime,
-  error_to_file => '/dev/null',
-  nocheck => 1,
-  wait_child => 1);
+run [qw(file --brief --mime --dereference), $file], \undef, \$mime;
 my $charset ;
 if ($mime =~ m/; charset=((?!binary)(?!unknown)[\w-]+)/) {
 $charset = $1;



[1] 
https://github.com/Debian/devscripts/commit/c0687bcde23108dd42e146573c368b6905e6b8e8

Bug#791756: Running licensecheck on tarball or image results in crash

[Sandro Mani]

On 09.07.2015 13:17, Dominique Dumont wrote:

On Wednesday 08 July 2015 10:09:48 Sandro Mani wrote:

It should either print *No copyright* UNKNOWN or info that this script
doesn't work on binary files.

I suggest that licensecheck issues a warning when a non text file is found.
Like:

licensecheck warning: cannot parse file 'lm180.pdf' with mime type
'application/pdf; charset=binary'

Is this fine with you ?


Yes sounds good, thanks!


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#791756: Running licensecheck on tarball or image results in crash

[Sandro Mani]

Package: devscripts
Version: 2.15.5


From https://bugzilla.redhat.com/show_bug.cgi?id=1240914:

Description of problem:
In fedora-review package, script /usr/bin/licensecheck is used - it's part of 
devscripts-minimal package. Running licensecheck on binary file (such as 
tarball, picture, etc.) results in crash with:

Unknown encoding 'binary' at /usr/bin/licensecheck line 338.

Problem is that licensecheck uses file -bi to determine file encoding and 
uses this value to decode. Running file -bi on image file returns:

image/jpeg; charset=binary

but Perl function decode() doesn't know binary encoding.

Version-Release number of selected component (if applicable):
2.15.5-5

Steps to Reproduce:
1. Download any image.
2. Run licensecheck image.jpeg

Actual results:
It shows: Unknown encoding 'binary' at /usr/bin/licensecheck line 338.

Expected results:
It should either print *No copyright* UNKNOWN or info that this script 
doesn't work on binary files.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#766180: /usr/bin/annotate-output errors for date format with spaces

[Sandro Mani]

Package: devscripts
Version: 2.14.10


From https://bugzilla.redhat.com/show_bug.cgi?id=1082680:

/usr/bin/annotate-output does not handle date formats with spaces. I.e.:

$ /usr/bin/annotate-output +%F %T date
date: extra operand ‘%T’
Try 'date --help' for more information.
 I: Started date
date: extra operand ‘%T’
Try 'date --help' for more information.
 O: Mon Mar 31 11:25:40 EDT 2014
date: extra operand ‘%T’
Try 'date --help' for more information.
 I: Finished with exitcode 0


Patch suggested by original reporter:

$ diff /usr/bin/annotate-output /usr/bin/annotate-output.new
28c28
echo `date ${FMT}` $1: $line
---

printf %s %s: %s\n $(date $FMT) $1 $line

78c78
 echo `date ${FMT}` I: Started $@
---

addtime I  Started $*

83c83
 echo `date ${FMT}` I: Finished with exitcode $EXIT
---

addtime I  Finished with exitcode $EXIT



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739688: Manpages not utf-8 encoded

[Sandro Mani]

Package: sensible-utils
Version: 0.0.9

Packaging sensible-utils for Fedora, rpmlint told me:

sensible-utils.noarch: W: file-not-utf8 
/usr/share/man/de/man1/sensible-editor.1.gz
sensible-utils.noarch: W: file-not-utf8 
/usr/share/man/fr/man1/sensible-editor.1.gz
sensible-utils.noarch: W: file-not-utf8 
/usr/share/man/es/man1/sensible-editor.1.gz


Specifically:
$ file de/man1/sensible-editor.1
de/man1/sensible-editor.1: troff or preprocessor input, Non-ISO 
extended-ASCII text


$ file fr/man1/sensible-editor.1
fr/man1/sensible-editor.1: troff or preprocessor input, ISO-8859 text

$ file es/man1/sensible-editor.1
es/man1/sensible-editor.1: troff or preprocessor input, Non-ISO 
extended-ASCII text


de/man1/sensible-editor.1 and es/man1/sensible-editor.1 contain garbage 
characters.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org