Re: antioxidant update: librsvg builds, and other things (core-updates)

[Maxime Devos]

On 28-08-2022 00:04, Liliana Marie Prikler wrote:

Am Samstag, dem 27.08.2022 um 22:01 +0200 schrieb Maxime Devos:

On 27-08-2022 21:54, Liliana Marie Prikler wrote:

* Due to how regularised the Rust build system is, it's feasible
to compile tests even when cross-compiling (*), so cross-compiled
could run the cross-compiled tests on the system they are
cross-compiling for after the cross-compilation to verify their
cross-compiled software.

How exactly does this work without emulating the system in
question?

It works by not performing any work except compilation -- Guix'
responsibility would only be to cross-compile and install the tests
(_not_  running them), you are supposed to install the cross-compiled
thing (including tests) on the target system and run the tests on the
target system.

This doesn't strike me as a rust-specific setup, though.  In principle,
you should be able to do the same with a C/C++ program, but most of the
time "make check" implies both building and running the tests.


The difference between Rust and many C/C++ setups here, is that with 
Rust it's trivial to only compile and install the tests without running 
them (currently, antioxidant-build-system compiles+installs and runs the 
tests in separate phases), whereas in case of C/C++, there usually isn't 
a convenient '"make install-the-tests-without-running-them" target, 
rather building and running the tests is combined in a single "make 
check" as you note.


As I've written previously:


Due to how regularised the Rust build system is, it's feasible
to compile tests even when cross-compiling (*)
but that does not appear to be the case for C/C++, as you've noted with 
your comments about "make check" both building and running the tests.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: guix refresh to a specific version?

[Hartmut Goebel]

Am 07.07.22 um 09:45 schrieb Ludovic Courtès:

I’ll be monitoring guix-patches for the final version.  :-)


It took some time, and here it is: https://issues.guix.gnu.org/57460

--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

'staging' freeze

[Marius Bakke]

Hi Guix,

The 'staging' branch is in a pretty good shape, let's get it merged!

Highlights from this branch:

* Rust 1.60
* Gstreamer 1.20.3
* Sphinx 5.1.1
* ruby-nokogiri and its dependencies is no longer in the bootstrap path
  of TeX Live, so they can be more freely updated on 'master'

I'm fairly rusty when it comes to Cuirass, and don't see a button to
start the jobset here even when authenticated:

  https://ci.guix.gnu.org/jobset/staging

Can someone remind me how to enable a disable jobset?  :-)

Full shortlog below:

Marius Bakke (100):
  [a49c829a05] gnu: libva: Update to 2.14.0.
  [87793b349f] gnu: libva: Use G-expressions.
  [a5436115a0] gnu: python-babel: Update to 2.10.3.
  [e850e361b6] gnu: python-sphinx: Update to 5.0.2.
  [9acd1a150f] gnu: python-certifi: Update to 2022.6.15.
  [647ec2ae78] gnu: python-requests: Update to 2.28.0.
  [a4283bf55f] gnu: python-urllib3: Update to 1.26.9.
  [3787f0d215] gnu: python-charset-normalizer: Update to 2.1.0.
  [32c676bbcd] gnu: libepoxy: Update to 1.5.10.
  [2692624ecf] gnu: libepoxy: Use new style.
  [c209146212] gnu: libwebp: Update to 1.2.2.
  [1535d8c5d8] gnu: libwebp: Simplify inputs.
  [7f209d8425] gnu: bluez: Update to 5.64.
  [6cb7e67dc5] gnu: bluez: Simplify inputs.
  [60f17c197d] gnu: bluez: Use new style.
  [a6bc7baa54] gnu: freeglut: Update to 3.2.2.
  [ddc538ac32] gnu: libical: Update to 3.0.14.
  [b40151ff4f] gnu: glu: Update to 9.0.2.
  [421a3c8172] gnu: libinput: Update to 1.19.4.
  [fce910af55] gnu: Remove postgresql@13 replacement.
  [6c7fcc71d1] gnu: qtbase: Build with PostgreSQL@14.
  [66e3adcad8] gnu: Remove unused patch.
  [de9d389c54] gnu: nspr: Update to 4.34.
  [fd004ddafa] gnu: nss, nss-certs: Update to 3.80.
  [b316d8b751] gnu: nspr: Use G-expressions.
  [01d1b285b8] gnu: nss: Use G-expressions.
  [dce7ed146d] gnu: libunwind: Enable tests.
  [d33f051740] gnu: libmng: Remove input labels.
  [5b48591176] gnu: python-pillow: Update to 9.2.0.
  [32b7e12e77] gnu: python-cffi: Update to 1.15.1.
  [97e2983310] gnu: python-cffi: Remove input labels.
  [f49eef43fd] gnu: iso-codes: Remove input labels.
  [03a4908ea5] gnu: mozjs: Build with the default LLVM.
  [13040cd309] gnu: mozjs: Remove obsolete workaround.
  [1f22184b22] gnu: python-attrs: Disable test deadline on all 
