mtimes babi
hi,
I'm packaging babi and mtimes phase fails:
error: in phase 'ensure-no-mtimes-pre-1980': uncaught exception:
system-error "utime" "~A" ("No such file or directory") (2)
phase `ensure-no-mtimes-pre-1980' failed after 0.0 seconds
Backtrace:
13 (primitive-load "/gnu/store/4f5x3b0yvbh1aj44gvjj75dp6xf…")
In guix/build/gnu-build-system.scm:
906:2 12 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
1752:10 11 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
634:9 10 (for-each # …)
In ice-9/boot-9.scm:
1752:10 9 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
927:23 8 (_)
In ice-9/boot-9.scm:
1747:15 7 (with-exception-handler # …)
In ice-9/ftw.scm:
329:34 6 (go _)
In srfi/srfi-1.scm:
634:9 5 (for-each # …)
In ice-9/ftw.scm:
325:38 4 (go "./.activate.sh")
In guix/build/python-build-system.scm:
274:17 3 (_ "./.activate.sh" #(42 41792 41471 1 936 995 0 17 # …) …)
In unknown file:
2 (utime "./.activate.sh" 315619200 315619200 # …)
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure utime: No such file or directory
builder for `/gnu/store/fja5faknsszcw6dm0i0ii9xm7111m5jz-babi-1.5.3.drv' failed
with exit code 1
package:
(define-public babi
(package
(name "babi")
(version "1.5.3")
(source
(origin
(method git-fetch)
(uri
(git-reference
(url "https://github.com/asottile/babi";)
(commit (string-append "v" version
(sha256
(base32
"0d3a6km2bshym4lc4sdn8lhir4vc986d8hyhm1l3sm8ab0yzmawz"
(build-system python-build-system)
(arguments
'(#:phases
(modify-phases %standard-phases
(replace 'check
(lambda* (#:key tests? inputs #:allow-other-keys)
(when tests?
(invoke "pytest")))
(native-inputs (list python-pytest))
(propagated-inputs
(list python-babi-grammars
python-identify
python-importlib-metadata
python-onigurumacffi))
(home-page "https://github.com/asottile/babi/";)
(synopsis "Text editor inspired by nano")
(description
"A text editor written in Python and inspired by @code{nano}.")
(license license:expat)))
WDYT
Re: Packages depending on (guix build syscalls)
Hi Ludo, Ludovic Courtès writes: > Hello Guix! > > (Resending to the right mailing list, oops!) > > Quite a few packages depend on (guix build syscalls), starting from > ‘ant-bootstrap’ (since commit cded3a759356ff66b7df668bcdbdfa0daf96f4c5 > in 2018) up to GNOME-related packages such as ‘mutter’ (commit > d1c2fe248a7a326189fb7dcae64a59ece96251ba a few months ago). > > It’s great that we can reuse this module in different contexts! The > downside is that the module evolves quite often, because it’s a > foundation for Guix System and other things. As a result, all these > packages get rebuilt every time we change it. > > Maybe the only recommendation I would have is that we should make sure > we really need it before having a package deep down the graph depend on > it. I wouldn’t want us to do ‘staging’ cycles when we need a change in > (guix build syscalls). As mentioned by others, I think merging more general purpose things from Guix to Guile would be the best way forward. Every time I write a simple Guile script, I reach to Guix utils for simple things, which ought to be in Guile proper. Alternatively, there's at least 4 packages depending on (guix build syscalls) for working around a bug where dead processes are not reaped by PID1 in the Guix build container, causing some test suites to fail [0]. If we were to fix it, we could remove these workarounds. [0] https://issues.guix.gnu.org/30948 -- Thanks, Maxim
Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event
Hi Simon,
Sorry it took me so long to answer, but I've been struggling for the
past week with the upgrade of Poetry!! 😱
It requires updating `python-virtualenv` and `python-lockfile` and
suddenly a **LOT** of packages needed to be rebuilt/updated. #dependencyHell!
But that will definitively be the topic of a different thread…
Quoting zimoun (2022-10-19 11:57:15)
> On Tue, 18 Oct 2022 at 18:19, Tanguy LE CARROUR wrote:
>
> > ```console
> > $ guix package -I | awk '{print $1}' | tr '\n' ' ' | xargs guix refresh
> > 2>&1 | ag -v "already" | ag -v "failed" | ag -v "no updater" | ag -v
> > "warning"
> > ```
> >
> > Yeah, I know… ugly! But, it does (part of) the job! 😎
>
> Well, if you are using a manifest file, you can directly pass it to
> ’guix refresh‘. Otherwise,
>
> guix package --export-manifest > /tmp/my-pkgs.scm
> guix refresh -m /tmp/my-pkgs.scm 2>&1 | ...
I'm not using manifest (anymore). I used to, but for the time being, I'm using
`divenv` + `guix shell` and I'm quite happy with that setup.
> And even, being in a checkout of Guix,
>
> guix refresh -m /tmp/my-pkgs.scm --update
>
> and then give a look at the script etc/committer.scm.
That would create more patches than I could process I guess. I like the
idea of cherry-picking from the "need to be updated" list.
But `etc/committer.scm` is definitively a tool I was missing! Thanks!
Regards,
--
Tanguy
Re: Could the Go importer use the Go toolchain? (was Re: Go importer and packages with version flags)
Hi François, Good to see interest being picked up on the Go front. François writes: > Hello, > > After a hiatus I am trying to package several softwares written on Golang > (I would like to have terraform and go-jsonnet for example) and I have > some problems with the current implementation so I am resurrecting this > old mail from my Draft folder. > > Looking at it I think it is mostly reformulations of what Katherine and > Sarah already wrote on the thread but several months later it could be > a useful reminder. > > I have not really the energy at the moment to work on this alone but I > would be interested for team work. > > On Thu, Sep 30, 2021 at 10:31:08AM -0500, Katherine Cox-Buday wrote: >> Sarah Morgensen writes: >> >> >> IMO, module resolution and graph dependencies in Go are complicated enough >> >> that I'd much rather take the effort we put in trying to replicate and >> >> keep >> >> up with the Go toolchain's behavior, and spend that effort elsewhere. >> >> >> >> Does anyone have opinions on this? >> > >> > Hmmm. Setting aside whether or not we want to use external tools in >> > general... >> > >> > If we use the Go tool, we shift the problem domain into "translating >> > between >> > `go' and Guix." > > I felt uneasy when we reimplemented some inherently Go-specific pieces > of software like go.mod file parsing and dependency resolution. It seems > so brittle. So I think that for importer specifically we should be able > to use external programs like the Go toolchain to be in $PATH. And, > given the Go tool would have proper interfaces, we would indeed just > have to do some sort of translation. It's true, that we could perhaps make use of Go for the importer, if that simplify things and make them more robust in the long term. I do not expect these file formats (go.mod) to change too much though, so the brittleness concern may be exaggerated. In general, there's a tendency in Guix to do everything in Guile, for better and worst. > But as to the exact "how" it is not easy. > > Ideally we could split the tasks in severals steps. > 1. identify all dependencies on form of go modules paths > 2. identify source repositories (generally identified by a git-ref) for each > of those modules > 3. download content of source repository > 4. populate a ready-to-use source code local cache > 5. build > > As I see it in Guix we want : > - 1 and 2 in the importer; > - 3 is the "origin" method; > - 4 and 5 in the build system. > > `go mod download` does all of 1, 2 and 3. The translations problems are > how to extract data from this output to isolate dependency management on > the importer and having the necessary info for the "origin" method. Nix > bypass completely the problem by using the complete go mod cache as its > "origin" (or more recently "vendored" dependencies see this Nix change > to go mod vendor[4]) for each Go package. This solution is not viable > for us as we want to be able to reuse Go modules. > > For the build system part I think we want to use the GOMODCACHE format as > output of Guix package and to be able to do union-dir of all dependencies > when we want to build a leaf package (e.g. using GOPROXY=file:/// or > something like that). I agree this seems the way to go. [...] > Any interest on the matter ? I think supporting GO modules properly is going to be a must have as Go moves forward in that direction. I am interested to have that, but I don't think I have the bandwidth to volunteer much on the coding front. I'd be happy to review things or brainstorm though. -- Thanks, Maxim
Re: Pinning package inputs using inferiors?
Hi, On Fri, Oct 21, 2022 at 4:51 PM Phil wrote: > > have the releases available ... > but without ... an obligation on ... applications to adopt > these changes While I am relatively new to functional package management, I find it inconsistent that inputs in Guix are provided by variables. I believe the inputs should be provided by functions that deliver the most suitable version of a package. For most packages, that is the most recent version unless pinned. A package definition would be the list of available versions rather than just one version. One day, those functions could even be combined with importers in the sense that many versions are potentially available. Substitutes would only be produced and served for versions actually used, plus the most recent version. Kind regards Felix Lechner
Re: Types and builds for mypy
Hi, Philip Beadling writes: > Hi all > > Users of mypy and python will have noticed since the promotion of mypy to v0. > 971 it is now neccesary to provide separate python packages containing types > of non core libraries. > > The way we've been collecting these, outside of Guix proper, is in a single > module called python-types, which can then simply be added as a native-input > to any python build requiring mypy. > > The alternative is to colocate the types with their packages, or perhaps > colocate them all with mypy itself. Is MyPy the only consumer of Python type annotations? I think so, but I'm not sure. If it's the only one, it'd make sense to move mypy and all the annotation types to (gnu packages python-types), I think. > My preference is to put them all in one module, I think. > > Is there formal strategy in Guix for how to organise these packages? I'd be > happy to make available our current python-types.scm as a starting point? > > Finally and slightly related I note that by default the 971 package of > mypy is not C compiled using mypyc. It's a simple tweak to turn this > on in the package and it makes huge performance difference when using > mypy (on average 4x faster is quoted). Again, happy to offer up a > modified or inherited package if other people are frustrated by the > slow down? I think if it doesn't negatively impact its use, we should go ahead and make this change in the mypy package. Happy to review patches! -- Thanks, Maxim
Re: mtimes babi
jgart writes:
> I'm packaging babi and mtimes phase fails:
>
> error: in phase 'ensure-no-mtimes-pre-1980': uncaught exception:
> system-error "utime" "~A" ("No such file or directory") (2)
> phase `ensure-no-mtimes-pre-1980' failed after 0.0 seconds
Try "(delete 'ensure-no-mtimes-pre-1980)" like in `guix edit
python-identify`.
--
"Das Leben ist hart." - "Verglichen womit?" (Voltaire)
signature.asc
Description: PGP signature
Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event
On Wed, Oct 19 2022, 11:57:15 AM +0200 zimoun wrote: > and then give a look at the script etc/committer.scm. Didn't know this existed. This should definitely get a mention in the Guix manual. --
Re: Packages depending on (guix build syscalls)
Hello, Ludovic Courtès writes: > Hello Guix! > > (Resending to the right mailing list, oops!) > > Quite a few packages depend on (guix build syscalls), starting from > ‘ant-bootstrap’ (since commit cded3a759356ff66b7df668bcdbdfa0daf96f4c5 > in 2018) up to GNOME-related packages such as ‘mutter’ (commit > d1c2fe248a7a326189fb7dcae64a59ece96251ba a few months ago). The (guix build syscalls) dependency of Mutter can go away after we fix https://issues.guix.gnu.org/30948. -- Thanks, Maxim
Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event
Hi Efraim,
Quoting Efraim Flashner (2022-10-19 21:31:15)
> On Tue, Oct 18, 2022 at 06:19:18PM +0200, Tanguy LE CARROUR wrote:
> > Quoting Tanguy LE CARROUR (2022-10-05 16:01:40)
> > > Quoting Christopher Baines (2022-09-18 17:55:30)
> > […]
> > This is no magic scheme, it's just an alias for:
> >
> > ```console
> > $ guix package -I | awk '{print $1}' | tr '\n' ' ' | xargs guix refresh
> > 2>&1 | ag -v "already" | ag -v "failed" | ag -v "no updater" | ag -v
> > "warning"
> > ```
>
> I'd like to suggest swapping out the ag options for a grep option:
> grep -v -E '(already|failed|no updater|warning|redirection)'
> _should_ work, but I haven't tested that myself yet.
Right! Those multiple `-v` looked weird!
Thanks to your suggestion, I now have:
```console
$ guix package -I | awk '{print $1}' | tr '\n' ' ' | xargs guix refresh 2>&1 \
| ag -v '(already|failed|no updater|warning|redirection)'
```
Regards,
--
Tanguy
Re: Packages depending on (guix build syscalls)
On Fri, Oct 21, 2022 at 11:03:18AM +0200, Ludovic Courtès wrote: > Ludovic Courtès skribis: > > > Quite a few packages depend on (guix build syscalls), starting from > > ‘ant-bootstrap’ (since commit cded3a759356ff66b7df668bcdbdfa0daf96f4c5 > > in 2018) up to GNOME-related packages such as ‘mutter’ (commit > > d1c2fe248a7a326189fb7dcae64a59ece96251ba a few months ago). > > An issue is that GNOME now depends on Java: > > --8<---cut here---start->8--- > $ guix graph gnome --path icedtea > gnome@42.4 > font-abattis-cantarell@0.303 > python-cffsubr@0.2.9.post1 > python-afdko@3.9.1 > antlr4@4.10.1 > antlr3@3.5.2 > antlr2@2.7.7 > icedtea@3.19.0 > --8<---cut here---end--->8--- > > It is great to have ‘font-abattis-cantarell’ built from source (since > commit 97766323bc6e2b4dcfba4d6b46749a4280bca709), but it’s costly. > > There’s probably not much we can do, unless the python-afdko -> icedtea > dependency is optional. > > Ideas? I looked into this one since it was causing mate to not appear for i686-linux. I wasn't able to remove the java dependency for the font, generating the font explicitly imports cffsubr. Python-cffsubr needs python-afdko for the 'tx' command. I suppose we could re-bundle it but I haven't gone down that rabbit hole yet. Or we could just make that font optional. -- 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: Types and builds for mypy
Thanks for your reply Maxim, Maxim Cournoyer writes: > Is MyPy the only consumer of Python type annotations? I think so, but > I'm not sure. If it's the only one, it'd make sense to move mypy and > all the annotation types to (gnu packages python-types), I think. Mypy is certainly a prominent consumer, but you're right - PEP 561 type stub packages are also used by PyCharm, pytype, and I've heard CPython can use them to compile, to name a few. So I think my revised opinion is mypy should stay where it is, but I do like the idea of keeping all the types in one module? Co-locating them with the module they provide type for also works fine, but I kinda see the type files as visual noise if we put them in packages which are organized into categories they don't directly contribute to. Perhaps they are better kept in once place? It also means that when running mypy you can just import your python-types module, and be sure it's going to work. > I think if it doesn't negatively impact its use, we should go ahead and > make this change in the mypy package. > > Happy to review patches! Cool thanks - leave this with me, I have a working package so can submit a patch shortly!
Re: Pinning package inputs using inferiors?
On Fri, Oct 21, 2022 at 10:08:10PM +0100, Phil wrote: > Thanks Simon - I've given an example below. > > zimoun writes: > > > For an example, see python-numpy and python-numpy-next in (gnu packages > > python-xyz). > > This was my original way of handling this but in what is perhaps a niche > use of Guix by my department - it ultimately doesn't scale well, for our > use-case. > > Originally the department was small enough that there was only a handful > of applications sharing one or two common in-house libraries. > > As we've scaled-up we now have the situation where 3 or 4 common > libraries are being used by say 10 applications. > > We have rapid release schedules - and want to be able to release the > common libraries on a weekly basis. But the time to sign-off on a > common library takes a few days per application, so it's not practical for > every project to bump version every week - they have other priorities. > > In an ideal world automated unit and regression testing would be > comprehensive enough that we could move aggressively each week, but at > least for now that's not practical given the complex nature of signing > off the libraries and the applications which use the libraries. > > So, ideally, what we'd like to do is just have each common library > churn-out releases every week, and have the releases available in Guix, > but without having an obligation on dependent applications to adopt > these changes if they don't want to. > > Note all libraries and applications share the same channel - one > solution would be to have each library in their own channel, but this > feels ugly to me. > > Our solution (somewhat tricky to explain without a whiteboard - > apologies!) is to co-locate the package definition of the common library > in the common library repo itself - we call it something like > .requirements.scm and it is naturally kept in lockstep with the code in > that repo that the definition will build. This is very different to > traditional Guix where channels contain definitions separately in a > different repo to the code those definitions describe how to build. > > We then have a job in our CI/CD system that allows us to give a tag on the > common library repo, and the name of an application that uses the common > library. > > The job will copy the .requirements.scm into our channel inside a > private module specific to the application that uses the common library. > > The idea is that you can have many versions of .requirements.scm private > to every application package definition that references it. > > You could even read .requirements.scm using a function that clones the > application repo on-the-fly rather than statically storing it in the > channel - we haven't gone this far yet, as it makes the system even more > complex to reason about. > > This is basically the same idea as the python-numpy-next but allows for > many versions of python-numpy to co-exist by keeping them all in private > modules so they don't clash. > > It's a cool idea and works pretty well, but requires us to augment Guix > with a set of extra tools to lift and shift these private definitions > around, which complicates our setup considerably. > > It feels like wanting to make many versions of a library available at > once isn't an unreasonable way to work at-scale. However, it also feels > like a departure from the philosophy of Guix to decentralise package > definitions and to allow for a potentially large range of versions to > co-exist in the same channel commit. > > We could try to further integrate the idea into guix by writing new guix > commands to support it - we're still working out the details ourselves, > but if it works well we'd love to present it at a future Guix Days or > similar! > > In the meantime I was wondering if anyone else had a similar use-case > for Guix and if they had tried something similar or different to handle > many versions in an automated way in the same channel commit? > > Apologies that's more than I was intending to write - but hopefully that > makes some sense! If it doesn't I can try to flesh out specific example? Apologies for not slotting in the reply inline, I'm not sure exactly where to put it. This might be a good use for package transformations. Imagine the following: ;;; Python-dep-1 (define-publid python-dep1-week1 ...) (define-publid python-dep1-week2 ...) (define-publid python-dep1-week3 ...) ;;; Python-dep-2 (define-publid python-dep2-week1 ...) (define-publid python-dep2-week2 ...) (define-publid python-dep2-week3 ...) ;;; Python package (define my-python-package-base (name "my-python-package-base") ... (inputs (list python-dep1 python-dep2))) (define-public my-python-package (inherit my-python-package-base) (name "my-python-package") (inputs (modify-inputs (package-inputs python-package-base) (replace python-dep1 python-dep1-week3) (replace python-dep2 python-dep2-week2
Re: Rust on aarch64-linux
On Fri, Oct 21, 2022 at 10:51:59AM +0200, Ludovic Courtès wrote: > Hello, > > Efraim Flashner skribis: > > > I'm not sure there is a bug report, I didn't see it either. It looks > > like when I bumped rust-bootstrap from 1.39 to 1.54 we lost aarch64 > > support. I've bumped mrustc on staging and successfully performed a > > qemu-binfmt build of rust-bootstrap for aarch64 on my x86_64 box. I was > > then able to use that to build rust-1.55 on actual aarch64 hardware, so > > I assume it's good, I just don't have the hardware to build > > rust-bootstrap for aarch64 natively. > > So the presumed fix involves bumping rust-bootstrap from 1.54 to 1.55, > is that right? > > That means we’ll have to rebuild on all architectures. This is > happening here: > > https://ci.guix.gnu.org/eval/739823 > > Could you monitor it? If things go well, can we aim for a merge by next > Thursday? I think it looks good, but I'm not sure how to compare it to master. perhaps some Magic View™ using the guix data service? -- 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: Packages depending on (guix build syscalls)
Ludovic Courtès skriver: > Ludovic Courtès skribis: > >> Quite a few packages depend on (guix build syscalls), starting from >> ‘ant-bootstrap’ (since commit cded3a759356ff66b7df668bcdbdfa0daf96f4c5 >> in 2018) up to GNOME-related packages such as ‘mutter’ (commit >> d1c2fe248a7a326189fb7dcae64a59ece96251ba a few months ago). It seems the usage of (guix build syscalls) in java.scm and ant-build-system is solely for 'mkdtemp!'. Guile 3.0.6 gained 'mkdtemp', so I suppose we can switch to that? If there are backwards-compatibility concerns it seems possible to modify these procedures to not need to 'mkdtemp' at all. I can prepare a patch along these lines, but not sure if we need to maintain backward compatibility in (gnu packages). > An issue is that GNOME now depends on Java: [...] > There’s probably not much we can do, unless the python-afdko -> icedtea > dependency is optional. This relationship was added in b0ddbb05729e86ce4efb7eac8909317e16d7bed7 and is possible to trade at a purity cost. signature.asc Description: PGP signature
Installer for 1.4.0
Hello, The installer has been hardened during the past months when it comes to error reporting: - Guile exceptions are caught, displayed and possibly uploaded to dump.guix.gnu.org if the user agrees to do so. - Failing system commands can be run again. I think that it would be nice to go a bit further as people tend to use the stable Guix installer image and given our current release rate, the future 1.4.0 could last for long. It would be awesome if we could tackle the following issues before the release: - Guile and library segfaults could be reported as proposed here: https://issues.guix.gnu.org/58733. - There is a nasty finalizer bug that has probably bitten a lot of users here: https://issues.guix.gnu.org/58732. - The backtrace page is not displayed correctly if an exception occurs withing the final PTY: https://issues.guix.gnu.org/58734. This one is maybe not as important but it would be great to have it fixed so that every part of the installer is well covered by the dump mechanism. - Displaying upfront that the WiFi, video card or any other hardware won't be supported by the installer/linux-libre in the spirit of: https://issues.guix.gnu.org/58549 would be great. For instance, I tested recently the installer on a laptop with an unsupported WiFi card. The WiFi page is skipped altogether by the installer which forces the user to plug an ethernet cable without explaining why. I think we could be a bit more didactic. Any volunteers? Thanks, Mathieu
