Re: Antioxidant (new rust build system) update - 100% builds

[Csepp]

Maxime Devos  writes:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> 100% (rounded up) of the packages build with antioxidant, though a
> very few still fail to build:
> .

Heck yeah!  This is some super exciting work. UwU

Compile skribilo doc containing guix channel references

[Phil]

Hi all,

I'd like to document a private guix channel using Guile-based document
framework: Skribilo - https://www.nongnu.org/skribilo/.

The idea is that the guix channel repo will contain a skb file which can
then reference code in the channel by setting the source-path and then
using the :definition in the source function to reference bits of the
package I want to talk about in my document.

(source :language [:tab 8] [:definition] [:stop] [:start] [:file])

This works really well, but it got me thinking - what would be even
cooler would be if I could import modules in my channel and actually
execute channel functions to generate document output as part of the
document compilation process, rather than just display the package code!

The problem with this is that in order to import modules in my channel,
I'd also have to have the guix core modules on my load-path at skribilo
compilation time, otherwise skribilo complains when my channel makes use
of guix modules.

For example, if I just add the channel packages without guix core
modules at the top of my skribilo document:
(add-to-load-path (string-append (dirname (current-filename)) "/packages"))

I understandably get something like the below:
no code for module (guix git)

Normally when scripting for guix you'd avoid the above problem by using
'guix repl -- some-script.scm' but here I'm using the skribilo
executable, *not* guix as the entry point - it's not entirely clear to me
how to get the required guix modules onto my load path?

As an ill-advised hack I tried the following under guix repl:
(use-modules (gnu packages))
(%package-module-path)

Then I added the returned paths via add-to-load-path at the top of my skb
file.  This resulted in:
$ GUILE_AUTO_COMPILE=0 guix environment --ad-hoc skribilo -- skribilo
--target=html --source-path=.. guix-packages.skb -o index.html
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
/gnu/store/8bab6fga7858whgd11f0wlsi2zsp4yr2-guix-module-union/share/guile/site/3.0/guix/packages.scm:361:5:
Unknown #object: "#~"

My guess is there is a better approach - any suggestions?  Perhaps I can
call the skribilo compiler from inside "guix repl" for example?

Cheers,
Phil.

Re: How do I reference the src checkout in a package?

[jgart]

On Sun, 30 Oct 2022 12:47:13 +0800 Zhu Zihao  wrote:
> 
> Try `#$(package-source this-package)` in the builder gexp.

Thanks! https://issues.guix.gnu.org/58898

Re: Questions about Cuirass

[James Hobson]

Sorry for not getting back to you.

Looks promising!

I wish I could release everything under a free license. Baby steps though! I’ve 
managed to release a few things under LGPL since I started! That’s 100% more 
than before!

But anyway. The biggest hurdle I see is that updating in an air gapped 
environment doesn’t seem supported because guix’s git url is hard coded. Does 
this need to be the case? If not, I might see if I can find an nice way of 
making this more configurable

James

> On 21 Oct 2022, at 11:01, Maxime Devos  wrote:
> 
> On 20-10-2022 23:19, James Hobson wrote:
>> Hello!
>> Currently evaluating guix for embedded systems at work. But I have a few 
>> questions that I can’t quite work out from the docs. Please feel no 
>> obligation to answer!
>> Please note that my guix journey is at its very beginning. I’ve not even had 
>> a go at packaging!
>> Question 1
>> We would need to host the guix substitute server in an airgapped 
>> environment. The server would contain plain guix packages, our in house 
>> packages, and maybe patched guix packages. Would that be possible without 
>> having to rebuild the entire guix package set? We don’t have so many build 
>> machines, especially not for armv7.
> 
> You can tell Cuirass to only build a selection of packages (and their 
> dependencies), by using a manifest, then not all of Guix is compiled but only 
> what's necessary for your particular purpose.
> 
> Also, your Cuirass instance still needs access to the source code of the 
> packages somehow, which will need to be somehow be squared with your 
> 'airgapped environment', though maybe 'copy over the result of guix build 
> --sources=transitive" would be acceptable (*).
> 
> (*) except that this is after application of snippet; some kind of 
> "--sources=raw,transitive" may be needed.
> 
>> Question 2 [...]
> 
> I don't know the answer to this.
> 
>> Question 3
>> Our software is sadly proprietary. Is there a way for guix build to 
>> selectively unpack and patch all non-proprietary sources so that we can 
>> provide it to anyone who asks? I feel like if this isn’t a thing already, I 
>> guess I can write it in scheme?
> 
> I assume you meant 'patch all non-proprietary' -> 'patch out all 
> proprietary', such that at least the free parts can be used?
> 
> In that case, this is done already in some package definitions in Guix, by a 
> 'snippet' removing parts that are non-free, such that they are not built and 
> are not part of "guix build --source". (See: ‘Snippets versus Phases’ in the 
> documentation, though it doesn't mention non-free things directly).
> 
> The Guix user can still access the unpatched source code though, by 
> inspecting the package definition and removing the snippet, so it looks to me 
> like that option is only good for 'you aren't allowed to modify this part of 
> the source code + guix build --source must produce something free', not for 
> 'you aren't allowed to see or distribute this' situations.
> 
> Alternatively, you could avoid all this complexity by making your software 
> free.
> 
> Greetings,
> Maxime.
>