Re: A Few Irc Logs

[jbranso]

October 28, 2022 6:09 PM, "jgart"  wrote:

> Does anyone know of any program that generates tags for irc logs?
> 
> Kind of like afew but for massive irc logs not unlike logs.guix.gnu.org
> 
> * https://github.com/afewmail/afew

You might get better answers in the help-guix list, which I am CC-ing now.

You might have some good luck asking this in #guix too.  :)

Re: "guix system init" from regular system fails

[Tobias Geerinckx-Rice]

Hi Li!

l...@dotdot.li 写道：
  The only difference is that I did not run "herd start 
  cow-store /mnt".
That service is only available when using the installer.  I also 
believe

that it is not necessary because the documentation says that


Correct.  It's only for (and on) the ‘live’ installer.

  After this /mnt/gnu/store is populated and the bootloader also 
  appears

to be installed.  However, this is not a usable system.


OK…  how exactly did you try to use it?


/mnt/{bin,etc,
home,run} are all empty (except for /mnt/etc/config.scm).  Where 
did I

go wrong?


What makes you think you did?  I've never seen these directories 
be populated by guix system init.


Did you try to boot it?  If so, please share the errors you got.

Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Help packaging R Quarto Cli

[Sébastien Rey-Coyrehourcq]

Wojtek Kosior  writes:

> I think I almost understand your approach. Just a quick question - what
> Guix command are you using to try building? With this setup I’d try
> something like
>
> guix shell -L ./export/ rust-deno
>

Actually, from export folder i try :
i try *guix build -L . -f rust-deno-1.scm*

But the module are not loaded, i don’t understand well the way guix load module 
it seems.

Into rust-deno-1.scm i put :