architectures.
  [572ed223ab] gnu: python-requests: Update to 2.28.1.
  [8d241c685a] gnu: python-chardet: Update to 5.0.0.
  [3b20467807] gnu: libva: Update to 2.15.0.
  [c0c6944f1a] gnu: perl-pod-parser: Update to 1.65.
  [9b4b5e33c4] gnu: perl-file-basedir: Update to 0.09.
  [c3da692293] gnu: perl-file-mimeinfo: Update to 0.33.
  [4625519f2c] gnu: libmbim: Update to 1.26.4.
  [718f75a55a] gnu: libqmi: Update to 1.30.8.
  [40992a1e02] gnu: modem-manager: Remove input labels.
  [9ee4069eb0] gnu: modem-manager: Use G-expression.
  [fdd40f391c] gnu: modem-manager: Remove obsolete input.
  [68aab436af] gnu: modem-manager: Update to 1.18.10.
  [f098d93352] gnu: nss, nss-certs: Update to 3.81.
  [f3673447cc] gnu: rust-smallvec: Update to 1.9.0.
  [ca5f1dd01e] gnu: rust-target-lexicon: Update to 0.12.4.
  [7b38d7731a] gnu: rust-cfg-expr: Add 0.10.3.
  [8d05800f67] gnu: rust-system-deps: Add 6.0.2.
  [e31cc7f0c9] gnu: rust-glib-sys: Add 0.15.
  [21e5e408bf] gnu: rust-cairo-sys: Add 0.15.1.
  [633c4ca407] gnu: rust-gobject-sys: Add 0.15.10.
  [ac393134e5] gnu: rust-glib-macros: Add 0.15.
  [bc9ea4f6e8] gnu: rust-glib: Add 0.15.12.
  [01c410a440] gnu: rust-cairo-rs: Add 0.15.12.
  [def0acd5e5] gnu: rust-pango-sys: Add 0.15.
  [713b289ff0] gnu: rust-pango: Add 0.15.10.
  [c5d4f2e8f0] gnu: rust-pangocairo-sys: Add 0.15.
  [2f9aa892c6] gnu: rust-pangocairo: Add 0.15.1.
  [b4678e4488] gnu: rust-gio-sys: Add 0.15.10.
  [bdd55817ed] gnu: rust-gdk-pixbuf-sys: Add 0.15.
  [79ee7d783a] gnu: rust-gio: Add 0.15.12.
  [c7bbf937ff] gnu: rust-gdk-pixbuf: Add 0.15.11.
  [de212cb74e] gnu: rust-itertools@0.10: Update to 0.10.3.
  [26afc27f29] gnu: rust-tinyvec@1: Update to 1.2.0.
  [e62dd8e762] gnu: rust-crc32fast: Update to 1.3.2.
  [822edbf08b] gnu: rust-gzip-header: Add 1.0.0.
  [fe76e27789] gnu: rust-mint: Update to 0.5.9.
  [1160932ea0] gnu: rust-deflate: Add 1.0.0.
  [4059158e6a] gnu: rust-png: Add 0.17.
  [1338e25610] gnu: rust-yeslogic-fontconfig-sys: Add 2.11.2.
  [0b770c2da4] gnu: librsvg: Update to 2.54.4.
  [7b69cd0740] Revert "gnu: librsvg: Update to 2.54.4."
  [b9a3083db3] gnu: qtscxml: Fix build failure.
  [f561830a5b] gnu: python-pympler: Update to 1.0.1.
  [431df1214e] gnu: python-dateutil: Adjust tests for Pytest 7.
  [30ac875bd8] gnu: python-sphinx: Update to 5.1.1.
  [a20a934081] gnu: python-freezegun: Update to 1.2.2.
  [c5860b97e9] gnu: python-free

