Re: linux-libre source tarballs

[Alexandre Oliva]

On May  6, 2021, Maxim Cournoyer  wrote:

> Alexandre Oliva  writes:

>> recipes as to the possibilities of getting to the GNU Linux-libre
>> sources from it, how to verify signatures, etc

> I for one have not seen them.  Would you mind making them available
> somewhere?  I'd be interested in having a look.

Not as extensive as I thought ;-)
unless I found only an early version,
but so here it goes:


* Download one release as git checkout:

git clone -b sources/v$version --single-branch \
  git://linux-libre.fsfla.org/releases.git linux-libre-$version/


* Example substitutions:

version=5.7-gnu upversion=5.7
prefix=linux-$upversion/


* If you plan on verifying any releases:

git archive --remote=git://linux-libre.fsfla.org/releases.git \
  --format tar master | tar -x -O keyring.gpg | gpg --import -


* If you plan on verifying release $version:

git archive --remote=git://linux-libre.fsfla.org/releases.git \
  --format tar logs/v$version | tar -x &&
if test -f linux-libre-$version.git.tar.sign; then
  prefix=linux-libre-$version/ targit=.git
else
  prefix=linux-$upversion/ targit=
fi


* Download/archive one release as git tarball:

# Use the conditional prefix above to be able to verify.
git archive --remote=git://linux-libre.fsfla.org/releases.git \
  --format tar.gz --prefix=$prefix sources/v$version \
  -o linux-libre-$version$targit.tar.gz


* Verify one release in git repo:

git archive --format tar --prefix=$prefix sources/v$version |
gpg --verify logs/v$version/linux-libre-$version$targit.tar.sign -


* Verify one release in a (gzip-compressed) tarball:

# Must have used the conditional prefix above to verify.
zcat linux-libre-$version$targit.tar.gz |
gpg --verify linux-libre-$version$targit.tar.sign -


* Download and verify a released compressed tarball:

ext=lz comp=lzip # ext=bz2 comp=bzip2 # ext=xz comp=xz
wget https://linux-libre.fsfla.org/pub/linux-libre/releases\
/$version/linux-libre-$version.tar.{$ext,sign} &&
$comp -d < linux-libre-$version.tar.$ext |
gpg --verify linux-libre-$version.tar.sign - # no $targit


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

About emacs-pyim-basedict

[tumashu]

Hello


 emacs-pyim-basedict is a GNU elpa package, suggest use elpa method :-)



http://git.savannah.gnu.org/cgit/guix.git/commit/?id=ccaf29afd0b8093067dbf43d48e21d7a5e741006

Re: The purpose of the "license" list of a Guix package (Was: Re: Jam: which licence is this?)

[Leo Prikler]

Am Samstag, den 08.05.2021, 22:52 +0200 schrieb Maxime Devos:
> Leo Prikler schreef op za 08-05-2021 om 12:16 [+0200]:
> > [... something about dependencies and copyleft ...]
> > [...]
> > However, compliance is not *that* simple.  If you're dealing with
> > copyleft, providing the source is not enough, you also need to
> > license
> > your own work under that copyleft license, e.g. the GPL. [...]
> 
> Just checking if our understanding is the same, as I have seen a
> discussion on IRC where people the situation described below was
> _not_ legally acceptable.
Disclaimer: IANAL, but I'd argue the following.

> Suppose we have a GPLv3+ library, say guile-jwt.
> Suppose there is a (group of) developer(s) writing an application
> using guile-jwt. Let's call the application APP, and the developer(s)
> DEV.
At this point in time, I'd argue, that APP is "a work based on guile-
jwt", as defined in section 0 of the GPLv3.

> A hypothetical situation:
> 
>   * Suppose DEV is not very fond of licensing APP under a copyleft
> license,
> and insteads prefers something with basically no licenses.
>   * DEV wants to choose, say, license:expat.
>   * license:expat is not license:gpl3
>   * Would this be a problem? I would think not. While APP used 
> guile-jwt, it doesn't include or modify its source code.
I would think yes.  If what you said was true about Guile code, then
any proprietary code could just link against the GPL willy-nilly (well,
they'd have to take care to explicitly call dlopen, but you get the
point).  That obviously is not the case, the LGPL exists for a reason.