(define-module (rust-deno-1 rust-deno-1)
 #:use-module (rust-cache-control-0.2 rust-cache-control-0.2)

and into ./rust-cache-control-0.2/rust-cache-control-0.2.scm i put :

(define-module (rust-cache-control-0.2 rust-cache-control-0.2)

But any of this pass using the *guix build* command :

`no code for module (rust-cache-control-0.2 rust-cache-control-0.2)'


> and then I’d put
>
> (define-module (rust-ecdsa-0.14 rust-ecdsa-0.14)
>   #:use-module (rust-serdect-0.1 rust-serdect-0.1))
>
> inside `./export/rust-ecdsa-0.14/rust-ecdsa-0.14.scm`. That’s how guile
> modules work - a module is identified by a list of symbols that match
> module file’s path (starting from a guile’s modules root directory, in
> this case the one passed via the `-L` option).
>
>> If that works locally i suppose i could sent a patch with all the
>> rust modules needed to build Deno ?
>
> A patch would then expect the module(s) to be put under gnu/packages in
> the Guix repo and then their `#:use-module` lines would need to be
> modified accordingly… So you’d need to make these small adaptations
> first.
>
> Honestly, I haven’t been submitting patches before and I don’t know
> exactly what module structure Guix devs expect. Perhaps someone else
> may help you here.
>
> Anyway, it seems right now you just have the result of running
> `guix import` and you have not yet built any of those recipes? I don’t
> want to be pessimistic but here’s a warning - there’ll surely be some
> fixes you’ll have to make. Be prepared to dive into scheme :)
>

I first put all the things into deno.scm, with thousand of lines, that compile 
a little… and i changing my mind finally …
imho the module way is perhaps less discouraging : Resolving bug modules by 
modules…

I push some corrections to my python script to generate good module name when i 
found.

Yes, i probably need some guile diving …

Best,
Sr-C.

> Best,
> Wojtek
>
> – (sig_start)
> website: 
> PGP: 
> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>
> Meet Kraków saints!   #16: saint Jan z Dukli
> Poznaj świętych krakowskich!  #16: święty Jan z Dukli
> 
> – (sig_end)
>
>
> On Fri, 28 Oct 2022 18:19:32 +0200
> Sébastien Rey-Coyrehourcq  wrote:
>
>> Hi,
>>
>> Wojtek Kosior  writes:
>>
>> >> Hi,
>> >>
>> >> I continue the packaging using guix import crate, this is a slow process, 
>> >> but everything goes well at this time.
>> >>
>> >> My file deno.scm contain 6000 line, with all packages imported, this is a 
>> >> problem because i need to remove duplicate.
>> >> The best way was probably to export all `(define public method … )`  into 
>> >> a folder with corresponding library.scm.
>> >
>> > Do you have wour work-in-progress in some public repo? This would make
>> > us easier to understand your setup and would also allow more ppl to
>> > cooperate (although unfortunately Idk if there’s anyone else who’s
>> > particularly interested in deno at this particular moment).
>> >
>>
>> Here we are : 
>>
>> This is a wip python script that build an `export/’ directory containing all 
>> rust module needed to compile deno (i suppose)
>>
>> The deno script is localized at the root of `export/’ folder
>>
>> I build the modules folders, but know i don’t know how to compile all this 
>> folders correctly using correct path …
>> Any guile help appreciated to do that !
>>
>> For example, the module *./export/rust-ecdsa-0.14/rust-ecdsa-0.14.scm* need 
>> a module localized to *./export/rust-serdect-0.1/rust-serdect-0.1.scm*
>>
>> I simply try *#:use-module (../rust-serdect-01)* in *rust-ecdsa-0.14* 
>> define-module but this probably not the good way.
>>
>> >> I need to create a module by package do you thing ? and after that import 
>> >> all the package using `use-modules` ?
>> >
>> > From what I’ve seen, Guix package definitions are usually grouped into
>> > modules thematically. Although until you actually try upstreaming your
>> > work, you’re not bound by any reqs and you can structure the
>> > definitions in a way that’s comfortable for you.
>> >
>> > Also, are you adding your package by modifying the actual Guix sources?
>> > Or by creating modules outsite of these? Perhaps this was already
>> > metioned but I don’t have previous emails on the top…
>> >
>>
>> If that works locally i suppose i could sent a patch with all the rust 
>> modules needed to build Deno ?
>>
>> Best !
>> SR.
>>
>> > Good 

"guix system init" from regular system fails

[li]

Hello,

  I am trying to prepare a new system on new drive from my current Guix
installation, i.e., the first way mentioned in (info "(guix)System
Images").  The documentation at (info "(guix)Invoking guix system)") is
sparse, so I followed those in (info "(guix)Manual Installation"), which
I have successfully done before a couple of times.

  I have made sure the partitions are mounted (/ and /boot/efi @ /mnt
and /mnt/boot/efi) and that that they are correctly configured in
/mnt/etc/config.scm.

  The only difference is that I did not run "herd start cow-store /mnt".
That service is only available when using the installer.  I also believe
that it is not necessary because the documentation says that

> This makes ‘/gnu/store’ copy-on-write, such that packages added to it
> during the installation phase are written to the target disk on ‘/mnt’
> rather than kept in memory.  This is necessary because the first phase
> of the ‘guix system init’ command (see below) entails downloads or
> builds to ‘/gnu/store’ which, initially, is an in-memory file system.

  In this case /gnu/store is not an in-memory file system, so I assume
this is not necessary.  But maybe something equivalent is necessary?

  "sudo guix system init /mnt/etc/config.scm /mnt" succeeds quickly
with output:

<...snip...>
/gnu/store/dhk4hrjpqfcph2alliwg18iiqwc3j86x-system
/gnu/store/q6b71455an8dl1hg8y859rkja22fxk4j-grub.cfg

initializing operating system under '/mnt/'...
copying to '/mnt'...
populating '/mnt'...
The following derivation will be built:
  /gnu/store/sjg10gcq9m88ad7q3znqxfc7qyq4aq8j-install-bootloader.scm.drv

building 
/gnu/store/sjg10gcq9m88ad7q3znqxfc7qyq4aq8j-install-bootloader.scm.drv...
guix system: bootloader successfully installed on /boot/efi


  After this /mnt/gnu/store is populated and the bootloader also appears
to be installed.  However, this is not a usable system. /mnt/{bin,etc,
home,run} are all empty (except for /mnt/etc/config.scm).  Where did I
go wrong?

  Thanks for your help!
  L

Re: Help packaging R Quarto Cli

[Wojtek Kosior via]

I think I almost understand your approach. Just a quick question - what
Guix command are you using to try building? With this setup I'd try
something like

guix shell -L ./export/ rust-deno

and then I'd put

(define-module (rust-ecdsa-0.14 rust-ecdsa-0.14)
  #:use-module (rust-serdect-0.1 rust-serdect-0.1))

inside `./export/rust-ecdsa-0.14/rust-ecdsa-0.14.scm`. That's how guile
modules work - a module is identified by a list of symbols that match
module file's path (starting from a guile's modules root directory, in
this case the one passed via the `-L` option).

> If that works locally i suppose i could sent a patch with all the
> rust modules needed to build Deno ?

A patch would then expect the module(s) to be put under gnu/packages in
the Guix repo and then their `#:use-module` lines would need to be
modified accordingly... So you'd need to make these small adaptations
first.

Honestly, I haven't been submitting patches before and I don't know
exactly what module structure Guix devs expect. Perhaps someone else
may help you here.

Anyway, it seems right now you just have the result of running
`guix import` and you have not yet built any of those recipes? I don't
want to be pessimistic but here's a warning - there'll surely be some
fixes you'll have to make. Be prepared to dive into scheme :)

Best,
Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!   #16: saint Jan z Dukli
Poznaj świętych krakowskich!  #16: święty Jan z Dukli
https://pl.wikipedia.org/wiki/Jan_z_Dukli
-- (sig_end)


On Fri, 28 Oct 2022 18:19:32 +0200
Sébastien Rey-Coyrehourcq  wrote:

> Hi,
> 
> Wojtek Kosior  writes:
> 
> >> Hi,
> >>
> >> I continue the packaging using guix import crate, this is a slow process, 
> >> but everything goes well at this time.
> >>
> >> My file deno.scm contain 6000 line, with all packages imported, this is a 
> >> problem because i need to remove duplicate.
> >> The best way was probably to export all `(define public method … )`  into 
> >> a folder with corresponding library.scm.  
> >
> > Do you have wour work-in-progress in some public repo? This would make
> > us easier to understand your setup and would also allow more ppl to
> > cooperate (although unfortunately Idk if there’s anyone else who’s
> > particularly interested in deno at this particular moment).
> >  
> 
> Here we are : 
> 
> This is a wip python script that build an `export/' directory containing all 
> rust module needed to compile deno (i suppose)
> 
> The deno script is localized at the root of `export/' folder
> 
> I build the modules folders, but know i don’t know how to compile all this 
> folders correctly using correct path …
> Any guile help appreciated to do that !
> 
> For example, the module *./export/rust-ecdsa-0.14/rust-ecdsa-0.14.scm* need a 
> module localized to *./export/rust-serdect-0.1/rust-serdect-0.1.scm*
> 
> I simply try *#:use-module (../rust-serdect-01)* in *rust-ecdsa-0.14* 
> define-module but this probably not the good way.
> 
> >> I need to create a module by package do you thing ? and after that import 
> >> all the package using `use-modules` ?  
> >
> > From what I’ve seen, Guix package definitions are usually grouped into
> > modules thematically. Although until you actually try upstreaming your
> > work, you’re not bound by any reqs and you can structure the
> > definitions in a way that’s comfortable for you.
> >
> > Also, are you adding your package by modifying the actual Guix sources?
> > Or by creating modules outsite of these? Perhaps this was already
> > metioned but I don’t have previous emails on the top…
> >  
> 
> If that works locally i suppose i could sent a patch with all the rust 
> modules needed to build Deno ?
> 
> Best !
> SR.
> 
> > Good luck :)
> > Wojtek
> >
> > – (sig_start)
> > website: 
> > PGP: 
> > fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
> >
> > Meet Kraków saints!   #33: blessed Antonin Bajewski
> > Poznaj świętych krakowskich!  #33: błogosławiony Antonin Bajewski
> > 
> > – (sig_end)
> >
> >
> > On Thu, 27 Oct 2022 09:05:52 +0200
> > Sébastien Rey-Coyrehourcq  wrote:
> >  
> >> Hi,
> >>
> >> I continue the packaging using guix import crate, this is a slow process, 
> >> but everything goes well at this time.
> >>
> >> My file deno.scm contain 6000 line, with all packages imported, this is a 
> >> problem because i need to remove duplicate.
> >> The best way was probably to export all `(define public method … )`  into 
> >> a folder with corresponding library.scm.
> >>
> >> I need to create a module by package do you thing ? and after that import 
> >> all the package using `use-modules` ?
> >>
> >> Best
> >>
> >> Wojtek Kosior  writes:
> >>
> 

