Re: Move /gnu/store to another filesystem
Hello Théo Théo Maxime Tyburn writes: > I figured out where the problem came from. I forgot to use the -p option > while copying the store with cp. Because of this some scheme files where > newer than their compiled counterpart, which forced to compile them anew. > > Just did everything again with cp -p and it worked like a charm. Great! IMHO it'd be useful for other users to have a "Move store to another device" section in our cookbook: would you like to try to add a patch to it and see if maintainers accept it? I can help if needed. [...] >> If you have the new /gnu/store as a btrfs subvolume, you may need to >> tell `mount` which subvolume to mount there. good point Kaelyn! [...] Happy Hacking! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Test Failure when upgrading python-rope
Hi Guixers,
Can anyone help me debug this test failure for python-rope?
The part that jumps out at me from the traceback is `AssertionError: ('from
build import env', 'env') not found in []`
More logs follow:
```
test_a_function_with_different_returns
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_always_returning_containing_class_for_selfs
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_call_function_and_parameters (ropetest.advanced_oi_test.NewStaticOITest)
... ok
test_following_function_calls_when_asked_to
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_handling_generator_functions_for_strs
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_invalidating_concluded_data_in_a_function
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_not_reporting_out_of_date_information
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_not_saving_unknown_function_returns
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_properties_and_calling_get_property
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_report_change_in_libutils (ropetest.advanced_oi_test.NewStaticOITest) ...
ok
test_report_libutils_and_analyze_all_modules
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_set_comprehension (ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_soi_on_constructors (ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_soi_on_literal_assignment (ropetest.advanced_oi_test.NewStaticOITest) ...
ok
test_soi_on_typed_assignment (ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_static_oi_class_methods (ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_static_oi_for_dicts_depending_on_append_function
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_static_oi_for_dicts_depending_on_for_loops
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_static_oi_for_dicts_depending_on_update
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_static_oi_for_dicts_depending_on_update_on_seqs
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_static_oi_for_infer_return_typs_from_funcs_based_on_params
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_static_oi_for_lists_depending_on_append_function
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_static_oi_for_lists_per_object_for_extending_lists
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_static_oi_for_lists_per_object_for_fields
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_static_oi_for_lists_per_object_for_get_item
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_static_oi_for_lists_per_object_for_iters
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_static_oi_for_lists_per_object_for_set_item
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_static_oi_for_nested_calls (ropetest.advanced_oi_test.NewStaticOITest) ...
ok
test_static_oi_for_sets_per_object_for_set_item
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_static_oi_for_simple_function_calls
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_static_oi_not_failing_when_callin_callables
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_static_oi_preventing_soi_maximum_recursion_exceptions
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_using_the_best_callinfo (ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_validation_problems_for_changing_builtin_types
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
test_validation_problems_for_objectdb_retrievals
(ropetest.advanced_oi_test.NewStaticOITest) ... ok
==
FAIL: test_search_submodule (ropetest.contrib.autoimporttest.AutoImportTest)
--
Traceback (most recent call last):
File
"/tmp/guix-build-python-rope-1.1.1.drv-0/rope-1.1.1/ropetest/contrib/autoimporttest.py",
line 121, in test_search_submodule
self.assertIn(import_statement, self.importer.search("env",
exact_match=True))
AssertionError: ('from build import env', 'env') not found in []
--
Ran 1892 tests in 17.052s
FAILED (failures=1, skipped=33, expected failures=1)
Test failed:
error: Test failed:
error: in phase 'check': uncaught exception:
%exception #< program: "python" arguments: ("-c" "import
setuptools, tokenize;__file__='setup.py';f=getattr(tokenize, 'open',
open)(__file__);code=f.read().replace('\\r\\n',
'\\n');f.close();exec(compile(code, __file__, 'exec'))" "test") exit-status: 1
term-signal: #f stop-signal: #f>
phase `check' failed after 18.6 seconds
command "python" "-c" "import setuptools,
tokenize;__file__='setup.py';f=getattr(tokenize, 'open',
open)(__file__);code=f.read().replace('\\r\\n',
'\\n');f.close();exec(compile(code, __file__, 'exec'))" "test" failed with
status 1
builder for `/gnu/store/9qmc9y88ncsrcpg7kp5jbs9h9dn0x0w2-python-rope-1.1.1.drv'
failed with exit code 1
build of
Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues
Hello Gio'
On Thursday, May 26th, 2022 at 8:01 AM, Giovanni Biscuolo
wrote:
> Hello Kaelyn and Ludo'
>
> thank you for your help!
>
> Kaelyn kaelyn.al...@protonmail.com writes:
>
>
> [...]
>
> > > First, we need to cherry-pick relevant commits from gitlab.com. Any
> > > takers? If you Giovanni or anyone else is willing to help,
>
>
> I'd be really happy to help, I just saw Kaelyn was already working on
> this
>
> unfortunately I'm not the right person to maintain emacs-guix since my
> *-lisp foo is still Panda-style
>
> > > we can grant commit access so we share the work. Another way to help
> > > is by listing commits that should be applied.
> > >
> > > Volunteers?
> >
> > I'd be happy to help with the efforts! I just took a few minutes and
> > checked both repos out into a single working tree, and there aren't
> > many commits unique to each repository. The official savannah repo has
> > 5 commits since they diverged, with the 3 oldest looking like
> > variations of the 6 oldest in the gitlab repo. Likewise, not counting
> > the 6 just mentioned, there are 4 unique commits in the gitlab repo.
>
>
> how is your cherry-picking going?
>
> is there anything I can do to help?
I've attempted to cherry-pick the four gitlab commits (by interactively
rebasing the gitlab HEAD on the savannah HEAD and dropping the overlapping
commits) but haven't made progress beyond that. The rebase/cherry-pick was
pretty simple as there didn't seem to be conflicts. However, I keep getting
elisp errors about something having the wrong number of arguments, and I'm
still new enough to emacs that I don't know how to debug it or to get a useful
backtrace of where the error is coming from.
Basically it seems like the same error compiling any of the elisp files (at
least with emacs 27), but the errors are ignored by default and so installation
fails because all of the .elc files to be installed are missing. A sample of
the repeated error:
ELC elisp/guix-hash.elc
Wrong number of arguments: #[nil "ÁÂÃ \"Ä\")" [autoloads mapcan
guix-emacs-find-autoloads guix-emacs--non-core-load-path mapc #[(f) "Â\"" [f
load noerror] 3]] 3
("/gnu/store/wl48zzhf6gvvi7vml7w0yzg14ks4b0ls-profile/share/emacs/site-lisp/guix-emacs.elc"
. 1084) nil], 1
make[1]: [Makefile:1285: elisp/guix-hash.elc] Error 255 (ignored)
ELC elisp/guix-derivation.elc
Wrong number of arguments: #[nil "ÁÂÃ \"Ä\")" [autoloads mapcan
guix-emacs-find-autoloads guix-emacs--non-core-load-path mapc #[(f) "Â\"" [f
load noerror] 3]] 3
("/gnu/store/wl48zzhf6gvvi7vml7w0yzg14ks4b0ls-profile/share/emacs/site-lisp/guix-emacs.elc"
. 1084) nil], 1
make[1]: [Makefile:1285: elisp/guix-derivation.elc] Error 255 (ignored)
I wanted to at least make sure the package built with the included guix.scm
before figuring out how to send a pull request (or patch series) to a
savannah-hosted project, but that error has me stumped.
Cheers,
Kaelyn
>
> Thanks, Gio'
>
> [...]
>
> --
> Giovanni Biscuolo
>
> Xelera IT Infrastructures
Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues
Hi, I would also be happy to help if I can. I could create a new branch starting at savannah’s HEAD and cherry pick everything relevant from gitlab since the merge-base. That would probably be everything except the duplicates, so the 4 commit Kaelyn mentioned, right ? Probably we also need to gather the issues from gitlab. Not experienced with savannah issue tracker, but I could try it out. Cheers, Théo Kaelyn writes: > Hi, > > --- Original Message --- > On Monday, May 23rd, 2022 at 7:39 AM, Ludovic Courtès wrote: > > >> Hi, >> >> Ludovic Courtès l...@gnu.org skribis: >> >> > Anyway, the situation is confusing; there’s no point in having two >> > slightly different variants. I suggest we check with Alex off-list to >> > get a better understanding of what they want. Worst case, we can >> > cherry-pick commits from Alex’s copy if Alex doesn’t want to be involved >> > in discussions around Emacs-Guix or Guix development. >> >> >> Emailed Alex off-list and didn’t get a reply. >> >> So we’re on our own like grownups, but that’s fine, I’m sure we’ll >> manage. :-) >> >> First, we need to cherry-pick relevant commits from gitlab.com. Any >> takers? If you Giovanni or anyone else is willing to help, we can grant >> commit access so we share the work. Another way to help is by listing >> commits that should be applied. >> >> Volunteers? > > I'd be happy to help with the efforts! I just took a few minutes and > checked both repos out into a single working tree, and there aren't > many commits unique to each repository. The official savannah repo has > 5 commits since they diverged, with the 3 oldest looking like > variations of the 6 oldest in the gitlab repo. Likewise, not counting > the 6 just mentioned, there are 4 unique commits in the gitlab > repo. Those 4 commits are: > > * c9aef52 - (gitlab/master, gitlab/HEAD) elisp/ui-package: Add > 'guix-package-use-name-at-point' variable (12 months ago) > * e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months > ago) > * 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 > months ago) > * fbc2bbc - elisp/ui-package: Use thing at point for > 'guix-packages-by-name' command (1 year, 3 months ago) > > Cheers, > Kaelyn > > P.S For full reference, the remotes are: > gitlabhttps://gitlab.com/emacs-guix/emacs-guix.git > official git://git.savannah.gnu.org/guix/emacs-guix.git > > `git merge-base gitlab/master official/master` returns the hash: > 41fba4eec845e050be92bfe76c0f7980bbe821bd > > The commits since the merge-base in the savannah repo: > * c9c5cb0 - (HEAD -> master, official/master) elisp/profiles: Support Home > profiles. (3 months ago) > * 94fcf1f - elisp/prettify: Recognize "/zstd" in nar URLs. (4 months > ago) > * 825ab77 - Remove all references to the GuixSD name. (1 year, 4 months > ago) > * a42f66c - elisp: Support geiser @0.12.x (1 year, 4 months ago) > * d61d827 - scheme: Remove @@ for Guile 3.x support. (1 year, 4 months > ago) > > And the commits in the gitlab repo since the merge-base: > * c9aef52 - (gitlab/master, gitlab/HEAD) elisp/ui-package: Add > 'guix-package-use-name-at-point' variable (12 months ago) > * e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months > ago) > * 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 > months ago) > * fbc2bbc - elisp/ui-package: Use thing at point for > 'guix-packages-by-name' command (1 year, 3 months ago) > * 057e3a6 - Remove all references to the "GuixSD" name (1 year, 4 months > ago) > * bb2a053 - elisp/repl: Support geiser 0.12.x (1 year, 5 months ago) > * 753dbb0 - scheme: Remove "@@" from 'log-url' (1 year, 5 months ago) Soo> > * 66695d0 - scheme: Remove "@@" from "pack" symbols (1 year, 5 months > ago) > * 20cb235 - scheme: Remove "@@" from 'operating-system-firmware' (1 year, 5 > months ago) > * 307aa05 - scheme: Remove "@@" from 'search-path-environment-variables' (1 > year, 5 months ago) > >> >> Thanks, >> Ludo’.
Re: Breaking change: Make 'description' of mandatory
Hi,
Am Donnerstag, dem 26.05.2022 um 09:38 +0200 schrieb Reily Siegel:
> The solution here is incredibly obvious, I just need to add
> descriptions to services I declare in my configuration, but that this
> change happened, and I didn't see anyone else have issues on guix-
> devel, guix-help, or elsewhere (I may have missed something), I
> thought it a good idea to ask if I am doing something unsupported in
> my configuration.
I don't think so. Patches tend to sleep in the mailing list for a
while (the documentation says something about 14 days, but patches have
been pushed quicker than that). People in a similar situation likely
have already noticed and documented their services in advance; even if
not, someone always has to be the first to publicly notice.
> The problem arises when a certain feature needs to extend two
> services to be useful: take configuration of an emacs package. It
> must first extend (in the case of Guix home) home-emacs-service (from
> RDE channel) with the emacs configuration to be inserted to init.el,
> and home-profile-service-type, to add the emacs package to the
> profile.
> It seems like simple-service /would/ be a good option here, except as
> best I can figure out it can only extend one service. So instead, I
> create a new service-type, perhaps named my-emacs-feature-
> configuration-service,
> which takes no value and has no extension mechanism, but only serves
> to extend multiple other "real" services.
To be fair, that's a pretty weird design for design sake. You could
for instance make it s.t. your service takes a list of package+snippet
pairs as configuration, adding the package to your profile and the
snippet to your init.el. That'd be more generic than a "one-off"
definition that only carries your own configuration.
> This change (and the discussion at https://issues.guix.gnu.org/55404)
> indicates to me that all service-types, no matter where they are
> implemented, are meant to be consumed by a generic user, not used in
> a one-off way like my configuration does.
>
> So, to sum up, I have a few questions:
>
> 1. Is service-type meant for use in individual user configurations?
Yes and no. You can freely define new service types if it helps you,
but the way you describe seems like a somewhat large hammer. If your
service type provides no useful abstraction, why not use simple
services instead, even if you have to write multiple ones?
> 2. Is there an equivalent function to simple-service that takes
> multiple
> service/value pairs that I have missed?
> (e.g., (simple-service-like service-a val-a service-b val-b ...)
> or (simple-service-like (list service-a val-a service-b val-b)))
You can group multiple simple-services into a list, i.e.
(define my-service-collection
(list (simple-service service-a val-a)
(simple-service service-b val-b)))
and then add that to your configuration via append.
> 3. If the answer to 2 is no, does it make sense to extend
>simple-service to work with multiple service extensions, or is
>there some reason for only extending one service at a time?
No, you're nail-seeking. Just because one way of doing things has
vanished doesn't mean that there aren't others that end up with the
same result. As an analogy, (template) metaprogramming in C++ is
Turing-complete, so you could, for example, write a program that
computes a specific instance of 3SAT at compile time and the compiled
program will either be puts("yes") or puts("no"), depending on whether
the formula was satisfiable or not. While incredibly cool, doing that
serves no real purpose – the compiled program does not solve 3SAT, it's
essentially hello world.
Service types without configuration in a similar manner "do nothing",
i.e. they don't offer a way for the user to express their desired
system more concisely than if they didn't have them. Once you do have
a configuration, you have to think about what parts of your system it
abstracts and makes easier to configure, ad so on and so forth, thus
naturally leading to some documentation.
I wasn't involved in any discussion around this feature, so you might
want to take my opinion with a grain of salt; nevertheless I hope it's
useful to think about things in that way.
Documenting your service types should also be more helpful if you ever
want to share them with upstream, though in the particular case of Guix
Home that's split in two very distinct realms that might not be as
simple as I've just said.
Cheers
Re: Move /gnu/store to another filesystem
Hello Gio and Kaelyn, I figured out where the problem came from. I forgot to use the -p option while copying the store with cp. Because of this some scheme files where newer than their compiled counterpart, which forced to compile them anew. Just did everything again with cp -p and it worked like a charm. Thanks for the support! Théo Kaelyn writes: > Hi Théo, > > n Thursday, May 26th, 2022 at 3:44 AM, Théo Maxime Tyburn > wrote: > > >> Hi Gio, >> >> Giovanni Biscuolo g...@xelera.eu writes: >> >> >> [...] >> >> > maybe you misconfigured "mount-point" and "type"? >> > >> > what about: >> > >> > --8<---cut here---start->8--- >> > >> > (define %store-fs ;; <--- This is what I want to add. >> > (file-system (device (file-system-label "storage-fs")) >> > (mount-point "/gnu/store") >> > (type "btrfs") >> > >> > --8<---cut here---end--->8--- >> > >> > WDYT? >> >> >> Oh yes sorry, I did a mistake while copy-pasting. What you suggested >> is actually what I am using. > > If you have the new /gnu/store as a btrfs subvolume, you may need to tell > `mount` which subvolume to mount there. I haven't tried moving /gnu/store, > but my systems have / and /gnu/store as separate btrfs subvolumes in the same > LUKS-encrypted partition. Here is the `file-systems` stanza of one of my > system's operating-system declaration, in case it is helpful: > > (file-systems > (let ((rootfs (file-system > (mount-point "/") > (device "/dev/mapper/cryptroot1") > (type "btrfs") > (check? #f) > (options "compress=zstd,subvol=@guix") > (dependencies mapped-devices > (cons* rootfs >(file-system > (mount-point "/boot/efi") > (device (file-system-label "EFI")) > (type "vfat") > (mount-may-fail? #t) > (dependencies mapped-devices)) >(file-system > (mount-point "/gnu") > (device "/dev/mapper/cryptroot1") > (type "btrfs") > (check? #f) > (options "compress=zstd,subvol=@gnu_store") > (dependencies (cons rootfs mapped-devices))) >%base-file-systems))) > > Cheers, > Kaelyn > >> >> > > Anyway this is probably not the right way to do it. Simply coping >> > > /gnu/store around looks a bit brutal. >> > >> > AFAIK we can move /gnu/store anywhere if the system is not live, >> > like you did booting in "rescue mode" >> >> >> Well then I don’t see what could have gone wrong. I’ll try it agin. >> >> > Happy hacking! Gio' >> >> >> Tks!
Re: Move /gnu/store to another filesystem
Hi Théo, n Thursday, May 26th, 2022 at 3:44 AM, Théo Maxime Tyburn wrote: > Hi Gio, > > Giovanni Biscuolo g...@xelera.eu writes: > > > [...] > > > maybe you misconfigured "mount-point" and "type"? > > > > what about: > > > > --8<---cut here---start->8--- > > > > (define %store-fs ;; <--- This is what I want to add. > > (file-system (device (file-system-label "storage-fs")) > > (mount-point "/gnu/store") > > (type "btrfs") > > > > --8<---cut here---end--->8--- > > > > WDYT? > > > Oh yes sorry, I did a mistake while copy-pasting. What you suggested > is actually what I am using. If you have the new /gnu/store as a btrfs subvolume, you may need to tell `mount` which subvolume to mount there. I haven't tried moving /gnu/store, but my systems have / and /gnu/store as separate btrfs subvolumes in the same LUKS-encrypted partition. Here is the `file-systems` stanza of one of my system's operating-system declaration, in case it is helpful: (file-systems (let ((rootfs (file-system (mount-point "/") (device "/dev/mapper/cryptroot1") (type "btrfs") (check? #f) (options "compress=zstd,subvol=@guix") (dependencies mapped-devices (cons* rootfs (file-system (mount-point "/boot/efi") (device (file-system-label "EFI")) (type "vfat") (mount-may-fail? #t) (dependencies mapped-devices)) (file-system (mount-point "/gnu") (device "/dev/mapper/cryptroot1") (type "btrfs") (check? #f) (options "compress=zstd,subvol=@gnu_store") (dependencies (cons rootfs mapped-devices))) %base-file-systems))) Cheers, Kaelyn > > > > Anyway this is probably not the right way to do it. Simply coping > > > /gnu/store around looks a bit brutal. > > > > AFAIK we can move /gnu/store anywhere if the system is not live, > > like you did booting in "rescue mode" > > > Well then I don’t see what could have gone wrong. I’ll try it agin. > > > Happy hacking! Gio' > > > Tks!
Re: Arun Isaac Presentation on guix-forge this Saturday
Hi Olivier, > Right. Postgresql makes sens for huge CI like ci.guix.gnu.org I guess. > However it would indeed be nice to have the option to select sqlite as > the DBMS. Exactly! > Maybe the solution would be to use a object-relational mapper and > generate the schemas on the fly depending on the DBMS. I think that > `guile-dbi` does just that. I think object-relational mappers add too much complexity. guile-dbi and guile-dbd-* with simple SQL queries should be more than sufficient for the job. Regards, Arun
Re: Arun Isaac Presentation on guix-forge this Saturday
On Thu, 26 May 2022, Arun Isaac wrote: >> Tell me, does Laminar check for channels update like cuirass? The main >> feature I like about cuirass is that if any dependencies of a package is >> updated, it will rebuild my package. If it does support that, I will >> seriously consider switching to guix-forge for my project. > it should be possible to set up something that runs `laminarc queue > ' on dependency changes. Right. It's just a matter of checking how cuirass does it and do the same in guix-forge. > Laminar stands out from other CI systems in that it is not a monolith > and is very easy to interface with external tools. So, I was able to > write up Guix system configuration to do it. But, if Cuirass can provide > smoother integration with Guix, I'm more than happy to switch. The main > blocker is the postgres database. Right. Postgresql makes sens for huge CI like ci.guix.gnu.org I guess. However it would indeed be nice to have the option to select sqlite as the DBMS. For the Guile portion that should be trivial I think. The difficult part is probably within the SQL schema, if Postgresql' extensions were used. Maybe the solution would be to use a object-relational mapper and generate the schemas on the fly depending on the DBMS. I think that `guile-dbi` does just that. To continue :-) Regards, old -- Olivier Dion oldiob.dev
Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues
Hello Kaelyn and Ludo' thank you for your help! Kaelyn writes: [...] >> First, we need to cherry-pick relevant commits from gitlab.com. Any >> takers? If you Giovanni or anyone else is willing to help, I'd be really happy to help, I just saw Kaelyn was already working on this unfortunately I'm not the right person to maintain emacs-guix since my *-lisp foo is still Panda-style >> we can grant commit access so we share the work. Another way to help >> is by listing commits that should be applied. >> >> Volunteers? > > I'd be happy to help with the efforts! I just took a few minutes and > checked both repos out into a single working tree, and there aren't > many commits unique to each repository. The official savannah repo has > 5 commits since they diverged, with the 3 oldest looking like > variations of the 6 oldest in the gitlab repo. Likewise, not counting > the 6 just mentioned, there are 4 unique commits in the gitlab repo. how is your cherry-picking going? is there anything I can do to help? Thanks, Gio' [...] -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Breaking change: Make 'description' of mandatory
Hello, This commit at 3948ac25b1dccc40c7fdf56377f94a0775a835ee broke my configuration. I don't mean to grumble about this, but rather figure out if I am doing something horribly wrong in my configuration to cause such a simple change to break things, and perhaps alert other people making similar mistakes happen. The solution here is incredibly obvious, I just need to add descriptions to services I declare in my configuration, but that this change happened, and I didn't see anyone else have issues on guix-devel, guix-help, or elsewhere (I may have missed something), I thought it a good idea to ask if I am doing something unsupported in my configuration. The problem arises when a certain feature needs to extend two services to be useful: take configuration of an emacs package. It must first extend (in the case of Guix home) home-emacs-service (from RDE channel) with the emacs configuration to be inserted to init.el, and home-profile-service-type, to add the emacs package to the profile. It seems like simple-service /would/ be a good option here, except as best I can figure out it can only extend one service. So instead, I create a new service-type, perhaps named my-emacs-feature-configuration-service, which takes no value and has no extension mechanism, but only serves to extend multiple other "real" services. This change (and the discussion at https://issues.guix.gnu.org/55404) indicates to me that all service-types, no matter where they are implemented, are meant to be consumed by a generic user, not used in a one-off way like my configuration does. So, to sum up, I have a few questions: 1. Is service-type meant for use in individual user configurations? 2. Is there an equivalent function to simple-service that takes multiple service/value pairs that I have missed? (e.g., (simple-service-like service-a val-a service-b val-b ...) or (simple-service-like (list service-a val-a service-b val-b))) 3. If the answer to 2 is no, does it make sense to extend simple-service to work with multiple service extensions, or is there some reason for only extending one service at a time? Thanks for reading through this email that I am for some reason sending even though it would be faster to just add descriptions to all my services, and hopefully I can learn something about Guix! -- Reily Siegel
Re: Blender export backend missing
Hello,
I tried several things in the last days. Unfortunatly I still didn’t
manage to build Blender with the new OpenEXR IMath version. Long story
short: I think upgrading blender to 3.1.0 will solve the problem. But
this requires to have python 3.10. So I’ll wait until we have it and
come back to it later.
In the meantime we can leave openexr to the old version and just add
an alternative alembic package that is based on it. I used this approach in the
last few days to work
with alembic files in blender and it just works fine. I’ll propose a
patch for this. I never did this for guix though, so I might still have
some questions :)
Ekaitz Zarraga writes:
[...]
> I know this is a huge effort, I had to deal with similar things in
> Blender and Meshlab in the past, so I'm here to help!
>
> Good job,
> Ekaitz
Thank you for encouraging me! It is indeed a messy problem. Let’s see
how this works out with the newer version of python and blender.
Here is the story of my experimentations with gorry details:
The patch I mentioned in my previous message is actually for a much older
version, so it can’t
even apply. There is a simple way to avoid the error occuring at config
time though: if you set "-DWITH_CYCLES=OFF" then the config succedes. So
it seems the problem comes from Cycles. This is a problem on its
own. Not sure what to do about it. It looks more like an upstream
problem.
Anyway, even with that problem put aside, there is another one. The package
half is not found at
compile time. In earlier versions of OpenEXR it was part of IlmBase, now
it is in IMath. The trick for blender based on ilmbase was to add
(string-append (assoc-ref inputs "ilmbase") "/include/OpenEXR/")
to C_INCLUDE_PATH and CPLUS_INCLUDE_PATH so that half can be found.
So now that half is in IMath I changed it to
(string-append (assoc-ref inputs "imath") "/include/IMath/")
unfortunatly this didn’t work: half is still not found.
I am confused because I tried a small experiement with a simple c code
and it worked when setting C_INCLUDE_PATH. So this compiles:
--8<---cut here---start->8---
C_INCLUDE_PATH=/gnu/store/pxf5591fpradfjjqyx7j269xilwndcmk-imath-3.1.3/include/Imath/
gcc use-half.c
--8<---cut here---end--->8---
where use-half.c contains
--8<---cut here---start->8---
#include
void main() {
printf("hello");
}
--8<---cut here---end--->8---
So I’m not sure why this doesn’t work in the context of blender being
built. Any idea?
By the way this seems to be something that should be set by the ilmbase and
imath packages, right? Or is it just a problem of blender not specifying
half is to be found in IMath. For example this compiles:
--8<---cut here---start->8---
gcc use-Imath-half.c
--8<---cut here---end--->8---
where use-Imath-half.c contains
--8<---cut here---start->8---
#include
void main() {
printf("hello");
}
--8<---cut here---end--->8---
So we could actually try to just change all #include with
#include in the blender source code. How can one
achieve that?
But even if this works, we still have the problem that Cycles need to
have the old version of OpenEXR.
As long as this problem with configuring Cycles with newer versions of
OpenEXR and Imath fails I see no way around.
Happy hacking,
Théo
Re: Move /gnu/store to another filesystem
Hi Gio, Giovanni Biscuolo writes: [...] > maybe you misconfigured "mount-point" and "type"? > > what about: > > --8<---cut here---start->8--- > > (define %store-fs ;; <--- This is what I want to add. >(file-system (device (file-system-label "storage-fs")) > (mount-point "/gnu/store") > (type "btrfs") > > --8<---cut here---end--->8--- > > WDYT? Oh yes sorry, I did a mistake while copy-pasting. What you suggested is actually what I am using. >> Anyway this is probably not the right way to do it. Simply coping >> /gnu/store around looks a bit brutal. > > AFAIK we can move /gnu/store anywhere **if** the system is not live, > like you did booting in "rescue mode" Well then I don’t see what could have gone wrong. I’ll try it agin. > Happy hacking! Gio' Tks!
Re: Move /gnu/store to another filesystem
Hello Théo Théo Maxime Tyburn writes: [...] > (define %store-fs ;; <--- This is what I want to add. > (file-system (device (file-system-label "storage-fs")) > (mount-point mt-point) > (type "/gnu/store") maybe you misconfigured "mount-point" and "type"? what about: --8<---cut here---start->8--- (define %store-fs ;; <--- This is what I want to add. (file-system (device (file-system-label "storage-fs")) (mount-point "/gnu/store") (type "btrfs") --8<---cut here---end--->8--- WDYT? [...] > Anyway this is probably not the right way to do it. Simply coping > /gnu/store around looks a bit brutal. AFAIK we can move /gnu/store anywhere **if** the system is not live, like you did booting in "rescue mode" [...] Happy hacking! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Arun Isaac Presentation on guix-forge this Saturday
Hi Olivier, > Tell me, does Laminar check for channels update like cuirass? The main > feature I like about cuirass is that if any dependencies of a package is > updated, it will rebuild my package. If it does support that, I will > seriously consider switching to guix-forge for my project. Short answer: No, laminar/guix-forge don't rerun CI jobs when package dependencies change. Long answer: It should be possible to configure laminar to do something like that. Laminar has a very minimalist Unix-philosophy design and does not even automatically trigger CI jobs on git commits. The user has to manually set up a post-receive hook in the git repository that runs `laminarc queue '. guix-forge automatically handles this post-receive hook setup for you. So, though I don't immediately see how to do it, it should be possible to set up something that runs `laminarc queue ' on dependency changes. Laminar stands out from other CI systems in that it is not a monolith and is very easy to interface with external tools. So, I was able to write up Guix system configuration to do it. But, if Cuirass can provide smoother integration with Guix, I'm more than happy to switch. The main blocker is the postgres database. Regards, Arun
Re: Arun Isaac Presentation on guix-forge this Saturday
Hi all, Thanks for giving me this opportunity to present guix-forge. In particular, I wish to thank both jgart and Pjotr. guix-forge owes its existence to their encouragement. guix-forge is a Guix service that, ambitiously, tries to reproduce a sourcehut, GitHub or GitLab like code forge, but using only off-the-shelf components like cgit, laminar, public-inbox, etc. The idea is to enable users to write a few lines of Guix operating-system configuration code, and have an entire code forge deployed and ready. guix-forge is similar to projects like FreedomBox, YunoHost and Mail-in-a-Box, but for code forges and built on the rock-solid foundation that is Guix. For now, only the laminar CI feature is in place. In the presentation, I will show a setup of laminar CI with guix-forge. On every git commit to a project repo, the CI will - automatically run tests for the project - build and deploy a static project website If you would like to take a sneak peek of a guix-forge configuration, there is a simple example in the Tutorial section of the manual at https://guix-forge.systemreboot.net/manual/dev/en/ For a more complex real world configuration that, among other things, does continuous deployment of a web service, you can look at the guix-forge configuration for genenetwork.org at https://git.genenetwork.org/arunisaac/genenetwork-machines . The Laminar CI deployed by this configuration is at https://ci.genenetwork.org/ Thanks, Arun