> So I would think DEV must still respect GPL for the combination 
> (e.g., if DEV provides binaries for APP, they must include source
> code for guile-jwt *and* APP), and theoretically someone may fork
> APP to replace guile-jwt with a hypothetical guile-jwt/expat, and
> at that point the GPL doesn't apply anymore to the combination
> APP-with-guile-jwt/expat.
I agree, that they'd at least have to provide the Corresponding Source
as laid out in section 6, but I also think they'd have to follow
section 4 and 5, in particular 5c.
The code within APP, that is not directly related to guile-jwt may very
well be Expat, and DEV might even go so far as to claim, that "just the
source" of the other stuff is Expat as well, but APP as a package must
be GPL'd (unless APP is only using public domain or Expat parts of
guile-jwt if they exist).

Once someone does have an expat-fork of guile-jwt and it's fair to no
longer assume APP to be based on guile-jwt, but rather guile-jwexpat,
the package as a whole can be distributed under the Expat license.

> I would find it interesting to know if some ‘legal people’ have
> worked out this situation.
Which ones?  The ones who tell you "you must form a bill of materials"
or the ones who tell you "just provide the source"?  :)

Regards,
Leo

PS: The above was written under the assumption, that you write your app
in a way, that it calls guile-jwt directly, not by forking guile and
communicating to it through pipes or sockets.

Re: Expat 2.3.0 has been released

[Sebastian Pipping]

Hello everyone,


just a quick heads up that there will be a new release of libexpat with
security fix in a few weeks.  Unless I looked in the wrong place, I
noticed that your distro has not updated to libexpat 2.3.0 as of today.
 If you ran into any issues with packaging 2.3.0, please let me know now
so that I can fix things upstream for you and everyone while there is
still a window before next releases to do so.  Thank you!

Best



Sebastian


On 25.03.21 21:27, Sebastian Pipping wrote:
> Hello everyone!
> 
> 
> Expat 2.3.0 — simplified — brings…
> 
>   - bugfixes,
> 
>   - improvements to both build systems, and
> 
>   - improvements to xmlwf usability.
> 
> Please see the changelog at [1] for more details.
> 
> 
> If you have patches for Expat that are still required
> with version 2.3.0, please send them my way.  Thank you!
> 
> Best
> 
> 
> 
> Sebastian
> 
> 
> [1] https://github.com/libexpat/libexpat/blob/R_2_3_0/expat/Changes
> 

Re: The purpose of the "license" list of a Guix package (Was: Re: Jam: which licence is this?)

[Maxime Devos]

Leo Prikler schreef op za 08-05-2021 om 12:16 [+0200]:
> [... something about dependencies and copyleft ...]
> [...]
> However, compliance is not *that* simple.  If you're dealing with
> copyleft, providing the source is not enough, you also need to license
> your own work under that copyleft license, e.g. the GPL. [...]

Just checking if our understanding is the same, as I have seen a discussion
on IRC where people the situation described below was _not_ legally acceptable.

Suppose we have a GPLv3+ library, say guile-jwt.
Suppose there is a (group of) developer(s) writing an application using
guile-jwt. Let's call the application APP, and the developer(s) DEV.

A hypothetical situation:

  * Suppose DEV is not very fond of licensing APP under a copyleft license,
and insteads prefers something with basically no licenses.
  * DEV wants to choose, say, license:expat.
  * license:expat is not license:gpl3
  * Would this be a problem? I would think not. While APP used guile-jwt,
it doesn't include or modify its source code.

So I would think DEV
must still respect GPL for the combination (e.g., if DEV provides binaries
for APP, they must include source code for guile-jwt *and* APP),
and theoretically someone may fork APP to replace guile-jwt with
a hypothetical guile-jwt/expat, and at that point the GPL doesn't
apply anymore to the combination APP-with-guile-jwt/expat.



I would find it interesting to know if some ‘legal people’ have worked out
this situation.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

GNU Guix 1.3.0rc2 available for testing!

[Maxim Cournoyer]

Hello Guix!

A second RC for the upcoming 1.3.0 release is now available for testing:

  source:
https://alpha.gnu.org/gnu/guix/guix-1.3.0rc2.tar.gz

  binary tarball (to install on a “foreign distro”):
https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc2.aarch64-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc2.armhf-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc2.i686-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc2.powerpc64le-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc2.x86_64-linux.tar.xz

  system installation:

https://alpha.gnu.org/gnu/guix/guix-system-install-1.3.0rc2.i686-linux.iso

https://alpha.gnu.org/gnu/guix/guix-system-install-1.3.0rc2.x86_64-linux.iso

  virtual machine image:

https://alpha.gnu.org/gnu/guix/guix-system-vm-image-1.3.0rc2.x86_64-linux.qcow2

SHA256 hashes:

18baef75195d702f6b9f8b623d8a64164aad63581b1478e1668e81ca6e6b6425
guix-1.3.0rc2.tar.gz
8a7d2fab6a46f0bdd753a1d7cb2e0fb1d6bbdb27b951c357eb6b2655bca768ce
guix-binary-1.3.0rc2.aarch64-linux.tar.xz
e60ce44cecb039755348688234092e113a7280d059c460395ec4ef51c2d3239b
guix-binary-1.3.0rc2.armhf-linux.tar.xz
082f5bdb159dc09dac31a8c64b3b2e18cbf22c420fb17ad15f8f7d813a6701db
guix-binary-1.3.0rc2.i686-linux.tar.xz
1cad283b1d13983c25622d68f7492f7f11271e22df592a74372b7f4033eab5f1
guix-binary-1.3.0rc2.powerpc64le-linux.tar.xz
83dc8f00d3c0c02468900a875db83c70b9812e94487dfe209965527c294d5795
guix-binary-1.3.0rc2.x86_64-linux.tar.xz
ac9364ecf11c7f6a307e24eba1a42d04babeb4170763d91532e66caf461b0e69
guix-system-vm-image-1.3.0rc2.x86_64-linux.qcow2
b4bfe750615331b0dfd344dc842cfb0e72b1b87f67b62ce2bcdd823509e4d70d
guix-system-install-1.3.0rc2.i686-linux.iso
479a4a1bf7dbb0149b62fa9380014fa5dc881664fb2e43117d6c6a3bc69cc506
guix-system-install-1.3.0rc2.x86_64-linux.iso

All these files have an associated ‘.sig’, an OpenPGP signature that you
can verify as explained at
 [0].

Compared to RC1, this release candidate has seen minor improvements such
as fixes in the build system, improvements to the installation script
and the addition of the spice-vdagent service to the provided VM image.
The installation script can now automatically retrieve the required
OpenPGP keys.  The ISO images are no longer manually compressed, which
should make them easier to use.  The VM .qcow2 images are no longer
manually compressed with xz, as the qcow2 format used by 'guix system
image -t qcow2' is already compressed.  The 'wget' utility is now
included out of the box.  A locale warning problem was fixed.

You can help by:

  1. Testing the binary tarball on the distro of your choice.  You can
 download 
.
  Uncomment the
 ‘GNU_URL’ variable assignment that refers to alpha.gnu.org and it
 should pick up 1.3.0rc2 automatically.

  2. Testing the graphical installer of Guix System.

  3. Testing the VM image.

In any case, please report success, failure, and annoyances in this
thread.

Thanks to those who have provided feedback so far!  The planned release
date for v1.3.0 is this Monday, May 10th.

Thank you!

Maxim

[0] Replacing https://sv.gnu.org/people/viewgpg.php?user_id=15145 by
https://sv.gnu.org/people/viewgpg.php?user_id=127547 in the
instructions.  This will only be reflected on the website after the
release is made.

Re: Interesting reading for minimalists, esp mes folks? :)

[Bengt Richter]

On +2021-05-08 12:56:36 +0200, Bengt Richter wrote:
> Hi minimalists :)
>
Forgot the main project link [6] ;/

> In case you hadn't yet come across this (LWN did a piece [5] about a year ago,
> which was the first I heard of it. (Chasing a dream led me to check
> more current status) Enjoy :)
> 
> [1] 
> https://drops.dagstuhl.de/opus/volltexte/2020/11779/pdf/OASIcs-NG-RES-2020-3.pdf
> [2] https://github.com/bao-project/bao-demos
> [3] https://github.com/bao-project/bao-hypervisor
> [4] https://github.com/bao-project/bao-hypervisor#readme
> [5] https://lwn.net/Articles/820830/
  [6] http://www.bao-project.org/