Re: look up for Guix version installed

[Gottfried]

Sincere thanks to paren, T G-R

I came to this idea because when I check:

 guix pull --news --details

then it shows me the new and updated packages.

And today there was:

guix 1.3.0-32.682639c

besides

 icedove-wayland@102.4.1,icedove@102.4.1, keepassxc@2.7.3, 
komikku@1.2.0, linux-libre-bpf@5.19.17 etc.


When icedove@102.4.1 shows the new version, which can be installed,
so I guessed that the new guix version can also be shown through a command.

Gottfried


Am 28.10.22 um 20:10 schrieb Tobias Geerinckx-Rice:

Gottfried 写道：

I would like to have the numbers... guix 1.3.0-32


Right.  That's what ‘guix --version’ should provide, but it's currently 
broken:


  λ guix --version
  guix (GNU Guix) 0

You can plug the commit given by ‘guix describe’ (or ‘guix system 
describe’, which can differ!) into a local Guix git checkout as a 
horrible work-around:


  λ guix describe
    […]
    guix 39e00f7
  […]
    commit: 39e00f7f6a0b80e95cf16970d201c786684e076a
  λ git clone https://git.savannah.gnu.org/git/guix.git
  λ cd guix
  λ git describe 39e00f7f6a0b80e95cf16970d201c786684e076a
  v1.3.0-26871-g39e00f7f6a0 (your ‘32’ was just a bit optimistic  :-)

