Re: API for rewriting package fields ?
On Fri, Apr 26, 2024 at 05:25:47PM +0200, Ricardo Wurmus wrote:
> Nicolas Graves via "Development of GNU Guix and the GNU System distribution."
> writes:
>
> > Is there an interface to rewrite / update a field from a series of
> > packages easily?
>
> We have "update-package-inputs" in (guix upstream), which defines a
> local procedure "update-field". Perhaps you can use that?
>
> What it cannot do yet is *create* a field, e.g. add a native-inputs
> field to add an input when the package currently doesn't have a
> native-inputs field.
There's also the package property updater-extra-{native-,propagated-,}inputs
to add a package even if it's not shown as required by the importer.
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
Re: Managing patches and branches, retrospective and futher changes?
On Wed, Apr 24, 2024 at 02:21:56PM +0100, Christopher Baines wrote: > Hey! > > Almost a year ago, the branching strategy was changed [1][2]. > > 1: https://issues.guix.gnu.org/63459 > 2: https://lists.gnu.org/archive/html/guix-devel/2023-06/msg00024.html > > I think these changes have gone OK, we've had ~27 [3] branches merged in > this manor and I think looking back these changes have been > helpful. Coordination and visibility has improved, and we've been able > to build and test more prior to merging. I'd like to just say that this (without checking the numbers) is almost 10x the number of merges we had previously with just the core-updates/staging branch strategy. > 3: https://issues.guix.gnu.org/search?query=%22Request+for+merging%22 > > There's still room for more improvement though. The current guidance is > here [4], and I've sent a patch for improvements here [5]. > > 4: > https://guix.gnu.org/en/manual/devel/en/html_node/Managing-Patches-and-Branches.html > 5: https://issues.guix.gnu.org/70549 > > Let me know if you have any thoughts or questions! > > Thanks, > > Chris -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Core updates status
On Fri, Apr 26, 2024 at 01:56:12PM +0100, Steve George wrote: > Hi, > > On 25 Apr, Kaelyn wrote: > > Hi, > > > > On Tuesday, April 23rd, 2024 at 11:08 PM, Steve George > > wrote: > (...) > > > - 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). > > That's great, thanks for taking a look. Efraim mentioned that there would be > Rust changes for it. Seeing that librsvg has rust-pango (and some others) in cargo-inputs, and therefore needs pango to build, I think it's safe to move pango (and others as needed) to propagated inputs. Make sure to make the necessary changes to librsvg-2.40 also. I haven't had any problems building the rust based librsvg on core-updates, so I'd suggest leaving that alone for now. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: rust-team branch merged
On Wed, Apr 24, 2024 at 11:58:22AM -0400, Jason Conroy wrote: > > Efraim Flashner writes: > > On the other hand, by generating it during the build of each package we > > make sure to pull in all the crates which exist in the build, so we > > could add into a profile/manifest just the crates listed in a Cargo.toml > > and then each crate would pull in its own dependencies, and then the > > profile hook could combine them all together. > > Thanks. Just to make sure I understand: it sounds like you're saying that by > creating the JSON index files up front, we'd be preserving some knowledge > about a package's dependency graph that isn't easily recovered later by > recursively walking through inputs and cargo-inputs for the package specs in > a manifest/profile? If we create it upfront it may be easier to keep track of the cargo-dependencies, but I suppose it would mostly depend on the implementation. I'm not sure that'd actually be the case, so don't worry about it too much. Whatever we end up with will be better than what we have now, and we can always make it better later if it needs to change. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: rust-team branch merged
On Thu, Apr 18, 2024 at 12:54:02PM -0400, Jason Conroy wrote: > > Efraim Flashner writes: > > > Currently if you were to pull in rust-rand-0.8 and rust-rand-0.7 then > > you'd have both rand-0.*.crate files in the registry but only one of > > them would be listed in share/cargo/registry/index/ra/nd/rand. I need to > > adjust the generation of that file to combine multiple sources if they > > exist, and sort them (I'm not sure it's necessary, but wouldn't be > > surprised if we hit undefined behaviour if they were listed multiple > > times or out of order). > > Hi Efraim, > > I'm currently investigating this limitation of your proposed patch. > > Did you have a strategy in mind for how to fix it? I see that the index > files are currently generated during a phase of cargo-build-system, rather > than as a profile hook. So, to build an index that properly reflects the > contents of a profile, it would seem that the two simplest options are: a) > keep your existing index-generation logic during the build, and merge these > per-package index files when building the profile; or b) move your patch's > index-generating code out of the build phase and into a profile hook, so > that we build each index file in a single pass (for all versions of a > package) rather than merging the files from each package output. > > On the surface option (b) seems cleaner, but maybe you had a reason for > generating the index contents during the build? I like the idea of moving the code into a profile hook much better than what I have now. What's there was more of a proof-of-concept of how it might work. On the other hand, by generating it during the build of each package we make sure to pull in all the crates which exist in the build, so we could add into a profile/manifest just the crates listed in a Cargo.toml and then each crate would pull in its own dependencies, and then the profile hook could combine them all together. The down side is we'd have to have the logic to combine the overlapping rand-0.7/rand-0.8 paths both in the build system and in the profile. Overall it doesn't seem that bad though, since we could then add packages either as a regular input or as a cargo-input. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Status of ‘core-updates’
On Wed, Apr 17, 2024 at 01:47:49PM -0400, Maxim Cournoyer wrote: > Hello, > > Ludovic Courtès writes: > > > Hi Steve, > > > > Steve George skribis: > > > >> On 10 Apr, Ludovic Courtès wrote: > > > > [...] > > > >>> To be clear (but I guess it’s crystal clear to anyone who’s been around > >>> long enough :-)), what we need most is someone to keep track of changes, > >>> coordinate efforts, decide what goes in the branch and what’s postponed > >>> or moved to a separate branch, and send periodic (weekly) status updates > >>> over the course of a couple of months. This can (and probably should) > >>> be done without doing any actual hacking on the branch. > >> (...) > >> > >> This sounds like something I can do: > >> > >> - track changes (in branch) > >> - co-ordinate blocking issues (in bug system) > >> - co-ordinate with people doing the actual work :-P > >> - send (periodic) weekly emails > >> - encourage shipping by minimising scope creep ;-) > > > > Awesome, thanks for volunteering! > > > >> Sounds like there's already agreement to revert the 'pkgconf' change > >> and push a new branch without them which becomes > >> 'core-updates'. Josselin on IRC I had the impression you were > >> working on that? > > > > I’m not sure what the situation is (I see Maxim just pushed changes on > > top of current ‘core-updates’, so maybe it’s OK?). > > Since branches were merged in, I believe the problem we are facing at > the moment is librsvg failing its test suite with a segfault (!). Could > be the glibc upgrade, or rust itself, I'm not sure. I was trying to > upgrade librsvg, which needs an update anyway, but it pulls many rust > crates updates. I'll get there eventually, if nobody beats me to it. I personally think getting librsvg updated will be easier on the rust-team branch than on the core-updates branch, since there have been many commits to the rust-team branch that haven't yet been merged into master. Assuming that now that the cairo upgrade to 1.18 was what was holding back the librsvg upgrade, I can get librsvg up to a newer version and then submit it for a merge. Overall the branch should be in fairly good shape. > > Josselin, Maxim: could you explain what problems there are around > > pkgconf and what you would recommend? > > Nothing in particular to point at the moment, but remaining problems > would manifest in the form of missing inputs, due to transitive libtool > dependencies causing overlinking and the new pkgconf being smart enough > to optimize away some previously captured link directives that would be > baked in the RUNPATH and sastify libtool overlinking needs. > > The solution is to hunt the libtool .la files from the transitive > dependencies causing the problem and removing them. See commit > b6540bd285cbe5920ad379ddfc6256359ee7204c for an example. > > -- > Thanks, > Maxim > -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Google Summer of Code Inquiry
On Tue, Apr 09, 2024 at 05:25:35PM +0200, Ludovic Courtès wrote: > Hi Sebastian, > > Sebastian Dümcke skribis: > > > just wanted to chime in. Since last week I have some working code to > > generate AppImages with guix pack. I was planning on tidying this up > > for submission over the next weeks. > > There is still work to do regarding documentation, adding options > > specific to the AppImage format, building the AppImageKit runtime from > > source and a lot of testing. > > This is great news! Looking forward to incorporating those changes. > > > However, I believe that the remaining effort is around 8-10 hours. I > > am happy to hand the code over to you to finish up and co-mentor > > (though this patch would be my first contribution to guix) if you > > think this is appropriate. > > It does sound like it jeopardizes this specific project. In a way, > that’s a good problem to have as a project, but it does mean that > Zachary would need to look for another project (which could still be > related to ‘guix pack’). > > Thoughts? There's always the option of trying to create flatpaks using Guix. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Vim helper config for Guix
I've been meaning to upstream my guix.git specific vimrc config file,
like the .dir-locals.el in the repo. It is architected so that it also
works in git worktrees.
jump-to-definition works with C+]
If you have guix.vim installed then :Guix defaults to using
./pre-inst-env guix from that worktree.
opening new files ignores the .go files when tab completing
Most of the line indentation works pretty well. Vim, by default for lisp
languages, hardcodes an indent as 2 spaces, and I haven't gotten around
to learning how to write an indentexpr to make it work for guix. As a
result some of the indentation is close but not quite correct, and there
are some cases where the indentation is straight up ignored. I think
that's the case inside g-expressions, but I don't remember.
I've also included a link to my vimrc¹ if anyone wants to see what I
have there.
¹ https://git.sr.ht/~efraim/guix-config/tree/master/item/vim
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
" This file is a per-project '.exrc' file.
" To easily use this file to extend the global .vimrc place it in the root of
" your project and then run:
" ':source .exrc' from the root of your project.
" Add lispwords which occur in the Guix source tree.
" NB: Vim hardcodes 2 as the indentation. See get_lisp_indent in src/indent.c
setlocal lispwords+=add-after
setlocal lispwords+=add-before
setlocal lispwords+=case
setlocal lispwords+=call-with-input-file
setlocal lispwords+=define
setlocal lispwords+=define*
setlocal lispwords+=define*-public
setlocal lispwords+=define-configuration
setlocal lispwords+=define-deprecated
setlocal lispwords+=define-deprecated/public
setlocal lispwords+=define-deprecated/public-alias
setlocal lispwords+=define-gexp-compiler
setlocal lispwords+=define-module
setlocal lispwords+=define-public
setlocal lispwords+=define-record-type
setlocal lispwords+=define-record-type*
setlocal lispwords+=define-syntax
setlocal lispwords+=define-values
setlocal lispwords+=lambda
setlocal lispwords+=lambda*
setlocal lispwords+=let
setlocal lispwords+=let*
setlocal lispwords+=let*-values
setlocal lispwords+=let-syntax
setlocal lispwords+=let-values
setlocal lispwords+=letrec
setlocal lispwords+=letrec*
setlocal lispwords+=letrec-syntax
setlocal lispwords+=match-lambda
setlocal lispwords+=match-lambda*
setlocal lispwords+=match-record
setlocal lispwords+=mixed-text-file
setlocal lispwords+=modify-inputs
setlocal lispwords+=modify-phases
setlocal lispwords+=modify-services
setlocal lispwords+=parameterize
setlocal lispwords+=plain-file
setlocal lispwords+=program-file
setlocal lispwords+=replace
setlocal lispwords+=set!
setlocal lispwords+=strip-keyword-arguments
setlocal lispwords+=substitute*
setlocal lispwords+=substitute-keyword-arguments
setlocal lispwords+=syntax-rules
setlocal lispwords+=unless
setlocal lispwords+=when
setlocal lispwords+=while
setlocal lispwords+=with-directory-excursion
setlocal lispwords+=with-extensions
setlocal lispwords+=with-fluids
setlocal lispwords+=with-imported-modules
setlocal lispwords+=with-input-to-file
setlocal lispwords+=with-output-to-file
setlocal lispwords+=with-parameters
setlocal lispwords+=wrap-program
setlocal lispwords+=wrap-script
" In this repository .go files are compiled guile objects, not golang.
set wildignore+=*.go
" This is for the tie-in with guix.vim.
" TODO: guix.vim needs to correctly export autoloaded_guix.
if match(, 'guix') != -1
let g:guix_binary = expand('%:p:h') . "/pre-inst-env guix "
endif
" Editorconfig.vim has been distributed with vim since 9.0.1799.
if (has('syntax') && has('eval') &&
\ has("patch-9.0.1799") &&
\ filereadable('.editorconfig') &&
\ (match(, 'editorconfig') != -1))
packadd! editorconfig
endif
if (has("cscope") && executable('global') && executable('find'))
" These two lines could go in a gtags.conf file.
call setenv('GTAGSLABEL', 'pygments')
silent! call system("find {gnu,guix} -name '*\.scm' -print > gtags.files")
if !filereadable("GTAGS")
" This is a blocking operation, but it needs to complete before
" 'cscope add' is run. In addition, there needs to be a 'trigger' of
" some sort to cause vim to recognize the cscope database is ready if
" vim is already open.
" First run can be very slow.
call system("gtags")
"let tags_job = job_start("gtags", {'exit_cb': execute('cscope add
GTAGS $PWD -a')})
else
call system('global --update')
"let tags_job = job_start('global --update', {'exit_cb':
execute('cscope add GTAGS $PWD -a')})
endif
execute('cscope add GTAGS $PWD -a')
e
Re: the right to rewrite history to rectify the past (was Re: Concerns/questions around Software Heritage Archive)
On Thu, Mar 21, 2024 at 04:23:01PM +0100, Hartmut Goebel wrote: > Am 21.03.24 um 07:12 schrieb MSavoritias: > > Specifically the social rules that we support trans people and we want > > to include them. Any person really that want to change their name at > > some point for some reason. > > Interestingly you are asking the right to get the old name rewritten for > trans people only. > > To be frank: IMHO This is a quiet egocentric point of view. I took it in as though we were discussing the recent activity, not that it was ONLY this instance that we care about. I have a number of friends who have more than 1 set of names and specifically wish to to by one set over the other. The point is that there is a vocal portion of people in the world who insist on deadnaming people, and that is not okay. > In many cultures all over the world women are required to change their name > when they merry. And you are not asking for women's right. But only for > right for the small but loud minority of trans people. As a project, we support people by addressing them by their preferred name, and honoring their wishes as to name, gender, honorifics, etc. For all people. If a person chooses to go by their "maiden name" or their "married name" or a pseudonym, that's their prerogative. > > -- > Regards > Hartmut Goebel > > | Hartmut Goebel | h.goe...@crazy-compilers.com | > | www.crazy-compilers.com | compilers which you thought are impossible | > > -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: rust-team branch merged
On Thu, Mar 07, 2024 at 11:48:53AM -0500, Jason Conroy wrote: > On Thu, Mar 7, 2024 at 3:08 AM Efraim Flashner > wrote: > > > The transitive dependencies getting pulled in automatically should work > > automatically if we ever finish the antioxidant-build-system. > > > Since you bring up antioxidant, I'm kind of curious whether that stalled > mainly due to shifts in contributor priorities, or due to significant > technical issues. More the first. I found that the actual build time was slightly faster using the antioxidant-build-system over the cargo-build-system but I wasn't in a position to take it up when the original author moved on to other things. > > Until then > > I've been experimenting by manually listing the other crates I've needed > > but in theory we could try to make `guix shell --development` pull in > > the needed crates. > > > > I was considering another option that falls somewhere in between: since I'm > already building shells from manifest files, it should suffice to have a > Scheme utility function that calculates the transitive dependencies for a > given list of library packages. Similar logic seems to exist already in > `(guix build-system cargo)` but it's not exposed publicly. As interim > solutions go, what do you think about this one versus modifying `guix > shell`? Once you have something like that working it shouldn't be too hard to merge that into `guix shell`, assuming we go that route. > > > > I misread what you wrote as it was working. It's definitely something I > > want but wasn't ready to work on yet. > > > > > I took rust-rand as an example only because it does have some > > dependencies: > > > > > > $ cd $CARGO_PROJECT > > > $ cat Cargo.toml > > > [package] > > > name = "test_prog" > > > ... > > > [dependencies] > > > rand = "0.8.5" > > > > > > $ cargo build > > > Updating crates.io index > > > Downloaded cfg-if v1.0.0 > > > Downloaded rand_chacha v0.3.1 > > > Downloaded rand v0.8.5 > > > Downloaded ppv-lite86 v0.2.17 > > > Downloaded rand_core v0.6.4 > > > Downloaded getrandom v0.2.12 > > > Downloaded libc v0.2.153 > > > Downloaded 7 crates (932.0 KB) in 0.48s > > >Compiling libc v0.2.153 > > >Compiling cfg-if v1.0.0 > > >Compiling ppv-lite86 v0.2.17 > > >Compiling getrandom v0.2.12 > > >Compiling rand_core v0.6.4 > > >Compiling rand_chacha v0.3.1 > > >Compiling rand v0.8.5 > > >Compiling test_prog v0.1.0 (/home/...) > > > > > > > > > > Currently if you were to pull in rust-rand-0.8 and rust-rand-0.7 then > > > > you'd have both rand-0.*.crate files in the registry but only one of > > > > them would be listed in share/cargo/registry/index/ra/nd/rand. I need > > to > > > > adjust the generation of that file to combine multiple sources if they > > > > exist, and sort them (I'm not sure it's necessary, but wouldn't be > > > > surprised if we hit undefined behaviour if they were listed multiple > > > > times or out of order). > > > > > > > > > I'm somewhat new to rust, but it appears that outside of Guix, the > > > local-only development workflow looks like this: > > > > > > $ cd $CARGO_PROJECT > > > $ mkdir $VENDOR > > > $ cargo vendor $VENDOR > > > > > > After downloading and unpacking all of the crates into $VENDOR, this last > > > command instructs me to add the following in ~/cargo/config.toml. > > > Then, after opening a new guix shell without network access, I can > > confirm > > > that `cargo build` works fine with the vendored crates. > > > > > > [source.crates-io] > > > replace-with = "vendored-sources" > > > > > > [source.vendored-sources] > > > directory = "" > > > > I wanted local-registry over replace-with because IIRC replace-with > > won't fall back to downloading from crates.io if there's missing crates, > > while local-registry will check there first and then download any > > missing crates. The use-case I was looking at for that was adding a new > > dependency to a project and then not needing to re-create a shell or > > package the new crates before continuing on. > > > > I see, thanks. My preferred workflow is different but I acknowledge that > use case. > > The link below claims that one can update the vendor directory in a similar >
Re: Creating an unversioned rust-cargo symbol
On Thu, Feb 29, 2024 at 05:42:20PM -0500, Richard Sent wrote: > Hi Guix, > > There isn't an unversioned symbol for rust-cargo defined or exported by > the (gnu packages crates-io) module. I think it would be best if an > unversioned rust-cargo symbol was created that was equal to the highest > rust-cargo release. (i.e. rust-cargo, not rust-cargo-0.76) > > Alternatively, since (seemingly) only one rust-cargo package is present > at a time, perhaps the version information could be removed outright and > only an unversioned symbol used. > > The alternative, (specification->package), does not work in all > circumstances (primarily with -L) [1]. This would also make Scheme code > that refers to rust-cargo cleaner, either not needing updating every new > version when the symbol changes or removing potentially awkward > (specification->package) calls. > > I see that most/all of the symbols in crates-io are versioned. While > from a user perspective it would be nice if there were more unversioned > symbols, rust-cargo is /probably/ the one that needs it the most since > it's so central to the ecosystem. I can also see why versioning every > symbol might help with development given Rust's release schedule and > bootstrapping chain. > > This would follow the pattern of linux-libre. > > Posting to guix-devel instead of bug-guix since I'm not entirely sure > this is a bug or working as intended. > > [1] https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00310.html > I've added a rust-cargo package in rust-apps.scm and a note in crates-io.scm to remove it with the next rust-team merge. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: GSoC 2024
On Thu, Mar 07, 2024 at 02:09:32PM +, Steve George wrote: > > Hi, > > I had a couple of ideas - but would need help from someone to mentor > > 1. Moldable development in Guix > Exploratory REPL experience is one of the hall-marks of 'moldable' systems. > This shortens the development cycle and improves the ability of users to > explore Guix. > > The best REPL experience today is through Emacs. We have a modern nREPL > implementation that is compatible with Guile. This needs further development > and the Guix client side improved. > > * Develop a basic CLI Nrepl experience in guile-ares-rs > (https://git.sr.ht/~abcdw/guile-ares-rs) > * Add further CLI REPL functions to Guix > * Stretch goal to add a Guix / Guile Scheme nrepl support to Conjure > (https://github.com/Olical/conjure/issues/549) > > This would need co-ordination with Andrew Tropin (abcw) and Oliver Caldwell > (Olical), and some help from a Guix mentor. > > 2. Improving Docker image output (guix pack) > Docker containers are a common deployment method for applications. While they > may be good for deployment, they have weak reproducibilty which Guix solves. > Docker containers generated by Guix for deployment are large compared to > similar deployments using Nix or Alpine. The purpose of this project is to > optimise the build and deployment pipeline in Guix. > > * Examine the current 'guix pack' process for optimisations > * Optimise the build process to add docker specific capabilities like > multi-stage builds > * Explore using grafts or masking to reduce final image size > > ** NOTE:** I know this is a bit weak - I don't know enough about this myself > yet - is this even a good target - I think it's interesting for scientific > computing? This would also be useful for "deploy this guix service as a docker container". > 3. Add sandboxing to guix packages > Improving the security for end-users by implementing optional sandboxing for > desktop applications. The likes of Bubblewrap and Flatseal are available for > Linux. There's some existing Nix prior-art that could be a good starting > point (https://nixos.wiki/wiki/Firejail) and > (https://sr.ht/~fgaz/nix-bubblewrap/) > > * Figure out which of the available options is the most sustainable > * Integrate policys and implementation into high-profile packages > * Stretch would be to create a Guile native library / approach > > Anyone interested in these - willing to mentor/co-mentor with me? > > On 4 Mar, Gábor Boskovits wrote: > > Hello guix, > > > > I coordinated with the GNU org admins, and we can still do this round, > > but we have to go fast to make this happen. I have already taken the > > initiative to try to get an ideas page up, now I would like to confirm > > if the mentors from last year are still available, and that the ideas > > are still valid. > > > > Hereby I quickly collected the projects with the respective mentors, > > please pm me your availability: > > > > Decentralized substitute distribution > > pukkamustard (pukkamustard [at] posteo [dot] net) > > attila.lendvai (ethswarm.org, scheme) > > > > Robustify long-term support for Reproducible Research > > Simon Tournier (zimoun) > > > > Develop a Web interface to configure Guix System > > Ludovic Courtès (civodul) > > > > Trusted computing: Goblins for GNU Guix > > Christopher Webber, Ludovic Courtès and Pjotr Prins > > > > Guix Data Service revision processing instrumentation and performance > > Christopher Baines > > > > Guile based build-tool > > Pjotr Prins > > > > GNU Guix system monitor > > Pjotr Prins > > > > Booting via network > > Danny Milosavljevic > > > > Syntax and semantics of systemd units in the Shepherd > > Ludovic Courtès (civodul) > > > > GNUnet integration > > no mentor available > > > > Adding modules in support of continuous integration to cuirass > > Ludovic Courtès (civodul) > > > > Continue rewrite build daemon in Guile Scheme > > Ludovic Courtès (civodul) > > > > I myself am available to co-mentor, and also to be the formal mentor > > in case someone does not feel like doing the official dance with > > Google. Currently I can commit to devoting two hours a week to this. > > > > Regards, > > g_bor > > > -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: rust-team branch merged
On Wed, Mar 06, 2024 at 12:53:44PM -0500, Jason Conroy wrote: > On Wed, Mar 6, 2024 at 4:06 AM Efraim Flashner > wrote: > > > On Mon, Feb 26, 2024 at 09:24:29PM -0500, Jason Conroy wrote: > > > Hello Efraim, > > > > > > Thanks for investigating this - a Rust development workflow using only > > > Guix-native crates is something I've been waiting for! > > > > > > I was experimenting with your patches and it seems that they do pull in > > the > > > source crates for requested packages, but not their dependencies (example > > > below). Is there something I'm missing? > > > > When you say they pull in the source crates do you mean the sources of > > the other rust packages needed by rust-rand? I didn't test that, but I > > assumed it wouldn't. > > > > That's right, I'm interested in having `guix shell` populate the full set > of transitive dependencies in the registry, similar to what happens when > using `cargo build` in the conventional way (but instead using > Guix-packaged crates). I interpreted your message up-thread to mean that > you were trying to accomplish the same, but please correct me if not. The transitive dependencies getting pulled in automatically should work automatically if we ever finish the antioxidant-build-system. Until then I've been experimenting by manually listing the other crates I've needed but in theory we could try to make `guix shell --development` pull in the needed crates. I misread what you wrote as it was working. It's definitely something I want but wasn't ready to work on yet. > I took rust-rand as an example only because it does have some dependencies: > > $ cd $CARGO_PROJECT > $ cat Cargo.toml > [package] > name = "test_prog" > ... > [dependencies] > rand = "0.8.5" > > $ cargo build > Updating crates.io index > Downloaded cfg-if v1.0.0 > Downloaded rand_chacha v0.3.1 > Downloaded rand v0.8.5 > Downloaded ppv-lite86 v0.2.17 > Downloaded rand_core v0.6.4 > Downloaded getrandom v0.2.12 > Downloaded libc v0.2.153 > Downloaded 7 crates (932.0 KB) in 0.48s >Compiling libc v0.2.153 >Compiling cfg-if v1.0.0 >Compiling ppv-lite86 v0.2.17 >Compiling getrandom v0.2.12 >Compiling rand_core v0.6.4 >Compiling rand_chacha v0.3.1 >Compiling rand v0.8.5 >Compiling test_prog v0.1.0 (/home/...) > > > > Currently if you were to pull in rust-rand-0.8 and rust-rand-0.7 then > > you'd have both rand-0.*.crate files in the registry but only one of > > them would be listed in share/cargo/registry/index/ra/nd/rand. I need to > > adjust the generation of that file to combine multiple sources if they > > exist, and sort them (I'm not sure it's necessary, but wouldn't be > > surprised if we hit undefined behaviour if they were listed multiple > > times or out of order). > > > I'm somewhat new to rust, but it appears that outside of Guix, the > local-only development workflow looks like this: > > $ cd $CARGO_PROJECT > $ mkdir $VENDOR > $ cargo vendor $VENDOR > > After downloading and unpacking all of the crates into $VENDOR, this last > command instructs me to add the following in ~/cargo/config.toml. > Then, after opening a new guix shell without network access, I can confirm > that `cargo build` works fine with the vendored crates. > > [source.crates-io] > replace-with = "vendored-sources" > > [source.vendored-sources] > directory = "" I wanted local-registry over replace-with because IIRC replace-with won't fall back to downloading from crates.io if there's missing crates, while local-registry will check there first and then download any missing crates. The use-case I was looking at for that was adding a new dependency to a project and then not needing to re-create a shell or package the new crates before continuing on. The registry as setup in the patches is actually mostly correct, minus the multiple versions of a crate, it just needs to be fed the crates. > Getting back to your patch set: would it make sense to emulate this vendor > workflow instead of trying to construct a registry directly? Even assuming > that all details of the registry structure are stable and documented, the > layout of the vendor directory appears much simpler. And IIUC the code for > setting up vendored libraries already exists in cargo-build-system. > > I also need to figure out something with a > > config.toml to see if it's possible to generate one that could be > > included from another one, since you can't add 'local-registry = > > $GUIX_PROFILE/...' in a toml file. > > > > You've probably researched this more than I
Re: rust-team branch merged
On Mon, Feb 26, 2024 at 09:24:29PM -0500, Jason Conroy wrote: > Hello Efraim, > > Thanks for investigating this - a Rust development workflow using only > Guix-native crates is something I've been waiting for! > > I was experimenting with your patches and it seems that they do pull in the > source crates for requested packages, but not their dependencies (example > below). Is there something I'm missing? When you say they pull in the source crates do you mean the sources of the other rust packages needed by rust-rand? I didn't test that, but I assumed it wouldn't. Currently if you were to pull in rust-rand-0.8 and rust-rand-0.7 then you'd have both rand-0.*.crate files in the registry but only one of them would be listed in share/cargo/registry/index/ra/nd/rand. I need to adjust the generation of that file to combine multiple sources if they exist, and sort them (I'm not sure it's necessary, but wouldn't be surprised if we hit undefined behaviour if they were listed multiple times or out of order). I also need to figure out something with a config.toml to see if it's possible to generate one that could be included from another one, since you can't add 'local-registry = $GUIX_PROFILE/...' in a toml file. > Cheers, > Jason > > $ guix shell --pure bash findutils rust-rand -- bash -c 'find -L > $GUIX_ENVIRONMENT/share/cargo' > /gnu/store/zf88v65rbg2di4qhgdbvhfcjf31rdzby-profile/share/cargo > /gnu/store/zf88v65rbg2di4qhgdbvhfcjf31rdzby-profile/share/cargo/registry > /gnu/store/zf88v65rbg2di4qhgdbvhfcjf31rdzby-profile/share/cargo/registry/index > /gnu/store/zf88v65rbg2di4qhgdbvhfcjf31rdzby-profile/share/cargo/registry/index/ra > /gnu/store/zf88v65rbg2di4qhgdbvhfcjf31rdzby-profile/share/cargo/registry/index/ra/nd > /gnu/store/zf88v65rbg2di4qhgdbvhfcjf31rdzby-profile/share/cargo/registry/index/ra/nd/rand > /gnu/store/zf88v65rbg2di4qhgdbvhfcjf31rdzby-profile/share/cargo/registry/rand-0.8.5.crate > /gnu/store/zf88v65rbg2di4qhgdbvhfcjf31rdzby-profile/share/cargo/registry/config.json > > On Thu, Dec 14, 2023 at 10:10 AM Efraim Flashner > wrote: > > > On Wed, Dec 13, 2023 at 10:34:11AM +0200, Efraim Flashner wrote: > > > * Compiled rust packages currently have a 'package' phase, which runs > > > the command used to crate a 'crate tarball', and is installed in > > > %output/share/cargo/registry, with unpacked sources in > > > %output/share/cargo/src. In theory it should be possible to use these > > > for local rust development. The benefits include everything that comes > > > with being a guix package, including pre-patched shebangs. Currently no > > > index file is created in $GUIX_ENVIRONMENT/share/cargo/registry/index, > > > which is likely necessary to actually make use of this. Additionally, I > > > am unsure how to use '$GUIX_ENVIRONMENT' in ~/.cargo/config so that it > > > is expanded and not taken as a literal string. > > > > In the Guix London meetup someone mentioned that they were interested in > > playing around with using Guix for rust development. I've adjusted the > > cargo-build-system to produce the registry index files and I added a > > profile hook to generate the config.json to locate the packaged crates. > > > > toml files can't process environment variables (which is probably a good > > thing ...) but that means its a little harder to test out. > > > > with the two patches applied create an environment with the crates you > > want and get the location of GUIX_ENVIRONMENT: > > `env | grep GUIX_ENVIRONMENT | cut -f2 -d=` > > > > in ~/.cargo/config: > > [source.crates-io] > > local-registry = '/share/cargo/registry' > > > > 'cargo build' should pull from the local crates in the GUIX_ENVIRONMENT. > > I'm not sure what happens if it doesn't have those crates available and > > would need to get them from crates.io. > > > > -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: %base-packages and default grub theme depend on rust
On Thu, Feb 08, 2024 at 02:33:35PM +0200, Efraim Flashner wrote: > On Mon, Jan 29, 2024 at 05:36:52PM +0100, Ludovic Courtès wrote: > > Hi, > > > > Vagrant Cascadian skribis: > > > > > This is because the default grub theme generates a .png from an .svg > > > ... using guile-rsvg, which uses librsvg, which uses rust ... > > > > How about using a guile-rsvg variant that depends on ‘librsvg-2.40’, the > > last version written in C? > > > > That’s easy to do and would address the immediate problem. > > I bet we could switch it to use guile-cairo. Also, is guile-png too low > level? My experiments with this didn't show it as possible. I like vagrant's idea about using the older librsvg for the guile-rsvg used here, or just pre-generating the png itself and adding it to the guix-artwork repo and using it from there. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Guix days guix home discussion
On Thu, Feb 29, 2024 at 12:59:53AM +0100, Gábor Boskovits wrote: > On guix days in the guix home discussion the following observations were > made: > 1. It is rare that guix home import does the right thing (it is usually > removing some startup file customizations, does not seem to arrange to pick > up profiles, not even its own). Either we should improve it, or document > that it only gives a skeleton configuration and add some guidance on the > steps needed to get a working one. > 2. The user default profile and the home package profile being separate is > causing some issues. It might be enough to document all the special > profiles somewhere (which as of now include at least system profile, user > profile, pull profile and home profile), but we can also think about a bit > more general solution, along the lines of a home service that ensures that > a given profile matches the supplied manifest, and have variables for the > special profiles. (These could then provide extensions to the shell > services which could arrange to pick them up) In the past we had some issues with various assumptions in guix that ~/.guix-profile was the main profile and we had to add additional use-cases for ~/.guix-home. I'm not sure if we've gotten all of them yet. It also might be helpful to consider something along the lines of exposing the symlink service bits from the home service modules and see if it would be a good idea to offer adding a symlink from ~/.guix-home/profile to ~/.guix-profile. Or (magically) adjusting ~/.guix-profile/etc/profile to also source ~/.guix-home/profile if it exists. > 3. Sometime on home reconfigure the shell prompt customizations seem to get > lost. Sourcing the shell startup file fixes it. I will have to look into > this more to file a proper bug report. > 4. Creating a guix development environment service would be beneficial, to > showcase the possibilities and to simplify onboarding. On top of there > could be an additional service that adds emacs integration to this > development environment. Also on the topic of onboarding to guix-home, the etc-skel service now also includes a bare-bones guix-home file. It lives in /etc/skel/guix-home-config.scm on Guix System. > 5. There was a recommendation to relax the expectations on the home > services merged. Right now a lot of people are just writing services for > private use. Most probably such a single usecase service would already be > beneficial to multiple people. The idea is the following: make it easy for > an initial home service to be merged. (Example: do not ask to implement > options that the submitter is not using). Then take care that if there is > an addition to the service that it really gets merged with what we already > have. This needs a bit of up front design, we have to make sure that the > services can be extended while maintaining backwards compatibility. Seeing how often we add an extra-config field for just about every other service I don't think that should be a hindrance. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Rust team branch merged
On Wed, Feb 28, 2024 at 01:53:13PM +0100, Andreas Enge wrote: > $ git status > On branch master > Your branch is behind 'origin/master' by 1438 commits, and can be > fast-forwarded. > (use "git pull" to update your local branch) > > $ git log origin/master > commit f29f80c194d0c534a92354b2bc19022a9b70ecf8 (origin/master, origin/HEAD) > Merge: c034088e37 7947d47c9b > Author: Efraim Flashner > Date: Wed Feb 28 12:18:45 2024 +0200 > Merge branch 'rust-team' > Change-Id: Iee31c5de29c357c822f60df4fa8ce758779eb349 > > Congratulations to the Rust team (aka Efraim) for this big endeavour! Thanks! This round brings rust from 1.73 to 1.75 and re-adds rust support for riscv64. We're really close on having rust support on powerpc64le but I'm fighting a bug on rust-1.73 there. For cross-compilation support, this update brings support for x86_64-linux-gnux32 and i586-pc-gnu¹ but unfortunately seems to have lost support for x86_64-w64-mingw32² in at least some circumstances. I've started working on breaking up the very large crates-io module and now we have a couple of crates modules. * Most of the packages in rust-apps have been upgraded. * rav1e was upgraded from 0.6.6 to 0.7.1 * dav1d was upgraded from 1.0.0 to 1.3.0 * libaom was upgraded from 3.5.0 to 3.8.0 * maturin was upgraded from 1.1.0 to 1.4.0 * All the rust-ring packages now rebuild their pre-generated files, although they still retain some of their vendored boringssl files. ¹ Not all crates support the Hurd yet ² There are some linking issues with the windows crates -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Packaging Hyprland
On Sat, Feb 24, 2024 at 10:32:29PM +, John Kehayias wrote: > Slightly off topic, but for anyone wondering about my emacs keys issue: > > On Sat, Feb 24, 2024 at 04:01 PM, John Kehayias wrote: > > > Seems xremap can do it (which we have packaged) except it doesn't > > pick up different applications for where keys apply on Hyprland. I > > do miss in Stump how easy that was right in the config. > > It does work! Slight difficulty since I had already set capslock to > control in my Hyprland settings (via xkb I believe). So I still had to > map capslock to control in xremap as well, and then the provided > example of emacs keybindings works (with the modification that on my > system at least it is 'emacs' (lowercase) for the application name to > make sure xremap doesn't apply there as well.) > > Guess I can continue with Hyprland! The README and Cargo.toml disagree about what commands to call, but I can add a hyprland variant of the xremap package if there's interest. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Initialization of go-team branch.
On Fri, Feb 23, 2024 at 09:44:53AM +, Sharlatan Hellseher wrote: > > Hello Guix! > > After intitiating go-team branch (inspired by the rust-team) I started > pushing reviwed patches to it, which may require a full Golang rebuild. > My future plan is to update the existing Golang ecosystem to recent > versions, as most of the packages are quite dated (2-5 years old). > > As an intial work golang-*.scm submodules are introduces and some > packages were extracted from golang.scm and placed into logical modules. > > - golang-build.scm > - golang-check.scm > - golang-compression.scm > - golang-crypto.scm > - golang-web.scm > - golang-xyz.scm > > I have CC'd Troy and Artyom as they are actively working on Golang updates. > > Following these threads: > - https://lists.gnu.org/archive/html/guix-devel/2024-02/msg00026.html > - https://lists.gnu.org/archive/html/guix-devel/2024-01/msg00128.html > > I might need some guidance on the following topics: > - Do I need to rebase to master or merge master into go-team while > working on it? In general a wip- branch is expected to be rebased and otherwise it's expected to merge. IMO for a team branch it should be expected that the team knows what's going on, but I can see how it would get confusing quickly with multiple teams. > - What is the approximate merge into master cycle? When the branch seems good then you send a patch to guix-patches with The Magic Words™¹ which will cause qa.guix.gnu.org to start building the branch, once the other team branches ahead of it are finished merging. As far as when, whenever it seems like its ready, at whatever cadence you're (as the team and/or the steward in charge of shepherding the merge through is) happy with. > - Do I need to send patches to guix-patc...@gnu.org even if I intend to > push them to the go-team branch? In general it should follow the same standard as other patches for Guix. In practice people filter for their own interests and hope someone else will take a look at any others. > After reviewing: > - #69205 [PATCH] gnu: Add go-1.22 and its standard library. > - #68300 [PATCH] gnu: Remove go-1.14. > - #69015 [PATCH 0/2] Deprecate the go-etcd-io-bbolt variable, > > I rebased on the latest master, then merged master, and finally pushed > to the go-team branch. Also can you pull in the patch from bug#67505? Thanks. ¹ I have to look up the phrasing each time. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: [RFC] proposal for refactoring bootloaders
On Fri, Feb 16, 2024 at 02:33:02AM -0600, Lilah Tascheter wrote: > one more quick change that I've realized will be necessary: add a > bootloader-targets field to boot-parameters. some bootloaders would > need target info to know where to install config files, and > reinstall-bootloader doesn't have access to the operating-system > record. rollbacks to generations pre-field addition shouldn't be an > issue with this either, as existing bootloaders (sans depthcharge?) do > just fine without targets. > > all in all, bootloader-installer and bootloader-config-file-installer > would be procedures that return gexps, with the following signatures: > > * (installer entries #:key bootcfg mount-offset generation old-entries >store-crypto-devices store-directory-prefix locale) > * (config-file-installer entries #:key package targets mount-offset >generation old-entries store-crypto-devices store-directory-prefix >locale) > > mount-offset is the current target, and old-entries becomes an alist with > generation numbers. The current bootloader system started as grub only and then grew more capabilities for other things too. It should be possible to flash u-boot separately and then use grub-efi (or something like it) but it's not currently supported out of the box. I look forward to seeing how this might look. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Debugging missing architecture support
On Thu, Feb 15, 2024 at 11:29:55AM +0100, Konrad Hinsen wrote:
> Hi Saku,
>
> > Maybe someone else can give more general or Guix specific advice on
> > finding out the cause of such problems, but I believe that in this case
> > the fix would just be packaging GHC for aarch64-linux. It should[1] be
> > possible but it will require some work.
> >
> > [1]: https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms
>
> Thanks for the pointer! It looks indeed like GHC already support
> aarch64, so it's just a matter of integrating that support into Guix.
> I'll see if I can find someone motivated and competent to do that.
I've been carrying around this diff for a while but I don't think I'm
currently ready to finish it off. It adds aarch64 and armhf bootstrap
binaries for GHC and gets started on the path to building ghc-8.6 with
them.
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm
index 62815efbb1..92ba976189 100644
--- a/gnu/packages/haskell.scm
+++ b/gnu/packages/haskell.scm
@@ -57,6 +57,7 @@ (define-module (gnu packages haskell)
#:use-module (gnu packages libffi)
#:use-module (gnu packages linux)
#:use-module (gnu packages lisp)
+ #:use-module (gnu packages llvm)
#:use-module (gnu packages m4)
#:use-module (gnu packages multiprecision)
#:use-module (gnu packages ncurses)
@@ -699,6 +852,24 @@ (define ghc-bootstrap-i686-7.8.4
(base32
"0wj5s435j0zgww70bj1d3f6wvnnpzlxwvwcyh2qv4qjq5z8j64kg"
+(define ghc-bootstrap-armhf-8.2.2
+ (origin
+(method url-fetch)
+(uri
+
"https://downloads.haskell.org/~ghc/8.2.2/ghc-8.2.2-armv7-deb8-linux.tar.xz;)
+(sha256
+ (base32
+ "1jmv8qmnh5bn324fivbwdcaj55kvw7cb2zq9pafmlmv3qwwx7s46"
+
+(define ghc-bootstrap-aarch64-8.2.2
+ (origin
+(method url-fetch)
+(uri
+
"https://downloads.haskell.org/~ghc/8.2.2/ghc-8.2.2-aarch64-deb8-linux.tar.xz;)
+(sha256
+ (base32
+ "1k2amylcp1ad67c75h1pqf7czf9m0zj1i7hdc45ghjklnfq9hrk7"
+
;; 43 tests out of 3965 fail.
;;
;; Most of them do not appear to be serious:
@@ -1057,10 +1228,115 @@ (define-public ghc-8.4
(file-pattern ".*\\.conf\\.d$")
(file-type 'directory))
+(define ghc-8.4-bootstrap
+ (package
+(inherit ghc-8.4)
+(name "ghc")
+(version "8.4.4")
+(supported-systems '("aarch64-linux" "armhf-linux"))
+(native-inputs
+ `(;("clang" ,clang)
+ ("gcc:lib" ,gcc "lib")
+ ("ghc-bootstrap" ,(if (target-aarch64?)
+ ghc-bootstrap-aarch64-8.2.2
+ ghc-bootstrap-armhf-8.2.2))
+ ("llvm" ,llvm-9)
+ ("patchelf" ,patchelf)
+ ;("ld-wrapper" ,(@ (gnu packages commencement) ld-gold-wrapper)) ; for
arm
+ ,@(filter (match-lambda
+ (("ghc-bootstrap" . _) #f)
+ (_ #t))
+ (package-native-inputs ghc-8.4
+(arguments
+ (substitute-keyword-arguments (package-arguments ghc-8.4)
+ ((#:modules _ #~%gnu-build-system-modules)
+'((guix build gnu-build-system)
+ (guix build utils)
+ (srfi srfi-26)
+ (srfi srfi-1)))
+ ((#:phases phases)
+#~(let* ((ghc-bootstrap-path
+ (string-append (getcwd) "/" #$name "-" #$version
"/ghc-bin"))
+ (ghc-bootstrap-prefix
+ (string-append ghc-bootstrap-path "/usr")))
+(modify-phases #$phases
+ (add-after 'unpack 'unpack-bin
+(lambda* (#:key inputs #:allow-other-keys)
+ (mkdir-p ghc-bootstrap-prefix)
+ (with-directory-excursion ghc-bootstrap-path
+(invoke "tar" "xvf" (assoc-ref inputs "ghc-bootstrap")
+ (add-before 'configure 'install-bin
+(lambda _
+ (with-directory-excursion
+(string-append ghc-bootstrap-path "/ghc-8.2.2")
+(invoke "make" "install"
+ (add-before 'install-bin 'configure-bin
+(lambda* (#:key inputs outputs #:allow-other-keys)
+ (let* ((binaries
+ (list "ghc/stage2/build/tmp/ghc-stage2"
+ "iserv/stage2/build/tmp/ghc-iserv"
+ "iserv/stage2_dyn/build/tmp/ghc-iserv-dyn"
+ "iser
Re: Debugging missing architecture support
On Wed, Feb 14, 2024 at 02:26:46PM +0100, Konrad Hinsen wrote:
> Hi Guix experts,
>
> in trying to build a Docker image for ARM64 (aarch64-linux), I am
> hitting errors of the kind
>
> "package git-annex@10.20230926 does not support aarch64-linux"
>
> There doesn't seem to be anything specifically in the package
> definitions that precludes building for aarch64-linux, so I suspect it's
> either a dependency or the build system that lacks the required support.
>
> How would I go about debugging such issues? Maybe the causes are simple
> and I can fix them. But I don't even know where to start.
Currently GHC is only supported on i686 and x86_64.
(use-modules (gnu packages)(guix packages))
(supported-package? (specification->package "git-annex"))
$1 = ("x86_64-linux" "i686-linux")
As far as tracking back from git-annex to ghc to see that it's not
supported on aarch64, I'm not sure how you would find that information.
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
Re: %base-packages and default grub theme depend on rust
On Mon, Jan 29, 2024 at 05:36:52PM +0100, Ludovic Courtès wrote: > Hi, > > Vagrant Cascadian skribis: > > > This is because the default grub theme generates a .png from an .svg > > ... using guile-rsvg, which uses librsvg, which uses rust ... > > How about using a guile-rsvg variant that depends on ‘librsvg-2.40’, the > last version written in C? > > That’s easy to do and would address the immediate problem. I bet we could switch it to use guile-cairo. Also, is guile-png too low level? -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
patch workflow without emacs (Was: Re: Guix Days: Patch flow discussion)
On Mon, Feb 05, 2024 at 10:50:36PM +, Steve George wrote:
> Hi Hartmut,
>
> Apologies, my reply-to went a bit mad and I sent you empty emails :-(
>
> You said:
>
> > The current mail-based workflow is too complicated for new and
> > occasional committers. This is the main reason I gave up reviewing patches.
> >
>
> In the case of *reviewing patches* can you give some examples of:
>
> 1. Some patches from others you reviewed?
> 2. The steps you went through to undertake that review?
>
> If for example, you started to review a simple update to a package how do you
> aproach it?
>
> It would be great to hear directly from someone doing 'reviewing' on the
> specifics. Apologies, if this is going over old ground.
First step is choosing a package to review. I normally start with ones
that are emailed to me directly as part of the rust-team.
I now have an email thread with between 20 and 150 patches to review. (I
start by looking through some of them manually to see if they look like
they're following conventions, ie: 1 change per patch. Assuming they
generally look good,) I start with the first patch and, from mutt, I
pipe the patch to 'cd ~/workspace/guix; git am -S -s'. I then compare
the commit message to the contents of the patch, looking at it in 'tig',
a TUI git interface, and will adjust the patch and/or the commit message
as necessary. Then I try to build the package(s) changed by the patch
set so far. When I'm happy with how it looks I'll pipe the next patch
from mutt to check out.
Once I reach the end of a patch series, or after a bunch of patches,
I'll look through the set I've applied to make sure I'm still happy with
them as a whole (update the package and then remove it?) and then
continue on. At the end, when I'm happy with it, I'll reply to the
first or last email, detail a bit what changes I've made, and tell them
that I've applied the patches. I then save the email in my drafts folder
and move on to the next patch series I'm going to look at. At the end,
after rebasing everything on top of wherever the branch moved to while I
was working, I'll push my branch to Savannah and then send off the
emails.
If I come across a patch that I'd like changes to before committing I'll
either add them inline ('v' in mutt to see the parts of the email,
choose the part with the patch, 'g' to reply-all, and then add them
inline), or I'll apply it and then reply to the original email with the
diff ('git diff -p > ~/changes-to-.diff', attach in reply email) and
some text in the header about the changes. I then throw out my local
changes since they're either where I can recover it from the email or in
my git stash.
If I choose a package from qa.guix.gnu.org to review I'll pick one and
note the number. I go to my checkout, 'git fetch --all' to refresh my
checkouts¹, open it with tig, switch to the branches view (with 'r'),
find the patchset (guix-patches/issue-X), and then with 'C' I'll
cherry-pick all the patches from the patchset in one go. I then look
them over one at at time in tig like above, and I'll make any changes to
either 'squash' or 'fixup' onto specific patches later when I go over it
with 'git rebase -i'.
Some notes: I've never figured out how to use emacs, much less emacs and
debbugs. My only interaction with debbugs is to open or close bugs; I
do not know how to look at user tags, or any other tags, in debbugs,
although I would guess that it might be possible from the web frontend.
Similarly, I don't know if a bug has been closed by someone else, I just
assume it to be so when a patch is applied or if I see it said so in an
email. I use vim-fugitive (and editorconfig I guess) as my only plugin
for working with git.
¹ https://git.guix-patches.cbaines.net/git/guix-patches is the location
where the patchsets are stored in a git repo
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
Re: [post Guix Days] Guix Common Document (was: Request-For-Comment process)
On Sat, Feb 03, 2024 at 11:34:13AM +0100, Simon Tournier wrote: > Hi all, > > I hope that the discussion we had yesterday (Friday 2nd) in Guix Days > has clarified the idea behind this proposal. > > I am waiting Ludo’s notes in order to refine this proposal, integrate > many comments and/or ideas, and polish. > > Thanks all participants. > > > The aim of the proposal is to have a process to document our processes > with the least bureaucracy as possible. Well, Debian project is often > cited as an example (social contract, voting system, etc.). Indeed, > however there is more bureaucracy in Debian than in French State. ;-) > > Instead, let just formalize what we are already doing. > > Currently, we are just adding more and more sections to the manual and > for other parts the structure for making decisions is not clear. For > sure, it works… until now but I think it does not scale and we are > touching the limits about what can be done with this informal structure. > > Let me clarify my attempt behind this “RFC proposal”. First, > pukkamustard proposed the name “Guix Common Document” echoing “greatest > common divisor“ (gcd): the greatest common divisor of two or more > integers is the largest positive integer that divides each of the > integers – other said, that’s the larger integer in common with all. > > I like it because it captures well the idea; although such different > name could be confusing from the outside. Anyway. That’s an > implementation detail. ;-) > > Second, from my point of view, the core components of the proposal are: > > + consensus; > + co-supporter. > > Consensus, because it is how we already collaborate. Somehow, it > changes almost nothing for our daily operations but having an explicit > formalization will help outsiders. The definition of “consensus” is > twofold: > > 1. can live with; > 2. concerns are actively resolved. > > Other said, the definition wording of “consensus” specifies how to avoid > being blocked by disagreements: when one wish to block a proposal then > one bears a special responsibility for finding alternatives, proposing > ideas/code or explaining the rationale for the status quo. > > And to make it clear, the first idea for making decision is “voting” but > then we need to define “who” votes. Well, this appears to me a > counter-measure against something that would be rare and this solution > does not trust in the values of our community (being welcoming, > inclusive, taking care of each other, etc. well as least, trying as much > as possible :-)). > > For me, the counter-measure against an hostile takeover is somehow > captured the point #2 above. > > > Co-supporter, because similarly as the manual section « (guix) Reviewing > the Work of Others » [1], the aim is to cross the final line, make > progress by incremental focused improvements. Therefore, a proposal > needs the help of someone committed to the project (long-standing > contributor, committer, etc.). > > I agree that “contributor sufficiently familiar” is maybe too vague and > needs more specific examples as “contributor sufficiently familiar > (committers or people with X commits)”. Well, that’s part refining the > proposal. :-) For this part I think that for 'contributor sufficiently familiar' can be interpreted as someone sufficiently familiar with Guix, the coding standards, etc., and it could also be interpreted as someone sufficiently familiar with the subject matter being proposed. For example, I don't know about AVR chips or programming them or knowing what to do with them, but I can review the code submitted to make sure it doesn't break other functionality already included in Guix and rely on others telling me that they've tested out the code and it works with their chips. > Last, I think that the time-frame for discussing needs to be bounded. > Somehow this bound will help in the incremental improvement and will > avoid the trap of the perfect-as-the-first-try. > > > Well, let recover from these awesome Guix Days and from FOSDEM and then > resume this proposal. > > Cheers, > simon > > 1: https://guix.gnu.org/manual/devel/en/guix.html#Reviewing-the-Work-of-Others > -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Git-LFS or Git Annex?
On Wed, Jan 24, 2024 at 04:22:05PM +0100, Ludovic Courtès wrote: > Hello! > > I’m looking for ways to incorporate videos into the repositories of our > web sites so they’re content-addressed and properly tracked, and to make > it easier to create backups (right now those videos are stored on our > two main servers and rsynced between them⁰; I’m talking about the videos > at guix.gnu.org, 10years.guix.gnu.org, and hpc.guix.info). > > The question boils down to: Git-LFS or Git Annex? > > From a quick look (I haven’t used them), Git-LFS seems to assume a > rather centralized model where there’s an LFS server sitting next to the > Git server¹. Git Annex looks more decentralized, allowing you to have > several “remotes”, to check the status of each one, to sync them, etc.² > Because of this, Git Annex seems to be a better fit. > > Data point: guix.gnu.org source is hosted on Savannah, which doesn’t > support Git-LFS; the two other web sites above are hosted on GitLab > instances, which I think do support Git-LFS. > > What’s your experience? What would you suggest? I'll respond off the first email because I lost where I was thinking of responding to. One git annex repository that I sometimes visit is the conference_proceedings¹ repository, which has many years worth of conference videos. With such a repo you wouldn't actually run `git annex sync`, you'd `git pull` as desired, run `git annex get path/to/the/video`, watch the video, and then `git annex drop path/to/the/video`. Last I checked there's even tie-in scripts for some file managers like thunar. I actually use git-annex with my family's photos and videos, with a full master copy at my place and one at my parent's place, and a couple of remotes on the internet. $ git annex whereis Wedding.iso whereis Wedding.iso (5 copies) 00f742bc-02d6-4b05-853a-7703f87b29f9 -- efraim@debian:~/workspace/Flashner_Backup [ct-tor] 47c3cd13-68d9-43f7-b8a7-e742dccce3be -- [scaleway] 66babe8f-d716-4502-844f-06645eda3b23 -- efraim@raspberrypi:/media/Elements/efraim/Flashner_Backup c8898bb8-da93-4507-87c2-5496241b5dc6 -- efraim@3900XT:~/workspace/Flashner_Backup [here] d22b8903-9e94-47f3-8e8a-ef1468e478e3 -- cloud [amazon] ok The ISO is encrypted with my GPG key. For this repo I do just run `git annex sync` because it's really only me interacting with it, and I don't care about how awful the git history looks. In our Guix video option, we could upload the actual videos to, say, archive.org or to audiovideo.gnu.org (or whatever the site is) and then add the video as a remote `git annex addurl https://path/to/the/video` and it'll just be available in the repo. ¹ https://github.com/RichiH/conference_proceedings -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: [core-updates] Native build of make-boot0 fails on missing zstd
sts/scripts/options/dash-W
> make-4.4.1/tests/scripts/options/dash-d
> make-4.4.1/tests/scripts/options/dash-e
> make-4.4.1/tests/scripts/options/dash-f
> make-4.4.1/tests/scripts/options/dash-k
> make-4.4.1/tests/scripts/options/dash-l
> make-4.4.1/tests/scripts/options/dash-n
> make-4.4.1/tests/scripts/options/dash-q
> make-4.4.1/tests/scripts/options/dash-r
> make-4.4.1/tests/scripts/options/dash-s
> make-4.4.1/tests/scripts/options/dash-t
> make-4.4.1/tests/scripts/options/eval
> make-4.4.1/tests/scripts/options/general
> make-4.4.1/tests/scripts/options/print-directory
> make-4.4.1/tests/scripts/options/shuffle
> make-4.4.1/tests/scripts/options/symlinks
> make-4.4.1/tests/scripts/options/warn-undefined-variables
> make-4.4.1/tests/scripts/targets/
> make-4.4.1/tests/scripts/targets/DEFAULT
> make-4.4.1/tests/scripts/targets/DELETE_ON_ERROR
> make-4.4.1/tests/scripts/targets/FORCE
> make-4.4.1/tests/scripts/targets/INTERMEDIATE
> make-4.4.1/tests/scripts/targets/NOTINTERMEDIATE
> make-4.4.1/tests/scripts/targets/ONESHELL
> make-4.4.1/tests/scripts/targets/PHONY
> make-4.4.1/tests/scripts/targets/POSIX
> make-4.4.1/tests/scripts/targets/SECONDARY
> make-4.4.1/tests/scripts/targets/SILENT
> make-4.4.1/tests/scripts/targets/WAIT
> make-4.4.1/tests/scripts/targets/clean
> make-4.4.1/tests/scripts/test_template
> make-4.4.1/tests/scripts/variables/
> make-4.4.1/tests/scripts/variables/CURDIR
> make-4.4.1/tests/scripts/variables/DEFAULT_GOAL
> make-4.4.1/tests/scripts/variables/EXTRA_PREREQS
> make-4.4.1/tests/scripts/variables/GNUMAKEFLAGS
> make-4.4.1/tests/scripts/variables/INCLUDE_DIRS
> make-4.4.1/tests/scripts/variables/LIBPATTERNS
> make-4.4.1/tests/scripts/variables/MAKE
> make-4.4.1/tests/scripts/variables/MAKECMDGOALS
> make-4.4.1/tests/scripts/variables/MAKEFILES
> make-4.4.1/tests/scripts/variables/MAKEFLAGS
> make-4.4.1/tests/scripts/variables/MAKELEVEL
> make-4.4.1/tests/scripts/variables/MAKE_RESTARTS
> make-4.4.1/tests/scripts/variables/MFILE_LIST
> make-4.4.1/tests/scripts/variables/SHELL
> make-4.4.1/tests/scripts/variables/automatic
> make-4.4.1/tests/scripts/variables/define
> make-4.4.1/tests/scripts/variables/flavors
> make-4.4.1/tests/scripts/variables/negative
> make-4.4.1/tests/scripts/variables/private
> make-4.4.1/tests/scripts/variables/special
> make-4.4.1/tests/scripts/variables/undefine
> make-4.4.1/tests/scripts/vms/
> make-4.4.1/tests/scripts/vms/library
> make-4.4.1/tests/test_driver.pl
> make-4.4.1/tests/thelp.pl
> make-4.4.1/vms_export_symbol_test.com
> source is at 'make-4.4.1'
> applying
> '/gnu/store/ycrzxjd2rpmcmhvn1mbfxrygsk4xsn1v-make-impure-dirs.patch'...
> patching file src/read.c
> Hunk #1 succeeded at 111 with fuzz 2 (offset 12 lines).
> patching file src/remake.c
> Hunk #1 succeeded at 1690 with fuzz 1 (offset 238 lines).
> /gnu/store/sb4x78r4d5l8833nmrml4b823irf954h-bootstrap-binaries-0/bin/tar:
> Option --mtime: Treating date '@1' as 1970-01-01 01:00:01
> make-4.4.1/
> make-4.4.1/ABOUT-NLS
> sh: zstd: command not found
> /gnu/store/sb4x78r4d5l8833nmrml4b823irf954h-bootstrap-binaries-0/bin/tar:
> /gnu/store/wflsiizcin3s61qyjw4flkdg2s8mg3vz-make-4.4.1.tar.zst: Wrote only
> 6144 of 10240 bytes
> /gnu/store/sb4x78r4d5l8833nmrml4b823irf954h-bootstrap-binaries-0/bin/tar:
> Child returned status 127
> /gnu/store/sb4x78r4d5l8833nmrml4b823irf954h-bootstrap-binaries-0/bin/tar:
> Error is not recoverable: exiting now
> Backtrace:
> In ice-9/boot-9.scm:
> 160: 9 [catch #t # ...]
> In unknown file:
>?: 8 [apply-smob/1 #]
> In ice-9/boot-9.scm:
> 66: 7 [call-with-prompt prompt0 ...]
> In ice-9/eval.scm:
> 432: 6 [eval # #]
> In ice-9/boot-9.scm:
> 2412: 5 [save-module-excursion # ()>]
> 4089: 4 [#]
> 1734: 3 [%start-stack load-stack # ice-9/boot-9.scm:4080:10 ()>]
> 1739: 2 [#]
> In unknown file:
>?: 1 [primitive-load
> "/gnu/store/a32wg40bisgx0n5c4rga3nffljq90mqn-make-4.4.1.tar.zst-builder"]
> In guix/build/utils.scm:
> 816: 0 [invoke
> "/gnu/store/sb4x78r4d5l8833nmrml4b823irf954h-bootstrap-binaries-0/bin/tar"
> ...]
>
> guix/build/utils.scm:816:6: In procedure invoke:
> guix/build/utils.scm:816:6: Throw to key `srfi-34' with args `(# [program:
> "/gnu/store/sb4x78r4d5l8833nmrml4b823irf954h-bootstrap-binaries-0/bin/tar"
> arguments: ("cvfa"
> "/gnu/store/wflsiizcin3s61qyjw4flkdg2s8mg3vz-make-4.4.1.tar.zst" "--mtime=@1"
> "--owner=root:0" "--group=root:0" "--sort=name" "make-4.4.1") exit-status: 2
> term-signal: #f stop-signal: #f] 61b780>)'.
> builder for
> `/gnu/store/g17dphzhaw5c7lbxjr1ixvk0krrgmrr3-make-4.4.1.tar.zst.drv' failed
> with exit code 1
> @ build-failed
> /gnu/store/g17dphzhaw5c7lbxjr1ixvk0krrgmrr3-make-4.4.1.tar.zst.drv - 1
> builder for
> `/gnu/store/g17dphzhaw5c7lbxjr1ixvk0krrgmrr3-make-4.4.1.tar.zst.drv' failed
> with exit code 1
> derivation
> '/gnu/store/g17dphzhaw5c7lbxjr1ixvk0krrgmrr3-make-4.4.1.tar.zst.drv'
> offloaded to 'kluit.dezyne.org' failed: build of
> `/gnu/store/g17dphzhaw5c7lbxjr1ixvk0krrgmrr3-make-4.4.1.tar.zst.drv' failed
> build of /gnu/store/g17dphzhaw5c7lbxjr1ixvk0krrgmrr3-make-4.4.1.tar.zst.drv
> failed
> View build log at
> '/var/log/guix/drvs/g1/7dphzhaw5c7lbxjr1ixvk0krrgmrr3-make-4.4.1.tar.zst.drv.gz'.
> cannot build derivation
> `/gnu/store/zbp7rf2qm32qb2mq0w67pnn973892d3w-make-boot0-4.4.1.drv': 1
> dependencies couldn't be built
> guix build: error: build of
> `/gnu/store/zbp7rf2qm32qb2mq0w67pnn973892d3w-make-boot0-4.4.1.drv' failed
> [1]10:22:08 janneke@drakenpad:~/src/guix/core-updates
> $
> --8<---cut here---end--->8---
>
> --
> Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org
> Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
>
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
Re: How to always keep build tree when run guix build.
On Wed, Jan 17, 2024 at 04:21:05PM +0800, Adam Faiz wrote: > Hello, > > > Hello: > > > > How to always keep build tree when run guix build, at the moment, I > > use --keep-failed, but it will remove build tree when build success, the > > problem is that build success alway not right build success :-), I need > > go to build tree to check some thing. > > > > Thanks! > > > > > > -- > > You can add the `--cache-failures` option when starting the guix-daemon, > which tells it to keep the build failures by default. > It's explained in more detail in the "Invoking guix-daemon" section of the > Guix manual: > https://guix.gnu.org/en/manual/devel/en/html_node/Invoking-guix_002ddaemon.html '--cache-failures' keeps track of build failures and then refuses to build that derivation again if it's already known to fail. I don't think there's something like '--keep-failed' for guix-daemon. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Guix CLI, thoughts and suggestions
All commands should be organized into a tree of verbs. > > Verbs should have common aliases (`rm' for `remove', etc). > > Verbs should be selected by specifying the minimum unambiguous substring. > For example `guix sys gen sw' could refer to `guix system generation > switch'. > > Options should be applicable to each level of the tree, ex `guix > -L~/src/my-channel' would add that load-path, which would be visible to any > command. > > Requesting help is a verb. Appending "help" to any level of the verb tree > should show both options applicable to that verb, and its child verbs. > `guix help' would show global options and all top-level verbs (package, > system, generation, etc); `guix package help' would show package-specific > options and package-specific verbs; and so on. > > > Conclusion > == > > I have no idea if anyone feels similarly about this, or whether there’s > appetite to change the CLI, but I think it’d be time well-spent. Having > some kind of agreed-upon standard for how the CLI stuff is organized seems > like a good thing to me, even if it just stops or slows the addition of more > commands with unique expressions. > > It seems like a lot of work to change, and backwards compatibility also is > an issue. One option I could see working is shoving the entire existing > structure under a command in the new tool, so you could do `guix old package > -I' or similar. An alternate approach would be using an environment > variable to change behaviors. > > What do you all think? This is probably the most well written critique I've seen on the layout of the CLI for Guix. I think it would be worthwhile to mock-up a 'guix profile' command to see how it would look. I'm going to add it as a possible topic for Guix Days just before FOSDEM and see if we can create something that makes more sense. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: An update on ‘core-updates’
On Thu, Jan 11, 2024 at 04:10:14PM +0100, Ludovic Courtès wrote: > Hello Guix! > > Several of us have been fiddling with the ‘core-updates’ branch for a > while. I think there’s now consensus that the branch is really > dedicated to core packages and (guix build …) modules, as embodied in > the new ‘core-packages’ team¹. > > We’ve updated GCC 11.x, glibc, binutils, and various packages from (gnu > packages base). Notable exceptions are Coreutils, Findutils, sed, and > tar; I tried but that’s a bit more work, notably because their variants > in commencement.scm would no longer build because their build scripts > use sed patterns not supported by Gash-Utils. > > Long story short: I’d like us to freeze and merge the branch ASAP, > notably because the glibc graft on ‘master’ leads to a bad user > experience. I’m happy with the current state of the branch and wouldn’t > mind postponing remaining upgrades for the next cycle. > > Thoughts? > > Remaining work includes: checking that cross-compilation targets still > work after the recent Binutils updates, checking i586-gnu (GNU/Hurd) and > other platforms, and possibly addressing the Gawk non-determinism > issue². > > Currently package subsets are built here: > > https://ci.guix.gnu.org/jobset/core-updates > https://guix.bordeaux.inria.fr/jobset/guix-core-updates > > I don’t think I can commit to coordinating the stabilization effort > though as I’m busy with other things this month. Would anyone like to > take the lead on this? > > Happy updating! > > Ludo’. > > ¹ https://issues.guix.gnu.org/67880 > ² https://issues.guix.gnu.org/68378 There's a patch floating around somewhere to adjust the page size on jemalloc on aarch64 to be at least 64k so that people running guix software on apple silicon don't have issues. I think we should add it for core-updates so it doesn't get forgotten, I've seen it come up on IRC at least once a week. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: An update on ‘core-updates’
On Fri, Jan 12, 2024 at 01:55:47PM +0100, Janneke Nieuwenhuizen wrote:
> Ludovic Courtès writes:
>
> Hi!
>
> > We’ve updated GCC 11.x, glibc, binutils, and various packages from (gnu
> > packages base). Notable exceptions are Coreutils, Findutils, sed, and
> > tar; I tried but that’s a bit more work, notably because their variants
> > in commencement.scm would no longer build because their build scripts
> > use sed patterns not supported by Gash-Utils.
>
> CC'ing Ekaitz and I'll also relay this to #guix-risc-v. There's quite
> some work going on in commencement, we can probably incorporate these.
>
> I think a possible workaround was suggested by Timothy
>
> https://lists.gnu.org/archive/html/gash-devel/2023-09/msg2.html
The update to stage0-posix, mes-boot and tcc-boot0 are now in
core-updates, and I didn't see any regressions on x86_64/i686.
> > Long story short: I’d like us to freeze and merge the branch ASAP,
> > notably because the glibc graft on ‘master’ leads to a bad user
> > experience. I’m happy with the current state of the branch and wouldn’t
> > mind postponing remaining upgrades for the next cycle.
> >
> > Thoughts?
>
> FWIW, I'm all for this. The longer we wait, the harder it gets? As
> soon as everything works, see below...
Currently there's an issue on riscv64/ppc64le (and maybe others?) about
zstd not being available for patch-and-repack for make-boot0 and
perl-boot0 (and probably others).
> > Remaining work includes: checking that cross-compilation targets still
> > work after the recent Binutils updates, checking i586-gnu (GNU/Hurd) and
> > other platforms, and possibly addressing the Gawk non-determinism
> > issue².
>
> Building a bare-hurd system on core-updates succeeded "not long ago"
> (after the glibc+locales patch series I think) but now fails on
> gcc-cross-sans-libc-i586-pc-gnu-11.4.0
>
> --8<---cut here---start->8---
> Configuring in i586-pc-gnu/libobjc
> [..]
> checking dynamic linker characteristics... configure: error: Link tests are
> not allowed after GCC_NO_EXECUTABLES.
> [..]
> builder for
> `/gnu/store/94lj8490ixpd997m3siaxw5yhd52za6g-gcc-cross-sans-libc-i586-pc-gnu-11.4.0.drv'
> failed with exit code 1
> --8<---cut here---end--->8---
>
> Any ideas what may have happened/changed here? Hmm, it looks like
>
> d21d596f72ad491937123980e65d3efedc903bd6
> gnu: gcc: Support objc, objc++ by default.
>
> was probably the problem. Trying the attached patch, Hurd system not
> build yet.
you might need ,@(if (target-hurd?)
my debugging trick is to make the changes and then check the "else" case
to see if it's changed anything there. Since it looks like you're not
trying to change the flags for other architectures the derivation
shouldn't change if you've gotten the rest of the patch correct :)
> Greetings,
> Janneke
>
> From 0e1bf5714261de8f25baabca3b826284102b6c40 Mon Sep 17 00:00:00 2001
> Message-ID:
> <0e1bf5714261de8f25baabca3b826284102b6c40.1705062924.git.jann...@gnu.org>
> From: Janneke Nieuwenhuizen
> Date: Fri, 12 Jan 2024 13:24:14 +0100
> Subject: [PATCH] gnu: gcc: Fix building cross compiler for the Hurd.
>
> This is a follow-up to commit
> d21d596f72ad491937123980e65d3efedc903bd6
> gnu: gcc: Support objc, objc++ by default.
>
> * gnu/packages/gcc.scm (gcc-4.7): Only build c,c++ when building for the Hurd.
>
> Change-Id: I21ce5dd30d7ab253e6a46173eb674b55d6c01505
> ---
> gnu/packages/gcc.scm | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
> index ecd88931eb..111b096185 100644
> --- a/gnu/packages/gcc.scm
> +++ b/gnu/packages/gcc.scm
> @@ -15,6 +15,7 @@
> ;;; Copyright © 2022 Greg Hogan
> ;;; Copyright © 2023 Bruno Victal
> ;;; Copyright © 2023 Maxim Cournoyer
> +;;; Copyright © 2024 Janneke Nieuwenhuizen
> ;;;
> ;;; This file is part of GNU Guix.
> ;;;
> @@ -132,9 +133,11 @@ (define-public gcc-4.7
> ;; contents of (maybe-target-tools).
> (list 'quasiquote
>(append
> - '("--enable-plugin"
> - "--enable-languages=c,c++,objc,obj-c++"
> - "--disable-multilib"
> + '("--enable-plugin")
> + (if (target-hurd?)
> + '("--enable-languages=c,c++")
> + '("--enable-languages=c,c++,objc,obj-c++"))
> + '("--disable-multilib"
>
Re: Commit Access: Sharlatan Hellseher
On Fri, Jan 12, 2024 at 05:21:51PM +0100, Clément Lassieur wrote: > On Thu, Jan 11 2024, Sharlatan Hellseher wrote: > > > Hi Guix! > > > > I am happy to have been granted commit access and I am ready to help > > review pending issues and prepare queued packages for GNU packages in > > astronomy. I would like to concentrate on the packages covered by the > > Go, Lisp, Python, and Science teams. > > > > I would like to thank the Guix team for allowing me to become a > > committer member. I am looking forward to continuing our collaboration. > > > > If anyone has a good patch review workflow using Emacs, Gnus, and Magit, > > I would appreciate it ;-) > > Hey, welcome. > > I use this Emacs code to apply patches, with emacs-debbugs and Gnus. > > --8<---cut here---start->8--- > (defun my-apply-patch-or-abort () > (interactive) > (my-apply-patch-internal "git am || git am --abort")) > > (defun my-apply-patch () > (interactive) > (my-apply-patch-internal "git am --reject")) > > (defun my-apply-patch-or-abort-attachment (n) > (interactive "P") > (my-apply-patch-attachment-internal "git am || git am --abort" n)) > > (defun my-apply-patch-attachment (n) > (interactive "P") > (my-apply-patch-attachment-internal "git am --reject" n)) > > (defun my-apply-patch-attachment-internal (cmd n) > "C-u M-x my-apply-..." > (let ((git-dir "~/src/guix")) > (save-window-excursion > (gnus-article-part-wrapper >n >(lambda (handle) > (let ((default-directory git-dir)) >(mm-pipe-part handle cmd))) > > (defun my-apply-patch-internal (cmd) > "Works with a selection of articles." > (let ((git-dir "~/src/guix") > (articles (gnus-summary-work-articles nil))) > (save-window-excursion > (while articles > (gnus-summary-goto-subject (pop articles)) > (with-current-buffer gnus-summary-buffer > (let ((default-directory git-dir)) > (gnus-summary-save-in-pipe cmd)) > (gnus-article-hide-headers)) > --8<---cut here---end--->8--- > > Just my 2 cents, I imagine every person here has their own workflow. I'm going to suggest 'git am -3' that someone else here suggested to me. When a patch fails to apply cleanly git will try harder and leave the failed-to-apply bits inside the code, making it easier to clean-up the patch than to manually apply it. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Proposition to streamline our NAR collection to just zstd-compressed ones
On Wed, Jan 10, 2024 at 12:36:51PM +0100, Ludovic Courtès wrote:
> Hello,
>
> Maxim Cournoyer skribis:
>
> > It's been on my head for quite a bit of time (about 2 years, according
> > to [0]), to streamline our offering of cached nars. Letting go of gzip
> > 2 years ago, along a more aggressive garbage collection policy allowed
> > us to reduce our storage needs by at least 6.5 TiB. I'm proposing to do
> > the same with our lzip compressed nars, to let go of an additional 3.9
> > TiB:
>
> Those space savings would be welcome.
>
> > The above suggests that zstd compressed nars are about 5% larger than
> > the lzip ones, which is not big enough to justify carrying both, in my
> > opinion. In exchange for a little bit more bandwidth, users would have
> > the nars decompressed much faster with less CPU overhead locally.
>
> The difference is slightly higher, with lzip being 8% smaller, for a big
> package like ungoogled-chromium or icecat:
>
> --8<---cut here---start->8---
> $ wget -qO-
> https://ci.guix.gnu.org/7n95j1zlnwzc44azjs7nj8givnzdfs87.narinfo|grep -B1
> ^FileSize
> Compression: lzip
> FileSize: 85783483
> --
> Compression: zstd
> FileSize: 92796393
> $ wget -qO-
> https://ci.guix.gnu.org/prpjnnnhay0alanmkgjh66vfwjlb98kq.narinfo|grep -B1
> ^FileSize
> Compression: lzip
> FileSize: 295991
> --
> Compression: zstd
> FileSize: 323456
> --8<---cut here---end--->8---
>
> But yeah, even though adaptive compression selection on the client is a
> minor improvement, whether it warrants the extra space is debatable.
There's another zstd flag that we should probably add: --rsyncable.
--rsyncable: zstd will periodically synchronize the compression state to
make the compressed file more rsync-friendly. There is a negligible
impact to compression ratio, and a potential impact to compression
speed, perceptible at higher speeds, for example when combining
--rsyncable with many parallel worker threads. This feature does
not work with --single-thread. You probably don´t want to use it with
long range mode, since it will decrease the effectiveness of the
synchronization points, but your mileage may vary.
> > What do you think? Should we go ahead and effect the following simple
> > change for the Berlin build farm?
> >
> > modified hydra/modules/sysadmin/services.scm
> > @@ -683,7 +683,7 @@ to a selected directory.")
> > ;;
> > <https://lists.gnu.org/archive/html/guix-devel/2021-01/msg00097.html>
> > ;; for the compression ratio/decompression speed
> > ;; tradeoffs.
> > - (compression '(("lzip" 9) ("zstd" 19)))
> > + (compression '(("zstd" 19)))
>
> No objection from me, but…
>
> … an important consideration: zstd support was added in 1.3.0, released
> in May 2021.
>
> From experience we know that users on foreign distros rarely, if ever,
> upgrade the daemon (on top of that, upgrading the daemon is non-trivial
> to someone who initially installed the Debian package, from what I’ve
> seen, because one needs to fiddle with the .service file to adjust file
> names and the likes), and we can be sure that many are still running an
> old daemon. We spent a lot of time on user support after gzip
> substitutes had been removed (‘guix substitute’ would just crash) and we
> must avoid that.
>
> (guix store) emits a warning when connecting to an “old” daemon, but
> only for daemons older than 2018. We could emit a warning based on
> whether or not “builtin:git-download” is available, but maybe that’s too
> early?
builtin:git-download sometimes bites me on my machines since I don't
upgrade my aarch64/riscv64 installs that often.
Also, 2018 is now about 5 years ago. It might be a good idea to just
have a rolling YEAR-3 warning that the daemon is getting old and they
might be missing out on features present in newer daemon versions.
> In addition to the warning, we should communicate in advance and make
> sure our instructions on how to upgrade the daemon are accurate and
> clear.
>
> Thoughts?
>
> Ludo’.
>
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
Re: Performance of computing cross derivations
On Thu, Jan 11, 2024 at 01:26:35PM +, Christopher Baines wrote: > > Ludovic Courtès writes: > > > Christopher Baines skribis: > > > >> I think you're right, while I send some other changes in #68266, I think > >> it's this change around make-rust-sysroot that has pretty much all the > >> effects on performance. > >> > >> I think the tens of thousands of duplicated packages from cross-base > >> that I was looking at are almost entirely coming from > >> make-rust-sysroot. As Ludo mentions in [1], maybe this has something to > >> do with use of cross- procedures in native-inputs, although I'm not sure > >> that moving those calls out of native-inputs is a correct thing to do. > >> > >> I don't know what the correct approach here is, but I think something > >> needs doing here to address the performance regression. > > > > I probably missed it in the thread: what commit caused the regression, > > and how can I test any changes? I’m willing to help but I missed some > > of the context. > > It's not a pure performance regression, more that in it's current form, > rust cross derivations are very expensive to compute. It's been this way > since cross-compiling was enabled in [1]. > > 1: > https://git.savannah.gnu.org/cgit/guix.git/patch/?id=e604972d9c697302691aeb22e9c50c933a1a3c72 > > I've been looking at data service slowness in processing revisions over > the last few weeks, and I think it's mostly down to this. Looking at the > revision prior to the change [2], computing all the derivations took > around 3 hours, which is ages, but still quick compared to the nearly 9 > hours it took after this change [3]. > > 2: https://data.guix.gnu.org/revision/58bbb38c5bd2e42aab9e9408d8c9d8da3409f178 > 3: https://data.guix.gnu.org/revision/c9e1a72cc27925484635ae01bc4de28bf232689d > > Obviously having more derivations is good and that usually means more > work for the data service, but in this case it seems like things can be > sped up quite a bit. > > For testing locally, I've been computing all the derivations for > i586-pc-gnu, but Efraim also posted a concise command to look at > computing some cross derivations for a subset of rust packages [4]. > > 4: https://lists.gnu.org/archive/html/guix-devel/2024-01/msg00053.html list-all-cargo-build-system-packages is actually a script I have locally that I should probably put in the etc/teams/rust folder. I've attached it in case anyone wants to try it out, or see the speed-up of computing the cross-derivations. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted guile -c '(use-modules (gnu packages)(guix packages)(guix build-system)) (display (fold-packages (lambda (package lst) (if (eq? (build-system-name (package-build-system package)) (quote cargo)) (cons package lst) lst)) (list)))' | tr ' ' '\n' | grep \@ signature.asc Description: PGP signature
Re: Welcome Oleg (sharlatan) as a new committer
On Tue, Jan 09, 2024 at 11:19:51PM -0500, Maxim Cournoyer wrote: > Hello Guix! > > I'm happy to start the 2024 year with a new committer onboard: Sharlatan > (Oleg). > > Sharlatan is maintaining a growing collection of astronomy packages in > Guix, among others. > > Let's Wish them a warm welcome! Welcome! -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Performance of computing cross derivations
On Fri, Jan 05, 2024 at 04:41:14PM +, Christopher Baines wrote: > > Ludovic Courtès writes: > > > Hi, > > > > Christopher Baines skribis: > > > >> When asked by the data service, it seems to take Guix around 3 minutes > >> to compute cross derivations for all packages (to a single > >> target). Here's a simple script that replicates this: > > ... > > > One idiom that defeats caching is: > > > > (define (make-me-a-package x y z) > > (package > > …)) > > > > Such a procedure returns a fresh package every time it’s called, > > preventing caching from happening (because cache entries are compared > > with ‘eq?’). That typically leads to lower hit rates. > > > > Anyway, lots of words to say that I don’t see anything immediately > > obvious with cross-compilation, yet I wouldn’t be surprised if some of > > these cache-defeating idioms were used because we’ve payed less > > attention to this. > > I've got a feeling that performance has got worse since I looked at this > originally, I've finally got around to having a further look. > > I spent some time looking at various metrics, but it was most useful to > just write the cache keys of various types to files and have a read. > > The cross-base module was causing many issues, as all but one of the > procedures there produced new package records each time. There is also > make-rust-sysroot which showed up. > > I've sent some patches as #68266 to add memoization to avoid this, and > that seems to speed things up. > > Looking at other things in the cache, I think there are some issues with > file-append and local-file. The use of file-append in svn-fetch and > local-file in the lower procedure in the python build system both bloat > the cache for example, although I'm less sure about how to address these > cases. > > One thing I am sure about though, is that these problems will come > back. Maybe we could add some reporting in to Guix to look through the > cache at the keys, lower them all and check for equivalence. That way it > should be possible to automate saying that having [1] in the cache > several thousand times is unhelpful. The data service could then run > this reporting and store it. > > 1: # gnu/packages/version-control.scm:2267 7f294d908840> "/bin/svn"> I grabbed the patch for make-rust-sysroot to try it out: Native builds: time GUIX_PROFILING="object-cache" ./pre-inst-env guix build --no-grafts $(./pre-inst-env ~/list-all-cargo-build-system-packages | grep rust- | head -n 100) -d Object Cache: fresh caches:21 lookups: 133146 hits: 130101 (97.7%) cache size:3044 entries real0m7.539s user0m10.239s sys 0m0.327s Before: time GUIX_PROFILING="object-cache" ./pre-inst-env guix build --no-grafts $(./pre-inst-env ~/list-all-cargo-build-system-packages | grep rust- | head -n 100) --target=aarch64-linux-gnu -d Object Cache: fresh caches:20 lookups: 221189 hits: 211390 (95.6%) cache size:9798 entries real0m18.215s user0m14.492s sys 0m0.469s After: time GUIX_PROFILING="object-cache" ./pre-inst-env guix build --no-grafts $(./pre-inst-env ~/list-all-cargo-build-system-packages | grep rust- | head -n 100) --target=aarch64-linux-gnu -d Object Cache: fresh caches:20 lookups: 138654 hits: 135291 (97.6%) cache size:3362 entries real0m7.753s user0m10.248s sys 0m0.328s That's a massive drop in the size of the cache and a big decrease in the amount of time it took to calculate those 100 items. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: xwayland security updates, to mesa- or core-updates or ?
On Mon, Jan 08, 2024 at 05:43:40AM +, John Kehayias wrote: > Hi all, > > Forgive the top post and please see below/previous messages for > previous updates. > > TL;DR: I plan to merge mesa-updates into master today-ish (well, > tomorrow for me at this point). > > I've been checking in with Efraim who's been very helpful at trying to > nudge along substitute coverage on non-x86_64 platforms. Unfortunately > looks like we have plateaued a bit on, e.g., aarch64. We haven't been > getting stats from QA for this round, and Berlin looks good for what > it covers (x86) but other architectures are down from what we can > tell. > > I don't think there are any fundamental failures at this point but > just lots of "missing derivation" errors (I've restarted so many > manually for x86_64/i686) and builds not completing without restarts. > Or unknown reasons. Given the few weeks I've given this and the risk > of just perpetually doing rebuilds to keep catching up (with then more > updates to push) I think it would be best to merge to master. Mesa and > other bits will continue to move forward as well, so I think it is > time so we can be somewhat timely. > > I'd rather not without complete substitute coverage, but given recent > build farm difficulties, and the tools we do have for users (pinning, > weather checks, etc.) I think it is best to call this branch so we can > move on. Gnome has some updates that will need (re)building as well as > trying to move forward with core-updates now too. > > This is a case where having some better sense of our users and actual > substitute needs/wants would be helpful (yes, Guix survey!) as well as > recognizing our current infrastructure limits. Here's another vote for > prioritizing infrastructure and making sure QA lives and expands. > > Feel free to object to this merge timing, though with the relative > silence in each previous message I take it I can make a call here. > > Thanks everyone and hope 2024 is off to a good start! Enjoy the new > mesa with curl and xwayland security updates (no new grafts!). To record here more or less what I said on IRC, we're currently at rust-1.56 or 1.57 on the mesa-teams branch, and we're looking at probably more than a week to build out to rust itself, and then the packages which depend on it. Currently, on master, Berlin already is running behind on building rust, and it wasn't until after the previous mesa-updates merge that it caught up with building rust. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: xwayland security updates, to mesa- or core-updates or ?
On Thu, Jan 04, 2024 at 05:13:46AM +, John Kehayias wrote: > Hi Efraim and guix-devel > > On Mon, Dec 25, 2023 at 08:44 AM, Efraim Flashner wrote: > > > On Fri, Dec 22, 2023 at 09:19:27AM +0200, Efraim Flashner wrote: > >> On Thu, Dec 21, 2023 at 09:18:50PM +, John Kehayias wrote: > >> > Hi all, > >> > > >> > On Mon, Dec 18, 2023 at 12:57 AM, John Kehayias wrote: > >> > > [snip] > >> > > >> > I haven't seen QA process this branch, so I'm just going with what I > >> > see on Berlin. From the branches overview it shows about 61% last I > >> > saw, compared to 72% for master. Unfortunately, non x86 architectures > >> > are usually better covered by Bordeaux, but I don't know where to get > >> > a sense of that coverage. For what it is worth, Efraim has manually > >> > built xorgproto and mesa at least on powerpc64le, riscv64, without > >> > issues. > >> > >> I had berlin build for powerpc64le and that went without any problems. > >> Locally I built for riscv64 and powerpc and those both built fine. I > >> ran into an issue locally with curl on aarch64 and test 1477(?) which is > >> weird since it's supposed to be skipped but I'm sending it through > >> again. Haven't started armhf yet. > >> > >> > Coverage on x86_64 and i686 seems good from what I can tell. I also > >> > don't think there are any other branches ready to merge, and would > >> > like to give them time to rebuild once these changes hit. > >> > > >> > Any thoughts on when to merge? > >> > > >> > Thanks everyone! > >> > John > > > > Coming back to this point, seems Berlin is doing better with building > but I don't see mesa-updates on QA so I'm not sure about non > x86_64/i686-linux coverage. Anyone have any thoughts? > > I don't know that I've seen real new failures, as still lots of > "missing derivation" or other transient issues that resolve on forcing > a rebuild. > > I don't want to merge to master and have issues with substitute > coverage, but do have to call it at some point or will end up keep > scheduling/waiting for rebuilds to happen anyway. > > Thoughts? I've been massaging the aarch64 builds to try to build out to rust, currently I'm still around cmake. Last time we relied on bayfront for substitutes, which I'd be okay with again, as long as we can tell that it's doing alright. > > I've been having trouble with curl on aarch64 again. Looking at this > > snippet from the build log: > > > > test 1477...[Verify that error codes in headers and libcurl-errors.3 are in > > sync] > > > > 1477: stdout FAILED: > > --- log/1/check-expected2023-12-22 10:53:51.658667071 + > > +++ log/1/check-generated 2023-12-22 10:53:51.658667071 + > > @@ -1 +0,0 @@ > > -Result[LF] > > > > - abort tests > > test 1475...[-f and 416 with Content-Range: */size] > > --pd---e--- OK (1247 out of 1472, remaining: 00:45, took 5.310s, duration: > > 04:11) > > test 1474...[HTTP PUT with Expect: 100-continue and 417 response during > > upload] > > --pd---e--- OK (1246 out of 1472, remaining: 00:48, took 22.794s, duration: > > 04:29) > > Warning: test1474 result is ignored, but passed! > > ... > > TESTFAIL: These test cases failed: 1477 > > > > It looks like 1474 is passing locally and the ~1474 is telling the test > > suite to ignore the result. If that's how ~ is interpreted then > > I'd suggest that 1477 is failing hard enough that it's taking the test > > suite with it, not merely ignoring the result. I'll continue poking it > > but right now I'm starting to like the hurd plan of disabling the test > > instead of merely ignoring the result. > > Thanks for looking at this Efraim. Looks like a good chunk of the curl > rebuilds did get through, did it look okay on aarch64 and anywhere > else you checked? Looks like I got it working on whichever systems I tested it on and I today saw it build correctly on Berlin. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Are declarative app configs worth it?
On Wed, Dec 27, 2023 at 08:38:24AM +0100, Sergey Trofimov wrote: > > Ricardo Wurmus writes: > > > Sergey Trofimov writes: > > > > > - adding it to guix increases maintenance burden: new versions could > > > add or remove config options > > > > This is why there should be automated tests. There are too few of them. > > > > that adds up to the pile of boilerplate to implement a simple config. If > guix mandates it for new packages, it'll raise the bar for contribution even > higher than it already is. > > > > - it bloats guix: imagine if we add configs for every > > > user-configurable app > > > > That would be nice. > > > > If we started to accept the term bloat we could easily apply it to > > anything in Guix: all that R stuff? Bloat! All that bioinfo stuff? > > Bloat! > > > > imo, R and bioinfo should be in channels. That wasn't a serious suggestion. > > > - such configs are not easily transferrable: if I were to use the > > > same app in non-guix env, I'd have to maintain 2 configs > > > > We are generating configuration files from our config languages. So you > > would only need to generate them and copy them for your non-guix > > environment. > > > > Sure, that's why I wrote "not easily". My non-guix env is a corporate Mac > laptop. Currently I just clone my dotfiles, symlink required configs and > it's done. I can make changes in both environments and there is no > unnecessary "compiling" step involved. You're not required to use the guix-home bits. I didn't for a long time, and there are still a lot of config files that I have that I either symlink into place or I write out in my guix-home config file to be splatted into place. I still regularly scp my .screenrc and .inputrc to other machines. > > > Another recent example is `oci-container-configuration` which > > > defines > > > a subset of docker-cli startup arguments. The problem is that > > > `docker > > > run` command has 96 options and the configuration only uses a > > > handful, > > > lacking a way to provide the remaining ones. > > > > All config bindings need to have an escape hatch. > > > That would be great. Most services have an extra-options (or similarly named) field where you can add extra bits to the config. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Question on python-pydantic update, rust and maturin build tool
On Tue, Dec 26, 2023 at 12:27:38AM +, Sharlatan Hellseher wrote: > Hi Guix! > > > It might be addressed to rust/python teams. > https://github.com/pydantic/pydantic-core > > During update of some packages from (gnu packages astronomy) I've faced > with requirement for the fresh version of pydantic which depends on > pydantic-core built with rust and maturin. > > This thread is just conversation opener for the potential strategy to deal > with similar cases where python projects start using rust with rare but new > build tool. We have maturin packaged at 1.1.0 and I believe it is even used to build a couple of packages. python-rpds-py, which just landed in the repo today, is probably the best short example of how to use a combination of cargo and any other build system to build a project that doesn't really need any phases overridden, just added/replaced. Is there a specific version of pydantic that you need? I might be able to put together something either using the crates in the master branch or a newer version on the rust-team branch. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Rust <3 Guix
On Mon, Dec 25, 2023 at 07:25:26AM +, jgart wrote:
> > Do you need both nss-certs and curl?
>
> Hi Efraim, yes, I need both, oddly enough. If I remove one of them the build
> fails with the error message in the README that I provided.
>
> > I saw in a later commit you said it's working.
>
> I'm able to build main.rs with the guix installed tools but I'm not able to
> use guix-installed crate dependencies.
>
> I ended up installing the crates with cargo by fetching them from crates.io
> with the following invocations:
>
> cargo fetch
> cargo update
> cargo build
>
> Not sure at the moment how to get cargo to defer to guix for managing the
> crates when doing development... WDYT
It's not pretty currently using guix's crates. The first part, getting
the necessary crates, involves manually adding them (with their
dependencies!) to your environment. The second part involves adjusting
your config.toml to include the following:
[source.crates-io]
local-registry =
'/gnu/store/3nfgfhxlciblr360jyrgxl275sf78a6f-profile/share/cargo/registry'
HOWEVER, instead of /gnu/store/...-profile you need to adjust the path
to the value of your GUIX_ENVIRONMENT, and there's no way that I've
figured out to use $GUIX_ENVIRONMENT in a toml file.
Actually, it looks like I have the cargo registry patches sitting
unapplied on my machine, so I'm not even sure if it'll work the way I
wrote above. I'll see about getting them into a state I'm happy with
for the rust-team branch.
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
From 84d2f06e9facec9a1646afd53adcbf2b95da4da0 Mon Sep 17 00:00:00 2001
Message-ID:
<84d2f06e9facec9a1646afd53adcbf2b95da4da0.1702565894.git.efr...@flashner.co.il>
In-Reply-To:
References:
From: Efraim Flashner
Date: Thu, 14 Dec 2023 16:49:58 +0200
Subject: [PATCH 1/2] build: cargo-build-system: Produce registry index files.
* guix/build/cargo-build-system.scm (rewrite-deps): New procedure.
(package): Obtain output from 'cargo manifest' of the current package
when the package will be installed.
(install): Don't install cargo crates and source.
(install-source): New phase. Install cargo crates. Generate cargo
registry index files and install them in a known location.
(%standard-phases): Add 'install-source phase after 'install.
Change-Id: I6ce6c5b33fe3eb7667f86964daef798320724a25
---
guix/build/cargo-build-system.scm | 102 +-
1 file changed, 87 insertions(+), 15 deletions(-)
diff --git a/guix/build/cargo-build-system.scm
b/guix/build/cargo-build-system.scm
index ffb2ec898e..f1e35a5c65 100644
--- a/guix/build/cargo-build-system.scm
+++ b/guix/build/cargo-build-system.scm
@@ -73,6 +73,21 @@ (define (crate-src? path)
" | cut -d/ -f2"
" | grep -q '^Cargo.toml$'")
+(define (rewrite-deps cargo-deps)
+ (map (lambda (dependency)
+ `(@ ("name" . ,(assoc-ref dependency "name"))
+ ("req" . ,(assoc-ref dependency "req"))
+ ("features" . ,(assoc-ref dependency "features"))
+ ("optional" . ,(assoc-ref dependency "optional"))
+ ("default_features" . ,(assoc-ref dependency
+ "uses_default_features"))
+ ("target" . ,(assoc-ref dependency "target"))
+ ("kind" . ,(match (assoc-ref dependency "kind")
+ (null? "normal")
+ (kind kind)))
+ ("registry" . ,(assoc-ref dependency "registry"
+ cargo-deps))
+
(define* (unpack-rust-crates #:key inputs vendor-dir #:allow-other-keys)
(define (inputs->rust-inputs inputs)
"Filter using the label part from INPUTS."
@@ -271,7 +286,8 @@ (define* (package #:key
install-source?
(cargo-package-flags '("--no-metadata" "--no-verify"))
#:allow-other-keys)
- "Run 'cargo-package' for a given Cargo package."
+ "Run 'cargo-package' for a given Cargo package. Also generate metadata so
we can
+create a package index for the crates."
(if install-source?
(if skip-build?
(begin
@@ -322,19 +338,24 @@ (define* (package #:key
(delete-file-recursively dir)))
(find-files "." "\\.crate$")
(format #t "Not installing cargo sources, skipping `cargo package`.~%"))
- #t)
+
+ (when install-source?
+;; First generate the metadata so we can create the index file.
+;; https:
Re: xwayland security updates, to mesa- or core-updates or ?
On Fri, Dec 22, 2023 at 09:19:27AM +0200, Efraim Flashner wrote: > On Thu, Dec 21, 2023 at 09:18:50PM +, John Kehayias wrote: > > Hi all, > > > > On Mon, Dec 18, 2023 at 12:57 AM, John Kehayias wrote: > > > > > Hi Kaelyn and everyone, > > > > > > On Fri, Dec 15, 2023 at 05:25 PM, Kaelyn wrote: > > > > > >> 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.) > > >>> > > > > I also updated curl as it was going to be rebuilt and had a new > > version out (with some security fixes). I hadn't grafted it on master > > but we could do that if the mesa-updates branch isn't merged to master > > first. > > > > [snip] > > > > > > > > I've pushed 3 patches (mesa, xorgproto, xorg-server-xwayland) to > > > mesa-updates after merging in master. The farm is building away. > > > > > > > I also had to skip a failing test (unknown reasons) of gtk with these > > updates. > > > > Finally, I also enabled the zink driver in Mesa (zink is for OpenGL on > > Vulkan). I remember someone asking about it on #guix recently as well, > > and we should have it enabled in general, to support devices which may > > not be able to use OpenGL without it. > > > > > The request for merging is at <https://issues.guix.gnu.org/67875> with > > > some details. In short, running into some issues with builds "failing" > > > because they just die or "missing derivation" errors. I'm restarting > > > what I see that seems higher impact, but is there anyway to restart > > > all the failed builds or ones with missing dependencies? > > > > > > > This is still true though I've tried to manually restart lots of > > builds on x86_64 and i686, which has removed many of the failures. Any > > idea what is happening to cause this more recently? > > > > [snip] > > > > > Thanks! I saw you had posted the latest version and that's what I > > > included. On x86_64-linux at least everything has built fine for > > > those, but the larger world remains to be seen. > > > > > > Would still like confirmation from other branches about what they want > > > to do, but we have some time while things build. And builds get > > > restarted. > > > > > > > I haven't seen QA process this branch, so I'm just going with what I > > see on Berlin. From the branches overview it shows about 61% last I > > saw, compared to 72% for master. Unfortunately, non x86 architectures > > are usually better covered by Bordeaux, but I don't know where to get > > a sense of that coverage. For what it is worth, Efraim has manually > > built xorgproto and mesa at least on powerpc64le, riscv64, without > > issues. > > I had berlin build for powerpc64le and that went without any problems. > Locally I built for riscv64 and powerpc and those both built fine. I > ran into an issue locally with curl on aarch64 and test 1477(?) which is > weird since it's supposed to be skipped but I'm sending it through > again. Haven't started armhf yet. > > > Coverage on x86_64 and i686 seems good from what I can tell. I also > > don't think there are any other branches ready to merge, and would > > like to give them time to rebuild once these changes hit. > > > > Any thoughts on when to merge? > > > > Thanks everyone! > > John I've been having trouble with curl on aarch64 again. Looking at this snippet from the build log: test 1477...[Verify that error codes in headers and libcurl-errors.3 are in sync] 1477: stdout FAILED: --- log/1/check-expected2023-12-22 10:53:51.658667071 + +++ log/1/check-generated 2023-12-22 10:53:51.658667071 + @@ -1 +0,0 @@ -Result[LF] - abort tests test 1475...[-f and 416 with Content-Range:
Re: Rust <3 Guix
On Sun, Dec 24, 2023 at 08:35:36PM +, jgart wrote: > Hi Guixers, > > What do you think I am missing? > > Completion works. > Clippy works. > Rustfmt works. > > `rust-compile` from emacs-rust-mode does not work :( > > I get the following error listed in the README when I try to compile the > following Rust Guix project: > > https://git.sr.ht/~whereiseveryone/crab-meets-gnu I saw in a later commit you said it's working. Do you need both nss-certs and curl? Also, rust-analyzer is basically a convenience package around the rust-analyzer binary from rust:tools since we don't have a way to deprecate packages and point them to alternate outputs. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: xwayland security updates, to mesa- or core-updates or ?
On Thu, Dec 21, 2023 at 09:18:50PM +, John Kehayias wrote: > Hi all, > > On Mon, Dec 18, 2023 at 12:57 AM, John Kehayias wrote: > > > Hi Kaelyn and everyone, > > > > On Fri, Dec 15, 2023 at 05:25 PM, Kaelyn wrote: > > > >> 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.) > >>> > > I also updated curl as it was going to be rebuilt and had a new > version out (with some security fixes). I hadn't grafted it on master > but we could do that if the mesa-updates branch isn't merged to master > first. > > [snip] > > > > > I've pushed 3 patches (mesa, xorgproto, xorg-server-xwayland) to > > mesa-updates after merging in master. The farm is building away. > > > > I also had to skip a failing test (unknown reasons) of gtk with these > updates. > > Finally, I also enabled the zink driver in Mesa (zink is for OpenGL on > Vulkan). I remember someone asking about it on #guix recently as well, > and we should have it enabled in general, to support devices which may > not be able to use OpenGL without it. > > > The request for merging is at <https://issues.guix.gnu.org/67875> with > > some details. In short, running into some issues with builds "failing" > > because they just die or "missing derivation" errors. I'm restarting > > what I see that seems higher impact, but is there anyway to restart > > all the failed builds or ones with missing dependencies? > > > > This is still true though I've tried to manually restart lots of > builds on x86_64 and i686, which has removed many of the failures. Any > idea what is happening to cause this more recently? > > [snip] > > > Thanks! I saw you had posted the latest version and that's what I > > included. On x86_64-linux at least everything has built fine for > > those, but the larger world remains to be seen. > > > > Would still like confirmation from other branches about what they want > > to do, but we have some time while things build. And builds get > > restarted. > > > > I haven't seen QA process this branch, so I'm just going with what I > see on Berlin. From the branches overview it shows about 61% last I > saw, compared to 72% for master. Unfortunately, non x86 architectures > are usually better covered by Bordeaux, but I don't know where to get > a sense of that coverage. For what it is worth, Efraim has manually > built xorgproto and mesa at least on powerpc64le, riscv64, without > issues. I had berlin build for powerpc64le and that went without any problems. Locally I built for riscv64 and powerpc and those both built fine. I ran into an issue locally with curl on aarch64 and test 1477(?) which is weird since it's supposed to be skipped but I'm sending it through again. Haven't started armhf yet. > Coverage on x86_64 and i686 seems good from what I can tell. I also > don't think there are any other branches ready to merge, and would > like to give them time to rebuild once these changes hit. > > Any thoughts on when to merge? > > Thanks everyone! > John > -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Possible to separate out tk from python?
On Sun, Dec 17, 2023 at 06:22:19AM +, John Kehayias wrote: > Hi Guix, > > Quick(?) question if someone happens to know: can we separate out the tk > dependency from the python package, for instance by making the tk output of > python a separate package? > > I'm asking because I've realized that it is through tk that python, and thus > a good chunk of all packages, depend on things like libx11 and xorgproto. In > updating xorgproto for xorg-server-xwayland update, this causes python to be > rebuilt. I saw the same when ungrafting libx11 but didn't look close enough > to realize it is through tk. > > (As an aside, in using python as a user, it is easy to miss the python:tk > output when you need it. And without searching I'm guessing many fewer > packages depend on python:tk than the default output.) > > I don't know enough about how python is built (and then used in building) off > the top of my head to know if this is possible. But if it was, I think it > could untangle lots of the package graph. > > Thanks in advance! > John $ ./pre-inst-env guix build --no-grafts python /gnu/store/bvbrc8df75sfaxk7365xwwga5iy8xg57-python-3.10.7-idle /gnu/store/91wasjkmy50p8fq0rf9jby80mnmq1fxr-python-3.10.7 /gnu/store/vpip7zvwps9nwzn13m9x942q2za21rfq-python-3.10.7-tk $ guix gc --references /gnu/store/91wasjkmy50p8fq0rf9jby80mnmq1fxr-python-3.10.7 /gnu/store/2w976k6g70gkfih9wwhalqsni209vcqz-gdbm-1.23 /gnu/store/4jakqiibsvrkv4jdw1wyl6racrwv9bkh-sqlite-3.39.3 /gnu/store/69wd3pd1hd3j84xr965jj2fk2qmxn0hl-openssl-3.0.8 /gnu/store/6k1yys9wqrfn4y41ic1win8gpnimncwj-xz-5.2.8 /gnu/store/91wasjkmy50p8fq0rf9jby80mnmq1fxr-python-3.10.7 /gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib /gnu/store/bcc053jvsbspdjr17gnnd9dg85b3a0gy-ncurses-6.2.20210619 /gnu/store/fw1wywd34vh33l4dq182ds5d7jdz45j5-expat-2.5.0 /gnu/store/gqsxab8w881ds9raxkv74k0xcjds3z10-tcl-8.6.12 /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35 /gnu/store/lxfc2a05ysi7vlaq0m3w5wsfsy0drdlw-readline-8.1.2 /gnu/store/pl09vk5g3cl8fxfln2hjk996pyahqk8m-bzip2-1.0.8 /gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16 /gnu/store/slzq3zqwj75lbrg4ly51hfhbv2vhryv5-zlib-1.2.13 /gnu/store/vzl3lmb1lh702wvb3l1b3dzs2391lp02-tk-8.6.12 /gnu/store/w8b0l8hk6g0fahj4fvmc4qqm3cvaxnmv-libffi-3.4.4 $ grep /gnu/store/vzl3lmb1lh702wvb3l1b3dzs2391lp02-tk-8.6.12 -R /gnu/store/91wasjkmy50p8fq0rf9jby80mnmq1fxr-python-3.10.7 grep: /gnu/store/91wasjkmy50p8fq0rf9jby80mnmq1fxr-python-3.10.7/lib/python3.10/__pycache__/_sysconfigdata__linux_x86_64-linux-gnu.cpython-310.opt-1.pyc: binary file matches grep: /gnu/store/91wasjkmy50p8fq0rf9jby80mnmq1fxr-python-3.10.7/lib/python3.10/__pycache__/_sysconfigdata__linux_x86_64-linux-gnu.cpython-310.opt-2.pyc: binary file matches grep: /gnu/store/91wasjkmy50p8fq0rf9jby80mnmq1fxr-python-3.10.7/lib/python3.10/__pycache__/_sysconfigdata__linux_x86_64-linux-gnu.cpython-310.pyc: binary file matches /gnu/store/91wasjkmy50p8fq0rf9jby80mnmq1fxr-python-3.10.7/lib/python3.10/_sysconfigdata__linux_x86_64-linux-gnu.py: '-L/gnu/store/vzl3lmb1lh702wvb3l1b3dzs2391lp02-tk-8.6.12/lib ' /gnu/store/91wasjkmy50p8fq0rf9jby80mnmq1fxr-python-3.10.7/lib/python3.10/config-3.10-x86_64-linux-gnu/Makefile:TCLTK_LIBS= -L/gnu/store/gqsxab8w881ds9raxkv74k0xcjds3z10-tcl-8.6.12/lib -L/gnu/store/vzl3lmb1lh702wvb3l1b3dzs2391lp02-tk-8.6.12/lib -ltk8.6 -ltkstub8.6 -ltcl8.6 -ltclstub8.6 Checking through the python sources: New in python-3.6.0-alpha 3: - bpo-23968: Rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET). Rename the config directory (LIBPL) from config-$(LDVERSION) to config-$(LDVERSION)-$(PLATFORM_TRIPLET). Install the platform specific _sysconfigdata module into the platform directory and rename it to include the ABIFLAGS. New in python-3.6.0-alpha 2: - bpo-21272: Use _sysconfigdata.py to initialize distutils.sysconfig. https://docs.python.org/3/library/sysconfig.html It looks like sysconfigdata isn't just something we can rip out. $ guix shell python -- python3 -m sysconfig | grep TCLTK TCLTK_INCLUDES = "" TCLTK_LIBS = "-L/gnu/store/0scbhmjkll66vpgvgh7d77hayxgy1cc2-tcl-8.6.12/lib -L/gnu/store/fbjr5b0nfhq490x2ys1rzi7sg7rjpz95-tk-8.6.12/lib -ltk8.6 -ltkstub8.6 -ltcl8.6 -ltclstub8.6" $ guix shell pkg-config tcl tk -- pkg-config --libs tcl tk -L/gnu/store/fbjr5b0nfhq490x2ys1rzi7sg7rjpz95-tk-8.6.12/lib -L/gnu/store/0scbhmjkll66vpgvgh7d77hayxgy1cc2-tcl-8.6.12/lib -ltk8.6 -ltkstub8.6 -ltcl8.6 -ltclstub8.6 I do wonder if we could substitute TCLTK_LIBS to be: "`pkg-config --libs tcl tk`" and if that would work. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: rust-team branch merged
On Wed, Dec 13, 2023 at 10:34:11AM +0200, Efraim Flashner wrote:
> * Compiled rust packages currently have a 'package' phase, which runs
> the command used to crate a 'crate tarball', and is installed in
> %output/share/cargo/registry, with unpacked sources in
> %output/share/cargo/src. In theory it should be possible to use these
> for local rust development. The benefits include everything that comes
> with being a guix package, including pre-patched shebangs. Currently no
> index file is created in $GUIX_ENVIRONMENT/share/cargo/registry/index,
> which is likely necessary to actually make use of this. Additionally, I
> am unsure how to use '$GUIX_ENVIRONMENT' in ~/.cargo/config so that it
> is expanded and not taken as a literal string.
In the Guix London meetup someone mentioned that they were interested in
playing around with using Guix for rust development. I've adjusted the
cargo-build-system to produce the registry index files and I added a
profile hook to generate the config.json to locate the packaged crates.
toml files can't process environment variables (which is probably a good
thing ...) but that means its a little harder to test out.
with the two patches applied create an environment with the crates you
want and get the location of GUIX_ENVIRONMENT:
`env | grep GUIX_ENVIRONMENT | cut -f2 -d=`
in ~/.cargo/config:
[source.crates-io]
local-registry = '/share/cargo/registry'
'cargo build' should pull from the local crates in the GUIX_ENVIRONMENT.
I'm not sure what happens if it doesn't have those crates available and
would need to get them from crates.io.
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
From 84d2f06e9facec9a1646afd53adcbf2b95da4da0 Mon Sep 17 00:00:00 2001
Message-ID:
<84d2f06e9facec9a1646afd53adcbf2b95da4da0.1702565894.git.efr...@flashner.co.il>
In-Reply-To:
References:
From: Efraim Flashner
Date: Thu, 14 Dec 2023 16:49:58 +0200
Subject: [PATCH 1/2] build: cargo-build-system: Produce registry index files.
* guix/build/cargo-build-system.scm (rewrite-deps): New procedure.
(package): Obtain output from 'cargo manifest' of the current package
when the package will be installed.
(install): Don't install cargo crates and source.
(install-source): New phase. Install cargo crates. Generate cargo
registry index files and install them in a known location.
(%standard-phases): Add 'install-source phase after 'install.
Change-Id: I6ce6c5b33fe3eb7667f86964daef798320724a25
---
guix/build/cargo-build-system.scm | 102 +-
1 file changed, 87 insertions(+), 15 deletions(-)
diff --git a/guix/build/cargo-build-system.scm
b/guix/build/cargo-build-system.scm
index ffb2ec898e..f1e35a5c65 100644
--- a/guix/build/cargo-build-system.scm
+++ b/guix/build/cargo-build-system.scm
@@ -73,6 +73,21 @@ (define (crate-src? path)
" | cut -d/ -f2"
" | grep -q '^Cargo.toml$'")
+(define (rewrite-deps cargo-deps)
+ (map (lambda (dependency)
+ `(@ ("name" . ,(assoc-ref dependency "name"))
+ ("req" . ,(assoc-ref dependency "req"))
+ ("features" . ,(assoc-ref dependency "features"))
+ ("optional" . ,(assoc-ref dependency "optional"))
+ ("default_features" . ,(assoc-ref dependency
+ "uses_default_features"))
+ ("target" . ,(assoc-ref dependency "target"))
+ ("kind" . ,(match (assoc-ref dependency "kind")
+ (null? "normal")
+ (kind kind)))
+ ("registry" . ,(assoc-ref dependency "registry"
+ cargo-deps))
+
(define* (unpack-rust-crates #:key inputs vendor-dir #:allow-other-keys)
(define (inputs->rust-inputs inputs)
"Filter using the label part from INPUTS."
@@ -271,7 +286,8 @@ (define* (package #:key
install-source?
(cargo-package-flags '("--no-metadata" "--no-verify"))
#:allow-other-keys)
- "Run 'cargo-package' for a given Cargo package."
+ "Run 'cargo-package' for a given Cargo package. Also generate metadata so
we can
+create a package index for the crates."
(if install-source?
(if skip-build?
(begin
@@ -322,19 +338,24 @@ (define* (package #:key
(delete-file-recursively dir)))
(find-files "." "\\.crate$")
(format #t "Not installing cargo sources, skipping `cargo package`.~%"))
- #t)
+
+ (when inst
rust-team branch merged
The rust team is pleased to announce that the rust-team branch has been merged back into master. There are 570 commits across the branch. Cross-compiling support for the cargo-build-system was added, including for librsvg. Cross-compiling was tested for (nearly) all architectures supported in `guix build --list-targets`. Upstream rust added 'i686-unknown-hurd-gnu' as a target in rust-1.74, so that will need to wait until another time. In the meantime, x86_64-w64-mingw32 at least compiles correctly and tests well under wine. Notable notes: * New rust version is 1.73. * 4001 packages use the cargo-build-system * Rust crates produced in the 'package' phase of the cargo-build-system should now be reproducible (for real this time) * Packages added: eza, kibi, libgit2-1.6, libgit2-1.7, spotifyd, stgit-2 * Packages updated: alfis, rust-analyzer, rust-cargo-c * Rust-analyzer is built from the rust sources now, updating it to 1.73. It can be installed as 'rust-analyzer' or as 'rust:tools' * Cross-compiling support for the cargo-build-system was added Additional notes: * crates.io no longer accepts '-' instead of '_' in crate lookups, so there are a (probably large) number of packages which need to have their source adjusted. * Compiled rust packages currently have a 'package' phase, which runs the command used to crate a 'crate tarball', and is installed in %output/share/cargo/registry, with unpacked sources in %output/share/cargo/src. In theory it should be possible to use these for local rust development. The benefits include everything that comes with being a guix package, including pre-patched shebangs. Currently no index file is created in $GUIX_ENVIRONMENT/share/cargo/registry/index, which is likely necessary to actually make use of this. Additionally, I am unsure how to use '$GUIX_ENVIRONMENT' in ~/.cargo/config so that it is expanded and not taken as a literal string. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: [bug#67261] [PATCH 3/3] images: Add orangepi-r1-plus-lts image.
On Fri, Dec 01, 2023 at 11:58:57AM -0800, Vagrant Cascadian wrote: > On 2023-11-18, Herman Rimm wrote: > > * gnu/local.mk: Register image. > > * gnu/system/images/orangepi-r1-plus-lts-rk3328.scm: New file. > > * gnu/system/install.scm (orangepi-r1-plus-lts-rk3328-installation-os): > > New variable. > > I guess this opens in my mind a larger question of how many images do we > want to build out-of-the-box? > > Building images for every (ARM) board variant possibly supported in guix > might not be sustainable in the long term... this could easily become > hundreds of images. How big is each image? > > On the other hand, most of the images for a given architecture will > share much of the work between them, as most of the individual packages > used to build each image are the same. > > Not having CI build each and every image is one approach... although > then you might not notice when an individual image breaks. Do we normally build all the images in (gnu system images)? There seems to be a large number of different file-system offsets needed for different boards. I suppose we could standardize on a larger size that would take care of most of them, but until something is setup to make it possible I'm not sure it's possible to support them for Guix System without also adding an OS config for the offsets for the root file system. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: sbcl-py4cl does not appear in --list-dependent output
On Wed, Nov 29, 2023 at 01:27:15PM +, jgart wrote: > Hi Guixers, > > Does anyone happen to know why sbcl-py4cl doesn't appear in this output? > > guix refresh --list-dependent python-numpy > > (ins)efraim@3900XT ~$ guix refresh -l sbcl-py4cl A single dependent package: cl-py4cl@0.0.0-2.2f2a008 cl-py4cl@0.0.0-2.2f2a008 does appear in the list -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: guix refresh --update Removes Needed Dependencies
On Wed, Nov 22, 2023 at 10:45:48PM +0100, Ludovic Courtès wrote: > Hi jgart, > > "jgart" skribis: > > > ./pre-inst-env guix refresh --update python-sphinx > > [...] > > > - ;; The Sphinx LaTeX library '\RequirePackage' or \\usepackage > > - ;; these: > > - texlive-amsfonts ;amsmath, amssymb, amstext > > - texlive-amsmath > > - texlive-capt-of > > - texlive-carlisle ;remreset > > To avoid this problem one can add package properties such as > ‘updater-extra-native-inputs’ in this case: > > > https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-refresh.html#index-updater_002dextra_002dinputs_002c-package-property > > However, the way it’s implemented right now, you have to list the name > of every input that should be preserved by ‘guix refresh -u’, which is > inconvenient in this particular case because there are many of them. > > I can think of two ways to improve on that: > > 1. Use one of the ‘texlive-scheme-*’ packages instead of this long > list. :-) > > 2. Change the code to interpret extra inputs are regexps instead of > names. I like both ideas -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Request-For-Comment process: concrete implementation
On Tue, Oct 31, 2023 at 12:14:42PM +0100, Simon Tournier wrote: > Hi, > > This is a proposal for implementing Request-For-Comment process. > Comment are welcome in #66844 [1]: > > 1: https://issues.guix.gnu.org/issue/66844 > > > The proposal is highly inspired by Rust RFC: > > https://github.com/rust-lang/rfcs > > and also by GHC Haskell proposal process [1] and Nix RFC process [2]. Based > on my understanding of Guix community interactions, I write down this > text; below the text for easing the reading. > > Cheers, > simon > > 1: https://github.com/ghc-proposals/ghc-proposals > 2: https://github.com/NixOS/rfcs I think this is a great idea and that we should implement it. Looking through it I didn't see anything that jumped out to me as something that needed to be changed. Currently we have largish changes split between guix-patches and guix-devel, with no real clear way to draw people's attention to them. Currently I'm aware of re-arranging the go packages, splitting some of the system services into their own modules, I'd like to add a field to (guix platform), it'd be good to formalize some of these processes to make it clearer about what's expected and what's going on. Actually, in terms of suggestions, I'd add the rfc/ folder in etc/teams.scm to set guix-devel as one of the team members. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Confusing overview of mailing lists
On Thu, Nov 16, 2023 at 02:37:43AM +0100, Erik Grun wrote: > Hello, Guix, > > For some time now I've been using Guix on a few test machines. I have to > say, that I really like it. So much so, that I've now finally wanted to get > involved a bit closer. So I went to this page[1] with the overview of all > the mailing lists. > > Personally I find the links to the mailing list archives on the "Contact" > page a bit confusing. Because on the first look it appears, as if those list > are "archived". It looks even more so since not every list has the > "(Archive)" behind its name. > > My suggestion would be, to remove the archive links altogether from that > page. I mean, one can still get to the archives, when one goes to the > respective mailing list. > > If this topic doesn't fit here, please move it to the correct list (and keep > me in the CC). > > Best regards, > > Erik (egnun) > > [1] https://guix.gnu.org/en/contact I looked at the two links. Perhaps we could change it to (past archives), although I understand we refer to the mailing list archive when we're referring to previous mails sent to that mailing list. Alternatively, we could just get rid of it, that extra link only saves 1 click if you wanted to go and see the archives. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Upgrading Guix's security team
On Fri, Nov 17, 2023 at 11:31:41PM -0500, Maxim Cournoyer wrote: > Hi, > > Ludovic Courtès writes: > > [...] > > > Yes, we definitely need a rotation here! I for one have my name there > > but regardless of my interest, I have to admit that I’ve been unable to > > be sufficiently responsive. It’s time to let new folks take > > responsibility. > > > > I think we should make this a fixed-term position, to make it easier for > > people to commit to actually being active when needed, with the > > understanding that it’s not a commitment for life. > > > >> - currently we are not on the OS security distribution contact list: > >> <https://oss-security.openwall.org/wiki/mailing-lists/distros>; this > >> had been discussed before but we will need commitment from people > >> > >> - clear roles will be helpful; to me this includes at least a couple > >> of people to coordinate (the majority of security issues will be > >> handled through package upgrades/grafts) and people to help review > >> and/or contact needed experts, like for Guix internal issues; we > >> should make this more precise > > > > We could distinguish security issues in packages provided by Guix from > > security issues in Guix itself. > > > > That said, the security team could redirect things to members of the > > “core” team for security issues in Guix itself; maybe we don’t need to > > formally separate the two. > > > >> - likewise, a clear fixed timeframe for who is on this team; keeping > >> people fresh and engaged for what can suddenly be a time sensitive and > >> critical job; I think this will also help spread institutional > >> knowledge for better security practices in general > > > > +1! > > > >> - members need not be experts but should be active in the community as > >> committers (already a round of vetting), familiar with what issues and > >> processes may arise, and willing to learn; perhaps we need a list of > >> experts to consult though the current teams are a good starting point > > > > +1 > > > >> - what are your thoughts? what are the goals and outcomes we as a > >> distro want in security? > >> > >> - finally, I think an internal discussion with maintainers and long > >> time active committers would be helpful to get the improvements > >> started and moving, in addition to this wider discussion here > >> > >> And to get things started, I'm happy to volunteer myself to help > >> coordinate on security, if deemed okay by our current security team, > >> maintainers, and anyone else that's been helping to handle security. A > >> coordinating role with a term of say 6 months to a year? Happy to > >> provide more information and discuss here or privately; in short I'm > >> not a security expert but have time and bandwidth to keep things > >> moving and want to learn. > > > > Thank you for getting the ball moving! > > > > I’m all for having you on board and, to set an example, to leave as you > > join. > > > > If maintainers agree (Cc’d), I invite you to add your name and a > > termination date to the security page, remove my name, and subscribe to > > guix-security. We should add a term for other people on the team too. > > > > How does that sound? > > Sounds good to me! Sounds good to me too. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: bug#66964: Request for merging "mesa-updates" branch
On Tue, Nov 14, 2023 at 08:11:08PM +, 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. If the mesa branch is ready to merge so soon then I think we should just get that merged and then I'll rebase the rust-team branch on top of new master. The rust-team branch is also ready to merge, but we're way behind on aarch64 substitutes. Either way the substitute servers will be rebuilding all of rust so I think it'd be better to merge in mesa-updates and then do rust. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Better support remote deployment
On Wed, Nov 08, 2023 at 09:36:46AM -0500, Maxim Cournoyer wrote: > Hello, > > Felix Lechner writes: > > > Hi, > > > > On Tue, Nov 07 2023, Maxim Cournoyer wrote: > > > >> Then your suggestion to extend 'guix package' to be able to > >> install a profile from a store profile sounds useful, or perhaps a new > >> 'guix deploy-profile' (or a better name / sub-command?) that would > >> automate the copy and installation in one step. > > > > We have a lot of sub-commands already. Could 'guix deploy' instead be > > fed something other than a 'machine' record? > > Perhaps too much of an overload of that command; not sure. > > > How about a 'remote-user-profile'? > > 'guix package' is already the command we use to create profiles; maybe > it could accept a '--remote' argument to operate on a remote machine? > Or is this not what 'GUIX_DAEMON_SOCKET=ssh://your-target guix package > -m manifest.scm' can already accomplish? :-) Currently there's no ssh connection caching, so using GUIX_DAEMON_SOCKET can be quite slow, I normally allow 5-10 minutes for a profile. That works best when you can't use guix copy to send derivations over. The profile effectively already exists, it doesn't need to be computed on each machine. It does seem more like deploy: take this profile, send it to that machine, and activate it there. `guix deploy` already takes a file, the file could have a profile (or home config?) and a location for the profile. And a user. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Divvying up service definitions
On Tue, Nov 07, 2023 at 10:56:11AM -0500, Maxim Cournoyer wrote: > Hi Bruno, > > Bruno Victal writes: > > > Hi, > > > > As the gnu/services and gnu/home/services grow, I think we should > > consider divvying the services into stand-alone modules or > > subdirectories. > > > > Consider the ⌜dovecot-service-type⌝ in gnu/services/mail.scm: as of > > commit 'd22d2a05c389207f8cdcf824be7738b1499a987c' this service > > definition is nearly 1600 lines long, with the remainder of the file > > comprising of four other services with rudimentary support. > > > > It becomes troublesome working with such amalgamations as it makes it > > hard to keep track of the used modules and bindings, especially when > > define-configuration is used since the serializing procedures might be > > used by various service definitions. Further complicating things is > > 'define-maybe', whose use monopolizes the predicate and serializers for > > a particular service definition. > > > > Now, I'm not saying that we should go and split everything into its own > > module, I'm saying that we should be allowed to split some of them if > > convenient (all subjective but I believe we can see that working with a > > monolithic file in the kilolines where the interactions aren't obvious > > is not fun, and that's without bringing in the hygienic issues > > surrounding define-configuration and define-maybe). > > > > Some considerations (using dovecot-service-type as an example): > > * Splitting this as gnu/services/mail/dovecot.scm. > > We preserve the logical grouping of the services (with the addition > > that, for extremely comprehensive definitions, these can be neatly > > organized into subdirectories. (same structure seen with gnu/*.scm) > > A drawback is that 'use-service-modules' might not work with this > > although I wonder whether 'use-service-modules' & co. provide any > > value if we are already doing '(use-modules (gnu) …)' to begin with. > > They look redundant IMO. > > > > * Splitting this as gnu/services/dovecot.scm. > > We keep it compatible with 'use-service-modules' at the cost of having > > a multitude of files under gnu/services, without any logical grouping > > (messy). > > That's a great initiative! I agree that multiple 'define-configuration' > services per file can be a bit messy, having to use prefixes everywhere, > making the definitions more verbose. > > I don't have a strong preference of the caterogization of services, but > would perhaps prefer the first one (gnu/services/mail/dovecot.scm), > which could then make it easy to offer some interface as > gnu/services/mail.scm that'd re-export all that is needed (would that > work, or reintroduce the same top-level clashes?). I assume the define-maybe's aren't public, so I'd guess that shouldn't cause a problem as long as they aren't exported. There's some services, like ntpd and openntpd, which reuse the service user/group between them, I think with those being intentional about making sure there aren't clashes, or making sure they line up, would also be a good choice. Or moving the define-maybes to the top of the file and reusing them between services. Is that a possibility? -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Patch Review Flow
On Tue, Nov 07, 2023 at 12:32:35PM +, jgart wrote: > Hi Efraim, > > Thanks for sharing your approach as well. IIRC, a user can't interactively > cherry-pick a range with tig. If you find a way please do share ;() It looks like 'C' (that's a 'big c') over a commit will offer to cherry-pick the commit. Alternatively, if you're still looking at the branches then 'C' will offer to checkout that branch. Tig asks for an explicit y or n, so pressing enter for the prompt won't do anything. I should probably look at the different options tig has. I've had it installed forever but only ever used it for viewing commits and branches. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Patch Review Flow
On Mon, Nov 06, 2023 at 07:51:58AM +, Christopher Baines wrote: > > "jgart" writes: > > > Does anyone follow this workflow for reviewing patches? > > > > git clone https://git.guix-patches.cbaines.net/guix-patches/ > > git checkout issue-x > > git format-patch ... > > # then in the development checkout of Guix: > > git am ...; make; ./pre-inst-env guix build > > > > Should we document it in the manual? > > > > Does anyone follow a workflow that is more efficient than the above? > > I have the guix-patches repository as a remote, which I then cherry pick > from (via Magit), which makes it quick and easy to apply patches. I also have the guix-patches repository as a remote, and then I use tig to look at the different branches there. I haven't checked to see if it's possible to use git am or git cherry-pick from tig's interface so I'm doing that one by one. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: [RFC]: Skipping rust crate tests by default
On Wed, Oct 18, 2023 at 02:46:57PM -0400, Maxim Cournoyer wrote: > Hi Efraim, > > Efraim Flashner writes: > > [...] > > >> This sounds good except I don't understand how disabling the tests by > >> default help to "make sure that the packages have the correct inputs" ? > > > > When the tests are disabled, if a package shows red on the CI it means > > that either: > > A) there was a bundled shared/static library in the sources which need > > to be removed > > B) The inputs weren't correct and need to be fixed. > > What we're skipping is C) the test suite failed. > > > > When we get to the 'build phase of the cargo-build-system, cargo first > > checks that it has all of the crates listed in the Cargo.toml file, and > > that all of those crates have all of their (cargo-input) dependencies, > > and so on. If any of them are missing then the build will fail. This is > > also why we need to set #:skip-build? #t when we don't include the > > desired cargo-development-inputs. > > > > The change is mainly a quality of life improvement; it decreases the > > time that guix people and CI spend building these crates, and it makes > > it easier to see which, if any, rust packages need to be checked for > > brokenness (with the assumption that a broken or bit-rotted test suite > > isn't a problem). > > I understand that maintaining the large fleet of cargo crates packaged > in Guix is a lot of work, but I think we can try some things before > #:tests? #f; I gathered some idea below. > > > My premise is that the test suite of crates doesn't necessarily pass > > when built and run with a newer rust and that we shouldn't be concerned > > about it. > > > >> You've explained the rationale here: > >> <https://lists.gnu.org/archive/html/guix-devel/2023-10/msg00182.html>, > >> saying we sometimes use a newer Rust than the package tests are > >> expecting; how does it work in the Rust world? Don't they always build > >> even older versions against the most recent compiler? What about the > >> test suites then? Are these not typically run by users/distributions? > > > > In general, since rust expects all of the crates to be in source form, > > the tests are only run by developers when the crate is being developed. > > If someone comes along and uses that crate as a dependency for their > > project then they don't run the tests. If they continue using that crate > > (at that version) for several years then the developer using that older > > crate as a dependency still only compiles the part of the crate they > > need for their project and they only run the tests for their project, > > not for the crates which they've used as dependencies. > > OK. > > > As far as distributions, I can talk for Debian that they only provide > > the crates as -dev packages, that is, as the source crates. They make > > sure that they compile (and probably that they pass the test suite) at > > the time that they are packaged, but no one is distributing pre-compiled > > crates as packages to be used as inputs for further packages. > > I believe that's the more useful comparison for our discussion; I gather > that even -dev crates are built and have their test suite run when > submitted, but since source packages are not rebuilt (they are a static > archive, right?) then there's no checking that the test suite continues > working in time. The source packages are effectively repackaged tarballs. They've made sure there's no issues with the DFSG, maybe applied some patches, built and tested the crates, and then repackaged the tarballs. > > > > For an example of a failing doc-test, from the rust-nalgebra-0.21 crate: > > > > > >Doc-tests nalgebra > > error: unnecessary parentheses around index expression > > --> > > /tmp/guix-build-rust-nalgebra-0.21.1.drv-0/nalgebra-0.21.1/src/linalg/convolution.rs:45:47 > >| > > 45 | conv[i] += self[u_i] * kernel[(i - u_i)]; > >| ^ ^ > >| > > note: the lint level is defined here > > --> > > /tmp/guix-build-rust-nalgebra-0.21.1.drv-0/nalgebra-0.21.1/src/lib.rs:78:9 > >| > > 78 | #![deny(unused_parens)] > >| ^ > > help: remove these parentheses > >| > > 45 - conv[i] += self[u_i] * kernel[(i - u_i)]; > > 45 + conv[i] += self[u_i] * kernel[i - u_i]; > >| > > > > error: unnecessary parentheses around index expression > > -->
Re: [RFC]: Skipping rust crate tests by default
On Thu, Oct 05, 2023 at 03:52:46PM +0300, Efraim Flashner wrote: > Currently for for rust crates we build the crates, run the tests, and > then in %output we only have the license files and a repackaged version > of the source. > > The build system goes: > unpack source > unpack crates > patch shebangs > patch checksums of the crates > 'build > 'package > 'check > 'install > > 'install is clear, it does whatever the install command is. > > 'package repacks the source crate, after we've done any changes to it in > the snippet and later if we've gone and patched paths to binaries or > libraries. In theory this is useful with using these crates in a > GUIX_ENVIRONMENT > > 'check runs the test suite, which fairly often seems to need some > massaging to skip the odd test which fails or to try to skip the doc > tests, which fail far too often. > > 'build sounds like it just builds the package. The first thing it does > it makes sure that all the necessary crates are included in the build > environment. > > IMO the 'build phase is the most important one, it's the one that lets > us know if all the cargo-inputs and cargo-development-inputs are > correct. We don't care if rust-rand-0.6 or rust-nb-connect-1 builds, we > only care that it has the correct inputs so that when we pull it in for > an actual binary or library everything builds correctly. > > I propose changing the cargo-build-system to have '#:tests? #f' by > default and then enable them for packages which have a "clear output". > It will keep the benefits of knowing we have the correct inputs without > worrying about test errors we don't care about. If it fails to build > during its own 'build phase that's actually worth looking into. It will > also cut down the amount of time the CI spends building unneeded rust > crates, and lets us see which ones are actually broken. To add some more context from other places and to try to flesh out more: On Tue, Oct 17, 2023 at 11:41:11AM -0400, Maxim Cournoyer wrote: > Hi Efraim, > > Efraim Flashner writes: > > > IMO rust-team branch is ready to merge. We've updated rust to 1.70, > > librsvg to 2.56.4 and many new and updated packages. We've added a phase > > to the cargo-build-system to fail if it detects pre-built files and > > we've set the cargo-build-system to skip the test phase by default, > > allowing us to make sure that the packages have the correct inputs. With > > these changes I've gotten 100% of the packages built using the > > cargo-build-system to build successfully. > > This sounds good except I don't understand how disabling the tests by > default help to "make sure that the packages have the correct inputs" ? When the tests are disabled, if a package shows red on the CI it means that either: A) there was a bundled shared/static library in the sources which need to be removed B) The inputs weren't correct and need to be fixed. What we're skipping is C) the test suite failed. When we get to the 'build phase of the cargo-build-system, cargo first checks that it has all of the crates listed in the Cargo.toml file, and that all of those crates have all of their (cargo-input) dependencies, and so on. If any of them are missing then the build will fail. This is also why we need to set #:skip-build? #t when we don't include the desired cargo-development-inputs. The change is mainly a quality of life improvement; it decreases the time that guix people and CI spend building these crates, and it makes it easier to see which, if any, rust packages need to be checked for brokenness (with the assumption that a broken or bit-rotted test suite isn't a problem). My premise is that the test suite of crates doesn't necessarily pass when built and run with a newer rust and that we shouldn't be concerned about it. > You've explained the rationale here: > <https://lists.gnu.org/archive/html/guix-devel/2023-10/msg00182.html>, > saying we sometimes use a newer Rust than the package tests are > expecting; how does it work in the Rust world? Don't they always build > even older versions against the most recent compiler? What about the > test suites then? Are these not typically run by users/distributions? In general, since rust expects all of the crates to be in source form, the tests are only run by developers when the crate is being developed. If someone comes along and uses that crate as a dependency for their project then they don't run the tests. If they continue using that crate (at that version) for several years then the developer using that older crate as a dependency still only compiles the part of the crate they need for their project and they only run the tests for their project, not for the crates which they've used as dependencies. As far as distributio
Re: [RFC]: Skipping rust crate tests by default
On Mon, Oct 16, 2023 at 11:47:53AM -0400, Maxim Cournoyer wrote: > Hi Efraim, > > Efraim Flashner writes: > > > Currently for for rust crates we build the crates, run the tests, and > > then in %output we only have the license files and a repackaged version > > of the source. > > > > The build system goes: > > unpack source > > unpack crates > > patch shebangs > > patch checksums of the crates > > 'build > > 'package > > 'check > > 'install > > > > 'install is clear, it does whatever the install command is. > > > > 'package repacks the source crate, after we've done any changes to it in > > the snippet and later if we've gone and patched paths to binaries or > > libraries. In theory this is useful with using these crates in a > > GUIX_ENVIRONMENT > > > > 'check runs the test suite, which fairly often seems to need some > > massaging to skip the odd test which fails or to try to skip the doc > > tests, which fail far too often. > > Why do the doc tests often fail? Is something wrong on our side? As > rust aims to be fully deterministic, unless we stray too far away from > the specified input versions, it seems these failures should not happen > or be reported upstream. Addressing not just the doc tests but some of the failing tests in general: Often it is because it is an older version of a library, released for an older version of rust. Over time rust has been 'tightening' some of their allowed code patterns, meaning that while in the past tests might have passed with a warning, they now fail. There are some packages which haven't honored rust's semver guarantee as strongly as they might have, and those have resulted in some libraries failing when we upgrade some of the more heavily depended upon libraries, like serde. It's possible that we've packaged yanked versions of crates, the importer isn't as careful about that as it could be. I have a patch in the bugtracker to not import yanked crates. > > 'build sounds like it just builds the package. The first thing it does > > it makes sure that all the necessary crates are included in the build > > environment. > > > > IMO the 'build phase is the most important one, it's the one that lets > > us know if all the cargo-inputs and cargo-development-inputs are > > correct. We don't care if rust-rand-0.6 or rust-nb-connect-1 builds, we > > only care that it has the correct inputs so that when we pull it in for > > an actual binary or library everything builds correctly. > > > > I propose changing the cargo-build-system to have '#:tests? #f' by > > default and then enable them for packages which have a "clear output". > > It will keep the benefits of knowing we have the correct inputs without > > worrying about test errors we don't care about. If it fails to build > > during its own 'build phase that's actually worth looking into. It will > > also cut down the amount of time the CI spends building unneeded rust > > crates, and lets us see which ones are actually broken. > > It seems useful to me to have some assurance that each crate packaged in > Guix passes its test suite, so I'm reticent to have a #:tests? #f by > default, while I sympathize with the work that is it given the sheer > amount of Rust crates. > > -- > Thanks, > Maxim > -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: IDEA: missing-tests-pypi-error? condition
On Mon, Oct 09, 2023 at 01:17:10PM -0400, Maxim Cournoyer wrote: > Hi, > > "jgart" writes: > > >> You want `info -f doc/guix.info`. > > > > Ah yes, I actually used that flag once before and had forgotten it... > > FWIW, it works for me even without '-f'. To add in some more similar and useful knowledge, you can do the same thing with man, `man /path/to/man/page.gz` -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
[RFC]: Skipping rust crate tests by default
Currently for for rust crates we build the crates, run the tests, and then in %output we only have the license files and a repackaged version of the source. The build system goes: unpack source unpack crates patch shebangs patch checksums of the crates 'build 'package 'check 'install 'install is clear, it does whatever the install command is. 'package repacks the source crate, after we've done any changes to it in the snippet and later if we've gone and patched paths to binaries or libraries. In theory this is useful with using these crates in a GUIX_ENVIRONMENT 'check runs the test suite, which fairly often seems to need some massaging to skip the odd test which fails or to try to skip the doc tests, which fail far too often. 'build sounds like it just builds the package. The first thing it does it makes sure that all the necessary crates are included in the build environment. IMO the 'build phase is the most important one, it's the one that lets us know if all the cargo-inputs and cargo-development-inputs are correct. We don't care if rust-rand-0.6 or rust-nb-connect-1 builds, we only care that it has the correct inputs so that when we pull it in for an actual binary or library everything builds correctly. I propose changing the cargo-build-system to have '#:tests? #f' by default and then enable them for packages which have a "clear output". It will keep the benefits of knowing we have the correct inputs without worrying about test errors we don't care about. If it fails to build during its own 'build phase that's actually worth looking into. It will also cut down the amount of time the CI spends building unneeded rust crates, and lets us see which ones are actually broken. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: [bug#66343] Add more setups to Guix docs
On Wed, Oct 04, 2023 at 08:55:32PM +, Ekaitz Zarraga wrote: > > It looks good to me. > > Commit? Looks good to me too. Patch pushed! -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: [bug#66343] Add more setups to Guix docs
On Wed, Oct 04, 2023 at 06:47:51PM +, Ekaitz Zarraga wrote:
>
> --- Original Message ---
> On Wednesday, October 4th, 2023 at 18:35, Efraim Flashner
> wrote:
>
>
> > On Wed, Oct 04, 2023 at 06:15:53PM +, Ekaitz Zarraga wrote:
> >
> > > --- Original Message ---
> > > On Wednesday, October 4th, 2023 at 16:18, Efraim Flashner
> > > efr...@flashner.co.il wrote:
> > >
> > > > I think we can mention guix.vim also
> > >
> > > Certainly, do you want to add it yourself?
> > >
> > > Nobody is going to explain it better than you.
> >
> >
> > I tossed in a line or two in the middle of the patch
>
> But you didn't attach, did you?
>
> Or you directly commited?
I commented directly in the middle of the patch.
> +@example
> +guix install vim-fugitive
> +@end example
> +
And of course if you want to interact with Guix directly from inside of
vim, using the built-in terminal emulator, we have our very own
@code{guix.vim} package!
@example
guix install vim-guix-vim
@end example
> +In NeoVim you can even make a similar setup to Geiser using
> +@url{https://conjure.fun/, Conjure} that lets you connect to a running Guile
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
From 410eff90c552977a209db2c56538166ec5455be1 Mon Sep 17 00:00:00 2001
Message-ID:
<410eff90c552977a209db2c56538166ec5455be1.1696452671.git.efr...@flashner.co.il>
From: Ekaitz Zarraga
Date: Mon, 25 Sep 2023 16:16:28 +0200
Subject: [PATCH v2] doc: contributing: Add alternative setups section
Start with Guile Studio and Vim/NeoVim.
* doc/contributing.texi (Alternative Setups): Add section explaining
other setups that are similar to the one in The Perfect Setup
---
doc/contributing.texi | 85 +++
1 file changed, 78 insertions(+), 7 deletions(-)
diff --git a/doc/contributing.texi b/doc/contributing.texi
index 0de47a403b..f7c72634e7 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -23,6 +23,7 @@ Contributing
* Building from Git:: The latest and greatest.
* Running Guix Before It Is Installed:: Hacker tricks.
* The Perfect Setup:: The right tools.
+* Alternative Setups:: Other posible tools that do the job.
* Packaging Guidelines::Growing the distribution.
* Coding Style::Hygiene of the contributor.
* Submitting Patches:: Share your work.
@@ -453,6 +454,83 @@ The Perfect Setup
Emacs Manual} and @ref{Minor Mode,,, debbugs-ug, The Debbugs User
Guide}.
+@node Alternative Setups
+@section Alternative Setups
+
+Alternative setups than Emacs may let you work on Guix with a
+similar development experience and they might work better with the
+tools you currently use or help you make the transition to Emacs.
+
+The options listed below only provide the alternatives to the Emacs
+based setup, which is the most widely used in the Guix community. If
+you want to really understand how is the perfect setup for Guix
+development supposed to work, we encourage you to read the section
+before this regardless the editor you choose to use.
+
+@menu
+* Guile Studio::First step in your transition to Emacs.
+* Vim and NeoVim:: When you are evil to the root.
+@end menu
+
+@node Guile Studio
+@subsection Guile Studio
+
+Guile Studio is a pre-configured Emacs with mostly everything you need
+to start hacking in Guile. If you are not familiar with Emacs it makes
+the transition easier for you.
+
+@example
+guix install guile-studio
+@end example
+
+Guile Studio comes with Geiser preinstalled and prepared for action.
+
+@node Vim and NeoVim
+@subsection Vim and NeoVim
+
+
+Vim (and NeoVim) are also packaged in Guix, just in case you decided
+to go for the evil path.
+
+@example
+guix install vim
+@end example
+
+If you want to enjoy a similar development experience to that in the perfect
+setup, you should install several plugins to configure the editor. Vim (and
+NeoVim) have the equivalent to Paredit,
+@uref{https://www.vim.org/scripts/script.php?script_id=3998,
+@code{paredit.vim}}, that will help you with the structural editing of Scheme
+files (the support for very large files is not great, though).
+
+@example
+guix install vim-paredit
+@end example
+
+We also recommend that you run @code{:set autoindent} so that your code is
+automatically indented as you type.
+
+For the interaction with Git,
+@uref{https://www.vim.org/scripts/script.php?script_id=2975
+@code{fugitive.vim}} is the most commonly used plugin:
+
+@example
+guix install vim-fugitive
+@end example
+
+And of course if you want to interact with Guix directly from inside of
+vim, using the built-in terminal emulator, we hav
Re: [bug#66343] Add more setups to Guix docs
On Wed, Oct 04, 2023 at 06:15:53PM +, Ekaitz Zarraga wrote: > > > --- Original Message --- > On Wednesday, October 4th, 2023 at 16:18, Efraim Flashner > wrote: > > > > I think we can mention guix.vim also > > > Certainly, do you want to add it yourself? > > Nobody is going to explain it better than you. I tossed in a line or two in the middle of the patch -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: [bug#66343] Add more setups to Guix docs
> +
> +@example
> +guix install vim-paredit
> +@end example
> +
> +We also recommend that you run @code{:set autoindent} so that your code is
> +automatically indented as you type.
> +
> +For the interaction with Git,
> +@uref{https://www.vim.org/scripts/script.php?script_id=2975
> +@code{fugitive.vim}} is the most commonly used plugin:
> +
> +@example
> +guix install vim-fugitive
> +@end example
> +
And of course if you want to interact with Guix directly from inside of
vim, using the built-in terminal emulator, we have our very own
@code{guix.vim} package!
@example
guix install vim-guix-vim
@end example
> +In NeoVim you can even make a similar setup to Geiser using
> +@url{https://conjure.fun/, Conjure} that lets you connect to a running Guile
> +process and inject your code there live (sadly it's not packaged in Guix
> yet).
> +
> +
> @node Packaging Guidelines
> @section Packaging Guidelines
>
> @@ -1257,13 +1327,6 @@ Formatting Code
> @noindent
> @xref{Invoking guix style}, for more information.
>
> -@cindex Vim, Scheme code editing
> -If you are editing code with Vim, we recommend that you run @code{:set
> -autoindent} so that your code is automatically indented as you type.
> -Additionally,
> -@uref{https://www.vim.org/scripts/script.php?script_id=3998,
> -@code{paredit.vim}} may help you deal with all these parentheses.
> -
> We require all top-level procedures to carry a docstring. This
> requirement can be relaxed for simple private procedures in the
> @code{(guix build @dots{})} name space, though.
>
> base-commit: 284f8508bebcae510261c7c223dc28f9badf87ce
> --
> 2.41.0
>
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
Re: ActtivityPub and Haunt
On Thu, Sep 28, 2023 at 10:03:13PM +0200, Reza Housseini wrote: > > But I will hands-down say that Haunt was an EXCELLENT environment for > > writing ap.rocks. The implementation guide page especially is a great > > demonstration of Haunt's power: > > > >https://activitypub.rocks/implementation-report/ > > pretty cool stuff indeed! I also checked out the software mentioned on the > page, are there any attempts at packaging some of the software e.g. > microblog.pub? Looks like I was starting to work on it at some point. Not sure why I stopped. https://git.sr.ht/~efraim/my-guix/tree/master/item/wip/microblog-pub.scm -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Guix related things in Germany at the end of October/start of November
On Thu, Sep 28, 2023 at 11:58:10PM +0200, Ricardo Wurmus wrote: > > Christopher Baines writes: > > > PackagingCon [1] is happening in Berlin on the 26th to the 28th of > > October […] > > Is anyone else planning to attend these events, or otherwise interested > > in meeting up in Germany around these dates? > > I don’t seem to have anything planned around the time of PackagingCon, > so should a little Guix meeting happen in Berlin I’d try to make time to > stop by for a while. I think I got everyone in the list. It looks like I won't be traveling with wife & kids this trip. PackageCon is Thursday & Friday in Berlin with a hackday on Saturday. Then Reproducible Builds is Tuesday, Wednesday, Thursday in Hamburg. Saturday hackathon entrance fee is 5€ I think but it comes with the location and I assume outlets and internet and seems like a good idea to repurpose it for a meetup. Or we can meetup for food at some point. I don't have any ideas yet for Hamburg, except that I don't know if Chris has any plans on when he's heading over from Berlin and I haven't booked anything yet. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Emacs and Guix (was Re: The e(macs)lephant in the room and the Guix Bang)
On Mon, Sep 25, 2023 at 10:34:11PM +0200, Simon Tournier wrote: > Hi, > > On Mon, 25 Sep 2023 at 14:09, MSavoritias wrote: > > > when its the same people that push Emacs as the "blessed" way to > > contribute (as in the guix manual) > > Just to point 1. Guix is part of GNU – for the good, the bad and the > ugly – so 2. editors developed under the GNU umbrella are autopromoted – > GNU Emacs is one, GNU nano would be another one. Well, for what it is > worth, I feel such autopromotion as some consistency. > > BTW, Efraim is GNU Guix co-maintainer and demoed the use of Vim for Guix > development: > > https://10years.guix.gnu.org/video/using-vim-for-guix-development/ > > Somehow, when one co-maintainer publicly demoed using not-Emacs makes a > point that there is no “blessed“ editors – and the part dedicated for > Emacs in the manual seems just an autopromotion of GNU products that > contributors enjoy for cooking – dogfooding. ;-). Oh no! My very embarrassing talk where I was missing that magic 1 or 2 packages from my manifest and then everything fell apart. I think I need to watch it again myself and then try redoing it at home. > Contributions in the Guix manual or in the cookbook about how to setup > other editors than Emacs are very welcome. This is the big part. I have a setup that works reasonably well for me and I haven't done a good job sharing it with others so they can see some of the other options. IIRC one of the big things I wanted to show was using ctags with Guix to jump quickly between packages or to other definitions. Right now the tags make target is a stub, I (or someone else even) should see about adjusting that so 'make tags' works for the project. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Cross compilation status
On Sun, Sep 10, 2023 at 04:59:35PM +0200, Liliana Marie Prikler wrote: > Hi Mathieu, > > Am Sonntag, dem 10.09.2023 um 11:14 +0200 schrieb Mathieu Othacehe: > > I have CC'ed members of the python, java, ruby, rust, r, haskell and > > emacs teams. Any plans adding cross-compilation support to your > > build-system, barriers to overcome? > For Emacs, there are layers of problems. First things first, we are > only doing byte compilation atm, which may or may not be arch-dependant > based on stuff like endianness. For native compilation, there is the > thing that even a slightly differently configured emacs won't load the > packages you've just compiled without compiling it natively on its own. > Granted, if we want to do cross-compilation, having just the bytecode > might already be "good enough", but I wanted to throw this out there. > > I think we'd need some support from Emacs proper before we can start > implementing cross builds. I will note that the only big-endian architecture which we "support" is 32-bit powerpc, so we don't have to worry that much about wrong endianness. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: How can we decrease the cognitive overhead for contributors?
On Fri, Sep 08, 2023 at 04:20:30PM +0200, Ricardo Wurmus wrote: > > Josselin Poiret writes: > > > Regarding the “mom argument”, I would disagree and say that this is > > completely related: interruptions are more costly, you're more likely to > > have less attention span, and overall you probably don't want to commit > > to 20 steps just to send a contribution. > > That’s exactly it. > > I’m a parent working a full-time job and I’m easily overwhelmed by what > I would have considered to be simple processes 20 years ago. All these > simple and totally “easy” processes add up and – oops it’s 11:30pm > already and I had been feeling exhausted since 10am… > > There’s an hour before I pass out — what will I do with it? This thread > is about how we can reduce overhead; for me that would mean to have > certain checks automated, or to have commit messages be generated so I > only need to read them to sign off on them, etc. > > We all may gain from streamlining our processes. Personally, I see the > biggest problem in a lack of effective tools for reviewers, which > results in stretching out contribution interactions over weeks, months, > or years. This, to me, would be a way to increase the weight of the > rewards on the unbalanced scales that are overwhelmed by chores on the > other side. On the other hand, if we do manage to automate writing of commit messages, it makes one less thing for committers to manually fix before pushing the commit. The last couple of contributions I pushed had green checks on qa.guix.gnu.org and I felt at a bit of a loss what to do while checking it over. After checking that it was in fact green I double-checked the commit message and then also some of the layout of the commit and the package itself, and made sure it passed `guix lint`. More resources for qa.guix.gnu.org would let us build more patches more quickly. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Cross compilation status
On Sun, Sep 10, 2023 at 11:14:29AM +0200, Mathieu Othacehe wrote: > > Hello, > > In order for Guix to become an alternative to tools such as Yocto and > Buildroot, having most or all our packages cross-compiling is a > prerequisite. > > Here is a status of cross-compilation in Guix. For cross-compilation to > work, the build-system needs to support cross-compilation. > > The following build-systems explicitly refuse cross-compiling packages: > > > ocaml: 61 > haskell: 812 > maven: 2 > chicken: 12 > node: 57 > emacs: 1370 > dune: 289 > android-ndk: 12 > waf: 21 > julia: 300 > pyproject: 433 > r: 2441 > cargo: 3535 > ruby: 597 > rebar: 22 > scons: 15 > rakudo: 22 > agda: 6 > ant: 559 > python: 2488 > Cross-compilation KO: 13054 > --8<---cut here---end--->8--- > > Over the 28076 packages in Guix, 15065 are part of build-systems with > cross-compilation support and 13054 are part of build-systems without > cross-compilation support. > > Overall 46.5% of our packages will refuse to cross-compile with errors > such as: > > --8<---cut here---start->8--- > mathieu@meije ~$ guix build --target=aarch64-linux-gnu librsvg > guix build: error: gnu/packages/gnome.scm:3500:2: librsvg@2.54.5: build > system `cargo' does not support cross builds > --8<---cut here---end--->8--- > > I'd like to help converge towards the situation where all build-systems > support cross-compilation. > > I have CC'ed members of the python, java, ruby, rust, r, haskell and > emacs teams. Any plans adding cross-compilation support to your > build-system, barriers to overcome? I suspect librsvg is especially a problem since it is almost always pulled in with any sort of image building. I haven't looked at it closely yet, but I believe that in order to support cross-compilation support in rust we'll need to enable more targets, which will increase the build time for the final rust and the final output size. Considering that nothing built with rust links to it, I'm not convinced this is a problem. We will likely see people confused that we have a rust with cross-compiling abilities but with windows- and mac-specific (pre-compiled) libraries removed, so it wouldn't be able to cross-compile to those (or some other) platforms without changes. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Cross compilation status
On Sun, Sep 10, 2023 at 11:14:29AM +0200, Mathieu Othacehe wrote: > > I have CC'ed members of the python, java, ruby, rust, r, haskell and > emacs teams. Any plans adding cross-compilation support to your > build-system, barriers to overcome? Speaking as the one who added the rakudo build system and the perl6 packages, IMO all the perl6 packages should be removed and also the rakudo-build-system. I don't believe most of the packages have built for more than a year and I don't believe they have ever had any adoption. If it turns out that Raku (no longer perl6 for several years now) would make use of the current rakudo-build-system then we can always revert removing it. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: How can we decrease the cognitive overhead for contributors?
On Fri, Sep 08, 2023 at 11:53:43AM +0200, Giovanni Biscuolo wrote: > Hello Katherine, > > Katherine Cox-Buday writes: > > [...] > > > By "standard" I mean the GNU Changelog format > > (https://www.gnu.org/prep/standards/standards.html#Change-Logs). As > > in: it's expected that commit messages use this format. > > [...] > > > In my response I was trying to point out a flaw in your comparison: that > > with style guidelines, which are also complicated, there is usually a > > formatter that will do it for me, or a linter that will tell me that > > something is not meeting the standard. This is because languages have > > grammars, and linters have higher-order system grammars. > > AFAIU you are talking about the "Formatting Code" /subset/ of a "Coding > style", because there is no linter that will tell you if you are > following the subset called "Data Types and Pattern Matching" [1]: am I > wrong? > > Back to the git commit message formatting: please can you provide us > with one or two examples of how a commit message should be formatted and > what linter is available for that syntax? > > [...] > > > Here is my channel with things I intend to upstream, but haven't, > > largely because of this friction. > > By "this friction" you mean you miss a linter for commit messages? > > Or do you mean you do not agree with the style requested by Guix (and > GNU) for the commit messages? > > You are obviously free not to contribute your patches upstream but the > fact that you decided not to because it's "too hard" (my executive > summary about your complaints about Change Log content rules) to write > commit messages suitable for contribution it _not_ a Guix maintainers > fault, not at all. > > Obviously everyone is free to comment, ask for clarifications or > proposing **patches**, but it's not fair to say "I'm not contributing > largerly because I've a specific friction with the rules about commit > messages" (again, my executive summary). > > [...] > > Ciao, Gio' That wasn't my read of it at all. I too have many packages which I haven't upstreamed. One of the major pushes that I did was cleaning up mailman and pushing them to Guix. I had just finished working on it earlier in the week and it turned out I didn't actually need it anymore, but I figured better in Guix than out. It was either one or two 8 hour days of reviewing my own patches, making sure they all built correctly, and then finally committing them. I also have almost 500 go packages which I don't intend to upstream. I'm package them and update them occasionally when trying to package some big application like gitea or keybase or tailscale or gotosocial, but the effort to go through and see which packages are ACTUALLY needed and to clean up everything, it's just too much for me. I suppose this could be construed as "I'm not contributing these packages because I don't like go" but that's not the whole of it. And by rephrasing it like that takes out the nuance of other bits of why I haven't worked on those packages and neuters the discussion about why these are my packages instead of our packages. As far as commit messages, I've found that the script in etc/committer.scm to be very nice, even if there are plenty of cases where it doesn't do the job. I do think there's room for improvement and that may be one of the things we can do to make contributing easier. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: CI job for lisp-team branch
On Thu, Sep 07, 2023 at 12:31:39PM +, Guillaume Le Vaillant wrote:
> Efraim Flashner skribis:
>
> > On Wed, Sep 06, 2023 at 03:47:01PM +0300, Efraim Flashner wrote:
> >>
> >> I commented on IRC but figured I should post to the mailing list.
> >>
> >> I tested sbcl@2.3.8 on riscv64-linux and the build failed in the contrib
> >> section. I see the patch was removed, presumably because it was included
> >> in the upstream release. When I finish my current build target(s) I'll
> >> see what needs to be done there.
> >
> > Re-adding the patch failed hard when applying the patch. I tested
> > downgrading sbcl to 2.3.7 and that built everything without any trouble
> > on riscv64-linux.
>
> The patch was a backport from upstream (commit
> 8704f528f227f587d0e06dfd2f807aeca7a69a71), so it is already in the
> sources for sbcl 2.3.8.
>
> What error do you get when building on riscv64? Maybe we could report it
> upstream as I have not seen anything about riscv64 fixes in the commit
> history of sbcl since version 2.3.8.
//entering make-target-contrib.sh
make: Entering directory '/tmp/guix-build-sbcl-2.3.8.drv-0/sbcl-2.3.8/contrib'
make: *** No rule to make target 'sb-posix.fasl', needed by 'all'.
make: *** No rule to make target 'sb-bsd-sockets.fasl', needed by 'all'.
make: *** No rule to make target 'sb-introspect.fasl', needed by 'all'.
make: *** No rule to make target 'sb-cltl2.fasl', needed by 'all'.
make: *** No rule to make target 'sb-aclrepl.fasl', needed by 'all'.
make: *** No rule to make target 'sb-sprof.fasl', needed by 'all'.
make: *** No rule to make target 'sb-capstone.fasl', needed by 'all'.
make: *** No rule to make target 'sb-rotate-byte.fasl', needed by 'sb-md5.fasl'.
make: *** No rule to make target 'sb-executable.fasl', needed by 'all'.
make: *** No rule to make target 'sb-gmp.fasl', needed by 'all'.
make: *** No rule to make target 'sb-concurrency.fasl', needed by
'sb-queue.fasl'.
make: *** No rule to make target 'sb-rt.fasl', needed by 'all'.
make: *** No rule to make target 'asdf.fasl', needed by 'sb-grovel.fasl'.
make: Target 'all' not remade because of errors.
make: Leaving directory '/tmp/guix-build-sbcl-2.3.8.drv-0/sbcl-2.3.8/contrib'
real0m0.046s
user0m0.033s
sys 0m0.014s
error: in phase 'build': uncaught exception:
%exception #< program: "sh" arguments: ("make.sh" "clisp"
"--prefix=/gnu/store/yz18dz67jmy2vmvilxm1pbfdw8g1yky2-sbcl-2.3.8"
"--dynamic-space-size=3072" "--with-sb-core-compression"
"--with-sb-xref-for-internals" "--without-sb-simd") exit-status: 2 term-signal:
#f stop-signal: #f>
phase `build' failed after 11808.1 seconds
command "sh" "make.sh" "clisp"
"--prefix=/gnu/store/yz18dz67jmy2vmvilxm1pbfdw8g1yky2-sbcl-2.3.8"
"--dynamic-space-size=3072" "--with-sb-core-compression"
"--with-sb-xref-for-internals" "--without-sb-simd" failed with status 2
That's why I tried to reapply the patch, when I saw that I figured the
patch was still needed. I've attached a compressed log incase for
posterity.
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
sbcl-2.3.8-riscv64.log.gz
Description: application/gunzip
signature.asc
Description: PGP signature
Re: Guix related things in Germany at the end of October/start of November
On Tue, Sep 05, 2023 at 06:28:09PM +0100, Christopher Baines wrote: > Hey, > > PackagingCon [1] is happening in Berlin on the 26th to the 28th of > October, and the Reproducible Builds summit is happening in Hamburg on > the 31st of October to the 2nd of November. > > 1: https://packaging-con.org/ > 2: https://reproducible-builds.org/events/hamburg2023/ > > I've had a talk proposal on QA and Guix accepted for PackagingCon, and > I'm planning to attend the Reproducible Builds summit as well. Plus I'll > try to make some time to do some tourist stuff while I'm in Germany as > well. > > Is anyone else planning to attend these events, or otherwise interested > in meeting up in Germany around these dates? I'll be there! Feedback on my talk proposal was that it was perhaps a bit too niche, so I get to enjoy the conference without giving a talk. Haven't finalized my dates yet but I'm planning on coming in to Berlin on the Wednesday (25th?) so I can be there for PackagingCon and then my wife and kids are flying in on Sunday and we're going to take the train to Hamburg. No plans yet about which touristy things to do. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: CI job for lisp-team branch
On Wed, Sep 06, 2023 at 03:47:01PM +0300, Efraim Flashner wrote: > On Mon, Sep 04, 2023 at 09:27:44AM +, Guillaume Le Vaillant wrote: > > Hi. > > I created a lisp-team branch to work one some updates for clisp and > > sbcl. Could someone with admin access to the CI things add a job for it? > > Thanks. > > I commented on IRC but figured I should post to the mailing list. > > I tested sbcl@2.3.8 on riscv64-linux and the build failed in the contrib > section. I see the patch was removed, presumably because it was included > in the upstream release. When I finish my current build target(s) I'll > see what needs to be done there. Re-adding the patch failed hard when applying the patch. I tested downgrading sbcl to 2.3.7 and that built everything without any trouble on riscv64-linux. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: CI job for lisp-team branch
On Mon, Sep 04, 2023 at 09:27:44AM +, Guillaume Le Vaillant wrote: > Hi. > I created a lisp-team branch to work one some updates for clisp and > sbcl. Could someone with admin access to the CI things add a job for it? > Thanks. I commented on IRC but figured I should post to the mailing list. I tested sbcl@2.3.8 on riscv64-linux and the build failed in the contrib section. I see the patch was removed, presumably because it was included in the upstream release. When I finish my current build target(s) I'll see what needs to be done there. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: How can we decrease the cognitive overhead for contributors?
On Mon, Sep 04, 2023 at 10:56:39AM +0200, Ricardo Wurmus wrote: > > Vagrant Cascadian writes: > > > The only thing clunky about this particular aspect of the workflow > > described is the fact that the guix community (maintainers?) have > > decided on a one patch per mail policy with a cover letter, rather than > > submitting the patches as attachments in the initial mail. > > You are right. When I started contributing I actually did attach all > patches in one email. I wonder why we stopped doing that. I believe some found it easier to pipe multiple emails to git am than to pipe attachments. From mutt there's no difference for me. > I’ll say that many of my gripes with (the GNU instance of) Debbugs are > due to the fact that we can’t customize it to better suit our needs — it > is a shared resource with a complicated maintenance story. So all > changes went into Mumi as crude workarounds. I think this is a dead end > and we’d be better off leaving the shared GNU instance of Debbugs > behind. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: btrfs recommended layout for snapshots?
On Wed, Aug 16, 2023 at 10:10:25AM +0200, Nicolas Graves wrote: > On 2023-08-14 16:41, Nicolas Graves wrote: > > >> - either not snapshotting the rootfs / at all, with the hypothesis that > >> we get it back entirely from config files. Is that possible ? Is there > >> information in / (I think of /etc in particular) that is saved, not > >> temporary and not managed by guix system that would justify that we > >> want to snapshot / at all? > >> This would allow to simply care about only a few "user data" > >> directories, and be sure to not miss anything when there's a need to > >> restore the state. > >> > >> I can't find easily a case of successful use of the second > >> configuration, but would be glad to find one, as well as some discussion > >> about what would be a recommended way to secure the state beyond > >> dotfiles. > > > > I've found some equivalent information on the NixOS side here : > > https://nixos.wiki/wiki/Impermanence > > > > Some (rare) directories indeed seem that would better be saved because > > their information is useful for the system, in the case of NixOS, it > > seems to be "/etc/nixos", "/etc/NetworkManager" (for system > > connections), "/var/log", "/var/lib". > > Thank you all for your answers! > > I actually managed to replicate the impermanence functionality by > creating btrfs subvolumes for "/etc/guix" "/etc/NetworkManager" > "/var/log" "/var/lib" "/var/guix" and 4 light patches (I'm currently > trying to remove one I think might be not necessary, will send them > here. They basically amount to create directories when they might not be > present or allowing the root "none" to pass to the mount call). With impermanence I'd save /etc/ssh so you don't have to regenerate keys each time. Or perhaps look into SSH Certificate Authority if you want to go crazy with it. > This allows me to start with a tmpfs rootfs, and the only annoying thing > I experience not is that the root password is not set (the account > password is set though, since we can include that in the definition of > an os). Boot time is a bit higher since /etc/machine-id and some other > files have to be recreated, but that's not really noticeable. > > I don't know if I'll stick to this "impermanent" mode, but at least this > gives me the right information about what directories are worth > considering for snapshots (doesn't mean they are worth snapshotting), > and what a "precise" btrfs layout on Guix would have to consider. > > I guess it's possible to do the same with my home as well (thus only > saving actual data and not consecutive linking metadata), but that might > require some more time and fine-grained applications considerations. > > @Efraim : I don't have a /etc/guix/machines.scm to save (I don't have an > offloading deamon set for now), IIUC this means I could be doing as good > without "/etc/guix". What are the signing keys used for? The signing keys are used when offloading derivations to other machines. There's an example usage, with saving them for later, in the hurd-vm-service-type and the secret-root (by default in /etc/childhurd). > One weakness from this impermanence feature is that it's actually > application-dependent. For guix-system it's not very damaging (except if > we want very low-level optimizations, like setting nodatacow on > subvolumes with databases etc), but for guix-home, it makes things much > more difficult. @Andrew Tropin : maybe that's something we could in RDE in > a state-btrfs in (gnu home-services state) if we find a way to migrate > directories to subvolumes safely and reproducibly. > > -- > Best regards, > Nicolas Graves -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: btrfs recommended layout for snapshots?
On Mon, Aug 14, 2023 at 04:41:52PM +0200, Nicolas Graves via Development of GNU Guix and the GNU System distribution. wrote: > > > - either not snapshotting the rootfs / at all, with the hypothesis that > > we get it back entirely from config files. Is that possible ? Is there > > information in / (I think of /etc in particular) that is saved, not > > temporary and not managed by guix system that would justify that we > > want to snapshot / at all? > > This would allow to simply care about only a few "user data" > > directories, and be sure to not miss anything when there's a need to > > restore the state. > > > > I can't find easily a case of successful use of the second > > configuration, but would be glad to find one, as well as some discussion > > about what would be a recommended way to secure the state beyond > > dotfiles. > > I've found some equivalent information on the NixOS side here : > https://nixos.wiki/wiki/Impermanence > > Some (rare) directories indeed seem that would better be saved because > their information is useful for the system, in the case of NixOS, it > seems to be "/etc/nixos", "/etc/NetworkManager" (for system > connections), "/var/log", "/var/lib". > > However, I have much more files that aren't linked in the store, > especially in the /etc directory (at least 20 files). > > Has anybody tried to do something like this on Guix? I'm still not using most of the features of btrfs, just compression. Inside /etc/guix /etc/guix/acl is managed with the guix-service-type. IMO the signing keys should be rotated if you reload a machine (or at least properly securing them is more effort than is worthwhile), and /etc/guix/machines.scm isn't secret. I can't think of anything else in /etc I'd want besides /etc/guix/machines.scm. With that in mind, the only thing I could see snapshotting is /home, and living with the knowledge that I might have to adjust or remove some symlinks when rolling back. As far as what inside /home/ is worth backing up and what isn't, I suppose that depends on their use of guix-home or if they want to save space by not backing up ~/.cache or ~/.var or the like. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Can ALPS be included in the Guix repo? The question is about the licenses.
On Sat, Aug 12, 2023 at 04:03:31PM +0500, nigko wrote: > Hello Guix! > > The ALPS project* (Algorithms and Libraries for Physics Simulations) > https://web.archive.org/web/20210508050408/https://alps.comp-phys.org/mediawiki/index.php/Main_Page > is an open source effort aiming at providing simulation codes for strongly > correlated quantum mechanical systems as well as C++ libraries for > simplifying the development of such code. > > According to https://alps.comp-phys.org/mediawiki/index.php/Licensing the > ALPS _Libraries_ are available for _academic and non-commercial_ use under > the terms of the ALPS _Library_ License version 1.0, > > https://web.archive.org/web/20210506121129/https://alps.comp-phys.org/static/software/ALPS/LICENSE.txt/, > > the ALPS _Applications_ under the ALPS _Application_ License version 1.0, > > https://web.archive.org/web/20210512081507/https://alps.comp-phys.org/static/software/applications/LICENSE.txt/. > > I wonder can ALPS be included in the Guix repo? My concern is in the > licenses. In particular, the ALPS licenses state that the ALPS is for > "non-commercial academic use", but according to > https://www.gnu.org/philosophy/free-sw.html "a free program must be > available for commercial use, commercial development, and commercial > distribution", which are in the contradiction. > > Regards, > N Y > > *Since 2022-10-21 the project is being dormant, > https://green.physics.lsa.umich.edu/alps_legacy/index.php?title=Main_Page > Placing the limitation of 'academic and non-commercial' the license is non-free and cannot be included in Guix proper. If something depends on it that you're looking to upstream it'll need to be buildable without that library. I apologize for being the bearer of sad news. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: shepherd respawn frequency
On Sun, Jul 02, 2023 at 10:01:26PM +0200, Ludovic Courtès wrote: > Hi! > > Attila Lendvai skribis: > > > would the shepherd maintaners (looking at you Ludo :) accept a change that > > introduces a new field into called RESPAWN-DELAY, and issue a > > fiber sleep in RESPAWN-SERVICE when it is not #false, and the daemon > > process quits unexpectedly? > > We could do that. It never occurred to me that this is something one > would want to have though. My reasoning is that if you mark a service > as respawnable, then you really want it to be respawned as soon as it > fails, not 5 seconds later. > > Do you have a motivating example in mind (a daemon) to share? > > Thanks, > Ludo’. > If you want to make sure that something is really gone and cleaned up before trying again. Or an artificial delay, say while waiting for the correct network interface to come up. Or even just `mbsync -a && exit 1 || exit 1` -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Guix / Nix Benchmarks
On Mon, Jun 19, 2023 at 02:55:21PM -0400, kiasoc5 wrote: > On 6/19/23 08:54, Nicolas Graves via Development of GNU Guix and the GNU > System distribution. wrote: > > > > One of the criticism that can be read online about Guix (compared to > > Nix) is its speed. I have never tried Nix and probably won't in a near > > future, but I was wondering if some work has been made to compare them > > on basic tasks (package installation, removal...) (the reason why I ask > > is to be able to give an honest answer to someone hesitating between > > both). > > > > At least package installation is faster with Nix. One reason is that Hydra > (their "substitute server") has faster download speeds compared to > CI/Bordeaux, likely due to multiple geographical locations/mirrors. I believe on the Nix side that includes a ~$9000/month bill for AWS. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: FSDG issues of SCUMMVM-based games
On Tue, Jun 20, 2023 at 06:30:26AM +0200, Liliana Marie Prikler wrote: > Am Sonntag, dem 18.06.2023 um 21:07 +0200 schrieb Denis 'GNUtoo' > Carikli: > > [...] > > > Didn't you say that a hello world for scummvm exists? > > I don't know. There is a template for AGI games but the license is > > strange too, and it also requires some software to build it, and I've > > no idea if it's compatible with QT AGI, and I've also no idea if QT > > AGI works, doesn't have nonfree dependencies, etc. > > > > So that makes things way more complicated because here it probably > > requires a lot of work to confirm that it's possible or not possible > > to develop programs that run inside ScummVM with free software. > I see we're hitting a recurring pattern of not knowing things. This is > not aided by my personal disinterest for ScummVM, but I have to weigh > that disinterest against the potential interest of thousands of users > who are likely to only discover this argument to have taken place after > we've reached a conclusion. > > Note, that this discussion started IIRC a year ago and we have > practically known about actually existing FSDG violations since then. > My approach here is quite simple and pragmatic: Remove the games which > obviously violate the FSDG (that is all the games currently depending > on ScummVM as far as I know), but keep ScummVM for now to allow folks > to experiment. If in some one to five years we still find no practical > way of using ScummVM with only free software, that might be a reason to > remove it then. > > WDYT? This sounds like a sensible resolution to me. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: 02/03: gnu: openblas: Update architectures we provide substitutes for.
On Sat, Jun 03, 2023 at 08:12:48PM +0100, Christopher Baines wrote: > > Efraim Flashner writes: > > > On Fri, Jun 02, 2023 at 11:03:42PM +0100, Christopher Baines wrote: > >> > >> guix-comm...@gnu.org writes: > >> > >> > efraim pushed a commit to branch master > >> > in repository guix. > >> > > >> > commit 076688fa1e41a09f034a80e1a593bac43f1f1482 > >> > Author: Efraim Flashner > >> > AuthorDate: Thu Jun 1 11:06:00 2023 +0300 > >> > > >> > gnu: openblas: Update architectures we provide substitutes for. > >> > > >> > * gnu/packages/maths.scm (openblas)[arguments]: Adjust the > >> > substitutable? > >> > flag to only not provide substitutes when building for powerpc-linux. > >> > Adjust the comment accordingly. > >> > --- > >> > gnu/packages/maths.scm | 11 ++- > >> > 1 file changed, 2 insertions(+), 9 deletions(-) > >> > >> I've been looking at why armhf-linux substitute availability has been > >> dropping recently, and I think this change triggered a lot of > >> rebuilds. Could this have gone to core-updates? > >> > >> → guix refresh -l openblas > >> Building the following 2282 packages would ensure 5596 dependent packages > >> are rebuilt: ... > > > > It's not that it's triggered rebuilds, but that it's triggered builds. > > It's also triggered builds on powerpc64le and riscv64. Before any > > package which had openblas as a transitive dependency wasn't built by > > the CI because it wasn't substitutable¹. People still have the option of > > using package transformations to use openblas tuned for the cortex a7 or > > a15 on armhf, but in reality this just unlocks substitutes for those > > ~5600 packages which wasn't available before. > > > > ¹ We saw this in the past briefly in the past when openzfs made its way > > as a dependency to qemu and through that to Gnome. > > Ok, so the documentation does mention "rebuilding", and I do see that > indeed ci.guix.gnu.org doesn't build not substitutable things. > > Although I think it doesn't apply recursively. Take qjson, guix refresh > -l tells me it's dependent on openblas, and looking back at say this > output [1] for powerpc64le-linux, that's available from both > ci.guix.gnu.org. Which makes sense, as that derivation is substitutable, > even though one of it's inputs isn't. > > 1: > https://data.guix.gnu.org/gnu/store/fibiwzyz8s899ccpix5zs6r2pcdpxk5b-qjson-0.9.0 > > Maybe on the client side this works differently, and guix won't > substitute things which have a non substitutable input? > > Assuming ci.guix.gnu.org was building things for armhf-linux, I think > this would have still caused ~5596 rebuilds, and as I say, I think for > systems like powerpc64le-linux, I think it did cause ~5596 > rebuilds. I looked into it more. First I ran on master: './pre-inst-env guix build --no-grafts --system=armhf-linux openblas -d' /gnu/store/whi4yhiw2b0c0i3n6l8s0qfcphkvbzg4-openblas-0.3.20.drv Then I locally reverted the patch expanding the architectures where we provided substitutes: /gnu/store/1m57z8jkbf6gz7qlbw3ws4ayl0ln9602-openblas-0.3.20.drv Then I locally reverted the patch adjusting the make-flags: /gnu/store/1m57z8jkbf6gz7qlbw3ws4ayl0ln9602-openblas-0.3.20.drv It seems I was wrong, changing the #:substitutable? flag _does_ change the derivation of the package. I also checked the substitutes and saw that bordeaux did (and does) have substitutes for the non-substitutable version, showing that it was built before. I also checked for powerpc64le, to see if perhaps cuirass worked a different way and honored the #:substitutable flag by not building it there, and it too has substitutes for both versions of openblas. I didn't check for riscv64 but I assume the case is the same with a changing derivation. So obviously if I had realized this would cause ~5596 rebuilds per affected arch I wouldn't have pushed the patch. I should've checked the derivation before and after to make sure it didn't change. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: 02/03: gnu: openblas: Update architectures we provide substitutes for.
On Fri, Jun 02, 2023 at 11:03:42PM +0100, Christopher Baines wrote: > > guix-comm...@gnu.org writes: > > > efraim pushed a commit to branch master > > in repository guix. > > > > commit 076688fa1e41a09f034a80e1a593bac43f1f1482 > > Author: Efraim Flashner > > AuthorDate: Thu Jun 1 11:06:00 2023 +0300 > > > > gnu: openblas: Update architectures we provide substitutes for. > > > > * gnu/packages/maths.scm (openblas)[arguments]: Adjust the > > substitutable? > > flag to only not provide substitutes when building for powerpc-linux. > > Adjust the comment accordingly. > > --- > > gnu/packages/maths.scm | 11 ++- > > 1 file changed, 2 insertions(+), 9 deletions(-) > > I've been looking at why armhf-linux substitute availability has been > dropping recently, and I think this change triggered a lot of > rebuilds. Could this have gone to core-updates? > > → guix refresh -l openblas > Building the following 2282 packages would ensure 5596 dependent packages are > rebuilt: ... It's not that it's triggered rebuilds, but that it's triggered builds. It's also triggered builds on powerpc64le and riscv64. Before any package which had openblas as a transitive dependency wasn't built by the CI because it wasn't substitutable¹. People still have the option of using package transformations to use openblas tuned for the cortex a7 or a15 on armhf, but in reality this just unlocks substitutes for those ~5600 packages which wasn't available before. ¹ We saw this in the past briefly in the past when openzfs made its way as a dependency to qemu and through that to Gnome. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Do substitutes download slowly for you? / Speeding up substitute delivery/mirrors
On Thu, May 25, 2023 at 02:52:24PM +0100, Christopher Baines wrote: > Hey! > > I was reminded again about substitute download speeds outside of Europe > again today. It looks like I'm a bit later than most of the other responses. > Once again it would be good to gather some data on this, so here are > some test commands. I'm interested to see how France compares with > either the US or Singapore depending on your location. If you think that > none of these locations serve you well, then please say that plus give > some indication of what download speeds you see for things that download > quickly. > > France:wget > https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 (ins)efraim@3900XT /tmp$ wget https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 -O stellarium-france --2023-05-29 14:54:04-- 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: ‘stellarium-france’ stellarium-france 100%[>] 198.95M 12.2MB/sin 17s 2023-05-29 14:54:21 (11.8 MB/s) - ‘stellarium-france’ saved [208615205/208615205] > US:wget > https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 (ins)efraim@3900XT /tmp$ wget https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 -O stellarium-US --2023-05-29 14:55:02-- 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: ‘stellarium-US’ stellarium-US 100%[>] 198.95M 12.2MB/sin 17s 2023-05-29 14:55:20 (11.5 MB/s) - ‘stellarium-US’ saved [208615205/208615205] > Singapore: wget > https://bordeaux-singapore-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 (ins)efraim@3900XT /tmp$ wget https://bordeaux-singapore-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 -O stellarium-singapore --2023-05-29 14:56:29-- 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: ‘stellarium-singapore’ stellarium-singapore 100%[>] 198.95M 10.8MB/sin 19s 2023-05-29 14:56:50 (10.2 MB/s) - ‘stellarium-singapore’ saved [208615205/208615205] > 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 Israel, paying for a 100/2 connection. I'm surprised the download from Singapore went so quickly, I would've expected that to be slower. Unless things have changed our internet travels to us by way of Greece and Cyprus. As an aside, a few years ago we tried out using Amazon as a CDN, and IIRC I figured I was likely the only user in Israel with ~15GB/month draw. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Transformations Shell Syntax
On Tue, May 23, 2023 at 06:43:30AM +, jgart wrote: > Hi Guixers WDYT, > > Uses specified commit hash: > > guix build emacs-ement@8b56efa9387262514daf63151d41c9e111e79567 for a comparison, the current (long) version: guix build emacs-ement --with-commit=emacs-ement=8b56efa9387262514daf63151d41c9e111e79567 Obviously the difference is that --with-commit can apply to dependencies, and this looks to only work on the actual package, but I often find myself only adjusting the actual package I'm trying to build anyway. > Uses specified commit hash (short): > > guix build emacs-ement@8b56efa > > Uses latest upstream release: > > guix build emacs-ement@latest > > Uses upstream version 0.8.2 if not packaged: > > guix build emacs-ement@0.8.2 > > Uses the latest commit in the wip/find-room branch: > > guix build emacs-ement@wip/find-room I'm not sure how @latest would work with @wip/find-room, unless @latest was reserved to point to (maybe) the newest release. I think we've all seen that the updater sometimes gets confused by some of the upstream methods of tagging releases and trying to figure out what the lastest release actually is. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: [PATCH 0/8] Remove mysql
On Mon, Apr 17, 2023 at 04:29:13PM +0300, Efraim Flashner wrote: > I saw that a fix was applied to mysql on core-updates to have it build > with openssl-1.1, and I figured that rather than have a version that was > several years out of date (and surely had many many security > vulnerabilities) it would be better to try to just remove it. > `mariadb:dev` provides the `mysql_config` binary that some packages > search for so I used it as a drop-in replacement. Nothing seemed broken > to me after building some packages, so to the best of my knowledge of > these disparate packages and languages all is fine. > > Efraim Flashner (8): > gnu: sysbench: Build with mariadb. > gnu: ghc-mysql: Build with mariadb. > gnu: neko: Build with mariadb. > gnu: inspircd: Build with mariadb. > gnu: ulogd: Build with mariadb. > gnu: opensmtpd-extras: Build with mariadb. > gnu: sbcl-clsql: Build with mariadb. > gnu: cl-clsql: Build with mariadb. > > gnu/packages/benchmark.scm | 9 + > gnu/packages/haskell-xyz.scm | 4 ++-- > gnu/packages/haxe.scm| 3 ++- > gnu/packages/irc.scm | 4 ++-- > gnu/packages/linux.scm | 6 +++--- > gnu/packages/lisp-xyz.scm| 18 ++ > gnu/packages/mail.scm| 4 ++-- > 7 files changed, 22 insertions(+), 26 deletions(-) > > > base-commit: 2d06dfc050114dba44e791d8decc8eaa705fee01 This patch was pushed almost a month ago, closing the bug now -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: What's needed to get things building for i586-gnu (the hurd) post core-updates?
On Mon, May 15, 2023 at 06:46:17PM +0200, Josselin Poiret wrote:
> Hi Efraim,
>
> Efraim Flashner writes:
> > If all you need is to remove coreutils-boot0 from the origin then you
> > could create a similar boot0 package specifically for the hurd and make
> > the fix there, and then use the current package or your new one as an
> > input in later packages based on the architecture.
>
> Unfortunately, it is used in an origin snippet, and there you can't
> really case over the target system.
>
Let me clarify a bit:
Add gcc-boot0-hurd, but with the snippet using guile instead of
coreutils-boot0. Then in (%boot1-inputs) the code gets changed from
("gcc" ,gcc-boot0) to (untested)
("gcc" ,(if (target-hurd?)
gcc-boot0-hurd
gcc-boot0))
And then similarly through the rest of gnu/packages/commencement.
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
Re: Defaulting to MAC-based names for network interfaces
On Sun, May 14, 2023 at 02:52:26PM -0700, Felix Lechner via Development of GNU
Guix and the GNU System distribution. wrote:
> Hi everyone,
>
> Upon personal reflection, a declarative operating system like Guix probably
> ought to use only predictable interface names.
>
> More details about this proposal, including the text below, are
> available in Bug#63508.
>
> While shorter names like 'eno1' offer an indisputable convenience and beauty
> when typing on the command line, administrators in Guix are unlikely to do so
> due to the declarative configuration system.
>
> Some system services may explicitly refer to interface names in their
> configuration. They would also benefit from the predictable and constant
> nature of MAC-based names.
>
> The latter is particularly relevant on multi-homed machines, i.e. those with
> more than one network connection.
>
> A MAC-based interface name as issued by 'eudev' looks like this:
>
> enx0123456789af (fictitious)
>
> The commit in Bug#63508 was deployed on two production machines. The
> migration to MAC-based interface names took place without issues. A
> second reconfiguration was used to add the new interface name in
> services tha needed it. The second step can be skipped, since the name
> is known with certainty in advance.
>
> The current naming scheme is less desirable because some services may silently
> refuse to start after equipment was added or removed. A removal may take
> place, for example, when something broke or when equipment was sold.
>
> The device enumeration may also change when a CMOS battery fails and system
> options are lost. In the author's option, Guix should not depend on BIOS
> enumeration for device names.
>
> In the author's case, the name of the sole network interface changed from
> enp3s0 to enp4s0 when a PCIe disk controller (a SAS host-based adapter) was
> installed. As a result, OpenSMTPd silently failed to start.
>
> This commit switches 'eudev' from the standard naming order
>
> ID_NET_NAME_ONBOARD
> ID_NET_NAME_SLOT
> ID_NET_NAME_PATH
>
> to ID_NET_NAME_MAC, which is always available. [1]
>
> The author initially attempted to achieve the same result via
>
> (udev-rules-service 'net-name-mac
> (udev-rule
> "01-net-name-mac.rules"
> "SUBSYSTEM==\"net\", ACTION==\"add\", NAME=\"$env{ID_NET_NAME_MAC}\"
> ")))
> but that did not work. While the situation was not examined exhaustively, it
> was not clear that udevadm can currently work because the standard command to
> test udev setups: [2]
>
> $ udevadm --debug test /sys/class/net/*
>
> did not find the script installed via the 'udev-service-type'.
I was curious about this, since I've been using a udev rule for quite a
while to setup zram swap. I definitely have my zram swap enabled and
working, but 'udevadm --debug test /dev/zram0' didn't find any rule for
zram.
> A review of the 'eudev' sources indicated that the path to find rules [3] is
> hard-coded to the store location during installation. An attempt to set the
> path to /etc/udev/rules.d yielded a build error because that target folder
> outside the store was understandably not writable.
>
> The manual page for udevadm did not offer a way to select the runtime location
> of the udev/rules.d folder via environment variables or a command-line option.
>
> Anyone for whom such a setup is working properly should please contact the
> author. Thank you!
/etc/udev points to /etc/static/udev, which itself is a symlink to a
combined udev item in the store, made up of all the udev rules installed
in the current system.
> This commit may result in some loss of privacy, although it is presently not
> clear how meaningful that is. With this commit, anyone using privacy-enhanced
> IPv6 addresses risks having their MAC exposed when they publish their
> configuration files in Git or post a well-meant sample in a chat rooms,
> because that configuration may mention the MAC address.
>
> Moreover, the compatibility with schemes to generate fake one-time MAC
> addresses upon boot should be evaluated. One concern is that the explicit
> reference to a network interface in a configuration file would likely force
> the use of a single and constant MAC address for that interface.
>
> This commit was tested in production and is currently being used.
>
> The change here resulted in the recompilation of several seemingly unrelated
> packages such as Emacs and GTK. Perhaps those dependency relationships should
> be examined.
>
> [1]
> https://wiki.debian.org/NetworkInterfaceNames#How_to_migrate_to_this_scheme_on_upgraded_systems
> [2] https://wiki.archlinux.org/title/Udev#Testi
Re: What's needed to get things building for i586-gnu (the hurd) post core-updates?
On Sun, May 14, 2023 at 05:55:20PM +0200, Josselin Poiret wrote: > Hi Ludo and Chris, > > Ludovic Courtès writes: > > > Hello! > > > > Probably the main issue is that childhurds now fail to boot: > > > > https://issues.guix.gnu.org/62307#23 > > > > We can still build “new” i586-gnu binaries on an “old” childhurd, of > > course, but to me that’s doing that is less of a priority. > > [1] should fix this. We have at least three important failures > regarding native compilation now: > > - coreutils doesn't build. This is because our bootstrap glibc doesn't > contain all the kernel headers, and coreutils tries to use some of > them directly. This should be fixable by adding an additional > bootstrap input for the Hurd with the missing kernel sources, I'm > trying to get one right now. > > While discussing with janneke, we also figured out that > coreutils-boot0 was probably unneeded as it's only used to rm a file > in an origin later on that could be removed with pure Guile. That > would be a world rebuild though so let's leave that for later. If all you need is to remove coreutils-boot0 from the origin then you could create a similar boot0 package specifically for the hurd and make the fix there, and then use the current package or your new one as an input in later packages based on the architecture. > - m4 and findutils both have some failing tests, and they seem to be > crashing. I haven't investigated this yet. > > [1] https://issues.guix.gnu.org/63501 > > -- > Josselin Poiret -- Efraim Flashner פלשנר אפרים GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Tooling for branch workflows
On Wed, May 10, 2023 at 01:39:05PM +0200, Andreas Enge wrote: > Hello all, > > the title says it all, I wish to share some conclusions from working on > the core-updates merge. Clearly our tooling could be improved for the task; > there was some flying by night without instruments, and in the end I > merged the branch without being really able to tell how it compared > to master... (You may also blame it partially on my lack of patience.) > Having feature branches may or may not make things a bit easier, but it > will definitely not solve the problems. I have to agree with this sentiment. I merged the rust-team branch with the gut-feeling that nothing new was broken, but I wasn't really sure how to compare the two. > This mail is also of course a bit politically sensitive: It may look like > I am complaining about other people's work, who are volunteers and do what > they can, without offering to work on the code myself. So as a preamble, > let me express my gratitude to the few people who have been working > tirelessly on our tooling and contributing to our infrastructure, without > whom big code changes like we did on core-updates (and now on feature > branches) would simply be impossible; their work is vital to the project > and often not very visible. If I am critical, it is not to diminish their > work, but to discuss about a positive path forward; and I hope more people > will find the motivation to do infrastructure work, which I think will be > decisive for the success of Guix (together with policy and organisational > questions). I too wish to thank everyone for all the work they have done. I would especially like to thank those who work on cuirass and the Guix build coordinator, neither of which I've worked on but which are fundamental underpinnings of Guix. -- Efraim Flashner פלשנר אפרים GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: RISC-V (riscv64-linux) substitutes are coming
On Tue, May 09, 2023 at 06:24:11PM +0300, Aleksandr Vityazev wrote: > Hi, > > On 2023-05-09, 15:22 +0100, Christopher Baines wrote: > > > Efraim Flashner writes: > > > >> [[PGP Signed Part:Undecided]] > >> On Tue, May 09, 2023 at 02:40:21PM +0100, Christopher Baines wrote: > >>> Hey! > >>> > >>> Almost a year ago now [1] I mentioned that I had received a HiFive > >>> Unmatched board, but I hadn't got it doing anything yet. > >>> > >>> 1: https://lists.gnu.org/archive/html/guix-devel/2021-06/msg00104.html > >> > >> Some would say that's almost two years ago! > > > > Indeed, I got my maths wrong! Time is really getting on :/ > > > >>> In the last few days I've made some time to take a look at it again and > >>> try to get it connected up to the bordeaux build farm. > >>> > >>> This has been somewhat successful, you should be able to see the machine > >>> (named rochor) on the prototype activity viewer [2]. > >>> > >>> 2: https://bordeaux.guix.gnu.org/activity > >>> > >>> Unfortunately it seems a bit stuck trying to upload the build results > >>> back to the coordinator due to the suspendable ports issues in > >>> guile-gnutls, but that should be fixed in the latest release so > >>> hopefully I'll be able to deploy that fix soon. > >>> > >>> It's also just currently a bare board hooked up to a spare power supply > >>> I have. I'll try and cost up a dedicated power supply plus case for it, > >>> and if anyone has suggestions for minimal mini-itx compatible cases, > >>> please let me know! > >>> > >>> This is a start, but more hardware will be needed to keep up with the > >>> master branch, plus testing patches and other branches, so if you have > >>> hardware to hand, or know of hardware available for purchase that might > >>> be suitable, that would be really useful to know about. > >> > >> That's really exciting! > >> > >> I've been having good luck with the visionfive1 as a build machine. My > >> visionfive2 gets a little hot and I'm looking at getting a desk fan to > >> blow at it and some of the other boards that get a bit hot while > >> building. > > I also use visionfive2 as my build machine. Quite happy with it. I have > a fairly large heatsink installed without a fan, the temperature does > not exceed 60 degrees at full load. Where did you get the heatsink from? Something generic or from the makers of the visionfive2? > > Cool, well let me know if any of those can be hooked up to the build > > farm. It's quite easy and obviously you can still use them (and just > > stop the build coordinator agent) if you need to. > > > > I'd give it a try. Although now there is only a 256GB ssd plugged in and > no dedicated ip address. I don't know how the coordinator works, maybe > it doesn't matter, I need to see how it all works. > > -- > Best regards, > Aleksandr Vityazev -- Efraim Flashner פלשנר אפרים GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: RISC-V (riscv64-linux) substitutes are coming
On Tue, May 09, 2023 at 02:40:21PM +0100, Christopher Baines wrote: > Hey! > > Almost a year ago now [1] I mentioned that I had received a HiFive > Unmatched board, but I hadn't got it doing anything yet. > > 1: https://lists.gnu.org/archive/html/guix-devel/2021-06/msg00104.html Some would say that's almost two years ago! > In the last few days I've made some time to take a look at it again and > try to get it connected up to the bordeaux build farm. > > This has been somewhat successful, you should be able to see the machine > (named rochor) on the prototype activity viewer [2]. > > 2: https://bordeaux.guix.gnu.org/activity > > Unfortunately it seems a bit stuck trying to upload the build results > back to the coordinator due to the suspendable ports issues in > guile-gnutls, but that should be fixed in the latest release so > hopefully I'll be able to deploy that fix soon. > > It's also just currently a bare board hooked up to a spare power supply > I have. I'll try and cost up a dedicated power supply plus case for it, > and if anyone has suggestions for minimal mini-itx compatible cases, > please let me know! > > This is a start, but more hardware will be needed to keep up with the > master branch, plus testing patches and other branches, so if you have > hardware to hand, or know of hardware available for purchase that might > be suitable, that would be really useful to know about. That's really exciting! I've been having good luck with the visionfive1 as a build machine. My visionfive2 gets a little hot and I'm looking at getting a desk fan to blow at it and some of the other boards that get a bit hot while building. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: rust-team branch merged
On Tue, May 09, 2023 at 02:22:36PM +0100, Christopher Baines wrote: > > Andreas Enge writes: > > > Hello, > > > > Am Tue, May 09, 2023 at 11:54:00AM +0300 schrieb Efraim Flashner: > >> The way its currently setup all we need to do is re-add aarch64-linux to > >> the supported-systems of rust-bootstrap and it'll be enabled again, and > >> build successfully eventually. > > > > I am confused by what happened; did you disable rust on aarch64 for > > everyone, > > or just building on the farm? If the first, that sounds like a pity, since > > at worst people can still compile packages by themselves. > > Yeah, while I appreciate paying attention to what substitutes are > available, I think we should add aarch64-linux back to the supported > systems, regardless of what ci.guix.gnu.org is doing. Thank you all for the encouragement and feedback. I've re-enabled aarch64 for rust. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: rust-team branch merged
On Tue, May 09, 2023 at 09:33:46AM +0100, Christopher Baines wrote: > > Efraim Flashner writes: > > > I've merged the rust-team branch into master. I've dropped rust for > > aarch64-linux again for now until I can get it built on cuirass so it's > > not holding up the branch any longer. > > Do you know if it actually doesn't build, or whether it's just a > berlin/Cuirass issue? I've managed to build it myself on my own pinebook pro and used that to build librsvg and python-cryptography. riscv64-linux actually needs more work to fix so it's building again. > While I appreciate the waiting for the build farm to catch up, I think > that in the case of aarch64-linux substitutes from ci.guix.gnu.org, > whatever problems are causing the substitute availability to be so low > aren't really going to be helped by waiting, something more is probably > needed. The way its currently setup all we need to do is re-add aarch64-linux to the supported-systems of rust-bootstrap and it'll be enabled again, and build successfully eventually. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
rust-team branch merged
I've merged the rust-team branch into master. I've dropped rust for aarch64-linux again for now until I can get it built on cuirass so it's not holding up the branch any longer. Unfortunately I forgot about the mesa update earlier so there's more rebuilds than I expected. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