> 
> To whet your appetite (from the README at [4]):
> 
> --8<---cut here---start->8---
> Bao has no external dependencies, such as on privileged VMs running 
> untrustable, 
> large monolithic general-purpose operating systems (e.g., Linux), and, as 
> such, 
> encompasses a much smaller TCB.
> 
> Bao originally targets the Armv8-A architecture, but there is experimental 
> support
> for the RISC-V architecture. The full list of supported (and work in 
> progress) 
> platforms is presented below:
> 
> - [x] Xilinx Zynq UltraScale+ MPSoC ZCU102 (Armv8-A)
> - [x] Xilinx Zynq UltraScale+ MPSoC ZCU104 (Armv8-A)
> - [x] Ultra96 Zynq UltraScale+ ZU3EG (Armv8-A)
> - [x] 96Boards HiKey 960 (Armv8-A)
> - [ ] NXP MCIMX8M-EVK (Armv8-A) - wip
> - [ ] NXP MCIMX8QM-CPU (Armv8-A) - wip
> - [ ] 96Boards ROCK960 (Armv8-A) - wip
> - [ ] QEMU virt (Armv8-A) - wip
> - [ ] QEMU virt (RISC-V rv64) - wip
> 
> **NOTE**: This is work in progress! Don't expect things to be complete. 
> Use at your own risk.
> --8<---cut here---end--->8---
> 
> -- 
> Regards,
> Bengt Richter
> 

-- 
Regards,
Bengt Richter

Re: The purpose of the "license" list of a Guix package (Was: Re: Jam: which licence is this?)

[Leo Prikler]

Am Samstag, den 08.05.2021, 13:17 +0200 schrieb Ricardo Wurmus:
> Leo Prikler  writes:
> 
> > For the record, what command gives you transitive source 
> > closure?  I
> > can see transitive binary closure with `guix pack`, but I don't 
> > think
> > we do source closure unless asked to `guix build 
> > --no-substitutes`. 
> > Maybe a missing feature?
> 
> “guix build --sources=transitive hello” builds the source 
> derivations for hello and all its transitive inputs.
Documentation: N
Me: 0

Re: The purpose of the "license" list of a Guix package (Was: Re: Jam: which licence is this?)

[Ricardo Wurmus]

Leo Prikler  writes:

For the record, what command gives you transitive source 
closure?  I
can see transitive binary closure with `guix pack`, but I don't 
think
we do source closure unless asked to `guix build 
--no-substitutes`. 
Maybe a missing feature?


“guix build --sources=transitive hello” builds the source 
derivations for hello and all its transitive inputs.


--
Ricardo

Interesting reading for minimalists, esp mes folks? :)

[Bengt Richter]

Hi minimalists :)

In case you hadn't yet come across this (LWN did a piece [5] about a year ago,
which was the first I heard of it. (Chasing a dream led me to check
more current status) Enjoy :)

[1] 
https://drops.dagstuhl.de/opus/volltexte/2020/11779/pdf/OASIcs-NG-RES-2020-3.pdf
[2] https://github.com/bao-project/bao-demos
[3] https://github.com/bao-project/bao-hypervisor
[4] https://github.com/bao-project/bao-hypervisor#readme
[5] https://lwn.net/Articles/820830/

To whet your appetite (from the README at [4]):

--8<---cut here---start->8---
Bao has no external dependencies, such as on privileged VMs running 
untrustable, 
large monolithic general-purpose operating systems (e.g., Linux), and, as such, 
encompasses a much smaller TCB.

Bao originally targets the Armv8-A architecture, but there is experimental 
support
for the RISC-V architecture. The full list of supported (and work in progress) 
platforms is presented below:

- [x] Xilinx Zynq UltraScale+ MPSoC ZCU102 (Armv8-A)
- [x] Xilinx Zynq UltraScale+ MPSoC ZCU104 (Armv8-A)
- [x] Ultra96 Zynq UltraScale+ ZU3EG (Armv8-A)
- [x] 96Boards HiKey 960 (Armv8-A)
- [ ] NXP MCIMX8M-EVK (Armv8-A) - wip
- [ ] NXP MCIMX8QM-CPU (Armv8-A) - wip
- [ ] 96Boards ROCK960 (Armv8-A) - wip
- [ ] QEMU virt (Armv8-A) - wip
- [ ] QEMU virt (RISC-V rv64) - wip

