Re: Core updates status
Hi, On Tuesday, April 23rd, 2024 at 11:08 PM, Steve George wrote: > > > Hi, > > We're trying to stabilise and merge core-updates, help definitely wanted! > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70456 > > So far the main blockers are: > > - guile-rsvg failing > - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70537 > - I'm able to build librsvg@2.56.4 but not guile-rsvg > - guile-rsvg@2.18.1 / guile2.2-rsvg > - guile-rsvg builds on master - connected? I've started looking at this build failure this morning, and my initial impressions are that a propagated-input is missing. I tried building guile-rsvg from core-updates and the build failed with three missing pango libraries (ld could not find -lpangocairo-1.0, -lpangoft2-1.0, and -lpango-1.0). I tried moving pango from the inputs to the propagated-inputs for librsvg, and that fixed the build of guile-rsvg. I'm just not sure if that is the right place to propagate it; I haven't yet traced where the pango libraries are being added to the linking command, as I've checked the pkgconfig files for librsvg, cairo, and a couple of other packages and not seen references to pango (which is what makes me think the pango propagated-input is needed elsewhere, and not actually in librsvg--but I also don't know Rust or what dependencies the rust code in librsvg has). Cheers, Kaelyn > This blocks further progress > > What builds so far: > > - gcc-toolchain and all the dependents from commencement.scm > ./pre-inst-env guix build --no-substitutes gcc-toolchain > > - bunch of the basic - but blocked on guile-rsvg > ./pre-inst-env guix system --no-substitutes vm > gnu/system/examples/bare-bones.tmpl > > Other potential issues: > > - 45885 libpng non-deterministic build > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45885 > won't build due to block on pango - > > - 58719 [core-updates]: build failure for file on i686 > https://ci.guix.gnu.org/build/4057809/details > > - 40316 [core-updates] Nss not reproducible > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40316 > confirmed > > - 68270 libstdc++-boot0.x86_64 is broken > - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68270 > > - 39415 [core-updates] Removing SSL patches in CMake and Kodi - help wanted > - check if they are there and remove? > - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39415 > > > This is building from 4a0e6e3895cefe7c2999c22e56fe9b3dbca97f55 which includes > the last merge from master. > > Thanks, > > Steve
Re: xz backdoor
Hi Reza, On Monday, April 1st, 2024 at 12:46 PM, Reza Housseini wrote: > > > Hi Guixers > > Just stumbled upon this recently discovered supply chain attack on xz, > inserting a backdoor via test files [1, 2]. And it made me wondering, > what would have been the effects on guix and how can we potentially > avoid it? Thank you for your email about the xz backdoor! To hopefully help with your questions, there has already been some discussion on guix-devel about the backdoor and how it should be handled now and in the future: https://lists.gnu.org/archive/html/guix-devel/2024-03/msg00281.html https://lists.gnu.org/archive/html/guix-devel/2024-03/msg00292.html The quick summary is that Guix currently shouldn't be affected because a) Guix currently packages xz 5.2.8, which predates the backdoor, and b) the backdoor includes checks based on absolute paths e.g. under /usr and Guix executable paths generally don't match the patterns checked for. Cheers, Kaelyn > Stay safe! > Reza > > [1] https://www.openwall.com/lists/oss-security/2024/03/29/4 > [2] https://access.redhat.com/security/cve/cve-2024-3094#cve-cvss-v3
Re: Concerns/questions around Software Heritage Archive
age or > distribution medium does not bring the other work under the scope of this > License. > > 3. You may copy and distribute the Program (or a work based on it, under > Section 2) in object code or executable form under the terms of Sections 1 > and 2 above provided that you also do one of the following: > > a) Accompany it with the complete corresponding machine-readable source > code, which must be distributed under the terms of Sections 1 and 2 above on > a medium customarily used for software interchange; or, > b) Accompany it with a written offer, valid for at least three years, to > give any third party, for a charge no more than your cost of physically > performing source distribution, a complete machine-readable copy of the > corresponding source code, to be distributed under the terms of Sections 1 > and 2 above on a medium customarily used for software interchange; or, > c) Accompany it with the information you received as to the offer to > distribute corresponding source code. (This alternative is allowed only for > noncommercial distribution and only if you received the program in object > code or executable form with such an offer, in accord with Subsection b > above.) > > The source code for a work means the preferred form of the work for making > modifications to it. For an executable work, complete source code means all > the source code for all modules it contains, plus any associated interface > definition files, plus the scripts used to control compilation and > installation of the executable. However, as a special exception, the source > code distributed need not include anything that is normally distributed (in > either source or binary form) with the major components (compiler, kernel, > and so on) of the operating system on which the executable runs, unless that > component itself accompanies the executable. > > If distribution of executable or object code is made by offering access to > copy from a designated place, then offering equivalent access to copy the > source code from the same place counts as distribution of the source code, > even though third parties are not compelled to copy the source along with the > object code. > > 4. You may not copy, modify, sublicense, or distribute the Program except as > expressly provided under this License. Any attempt otherwise to copy, modify, > sublicense or distribute the Program is void, and will automatically > terminate your rights under this License. However, parties who have received > copies, or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. Again, I want to emphasize IANAL. As a layman, my understanding of ML model training is that it cannot maintain enough of a trace between GPLed input code and its (modified) use in the output to maintain the licensing and distribution requirements from either the GPL 3 sections above or the GPL 2 sections 2 and 3. I also believe that section 4 of the GPL 2 directly applies to these LLM code models. There is also the potential licensing issues of mixing (potentially) incompatible licenses in the training data sets, such as GPL and CDDL code, with no way to distinguish or separate the (arguably) modified sources from each. Just my $0.02 USD on the LLM side of matter, as much of the discussion seems to be around the cost vs benefit of rewriting the git history for updating personally identifying information. Cheers, Kaelyn > > Cheers, > simon
Re: Update to source-highlight seems to have broken rust
On Monday, January 29th, 2024 at 9:49 AM, John Kehayias
wrote:
>
>
> Hi Kaeylyn,
>
>
> On Monday, January 29th, 2024 at 12:26 PM, Kaelyn kaelyn.al...@protonmail.com
> wrote:
>
> > Hi Efraim and guix-devel,
> >
> > Based on my local cuirass instance and some spot testing this morning, it
> > appears the change to source-highlight in commit 367bc2d198 has broken the
> > build of rust 1.73.
> > * `guix refresh -l source-highlight` reports modifying the package would
> > require a large number of rebuilds ("Building the following 6129 packages
> > would ensure 9069 dependent packages are rebuilt").
> > * I am seeing a consistent test failure for rust starting with that commit.
> > * `guix weather rust@1.73` reports 100% availability for both
> > ci.guix.gnu.org and bordeaux.guix.gnu.org at commit fbeae77ae6 but 0%
> > availability at commit 367bc2d198.
>
>
> This was reverted in 0fb160a5e8b0b800426489c0a2ad387c6934fba so maybe you
> were just unlucky in what commit you were at?
>
> I can't comment on the details of the change or rust, but hopefully just
> pulling to a newer commit will go back to good coverage for you as well.
>
> Hope that helps!
That does help, thank you! I think I missed the revert because of a minor
misbehavior? of cuirass (so me getting unlucky about the commit in a different
way!).
I have a local cuirass server set up to build the packages in a local channel,
along with a job configured to build the packages in my Guix Home configs
(currently using a manually generated manifest file that is checked in as part
of the local channel)--but I don't have notifications set up and I only
occasionally check on its status. This morning I happened to notice that
wine64-staging was reported as having been failing for a while, because of
ffmpeg-6.1.1 failing to build due to the rust failure (i.e. cuirass reported
ffmpeg as the root failed build, and looking at the error log was what revealed
that it was actually rust that failed). I then mistakenly assumed the issue was
still present because the list of evaluations and evaluation dashboard reported
wine64-staging as still failing up through the evaluation for commit 2c5293a
from a few hours prior to my email. I'm guessing the underlying issue for the
rebuild not happening for the revert commit is tied to dependency propagation
triggering rebuilds (as a likely-related example, I find it odd that while
cuirass showed the wine64-staging rebuild failed because its dependency ffmpeg
failed to build, but claimed ffmpeg was the failed package when it was a unit
test in the rust build that actually failed).
Thank you again, John, for your response about the commit having already been
reverted!
Cheers,
Kaelyn
> John
>
> > The consistently-reported failure is:
> >
> > metadata::cargo_metadata_non_utf8 stdout
> > thread 'metadata::cargo_metadata_non_utf8' panicked at
> > crates/cargo-test-support/src/paths.rs:155:33:
> > failed to mkdir_p
> > /tmp/guix-build-rust-1.73.0.drv-0/rustc-1.73.0-src/build/x86_64-unknown-linux-gnu/stage1-tools/x86_64-unknown-linux-gnu/tmp/cit/t1684/foo/�/./src:
> > Invalid or incomplete multibyte or wide character (os error 84)
> > note: run with `RUST_BACKTRACE=1` environment variable to display a
> > backtrace
> >
> > failures:
> > metadata::cargo_metadata_non_utf8
> >
> > test result: FAILED. 2801 passed; 1 failed; 198 ignored; 0 measured; 0
> > filtered out; finished in 92.81s
> >
> > error: test failed, to rerun pass `--test testsuite`
> >
> > I don't exactly understand how wrapping scripts in source-highlight ended
> > up breaking the above rust test, nor do I use rust, so I wanted to bring it
> > to folks' attention since the failure appears to affect a great many
> > packages (I noticed it in an ffmpeg build failure on my local cuirass
> > instance).
> >
> > Cheers,
> > Kaelyn
Update to source-highlight seems to have broken rust
Hi Efraim and guix-devel,
Based on my local cuirass instance and some spot testing this morning, it
appears the change to source-highlight in commit 367bc2d198 has broken the
build of rust 1.73.
* `guix refresh -l source-highlight` reports modifying the package would
require a large number of rebuilds ("Building the following 6129 packages would
ensure 9069 dependent packages are rebuilt").
* I am seeing a consistent test failure for rust starting with that commit.
* `guix weather rust@1.73` reports 100% availability for both ci.guix.gnu.org
and bordeaux.guix.gnu.org at commit fbeae77ae6 but 0% availability at commit
367bc2d198.
The consistently-reported failure is:
metadata::cargo_metadata_non_utf8 stdout
thread 'metadata::cargo_metadata_non_utf8' panicked at
crates/cargo-test-support/src/paths.rs:155:33:
failed to mkdir_p
/tmp/guix-build-rust-1.73.0.drv-0/rustc-1.73.0-src/build/x86_64-unknown-linux-gnu/stage1-tools/x86_64-unknown-linux-gnu/tmp/cit/t1684/foo/�/./src:
Invalid or incomplete multibyte or wide character (os error 84)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
metadata::cargo_metadata_non_utf8
test result: FAILED. 2801 passed; 1 failed; 198 ignored; 0 measured; 0 filtered
out; finished in 92.81s
error: test failed, to rerun pass `--test testsuite`
I don't exactly understand how wrapping scripts in source-highlight ended up
breaking the above rust test, nor do I use rust, so I wanted to bring it to
folks' attention since the failure appears to affect a great many packages (I
noticed it in an ffmpeg build failure on my local cuirass instance).
Cheers,
Kaelyn
Re: [PATCH v2] gnu: wine-staging: Update to 8.18.
Hi guix-devel,
I just sent out https://issues.guix.gnu.org/68005 to remove dxvk 1.5.5, which
as far as I can tell has been broken for a few years now (IIRC I tested as far
back in guix history as wine-staging 5.13 or 5.22 from 2-3 years ago and still
encountered the same errors building dxvk). I wanted to bump this 2+ week old
update to wine-staging since dxvk is the only dependent on wine-staging and it
does not currently build (and the QA status of bug #66936 is still "Pending").
Cheers,
Kaelyn
On Saturday, December 9th, 2023 at 10:11 AM, Kaelyn Takata
wrote:
>
> * gnu/packages/wine.scm (wine-staging): Update to 8.18.
> (wine-staging-patchset-data)[#:builder]: Adjust accordingly.
> [native-inputs]: Drop bash.
> (wine-staging)[native-inputs]: Add python-3.
> [#:phases]: Adjust path to patch script.
>
> (wine64-staging)[#:phases]: Likewise.
>
>
> Change-Id: Ie71ed785c1e821b1d1752e46b3da11809b4331e5
> ---
> gnu/packages/wine.scm | 21 ++---
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/gnu/packages/wine.scm b/gnu/packages/wine.scm
> index 400f0e7607..48f7499ba2 100644
> --- a/gnu/packages/wine.scm
> +++ b/gnu/packages/wine.scm
> @@ -304,7 +304,7 @@ (define-public wine64
> (define-public wine-staging-patchset-data
> (package
> (name "wine-staging-patchset-data")
> - (version "8.0")
> + (version "8.18")
> (source
> (origin
> (method git-fetch)
> @@ -313,10 +313,10 @@ (define-public wine-staging-patchset-data
> (commit (string-append "v" version
> (file-name (git-file-name name version))
> (sha256
> - (base32 "11q9fa1jdrv1pd9piaicgqvidq1c08imkwpqhyzcj5r711rl7581"
> + (base32 "0qabyw5139xdfsvzbwbrn1nnqssgwk8mn88mxnq2cdkk9gbjvq56"
> (build-system trivial-build-system)
> (native-inputs
> - (list bash coreutils))
> + (list coreutils))
> (arguments
> `(#:modules ((guix build utils))
> #:builder
> @@ -324,16 +324,12 @@ (define-public wine-staging-patchset-data
> (use-modules (guix build utils))
> (let* ((build-directory ,(string-append name "-" version))
> (source (assoc-ref %build-inputs "source"))
> - (bash (assoc-ref %build-inputs "bash"))
> (coreutils (assoc-ref %build-inputs "coreutils"))
> (out (assoc-ref %outputs "out"))
> (wine-staging (string-append out "/share/wine-staging")))
> (copy-recursively source build-directory)
> (with-directory-excursion build-directory
> - (substitute* "patches/patchinstall.sh"
> - (("/bin/sh")
> - (string-append bash "/bin/sh")))
> - (substitute* "patches/gitapply.sh"
> + (substitute* '("patches/gitapply.sh" "staging/patchinstall.py")
> (("/usr/bin/env")
> (string-append coreutils "/bin/env"
> (copy-recursively build-directory wine-staging)
> @@ -363,7 +359,7 @@ (define-public wine-staging
> "wine-" wine-version ".tar.xz"))
> (file-name (string-append name "-" wine-version ".tar.xz"))
> (sha256
> - (base32 "0bkr3klvjy8h4djddr31fvapsi9pc2rsiyhaa7j1lwpq704w4wh2")
> + (base32 "1nv06awb3hv26v64nqnks9yiz7w368scxznj77vxa3zpmhafzyih")
> (inputs (modify-inputs (package-inputs wine)
> (prepend autoconf ; for autoreconf
> ffmpeg
> @@ -373,6 +369,9 @@ (define-public wine-staging
> python
> util-linux ; for hexdump
> wine-staging-patchset-data)))
> + (native-inputs
> + (modify-inputs (package-native-inputs wine)
> + (prepend python-3)))
> (arguments
> (substitute-keyword-arguments (package-arguments wine)
> ((#:phases phases)
> @@ -382,7 +381,7 @@ (define-public wine-staging
> (lambda* (#:key inputs #:allow-other-keys)
> (invoke (search-input-file
> inputs
> - "/share/wine-staging/patches/patchinstall.sh")
> + "/share/wine-staging/staging/patchinstall.py")
> "DESTDIR=."
> "--all")))
> (add-after 'apply-wine-staging-patches 'patch-SHELL
> @@ -417,7 +416,7 @@ (define-public wine64-staging
> (lambda* (#:key inputs #:allow-other-keys)
> (invoke (search-input-file
> inputs
> - "/share/wine-staging/patches/patchinstall.sh")
> + "/share/wine-staging/staging/patchinstall.py")
> "DESTDIR=."
> "--all")))
> (add-after 'apply-wine-staging-patches 'patch-SHELL
>
> base-commit: 61f2d84e75c340c2ba528d392f522c51b8843f34
> --
> 2.41.0
Re: xwayland security updates, to mesa- or core-updates or ?
On Thursday, December 14th, 2023 at 10:21 PM, John Kehayias wrote: > > Hi Guix, > > In light of (more) CVEs in xwayland, see > https://lists.x.org/archives/xorg-announce/2023-December/003435.html, > > with already pending security updates, see > https://issues.guix.gnu.org/67136, I would like to prioritize > > getting that fixed in master. The tricky thing is that, according to > 67136, the xwayland update needs newer xorgproto, which corresponds to > many rebuilds. (The related CVEs in xorg-server have been pushed > already as effectively minor version bumps.) > > Where is the most efficient branch for this, that could take these > rebuilds to be merged to master soon (whatever soon is for a scope of > something like 22k affected packages)? > > I was thinking to put that update and mesa, since it had a new stable > release after the current one never got updates, on mesa-updates and > merge once builds are done assuming no issues. Again, the potential > sore spot is xorgproto I would say. I could see about any other > pending/urgent related changes, but I'm not aware of any off the top > of my head and want to let this move quickly. I also don't want to > jump the queue sending other branches to rebuild everything again. This doesn't seem unreasonable to me, for picking up both the new mesa release and the latest xwayland security fixes. > I'll test things locally in the meantime, but please chime in. If I > don't hear anything too urgent I'll update the mesa-updates branch to > start builds at least. I've also cc'ed some names I think will be > knowledgeable about some current branches. > > And thanks to Kaelyn (also cc'ed) for the pending xwayland patches! You're welcome! I've been working on updating my patch set to xwayland 23.2.3, but it's been taking a while to build the update because most of the dependency stack on core-updates apparently needed rebuilding locally (presumably from a lack of recent substitutes unrelated to the xorgproto-triggered rebuilds, but that's based on my computer churning away at the build for the past day or so, and not having checked guix weather yet--I even ran into an issue with coreutils-minimal failing a test when /tmp was a btrfs partition, that I got past by mounting a tmpfs on /tmp). Cheers, Kaelyn > > Thanks! > John
Re: bug#66964: Request for merging "mesa-updates" branch
Hi, On Tuesday, November 14th, 2023 at 12:36 PM, Kaelyn wrote: > > Hi John, > > On Tuesday, November 14th, 2023 at 12:11 PM, John Kehayias > john.kehay...@protonmail.com wrote: > > > Hi Kaelyn, > > > > On Sun, Nov 12, 2023 at 08:01 PM, Kaelyn wrote: > > > > > Hi, > > > > > > I've just submitted a pair of patches for the mesa-updates branch: > > > https://issues.guix.gnu.org/67136 updating xorgproto and > > > xorg-server-xwayland. The xorgproto is a high-impact update (guix > > > refresh reports rebuilding 8710 packages would ensure 22871 dependent > > > packages are rebuilt), but required to update to the latest xwayland > > > as xwayland requires a newer version of presentproto than in the > > > current guix xorgproto package. The updating and ungrafting of mesa > > > and a number of X.org related libraries seemed like a good time (and > > > place) to update xorgproto as well. > > > > > > Cheers, > > > Kaelyn > > > > Thanks for the patches. I think mesa-updates in this current iteration > > is set on builds (ended up being a lot more due to the ungrafting but > > seems done on our main architectures for several days now). I had to > > make some other changes to fix some larger breakages but at this point I > > think it will just be taking us back in the build queue too much. > > > > So I think it would make more sense on the next big rebuild, either > > core-updates (talk about doing that with more ungrafts right now) or > > I'll do mesa-updates again when the next release of mesa hits. Or maybe > > it makes sense to just do another branch for xwayland? > > > > Open to ideas! I'll send a separate message soon on the status of > > mesa-updates and see what people think, but my thought was to merge this > > to master in the next day or so if there are no objections. > > > > Thanks! > > John > > > No worries! I realize I was a little late to the party for the mesa-updates > branch (had some ongoing technical issues), so if core-updates is still early > enough in the process I think it would be good to push the changes to that > branch. The current xwayland is pretty old, and the updated version has quite > a few CVEs fixed in comparison (just > https://www.phoronix.com/news/X.Org-Halloween-Bugs-2023 and > https://www.phoronix.com/news/X.Org-Server-Holiday-2022 list 8 CVEs fixed > between xwayland 21.1.3 and 23.2.2). I forgot to sent an email when I did this, but a few weeks ago I updated the xorgproto/xwayland update ticket (#66964) to refer to core-updates instead of mesa-updates and sent in a v2 of the patches rebased against core-updates. Cheers, Kaelyn
Re: problems installing on LUKS2 encrypted device
Hi Gio, On Friday, December 8th, 2023 at 9:34 AM, Giovanni Biscuolo wrote: > > Hello, > > I've noticed that the last released system installer [1], when using the > guided install workflow, is using a LUKS1 encryption; since I would like > to install on a LUKS2 encrypted root filesystem I tried to "manually" > install following the instructions in the manual [2]. > > When using a LUKS2 encryption format [3], completing the installation > and rebooting, I get an error from Grub: it cannot find the encrypted > volume, it's trying to open the /unencrypted/ volume instead (via UUID), > child of the LUKS2 encrypted one. > > If I just change the type of encryption to "luks1" in [3], the booting > of the installed machine works as expected. > > Since I know that the LUKS2 support in Grub was not available when Guix > 1.4 was released, I also tried to "guix pull && hash guix" /before/ > installing with "guix system init /mnt/etc/config.scm /mnt", but the > error was the same. > > I still have not tried to build an updated system installation image to > see if it is working. > > Since the (stable) manual provides instructions on how to install Guix > System on a LUKS2 encrypted partition [4], I'd like to understand if I'm > doing something wrong or there is a bug, at least in the manual. About halfway through the email, your use of LUKS2 with Grub was tickling my brain about what I remembered reading regarding Grub's LUKS2 support being limited. While searching for references for that--and subsequently seeing that you were already using PBKDF2--I came across https://savannah.gnu.org/bugs/?55093 which seems to hold the answer. According to the newest comment, Grub 2.06 has a seemingly-undocumented additional requirement for working with LUKS2 of needing to use sha256 as the keyslot hash. Additionally, https://wiki.archlinux.org/title/GRUB#LUKS2 suggests that Grub 2.06 requires manually creating an EFI binary using grub-mkimage (with grub-install once again being sufficient in 2.12rc1), though I don't know if the Guix bootloader machinery addresses that shortcoming or not. Please take the above with a grain of salt, as I have only ever used LUKS1 with Grub (and I've recently started moving away from Grub). HTH! Cheers, Kaelyn > I'm attaching the script I'm using for the "manual" installation: if I > set "luks2" in the "cryptsetup luksFormat..." command /and/ uncomment > the "guix pull && hash guix" commands, the installation provides an > unbootable system. > > Sorry for the "short story made long" but my script it's a proof of > concept to allow installing a Guix System starting from any (recent) > rescue system (tested only with a Guix install image and a systemd > rescue system, grml), that's why is so "long": > > > > Thanks! Gio' > > [1] https://ftp.gnu.org/gnu/guix/guix-system-install-1.4.0.-linux.iso > > > [2] https://guix.gnu.org/en/manual/en/html_node/Manual-Installation.html > > [3] cryptsetup luksFormat --type luks2 --pbkdf pbkdf2 /dev/sdaX > > [4] > https://guix.gnu.org/en/manual/en/html_node/Keyboard-Layout-and-Networking-and-Partitioning.html > > -- > Giovanni Biscuolo > > Xelera IT Infrastructures
Re: [PATCH] gnu: xorg-server: Update to 21.1.9.
Hi, I wanted to bring folks' attention to https://issues.guix.gnu.org/67047 which updates xorg-server, including a number of security fixes. The patch has been pending for about 17 days now, and while the QA badge reports "failed" I just spot-checked some of the failures and they seem to be unrelated (e.g. a lot of builds going from unknown to blocked or vice versa, the one new failure for aarch64 being a large download test in the onionshare package, etc). Is there anything I can do to help the process along? It may also be worth noting that "guix refresh -l xorg-server" reports 125 rebuilds. I also checked and the update to xorg-server does not appear to alter the derivation for the xorg-server-for-tests (which is still at version 21.1.1). Cheers, Kaelyn
Re: bug#66964: Request for merging "mesa-updates" branch
Hi John, On Tuesday, November 14th, 2023 at 12:11 PM, John Kehayias wrote: > > Hi Kaelyn, > > On Sun, Nov 12, 2023 at 08:01 PM, Kaelyn wrote: > > > Hi, > > > > I've just submitted a pair of patches for the mesa-updates branch: > > https://issues.guix.gnu.org/67136 updating xorgproto and > > xorg-server-xwayland. The xorgproto is a high-impact update (guix > > refresh reports rebuilding 8710 packages would ensure 22871 dependent > > packages are rebuilt), but required to update to the latest xwayland > > as xwayland requires a newer version of presentproto than in the > > current guix xorgproto package. The updating and ungrafting of mesa > > and a number of X.org related libraries seemed like a good time (and > > place) to update xorgproto as well. > > > > Cheers, > > Kaelyn > > > Thanks for the patches. I think mesa-updates in this current iteration > is set on builds (ended up being a lot more due to the ungrafting but > seems done on our main architectures for several days now). I had to > make some other changes to fix some larger breakages but at this point I > think it will just be taking us back in the build queue too much. > > So I think it would make more sense on the next big rebuild, either > core-updates (talk about doing that with more ungrafts right now) or > I'll do mesa-updates again when the next release of mesa hits. Or maybe > it makes sense to just do another branch for xwayland? > > Open to ideas! I'll send a separate message soon on the status of > mesa-updates and see what people think, but my thought was to merge this > to master in the next day or so if there are no objections. > > Thanks! > John No worries! I realize I was a little late to the party for the mesa-updates branch (had some ongoing technical issues), so if core-updates is still early enough in the process I think it would be good to push the changes to that branch. The current xwayland is pretty old, and the updated version has quite a few CVEs fixed in comparison (just https://www.phoronix.com/news/X.Org-Halloween-Bugs-2023 and https://www.phoronix.com/news/X.Org-Server-Holiday-2022 list 8 CVEs fixed between xwayland 21.1.3 and 23.2.2). Cheers, Kaelyn
Re: mesa-updates: call for patches
Hi, I've just submitted a pair of patches for the mesa-updates branch: <https://issues.guix.gnu.org/67136> updating xorgproto and xorg-server-xwayland. The xorgproto is a high-impact update (guix refresh reports rebuilding 8710 packages would ensure 22871 dependent packages are rebuilt), but required to update to the latest xwayland as xwayland requires a newer version of presentproto than in the current guix xorgproto package. The updating and ungrafting of mesa and a number of X.org related libraries seemed like a good time (and place) to update xorgproto as well. Cheers, Kaelyn
Re: branch master updated: gnu: Add passff.
--- Original Message ---
On Saturday, October 28th, 2023 at 8:05 AM, Clément Lassieur
wrote:
>
>
> On Sat, Oct 28 2023, Christopher Baines wrote:
>
> > This passff-host package looks a bit odd to me, one thing to mention is
> > that guix show says it has no dependencies, but I don't think that's
> > correct:
I agree about this. When I packaged passff-host locally some time ago, I saw it
has a runtime dependency on python and also needs to be able to find the pass
binary. I've attached the bare (unfinished/unpolished) package definition
extracted from my local channel and attached it, for if it is of assistance to
folks. My definition tries to embed a sane path for finding pass with a default
of the path to the password-store package it was built against, and also tries
to copy the passff.json into the correct browser folder for Chromium, Firefox,
and Icecat based on the packaged install_host_app.sh script (note: I have only
used it with Icecat).
Cheers,
Kaelyn
> >
> > ./pre-inst-env guix show passff-host
> > name: passff-host
> > version: 1.2.3
> > outputs:
> > + out: everything
> > systems: x86_64-linux mips64el-linux aarch64-linux powerpc64le-linux
> > riscv64-linux
> > + i686-linux armhf-linux i586-gnu powerpc-linux
> > dependencies:
>
>
> I imagine it's a bug in `guix show`? As doc says:
>
> • Gexps carry information about the packages or derivations they
> refer to, and these dependencies are automatically added as inputs
> to the build processes that use them.
>
> > Was this change sent as a patch to guix-patches?
>
>
> No it wasn't.
I(define-public passff-host
(package
(name "passff-host")
(version "1.2.3")
(home-page "https://github.com/passff/passff-host/;)
(source
(origin
(method git-fetch)
(uri (git-reference (url home-page)
(commit version)))
(file-name (git-file-name name version))
(sha256
(base32
"1p18l1jh20x4v8dj64z9qjlp96fxsl5h069iynxfpbkzj6hd74yl"))
))
;; NOTE: python-build-system is used instead of copy-build-system to
;; automatically pick up the Python 3 dependency and to wrap the installed
;; Python script.
;; FIXME: The passff.json in etc/ needs to go into a browser-dependent
;; location to work with that specific browser. How to install it to the
;; right location needs to be figured out and documented.
(build-system python-build-system)
(arguments
(list #:tests? #f ; There are no tests
#:phases
#~(modify-phases %standard-phases
(replace 'build
(lambda _
;; TODO? Add password-store as an input and embed the store
;; path to the "pass" executable.
(substitute* "src/passff.py"
(("_VERSIONHOLDER_") #$(package-version this-package))
;; (("\"pass\"") (string-append
;;"\""
;;#$(this-package-input "password-store")
;;"/bin/pass\""))
(("\"PATH\": .*")
(string-join (list
"\"PATH\""
" \"/run/current-system/profile/bin"
"/run/booted-system/profile/bin"
(string-append
#$(this-package-input "password-store")
"/bin\",\n"))
":"))
)))
(replace 'install
(lambda _
(let ((etc (string-append #$output "/etc"))
(libexec (string-append #$output "/libexec")))
;; Install the host script in libexec
(install-file "src/passff.py" libexec)
;; Insert the script path and install the (example)
;; native host manifest to etc
(substitute* "src/passff.json"
(("PLACEHOLDER") (string-append libexec "/passff.py")))
(for-each
(lambda (dir)
(install-file "src/passff.json" dir))
(list etc ;; Generic location for easier access
;; Chromium location based on src/install_host_app.sh
(string-append etc "/chromium/nati
Re: Order of manifest and overlapping binaries
he argument has to be a list after being evaluated twice (the first evaluation is of the quote, the second occurs after the gexp was expanded and calls list with the string arguments). For #3, the expectation of a list is more explicit, but the argument has to evaluate to a list where all of the elements have to then evaluate to something meaningful (not too much of an issue for this case as strings evaluate to themselves). #2 should only require that the evaluated argument has a printable representation that can be read back in, which at least to me feels more natural to work with. Hope my early morning explanation helps! Cheers, Kaelyn > Backtrace: > 9 (primitive-load "/gnu/store/qrj9l194a552vpg2234xx55k76j…") > In guix/build/gnu-build-system.scm: > 908:2 8 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #) > In ice-9/boot-9.scm: > 1752:10 7 (with-exception-handler _ _ #:unwind? _ # _) > In srfi/srfi-1.scm: > 634:9 6 (for-each # …) > > In ice-9/boot-9.scm: > 1752:10 5 (with-exception-handler _ _ #:unwind? _ # ) > In guix/build/gnu-build-system.scm: > 929:23 4 () > In ice-9/eval.scm: > 159:9 3 (_ #(#(#(#) (#)) …)) > > 159:9 2 (_ _) > In ice-9/boot-9.scm: > 1685:16 1 (raise-exception _ #:continuable? _) > 1685:16 0 (raise-exception _ #:continuable? _) > > ice-9/boot-9.scm:1685:16: In procedure raise-exception: > Wrong type to apply: "bin/parallel" > --8<---cut here---end--->8---
Re: Relaxing the restrictions for store item names
Hi, A couple of small early-morning (for me) comments below... not for or against the idea of percent encoding, but as a little bit of food for thought while pondering how to handle Unicode in package names and/or store paths. On Friday, August 25th, 2023 at 2:01 PM, Eidvilas Markevičius wrote: > Although now, just a few hours later, I'm having second thoughts on > this. When you really think about it, it's very unlinkely that some > user would prefer typing something like > > guix install > %D0%B8%D0%BC%D0%B0%D0%B3%D0%B8%D0%BD%D0%B0%D1%80%D0%B8-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC > > over > > guix install имагинари-програм I imagine that, for usability, the percent encoding (or other encoding or transliteration) of non-ASCII characters could be handled transparently, i.e. for "guix install имагинари-програм", guix would translate "имагинари-програм" to the encoded form for operations. And if the escape character (e.g. the "%" in percent encoding) isn't also a valid character for store or package names then the values can be handled transparently. For example, both "guix install git" and "guix install %67%69%74" and "guix install g%69t" would all install git. > even if they don't have the russian (or whatever other language) > keyboard layout set up on their system, so just for accessability > purposes, the solution wouldn't be all that great. > It would also make > store name unnecessarily long (they're already long as is), and > there's a 255 char limit for filenames that we have to keep in mind as > well. Searching the store using standard utilities such as find and > grep would too, as a consequence, I split out the quote above as a bit of reference. While I agree that we have to keep in mind the 255 char limit for filenames, with percent encoding causing a single byte in ASCII or UTF-8 to become ~3 bytes (with iirc most non-latin characters having multi-byte encodings in UTF-8) and the store hashes being a 33 byte prefix (counting the dash), 255 chars is still quite a bit. Specifically, the extracted quote above--without the "> " prefixes and with line breaks treated as single characters--is exactly 255 characters. (I find a bit of readable text to be helpful for wrapping my brain around a value like "255 characters".) Cheers, Kaelyn > break... There's just too many > problems with this. > > I believe what Julien proposed is the most reasonable solution: > unrestrict unicode characters in the store and (maybe) make it a > project policy to not put unicode characters inside package names > (however, personally I wouldn't be against that either). > > Now ensuring that URIs don't break, especially for substitute > provision, should also be taken into consideration, but this can be > handled separately. > > On Fri, Aug 25, 2023 at 12:14 PM Eidvilas Markevičius > markeviciuseidvi...@gmail.com wrote: > > > On Fri, Aug 25, 2023 at 11:37 AM Nathan Dehnel ncdeh...@gmail.com wrote: > > > > > What you could do is implement percent encoding: > > > https://en.wikipedia.org/wiki/Percent-encoding > > > -Allows you to store package titles in any language in an encoded form > > > -Allows the titles to be typed on latin keyboards > > > -Allows the packages to be accessed through URIs in the future without > > > causing problems > > > > Now that's an idea. I didn't really thought of that. Although it'd > > probably be trickier to implement in order to make all the tooling > > compatible. I think that might be a good solution nonetheless.
Re: Relaxing the restrictions for store item names
Hi, On Tuesday, August 22nd, 2023 at 6:49 AM, Eidvilas Markevičius wrote: > Therefore, my proposal is to relax these limitations as much as > possible (or at least somewhat) and to allow some more freedom when it > comes to naming packages and other kinds of items in the store. We > could, of course, still disallow all the main problematic characters, > such as NUL, /, $, ~, space, newline and a few others, but other than > that, I don't see any reason to forbid any of the remaining ones from > being used. While I don't really have an opinion on the matter aside from the biases of growing up in the US, one non-trivial issue with Unicode store paths and package names which hasn't been mentioned is that of Unicode equivalence[1], particularly homographs[2]. For example U+0061 and U+0430 (the Latin and Cyrillic small letter "a", respectively) are often visually identical but programmatically distinct. If not handled well, it could lead to untypable package or store names by virtue of the user having to guess which Unicode code point(s) is/are the correct one(s) for a certain visual glyph. Cheers, Kaelyn [1] https://en.wikipedia.org/wiki/Unicode_equivalence [2] https://en.wikipedia.org/wiki/IDN_homograph_attack
Re: Do substitutes download slowly for you? / Speeding up substitute delivery/mirrors
> France: wget > https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 > US: wget > https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 > Singapore: wget > https://bordeaux-singapore-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 > > > So please share the output from wget and if you're comfortable doing so, > the rough real world location of where the computer doing the > downloading is. I'm in Salem, Oregon with Comcast/Xfinity home internet, and while the speeds I get from sites varies a lot, the mirrors are kind of all equally slow for me compared to what I usually see. The Singapore mirror was a little slower on average than France or US east, but all three showed fluctuations throughout the transfer ranging roughly from 650KB/s to 3+MB/s. Below are my results, along with a 4th result downloading a kernel tarball from kernel.org which shows a more typical speed for me. Cheers, Kaelyn $ wget -O/dev/null https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 --2023-05-26 11:13:25-- https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 Resolving bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)... 185.233.100.56, 2a0c:e300::58 Connecting to bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)|185.233.100.56|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 208615205 (199M) [text/plain] Saving to: ‘/dev/null’ /dev/null100%[>] 198.95M 1.07MB/sin 1m 57s 2023-05-26 11:15:23 (1.70 MB/s) - ‘/dev/null’ saved [208615205/208615205] $ wget -O/dev/null https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 --2023-05-26 11:16:09-- https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 Resolving bordeaux-us-east-mirror.cbaines.net (bordeaux-us-east-mirror.cbaines.net)... 5.161.49.48 Connecting to bordeaux-us-east-mirror.cbaines.net (bordeaux-us-east-mirror.cbaines.net)|5.161.49.48|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 208615205 (199M) [text/plain] Saving to: ‘/dev/null’ /dev/null100%[>] 198.95M 1.65MB/sin 2m 2s 2023-05-26 11:18:12 (1.62 MB/s) - ‘/dev/null’ saved [208615205/208615205] $ wget -O/dev/null https://bordeaux-singapore-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 --2023-05-26 11:18:30-- https://bordeaux-singapore-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 Resolving bordeaux-singapore-mirror.cbaines.net (bordeaux-singapore-mirror.cbaines.net)... 64.176.80.78, 2401:c080:1400:71df:5400:4ff:fe73:757d Connecting to bordeaux-singapore-mirror.cbaines.net (bordeaux-singapore-mirror.cbaines.net)|64.176.80.78|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 208615205 (199M) [text/plain] Saving to: ‘/dev/null’ /dev/null100%[>] 198.95M 760KB/sin 2m 26s 2023-05-26 11:20:57 (1.37 MB/s) - ‘/dev/null’ saved [208615205/208615205] $ wget -O/dev/null https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.1.30.tar.xz --2023-05-26 11:21:17-- https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.1.30.tar.xz Resolving cdn.kernel.org (cdn.kernel.org)... 151.101.1.176, 151.101.65.176, 151.101.193.176, ... Connecting to cdn.kernel.org (cdn.kernel.org)|151.101.1.176|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 134914908 (129M) [application/x-xz] Saving to: ‘/dev/null’ /dev/null100%[>] 128.66M 10.2MB/sin 12s 2023-05-26 11:21:34 (10.5 MB/s) - ‘/dev/null’ saved [134914908/134914908]
Re: Howto reference a custom package from a manifest
--- Original Message --- On Wednesday, May 24th, 2023 at 8:25 PM, Timothy Washington wrote: > . This is expected. When you ran the "guix package -L ~/dotfiles/ -m > ~/dotfiles/guix/packages/manifest.scm" command above, that not only built the > manifest but also > used the manifest to create a new generation of /home/twashing/.guix-profile. > > Ah I see. > > . If you run "guix package --list-generations" you should see a list of all > of the existing (numbered) generations with the currently active generation > marked > (it's typically the last / latest generation, and should be in this case). > . Running "guix package -I" will list the packages in the current generation > of your default guix profile, > which should contain the packages in your manifest. > > . To go into more details about how profiles work: unless you specify the > "-p" argument to "guix package", > it will operate on your default profile when installing or removing packages > (including through using manifests with "-m"), > and create a new generation when the set of installed packages changes. > > . /home/twashing/.guix-profile is a symlink to > /var/guix/profiles/per-user/twashing/guix-profile, > which in turn is a symlink to one of the numbered symlinks in that same > /var/guix directory (i.e. if your current generation number is 14, then > /var/guix/profiles/per-user/twashing/guix-profile will point to > /var/guix/profiles/per-user/twashing/guix-profile-14-link). > > . Each of those numbered symlinks points to the actual profile in /gnu/store, > so using that hypothetical generation 14 as the one created by your "guix > package -m" command above, > /var/guix/profiles/per-user/twashing/guix-profile-14-link would be a symlink > to /gnu/store/sqaz4ff2nshfizfh8ymbzllia6lsgnfv-profile. > > This is really useful for my understanding. Thank-you! > > But when I restart my machine, the currently installed tools (from "guix > package -i foo") are not available on login. > For example, I manually ran "guix package -i tree git". And after restarting > my machine, those were no longer available, even though presumably they > should have been part of my latest generation. > I do remember trying to load the tools like below. But git and tree were > still not available. > ". /home/twashing/.guix-profile/etc/profile" > > Are tools in generations cumulative? They are when installed or removed via "guix package -i" and "guix package -r". Updating your profile using a manifest is not cumulative--the new generation of your profile will have exactly the set of packages in the manifest. You can then use "guix package -i" and "guix package -r" to modify the installed set, but the set will be reset if/when "guix package -m my-manifest.scm" is run. > And how can I load the cumulative sum of all my generations, and any custom > profiles I create? The most reproducible way to maintain the set of packages in your default profile is to include them in your manifest (e.g. adding git and tree to the list of packages included in the manifest, then running "guix package -m your-manifest.scm" again). The generations of a profile are like git commits or filesystem snapshots in that they represent the profile at different points in time, and they aren't really meant to be composed together. If you'd like to maintain separate profiles for different sets of packages or groups of functionality instead of installing all the things you need in your default profile, I might recommend taking a look at the Guix Cookbook, in particular https://guix.gnu.org/cookbook/en/html_node/Guix-Profiles-in-Practice.html. On a different tack, if you have no issue with installing all of the packages you need in a single profile using a manifest, and you'd like a way of managing at least some of your home configuration (shell aliases, simple config files, etc), there is also "guix home" for a declarative way of specify those pieces: https://guix.gnu.org/en/manual/devel/en/html_node/Home-Configuration.html. In a manner of speaking, it is to your home directory what "guix system" is to the OS when booting Guix. Cheers, Kaelyn > > Thanks againTim > > On Tue, 23 May 2023 at 12:39, Kaelyn wrote: > > > Hi Tim, > > > > --- Original Message --- > > On Monday, May 22nd, 2023 at 8:20 PM, Timothy Washington > > wrote: > > > > > > > Yes that was it! I added "(native-inputs (list perl python))" to my > > > package definition. > > > $ guix build -L ~/dotfiles/ rust-rustscan # A. Now builds again! > > >
Re: Howto reference a custom package from a manifest
Hi Tim,
--- Original Message ---
On Monday, May 22nd, 2023 at 8:20 PM, Timothy Washington
wrote:
> Yes that was it! I added "(native-inputs (list perl python))" to my package
> definition.
> $ guix build -L ~/dotfiles/ rust-rustscan # A. Now builds again!
> /gnu/store/4bldy27x1f2mzjqg5jd176nrawl98y1y-rust-rustscan-2.1.1
>
> $ guix package -L ~/dotfiles/ -m ~/dotfiles/guix/packages/manifest.scm # B.
> Now also builds!
> ...
> The following derivation will be built:
> /gnu/store/xll763hpl7mvdkxd3kf8f98pygarzh41-profile.drv
>
> ...
>
> guix package --list-profiles # C. does NOT show the custom profile just built
> /home/twashing/.config/guix/current
> /home/twashing/.guix-profile
This is expected. When you ran the "guix package -L ~/dotfiles/ -m
~/dotfiles/guix/packages/manifest.scm" command above, that not only built the
manifest but also used the manifest to create a new generation of
/home/twashing/.guix-profile. If you run "guix package --list-generations" you
should see a list of all of the existing (numbered) generations with the
currently active generation marked (it's typically the last / latest
generation, and should be in this case). Running "guix package -I" will list
the packages in the current generation of your default guix profile, which
should contain the packages in your manifest.
To go into more details about how profiles work: unless you specify the "-p"
argument to "guix package", it will operate on your default profile when
installing or removing packages (including through using manifests with "-m"),
and create a new generation when the set of installed packages changes.
/home/twashing/.guix-profile is a symlink to
/var/guix/profiles/per-user/twashing/guix-profile, which in turn is a symlink
to one of the numbered symlinks in that same /var/guix directory (i.e. if your
current generation number is 14, then
/var/guix/profiles/per-user/twashing/guix-profile will point to
/var/guix/profiles/per-user/twashing/guix-profile-14-link). Each of those
numbered symlinks points to the actual profile in /gnu/store, so using that
hypothetical generation 14 as the one created by your "guix package -m" command
above, /var/guix/profiles/per-user/twashing/guix-profile-14-link would be a
symlink to /gnu/store/sqaz4ff2nshfizfh8ymbzllia6lsgnfv-profile.
>
>
> cat /gnu/store/xll763hpl7mvdkxd3kf8f98pygarzh41-profile.drv # D. DOES show
> the new profile in /gnu/store
> Derive([("out","/gnu/store/sqaz4ff2nshfizfh8ymbzllia6lsgnfv-profile","","")],
> ...
> ("out","/gnu/store/sqaz4ff2nshfizfh8ymbzllia6lsgnfv-profile"),("preferLocalBuild","1")])
>
>
> i. Using a direct "guix build" gives you a directory in "/gnu/store". And you
> can add that bin to your PATH.
This is fragile and will work only as long as the package exists under
/gnu/store. Which is to say, this method will break as soon as "guix gc" is run
unless the package happens to be "live" as a member or dependency of any
existing generation of the system profile or other profiles (the profile
generation symlinks like the guix-profile-14-link mentioned above are the
garbage collector roots for guix, as can be seen with "guix gc --list-roots").
> ii. But for "/gnu/store/*-profile/", would you just loop over those profile
> directories, and run each "/gnu/store/*-profile/etc/profile"?
This is a very bad idea, as many or most of those "/gnu/store/*-profile"
directories are different generations of the same profile, and sourcing them
all would result in many conflicts and other troubles, including having
unpredictable and likely outdated versions of commands being picked up before
newer counterparts.
Cheers,
Kaelyn
>
>
> I'm attaching the full package definition to this email.
>
> Thanks a lot!Tim
>
> On Mon, 22 May 2023 at 14:18, Kaelyn wrote:
>
> > Hi Tim,
> >
> >
> > --- Original Message ---
> > On Sunday, May 21st, 2023 at 8:35 PM, Timothy Washington
> > wrote:
> >
> >
> > > Hey Simon, sure thing.
> > > I've attached "shaka.scm" here. I was able to build it separately (see
> > > "Howto supply cargo-build-system dependency to guix package definition").
> > > That was using these commands.
> > >
> > > guix import crate -r rustscan
> > >
> > > guix build -L ~/dotfiles/ rust-rustscan-2
> > >
> > >
> > > A. I re-ran "guix build". Note that I definitely installed (and sourced)
> > > perl and python3.
> >
> >
> > You will need
Re: Howto reference a custom package from a manifest
Hi Tim,
--- Original Message ---
On Sunday, May 21st, 2023 at 8:35 PM, Timothy Washington
wrote:
> Hey Simon, sure thing.
>
> I've attached "shaka.scm" here. I was able to build it separately (see
> "[Howto supply cargo-build-system dependency to guix package
> definition](https://lists.gnu.org/archive/html/help-guix/2023-05/msg9.html)").
> That was using these commands.
>
> guix import crate -r rustscan
> guix build -L ~/dotfiles/ rust-rustscan-2
>
> A. I re-ran "guix build". Note that I definitely installed (and sourced) perl
> and python3.
You will need to add perl and python to the native-inputs field of your
rust-rustscan-2 package for it to see those two programs. When packages are
built, the building happens in an isolated environment distinct from your shell
environment, so packages you install through "guix package -i" or "guix
install" won't be seen in the package's build environment.
https://guix.gnu.org/en/manual/devel/en/html_node/package-Reference.html#package-Reference
describes the various fields including three different types of inputs, but my
rule of thumb is that if the package depends on and is linking to a library
then the library package is an input, and if the dependency is a program that
needs to be run as part of the build (such as the rustscan package trying to
run perl and python3) it should be a native-input. HTH!
Cheers,
Kaelyn
P.S. I've not packaged any rust code, but from what I recall rust packages that
use cargo-build-system are a bit anomalous in that they have to declare the
rust packages they depend on in a #:cargo-inputs argument instead of the normal
inputs package field.
> And updated my system with "guix pull && guix package -u". But now it's
> failing with the below.
>
> guix build -L ~/dotfiles/ rust-rustscan
>
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%guix
> substitute: warning: ci.guix.gnu.org: connection failed: Connection timed out
> substitute:
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'...
> 100.0%
> The following derivation will be built:
> /gnu/store/x695f07186dwqpw2jk48b62p2s18f5ry-rust-rustscan-2.1.1.drv
> ...
> phase `patch-usr-bin-file' succeeded after 0.0 seconds
> starting phase `patch-source-shebangs'
> patch-shebang: ./fixtures/.rustscan_scripts/test_script.pl: warning: no
> binary for interpreter `perl' found in $PATH
> patch-shebang: ./fixtures/.rustscan_scripts/test_script.py: warning: no
> binary for interpreter `python3' found in $PATH
> patch-shebang: ./fixtures/.rustscan_scripts/test_script.sh: changing
> `/bin/bash' to
> `/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash'
> phase `patch-source-shebangs' succeeded after 0.0 seconds
> starting phase `configure'
> Unpacking rust-ansi-term
> ...
> error: failed to run custom build command for `ring v0.16.20`
> Caused by:
> process didn't exit successfully:
> `/tmp/guix-build-rust-rustscan-2.1.1.drv-0/rustscan-2.1.1/target/release/build/ring-9bf05aa562ef9c86/build-script-build`
> (exit status: 101)
> --- stderr
> running "perl" "crypto/fipsmodule/aes/asm/aesni-x86_64.pl" "elf"
> "/tmp/guix-build-rust-rustscan-2.1.1.drv-0/rustscan-2.1.1/target/release/build/ring-297f46c71994a65c/out/aesni-x86_64-elf.S"
> thread 'main' panicked at 'failed to execute ["perl"
> "crypto/fipsmodule/aes/asm/aesni-x86_64.pl" "elf"
> "/tmp/guix-build-rust-rustscan-2.1.1.drv-0/rustscan-2.1.1/target/release/build/ring-297f46c71994a65c/out/aesni-x86_64-elf.S"]:
> No such file or directory (os error 2)',
> /tmp/guix-build-rust-rustscan-2.1.1.drv-0/rustscan-2.1.1/guix-vendor/rust-ring-0.16.20.tar.xz/build.rs:653:9
> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
> warning: build failed, waiting for other jobs to finish...
> error: in phase 'build': uncaught exception:
> %exception #< program: "cargo" arguments: ("build" "--release")
> exit-status: 101 term-signal: #f stop-signal: #f>
> phase `build' failed after 12.2 seconds
> command "cargo" "build" "--release" failed with status 101
> builder for
> `/gnu/store/x695f07186dwqpw2jk48b62p2s18f5ry-rust-rustscan-2.1.1.drv' failed
> with exit code 1
> build of /gnu/store/x695f07186dwqpw2jk48b62p2s18f5ry-rust-rustscan-2.1.1.drv
> failed
> View build log at
> '/var/log/guix/drvs/x6/95f07186dwqpw2jk48b62p2s18f5ry-rust-rustscan-2.1.1.drv.gz'.
> guix build: error: build of
> `/gnu/store/x695f07186dwqpw2jk48b62p2s18f5ry-rust-rustscan-2.1.1.drv' failed
>
> B. The idea is to include that package as part
Re: Mesa vulkan layer path fix for core-updates
Hi, --- Original Message --- On Tuesday, May 9th, 2023 at 4:51 AM, John Kehayias wrote: > > Hello, > > On Tue, Apr 25, 2023 at 04:40 PM, Kaelyn wrote: > > > Hi, > > > > --- Original Message --- > > On Tuesday, April 25th, 2023 at 2:15 PM, Andreas Enge andr...@enge.fr wrote: > > > > > Hello Kaelyn, > > > > > > thanks for your research! > > > > You're welcome! :) > > > > > Am Wed, Apr 19, 2023 at 04:07:51PM + schrieb Kaelyn: > > > > > > > * https://issues.guix.gnu.org/62176 can be closed when > > > > core-updates is merged, since core-updates contains mesa 22.2.4 > > > > * Though not exactly mesa-related, > > > > https://issues.guix.gnu.org/61364 can possibly be closed now, and > > > > almost certainly once the core-updates merge is completed. (The > > > > ticket is a number of workarounds the user applied in early Feb to > > > > be able to build their system profile using core-updates, to pick > > > > up Mesa 22 for newer hardware support. I'm not sure if any of the > > > > patches are still relevant.) > > > > > > I just closed these two. > > > > > > > * https://issues.guix.gnu.org/58887 looks like an alternate way of > > > > solving the layer path issues that > > > > https://issues.guix.gnu.org/59453 also addresses. Additionally, it > > > > adds two new nonstandard VK_*_PATH variables to vulkan-loader, > > > > with at least VK_ILAYER_PATH seeming very similar in functionality > > > > to VK_LAYER_PATH and VK_ADD_LAYER_PATH described at > > > > https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderInterfaceArchitecture.md > > > > * https://issues.guix.gnu.org/58251 would be fixed by > > > > https://issues.guix.gnu.org/59453 > > > > I feel these two can be closed once 59453 lands, as then the manifests > > will have the store path to their corresponding shared objects. I also > > think having the full paths in the manifests will lead to fewer > > cross-version/cross-package mixing of objects, compared to setting and > > using environment variables of directories to search. > > > I haven't looked at the details, but I'm guessing these can all be > closed now? Yes they can be. As a quick smoke test, prior to these patches landing, "vulkaninfo > /dev/null" would consistently print out vulkan loader errors about not being able to open libVkLayer_MESA_device_select.so. (I call it a smoke test because that layer not being found isn't fatal; I first encountered the errors in a breaking way when packaging vulkan-validationlayers for use with the tutorial at https://vulkan-tutorial.com/.) Slightly off-topic speaking of mesa bugs: another one that can be closed is https://issues.guix.gnu.org/43849 as the issue with mesa's reproducibility was fixed with a patch that landed in meson 0.59.0 (which Guix picked up in commit b15c3dd9b0 from July 2021). > > > > > * https://issues.guix.gnu.org/62313 might need a modification to > > > > mesa e.g. to add VDPAU_DRIVER_PATH as a native-search-path (one > > > > possible solution; in my home profile I made VDPAU work by setting > > > > "VDPAU_DRIVER_PATH=/run/current-system/profile/lib/vdpau"). > > > > * https://issues.guix.gnu.org/48868 appears to be the same > > > > VDPAU_DRIVER_PATH issue as https://issues.guix.gnu.org/62313. > > > > For the VDPAU drivers, I plan to do a little more digging and some > > experimenting but I suspect defining VDPAU_DRIVER_PATH as a > > native-search-path is the best way forward. I'll send a patch once > > I've tested a change locally without having my profile set > > VDPAU_DRIVER_PATH to /run/current-system/profile/lib/vdpau. > > > I checked that both 48868 and 62313 were fixed in the recent updates > and closed both. > > Thanks for the patches! > John You're welcome! And thank you for checking and resolving the bug reports! Cheers, Kaelyn
Re: gcc-toolchain is missing libstdc++.so
--- Original Message --- On Friday, May 5th, 2023 at 8:59 PM, John Kehayias wrote: > > > Hi Kaelyn, > > On Thu, May 04, 2023 at 11:45 PM, Kaelyn wrote: > > > --- Original Message --- > > I wasn't sure the best place to share it, so I've attached my "run" > > script for running the binary download of PolyMC in a container. It is > > both a shell script and a guix package manifest, and is the one place > > so far I've worked around the removal of gcc:lib. The main > > program-specific bits are what CMD defaults to and which packages need > > to be included (most of the various shares are to get things like > > hardware 3D, pulseaudio, and dbus working and aren't all always > > needed). It also contains the original manifest commented-out for > > comparison. Hope it can be of help to folks! > > > Thanks, that's a nice little hack! Just something very minor I > noticed, but you don't need to specify glibc directly for the -F (FHS) > option in guix shell, as it will automatically include the (modified) > glibc. Thanks! A small side note: I have glibc in there mainly so ldd is available for debugging problems or getting new binaries working (I think the comment with it is a remnant of an older version of the manifest from before "-F" was added to "guix shell"). Cheers, Kaelyn
Re: gcc-toolchain is missing libstdc++.so
--- Original Message --- On Thursday, May 4th, 2023 at 9:50 PM, John Kehayias wrote: > > I have similar use cases of FHS containers to run binaries (primarily > > games). I recently ran into the issue of gcc:lib going away and no > > output from a visible package providing libstdc++. My current > > workaround was to implement a replacement for specifications->manifest > > that could handle packages and '(package "output") pairs in addition > > to strings, so that I could include `(,(@@ (gnu packages gcc) gcc) > > "lib") in place of "gcc:lib". Internally it resolves package strings > > to packages with specification->package, then passes the package and > > optional output specifier to package->manifest-entry. But I digress a > > little... > > > Nice little hack Kaelyn, would you mind sharing somewhere? I wonder if > this should be something we should have more easily anyway. I wasn't sure the best place to share it, so I've attached my "run" script for running the binary download of PolyMC in a container. It is both a shell script and a guix package manifest, and is the one place so far I've worked around the removal of gcc:lib. The main program-specific bits are what CMD defaults to and which packages need to be included (most of the various shares are to get things like hardware 3D, pulseaudio, and dbus working and aren't all always needed). It also contains the original manifest commented-out for comparison. Hope it can be of help to folks! Cheers, Kaelyn run Description: Binary data
Re: gcc-toolchain is missing libstdc++.so
Hi, --- Original Message --- On Thursday, May 4th, 2023 at 3:26 PM, John Kehayias wrote: > > Hi Christopher, > > On Thu, May 04, 2023 at 11:05 AM, Christopher Rodriguez wrote: > > > Sorry for the spam; Resending this without the bugs address, but with > > the issue's address. > > > > Christopher Rodriguez yewsc...@gmail.com writes: > > > > > Hello All, > > > > > > I noticed today that libstdc++.so.1 (and some others), which used to be > > > part of gcc:lib, are not included in any of the outputs of the > > > superceding `gcc-toolchain` package. > > > > > > Is there another method for getting these needed shared libraries in a > > > guix system at this point? It's entirely possible I'm missing something. > > > > > > I am CCing guix-devel@gnu.org per podiki[m]'s request. > > > > > > Thanks! > > > Thanks for opening this and cc'ing; this has come up with some > frequency on IRC, especially recently. In discussing there today, the > current reasoning is that usually one will just call g++ which knows > how to find libstdc++. So, gcc-toolchain does not include gcc:lib as > part of what it makes available. > > I think what we (and when this comes up, others) are getting at are > some edge cases or different use cases where one wants to directly get > at libstdc++. Previously it was more direct to use gcc:lib; of course > one still can in code and/or cli with the proper call. For example, > guix build -e "(@@ (gnu packages gcc) gcc)" will download/build/show > the lib output of the (hidden) gcc package. Though I'm not sure how to > select just the lib output here. > > My use case currently is in the FHS container where a binary wants to > find some libraries directly. Previously one would include the gcc:lib > package output in the guix shell call. Now some of those libraries can > be found elsewhere, like libgccjit, but libstdc++ seems to be the > trickier one. Open to other suggestions/workarounds, or thoughts on if > it is worthwhile to include gcc:lib in the gcc-toolchain package (or > make a gcc-toolchain:lib output?). I have similar use cases of FHS containers to run binaries (primarily games). I recently ran into the issue of gcc:lib going away and no output from a visible package providing libstdc++. My current workaround was to implement a replacement for specifications->manifest that could handle packages and '(package "output") pairs in addition to strings, so that I could include `(,(@@ (gnu packages gcc) gcc) "lib") in place of "gcc:lib". Internally it resolves package strings to packages with specification->package, then passes the package and optional output specifier to package->manifest-entry. But I digress a little... Regarding solutions, I would prefer to have libstdc++ in it's own package or output rather than bundled into gcc-toolchain:out; it feels messy and against the grain of isolating programs in containers if I have to make the gcc and g++ compilers available in the container in order to run a program that needs libstdc++. Cheers, Kaelyn
Re: Mesa vulkan layer path fix for core-updates
Hi, --- Original Message --- On Tuesday, April 25th, 2023 at 2:15 PM, Andreas Enge wrote: > > > Hello Kaelyn, > > thanks for your research! You're welcome! :) > Am Wed, Apr 19, 2023 at 04:07:51PM +0000 schrieb Kaelyn: > > > * https://issues.guix.gnu.org/62176 can be closed when core-updates is > > merged, since core-updates contains mesa 22.2.4 > > * Though not exactly mesa-related, https://issues.guix.gnu.org/61364 can > > possibly be closed now, and almost certainly once the core-updates merge is > > completed. (The ticket is a number of workarounds the user applied in early > > Feb to be able to build their system profile using core-updates, to pick up > > Mesa 22 for newer hardware support. I'm not sure if any of the patches are > > still relevant.) > > > I just closed these two. > > > * https://issues.guix.gnu.org/58887 looks like an alternate way of solving > > the layer path issues that https://issues.guix.gnu.org/59453 also > > addresses. Additionally, it adds two new nonstandard VK_*_PATH variables to > > vulkan-loader, with at least VK_ILAYER_PATH seeming very similar in > > functionality to VK_LAYER_PATH and VK_ADD_LAYER_PATH described at > > https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderInterfaceArchitecture.md > > * https://issues.guix.gnu.org/58251 would be fixed by > > https://issues.guix.gnu.org/59453 I feel these two can be closed once 59453 lands, as then the manifests will have the store path to their corresponding shared objects. I also think having the full paths in the manifests will lead to fewer cross-version/cross-package mixing of objects, compared to setting and using environment variables of directories to search. > > * https://issues.guix.gnu.org/62313 might need a modification to mesa e.g. > > to add VDPAU_DRIVER_PATH as a native-search-path (one possible solution; in > > my home profile I made VDPAU work by setting > > "VDPAU_DRIVER_PATH=/run/current-system/profile/lib/vdpau"). > > * https://issues.guix.gnu.org/48868 appears to be the same > > VDPAU_DRIVER_PATH issue as https://issues.guix.gnu.org/62313. For the VDPAU drivers, I plan to do a little more digging and some experimenting but I suspect defining VDPAU_DRIVER_PATH as a native-search-path is the best way forward. I'll send a patch once I've tested a change locally without having my profile set VDPAU_DRIVER_PATH to /run/current-system/profile/lib/vdpau. Cheers, Kaelyn > > > And leave these to you and anybody who wants to work on them! > > Andreas
Re: Mesa vulkan layer path fix for core-updates
--- Original Message --- On Wednesday, April 19th, 2023 at 3:26 PM, Andreas Enge wrote: > > > Hello, > > thanks for bringing this back to our attention! You're welcome! :) > > Am Wed, Apr 19, 2023 at 02:41:57PM + schrieb Kaelyn: > > > While I know it is late in the process of preparing core-updates for > > merging into master, I wanted to ask if it would be possible to have the > > patch addressed prior to the merge? > > > Given how many packages depend on mesa and their importance, I think it > would be safer to postpone the fix until after the merge; be it in a > dedicated mesa feature branch that could quickly be merged afterwards, > or better yet regroup other changes in this area. (Searching for open mesa > packages on issues.guix.gnu.org returns quite a few matches, this could be > a good occasion to sort them out.) I'm okay with it waiting until after the core-updates merge and going into a feature branch, especially if that branch includes updating mesa to the latest release (currently 23.0.0, or 22.3.7 if going with the latest patch of the previous feature release instead of the x.y.0 release of the newest series). Inspired by your comment, I also just did a quick scan of https://issues.guix.gnu.org/search?query=mesa+is%3Aopen and took a peek at some tickets that looked like they may be related to the mesa package. From that perspective, six other tickets caught my eye in the results: * https://issues.guix.gnu.org/62176 can be closed when core-updates is merged, since core-updates contains mesa 22.2.4 * https://issues.guix.gnu.org/58887 looks like an alternate way of solving the layer path issues that https://issues.guix.gnu.org/59453 also addresses. Additionally, it adds two new nonstandard VK_*_PATH variables to vulkan-loader, with at least VK_ILAYER_PATH seeming very similar in functionality to VK_LAYER_PATH and VK_ADD_LAYER_PATH described at https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderInterfaceArchitecture.md * https://issues.guix.gnu.org/58251 would be fixed by https://issues.guix.gnu.org/59453 * https://issues.guix.gnu.org/62313 might need a modification to mesa e.g. to add VDPAU_DRIVER_PATH as a native-search-path (one possible solution; in my home profile I made VDPAU work by setting "VDPAU_DRIVER_PATH=/run/current-system/profile/lib/vdpau"). * https://issues.guix.gnu.org/48868 appears to be the same VDPAU_DRIVER_PATH issue as https://issues.guix.gnu.org/62313. * Though not exactly mesa-related, https://issues.guix.gnu.org/61364 can possibly be closed now, and almost certainly once the core-updates merge is completed. (The ticket is a number of workarounds the user applied in early Feb to be able to build their system profile using core-updates, to pick up Mesa 22 for newer hardware support. I'm not sure if any of the patches are still relevant.) Cheers, Kaelyn
Mesa vulkan layer path fix for core-updates
Hi, Some time back I mailed in https://issues.guix.gnu.org/59453 to fix an issue with the manifests for the vulkan layers that ship with mesa. Basically the error is that the manifests don't include the store path to the referenced libraries, only the file name. An example the error can be seen by running "vulkaninfo &| less", where this message is printed a few times: ERROR: [Loader Message] Code 0 : libVkLayer_MESA_device_select.so: cannot open shared object file: No such file or directory While I know it is late in the process of preparing core-updates for merging into master, I wanted to ask if it would be possible to have the patch addressed prior to the merge? I just encountered the error message again after having a need to check vulkaninfo and it reminded me of the patch. (The vulkan-validationlayers package that was recently merged to master from staging includes a similar phase for fixing the layer object path in its layer manifest.) Thanks, Kaelyn
Re: wget (was Re: i686 core-updates failure.)
--- Original Message --- On Sunday, April 16th, 2023 at 5:06 PM, Andreas Enge wrote: > > > Am Sat, Apr 15, 2023 at 06:25:52PM + schrieb Kaelyn: > > > I tried to update the package definition to be able to build from git but > > it became a much bigger rabbit hole than I have the energy for at the > > moment. > > > As an explanation, this may be because the git checkout contains gnulib > as a submodule. So just "git clone" is not enough. Indeed. I'd basically gotten as far as pointing the origin to the git repo and adding a bunch of needed inputs for the bootstrap phase. At that point the bootstrap script tried to run git, and git couldn't find a valid work tree. Looking at the script, it seemed that the flag "--no-git" would have to be passed in to prevent it from trying to run git and I wasn't sure how to pass the flag to the bootstrap script with the gnu-build-system (and suspected that once I cleared that hurdle I'd have more work to do for satisfying the gnulib dependency). Cheers, Kaelyn > > Andreas
Re: wget (was Re: i686 core-updates failure.)
--- Original Message --- On Saturday, April 15th, 2023 at 4:37 PM, Kaelyn wrote: > > > Hi, > > --- Original Message --- > On Saturday, April 15th, 2023 at 10:43 AM, Andreas Enge andr...@enge.fr wrote: > > > Am Fri, Apr 14, 2023 at 08:51:18PM -0400 schrieb Maxim Cournoyer: > > > > > None, but are there wget uptsream reports about the problem? > > > > I do not see anything at > > https://gitlab.com/gnuwget/wget > > > > Andreas > > > Doing a search of the error message, I just found > https://savannah.gnu.org/bugs/?62110; the subject is about the HSTS tests > being broken 32-bit big endian devices, but comment #3 mentions the tests > failing on i686, with the same error we are seeing. It looks like > https://gitlab.com/gnuwget/wget/-/merge_requests/31 was merged to fix the > issue about a month after 1.21.3 was released (I haven't tested yet since the > package definition downloads a release tarball instead of building from git). I tried to update the package definition to be able to build from git but it became a much bigger rabbit hole than I have the energy for at the moment. I also tried to cherry-pick the commit from the merge request without luck. At least until a new release of wget occurs (and is confirmed to build on i686), I feel like the most expedient solution may be to revert commit 9cd22702b8 which updated wget from 1.21.1 to 1.21.3. I tried building 1.21.2 for i686 and hit the same test failures, but have confirmed that 1.21.1 builds just fine for i686 on core-updates Cheers, Kaelyn
Re: wget (was Re: i686 core-updates failure.)
Hi, --- Original Message --- On Saturday, April 15th, 2023 at 10:43 AM, Andreas Enge wrote: > > Am Fri, Apr 14, 2023 at 08:51:18PM -0400 schrieb Maxim Cournoyer: > > > None, but are there wget uptsream reports about the problem? > > > I do not see anything at > https://gitlab.com/gnuwget/wget > > Andreas Doing a search of the error message, I just found https://savannah.gnu.org/bugs/?62110; the subject is about the HSTS tests being broken 32-bit big endian devices, but comment #3 mentions the tests failing on i686, with the same error we are seeing. It looks like https://gitlab.com/gnuwget/wget/-/merge_requests/31 was merged to fix the issue about a month after 1.21.3 was released (I haven't tested yet since the package definition downloads a release tarball instead of building from git). Cheers, Kaelyn
Re: [PATCH core-updates] gnu: python-pytest: Fix failing test_raising_repr.
--- Original Message --- On Saturday, April 15th, 2023 at 2:08 PM, Josselin Poiret wrote: > > * gnu/packages/patches/pytest-fix-unstrable-exception-test.patch: Add new > patch from upstream. > * gnu/packages/check.scm (python-pytest): Use it. > * gnu/local.mk (dist_patch_DATA): Register it. > --- > Hey Andreas and Kaelyn, > > This should also fix it without bumping python-pytest to a new version (since > it > has so many dependents, don't want to introduce new breakage now). > > Best, > Josselin > > gnu/local.mk | 1 + > gnu/packages/check.scm | 3 +- > .../pytest-fix-unstrable-exception-test.patch | 34 +++ > 3 files changed, 37 insertions(+), 1 deletion(-) > create mode 100644 > gnu/packages/patches/pytest-fix-unstrable-exception-test.patch > > diff --git a/gnu/local.mk b/gnu/local.mk > index e29e09b688..73756a8c49 100644 > --- a/gnu/local.mk > +++ b/gnu/local.mk > @@ -1730,6 +1730,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/pytest-fix-unstrable-exception-test.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/check.scm b/gnu/packages/check.scm > index f388eb82a7..d072edbf51 100644 > --- a/gnu/packages/check.scm > +++ b/gnu/packages/check.scm > @@ -1253,7 +1253,8 @@ (define-public python-pytest > (uri (pypi-uri "pytest" version)) > (sha256 > (base32 > - "0f8c31v5r2kgjixvy267n0nhc4xsy65g3n9lz1i1377z5pn5ydjg" > + "0f8c31v5r2kgjixvy267n0nhc4xsy65g3n9lz1i1377z5pn5ydjg")) > + (patches (search-patches "pytest-fix-unstrable-exception-test.patch" > (build-system python-build-system) > (arguments > (list > diff --git a/gnu/packages/patches/pytest-fix-unstrable-exception-test.patch > b/gnu/packages/patches/pytest-fix-unstrable-exception-test.patch > new file mode 100644 > index 00..4d77786b77 > --- /dev/null > +++ b/gnu/packages/patches/pytest-fix-unstrable-exception-test.patch > @@ -0,0 +1,34 @@ > +From b55e264a675f7621b8351e227b93742f19e01c7d Mon Sep 17 00:00:00 2001 > +From: Daniel Valenzuela dsvalenzu...@uc.cl > > +Date: Wed, 9 Nov 2022 19:43:10 -0300 > +Subject: [PATCH] Fix test_raising_repr test > + > +Closes #10473 > + > +Python <3.11 versions depend on `exceptiongroup>=1.0.0rc8`, and they > released version `1.0.1` > > +6 days ago (2022/11/03) that as a side-effect changed the output of > exceptions. > +--- > + testing/test_assertion.py | 10 +- > + 1 file changed, 1 insertion(+), 9 deletions(-) > + > +diff --git a/testing/test_assertion.py b/testing/test_assertion.py > +index d8844f2e41..7574592210 100644 > +--- a/testing/test_assertion.py > b/testing/test_assertion.py > +@@ -1664,15 +1664,7 @@ def test_raising_repr(): > + """ > + ) > + result = pytester.runpytest() > +- if sys.version_info >= (3, 11): > > +- # python 3.11 has native support for un-str-able exceptions > +- result.stdout.fnmatch_lines( > +- ["E AssertionError: "] > > +- ) > +- else: > +- result.stdout.fnmatch_lines( > +- ["E AssertionError: "] > > +- ) > ++ result.stdout.fnmatch_lines(["E AssertionError: "]) > > + > + > + def test_issue_1944(pytester: Pytester) -> None: > > > base-commit: 7ccf9943029747d4ba97160214f895b365511278 > -- > 2.39.2 Hi Josselin, I just confirmed locally that the patch fixes the python-pytest test failure. Thank you for figuring out the failure! Cheers, Kaelyn
Re: i686 core-updates failure.
--- Original Message --- On Friday, April 14th, 2023 at 8:28 AM, Andreas Enge wrote: > > > Am Thu, Apr 13, 2023 at 06:25:47PM +0200 schrieb Andreas Enge: > > > For the Fortran bindings, I am hesitant as well. I think it is bad style > > to disable a test just because it fails ;-) Maybe someone with experience > > in numpy can speak up. > > > Well, given how many packages on i686 eventually depend on numpy, > I think disabling these two tests on i686 (maybe in a phase so that they > continue to run on other architectures, see the recent powerpc commit on > core-updates) is justifiable. At worst we end up with numpy with broken > fortran bindings on i686. It is likely that pulseaudio will continue > to work nevertheless. I just sent in https://issues.guix.gnu.org/62843 to disable the two tests for i686 and armhf (disabling TestKind.test_all for armhf might not be needed, but the Gentoo package definition suggests the huge array test will fail for armhf as well). Cheers, Kaelyn > > Andreas
Re: i686 core-updates failure.
Hi, --- Original Message --- On Wednesday, April 12th, 2023 at 9:31 PM, Andreas Enge wrote: > > > Hello, > > Am Wed, Apr 12, 2023 at 04:11:58PM + schrieb Kaelyn: > > > For the actual failures in python-numpy[2]: > > > you could always try whether an update solves the test failures; the package > has 2892 dependents, but anyway, the only option is fixing it and rebuilding > all the 2892 dependents also on x86_64, or renouncing at the 2892 dependents > on i686. I think the former would be preferable (and maybe even required for > merging). I forgot to mention that I had also tried updating to the latest numpy (2.24.2), with the same tests failing. I agree the test failures in numpy need to be resolved in some way for merging core-updates, since the failure affects such a large number of common (desktop) applications on i686. My inclination is to disable both failing tests (at least for now), and possibly updating to the latest numpy since changing the package would trigger a rebuild anyway. I only hesitate about disabling TestKind.test_all since I don't know what role the Fortran bridging code plays in numpy and if the failure is a sign of a legitimate problem instead of a platform limitation (as the large array test failure seems to be). Cheers, Kaelyn > > Andreas
i686 core-updates failure.
Hi, I've been working on getting wine to build on core-updates, with the most recent blocker being python-numpy failing two tests on i686 (one of which is apparently too big for 32-bit systems, based on the comment in the Gentoo ebuild of python-numpy where they skip the test). I just poked through the CI dashboard for the latest core-updates evaluation to see if it was hitting the same failure (it was), and discovered an odd chain of dependencies. Before going into the chain, I want to mention that wine has 6 failing dependencies[1], one of which is pulseaudio, two of which include pulseaudio as part of why they failed, and two include dependency failures that are on pulseaudio's dependency chain (the 6th failed dependency is due to qtbase which I didn't look into; none are direct failures). On to the odd chain: * The sole failed dependency of pulseaudio is bluez * bluez's sole failed dependency is libical * libical's sole failed dependency is gtk-doc (also a failed dependency of two other wine dependencies) * gtk-doc's sole failed dependency is dblatex * dblatex's sole failed dependency is inkscape(?!?!?) * inkscape's sole failed dependency is python-numpy, which is failing two tests. I call the dependency chain odd in that pulseaudio--which is near the heart of a lot of Linux software that supports audio--is failing because inkscape--a graphical vector editor--is a dependency of a tool designed to extract API documentation from source code. For the dependency chain, I have no real thoughts, goals, or proposed changes other than surprise that pulseaudio fails to build because a GUI SVG editor failed to build. For the actual failures in python-numpy[2]: 1. TestUfunc::test_identityless_reduction_huge_array in numpy/core/tests/test_ufunc.py: as I alluded to earlier, the Gentoo ebuild[3] disables this test with a comment that the test is "too large for 32-bit platforms". 2. TestKind::test_all in numpy/f2py/tests/test_kind.py: I'm not sure why this test is failing or what to do about it, since it seems to be seeing incorrect values for objects coming from Fortran code. Perhaps a type size mismatch for 32-bit platforms, but hard for me to say since I don't know Fortran and I haven't had luck finding other reports of that test failing. Cheers, Kaelyn [1] https://ci.guix.gnu.org/build/843194/details [2] https://ci.guix.gnu.org/build/712672/log/raw [3] https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/numpy/numpy-1.24.0.ebuild#n142
Re: Fix for librsvg 2.40 on core-updates
--- Original Message --- On Saturday, April 8th, 2023 at 3:55 PM, Kaelyn wrote: > > --- Original Message --- > On Saturday, April 8th, 2023 at 9:52 AM, Andreas Enge andr...@enge.fr wrote: > > > > > Hello, > > > > Am Fri, Apr 07, 2023 at 04:53:15PM + schrieb Kaelyn: > > > > > On core-updates, librsvg-2.40 fails to compile due to a single failing > > > test (I've confirmed the failure on x86_64 and i686, though the package > > > is only used/needed on non-x86_64 systems for gtk+ and others; it also > > > affects wine and wine-staging on x86_64 as they are 32-bit packages). I > > > was able to track down the test failure to a text rendering difference > > > between Pango 1.48 and 1.50, which led to the text being one pixel line > > > higher between the reference and output images. On Monday I submitted > > > https://issues.guix.gnu.org/62646 which adds a phase to librsvg-2.40 to > > > adjust the output Y coordinate of the SVG transformation matrix by one > > > for the failing test so that it passes with Pango 1.50. > > > > thanks a lot, I added a copyright line for you and pushed. > > > Thank you! (I often forget the copyright line, so thanks for that as well.) > > > Wine still fails to build due to autogen not building on i686: > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts > > -DPKGDATADIR=\"/gnu/store/6i60j0fxdsg4qwymas4ymfqlv1azidnc-autogen-5.18.16/share/autogen\" > > -g -O2 -Wno-format-contains-nul -fno-strict-aliasing -Wall -Werror > > -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow > > -Wstrict-prototypes -Wwrite-strings -Wstrict-aliasing=3 -Wextra > > -Wno-cast-qual -g -O2 -Wno-format-contains-nul -fno-strict-aliasing -c > > libopts.c -fPIC -DPIC -o .libs/libopts_la-libopts.o > > In file included from libopts.c:48: > > usage.c: In function ‘prt_extd_usage.isra’: > > usage.c:736:38: error: ‘s ’ directive output may be truncated writing 2 > > bytes into a region of size between 0 and 9 [-Werror=format-truncation=] > > 736 | snprintf(vfmt, sizeof(vfmt), vfmtfmt, (unsigned int)nmlen + 4); > > | ^~~ > > usage.c:736:9: note: ‘snprintf’ output between 9 and 18 bytes into a > > destination of size 12 > > 736 | snprintf(vfmt, sizeof(vfmt), vfmtfmt, (unsigned int)nmlen + 4); > > | ^~ > > > > Just in case you wish to continue investigating :) > > > I probably will. :) My goal has been to build my home and system profiles > from core-updates, including wine64-staging. I just mailed https://issues.guix.gnu.org/62758 to add a snippet to fix the build error. I used a similar approach as the existing snippet for fixing a format overflow error. (I also forgot to set the subject prefix to "PATCH core-updates" on the git send-mail command line.). Cheers, Kaelyn
Re: Fix for librsvg 2.40 on core-updates
--- Original Message --- On Saturday, April 8th, 2023 at 9:52 AM, Andreas Enge wrote: > > > Hello, > > Am Fri, Apr 07, 2023 at 04:53:15PM + schrieb Kaelyn: > > > On core-updates, librsvg-2.40 fails to compile due to a single failing test > > (I've confirmed the failure on x86_64 and i686, though the package is only > > used/needed on non-x86_64 systems for gtk+ and others; it also affects wine > > and wine-staging on x86_64 as they are 32-bit packages). I was able to > > track down the test failure to a text rendering difference between Pango > > 1.48 and 1.50, which led to the text being one pixel line higher between > > the reference and output images. On Monday I submitted > > https://issues.guix.gnu.org/62646 which adds a phase to librsvg-2.40 to > > adjust the output Y coordinate of the SVG transformation matrix by one for > > the failing test so that it passes with Pango 1.50. > > > thanks a lot, I added a copyright line for you and pushed. Thank you! (I often forget the copyright line, so thanks for that as well.) > > Wine still fails to build due to autogen not building on i686: > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts > -DPKGDATADIR=\"/gnu/store/6i60j0fxdsg4qwymas4ymfqlv1azidnc-autogen-5.18.16/share/autogen\" > -g -O2 -Wno-format-contains-nul -fno-strict-aliasing -Wall -Werror > -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow > -Wstrict-prototypes -Wwrite-strings -Wstrict-aliasing=3 -Wextra > -Wno-cast-qual -g -O2 -Wno-format-contains-nul -fno-strict-aliasing -c > libopts.c -fPIC -DPIC -o .libs/libopts_la-libopts.o > In file included from libopts.c:48: > usage.c: In function ‘prt_extd_usage.isra’: > usage.c:736:38: error: ‘s ’ directive output may be truncated writing 2 bytes > into a region of size between 0 and 9 [-Werror=format-truncation=] > 736 | snprintf(vfmt, sizeof(vfmt), vfmtfmt, (unsigned int)nmlen + 4); > | ^~~ > usage.c:736:9: note: ‘snprintf’ output between 9 and 18 bytes into a > destination of size 12 > 736 | snprintf(vfmt, sizeof(vfmt), vfmtfmt, (unsigned int)nmlen + 4); > | ^~ > > Just in case you wish to continue investigating :) I probably will. :) My goal has been to build my home and system profiles from core-updates, including wine64-staging. Cheers, Kaelyn > > Andreas
Fix for librsvg 2.40 on core-updates
Hi, On core-updates, librsvg-2.40 fails to compile due to a single failing test (I've confirmed the failure on x86_64 and i686, though the package is only used/needed on non-x86_64 systems for gtk+ and others; it also affects wine and wine-staging on x86_64 as they are 32-bit packages). I was able to track down the test failure to a text rendering difference between Pango 1.48 and 1.50, which led to the text being one pixel line higher between the reference and output images. On Monday I submitted https://issues.guix.gnu.org/62646 which adds a phase to librsvg-2.40 to adjust the output Y coordinate of the SVG transformation matrix by one for the failing test so that it passes with Pango 1.50. Cheers, Kaelyn
Re: Procps in core-updates
Hi Felix,
--- Original Message ---
On Sunday, March 19th, 2023 at 5:49 PM, Felix Lechner via "Development of GNU
Guix and the GNU System distribution." wrote:
>
>
> Hi Andreas,
>
> On Sat, Mar 18, 2023 at 5:33 AM Andreas Enge andr...@enge.fr wrote:
>
> > FAIL: strtod_nol_or_err("123") != 123.00
>
>
> Can you multiply by "1.0" to force a floating-point comparison, or
> round the other side to the nearest int?
Judging from the function name ("strtod_nol_or_err", which seems in line with
the standard "strtof"/"strtod"/"strtold" conversion functions), the function
returns a double value. Depending on the specific code, it could be
encountering inconsistencies comparing a double to a float (non-double)
constant due to the difference in types' precision.
Cheers,
Kaelyn
>
> Kind regards
> Felix
Zabbix web front-end broken on master
Hi, I wanted to bring attention to a patch I sent out a week ago: https://issues.guix.gnu.org/62137 updating Zabbix from 6.0.12 to 6.0.14. My motivation for the update of the LTS version of Zabbix is to fix the web front-end, which has been broken since PHP was upgraded from 7.4.30 to 8.2.2. The front-end is written in PHP and currently none of the graphs will display properly because of deprecation warnings[1] new to PHP 8.2 (IIRC Zabbix 6.0.12 only supported up through PHP 8.1), and PHP 8.2 support is one of the main features of the 6.0.14 release[2]. I've been running the updated version on a small Cuirass server I've set up so that I could update the system to versions of Guix newer than late January, and have confirmed the graphs display properly again with the newer Zabbix release. Cheers, Kaelyn [1] https://support.zabbix.com/browse/ZBXNEXT-8204 [2] https://www.zabbix.com/rn/rn6.0.14
Re: State of core-updates
--- 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-ne
Re: State of core-updates
Hi Felix and Andreas, --- Original Message --- On Friday, March 17th, 2023 at 8:27 PM, Felix Lechner wrote: > > > Hi Andreas and Kaelyn, > > On Fri, Mar 17, 2023 at 1:18 PM Kaelyn kaelyn.al...@protonmail.com wrote: > > > sorry about "git am" not working > > > I hesitate to get in the middle, but it may be appropriate for > attribution reasons to revert commit cc56be2f and then re-commit with > the '--author' option, unless rebasing and breaking history is > acceptable. [1] 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). 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.) Cheers, Kaelyn > > Kind regards > Felix > > [1] https://stackoverflow.com/a/28845565
Re: State of core-updates
--- Original Message --- On Friday, March 17th, 2023 at 8:01 PM, Andreas Enge wrote: > > Am Wed, Mar 15, 2023 at 05:59:12PM + schrieb Kaelyn: > > > 1) glib-networking has a 32-bit-only patch left over from the upgrade from > > 2.70.0 to 2.72.2, which does not apply against the newer version, and which > > seems unneeded. I just sent in https://issues.guix.gnu.org/62209 to fix the > > package. > > > Splendid, thanks a lot! I did not manage to extract a git commit that I > could apply with "git am" out of your message, so I ended up pushing it > under my name while adding yours as a comment in the git log. > > The package builds under x86_64 and i686, I did not test the arm > architectures. We will see what happens. > > Thanks a lot! You're welcome! I'm happy to help. :) And sorry about "git am" not working, though I'm not sure why. I sent the email with "git send-email --to=guix-patc...@gnu.org --subject-prefix="PATCH core-updates" HEAD^" as I've done with other patches (I also have format.useAutoBase set to whenAble in my .gitconfig). Cheers, Kaelyn > > Andreas
Re: Offloading problems on berlin
--- Original Message --- On Thursday, March 16th, 2023 at 8:40 PM, Andreas Enge wrote: > > > Am Thu, Mar 16, 2023 at 02:50:53PM +0100 schrieb Ludovic Courtès: > > > There’s a problem with offloading on berlin: > > https://issues.guix.gnu.org/61839 > > I occasionally offload from my laptop to machines at work but didn’t hit > > this bug, so we’ll have to see if it’s specific to berlin or not. > > > Thanks for pointing out that it is a known issue! > Is there a commandline program that can be used like gkrellm to check > whether data is flowing out of berlin to the build node? You may be able to use jnettop to see the network streams (it does need superuser privileges to run). Not sure how readable/useful it might be if berlin has a lot of active connections, though. HTH, Kaelyn > > Andreas
Re: State of core-updates
Hi,
On the topic of the state of core-updates, I wanted to mention two things
affecting i686-linux builds (and by extension some x86_64 packages like wine64):
1) glib-networking has a 32-bit-only patch left over from the upgrade from
2.70.0 to 2.72.2, which does not apply against the newer version, and which
seems unneeded. I just sent in https://issues.guix.gnu.org/62209 to fix the
package.
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:
gcc -Wall -Werror -I../src -g -O2 -DTEST_NAME=\"cases/23.t\" -o cases/23.p
main.c ../src/libaio.a -lpthread
mkdir testdir
rm -f testdir/rofile
echo "test" >testdir/rofile
chmod 400 testdir/rofile
rm -f testdir/rwfile
rm -f testdir/wofile
echo "test" >testdir/rwfile
echo "test" >testdir/wofile
chmod 600 testdir/rwfile
chmod 200 testdir/wofile
In file included from main.c:24:
cases/23.t: In function ‘thrproc2’:
cases/23.t:82:35: error: passing argument 2 of ‘splice’ from incompatible
pointer type [-Werror=incompatible-pointer-types]
82 | if (splice(tmpfd, , pipefds[1], NULL, 1, 0) != 1)
| ^~~
| |
| off_t * {aka long int *}
In file included from
/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/include/bits/fcntl.h:61,
from
/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/include/fcntl.h:35,
from main.c:9:
/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/include/bits/fcntl-linux.h:398:49:
note: expected ‘__off64_t *’ {aka ‘long long int *’} but argument is of type
‘off_t *’ {aka ‘long int *’}
398 | extern __ssize_t splice (int __fdin, __off64_t *__offin, int __fdout,
| ~~~^~~
In file included from main.c:24:
cases/23.t: In function ‘thrproc3’:
cases/23.t:106:35: error: passing argument 2 of ‘splice’ from incompatible
pointer type [-Werror=incompatible-pointer-types]
106 | if (splice(tmpfd, , pipefds[1], NULL, 1, 0) != 1)
| ^~~
| |
| off_t * {aka long int *}
In file included from
/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/include/bits/fcntl.h:61,
from
/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/include/fcntl.h:35,
from main.c:9:
/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/include/bits/fcntl-linux.h:398:49:
note: expected ‘__off64_t *’ {aka ‘long long int *’} but argument is of type
‘off_t *’ {aka ‘long int *’}
398 | extern __ssize_t splice (int __fdin, __off64_t *__offin, int __fdout,
| ~~~^~~
cc1: all warnings being treated as errors
make[1]: *** [Makefile:24: cases/23.p] Error 1
make[1]: Leaving directory
'/tmp/guix-build-libaio-0.3.113.drv-0/libaio-0.3.113/harness'
make: *** [Makefile:23: partcheck] Error 2
Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #< program: "make" arguments: ("partcheck" "-j" "12"
"prefix=/gnu/store/xr6s773c3d62g9aynydp1h6231p42ixn-libaio-0.3.113" "CC=gcc")
exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 0.3 seconds
Cheers,
Kaelyn
P.S. For context, I hit the libaio error trying to build icecat (x86_64) on
core-updates the other day; I hit the glib-networking error this morning trying
to build wine, and then hit the libaio error again when retrying the wine
(i686) build with my glib-networking change applied. The same build error
affects both x86_64 and i686 builds of libaio.
Re: Python (was: Merging core-updates?)
--- Original Message --- On Sunday, February 19th, 2023 at 10:08 PM, Andreas Enge wrote: > > There is poezio, which has a new release (0.14), with a license change to > gpl3+. I updated python-slixmpp, a dependency of poezio, but this is not > enough: The newest poezio still depends on python-potr, which in turn depends > on python-pycrypto. It was mentioned recently that python-pycryptodome is / should be a drop-in replacement for python-pycrypto (it is also says that in the package description); perhaps replace the python-pycrypto input with python-pycryptodome for python-potr, with a snippet to change the pycrypto dependency to pycryptodome in python-potr's setup.py? After taking a peek at the poezio and python-potr git repos, the main alternative I can see to patching the dependency is to remove python-potr from poezio's inputs since python-potr is listed as an optional dependency in poezio's setup.py (for its OTR plugin). Cheers, Kaelyn > > Andreas
Re: Openjdk (was: Merging core-updates?)
Hi, --- Original Message --- On Friday, February 17th, 2023 at 4:28 PM, Andreas Enge wrote: > Am Fri, Feb 17, 2023 at 03:49:19PM +0100 schrieb Andreas Enge: > > > Hm, I compiled up to openjdk@13, @14 fails with the message below. > > This is strange. It looks as if the patch that has become obsolete, > > because integrated into the source @13, is needed again @14! > > And then @15, the patch is again already integrated into the source code. > > Very weird! > > > Things become totally crazy. > So far I have compiled @13 without the patch, @14 with the patch, > @15 without the patch, and @16 seems to need it again. Is this an > odd/even thing? Are there spring and autumn versions of openjdk with > different release teams? Hi, I don't know much about openjdk or its development process, but I had one possible thought about the pattern of patch application. Was it a patch that was applied or backported to existing openjdk releases, and are @14 and @16 the latest releases of those series? At least to me as a naive outside observer, the patch being needed for some of the older release branches but not others sounds like a patch applied to multiple existing release branches, with openjdk@14 and @16 being at older point releases from prior to the patch being applied upstream. HTH! (And I apologize for the noise if not!) Cheers, Kaelyn > Well, in @17, @18 and @19 the patch seems to be definitely integrated > into the source code. > > Andreas
Re: Merging core-updates?
--- Original Message --- On Tuesday, February 14th, 2023 at 8:29 PM, Kaelyn wrote: > > --- Original Message --- > On Tuesday, February 14th, 2023 at 2:50 PM, Efraim Flashner > efr...@flashner.co.il wrote: > > [snip] > > > I ended up going a different route and moving xz from the finalize > > packages to an actual xz-final and replacing xz-bootstrap/xz-mesboot in > > %boot6-inputs. > > > > I also tracked down the issue in tar and adjusted the testsuite so it > > shouldn't be a problem on 32-bit systems. > > > I just tried building wine-minimal from core-updates at commit da7d615629, > and I think you may have be missing a "!" with the new flag for the tar test > suite (i.e. it needs to be "-k '!tricky time stamps'"). Based on the build > log, right now only the failing test is being run: > > ## - ## > ## Test results. ## > ## - ## > > ERROR: 1 test was run, > 1 failed unexpectedly. > > ## ## > ## Summary of the failures. ## > ## ## > Failed tests: > GNU tar 1.34 test suite test groups: > > NUM: FILE-NAME:LINE TEST-GROUP-NAME > KEYWORDS > > 151: time01.at:20 time: tricky time stamps > time time01 I wanted to give a quick update: once I fixed the test exclusion for tar, I was successful in building wine-minimal on core-updates (which is 32-bit package on x86_64 as well). > Cheers, > Kaelyn > > > -- > > Efraim Flashner efr...@flashner.co.il אפרים פלשנר > > > > GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 > > Confidentiality cannot be guaranteed on emails sent or received unencrypted
Re: Merging core-updates?
--- Original Message --- On Tuesday, February 14th, 2023 at 2:50 PM, Efraim Flashner wrote: > [snip] > > I ended up going a different route and moving xz from the finalize > packages to an actual xz-final and replacing xz-bootstrap/xz-mesboot in > %boot6-inputs. > > I also tracked down the issue in tar and adjusted the testsuite so it > shouldn't be a problem on 32-bit systems. I just tried building wine-minimal from core-updates at commit da7d615629, and I think you may have be missing a "!" with the new flag for the tar test suite (i.e. it needs to be "-k '!tricky time stamps'"). Based on the build log, right now only the failing test is being run: ## - ## ## Test results. ## ## - ## ERROR: 1 test was run, 1 failed unexpectedly. ## ## ## Summary of the failures. ## ## ## Failed tests: GNU tar 1.34 test suite test groups: NUM: FILE-NAME:LINE TEST-GROUP-NAME KEYWORDS 151: time01.at:20 time: tricky time stamps time time01 Cheers, Kaelyn > > -- > Efraim Flashner efr...@flashner.co.il אפרים פלשנר > > GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 > Confidentiality cannot be guaranteed on emails sent or received unencrypted
Re: Merging core-updates?
--- Original Message --- On Monday, February 13th, 2023 at 8:04 PM, Efraim Flashner wrote: > > > On Sun, Feb 12, 2023 at 06:29:04PM +0000, Kaelyn wrote: > > > Hi, > > > > --- Original Message --- > > On Sunday, February 12th, 2023 at 5:08 PM, Andreas Enge andr...@enge.fr > > wrote: > > > > > Am Sun, Feb 12, 2023 at 12:58:06PM +0100 schrieb Julien Lepiller: > > > > > > > And I was able to rebuild (with --check) patch-mesboot. The error looks > > > > a lot like https://issues.guix.gnu.org/49985. We should fix that indeed > > > > :) > > > > > > Ah indeed, that looks like deal breaking; maybe someone from MES can have > > > a look? > > > > > > What is the magic incantation with double "@@" to build this package? > > > Ah, here we go, for reference to self: > > > guix build -e '(@@ (gnu packages commencement) patch-mesboot)' > > > > > > Andreas > > > > While not directly related to the patch-mesboot error, I want to mention > > that there is also https://issues.guix.gnu.org/58719 blocking i686 builds > > on core-updates (and x86_64 builds of certain packages like wine64, which > > has i686 dependencies) since the update to glibc 2.35. > > > > It may also need assistance from the MES folks to fix, since the error > > message is about an undefined symbol in glibc-mesboot's libpthread.so.0: > > > > make[2]: Entering directory > > '/tmp/guix-build-file-5.44.drv-0/file-5.44/magic' > > ../src/file -C -m magic > > /tmp/guix-build-file-5.44.drv-0/file-5.44/src/.libs/file: symbol lookup > > error: > > /gnu/store/s4yd6ibxsh5q1j9ipygb9vpjj4g00wc9-glibc-mesboot-2.16.0/lib/libpthread.so.0: > > undefined symbol: h_errno, version GLIBC_PRIVATE > > make[2]: *** [Makefile:863: magic.mgc] Error 127 > > > > Cheers, > > Kaelyn > > > I think I found where this is coming from. %boot3-inputs added > ld-wrapper-boot3 but didn't remove ld-wrapper-0, which pulled in > glibc-mesboot. I'm testing out removing ld-wrapper-0 from %boot3-inputs > to see if that's enough to make that final file build. Hopefully it'll > also fix the final tar for i686, which I found was also failing for me. Interesting! Since my last email, I was able to fix the issue with file by adding "--disable-xzlib" to the file package in gnu/packages/commencement.scm (after discovering it when noticing "--disable-bzlib" was being passed to the configure script), but hadn't sent in a patch yet because I hit a subsequent test failure while building tar. I thought to disable xz support because I traced the source of the glibc-mesboot libpthread.so in the error message to xz-mesboot being detected by the configure script and linked in even though file itself was being linked against a newer glibc and had no explicit dependencies. (I think the error after upgrading to glibc 2.35 from 2.33 was an abi compatibility between the newer glibc and the old pthread being pulled in via xz-mesboot.) Cheers, Kaelyn > > -- > Efraim Flashner efr...@flashner.co.il אפרים פלשנר > > GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 > Confidentiality cannot be guaranteed on emails sent or received unencrypted
Re: Merging core-updates?
Hi, --- Original Message --- On Sunday, February 12th, 2023 at 5:08 PM, Andreas Enge wrote: > > > Am Sun, Feb 12, 2023 at 12:58:06PM +0100 schrieb Julien Lepiller: > > > And I was able to rebuild (with --check) patch-mesboot. The error looks > > a lot like https://issues.guix.gnu.org/49985. We should fix that indeed > > :) > > > Ah indeed, that looks like deal breaking; maybe someone from MES can have > a look? > > What is the magic incantation with double "@@" to build this package? > Ah, here we go, for reference to self: > guix build -e '(@@ (gnu packages commencement) patch-mesboot)' > > Andreas While not directly related to the patch-mesboot error, I want to mention that there is also https://issues.guix.gnu.org/58719 blocking i686 builds on core-updates (and x86_64 builds of certain packages like wine64, which has i686 dependencies) since the update to glibc 2.35. It may also need assistance from the MES folks to fix, since the error message is about an undefined symbol in glibc-mesboot's libpthread.so.0: make[2]: Entering directory '/tmp/guix-build-file-5.44.drv-0/file-5.44/magic' ../src/file -C -m magic /tmp/guix-build-file-5.44.drv-0/file-5.44/src/.libs/file: symbol lookup error: /gnu/store/s4yd6ibxsh5q1j9ipygb9vpjj4g00wc9-glibc-mesboot-2.16.0/lib/libpthread.so.0: undefined symbol: h_errno, version GLIBC_PRIVATE make[2]: *** [Makefile:863: magic.mgc] Error 127 Cheers, Kaelyn P.S. I also have https://issues.guix.gnu.org/59453 open for few months to fix the Vulkan layer paths in mesa on core-updates, which I'd really like to see land before a core-updates merge happens (it had originally been part of a mesa version update patch I sent in back in October, but which had been obsoleted by a newer patch release of mesa landing in core-updates; mesa in core-updates is also a few releases behind at this point, but that's a separate matter).
Re: UTF-8 progress bar
--- Original Message --- On Saturday, January 28th, 2023 at 1:17 PM, Julien Lepiller wrote: > > > Hi Guix! > > I have a patch waiting (https://issues.guix.gnu.org/59975) that will > change progress bars to use some unicode characters. I think they look > better, but I'm a bit afraid they might not look right on some config, > so I'd like to know if your terminal is able to show these characters: > > "▏▎▍▌▋▊▉█▏▕" > > If you are not using a unicode locale, this change will not affect you > as guix will fallback to the ascii style. If your terminal can't show > these characters and you have a UTF-8 locale (you'd run echo $LANG to > know that), please report your config (name of terminal app, locale, > fonts, …)! I can see those characters in both xfce4-terminal and kitty. Cheers, Kaelyn
[bug#59453] [PATCH core-updates] gnu: mesa: Fix library paths in Vulkan layer manifests.
Hi Guix devs, Now that it's been a couple of months, I wanted to bump my core-updates patch to Mesa which fixes the library paths in Mesa's Vulkan layer manifest files (https://issues.guix.gnu.org/59453). The patch also resolves https://issues.guix.gnu.org/58251. Cheers, Kaelyn
Re: Proposed changes to the commit policy (#59513)
--- Original Message --- On Wednesday, January 18th, 2023 at 11:45 AM, Christopher Baines wrote: > > Andreas Enge andr...@enge.fr writes: > > > Hello, > > > > Am Mon, Jan 16, 2023 at 09:47:06PM + schrieb Christopher Baines: > > > > > I merged the changes a few days ago, so this is just a quick message to > > > say that the commit policy has changed. You can read the updated policy > > > here: > > > https://guix.gnu.org/en/manual/devel/en/html_node/Commit-Access.html#Commit-Policy > > > > as a quick concrete question: Do simple package updates still count as > > trivial, or do they need to go through the patches mailing list? > > I intended to update pari-gp from 2.15.1 to 2.15.2, as usual by checking > > that all dependent packages still compile. Having to fiddle with debbugs > > is somewhat deterring (although admittedly having qa compile all dependent > > packages is also a service in a context where I do not expect problems). > > > My feeling on this is that "simple" package updates are often not > trivial, or at least doing rigorous testing for these updates isn't > trivial. A definition of trivial might be "having little value or > importance", and I don't think that's generally the case for version > updates, they're often a valuable and important change. > > That's not to say that the policy doesn't allow for pushing the pari-gp > update directly to the master branch. I think the wiggle room in the > policy is given by the "should" instruction regarding posting to > guix-patc...@gnu.org and the "This is subject to being adjusted, > allowing individuals to commit directly on non-controversial changes on > parts they’re familiar with." bit. > > As you say, my hope is that having parts of the quality assurance > testing automated, e.g. compiling the updated version of para-gp and > affected packages on supported architectures will be something people > want to use, rather than feeling forced to. > > > In case the answer is that submitting to the patch tracker is required, > > I would suggest to shorten the waiting period from one week to zero > > (meaning that it is okay to push when there are no problems detected by qa, > > without having to wait for human review that has no reason to occur). > > > That seems reasonable to me, at least in the case of package > updates. Given that's such a common change, maybe that needs handling > specifically in the commit policy. > > > I would also like to update mpfr and mpc in core-updates. The documentation > > mentions the different branches under Step 9: > > https://guix.gnu.org/en/manual/devel/en/html_node/Submitting-Patches.html > > but how is this specified in the email to the patch tracker, > > so that qa applies the patch to the correct branch? > > > That's not something that's attempted yet, all patches are just applied > to master. Maybe setting out the subject like this [1] could indicate > the intended branch? I'm not sure what flags to pass to git > format-patch/send-email to achieve that though. On a side note, I'd recently discovered the flag to pass. To have a subject prefix like "[PATCH core-updates]" (as mentioned in the manual for staging and core-updates patches) instead of the default "[PATCH]", one can pass "--subject-prefix="PATCH core-updates" to git format-patch. Cheers, Kaelyn > > 1: https://issues.guix.gnu.org/55227
Re: Packaging: Need some help replacing a check phase
Hi Luis,
--- Original Message ---
On Monday, December 26th, 2022 at 4:15 PM, Luis Felipe
wrote:
>
>
> Hi,
>
> I'm packaging a Guile software but the package fails to build when I try to
> replace the check phase, and I can't see what I'm doing wrong.
>
> This is the package definition:
>
> ٭٭
> (define-module (packages guile-proba)
> #:use-module (gnu packages guile)
> #:use-module (gnu packages guile-xyz)
> #:use-module (gnu packages texinfo)
> #:use-module (guix build-system guile)
> #:use-module (guix git-download)
> #:use-module ((guix licenses) #:prefix license:)
> #:use-module (guix packages))
>
>
> (define-public guile-proba
> (package
> (name "guile-proba")
> (version "0.1.0")
> (source
> (origin
> (method git-fetch)
> (uri (git-reference
> (url "https://codeberg.org/luis-felipe/guile-proba;)
> (commit version)))
> (file-name (git-file-name name version))
> (sha256
> (base32 "0bai3nhdmzpcxkp55a74afp92sq609hh9dy5a5w01aysvchp4715"
> (build-system guile-build-system)
> (native-inputs (list guile-3.0 texinfo))
> (propagated-inputs (list guile-config guile-lib texinfo))
> (arguments
> `(#:phases
> (modify-phases %standard-phases
> ;; FIXME: Replacing 'check phase makes build fail.
> (replace 'check
> (lambda* (#:key tests? #:allow-other-keys)
> (when tests?
> (invoke "guile" "proba.scm" "run" "tests"
> (add-after 'install 'install-script-and-manual
> (lambda* (#:key outputs #:allow-other-keys)
> (let* ((out (assoc-ref outputs "out"))
> (bin-dir (string-append out "/bin"))
> (info-dir (string-append out "/share/info"))
> (script (string-append bin-dir "/proba")))
> (mkdir-p bin-dir)
> (mkdir-p info-dir)
> (copy-file "proba.scm" script)
> (chmod script #o555)
> (invoke "makeinfo" "manual/main.texi")
> (install-file "guile-proba" info-dir)
> #:not-compiled-file-regexp
> "((packages|tests)\\/.*.scm|(proba|manifest).scm)$"))
> (home-page "https://luis-felipe.gitlab.io/guile-proba/;)
> (synopsis "Testing tools for GNU Guile projects with SRFI 64 test suites")
> (description
> "This software is a set of testing tools for GNU Guile projects
> with SRFI 64-based test suites. It comes with a command-line interface
> to run test collections, and a library that includes a test runner and
> helpers for writing tests.")
> (license license:public-domain)))
> ٭٭
>
>
> And this is the error after running "guix build -L . guile-proba" (using guix
> 9cb42f7):
>
> ٭٭
> Backtrace:
> 14 (primitive-load "/gnu/store/36iw346l6n6s9wrd4qr923zywj1?")
> In ice-9/eval.scm:
> 214:21 13 (_ #f)
> 217:50 12 (lp (# ?))
>
> 217:50 11 (lp (# ?))
>
> 217:50 10 (lp (# ?))
>
> 217:50 9 (lp (# ?))
>
> 217:50 8 (lp (# ?))
>
> 217:50 7 (lp (# ?))
>
> 217:50 6 (lp (# ?))
>
> 217:50 5 (lp (# ?))
>
> 217:50 4 (lp (# ?))
>
> 217:50 3 (lp (# ?))
>
> 217:33 2 (lp (# ?))
>
> 293:34 1 (_ #(# ((# . #) ?)))
>
> In guix/build/utils.scm:
> 713:4 0 (alist-replace check # ?)
>
>
> guix/build/utils.scm:713:4: In procedure alist-replace:
> Throw to key `match-error' with args` ("match" "no matching pattern" ())'.
> ٭٭
I believe the build fails because the guile-build-system deletes the 'check
phase. From guix/build/guile-build-system.scm:
(define %standard-phases
(modify-phases gnu:%standard-phases
(delete 'bootstrap)
(delete 'configure)
(add-before 'install-locale 'set-locale-path
set-locale-path)
(replace 'build build)
(add-after 'build 'install-documentation
install-documentation)
(delete 'check)
(delete 'strip)
(delete 'validate-runpath)
(delete 'install)))
Hope that helps!
Cheers,
Kaelyn
>
>
> Thanks in advance.
>
>
> ---
> Luis Felipe López Acevedo
> https://luis-felipe.gitlab.io/
Re: GNU Guix 1.4.0rc1 available for testing!
--- Original Message --- On Saturday, December 3rd, 2022 at 9:50 AM, zimoun wrote: > > > Hi, > > On Fri, 02 Dec 2022 at 17:17, Ahmed Khanzada m...@enzu.ru wrote: > > > How can I switch my current GNU Guix installation over to 1.4? > > Afterwards, how could I switch it back? Is that all safe to do so? > > > I guess some usual, > > guix pull --branch=version-1.4.0 > guix system reconfigure > > then > > guix pull --roll-back > guix system reconfigure As a side note, if you use GRUB as your bootloader, you can select an alternate menu entry to temporarily switch to an older generation. You can also roll back to the previous system generations with: guix system roll-back > > Well, I think it should be possible using “guix time-machine”, something > like, > > guix time-machine --branch=version-1.4.0 -- system reconfigure > > but then I do not know how it goes for switching back. I've not tried guix time-machine to reconfigure a system, but once it is done, the same "guix system roll-back" should work for switching back to your previous system generation (pre-1.4.0-branch). HTH! Cheers, Kaelyn > > Cheers, > simon
Re: [IDEA] lint the whole dang thang
--- Original Message --- On Wednesday, September 7th, 2022 at 10:18 PM, jgart wrote: > Hi Guixers, > > wdyt if we have the following option for `guix lint`? > > `-f, --whole-file lint all the packages in the given file(s)` +1 to this. It would provide symmetry with the `--whole-file` option added to `guix style` a month ago in commit a15542d26df42dabdb5e2f76d150ae200230c3b0, and there have been times in the past where having the option for both would have been handy instead of having to call the tool for each package name in a file. (I also see potential for the file-wide option in the future for transformations that wouldn't work on a per-package basis, e.g. cleaning up unused module imports). Cheers, Kaelyn
Re: Shall updaters fall back to other updaters?
--- Original Message --- On Sunday, July 3rd, 2022 at 1:12 AM, Hartmut Goebel wrote: > Am 01.07.22 um 15:15 schrieb Ludovic Courtès: > > > > BTW 2: Which updater is used for each package is non-deterministic. > > > Do you have an example? I’d think they’re always tried in the same > > > order, no? > > > When looking at the code, I don't see any means of sorting: > https://git.savannah.gnu.org/cgit/guix.git/tree/guix/upstream.scm#n245 > > and below. (Maybe sorting is hidden in one of the function > guile-internal used there there.) I just looked at 'importer-modules and did some tracing of where the list of modules come from (back through 'all-modules, etc). It appears that by default the list of importer modules comes from 'scheme-file, which is defined at: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/discovery.scm#n43 That function builds a list of scheme files found recursively under a given directory with the help of 'scandir*. There is no sorting there or along the call chain back to 'importer-modules, so I'm fairly sure the directory entries are returned in a filesystem-dependent order. If the filesystem returns entries in sorted order or if the contents of that directory tree are relatively static (in that the order of directory entries hasn't changed), then the results will appear to be in a consistent/deterministic order. To me, this feels like the importers will need a more deterministic order imposed on them to get import results that are consistent across systems. HTH! Cheers, Kaelyn
Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues
On Tuesday, June 7th, 2022 at 10:42 AM, Kaelyn wrote: [snip] > > > I just took a few minutes and checked both repos out into a single > > > working tree, and there aren't many commits unique to each > > > repository. The official savannah repo has 5 commits since they > > > diverged, with the 3 oldest looking like variations of the 6 oldest in > > > the gitlab repo. Likewise, not counting the 6 just mentioned, there > > > are 4 unique commits in the gitlab repo. Those 4 commits are: > > > > > > * c9aef52 - (gitlab/master, gitlab/HEAD) elisp/ui-package: Add > > > 'guix-package-use-name-at-point' variable (12 months ago) > > > * e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 > > > months ago) > > > * 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, > > > 3 months ago) > > > * fbc2bbc - elisp/ui-package: Use thing at point for > > > 'guix-packages-by-name' command (1 year, 3 months ago) > > > > Awesome. > > > > Would you be willing to coordinate work on Emacs-Guix for some time? > > If so, I’m in favor of granting you commit access so you can first push > > these four commits, and eventually apply patches that are submitted or > > fix bugs here and there. > > > > If Giovanni or Théo wants to do that, that’s fine too. What we need is > > to make sure one of us/you can commit some time going forward to at > > least protect Emacs-Guix from bitrot, and ideally help improve it, as > > time permits. > > > > WDYT? > > > While my time can sometimes be a little spotty short-term, I am willing to > coordinate work on Emacs-Guix and at least protect it from bitrot. Right now, > I'm still fairly new to Emacs and am still working on my setup and learning & > integrating things like using Emacs-Guix or M-x debbugs-gnu, but I also wish > to both get more involved with Guix and improve my Emacs development and > debugging skills. I'll also be happy to push those four commits once I work > out my local build and testing (i.e. getting the tests to pass locally with a > clean tree to see if my cherry-picking of the commits are the reason tests > are failing.) I want to give a quick update: I have successfully built and run "make check" for my local branch with the four cherry-picked commits, plus one addition commit to fix the build (an emacs script used for local builds was passing an argument to guix-emacs-autoload-packages, which was refactored to not take arguments in guix commit 47b3b4c2aa from 2019). With my extra commit, I think the branch should be ready to push. Cheers, Kaelyn
Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues
Hi Ludo' Sorry for taking a while to send a reply! On Monday, May 30th, 2022 at 8:33 AM, Ludovic Courtès wrote: > Hello Kaelyn, > > Kaelyn kaelyn.al...@protonmail.com skribis: > > > > First, we need to cherry-pick relevant commits from gitlab.com. Any > > > takers? If you Giovanni or anyone else is willing to help, we can grant > > > commit access so we share the work. Another way to help is by listing > > > commits that should be applied. > > > > > > Volunteers? > > > > I'd be happy to help with the efforts! > > > Yay! > > > I just took a few minutes and checked both repos out into a single > > working tree, and there aren't many commits unique to each > > repository. The official savannah repo has 5 commits since they > > diverged, with the 3 oldest looking like variations of the 6 oldest in > > the gitlab repo. Likewise, not counting the 6 just mentioned, there > > are 4 unique commits in the gitlab repo. Those 4 commits are: > > > > * c9aef52 - (gitlab/master, gitlab/HEAD) elisp/ui-package: Add > > 'guix-package-use-name-at-point' variable (12 months ago) > > * e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months > > ago) > > * 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 > > months ago) > > * fbc2bbc - elisp/ui-package: Use thing at point for > > 'guix-packages-by-name' command (1 year, 3 months ago) > > > Awesome. > > Would you be willing to coordinate work on Emacs-Guix for some time? > If so, I’m in favor of granting you commit access so you can first push > these four commits, and eventually apply patches that are submitted or > fix bugs here and there. > > If Giovanni or Théo wants to do that, that’s fine too. What we need is > to make sure one of us/you can commit some time going forward to at > least protect Emacs-Guix from bitrot, and ideally help improve it, as > time permits. > > WDYT? While my time can sometimes be a little spotty short-term, I am willing to coordinate work on Emacs-Guix and at least protect it from bitrot. Right now, I'm still fairly new to Emacs and am still working on my setup and learning & integrating things like using Emacs-Guix or M-x debbugs-gnu, but I also wish to both get more involved with Guix and improve my Emacs development and debugging skills. I'll also be happy to push those four commits once I work out my local build and testing (i.e. getting the tests to pass locally with a clean tree to see if my cherry-picking of the commits are the reason tests are failing.) > Bug reports would still go to https://issues.guix.gnu.org, which you > > can access from the comfort of your Emacs with M-x debbugs-gnu. :-) I really need to try that out! :) Cheers, Kaelyn > Thanks, > Ludo’.
Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues
Hello Gio'
On Thursday, May 26th, 2022 at 8:01 AM, Giovanni Biscuolo
wrote:
> Hello Kaelyn and Ludo'
>
> thank you for your help!
>
> Kaelyn kaelyn.al...@protonmail.com writes:
>
>
> [...]
>
> > > First, we need to cherry-pick relevant commits from gitlab.com. Any
> > > takers? If you Giovanni or anyone else is willing to help,
>
>
> I'd be really happy to help, I just saw Kaelyn was already working on
> this
>
> unfortunately I'm not the right person to maintain emacs-guix since my
> *-lisp foo is still Panda-style
>
> > > we can grant commit access so we share the work. Another way to help
> > > is by listing commits that should be applied.
> > >
> > > Volunteers?
> >
> > I'd be happy to help with the efforts! I just took a few minutes and
> > checked both repos out into a single working tree, and there aren't
> > many commits unique to each repository. The official savannah repo has
> > 5 commits since they diverged, with the 3 oldest looking like
> > variations of the 6 oldest in the gitlab repo. Likewise, not counting
> > the 6 just mentioned, there are 4 unique commits in the gitlab repo.
>
>
> how is your cherry-picking going?
>
> is there anything I can do to help?
I've attempted to cherry-pick the four gitlab commits (by interactively
rebasing the gitlab HEAD on the savannah HEAD and dropping the overlapping
commits) but haven't made progress beyond that. The rebase/cherry-pick was
pretty simple as there didn't seem to be conflicts. However, I keep getting
elisp errors about something having the wrong number of arguments, and I'm
still new enough to emacs that I don't know how to debug it or to get a useful
backtrace of where the error is coming from.
Basically it seems like the same error compiling any of the elisp files (at
least with emacs 27), but the errors are ignored by default and so installation
fails because all of the .elc files to be installed are missing. A sample of
the repeated error:
ELC elisp/guix-hash.elc
Wrong number of arguments: #[nil "ÁÂÃ \"Ä\")" [autoloads mapcan
guix-emacs-find-autoloads guix-emacs--non-core-load-path mapc #[(f) "Â\"" [f
load noerror] 3]] 3
("/gnu/store/wl48zzhf6gvvi7vml7w0yzg14ks4b0ls-profile/share/emacs/site-lisp/guix-emacs.elc"
. 1084) nil], 1
make[1]: [Makefile:1285: elisp/guix-hash.elc] Error 255 (ignored)
ELC elisp/guix-derivation.elc
Wrong number of arguments: #[nil "ÁÂÃ \"Ä\")" [autoloads mapcan
guix-emacs-find-autoloads guix-emacs--non-core-load-path mapc #[(f) "Â\"" [f
load noerror] 3]] 3
("/gnu/store/wl48zzhf6gvvi7vml7w0yzg14ks4b0ls-profile/share/emacs/site-lisp/guix-emacs.elc"
. 1084) nil], 1
make[1]: [Makefile:1285: elisp/guix-derivation.elc] Error 255 (ignored)
I wanted to at least make sure the package built with the included guix.scm
before figuring out how to send a pull request (or patch series) to a
savannah-hosted project, but that error has me stumped.
Cheers,
Kaelyn
>
> Thanks, Gio'
>
> [...]
>
> --
> Giovanni Biscuolo
>
> Xelera IT Infrastructures
Re: Move /gnu/store to another filesystem
Hi Théo, n Thursday, May 26th, 2022 at 3:44 AM, Théo Maxime Tyburn wrote: > Hi Gio, > > Giovanni Biscuolo g...@xelera.eu writes: > > > [...] > > > maybe you misconfigured "mount-point" and "type"? > > > > what about: > > > > --8<---cut here---start->8--- > > > > (define %store-fs ;; <--- This is what I want to add. > > (file-system (device (file-system-label "storage-fs")) > > (mount-point "/gnu/store") > > (type "btrfs") > > > > --8<---cut here---end--->8--- > > > > WDYT? > > > Oh yes sorry, I did a mistake while copy-pasting. What you suggested > is actually what I am using. If you have the new /gnu/store as a btrfs subvolume, you may need to tell `mount` which subvolume to mount there. I haven't tried moving /gnu/store, but my systems have / and /gnu/store as separate btrfs subvolumes in the same LUKS-encrypted partition. Here is the `file-systems` stanza of one of my system's operating-system declaration, in case it is helpful: (file-systems (let ((rootfs (file-system (mount-point "/") (device "/dev/mapper/cryptroot1") (type "btrfs") (check? #f) (options "compress=zstd,subvol=@guix") (dependencies mapped-devices (cons* rootfs (file-system (mount-point "/boot/efi") (device (file-system-label "EFI")) (type "vfat") (mount-may-fail? #t) (dependencies mapped-devices)) (file-system (mount-point "/gnu") (device "/dev/mapper/cryptroot1") (type "btrfs") (check? #f) (options "compress=zstd,subvol=@gnu_store") (dependencies (cons rootfs mapped-devices))) %base-file-systems))) Cheers, Kaelyn > > > > Anyway this is probably not the right way to do it. Simply coping > > > /gnu/store around looks a bit brutal. > > > > AFAIK we can move /gnu/store anywhere if the system is not live, > > like you did booting in "rescue mode" > > > Well then I don’t see what could have gone wrong. I’ll try it agin. > > > Happy hacking! Gio' > > > Tks!
Re: Why does sh in the build environment ignore SIGINT and SIGQUIT?
Hi, --- Original Message --- On Monday, May 23rd, 2022 at 11:25 PM, Foo Chuan Wei wrote: > On 2022-05-23 03:14 +, Foo Chuan Wei wrote: > > > `(invoke "sh" "-c" "trap")` is merely a trivial example for > > demonstrating that the shell ignores SIGINT and SIGQUIT. This might be > > significant if the build step invokes the shell to do something more > > significant (e.g. to build something). > > > > Anyway, I found that this behavior is possibly related to one specified > > by POSIX [1]: > > > > > 2.11. Signals and Error Handling > > > > > > If job control is disabled (see the description of set -m) when the > > > shell executes an asynchronous list, the commands in the list shall > > > inherit from the shell a signal action of ignored (SIG_IGN) for the > > > SIGINT and SIGQUIT signals. > > > Maybe not. Guix's `invoke` procedure uses Guile's `system*` procedure, > which ignores SIGINT and SIGQUIT as can be seen in Guile's source code: > https://git.savannah.gnu.org/cgit/guile.git/tree/libguile/posix.c?h=v3.0.8#n1524 > > > Do you have a solution to this problem? > > > Guile's `system` procedure does not have this problem (compare > `(system "bash -c trap")` with `(system* "bash" "-c" "trap")`). > One possible solution is to replace `invoke` with `system`: While `system` may not show the problem that `system*`, note that they aren't strictly interchangeable. To quote https://www.gnu.org/software/guile/manual/html_node/Processes.html#index-system_002a: "system* is similar to system, but accepts only one string per-argument, and performs no shell interpretation. The command is executed using fork and execlp. Accordingly this function may be safer than system in situations where shell interpretation is not required." Cheers, Kaelyn > > diff --git a/gnu/packages/sml.scm b/gnu/packages/sml.scm > index 04411c02c3..fafdba9a3f 100644 > --- a/gnu/packages/sml.scm > +++ b/gnu/packages/sml.scm > @@ -175,10 +175,14 @@ function interface, and a symbolic debugger.") > "sml.boot.amd64-unix/SMLNJ-BASIS/.cm/amd64-unix/basis-common.cm")) > > ;; Build. > - (invoke "./config/install.sh" "-default" > - (if (string=? "i686-linux" ,(%current-system)) > - "32" > - "64")) > + (let ((exit-code > + (system (string-append "./config/install.sh -default " > + (if (string=? "i686-linux" > + ,(%current-system)) > + "32" > + "64") > + (unless (zero? exit-code) > + (error (format #f "Exit code: ~a" exit-code > > ;; Undo the binary patch. > (for-each
Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues
Hi, --- Original Message --- On Monday, May 23rd, 2022 at 7:39 AM, Ludovic Courtès wrote: > Hi, > > Ludovic Courtès l...@gnu.org skribis: > > > Anyway, the situation is confusing; there’s no point in having two > > slightly different variants. I suggest we check with Alex off-list to > > get a better understanding of what they want. Worst case, we can > > cherry-pick commits from Alex’s copy if Alex doesn’t want to be involved > > in discussions around Emacs-Guix or Guix development. > > > Emailed Alex off-list and didn’t get a reply. > > So we’re on our own like grownups, but that’s fine, I’m sure we’ll > manage. :-) > > First, we need to cherry-pick relevant commits from gitlab.com. Any > takers? If you Giovanni or anyone else is willing to help, we can grant > commit access so we share the work. Another way to help is by listing > commits that should be applied. > > Volunteers? I'd be happy to help with the efforts! I just took a few minutes and checked both repos out into a single working tree, and there aren't many commits unique to each repository. The official savannah repo has 5 commits since they diverged, with the 3 oldest looking like variations of the 6 oldest in the gitlab repo. Likewise, not counting the 6 just mentioned, there are 4 unique commits in the gitlab repo. Those 4 commits are: * c9aef52 - (gitlab/master, gitlab/HEAD) elisp/ui-package: Add 'guix-package-use-name-at-point' variable (12 months ago) * e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months ago) * 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 months ago) * fbc2bbc - elisp/ui-package: Use thing at point for 'guix-packages-by-name' command (1 year, 3 months ago) Cheers, Kaelyn P.S For full reference, the remotes are: gitlab https://gitlab.com/emacs-guix/emacs-guix.git officialgit://git.savannah.gnu.org/guix/emacs-guix.git `git merge-base gitlab/master official/master` returns the hash: 41fba4eec845e050be92bfe76c0f7980bbe821bd The commits since the merge-base in the savannah repo: * c9c5cb0 - (HEAD -> master, official/master) elisp/profiles: Support Home profiles. (3 months ago) * 94fcf1f - elisp/prettify: Recognize "/zstd" in nar URLs. (4 months ago) * 825ab77 - Remove all references to the GuixSD name. (1 year, 4 months ago) * a42f66c - elisp: Support geiser @0.12.x (1 year, 4 months ago) * d61d827 - scheme: Remove @@ for Guile 3.x support. (1 year, 4 months ago) And the commits in the gitlab repo since the merge-base: * c9aef52 - (gitlab/master, gitlab/HEAD) elisp/ui-package: Add 'guix-package-use-name-at-point' variable (12 months ago) * e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months ago) * 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 months ago) * fbc2bbc - elisp/ui-package: Use thing at point for 'guix-packages-by-name' command (1 year, 3 months ago) * 057e3a6 - Remove all references to the "GuixSD" name (1 year, 4 months ago) * bb2a053 - elisp/repl: Support geiser 0.12.x (1 year, 5 months ago) * 753dbb0 - scheme: Remove "@@" from 'log-url' (1 year, 5 months ago) * 66695d0 - scheme: Remove "@@" from "pack" symbols (1 year, 5 months ago) * 20cb235 - scheme: Remove "@@" from 'operating-system-firmware' (1 year, 5 months ago) * 307aa05 - scheme: Remove "@@" from 'search-path-environment-variables' (1 year, 5 months ago) > > Thanks, > Ludo’.
Re: see which X11 config is being used
--- Original Message --- On Friday, April 29th, 2022 at 6:08 AM, Théo Maxime Tyburn wrote: > Hi, > > I would like to look at the final config file for xorg that was generated in > the system definition. I looked into > /var/guix/profiles/system/profile/share/X11/ with no success. Where > could I find it ? Could it also be possible to generate it directly in > scheme in the guix repl ? > > Best, > > Théo Hi Théo, I'm not sure about a more direct way of determining the path to the final xorg config (I'm still trying to learn/discover how to find the right path to various generated configs like that where there are multiple versions in /gnu/store), but if you've (attempted to) run xorg with your current system profile you can find the paths in /var/log/Xorg.0.log. For example, lines 14-16 of my Xorg.0.log: [30.068] (++) Using config file: "/gnu/store/w1zvqxc4vzkifpjrs07is7qs3h3x3g1x-xserver.conf" [30.068] (++) Using config directory: "/gnu/store/srgk57icx1mv689ildw2937ik6pyw9q3-xorg.conf.d" [30.068] (==) Using system config directory "/gnu/store/hllpqzv60p9vakrb2p98fvfksdqwcc9j-xorg-server-21.1.2/share/X11/xorg.conf.d" HTH! Cheers, Kaelyn
Re: go importer documentation/exceptions
--- Original Message --- On Saturday, April 23rd, 2022 at 9:51 AM, jgart wrote: > Hi Guixers, > > Here's my experience of learning the right syntax for the go importer: > > 2022-04-23 16:27:42 guix import go > https://git.sr.ht/~emersion/chathistorysync@0.1.0 > > 2022-04-23 16:27:53 guix import go > https://git.sr.ht/~emersion/chathistorysync@latest > > 2022-04-23 16:27:58 I tried that too > > 2022-04-23 16:28:00 and > > 2022-04-23 16:28:09 guix import go > https://git.sr.ht/~emersion/chathistorysync@v0.1.0 > > 2022-04-23 16:28:28 singpolyma: is this related to the issue you have > open? > > 2022-04-23 16:29:41 Do you get an error about a tag being > missing? > > 2022-04-23 16:31:32 here's the exact errors for all three attempts: > https://paste.sr.ht/~whereiseveryone/dae9350b5680a3960e0e56c6b7c5da5660d3b8a6 > > 2022-04-23 16:32:29 looks like a 410: > https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/410 > > 2022-04-23 16:33:26 guix import go > git.sr.ht/~emersion/chathistorysync@0.1.0 > > 2022-04-23 16:33:30 this worked > > > The Guix docs do not explicitly state that a uri like > https://git.sr.ht/~emersion/chathistorysync@0.1.0 is not allowed: > > https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-import.html > > This leaves footguns for new users trying to use the go importer for the > first time since a new user might want to just copy paste the go package's > url into the terminal. > > Should we be explicit in the docs about what uri syntax is and is not allowed > or should we provide better exceptions when the go importer blows up? My $0.02: both would be best. Documenting the correct syntax instead of relying on error messages for that information makes for a much nicer user experience, as do better/clearer exceptions when a tool fails. Cheers, Kaelyn > > all best, > > jgart > > https://whereis.みんな/ > gemini://whereis.みんな/ > http://litterbox.whereis.みんな/
Re: Error pulling custom channel that includes another third-party channel
--- Original Message ---
On Wednesday, April 13th, 2022 at 4:29 PM, B. Wilson
wrote:
> Hey Guix,
>
> In my channels.scm, in addition to the primary guix channel I have my-channel
> and other-channel. This has worked just fine, until I added a commit in
> my-channel which use-modules something from other-channel.
>
> Now guix pull fails when attempting to build my-channel:
>
> (exception misc-error (value #f) (value "no code for module ~S") (value
> ((other channel module))) (value #f))
>
> What am I missing?
>
> Just to be clear, locally building with `guix build -L path/to/my-channel foo`
> succeeds just fine. Is there somewhere inside my-channel where I need to
> explicitly declare the dependency on other-channel?
>
> Any help appreciated. Cheers,
>
> BW
Hello! I have a local guix channel that depends on another channel. Basically
in the top-level folder of your channel's git repo, you need a .guix-channel
file declaring the dependency (in a fashion similar to channels.scm). For
example, for my-channel:
(channel
(version 0)
(dependencies
(channel
(name other-channel)
(url "http://other-channel;)
(branch "master"
HTH!
Cheers,
Kaelyn
Re: service extensions to guix-service-type
--- Original Message --- On Sunday, April 10th, 2022 at 8:19 PM, Justin Veilleux wrote: > Hi guix-devel. > > For my os.scm, I want to create a service which encapsulates the process > of adding channels to the global channels file, adding substitute urls > to the daemon and also adding authorized keys to the daemon. With the > service extension system, I was able to do the first thing by extending > `special-files-service-type`. However, I cannot do the last two things, > because the current definition of guix-service-type only exposes > chroot-directories (what is the use case for this, btw?). > > Is there a reason for this particular design? I will probably submit a > patch to add this functionality. > > Cheers. Hi Justin, You should be able to add authorized keys and substitute URLs by modifying the guix-service-type's config in your OS's list of services. For example: (modify-services %desktop-services (guix-service-type config => (guix-configuration (inherit config) (substitute-urls (cons* "http://myserver:8880; (guix-configuration-substitute-urls config))) (authorized-keys (cons* (gexp:local-file "myserver-signing-key.pub") (guix-configuration-authorized-keys config)) (More info on the guix-configuration fields can be found at https://guix.gnu.org/en/manual/devel/en/html_node/Base-Services.html#Base-Services :) Hope that helps! Cheers, Kaelyn
Re: Package's inputs for developer?
Hello, On Sunday, March 6th, 2022 at 8:19 AM, Olivier Dion via "Development of GNU Guix and the GNU System distribution." wrote: > Hi Guix, > > I often find my self using inheritance of package to add native-inputs > > that are not stricly necessary for building the project, but are used > > for developement purpose like so: > > - > > (define base-native-inputs (list ...)) > > (define my-package > > (package > > ... > > (native-inputs base-native-inputs) > > ...)) > > ;; Developers version > > (package > > (inherit my-package) > > (native-inputs > > (append base-native-inputs > > (list gdb lcov > > - > > I guess this is the correct way of doing it or perhaps I should put gdb > > and lcov in the base-native-inputs?. But I was thinking that perhaps > > something like `(developer-inputs (list gdb lcov))` would be better, > > since these inputs are not stricly necessary for building the package. Can you give a bit more detail about what the use case is for adding developer tools as inputs? The inheritance you describe seems more cumbersome than simply doing `guix shell gdb lcov -D my-package` to enter a development environment with gdb and lcov present, while also being a bit more limited when there are multiple tools with a similar function. In the above example, imagine if a developer wants to debug my-package using lldb instead of gdb--the developer-inputs would require transforming the package definition, but the ad-hoc invocation could simply be `guix shell lldb lcov -D my-package`. Cheers, Kaelyn > > Regards, > > old > > -- > > Olivier Dion > > Polymtl
Re: Statement from the Guix maintainers regarding recent events
Hi Maxim and the other Guix maintainers, As a new-ish Guix user, fledgling contributer, and fairly quiet list member for whom those recent discussions hit close to home, I would like to thank you all for your handling of the situation. I also thank you for sending the statement about the resolution of the events. The threads were emotionally too difficult for me to keep following them, and seeing this statement has again re-affirmed my faith in the Guix community and the consideration and respect I have observed in it over the past nine months. Again, I give you my heart-felt thanks. Cheers, Kaelyn
Re: llvm on aarch64 builds very slowly
On Wednesday, February 23rd, 2022 at 9:49 AM, Christopher Baines wrote: > Ricardo Wurmus rek...@elephly.net writes: > > > Ricardo Wurmus rek...@elephly.net writes: > > > > > Hi Guix, > > > > > > I had to manually run the build of llvm 11 on aarch64, because it would > > > > > > keep timing out: > > > > > > time guix build > > > /gnu/store/0hc7inxqcczb8mq2wcwrcw0vd3i2agkv-llvm-11.0.0.drv > > > --timeout=99 --max-silent-time=99 > > > > > > After more than two days it finally built. This seems a little > > > > > > excessive. Towards the end of the build I saw a 1% point progress > > > > > > increase for every hour that passed. > > > > > > Is there something wrong with the build nodes, are we building llvm 11 > > > > > > wrong, or is this just the way it is on aarch64 systems? > > > > I now see that gfortran 10 also takes a very long time to build. It’s > > > > on kreuzberg (10.0.0.9) and I see that out of the 16 cores only one is > > > > really busy. Other cores sometimes come in with a tiny bit of work, but > > > > you might miss it if you blink. > > > > Guix ran “make -j 16” at the top level, but the other make processes > > > > that have been spawned as children do not have “-j 16”. There are > > > > probably 16 or so invocations of cc1plus, but only CPU0 seems to be busy > > > > at 100% while the others are at 0. > > > > What’s up with that? > > Regarding the llvm derivation you mentioned [1], it looks like for > > bordeaux.guix.gnu.org, the build completed in around a couple of hours, > > this was on the 4 core Overdrive machine though. > > 1: > https://data.guix.gnu.org/gnu/store/0hc7inxqcczb8mq2wcwrcw0vd3i2agkv-llvm-11.0.0.drv > > On the subject of the HoneyComb machines, I haven't noticed anything > > like you describe with the one (hatysa) running behind > > bordeaux.guix.gnu.org. Most cores are fully occupied most of the time, > > which the 15m load average sitting around 16. > > Some things to check though, what does the load average look like when > > you think the system should be using all it's cores? If it's high but > > there's not much CPU utilisation, that suggests there's a bottleneck > > somewhere else. > > Also, what does the memory and swap usage look like? Hatysa has 32GB of > > memory and swap, and ideally it would actually have 64GB, since that > > would avoid swapping more often. One thing I remember about building LLVM a number of years ago when I was working on it through my job (though only for x86-64, not aarch64) is that the build is very memory intensive. In particular, linking the various binaries would each be quite slow and consume a lot of memory, causing significant, intense swapping with less than 64GB of memory in a parallel build (and sometimes eventually trigger the OOM killer). As I recall, using ld.bfd for the build was by far the slowest, ld.gold was noticeably better, and ld.lld was showing promise for doing better than ld.gold. Just my $0.02 of past experiences, in case they help to understand the slow aarch64 build with LLVM 11. Cheers, Kaelyn > > One problem I have observed with hatysa is storage > > instability/performance issues. Looking in /var/log/messages, I see > > things like the following. Maybe check /var/log/messages for anything > > similar? > > nvme nvme0: I/O 0 QID 6 timeout, aborting > > nvme nvme0: I/O 1 QID 6 timeout, aborting > > nvme nvme0: I/O 2 QID 6 timeout, aborting > > nvme nvme0: I/O 3 QID 6 timeout, aborting > > nvme nvme0: Abort status: 0x0 > > nvme nvme0: Abort status: 0x0 > > nvme nvme0: Abort status: 0x0 > > nvme nvme0: Abort status: 0x0 > > Lastly, I'm not quite sure what thermal problems look like on ARM, but > > maybe check the CPU temps. I see between 60 and 70 degrees as reported > > by the sensors command, this is with a different CPU cooler though. > > Chris
Re: [CORE-UPDATES] librsvg and rust
On Wednesday, December 8th, 2021 at 6:36 AM, Ricardo Wurmus wrote: > Ludovic Courtès l...@gnu.org writes: > > > Hello! > > > > For the record, this is a followup to Efraim’s proposal in > > > > https://issues.guix.gnu.org/51845. > > > > Efraim Flashner efr...@flashner.co.il skribis: > > > > > Option 1: > > > > > > Track down the ~220 crates which form the dependency graph (of crates) > > > > > > for librsvg and pin them until the next core-updates cycle. Continue > > > > > > like with other packages and add newer versions (like cmake or meson) as > > > > > > packages need them.¹ > > > > The advantage of this approach is that we could do it incrementally: we > > > > could merge ‘core-updates-frozen’ today and just add pinned variants of > > > > these 200+ crates as needed as time passes. The downside is that it’s a > > > > lot of crates to take care of, and we might still accidentally overlook > > > > seemingly innocuous crate upgrades that end up causing major rebuilds. > > > > > Option 2: > > > > > > Use the bundled crates and treat it as just part of the librsvg source > > > > > > code.² > > > > > > Option 2b: > > > > > > Use the bundled crates for now to finish with core-updates-frozen and > > > > > > revisit this immediately on core-updates (not frozen). > > > > This option will involved a rebuild on x86_64, but the advantage is that > > > > we’ll be safe going forward: we won’t accidentally cause world rebuilds > > > > just because an obscure crate somewhere has been upgraded. > > > > [...] > > > > > I'm currently leaning option 2b, it'll get us past this hurdle for > > > > > > core-updates-frozen and let us make changes to the crates as we work to > > > > > > integrate them more fully into Guix. > > > > Same here; it’s not ideal, but it seems like the most reasonable > > > > short-term option. > > > > If there are no objections, I’d suggest that you go ahead with this > > > > plan. > > I agree that 2b is the most sensible option in our current situation. As a developer and new-ish Guix user (and not someone familiar with rust), I am also in favor of 2b. Dealing with 200+ dependencies takes time, and core-updates-frozen has been on the cusp of merging for some time now. I'd like to see c-u-f merged back into master sooner, as master lacks support for newer hardware while also getting regular package updates that are only periodically merged to core-updates-frozen. Even before the c-u-f sprint last month where I switched all of my systems to c-u-f, I had one system that was first a frankensteined master before finally managing to switch it to c-u-f, to pick up a newer mesa that wasn't unusably buggy on a Radeon RX 6700 XT. Cheers, Kaelyn P.S. Regarding switching my systems, the only issue I've run into that hasn't been fixed is that tigervnc only recently added support for building against xorg-server 21.1.1, and the current tigervnc release (1.12.0) was released before that support landed. (I have a standalone package definition for building a recent git commit.) > > > > Ricardo
Re: Reverse the naming of store items?
On Saturday, December 4th, 2021 at 7:04 AM, Jacob Hrbek wrote: > Currently we use > /gnu/store/zzz16sfz4jxsdvf8j29rkd46psrc6dpj-emacs-ert-runner-0.8.0.drv for > store items which are painful to navigate from CLI using bash's > auto-completion as the first letter doesn't correspond to the package name > which usually requires doing `ls /gnu/store | grep emacs` and then copy > pasting the path to work with the store items. > While I agree the store paths are a pain to work with from the CLI and could make CLI interactions a bit easier, I don't think reversing the name of the store items willresolve the issue of knowing the correct package path. Specifically, as package dependencies and derivations change over time, the hash changes without the package name or version changing. For example, on a computer I switched to GuixSD 3 or 4 months ago currently has 25 different hashes for mesa 20.2.4 (as seen from "ls -d /gnu/store/*mesa-20.2.4") and three more for mesa 21.2.5 from switching to core-updates-frozen. So using the latter as example, "ls -d /gnu/store/*mesa-21.2.5" currently yields: /gnu/store/5sbldxhgxwn2cjlkgak8sz1xms5paw2b-mesa-21.2.5/ /gnu/store/ibcvamhixj4gnxbimgzgb7hga01wa7fw-mesa-21.2.5/ /gnu/store/yai19kghj02lkp8g5rjh28qwyp3i7ik4-mesa-21.2.5/ Reversing the names won't solve the issue of which is the correct/current version. Following the same example, "guix build -n mesa" prints out the path corresponding to the current generation of "guix pull": 25.2 MB would be downloaded: /gnu/store/irq1fkfd4cg78qscycjzxy1nzf0n8j9m-mesa-21.2.5-bin /gnu/store/5sbldxhgxwn2cjlkgak8sz1xms5paw2b-mesa-21.2.5 (The message about the downloads is because the "*-bin" output isn't currently in my /gnu/store.) In the simplest cases picking any one of the three could work, though even then there could be library version conflicts if the picked version uses older/different libs than what your environment has (for mesa, that could be VDPAU_DRIVER_PATH pointing to a directory with incompatible modules; for python, that could be PYTHONPATH referring to the wrong python site directory such as "~/.guix-profile/lib/python3.8/site-packages"). In this case, because I also have wine installed, one of the three mesa-21.2.5 directories is not even the same architecture as the others: $ file /gnu/store/*mesa-21.2.5/lib/libGL.so.1.2.0 /gnu/store/5sbldxhgxwn2cjlkgak8sz1xms5paw2b-mesa-21.2.5/lib/libGL.so.1.2.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped /gnu/store/ibcvamhixj4gnxbimgzgb7hga01wa7fw-mesa-21.2.5/lib/libGL.so.1.2.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped /gnu/store/yai19kghj02lkp8g5rjh28qwyp3i7ik4-mesa-21.2.5/lib/libGL.so.1.2.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped That isn't to say I disagree with reversing the naming or other improvements to the CLI experience, because I do agree it could use some QoL polish. I only wanted to chime in about the complexities of providing better integrations. Cheers, Kaelyn > Would it break anything if we changed the metadata order like: > /gnu/store/emacs-ert-runner-0.8.0-zzz16sfz4jxsdvf8j29rkd46psrc6dpj.drv ? > > -- Jacob "Kreyren" Hrbek > > Sent with ProtonMail Secure Email.
Re: I just got my pinephone.
Hi Guix! I just received my pinephone this morning, so I'm going to be interested in bringing Guix to the pinephone as well. I hope to have the capacity to help with the efforts, even if it's just the occasional testing. Cheers, Kaelyn Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, September 1st, 2021 at 12:39 PM, Joshua Branson wrote: > Hey Guix! > > I just got my phinephone. It's currently running postmarketOS (1). I > > usually work nights two nights a week 10pm-6am (EST) Sunday night and > > Monday night. If a guix developer would like ssh access to it during > > those times, then please let me know. If I should use Mobian instead > > to help port guix to it, then I would be willing to switch. > > I'd be happy to help out! Also jmp.chat (2) works really well with > > chatty. > > Thanks, > > Joshua > > 1. https://postmarketos.org/source-code/ > 2. https://jmp.chat
Re: bug#48941: [powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs
Hi, ‐‐‐ Original Message ‐‐‐ On Wednesday, July 21st, 2021 at 1:08 AM, Chris Marusich wrote: > Hi, > > I need a little help figuring out how to use gdb in Guix for bug 48941: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48941 > > Here's the situation. A libfaketime test hangs forever. Upstream > > suggested I debug it. I'm trying to, but gdb errors out. What am I > > doing wrong? It's probably something simple, but I can't see what. > > I'll describe what I've done. First, I started a build like so: > > ./pre-inst-env guix build --keep-failed libfaketime > > While the problematic test hung, I found the PID of the test and killed > > it. This caused the build to fail, leaving the build environment for me > > to play around in. > > I entered a pure environment that contains all the things I need to > > debug the test (gcc 10.3.0 is currently the default gcc on > > core-updates): > > ./pre-inst-env guix environment --pure libfaketime --ad-hoc > gcc-toolchain@10.3.0 gcc-toolchain@10.3.0:debug gdb > > In the pure environment, I confirmed I can build and run the hanging > > test via the following commands (I added -g in order to get debug > > symbols): > > make FAKETIME_COMPILE_CFLAGS='-DFORCE_MONOTONIC_FIX -g' CC=gcc > PREFIX=/tmp/guix-build-libfaketime-0.9.9.drv-0/myprefix > > make FAKETIME_COMPILE_CFLAGS='-DFORCE_MONOTONIC_FIX -g' CC=gcc > PREFIX=/tmp/guix-build-libfaketime-0.9.9.drv-0/myprefix test > > OK, so I can trigger the hang. Great! Next step, fire up GDB: > > --8<---cut here---start->8--- > > [0] [env] marusich@suzaku:/tmp/guix-build-libfaketime-0.9.9.drv-0/source/test > > $ gdb ./timetest > > GNU gdb (GDB) 10.2 > > Copyright (C) 2021 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. > > Type "show copying" and "show warranty" for details. > > This GDB was configured as "powerpc64le-unknown-linux-gnu". > > Type "show configuration" for configuration details. > > For bug reporting instructions, please see: > > https://www.gnu.org/software/gdb/bugs/. > > Find the GDB manual and other documentation resources online at: > > http://www.gnu.org/software/gdb/documentation/. > > For help, type "help". > > Type "apropos word" to search for commands related to "word"... > > Reading symbols from ./timetest... > > (gdb) > > --8<---cut here---end--->8--- > > The debug symbols provided by gcc-toolchain@10.3.0:debug are under > > $GUIX_ENVIRONMENT/lib/debug. This is the value of GUIX_ENVIRONMENT: > > --8<---cut here---start->8--- > > $ echo $GUIX_ENVIRONMENT > > /gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile > > --8<---cut here---end--->8--- > > By the way, this directory corresponds to glibc 2.33: > > --8<---cut here---start->8--- > > $ realpath /gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile/lib/debug > > /gnu/store/8akrlhc25d7xvi85gzvginw0vdi4zyg4-glibc-2.33-debug/lib/debug > > --8<---cut here---end--->8--- > > Let's tell GDB where to find those debug symbols: > > (gdb) set debug-file-directory > /gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile/lib/debug > > Let's also tell GDB to set the environment variables that upstream > > recommended when running the test program: > > --8<---cut here---start->8--- > > (gdb) set environment LD_PRELOAD=../src/libfaketime.so.1 > > (gdb) set environment FAKETIME=-10d > > (gdb) set environment NO_FAKE_STAT=1 > > --8<---cut here---end--->8--- > > Now run it: > > --8<---cut here---start->8--- > > (gdb) run > > Starting program: /tmp/guix-build-libfaketime-0.9.9.drv-0/source/test/timetest > > /bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.33' not found > (required by ../src/libfaketime.so.1) /bin/sh: > /lib/powerpc64le-linux-gnu/libc.so.6: version` GLIBC_2.32' not found > (required by > /gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib/libpthread.so.0) Are you using Guix on a foreign distro? This line looks like your distro's normal libc.so was being used and it was from
Re: guix weather exit status?
Hi, I'm fairly new to Guix and haven't made much use of guix weather, but had a thought about the exit status. On Sunday, July 11th, 2021 at 4:40 AM, zimoun wrote: > Hi, > > On Sat, 10 Jul 2021 at 18:06, Leo Famulari l...@famulari.name wrote: > > > On Sat, Jul 10, 2021 at 04:41:44PM +0200, Ludovic Courtès wrote: > > > > > I agree we could change (or rather refine) semantics to exit with > > > > > > non-zero when overall coverage is below 100%. In the example above, it > > > > > > should return 0. > > > > Maybe we could distinguish between various cases like this: > > > > 0 means 100% coverage > > > > 1 means a substitute is available, but not from all servers > > > > 2 means a substitute is not available > > > > This would preserve the current meaning of 0, while still allowing `guix > > weather` to be used in scripts to "wait for a substitute". > > What about two or more packages? “guix weather foo bar” when the > > package ’foo’ is available on one server and ’bar’ is not at all. Or if > > ’foo’ is available on one server and ’bar’ on the other. Etc. > > We could have: > > 0 100% all servers > > 1 100% from one server > > 2 100% from a server mix > > 3 one or more substitute is missing It looks to me like there are two overlapping use cases for guix weather and it's exit status (and sorry if they aren't the clearest): checking substitute availability for download, and substitute progress/coverage among servers. There is already a "--coverage" flag to guix weather that the help describes as "show substitute coverage for packages with at least COUNT dependents". What if a new flag was added, say "-a" / "--available", which specifies the number of servers a single substitute must be available from to be considered available, possibly with a default of "1". That way guix weather can exit 0 when needed for both of the use cases. For example, with the original output that showed 100% substitute availability from ci.guix.gnu.org and 0% availability from bordeaux.guix.gnu.org for a single package and exited 1 as a result: * "guix weather -a 1" would exit 0 * "guix weather -a 2" would exit 1 because it was available from less than 2 servers. That way, even when multiple packages are specified at once, guix weather would exit 0 as long as all of the packages met the requested minimum availability. Cheers, Kaelyn P.S. If folks like the idea, I'm volunteering to implement it. ;)