Re: 'staging' freeze

[Mathieu Othacehe]

Hey Marius,

> The 'staging' branch is in a pretty good shape, let's get it merged!

Nice work!

> I'm fairly rusty when it comes to Cuirass, and don't see a button to
> start the jobset here even when authenticated:
>
>   https://ci.guix.gnu.org/jobset/staging
>
> Can someone remind me how to enable a disable jobset?  :-)

No easy way for now:

--8<---cut here---start->8---
psql -d cuirass -c "update specifications set is_active = 1 where name = 
'staging';"
--8<---cut here---end--->8---

does the trick.

Thanks,

Mathieu

Guix Plover package issue

[Matt]

I'm trying to use plugins with the version of Plover packaged in Guix.
For some reason, Plover isn't showing the plugin interface.  There is
normally a button which says "plugins".  Within Guix, that button
isn't there.

The Plover documentation says that the plugin installer can be accessed through

  plover -s plover_plugins list

This returns an error "no such script: plover_plugins".  It would seem
that the plugin module isn't along with Plover.

AFAICT, plugins are managed by the PyPI package plover-plugins-manager
(https://pypi.org/project/plover-plugins-manager/).  I've run guix
import pypi plover-plugins-manager and tried installing with guix
package --install-from-file.  Trying to follow the errors, I've got:

(use-modules
 (guix build-system python)
 (guix packages)
 (guix download)
 (gnu packages python-xyz))

(package
  (name "python-plover-plugins-manager")
  (version "0.7.1")
  (source (origin
(method url-fetch)
(uri (pypi-uri "plover_plugins_manager" version))
(sha256
 (base32
  "1nwzgcysxcmd7a46w1mjmc2a5gjmhhbx5qhhkas6zdjgdin9c67x"
  (build-system python-build-system)
  (propagated-inputs (list python-pip
   python-pkginfo
   python-plover
   python-pygments
   python-readme-renderer
   python-requests
   python-requests-cache
   python-requests-futures
   python-setuptools
   python-wheel))
  (native-inputs (list python-pytest python-pytest-shutil))
  (home-page "https://github.com/benoit-pierre/plover_plugins_manager";)
  (synopsis "Plugins manager for Plover")
  (description "Plugins manager for Plover")
  (license #f))

However, this fails on

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
error: python-plover: unbound variable

Including (gnu packages stenography) doesn't resolve it.  Using guix
edit plover, I see that the definition is in
gnu/packages/stenography.scm. Which module should I be using?

Thank you!

Re: Guix Plover package issue

[Maxime Devos]

On 28-08-2022 19:44, Matt wrote:

However, this fails on

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
error: python-plover: unbound variable

Including (gnu packages stenography) doesn't resolve it.  Using guix
edit plover, I see that the definition is in
gnu/packages/stenography.scm. Which module should I be using?


You did "guix edit plover", so you found the module to which "plover" 
belongs -- you found "plover", not "python-plover".


To find python-plover, try "guix edit python-plover".

Given that it does not exist, maybe you need 'plover' instead of 
python-plover.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Guix Plover package issue

[Matt]

  On Sun, 28 Aug 2022 13:47:47 -0400  Maxime Devos  wrote --- 

 > Given that it does not exist, maybe you need 'plover' instead of 
 > python-plover.

Ah, yes. That works. Thank you.

Re: Clarify the license field of the package

[宋文武]

John Kehayias  writes:

> Hello 宋文武,
>
> On Mon, Aug 22, 2022 at 05:02 PM, 宋文武 wrote:
>
>> Hello list, I have some questions about the 'license' of a package,
>> currently defined as:
>>
>> The license of the package; a value from ‘(guix licenses)’, or a
>> list of such values.
>>
>> 1. It's the license of source files (guix build -S) or built binary
>>files?
>>
>
> Not a lawyer by any means, so I'm not sure how it works. For sure it
> applies to the source, but after building the binary output will
> contain a LICENSE or COPYING file (always? I would assume). Other than
> that, I don't know :)

Yes, guix distribute both sources and binaries (via substitute).  As a
packager, I'm afraid to get that 'license' field wrong...

> [...]
> Those are my guesses/experiences above, hope that is helpful.

Thank you for join discussion!

Re: Clarify the license field of the package

[宋文武]

Maxime Devos  writes:

> On 22-08-2022 11:02, 宋文武 wrote:
>
>> Hello list, I have some questions about the 'license' of a package,
>> currently defined as:
>>
>>  The license of the package; a value from ‘(guix licenses)’, or a
>>  list of such values.
>>
>> 1. It's the license of source files (guix build -S) or built binary
>> files?
>
> (If 'built binary files', I would include generated or copied
> documentation in the list. And icons, .desktop files, ..., I'm not
> restricting myself to _executable_ binaries here and also not to
> binaries that aren't sources as well.)

Sure, it should be clear what license any file has.  Below, I'd refer
them as sources and outputs.
>
> Rarely, there is some weirdness where the source code is free
> (VSCodium?) but the official build has a non-free license
> (VSCode?). At least for that example, it doesn't apply to Guix though
> (because VSCodium is not packaged, and because with some rare
> exceptions we build from source).
>
> However, in my experience, in free software they almost always have
> the same license, so the distinction appears meaningless to me with
> the possible exception of build scripts and test files (including, but
> not limited to, test code).

There are 2 main cases which the licenses of sources and outputs of a
package can be different:

  1. statically linked binaries (eg: golang, rust), leading outputs has
  more licenses than the package's sources (should be all sources), see:
  
https://artemis.sh/2022/08/21/this-program-is-illegally-packaged-in-14-distributions.html

  2. not used sources or when licenses not propagated to outputs during
  build (eg: tests, build tools, sources generator), leading outputs has
  less licenses than sources.

I think this distinction will be important when we audit the license
compatibility issues for outputs, since we also distribute outputs via
substitutes.
>
> I think it should include the source files, as the license of the
> source is important for people doing 'guix build --source'.

I agree too.
>
>> 2. When its value is a list of multiple licenses, it's files under
>> different licenses (eg: lib/*.so under LGPL, while bin/* under GPL),
>> or files under one license select from choices?
>>
>> My guess is that the license field is for source files since we can
>> disable binary substitutes, and list is used for files under different
>> licenses.
>>
>> Does my guess is correct?  Thank you!
>
> As answered in a reply to a patch, myself I go for 'files under
> different licenses' -- to me it seems hard to go wrong with 'just
> include all participating licenses' instead of trying to make a
> selection.
>
> However, keep in mind that sometimes a file is part licensed as, say,
> BSD(*), part as Expat, with modifications under the GPL -- to me it
> appears that for practical purposes you could consider such a thing to
> be 'effectively GPL', but that's not 100% accurate, as it appears
> required to preserve the BSD and Expat license text. (Such things can
> happen when incorporating code from other, differently-licensed,
> projects).
>
> (*) let's say without the advertising clause or whatever it was (IIRC
> and IIUC the original BSD was incompatible with the GPL?).
>
> If there's some consensus, I think it would be nice to clarify this
> matter in the manual.

Yes, after read
 (Combining code),
I think we should list all licenses of sources files in the package's
license field.  

And for license choices, write in comments, since we lacking "OR", our
list of multiple license is same as "AND" in SPDX license expressions.

https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/
https://wiki.spdx.org/view/FileNoticeExamples

Later, I think we can introduce a "OR" form for license field or use SPDX 
license
expressions directly.


In summary, I think our next steps are:

1. Clarify the license field is for sources and the list is for files
under multiple license (required to simultaneously comply with two or
more licenses) in our manual.

2. Consider extend the license field with "OR" form or use SPDX license
expressions.

3. Introduce some ways to show and check licenses for package's outputs.


What do you think?  Thanks for help!