**NOTE**: This is work in progress! Don't expect things to be complete. 
Use at your own risk.
--8<---cut here---end--->8---

-- 
Regards,
Bengt Richter

Re: The purpose of the "license" list of a Guix package (Was: Re: Jam: which licence is this?)

[Leo Prikler]

Hi,

Am Freitag, den 07.05.2021, 11:31 -0700 schrieb Chris Marusich:
> My understanding is that the intent of the "license"
> field (which can be a list) in a Guix package is to call out the
> "main"
> (deliberately vague here) licenses related to the code, not to
> provide
> an exhaustive or authoritative description of all the licenses
> affecting
> every file in every possible situation.  As Leo has demonstrated, a
> package's license field (like probably most summaries of license
> information) is surely not exhaustive or authoritative; the licenses
> in
> the source code files themselves are authoritative.
I agree with both you and the other Leo, but I think we're getting a
little off-topic here.  The reason,why it's necessary to argue about
jam's license is because (as I see it) we don't have a jam package and
it is a necessary tool to build a package someone wants to contribute. 

The reason why we don't care about this when it comes to Autotools is
that we have Autotools packaged, and it is expected that all the stuff
generated by it exists in the package post the configure phase of a
package that uses gnu-build-system unmodified.  This makes it, so that
this question only ever arises for packages distributing `make dist`-
generated packages in the first place, and the question for those
should not be "Do we include those licenses", but "Do we trust, that
this was really generated with `make dist`"?

> My understanding is that a packager is expected to audit the licenses
> in
> the files when adding the package.  If an exhaustive audit is not
> feasible (which is often the case), they should perform a reasonable
> spot check and then list the "main" licenses in play in the licenses
> file.  As in the GNU Hello case, there is clearly a judgment call
> regarding what goes into the Guix package's licenses list, since a
> simple list cannot describe everything.  In general, even if
> hypothetically you did do an exhaustive audit of all files, it is not
> practical to try to describe all the licensing implications in the
> Guix
> package definition.  I don't think that's the purpose of the license
> field.
I agree, that the main license (the one that appears first in the
license list, or the one that appears alone) should more or less cover
"the whole package", but if there's a range of *actual* source files
(including source files from which a bizarre compiler or build tool is
built, that is afterwards used by the package), that should imo be
included in that list with a suitable comment.  

I don't fault any packager, who misses one or two licenses in some
obscure hidden file, but if someone finds and adds them, I think that
patch should likely be accepted.

> One more thing.  I have always felt that the license field of a Guix
> package is intended to call out the licenses that apply to the built
> output of the package in particular.  In other words, I think the
> license field is intended to call out the licenses that are most
> likely
> to apply in the situation where you "link" with the built output of
> the
> package.  That is the purpose of many packages: to be "linked" from
> other source code.  Since it is often the case that software you
> write
> will not be "linking" with the package's build scripts, but rather
> with
> the package's built output, the license of the build scripts are less
> relevant for that use case.
I think this misses the point when it comes to stuff like the artwork
for a game.  Clearly, that artwork is a substantial part of the game
and deserves a place in the license field.  The other way around,
whenever you encounter some Creative Commons license with the comment
"artwork", this might not concern linkage (unless the artwork is baked
into the program itself, as might be the case in some GTK and Qt
applications, but those are rarely "linked" from other programs), but
rather redistribution.

> In the end, I think a packager is expected to be operating in good
> faith, in accordance with the FSDG.  This means that packagers look
> for
> freedom issues and address them when found.  It does not mean that
> packagers are expected to provide a detailed "bill of materials" for
> every single package, although that is certainly something that some
> people think is important (and some people don't).
> 
> This reminds me of the following fun debate from FOSDEM 2020:
> 
> "Does Careful Inventory of Licensing Bill of Materials Have Real
> Impact
> on FOSS License Compliance?"
> https://archive.fosdem.org/2020/schedule/event/debate_license_compliance/
> 
> I think you might enjoy watching it.  Basically, the "negative"
> argument
> (careful inventory of licensing bill of materials does NOT have a
> real
> impact on FOSS license compliance) is somewhat relevant here, and it
> went something like this: the transitive closure of required source
> code
> itself is a kind of "bill of materials", and if you only use free
> software, it is always easy to comply - just provide the