Re: Preservation of Guix (PoG) report 2023-03-13

[Timothy Sample]

Hi Ludo,

Ludovic Courtès  writes:

> Do you think this could be turned into a Guix System service, with an
> eye towards making it run on project infrastructure?

I need to revisit what you did with Disarchive and Cuirass.  The process
for the PoG report is very similar.  I can’t jump into it right away,
but I agree that it would be better and I hope to work on it eventually.

> Subversion support should probably be high-priority because TeX Live is
> deep down in the dependency graph so if we ever lose it, we’re doomed.

I will start processing Subversion references on my end.  That way, we
will at least know how many of them are in the SWH archive.


-- Tim

Re: Preservation of Guix (PoG) report 2023-03-13

[Timothy Sample]

Hey,

Simon Tournier  writes:

> Well, I do not remember if you consider also the ’origin’
> (fixed-outputs) as ’inputs’ or ’patches’.  Do you?

I’m quite confident I’m getting everything.  I’ll describe my approach,
because I’m happy with it.  :)

The Guix package graph exists twice, essentially.  There’s the
high-level representation made up of packages, origins, gexps, etc.
Then, there is the low-level representation which is just derivations.
The high-level representation has nice metadata and makes sense to
humans, while the low-level representation is easy to traverse.

AFAICT, there’s no generic way to traverse the high-level
representation.  Every lowerable object has complete control over how it
references other lowerable objects, and is not obliged provide any means
of listing those references.  That is, there’s no ‘lowerable-inputs’
procedure or anything like that.  (We have ‘bag-node-edges’ in ‘(guix
scripts graph)’, but it doesn’t cover everything.)

What I do for the report is traverse (as best I can) the high-level
representation and construct a map from derivations to origin objects.
Then, I traverse the low-level representation to find all the
fixed-output derivations.  Finally, I use the map to look up origin
objects for each fixed-output derivation.  If I miss an origin object,
the fixed-output derivation still gets recorded.  It will show up in the
report as “unknown” until I investigate why it’s missing and correct it.

There’s currently 56 (out of 54K) fixed-output derivations that are
missing metadata in my database.  A fair few of them have to do with
Telegram, Thunderbird, and UBlock Origin.  All it means is that those
packages have sneaky ways of referencing origins that my code can’t
handle.  It’s harmless and easy to fix as time permits.

>> Over the whole set, 77.1% are known to be safely tucked away in the
>> Software Heritage archive.  But it’s actually much better than that.  If
>> we only look at the most recent sampled commit (from Sunday the 5th),
>> that number becomes 87.4%, which is starting to look pretty good!
>
> Just to be point the new nixguix loader [1] is still in SWH staging and
> not yet deployed, IIRC.  It will not change much the coverage on our
> side but it should be fix some corner-cases.
>
> 1: 

Good to know!

>>  This is kinda like an automated version of Simon’s recent
>> investigation.
>
> Neat!  Note that I also wanted to check the SWH capacity for cooking,
> not only checking the end points.  For instance, it allowed to discover
> mismatch due to uncovered CR/LF normalization; now fixed with:
> 58f20fa8181bdcd4269671e1d3cef1268947af3a.

Maybe we need a “chaos monkey mode” for Guix.  It could randomly select
packages to build, randomly pick source code fallback methods, and also
test reproducibility (like “--check”).  You could have a blocklist for
browsers, etc., but otherwise it could pick the odd package to test
thoroughly.  Those of us with the time and inclination could crank up
that knob and get interesting feedback about reproducibility at the cost
of doing a few package builds here and there.

>> Here’s a rough road map for that based on a glance at the script’s
>> output:
>>
>> • Subversion support (for TeX-based documentation stuff, I guess)
>
> For the interested reader, details for helping in the implementation:
>
> https://issues.guix.gnu.org/issue/43442#9
> https://issues.guix.gnu.org/issue/43442#11

Fantastic.  That looks very promising!

> However, it would ease all the dance if SWH would consider to store and
> expose NAR hashes on their side.  As discussed here:
>
> https://gitlab.softwareheritage.org/swh/meta/-/issues/4538

This would be nice, yes.

>>  However, 42% of them are old Bioconductor packages.  They
>> seem to be lost.  It looks like Bioconductor now stores multiple package
>> versions per Bioconductor version [2], but before version 3.15 that was
>> not the case.  As an example, take “ggcyto” from Bioconductor 3.10 [3].
>> We packaged version 1.14.0, and then at some point Bioconductor 3.10
>> switched to version 1.14.1.  We packaged that, too, but now 1.14.0 is
>> gone.
>
> Well, I have not investigated much because it is between December 2019
> and March 2020 thus “guix time-machine” is not smooth for this old time.
>
> First question, does we have the source tarball in Berlin or Bordeaux or
> somewhere else?  If yes, there is a hope. :-) Else, it is probably gone
> forever.

Like I wrote, I picked up a handful from Bordeaux, but not much.