I'm so sorry, but it technically does ‘work’…

Kind regards,

T G-R




OpenPGP_0x61FAF349C9FB7F94.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: look up for Guix version installed

[Tobias Geerinckx-Rice]

Gottfried 写道：

I would like to have the numbers... guix 1.3.0-32


Right.  That's what ‘guix --version’ should provide, but it's 
currently broken:


 λ guix --version
 guix (GNU Guix) 0

You can plug the commit given by ‘guix describe’ (or ‘guix system 
describe’, which can differ!) into a local Guix git checkout as a 
horrible work-around:


 λ guix describe
   […]
   guix 39e00f7
 […]
   commit: 39e00f7f6a0b80e95cf16970d201c786684e076a
 λ git clone https://git.savannah.gnu.org/git/guix.git
 λ cd guix
 λ git describe 39e00f7f6a0b80e95cf16970d201c786684e076a
 v1.3.0-26871-g39e00f7f6a0 (your ‘32’ was just a bit optimistic 
 :-)


I'm so sorry, but it technically does ‘work’…

Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: look up for Guix version installed

[(]

On Fri Oct 28, 2022 at 6:13 PM BST, Gottfried wrote:
> I would like to have the numbers... guix 1.3.0-32

That's not the version of Guix you have installed; that's the version of the
``guix'' package, which follows its own versioning scheme and is periodically
updated to the latest commit (and you shouldn't install it).

-- (

Re: look up for Guix version installed

[Gottfried]

Guix describe gives me:

gfp@Tuxedo ~$ guix describe
Generation 47   28. Oktober 2022 18:42:17   (aktuell)
  guix 8fed831
Repository-URL: https://git.savannah.gnu.org/git/guix.git
Branch: master
Commit: 8fed831e2affd33b6a4e092a190128f991905342

but it does not give me:

guix@1.3.0-32.682639c

I would like to have the numbers... guix 1.3.0-32

Gottfried


Am 28.10.22 um 18:57 schrieb (:

On Fri Oct 28, 2022 at 5:53 PM BST, Gottfried wrote:

which command (CLI) should I use to get the version of Guix, that is
installed on my system.
I checked the manual but didn't find anything. May be I overread it.


   guix describe

 -- (




OpenPGP_0x61FAF349C9FB7F94.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: look up for Guix version installed

[(]

On Fri Oct 28, 2022 at 5:53 PM BST, Gottfried wrote:
> which command (CLI) should I use to get the version of Guix, that is 
> installed on my system.
> I checked the manual but didn't find anything. May be I overread it.

  guix describe

-- (

guix import no like lifetime fishy

[jgart]

$ guix import stackage carp -r
Backtrace:
  12 (primitive-load "/home/jgart/.config/guix/current/bin/g…")
In guix/ui.scm:
   2263:7 11 (run-guix . _)
  2226:10 10 (run-guix-command _ . _)
In guix/scripts/import.scm:
92:11  9 (guix-import . _)
In ice-9/boot-9.scm:
  1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/import/stackage.scm:
   109:26  7 (_)
In guix/import/utils.scm:
   594:27  6 (recursive-import _ #:repo->guix-package _ #:guix-name _ …)
   584:33  5 (lookup-node "carp" #f)
In guix/memoization.scm:
 98:0  4 (mproc "carp" #:include-test-dependencies? #t # "")
In unknown file:
   3 (_ # …)
In guix/import/stackage.scm:
   117:21  2 (_ "carp" #:include-test-dependencies? _ #:lts-version _ …)
 93:4  1 (lts-package-version _ _)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure struct-vtable: Wrong type argument in position 1 (expecting 
struct): #f

WDYT

look up for Guix version installed

[Gottfried]

Hi Guixers,

which command (CLI) should I use to get the version of Guix, that is 
installed on my system.

I checked the manual but didn't find anything. May be I overread it.

e.g.: guix@1.3.0-32.682639c

Gottfried


OpenPGP_0x61FAF349C9FB7F94.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Help packaging R Quarto Cli

[Sébastien Rey-Coyrehourcq]

Hi,

Wojtek Kosior  writes:

>> Hi,
>>
>> I continue the packaging using guix import crate, this is a slow process, 
>> but everything goes well at this time.
>>
>> My file deno.scm contain 6000 line, with all packages imported, this is a 
>> problem because i need to remove duplicate.
>> The best way was probably to export all `(define public method … )`  into a 
>> folder with corresponding library.scm.
>
> Do you have wour work-in-progress in some public repo? This would make
> us easier to understand your setup and would also allow more ppl to
> cooperate (although unfortunately Idk if there’s anyone else who’s
> particularly interested in deno at this particular moment).
>

Here we are : 

This is a wip python script that build an `export/' directory containing all 
rust module needed to compile deno (i suppose)

The deno script is localized at the root of `export/' folder

I build the modules folders, but know i don’t know how to compile all this 
folders correctly using correct path …
Any guile help appreciated to do that !

For example, the module *./export/rust-ecdsa-0.14/rust-ecdsa-0.14.scm* need a 
module localized to *./export/rust-serdect-0.1/rust-serdect-0.1.scm*

I simply try *#:use-module (../rust-serdect-01)* in *rust-ecdsa-0.14* 
define-module but this probably not the good way.

>> I need to create a module by package do you thing ? and after that import 
>> all the package using `use-modules` ?
>
> From what I’ve seen, Guix package definitions are usually grouped into
> modules thematically. Although until you actually try upstreaming your
> work, you’re not bound by any reqs and you can structure the
> definitions in a way that’s comfortable for you.
>
> Also, are you adding your package by modifying the actual Guix sources?
> Or by creating modules outsite of these? Perhaps this was already
> metioned but I don’t have previous emails on the top…
>

If that works locally i suppose i could sent a patch with all the rust modules 
needed to build Deno ?

Best !
SR.

> Good luck :)
> Wojtek
>
> – (sig_start)
> website: 
> PGP: 
> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>
> Meet Kraków saints!   #33: blessed Antonin Bajewski
> Poznaj świętych krakowskich!  #33: błogosławiony Antonin Bajewski
> 
> – (sig_end)
>
>
> On Thu, 27 Oct 2022 09:05:52 +0200
> Sébastien Rey-Coyrehourcq  wrote:
>
>> Hi,
>>
>> I continue the packaging using guix import crate, this is a slow process, 
>> but everything goes well at this time.
>>
>> My file deno.scm contain 6000 line, with all packages imported, this is a 
>> problem because i need to remove duplicate.
>> The best way was probably to export all `(define public method … )`  into a 
>> folder with corresponding library.scm.
>>
>> I need to create a module by package do you thing ? and after that import 
>> all the package using `use-modules` ?
>>
>> Best
>>
>> Wojtek Kosior  writes:
>>
>>
>> >> > Out of curiosity - what are the problems between Guix and JS? When I
>> >> > read this my first suspicion was that maybe TS is a self-hosted
>> >> > language and cannot be bootstrapped. However, when I ran `guix search
>> >> > typescript`, it revealed the existence of some TS->JS compiler called
>> >> > ’rust-swc’. So I guess problems lie somewhere else, right?
>> >>
>> >> Nothing per se.  Note that «TypeScript is a strongly typed programming
>> >> language that builds on JavaScript» and from my understanding (maybe I
>> >> am wrong?), it is hard to package Javascript for Guix because the
>> >> Javascript ecosystem is messy.  Janneke provides some explanations [1]
>> >> and I am not convinced the situation have changed since then.  Maybe I
>> >> am wrong…
>> >>
>> >> 1: 
>> >
>> > A few months ago (I think) I did run some code to actually check what
>> > the dependency tree of the protocol buffers JS library (from npm) is.
>> > The tree of runtime deps wasn’t horribly big. The tree of
>> > recursively-computed dev deps was, on the other hand, as bad as
>> > described by Janneke or even worse… However, It seems in most cases
>> > many of those packages designated as dev deps are not strictly needed
>> > for actually building stuff. Some are just test dependencies. Others
>> > were perhaps put there because developers understood “dev dependencies”
>> > differently from how packagers understand it…
>> >
>> > Anyway, it seems the only way to check what the situation really is is
>> > to actually try packaging something. I’m confident it will be way
>> > easier than it seems :)
>> >
>> > Luckily for Sébastien, it seems quarto-cli - although written mostly in
>> > JS/TS - has no NPM deps. Or at least I don’t see any…
>> >
>> > Wojtek
>> >
>> > – (sig_start)
>> > website: 
>> > PGP: 

Re: program prepared with `guix pack` unusable by end users

[Maxim Cournoyer]

Hello,

Wojtek Kosior  writes:

>> > IMHO yes, the pack output does not work as expected.  That's the
>> > definition of a bug.  
>> 
>> I disagree.  That Python gives precedence to USERSITE compared to
>> site-packages and GUIX_PYTHONPATH is by design, so that users can
>> override system provided libraries such as those by Guix.  It used to be
>> the other way around, and it caused all sort of problems such as
>> virtualenv not working as expected on Guix.

My memory failed me here; the past problems with Guix and virtualenv had
to do with us (ab)using PYTHONPATH, which would take precedence above
everything and not get reset by virtualenv, if I remember.

--8<---cut here---start->8---
$ . bin/activate
(venv) maxim@hurd /tmp/venv [env]$ python -m site
sys.path = [
'/tmp/venv',
'/gnu/store/bbakd2h7s4g62fymjmqpxgvlanp1ydny-python-3.9.9/lib/python39.zip',
'/gnu/store/bbakd2h7s4g62fymjmqpxgvlanp1ydny-python-3.9.9/lib/python3.9',

'/gnu/store/bbakd2h7s4g62fymjmqpxgvlanp1ydny-python-3.9.9/lib/python3.9/lib-dynload',
'/tmp/venv/lib/python3.9/site-packages',
]
USER_BASE: '/home/maxim/.local' (exists)
USER_SITE: '/home/maxim/.local/lib/python3.9/site-packages' (doesn't exist)
ENABLE_USER_SITE: False
--8<---cut here---end--->8---

We can see that virtualenv disables loading libraries from USER_SITE
(ENABLE_USER_SITE: False).  We can also see that it puts its
site-packages directly on sys.path.

> Perhaps the best solution would be to
> * have Python interpreter itself give precedence to user site packages but
> * have user site disabled (or enabled with lower precedence) by default
>   for Python applications.
>
> Consider the creation of wrapper script for python programs as it is
> done now[1]. Is there currently any application that would behave
> incorrectly with PYTHONNOUSERSITE exported as 1 and
> `~/.local/lib/python/site-packages/` included in
> GUIX-PYTHONPATH after the other paths? If there is, perhaps it would be
> at least easier to make a workaround for this single application?

I agree that setting PYTHONNOUSERSITE to 1 in the wrapper of Python
commands to ensure no stray user-installed librairies from under
"~/.local/lib/python/site-packages/" clash with their
operation would make sense.

Note that this is an interoperability problem between 'guix' and 'pip',
for 'pip install x' users that end up filling their
"~/.local/lib/python/site-packages/" directory.  If you
'rm -rf ~/.local/lib/python*' and stick to use only Guix-provided
packages, they won't experience any issue.

-- 
Thanks,
Maxim

Re: Package renpy broken?

[Wojtek Kosior via]

Hi Christian,

I know nothing about Ren'Py and TFD but it seems there's an
approachable workaround - you can modify the package to patch
launcher/game/choose_directory.rpy to have a suitable directory used.

First, I'd suggest you look at how some existing packages use the
`substitute*` macro[1]. Then, look at how packages are defined[2] and
how to *inherit* from another package[3].

Once you grasp a bit of it, you should be able to define your own
variant of the Ren'Py package. One without the bug.

I realize it's probably a bit discouraging to come to a new distro and
find out you need to learn packaging to utilize it. Indeed, I wish I
had more time to prepare such modified package for you. Yet, honestly,
Guix is a geeky package manager - you can only benefit from its
super-powers once you're yourself Guix geek ¯\_(ツ)_/¯

Good luck :)

Wojtek

P.S. If TFD are really free as in freedom, it'd be cool to have the
package fixed to actually use them. But that might be more involving
than merely patching a path...

[1] 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/game-development.scm?id=779757047997d315d899b40c199be3709115cce4#n171
[2] 
https://guix.gnu.org/manual/en/html_node/Defining-Packages.html#Defining-Packages
[3] https://guix.gnu.org/en/cookbook/en/guix-cookbook.html#Inheritance


-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!   #3: blessed Bernardyna Maria Jabłońska
Poznaj świętych krakowskich!  #3: błogosławiona Bernardyna Maria Jabłońska
https://pl.wikipedia.org/wiki/Bernardyna_Maria_Jabłońska
-- (sig_end)


On Thu, 27 Oct 2022 06:58:58 +
Christian Gelinek  wrote:

> Dear Guix community,
> 
> I couldn't get the GUI `renpy-launcher` GUI to do anything useful.  It 
> says "The selected projects directory is not writable" for any 
> meaningful action I attempted.  Under "preferences" -> General, there is 
> a Projects Directory setting which (for me) displays as "Not Set".  
> Clicking that again shows the above error.
> 
> I'm new to Ren'Py (and GuixSD), so there may be a way of specifying this 
> directory on the command line or via a config file somewhere, but I 
> haven't found it.
> 
> Looking at the code at 
> https://github.com/renpy/renpy/blob/master/launcher/game/choose_directory.rpy 
> it seems that it tries to import the `_renpytfd` Python package, which - 
> if successful - would be used to display a `selectFolderDialog`.  
> Otherwise, it would try to use the parent directory and if that fails, 
> the directory specified in config.renpy_base, which is set to the empty 
> string. Interestingly the empty string should resolve to the current 
> directory, but that doesn't seem to be the case in my `renpy-launcher` 
> context.
> 
> Another thing I found is that `_renpytfd` is being removed from the 
> renpy package in 
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/game-development.scm#n1347
>  
> which probably is the reason for why I can't set the path in the GUI.  
> The comment says "drop _renpytfd, as there are missing sources" but 
> https://sourceforge.net/projects/tinyfiledialogs/files/ seems to 
> disagree with that.  Additionally, there is a Guix package 
> rust-tinyfiledialogs which I expect to also (at least indirectly) depend 
> on tinyfiledialogs, which is not a package.
> 
> Where to go from here?
> 
> 




pgpa6S9hLkW6j.pgp
Description: OpenPGP digital signature

Re: microscheme fails to assemble BLINK.ms due to avr-gcc search path issue

[zimoun]

Hi,

Sorry for the late reply.

On sam., 24 sept. 2022 at 18:53, Milind Kamble  
wrote:

> ~/tmp> microscheme -v -m UNO -d /dev/ttyACM0 -a ./BLINK.ms
> Microscheme 0.9.3, (C) Ryan Suchocki
>>> './BLINK.ms' found.
>>> Treeshaker: After 4 rounds: 89 globals purged! 22 bytes will be reserved.
>>> Remaining globals: [forever arduino-ports arduino-pins set-ddr set-pin 
>>> high? output low? toggle led-pin loop ]
>>> 21 lines compiled OK
>>> Assembling...
> avr-ld: cannot find crtatmega328p.o: No such file or directory
> avr-ld: cannot find -lm
> avr-ld: cannot find -lc
> avr-ld: cannot find -latmega328p
> collect2: error: ld returned 1 exit status
>>> Warning: Command may have failed. (Exit code 256)
> avr-objcopy: 'BLINK.elf': No such file
>>> Warning: Command may have failed. (Exit code 256)
>>> Finished.
>
> To debug the issue, I cloned the microscheme from github and built the
> tool . Running that version also gave the exact same error. So after
> combing for hints online, I realized that perhaps the "-B" flag needs
> to be provided in the avr-gcc command launched by microscheme. And
> that worked.
> So the hack needed to make it work was
> avr-gcc -mmcu=atmega328p -B ~/.guix-profile/avr/lib/avr5 -o BLINK.elf BLINK.s
>
>
>  ~/.guix-profile/avr/lib/avr5 is a link to
> /gnu/store/r7kn43jwf4qj9lagj0pr4irzrwbvls0b-avr-libc-2.0.0/avr/lib/avr5
>   -- the key point being it points to a subdirectory of avr-libc
> But the default search path of avr-gcc does not include avr-libc in
> the store. Hence the -B hack works.
>
> The question is why do we need to specify -B explicitly. avr-libs
> should be included in the search path for avr-gcc.
> What am I missing?

Just a naive question because I know nothing about this topic, does it
work if more than lib/avr5 (e.g., avr25, avr, avr31, etc.) is provided
in the search path?


Cheers,
simon