django-ajax-selects lintian errors/warnings

[Brian May]

Hello,

For django-ajax-selects in git[1] I am getting the following errors and
warnings:

E: django-ajax-selects source: source-is-missing 
ajax_select/static/ajax_select/js/bootstrap.js
W: python3-ajax-select: extra-license-file 
usr/lib/python3/dist-packages/ajax_select/LICENSE.txt
W: python3-ajax-select: image-file-in-usr-lib 
usr/lib/python3/dist-packages/ajax_select/static/ajax_select/images/loading-indicator.gif
E: python3-ajax-select: privacy-breach-uses-embedded-file 
usr/lib/python3/dist-packages/ajax_select/static/ajax_select/js/bootstrap.js 
You may use libjs-jquery-ui package. 
(//code.jquery.com/ui/1.10.3/themes/smoothness/jquery-ui.css)
E: python3-ajax-select: privacy-breach-uses-embedded-file 
usr/lib/python3/dist-packages/ajax_select/static/ajax_select/js/bootstrap.js 
You may use libjs-jquery package. 
(//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js)
W: python-ajax-select: image-file-in-usr-lib 
usr/lib/python2.7/dist-packages/ajax_select/static/ajax_select/images/loading-indicator.gif
E: python-ajax-select: privacy-breach-uses-embedded-file 
usr/lib/python2.7/dist-packages/ajax_select/static/ajax_select/js/bootstrap.js 
You may use libjs-jquery-ui package. 
(//code.jquery.com/ui/1.10.3/themes/smoothness/jquery-ui.css)
E: python-ajax-select: privacy-breach-uses-embedded-file 
usr/lib/python2.7/dist-packages/ajax_select/static/ajax_select/js/bootstrap.js 
You may use libjs-jquery package. 
(//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js)

To me it looks like I should override some of these.

source-is-missing - this is false, this is the source file, I believe it
was written by hand. It has some long lines. See below, I pasted it into
this message.

extra-license-file - at quick glace this warning is correct, and should
get fixed.

image-file-in-usr-lib - do we really care about this? For Django apps it
is common practise to put static files under the Python directory like
this. That means they go under /usr/lib. It is not really possible to
change this without a lot of extra complexity using a -common package
and symlinks. For one small file, not convinced it is worth it.

privacy-breach-uses-embedded-file - this is only correct if used by an
application that does not import jquery symbols itself. If the
application already has loaded jquery and jquery-ui from, say a local
source, I believe there is no privacy issue:

// load jquery and jquery-ui if needed
// into window.jQuery
if (typeof window.jQuery === 'undefined') {
  document.write('

Re: new default build flag from dpkg: -Wdate-time

[Mattia Rizzolo]

reassign 790103 gcc-avr 1:4.8.1+Atmel3.4.5-1
retitle 790103 gcc-avr: base on a newer version of gcc
affects 790103 expeyes

On Sat, Nov 14, 2015 at 10:35:46AM +0100, Georges Khaznadar wrote:
> > > 3- rebase the package gcc-avr on a newer version of gcc, which may be a
> > >hard work. Such a work seems to exist, for example at
> > >https://www.archlinux.org/packages/community/x86_64/avr-gcc/ since
> > >last July
> > 
> > This is what should be done, really.
> 
> I had a look at this last option, but I miss knowledge to keep on with
> it: as I could guess, the current gcc-avr package is based on a frozen
> archive of gcc-4.8, which is modified by adding subtle modifications.
> Obviously, I can freeze an archive of gcc-5, but I cannot craft the
> modifications to turn it into an efficient compiler for avr.

I miss those too, fwiw.

> So I shall reassign bug #790103 to gcc-avr, and keep the suggested link
> to expeyes.

done.

> As a matter of fact, I cannot push the severity such a bugreport higher
> than whishlist, as I cannot provide any help about the work to be done.

This is not what is used to decide the severities :), but still it's a
whishlist bug.

If this is not fixed in time for the change I'll open another bug
against expeyes to at least disable the flag.
If for some reason (=> allow us to test your package, maybe?) you want
to do it now adding this to d/rules should be sufficient
DEB_BUILD_MAINT_OPTIONS=reproducible=-timeless

> Best regards, Georges.

enjoy!

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: django-ajax-selects lintian errors/warnings

[Neil Williams]

On Sat, 14 Nov 2015 20:23:38 +1100
Brian May  wrote:

> Hello,
> 
> For django-ajax-selects in git[1] I am getting the following errors
> and warnings:

Many of these need work upstream, some can be replaced with symlinks,
some are not packaged in Debian due to problems with the minifier used
in the build process of that upstream.

> E: django-ajax-selects source: source-is-missing
> ajax_select/static/ajax_select/js/bootstrap.js

If this really is your own source code, a filename change would be one
way to do it. In most cases, bootstrap is not written by this upstream
but has been included into the upstream VCS from another location.

> python3-ajax-select: image-file-in-usr-lib
> usr/lib/python3/dist-packages/ajax_select/static/ajax_select/images/loading-indicator.gif

This matters more when the package list from this source package
contains Architecture: any instead of Architecture: all binaries, which
is uncommon with django apps. With Arch: any, the files in /usr/lib/
would be duplicated for each arch build which is a clear problem to be
avoided.

It would seem sensible that lintian could check the architecture of the
binary providing the files. Yes, it's a wrinkle and arguably ugly to
have images in /usr/lib/ but then what is the point of models.py and
views.py being in /usr/lib/ on that basis? setuptools moved
to /usr/lib/ some time ago, it's not a good idea to backtrack
to /usr/share just for Debian. Having a -common package for Arch:all
doesn't really make sense unless there is more than one Arch:all
package sharing those "common" files. /usr/lib/ makes sense for the
lower end python code which has architecture-specific bindings.

> E: python3-ajax-select: privacy-breach-uses-embedded-file
> usr/lib/python3/dist-packages/ajax_select/static/ajax_select/js/bootstrap.js
> You may use libjs-jquery-ui package.

You may indeed - replace the file with a symlink in debian/rules and
add to Depends.

> source-is-missing - this is false, this is the source file, I believe
> it was written by hand. It has some long lines. See below, I pasted
> it into this message.

lintian may just be basing this on the filename.
 
> image-file-in-usr-lib - do we really care about this? For Django apps
> it is common practise to put static files under the Python directory
> like this. That means they go under /usr/lib. It is not really
> possible to change this without a lot of extra complexity using a
> -common package and symlinks. For one small file, not convinced it is
> worth it.

As above, I'm not sure why lintian cannot appreciate the distinction
here for Arch: all packages. It would be nice if I could remove the
override: lava-server: image-file-in-usr-lib *
 
> privacy-breach-uses-embedded-file - this is only correct if used by an
> application that does not import jquery symbols itself. If the
> application already has loaded jqueblry and jquery-ui from, say a
> local source, I believe there is no privacy issue:
> 
> // load jquery and jquery-ui if needed
> // into window.jQuery
> if (typeof window.jQuery === 'undefined') {
>   document.write('

copyright files can be generated by cme (was Re: Copyright file granularity)

[Dominique Dumont]

Le vendredi 13 novembre 2015, 16:10:14 16:10:14 Wookey a écrit :
> However there are numerous copyright holders and files contributed on
> various dates so I spent several hours making this copyright file:
> https://sources.debian.net/src/ompl/1.0.0%2Bds2-1/debian/copyright/
> with each copyright owner split out into a separate stanza.

Detailed copyright files can be generated by cme. You can either run 
"cme update dpkg-copyright " [1] or "scan-copyrights" [2] . (you need to 
install cme and lib-config-model-dpkg-perl)

The first one tries its best to merge current copyright with existing 
debian/copyright file. 
The second one outputs on stdout coalesced copyright information 
gathered from source files.

Neither tools are perfect, but they produce information quite close 
to the required result.

See also:
https://ddumont.wordpress.com/2015/04/05/improving-creation-of-debian-copyright-file/
https://ddumont.wordpress.com/2015/05/31/improving-update-of-existing-debiancopyright-file/

All the best

[1] 
http://manpages.debian.org/cgi-bin/man.cgi?query=cme&apropos=0&sektion=0&manpath=Debian+unstable+sid&format=html&locale=en
[2] 
http://manpages.debian.org/cgi-bin/man.cgi?query=scan-copyrights&apropos=0&sektion=0&manpath=Debian+unstable+sid&format=html&locale=en
-- 
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/-o-   irc: dod at irc.debian.org

Re: Ideas to improve dpkg/ucf with hooks [was: Putting default config files in /usr]

[Vincent Danjean]

Le 13/11/2015 18:39, Manoj Srivastava a écrit :
> Hi,
> 
> Adding in his or callbacks would be easy enough. Do you have an
> idea of what you would need for your use case?

  I've some ideas, but no final proposition. Some thoughts:

- to be able to know :
  * the old file and the new (proposed) one before merging
  * the new file after merge (can be difficult if the 'merge' is done
manually after the package installation) => should probably be done
as currently by etckeeper, ie with a apt hooks after installation
and a crontab job.
  * all of this with the package (and the versions) involved
- to be able to propose new merge strategies:
  * 3 ways merges even for packages that does not use the --three-way
option
  * cme based merge/update (if possible)
  * specific merge strategies provided by other tools (for all or for
some config files)
- to be able to ask dpkg to use ucf (or to use the same callback
  and extended merge strategies) [because ucf does not cover lots of
  config files for now]
- to improve dpkg so that ucfr can register files into the dpkg file
  database (so that dpkg -S also works)

And, after the current discussion, I have new thoughts for more complex
things:
- to be able to track external directory (/usr/...) as 'models' for
  config files and to present the same kind of resolution conflict
  when a file in /etc is present that override a modified default config
  file in /usr
This can be a bit more difficult to integrate if we want to be
  able to do a kind of 'git diff official..master' to get only local
  config modification. And if we want to support partial override (such
  as services.d systemd directories)

  Regards
Vincent

> Manoj
> 
> On November 13, 2015 9:22:45 AM PST, Vincent Danjean  @free.fr> wrote:
> 
> Le 13/11/2015 17:47, Marc Haber a écrit :
> 
> Actually, I don't quite see why ucf would need hooks since it is
> called from the maintainer scripts, giving the local admin full power
> of creativity anyway. Chances are that ucf is already the right tool
> to maintain systemd and friends the Debian way if the Debian packaging
> team would be willing to.
> 
> 
> Because I cannot see a way (but diverting ucf itself) to interface it
> with etckeeper so that original maintainer files will be kept in a
> different git branch with merges in the master branch to keep the
> modified config.
> 
>   Regards
> Vincent
> 
> 
> -- 
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#805089: ITP: s2n -- lightweight implementation of the TLS/SSL protocols

[Daniel Stender]

Package: wnpp
Severity: wishlist
Owner: Daniel Stender 

* Package name: s2n
  Version : 0.0+git20150909.674df33
  Upstream Author : Colm MacCárthaigh 
* URL : https://github.com/awslabs/s2n
* License : Apache-2.0
  Programming Lang: C
  Description : lightweight implementation of the TLS/SSL protocols

S2N ("Signal to noise") is a C99 implementation of the TLS/SSL protocols.
One of the main goals of this project is to keep the code base as lean as
possible to be fast and to reduce security risks. s2n implements SSLv3,
TLS1.0, TLS1.1, and TLS1.2. For encryption, s2n supports 128-bit and
256-bit AES, in the CBC and GCM modes, 3DES, and RC4.

Re: Ideas to improve dpkg/ucf with hooks [was: Putting default config files in /usr]

[Dominique Dumont]

Le samedi 14 novembre 2015, 15:50:28 15:50:28 Vincent Danjean a écrit :
> And, after the current discussion, I have new thoughts for more complex
> things:
> - to be able to track external directory (/usr/...) as 'models' for
>   config files and to present the same kind of resolution conflict
>   when a file in /etc is present that override a modified default config
>   file in /usr

There's a similar mechanism supported by cme which is named "layered 
configuration". 

This was developed for multistrap whose's configuration 
uses base configuration files and override  files. This is also used by ssh 
model where
~/.ssh/config overrides the values defined in /etc/ssh/config

I admit that this feature is somewhat underdocumented [1] :-/

All the best

[1] 
http://search.cpan.org/dist/Config-Model-Itself/lib/Config/Model/models/Itself/ConfigRead.pod#default_layer_-_How_to_find_default_values_in_a_global_config_file
   and 
http://search.cpan.org/dist/Config-Model/lib/Config/Model/Value/LayeredInclude.pm

-- 
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/-o-   irc: dod at irc.debian.org

Re: copyright files can be generated by cme (was Re: Copyright file granularity)

[Neil Williams]

On Sat, 14 Nov 2015 15:28:02 +0100
Dominique Dumont  wrote:

> Le vendredi 13 novembre 2015, 16:10:14 16:10:14 Wookey a écrit :
> > However there are numerous copyright holders and files contributed
> > on various dates so I spent several hours making this copyright
> > file:
> > https://sources.debian.net/src/ompl/1.0.0%2Bds2-1/debian/copyright/
> > with each copyright owner split out into a separate stanza.  
> 
> Detailed copyright files can be generated by cme. You can either run 
> "cme update dpkg-copyright " [1] or "scan-copyrights" [2] . (you need
> to install cme and lib-config-model-dpkg-perl)
> 
> The first one tries its best to merge current copyright with existing
> debian/copyright file. The second one outputs on stdout coalesced
> copyright information gathered from source files.
> 
> Neither tools are perfect, but they produce information quite close 
> to the required result.

scan-copyrights must get much better handling of non-text formats.
I tried it with a package containing a lot of png files, the example at
the top of the manpage failed because the output of scan-copyrights was
a binary file. (It's a text-like file which contains binary snippets
pretending to be copyright information.)
 
No command line options, no way of preventing it wrapping itself into
knots. I also complained about .pyc files, fine I can remove those.

The output was 46K compared to the current 8K.

$ cme update dpkg-copyright
62;9;c62;9;c62;9;c62;9;c62;9;c

That's output slurped into the next command line buffer of this
terminal which needs Ctrl-C.

Similar problems with packages which contain images. It's not that hard
to handle images in ways that don't spool random characters to the
output.

So no, detailed copyright files for non-trivial packages cannot be
generated and the tools produce nothing close to the required result.
Trivial packages don't need generation.

It's not that neither tool is perfect, neither tool seems to have been
tried with actual packages that may need the tool.

Even with a trivial package, scan-copyrights produces output which
if used as debian/copyright would get rejected by lintian and ftpmaster.

Much more work needs to be done, IMHO, especially considering the
dozens of dependencies which typically need to be installed and which
seem to do nothing useful compared to using a bit of sed and grep.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpnAILjniN78.pgp
Description: OpenPGP digital signature

Bug#805106: ITP: vsearch-data -- example data for vsearch tool for processing metagenomic sequences

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: vsearch-data
  Version : 1.0.0
  Upstream Author : Torbjørn Rognes 
* URL : https://github.com/torognes/vsearch-data/
* License : BSD
  Description : example data for vsearch tool for processing metagenomic 
sequences
 Open and free 64-bit multithreaded tool for processing metagenomic sequences,
 including searching, clustering, chimera detection, dereplication, sorting,
 masking and shuffling
 .
 The aim of this project is to create an alternative to the USEARCH tool
 developed by Robert C. Edgar (2010). The new tool should:
 .
  - have open source code with an appropriate open source license
  - be free of charge, gratis
  - have a 64-bit design that handles very large databases and much more
than 4GB of memory
  - be as accurate or more accurate than usearch
  - be as fast or faster than usearch
 .
 This package only contains data to run the vsearch test suite.


Remark: Upstream has split the test data which were originally part of
the vsearch package into a separate source.  To be able to run the
unit tests and verify the functionality of vsearch the data are now
in a separate source package.  It will be maintaines by the Debian Med
team at
  Vcs-Svn: 
svn://anonscm.debian.org/debian-med/trunk/packages/vsearch-data/trunk/

Re: django-ajax-selects lintian errors/warnings

[Brian May]

Neil Williams  writes:

>> E: django-ajax-selects source: source-is-missing
>> ajax_select/static/ajax_select/js/bootstrap.js
>
> If this really is your own source code, a filename change would be one
> way to do it. In most cases, bootstrap is not written by this upstream
> but has been included into the upstream VCS from another location.

No, I have another package with bootstrap.js and lintian has no
problems. Suspect it might be due to line length. There are several bug
reports on this, the one I can find is:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802028


>> python3-ajax-select: image-file-in-usr-lib
>> usr/lib/python3/dist-packages/ajax_select/static/ajax_select/images/loading-indicator.gif
>
> This matters more when the package list from this source package
> contains Architecture: any instead of Architecture: all binaries, which
> is uncommon with django apps. With Arch: any, the files in /usr/lib/
> would be duplicated for each arch build which is a clear problem to be
> avoided.

This is Architecture: all, so sounds like not a problem here.


>> E: python3-ajax-select: privacy-breach-uses-embedded-file
>> usr/lib/python3/dist-packages/ajax_select/static/ajax_select/js/bootstrap.js
>> You may use libjs-jquery-ui package.
>
> You may indeed - replace the file with a symlink in debian/rules and
> add to Depends.

Replace what file with a symlink? bootstrap.js isn't the problem itself,
the problem is bootstrap.js referencing jquery.min.js from an external
source. The library itself doesn't currently come with a copy of jquery.

In this case the python*-ajax-select packages are not intended to be
used by users, rather they are libraries intended to be used by other
applications (Django apps) which are used by users. There simply isn't a
single standard way I know of providing and using one and only one
jquery in Django libraries. (no - Django Media objects don't help)

Maybe I should raise this issue with the Django developers? Even if I
did, came up with a proposal (I don't have one), and we agreed to a
solution, we still need a solution for now, with the current release of
Django.

If I tell upstream to include a copy of jquery.min.js and/or jquery.js
in the static directory (this is another issue[1]), it will get exported
in all Django apps that use this library, including those that don't
need or want it. Maybe this is considered a reasonable tradeoff - it is
unlikely to cause conflicts due to the directory name used, however I
come from the school of thought that you shouldn't be publishing files
unless there actually is a need to publish the files.

Apologies if I seem argumentative, however I really don't see a good
solution to this. The best decision really depends on the Django app
that uses this library, and upstream have tried to make it easier to get
started using the library in such a way it has minimal downsides for
Django apps that want to include their own version of jquery.



>> privacy-breach-uses-embedded-file - this is only correct if used by an
>> application that does not import jquery symbols itself. If the
>> application already has loaded jqueblry and jquery-ui from, say a
>> local source, I believe there is no privacy issue:
>> 
>> // load jquery and jquery-ui if needed
>> // into window.jQuery
>> if (typeof window.jQuery === 'undefined') {
>>   document.write('

Re: Copyright file granularity

[Osamu Aoki]

Hi,

On Fri, Nov 13, 2015 at 08:34:11PM +0100, Stephen Kitt wrote:
> On Fri, 13 Nov 2015 10:51:11 -0800, Steve Langasek  wrote:
> > On Fri, Nov 13, 2015 at 04:10:14PM +, Wookey wrote:
> [...]
> > And we should have better tools to generate debian/copyright files - this
> > shouldn't be an intensive manual process.  Unfortunately the only tool I'm
> > aware of that does this is coupled to cdbs.
> 
> I've used debmake which does a reasonable job of generating initial copyright
> files and checking them. Lintian is also getting better at the latter.

Due to the fact "debmake -cc" does bunching of the same copyright
claims, it intentionally picks up the first instance of the copyright
claim.  I know that is a design flaw which needs to be addressed.  (This
is one of the slowest part of the code. That is another reason why I am
reluctant to pick up many.)

Since license check only print its judgement, it does full text match
printing multiple matches.

If any of you find issues, please file bug report with pointer to the
problematic file example to debmake.

Osamu

Re: Copyright file granularity

[Osamu Aoki]

Hi,

On Fri, Nov 13, 2015 at 10:51:11AM -0800, Steve Langasek wrote:
...
> It is important to list all copyright holders; this is not something that
> it's "easy enough" to look up in the source, because many of these free
> software licenses require that you reproduce the copyright statement
> whenever you distribute binaries.
> 
>   2. 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.
> 
>   (/usr/share/common-licenses/BSD)
> 
> 
> To avoid accidental failures to comply with such license terms, Debian
> policy requires that *all* packages include the copyright information.

Please note one type of de-facto exception which is not documented but
widely accepted.  FTP master has accepted such packages with the GNU
permissive type license on autotools generated files.   I see almost no
one follow the rule literary on these files. They are slightly different
files to files and are nothing but noise for then purpose we use
debian/copyright if we pedantically list them.

In normal usage of the debmake parogram now, it drops all GNU permissive
license listing for autotools generated files.

> And if we want the debian/copyright file to be readable afterwards, the
> tools are going to need to make some smart decisions about grouping of
> copyright stanzas, and not just list one for each (license, copyright
> holders, copyright dates) tuple.

That's done and simple.  Spaces and line breaks does not affect the
grouping.

Tough part is when you see multiple copyright like text apears on the
file, what to do.  iThis involves judgement and huristics when to give
up and which file to skip for scanning.   A large translation dictionary
text file with a word "copyright" listed next to "著作権, 版権" may
cause false positive.  (I encounterd such file).
 
> As an example of what I mean by "smart" groupings, I offer up the
> debian/copyright of edk2, attached.  Unfortunately, I had to craft this
> monster by hand; and there are no tools to validate that it remains
> correct[1] after updating to new upstream releases.
> 
> Having a machine-readable copyright format is only the first step.  If I
> ever get a round tuit, my goals are:
> 
>  - a stand-alone tool that can generate a debian/copyright (with "smart"
>stanza grouping) from the output of licensecheck

Currently, I recommend to use debmake to make a nice initial template
copyright file and also check problematic non-free license with
licensecheck.  Then human manual work.

>  - a standard format for hinting this tool in the debian directory when the
>answers licensecheck detects by inspecting the source are inaccurate

This is interesting idea.

>  - a stand-alone tool that can compare any two machine-readable copyright
>files and a given source tree and tell you whether they are equivalent

"debmake -k" checks current source against existing debian/copyright
(It allow slightly different words such as name of organization to be
changed ...)

> The last is key, because it gives us automation around making sure
> debian/copyright is accurate and stays accurate.

Yes.  And focus should be non-free detection and incompatible license
mixture.  So we should not bother too much on permissive license like
the GNU permissive ones for autotools generated files.

Just for fun, I checked edk2 ;-)

I think some ISC license files are labeled as BSD-4-clause.  They are
human errors.

But debmake makes more mistakes than human.  Hmmm.. debmake needs to
improve on Intel-Fat-Driver license.  Hmmm... public domain is also non
optimal result although file has text "This file is in the public
domain,".

- BSD-4-clause
+ BSD-4-Clause-UC

This difference comes from the pedantic SPDX-ism I use.
  http://spdx.org/licenses/

Hmmm... SPDX seems to be updated.  That laso needs to be addressed.  I
don't know how precise we classify.

$ debmake -k
 ...
=== debian/copyright checked for 12165 data ===
Pattern #00: *
  File: StdLib/LibC/Time/tzfile.h
StdLib/LibC/Time/ZoneProc.c
StdLib/LibC/Time/Time.c
StdLib/LibC/Time/TimeVals.h
- BSD-2-clause
+ Public domain

Pattern #38: FatBinPkg/*
  File: FatBinPkg/License.txt
- Intel-Fat-Driver
+ BSD-3-Clause

Pattern #39: FatPkg/*
  File: FatPkg/FatPkg.dsc
FatPkg/FatPkg.dec
FatPkg/License.txt
FatPkg/FatPei/FatPei.inf
FatPkg/EnhancedFatDxe/Fat.inf
- Intel-Fat-Driver
+ BSD-3-Clause

Pattern #116: StdLib/LibC/Time/strftime.c
  File: StdLib/LibC/Time/strftime.c
- BSD-4-clause
+ BSD-4-Clause-UC

Pattern #118: StdLib/LibC/String/strsep.c
  File: StdLib/LibC/String/strsep.c
- BSD-4-clause
+ BSD-4-Clause-UC

Pattern #127: StdLib/LibC/Stdio/vswscanf.c
  File: StdLib/LibC/Stdio/vswscanf.c
- BSD-4-clause
+ BSD-4-Clause-UC

Pattern #130: StdLib/Include/sys/*
  File: StdLib/Include/sys/ansi.h
StdLib/Include/sys/EfiCdefs.h
StdLib/Inc