> The hope is: https://git.bioconductor.org/packages/ggcyto
>
> If we have the tarball with the correct checksum from commit
> f5f440312d848e12463f0c6f7510a86b623a9e27
>
> +(version "1.14.0")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (bioconductor-uri "ggcyto" version))
> +   (sha256
> +(base32
> + 

Re: Disarchive database synchronization

[Timothy Sample]

Hey Ludo,

Ludovic Courtès  writes:

> I copied over the 12K entries that were missing from
> disarchive.guix.gnu.org.  (Note that there are currently only two copies
> of the database: one at/in [bB]erlin, and one at/in [Bb]ordeaux.)
> disarchive.guix.gnu.org now weighs in at 1.8 GiB for 31,839 entries.

Wow – 12K!  For some reason I thought it would be fewer.  It’s very good
that we (finally) sync’d up the databases.

Also, my set is now at 31,821 after collecting the runoff from the
latest Preservation of Guix Report.  That’s shockingly close to the
31,839 you have.

> For the remaining entries, it’s trickier.  Sometimes it’s just the
> gzip compression parameters that differ, which could be addressed with a
> little bit more work:
>
> $ file ffdc77f5e5cb2390b9309de63eb7be68d9fe631e898f4da6c04a8159daefc2c0.gz 
> ../../disarchive/sha256/ffdc77f5e5cb2390b9309de63eb7be68d9fe631e898f4da6c04a8159daefc2c0.gz
> ffdc77f5e5cb2390b9309de63eb7be68d9fe631e898f4da6c04a8159daefc2c0.gz:  
>gzip compressed data, max compression, from Unix, original 
> size modulo 2^32 446731
> ../../disarchive/sha256/ffdc77f5e5cb2390b9309de63eb7be68d9fe631e898f4da6c04a8159daefc2c0.gz:
>  gzip compressed data, max speed, from Unix, original size modulo 2^32 446731

I’m not sure getting the compressed files to match matters.  Disarchive
cares a lot about that when it comes to source code tarballs, because
everybody signs and computes checksums over the compressed versions.
However, for these files, the differences introduced by compression can
be ignored.

> Sometimes it’s trickier:
>
> # diff -u <(gunzip -d < 
> 0001f025c1425ffe36270a81cb091eade87dd8d29ac773735ae47e1a8c8066c9.gz) <(gunzip 
> -d < 
> ../../disarchive/sha256/0001f025c1425ffe36270a81cb091eade87dd8d29ac773735ae47e1a8c8066c9.gz)
> --- /dev/fd/63  2023-03-14 16:13:21.635733426 +0100
> +++ /dev/fd/62  2023-03-14 16:13:21.635733426 +0100
> @@ -1,7 +1,7 @@
>  (disarchive
>(version 0)
>(gzip-member
> -(name "webview-sys-0.6.2.tar.gz")
> +(name "rust-webview-sys-0.6.2.tar.gz")
>  (digest
>(sha256
>  "0001f025c1425ffe36270a81cb091eade87dd8d29ac773735ae47e1a8c8066c9"))
> @@ -13,7 +13,7 @@
>  (footer (crc 1807070134) (isize 121344))
>  (compressor zlib-best)
>  (input (tarball
> - (name "webview-sys-0.6.2.tar")
> + (name "rust-webview-sys-0.6.2.tar")
>   (digest
> (sha256
>   
> "4fb18f3206838e11f7f8caba6fad9e0f796109428b502793b9f2f0613fe0f275"))
> @@ -78,7 +78,7 @@
>   (padding 0)
>   (input (directory-ref
>(version 0)
> -  (name "webview-sys-0.6.2")
> +  (name "rust-webview-sys-0.6.2")
>(addresses
>  (swhid 
> "swh:1:dir:fa41df38bf639ada28c900b0915661e787fe6d15"))
>(digest

The name field is not used for data reconstruction.  It’s for human
consumption (and it may have made some early examples of use at the
command line easier to explain).  Here, the difference is based on the
fact that Crate URIs are weird, and the Preservation of Guix code does
not keep the origin file name.  Hence, the PoG version extracts the
Crate name alone from the URI, and the Cuirass version uses the Guix
package name with the “rust-” prefix.

> As Tim pointed out, Disarchive disassembly is not fully deterministic
> and/or might change a bit over time as Disarchive evolves, and that’s
> prolly what we’re seeing here.

I honestly think this is a good thing.  My instincts tell me that we
should excise all sources of ambiguity, like we’re trying to do in the
big picture.  However, Disarchive will get better at describing things
over time.  For instance, it doesn’t handle tar extension headers
elegantly at the moment.  In the future, if I fix this, I might consider
creating a “migrate” feature that improves existing specifications
(e.g., converting the old, verbose representation of extension headers
into the new representation).  In particular, I’ve left some warts in
the software in order to ship it, and I would be sad to try and commit
to those for the rest of time!

We might also add other resolver addresses besides SWHIDs

Maybe I’m missing some perspective, but I don’t think trying to commit
to reproducible outputs for Disarchive makes sense.


-- Tim

P.S., we’ll have to do this dance again shortly, as I just computed
2,023 historical bzip2 specifications.  They’re not online yet, but
they’ll be up when I publish the next PoG report – which should take less
than a year this time!  :p

Re: Python

[Andreas Enge]

Am Sat, Mar 18, 2023 at 10:43:17AM +0100 schrieb Lars-Dominik Braun:
> Anything else that needs work?

Well, there is pyqt as written elsewhere, but this is not only python.

I just updated python-ipython to the first version that passes all tests
without any change, in the hope that this would have the least impact on
its dependents. Without luck, now python-trio fails. Updating this to the
latest version 0.22 does not help. I copy-paste the error message below.
If you could have a look, that would definitely be welcome.

Andreas


starting phase `check'
= test session starts ==
platform linux -- Python 3.10.7, pytest-7.1.3, pluggy-0.13.1 -- 
/gnu/store/82nin1sk01l31p5vpnz9c2ki76qka9b0-python-wrapper-3.10.7/bin/python
cachedir: .pytest_cache
hypothesis profile 'default' -> 
database=DirectoryBasedExampleDatabase('/tmp/guix-build-python-trio-0.20.0.drv-0/trio-0.20.0/.hypothesis/examples')
rootdir: /tmp/guix-build-python-trio-0.20.0.drv-0/trio-0.20.0, configfile: 
pyproject.toml
plugins: hypothesis-6.54.5, xdist-2.5.0, cov-3.0.0, forked-1.4.0
gw0 I / gw1 I / gw2 I / gw3 I
[gw0] linux Python 3.10.7 cwd: 
/tmp/guix-build-python-trio-0.20.0.drv-0/trio-0.20.0
[gw1] linux Python 3.10.7 cwd: 
/tmp/guix-build-python-trio-0.20.0.drv-0/trio-0.20.0
[gw2] linux Python 3.10.7 cwd: 
/tmp/guix-build-python-trio-0.20.0.drv-0/trio-0.20.0
[gw3] linux Python 3.10.7 cwd: 
/tmp/guix-build-python-trio-0.20.0.drv-0/trio-0.20.0
[gw0] Python 3.10.7 (main, Jan  1 1970, 00:00:01) [GCC 11.3.0]
[gw1] Python 3.10.7 (main, Jan  1 1970, 00:00:01) [GCC 11.3.0]
[gw2] Python 3.10.7 (main, Jan  1 1970, 00:00:01) [GCC 11.3.0]
[gw3] Python 3.10.7 (main, Jan  1 1970, 00:00:01) [GCC 11.3.0]
gw0 [0] / gw1 [0] / gw2 [0] / gw3 [0]

scheduling tests via LoadScheduling

 ERRORS 
 ERROR collecting test session _
/gnu/store/i0d555a5fd7isi606aqqmbp5zgy9jh6p-python-3.10.7/lib/python3.10/importlib/__init__.py:126:
 in import_module
return _bootstrap._gcd_import(name[level:], package, level)
:1050: in _gcd_import
???
:1027: in _find_and_load
???
:992: in _find_and_load_unlocked
???
:241: in _call_with_frames_removed
???
:1050: in _gcd_import
???
:1027: in _find_and_load
???
:992: in _find_and_load_unlocked
???
:241: in _call_with_frames_removed
???
:1050: in _gcd_import
???
:1027: in _find_and_load
???
:992: in _find_and_load_unlocked
???
:241: in _call_with_frames_removed
???
:1050: in _gcd_import
???
:1027: in _find_and_load
???
:1006: in _find_and_load_unlocked
???
:688: in _load_unlocked
???
:883: in exec_module
???
:241: in _call_with_frames_removed
???
trio/__init__.py:18: in 
from ._core import (
trio/_core/__init__.py:20: in 
from ._multierror import MultiError
trio/_core/_multierror.py:511: in 
warnings.warn(
E   RuntimeWarning: You seem to already have a custom sys.excepthook handler 
installed. I'll skip installing Trio's custom handler, but this means 
MultiErrors will not show full tracebacks.
 ERROR collecting test session _
/gnu/store/i0d555a5fd7isi606aqqmbp5zgy9jh6p-python-3.10.7/lib/python3.10/importlib/__init__.py:126:
 in import_module
return _bootstrap._gcd_import(name[level:], package, level)
:1050: in _gcd_import
???
:1027: in _find_and_load
???
:992: in _find_and_load_unlocked
???
:241: in _call_with_frames_removed
???
:1050: in _gcd_import
???
:1027: in _find_and_load
???
:992: in _find_and_load_unlocked
???
:241: in _call_with_frames_removed
???
:1050: in _gcd_import
???
:1027: in _find_and_load
???
:992: in _find_and_load_unlocked
???
:241: in _call_with_frames_removed
???
:1050: in _gcd_import
???
:1027: in _find_and_load
???
:1006: in _find_and_load_unlocked
???
:688: in _load_unlocked
???
:883: in exec_module
???
:241: in _call_with_frames_removed
???
trio/__init__.py:18: in 
from ._core import (
trio/_core/__init__.py:20: in 
from ._multierror import MultiError
trio/_core/_multierror.py:511: in 
warnings.warn(
E   RuntimeWarning: You seem to already have a custom sys.excepthook handler 
installed. I'll skip installing Trio's custom handler, but this means 
MultiErrors will not show full tracebacks.
 ERROR collecting test session _
/gnu/store/i0d555a5fd7isi606aqqmbp5zgy9jh6p-python-3.10.7/lib/python3.10/importlib/__init__.py:126:
 in import_module
return _bootstrap._gcd_import(name[level:], package, level)
:1050: in _gcd_import
???
:1027: in _find_and_load
???
:992: in _find_and_load_unlocked
???
:241: in _call_with_frames_removed
???
:1050: in _gcd_import
???
:1027: in _find_and_load
???
:992: in _find_and_load_unlocked
???
:241: in 

Re: Gnome dans core-updates

[Andreas Enge]

Am Sat, Mar 18, 2023 at 12:15:34PM +0100 schrieb Liliana Marie Prikler:
> Feel free to promote it into a snippet.  I didn't, because it only
> affects the build files rather than the package being built.

Okay, I did and pushed, many thanks again!

Andreas

Re: Procps in core-updates

[Andreas Enge]

Am Sat, Mar 18, 2023 at 01:38:48PM -0400 schrieb Leo Famulari:
> I recommend trying the latest upstream version, 4.0.3. The Sourceforge
> download page points to the new canonical location:

I already tried, it does not change anything. If I mess with the package,
I would in any case update the version - it requires about 7000 rebuilds,
so we may as well use it for an update.

> If that doesn't work, I would just disable the test, unless there is
> some authoritative upstream opinion about which patch to apply.

Sure, I can always do. I am just wondering about how the test failure
is even possible...

Andreas

Re: Discussion notes on releases and branches

[Leo Famulari]

On Fri, Mar 17, 2023 at 08:24:44AM -0700, Felix Lechner via Development of GNU 
Guix and the GNU System distribution. wrote:
> Instead of dividing similar tasks among many people with different
> priorities, I would appoint a "feature branch manager" (or perhaps,
> chief pruner).
> 
> That person's job would be to keep an eye on the number of feature
> branches on Savannah so they do not grow stale, or out of control.

There should be someone like this, although I suspect this particular
role could be informally performed by the people who are paying
attention to loads on the build farm at any given time. Generally, we
don't have success appointing people to jobs; rather, they volunteer or
even emerge non-explicitly.

Re: Procps in core-updates

[Leo Famulari]

I recommend trying the latest upstream version, 4.0.3. The Sourceforge
download page points to the new canonical location:

https://gitlab.com/procps-ng/procps

If that doesn't work, I would just disable the test, unless there is
some authoritative upstream opinion about which patch to apply.

Re: State of core-updates

[Andreas Enge]

Am Sat, Mar 18, 2023 at 04:36:26PM + schrieb Kaelyn:
> I'm at a complete loss as to why the patch won't apply properly.

Ah, the joys of email formatting maybe.

> I've attached the original patch as generated by "git format-patch

Thanks, I applied and pushed it and am closing the bug.

Andreas

Re: State of core-updates

[Kaelyn]

--- Original Message ---
On Saturday, March 18th, 2023 at 8:56 AM, Andreas Enge  wrote:


> 
> 
> Hello,
> 
> Am Fri, Mar 17, 2023 at 08:43:13PM + schrieb Kaelyn:
> 
> > I'm at least a little in favor of that, as the commit message for 
> > cc56be2f3858487cf1d8acfb345942f0784221ee is mis-formatted (it doesn't have 
> > the first 'gnu: ' prefixed summary line, and so git log --oneline doesn't 
> > format it right).
> 
> 
> sorry for that, I did go over the commit message, but overlooked this part.
> 
> > I just quickly formatted and sent a v2 patch using "git format-patch 
> > --attach" and "git send-email" to try to get something at 
> > https://issues.guix.gnu.org/62209 that will work properly with "git am". 
> > (I'm still puzzled at what happened with the first one, as downloading the 
> > whole message and applying it with "git am" also fails for me.)
> 
> 
> It still does not - there is no first line for the commit message
> (the "gnu: ...").
> 
> When I try to "git am the-message-in-mbox-format", I get:
> fatal: Dirty index: cannot apply patches (dirty: gnu/local.mk 
> gnu/packages/gnome.scm gnu/packages/patches/glib-networking-32-bit-time.patch)
> 
> When I just try to apply "git am 
> v2-0001-gnu-glib-networking-Fix-32-bit-builds.patch":
> Patch format detection failed.
> (which is normal, it does not have the commit message, but starts with
> "diff").
> 
> I may have made an error, but it is suspicious that QA apparently also did
> not manage to extract a git commit (there is no corresponding branch in
> guix-patches).
> 
> Concerning "git send-email", I recently tried it and followed the advice at
> https://guix.gnu.org/en/manual/devel/en/guix.html#Sending-a-Patch-Series
> It does not involve a "git format-patch" step.

I'm at a complete loss as to why the patch won't apply properly. I originally 
sent it using "git send-email" (following the manual instructions, which I also 
recently double-checked trying to figure out the problem) as I have done with 
almost all of the other patches I've submitted. The v2 patch was made with the 
addition of "--attachment" to see if the different format transferred better, 
but no luck there. https://issues.guix.gnu.org/62137 is another patch I sent a 
couple days prior to https://issues.guix.gnu.org/62209; I can download 62137 
through the web interface and apply it with git "am", but for either in 62209 I 
encounter the same errors as you.

The original commit message as shown by "git log" is:

commit 1ad88ac769189d36139fbfd3ceb562fbe3a1fed5 (core-updates)
Author: Kaelyn Takata 
Date:   Wed Mar 15 10:22:25 2023 -0700

gnu: glib-networking: Fix 32-bit builds.

* gnu/packages/gnome.scm (glib-networking): Remove obsolete patch.
* gnu/packages/patches/glib-networking-32-bit-time.patch: Remove patch.
* gnu/local: Remove it.


I've attached the original patch as generated by "git format-patch 
--to=62...@debbugs.gnu.org core-updates^..core-updates" since the mumi version 
doesn't want to cooperate. I also locally tested that the attached patch worked 
with "git am" locally.

Cheers,
Kaelyn

> 
> AndreasFrom 1ad88ac769189d36139fbfd3ceb562fbe3a1fed5 Mon Sep 17 00:00:00 2001
Message-Id: <1ad88ac769189d36139fbfd3ceb562fbe3a1fed5.1679157139.git.kaelyn.al...@protonmail.com>
From: Kaelyn Takata 
Date: Wed, 15 Mar 2023 10:22:25 -0700
Subject: [PATCH] gnu: glib-networking: Fix 32-bit builds.
To: 62...@debbugs.gnu.org

* gnu/packages/gnome.scm (glib-networking): Remove obsolete patch.
* gnu/packages/patches/glib-networking-32-bit-time.patch: Remove patch.
* gnu/local: Remove it.
---
 gnu/local.mk  |  1 -
 gnu/packages/gnome.scm| 11 
 .../patches/glib-networking-32-bit-time.patch | 61 ---
 3 files changed, 73 deletions(-)
 delete mode 100644 gnu/packages/patches/glib-networking-32-bit-time.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 73617d3af7..ff35978f07 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1204,7 +1204,6 @@ dist_patch_DATA =		\
   %D%/packages/patches/ghostscript-no-header-creationdate.patch \
   %D%/packages/patches/glib-appinfo-watch.patch			\
   %D%/packages/patches/glib-networking-gnutls-binding.patch	\
-  %D%/packages/patches/glib-networking-32-bit-time.patch	\
   %D%/packages/patches/glib-skip-failing-test.patch		\
   %D%/packages/patches/glibc-CVE-2019-7309.patch		\
   %D%/packages/patches/glibc-CVE-2019-9169.patch		\
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 62b3ae72c7..ce7f3b6cec 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -4911,17 +4911,6 @@ (define-public glib-networking
   (patches
(search-patches "glib-networking-gnutls-binding.patch"
 (build-system meson-build-system)
-(arguments
- (if (target-64bit?)
- '()
- (list #:phases
-   #~(modify-phases %standard-phases
-   (add-after 'unpack 

Re: Building more of ‘core-updates’ on ci.guix

[Andreas Enge]

Hello!

Am Wed, Mar 15, 2023 at 05:47:08PM +0100 schrieb Ludovic Courtès:
> I’ve just changed it the ‘core-updates’ job to build
> ‘etc/release-manifests.scm’ (you can check what’s in there).  So
> everything goes well (a big “if” :-)), we’ll soon have substitutes for
> Emacs, GTK, and whatnot.

thanks a lot, also for the explanation on what to do over ssh.

Would it be okay to add the following packages to etc/release-manifests.scm:
openjdk
unison (exercises ocaml)
ghc-pandoc (exercises ghc)
calibre (exercises Qt5 and python-pyqt)

icecat is supposed to be added as soon as rust is available on i686,
but I suppose we could add it conditionally only on x86_64, no?
Actually there is already a filter step in %system-manifest.
The same holds for ungoogled-chromium. It should be enough to just
add them.

Andreas

PyQt in core-updates

[Andreas Enge]

Hello,

the attached patch seems to be necessary to start configuring python-pyqt
in core-updates.

But then the configure step still fails. The error message of "guix build"
is not helpful, but running the configure step in the result of "guix build -K"
shows the following:
...
The interpreter used by pyuic5 is
/gnu/store/82nin1sk01l31p5vpnz9c2ki76qka9b0-python-wrapper-3.10.7/bin/python.
Generating the C++ source for the QtCore module...
Error: Unable to create the C++ code.

A search seems to indicate that sip does not do its job, but the exact same
error with this PyQt version does not show up.

The error message comes from the function
def generate_sip_module_code
in configure.py, which creates a command that is run with run_command.
Precisely, the command is
/gnu/store/zd8nrmc0207l90vscnf7dlswd6z16aas-python-sip-5.5.0/bin/sip5 -w -n 
PyQt5.sip -t WS_X11 -t Qt_5_15_0 -f -P -o -y QtCore.pyi -c 
/tmp/guix-build-python-pyqt-5.15.8.drv-2/PyQt5-5.15.8/QtCore -I sip -I 
/tmp/guix-build-python-pyqt-5.15.8.drv-2/PyQt5-5.15.8/sip 
/tmp/guix-build-python-pyqt-5.15.8.drv-2/PyQt5-5.15.8/sip/QtCore/QtCoremod.sip

If I run it by hand, it prints
.sip5-real: 
/tmp/guix-build-python-pyqt-5.15.8.drv-1/PyQt5-5.15.8/sip/QtCore/QtCoremod.sip:23:
 syntax error
This line 23 is very simple:
%Module(name=PyQt5.QtCore, call_super_init=True, 
default_VirtualErrorHandler=PyQt5, keyword_arguments="Optional", 
use_limited_api=True, py_ssize_t_clean=True)

And anyway, it is part of the source code...

There is a version 5.15.9 of PyQt (interestingly enough, not related to a
corresponding Qt version), with NEWS stating "Bug fixes", but what I have
written above is still valid.

At this point, I have to give up for lack of knowledge about sip.

Andreas

>From 82cb67b324e9ef63bb105caae5b778467aedf894 Mon Sep 17 00:00:00 2001
From: Andreas Enge 
Date: Sat, 18 Mar 2023 15:48:48 +0100
Subject: [PATCH] gnu: python-pyqt: Set variable in configure script.

* gnu/packages/patches/pyqt-minimum-sip-version.patch: New file.
* gnu/packages/qt.scm (python-pyqt): Add patch.
* gnu/local.mk (dist_patch_DATA): Register patch.
---
 gnu/local.mk   |  1 +
 .../patches/pyqt-minimum-sip-version.patch | 14 ++
 gnu/packages/qt.scm|  3 ++-
 3 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/pyqt-minimum-sip-version.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 43b7e4ceb3..d81f8ee0f8 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1707,6 +1707,7 @@ dist_patch_DATA = 
\
   %D%/packages/patches/pybugz-stty.patch   \
   %D%/packages/patches/pygpgme-disable-problematic-tests.patch  \
   %D%/packages/patches/pyqt-configure.patch\
+  %D%/packages/patches/pyqt-minimum-sip-version.patch   \
   %D%/packages/patches/python-2-deterministic-build-info.patch \
   %D%/packages/patches/python-2.7-adjust-tests.patch   \
   %D%/packages/patches/python-2.7-expat-compat.patch   \
diff --git a/gnu/packages/patches/pyqt-minimum-sip-version.patch 
b/gnu/packages/patches/pyqt-minimum-sip-version.patch
new file mode 100644
index 00..abcb4113e8
--- /dev/null
+++ b/gnu/packages/patches/pyqt-minimum-sip-version.patch
@@ -0,0 +1,14 @@
+Set the MinimumSipVersion to something, namely the currently available one.
+
+diff -u PyQt5-5.15.8.alt/configure.py PyQt5-5.15.8/configure.py
+--- PyQt5-5.15.8.alt/configure.py
 PyQt5-5.15.8/configure.py
+@@ -29,7 +29,7 @@ import sys
+ 
+ # Initialise the constants.
+ PYQT_VERSION_STR = "5.15.8"
+-SIP_MIN_VERSION = '@MinimumSipVersion@'
++SIP_MIN_VERSION = "5.5.0"
+ 
+ 
+ class ModuleMetadata:
diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
index 22a33341bf..45d99c241c 100644
--- a/gnu/packages/qt.scm
+++ b/gnu/packages/qt.scm
@@ -3294,7 +3294,8 @@ (define-public python-pyqt
 (sha256
  (base32
   "0q53xn1ax2kpfqwxkasby787ryq5a21chmw1p345cp0kp7py71dw"))
-(patches (search-patches "pyqt-configure.patch"
+(patches (search-patches "pyqt-configure.patch"
+ "pyqt-minimum-sip-version.patch"
 (build-system gnu-build-system)
 (native-inputs
  (list qtbase-5)) ; for qmake
-- 
2.39.2

Procps in core-updates

[Andreas Enge]

Hello,

procps fails its tests on core-updates when built with --system=i686-linux
(it succeeds on x86_64).

The error is completely not understandable (and Debian has disabled the test).
I modified the test file as attached; my changes are to compute the value val
separately before the "if" (interestingly enough, the variable declaration
"double val;" was already there), and I added the fprintf at the beginnings
of the lines.

The test then fails and prints
CMP 1
CMP 0
DIF 0.00
FAIL: strtod_nol_or_err("123") != 123.00

So val != tests[i].result when the "if" is executed,
this is still the case for the first fprintf,
and then changes for the second fprintf.

Has anyone got any explanation for this behaviour? A compiler error?

Here:
   
https://www.freelists.org/post/procps/strtod-nol-or-err-on-32bit-Was-procps-3312-released,2
the conclusion is
"Ive got a pending patch to just remove it. Floating point math sucks when
it comes to equality."
but this is not even floating point maths - whatever the contents of val
and tests[i].result, they should not be changed by a comparison (or an
fprintf; I can also make the test work just by adding some printf into
the strtod_nol_or_err function that is exercised by this test).

Andreas


#include 
#include 
#include "strutils.h"

struct strtod_tests {
char *string;
double result;
};

struct strtod_tests tests[] = {
{"123", 123.0},
{"-123",-123.0},
{"12.34",   12.34},
{"-12.34",  -12.34},
{".34", 0.34},
{"-.34",-0.34},
{"12,34",   12.34},
{"-12,34",  -12.34},
{",34", 0.34},
{"-,34",-0.34},
{"0",   0.0},
{".0",  0.0},
{"0.0", 0.0},
{NULL, 0.0}
};



int main(int argc, char *argv[])
{
int i;
double val;

for(i=0; tests[i].string != NULL; i++) {
val = strtod_nol_or_err(tests[i].string, "Cannot parse number");
if (val != tests[i].result) {
fprintf(stderr, "CMP %i\n", val != tests[i].result);
fprintf(stderr, "CMP %i\n", val != tests[i].result);
fprintf(stderr, "DIF %f\n", val - tests[i].result);
fprintf(stderr, "FAIL: strtod_nol_or_err(\"%s\") != %f\n",
tests[i].string, tests[i].result);
return EXIT_FAILURE;
}
//fprintf(stderr, "PASS: strtod_nol for %s\n", tests[i].string);
}
return EXIT_SUCCESS;
}

Re: Follow-up on julia import script

[Development of GNU Guix and the GNU System distribution.]

Just a quick reminder ;)

The patch series is 62202. 

I can squash the commits if this is too precise, you can tell me ;)

Have a great week-end. 


On 2023-03-15 13:43, Nicolas Graves wrote:

> Hi all!
>
> Took me quite more time than I would've liked, but I have a usable
> juliahub scheme import script!
>
> It seems there's still one edge case that isn't covered and revolves
> around when Julia packagers don't properly tag their git repos (I've
> only seen the case with SnoopPrecompile). There's the possibility to
> rely on tree commit hashes from the General repository (since this is a
> valid way to identify/store a git repo), but that needs some major
> changes in the way latest-repository-commit works. Otherwise, it needs
> to be done by hand. It might also not work for subpackages in
> directories that are up-to-date on juliahub but not yet on github, I
> haven't met this case yet.
>
> I'm sending a patch series in the coming minutes.

-- 
Best regards,
Nicolas Graves

Re: Gnome dans core-updates

[Liliana Marie Prikler]

Am Samstag, dem 18.03.2023 um 11:36 +0100 schrieb Andreas Enge:
> Am Sat, Mar 18, 2023 at 12:00:49AM +0100 schrieb Liliana Marie
> Prikler:
> > This error is caused by trying to install
> > '/gnu/store/mxp199mvjb6dhyyg0pi4hn6c7m0xibvp-bash-completion-
> > 2.11/share/bash-completion/completions/pkcon'.  Meson appears to
> > have a
> > feature where it tries to use pkexec to gain elevated privileges. 
> > However, since that pkexec is actually the one pulled in for the
> > build
> > system, that won't work here.
> > 
> > In any case, the attached patch fixes the more pressing issue of
> > getting the installation directory wrong.
> 
> Thanks for sorting this out!
> 
> Since it is a static change in a file ("lambda _"), should it not
> rather go into a snippet or a patch? And since it is specific to Guix
> (is it?), I think a snippet would be more appropriate.
Feel free to promote it into a snippet.  I didn't, because it only
affects the build files rather than the package being built.

Cheers

Re: Gnome dans core-updates

[Andreas Enge]

Am Sat, Mar 18, 2023 at 12:00:49AM +0100 schrieb Liliana Marie Prikler:
> This error is caused by trying to install
> '/gnu/store/mxp199mvjb6dhyyg0pi4hn6c7m0xibvp-bash-completion-
> 2.11/share/bash-completion/completions/pkcon'.  Meson appears to have a
> feature where it tries to use pkexec to gain elevated privileges. 
> However, since that pkexec is actually the one pulled in for the build
> system, that won't work here.
> 
> In any case, the attached patch fixes the more pressing issue of
> getting the installation directory wrong.

Thanks for sorting this out!

Since it is a static change in a file ("lambda _"), should it not rather
go into a snippet or a patch? And since it is specific to Guix (is it?),
I think a snippet would be more appropriate.

In any case, I confirm that the package now builds.

Andreas

Re: Gnome dans core-updates

[Andreas Enge]

Am Sat, Mar 18, 2023 at 11:07:08AM +0100 schrieb Andreas Enge:
> And a help-guix question: How do I retrace the part of the dependency
> graph that links ipxe-qemu to gnome?

I am still interested in the answer to this question, but here the line
is short:
ipxe-qemu -> qemu-minimal -> gnome-boxes -> gnome.

I wondered if we could not drop the dependency as somewhat alien to a
standard desktop, but it is in a list of packages labelled
"GNOME-Core-Utilities". It sounds like a stretch to have something in the
core of a desktop that "requires the @code{libvirt} and @code{virtlog}
daemons to run", but maybe there is a standard to what shall be part of
a minimal Gnome?

Andreas

Re: Python

[Andreas Enge]

Am Sat, Mar 18, 2023 at 11:02:57AM +0100 schrieb Lars-Dominik Braun:
> I just saw it was fixed on the develop branch already, but there’s no
> new release:
> https://github.com/kurtmckee/feedparser/commit/c55bd8ad37db89bd219783bc514d600c9523ed38

This dates from 2021, but strangely is not part of any of the 8 releases
made till then.

Andreas

Re: Gnome dans core-updates

[Andreas Enge]

Am Fri, Mar 17, 2023 at 08:40:00PM +0100 schrieb Andreas Enge:
> ipxe-qemu also fails its build phase:
> In file included from tests/bigint_test.c:38:
> tests/bigint_test.c: In function ‘bigint_test_exec’:
> tests/bigint_test.c:232:14: error: ‘result_raw’ may be used uninitialized 
> [-Werror=maybe-uninitialized]
> cc1: all warnings being treated as errors
> View build log at 
> '/var/log/guix/drvs/vn/01aaqcd9wmxb8hc8c9wsav89mbjyxy-ipxe-qemu-1.21.1.drv.gz'.
> Well, compiling everything with "-Werror" is okay when the authors want to
> test their code, but maybe overkill in a release?

This looks like
   https://github.com/ipxe/ipxe/issues/359
And has apparently been fixed following a different issue related to
ARM assembly (?!):
   https://github.com/ipxe/ipxe/pull/373

The project has had its latest release in December 2020, with more
than 400 commits since then. Difficult to assert that the release is
actually functional! Does it have to be a transitive input of gnome?
And a help-guix question: How do I retrace the part of the dependency
graph that links ipxe-qemu to gnome?

Andreas

Re: Python

[Lars-Dominik Braun]

Hello Andreas,

> excellent! It contradicts the feedparser author's statement that everything
> works well, so if you have the courage, maybe you could report the issue
> upstream.

I just saw it was fixed on the develop branch already, but there’s no
new release:
https://github.com/kurtmckee/feedparser/commit/c55bd8ad37db89bd219783bc514d600c9523ed38

Cheers,
Lars

Re: Gnome dans core-updates

[Andreas Enge]

Am Fri, Mar 17, 2023 at 09:46:27PM +0100 schrieb Liliana Marie Prikler:
> On a rather unrelated note, the uri
> https://gitlab.freedesktop.org/spice/libcacard/uploads/13b249e695a0d9aa7cb501b1a85ebab1/libcacard-2.8.1.tar.xz
> looks rather sus.  Should we perhaps replace that with a git-reference?

There are also more reasonable looking URL such as
   
https://gitlab.freedesktop.org/spice/libcacard/-/archive/v2.8.1/libcacard-v2.8.1.tar.bz2
But they may have the problem of unstable hashes sometimes encountered
with autogenerated tarballs.

I do not remember what is the state of the discussion with respect to
tarballs vs. git and am happy with any solution.

Andreas

Re: Python

[Lars-Dominik Braun]

Hi again,

> > > Right now I am left with a number of test failures that look real and 
> > > cannot
> > > easily be solved by an upgrade (either because we are already on the 
> > > latest
> > > version or because the tests still fail): python-sgmllib3k, 
> > > python-typeguard
> > > and python-coveralls. See messages below.
> > I don’t know for sure why any of these packages’ tests fail. typeguard
> > looks like it expects specific strings from Python or one of its libraries
> > – safe to ignore.
> 
> would you mind having a look how we should proceed? Fix tests or disable
> specific ones that you deem safe to ignore?

python-typeguard and python-coveralls are functional again:

d9a31cd34eb9f63460d74d3cfff0190f964f48f4 gnu: python-coveralls: Disable failing 
test and relax version requirements.
a7c96167ae8748a8b76fabaf74a997094cdf7fc5 gnu: python-typeguard: Python 3.10 
compatibility.

Anything else that needs work?

Cheers,
Lars

Re: State of core-updates

[Andreas Enge]

Hello,

Am Wed, Mar 15, 2023 at 05:59:12PM + schrieb Kaelyn:
> 2) libaio 0.3.113 does not build on core-updates, though the previous version 
> 0.3.112 does. I'm not sure how to handle this one, as the failure is a 
> compile error from one of the test cases:

it compiles for me on x86_64, but indeed not on i686.
I added a patch; unfortunately this means recompiling 2000 packages.

Thanks for the report!

Andreas

Re: Python

[Andreas Enge]

Hello Lars,

Am Sat, Mar 18, 2023 at 09:59:37AM +0100 schrieb Lars-Dominik Braun:
> I fixed both python-sgmllib3k and python-feedparser. Disabling tests
> would not do much in this case, since the packages really *were* broken
> by a Python upstream change.

excellent! It contradicts the feedparser author's statement that everything
works well, so if you have the courage, maybe you could report the issue
upstream.

Thanks, more things that work!

Andreas

Re: Python

[Lars-Dominik Braun]

Hello Andreas,

> This one is used for python-feedparser, used for calibre and quodlibet.
> The feedparser author is not enclined to work on it:
>https://github.com/kurtmckee/feedparser/issues/328
> I would suggest to try compiling python-sgmllib3k (and potentially
> python-feedparser) without the tests, and see whether calibre still works.
> But for this, we first need to get all other inputs of calibre into working
> shape.
I fixed both python-sgmllib3k and python-feedparser. Disabling tests
would not do much in this case, since the packages really *were* broken
by a Python upstream change.

f9bff8614be32f9c2c1a54da80eaed1365b49be3 gnu: python-feedparser: Add Python 
>=3.9 compatibility.
cfccd6fe5ae00d7e81cd755be55d51ff3bf17186 gnu: python-sgmllib3k: Add Python 
>=3.9 compatibility.

Cheers,
Lars

Re: State of core-updates

[Andreas Enge]

Hello,

Am Fri, Mar 17, 2023 at 08:43:13PM + schrieb Kaelyn:
> I'm at least a little in favor of that, as the commit message for 
> cc56be2f3858487cf1d8acfb345942f0784221ee is mis-formatted (it doesn't have 
> the first 'gnu: ' prefixed summary line, and so git log --oneline doesn't 
> format it right).

sorry for that, I did go over the commit message, but overlooked this part.

> I just quickly formatted and sent a v2 patch using "git format-patch 
> --attach" and "git send-email" to try to get something at 
> https://issues.guix.gnu.org/62209 that will work properly with "git am". (I'm 
> still puzzled at what happened with the first one, as downloading the whole 
> message and applying it with "git am" also fails for me.)

It still does not - there is no first line for the commit message
(the "gnu: ...").

When I try to "git am the-message-in-mbox-format", I get:
fatal: Dirty index: cannot apply patches (dirty: gnu/local.mk 
gnu/packages/gnome.scm gnu/packages/patches/glib-networking-32-bit-time.patch)

When I just try to apply "git am 
v2-0001-gnu-glib-networking-Fix-32-bit-builds.patch":
Patch format detection failed.
(which is normal, it does not have the commit message, but starts with
"diff").

I may have made an error, but it is suspicious that QA apparently also did
not manage to extract a git commit (there is no corresponding branch in
guix-patches).

Concerning "git send-email", I recently tried it and followed the advice at
   https://guix.gnu.org/en/manual/devel/en/guix.html#Sending-a-Patch-Series
It does not involve a "git format-patch" step.

Andreas