Any go expert willing to help with updating IPFS?

[Konrad Hinsen]

Hi Guix,

the version of IPFS in Guix is 0.8, and in view of the important changes
introduced in 0.10, that's obsolete by now. Which is why I am trying to
update to 0.11.

My current package definition is attached. It fails, but provides no
clear hint (to the Go ignorant that I am) about what is actually going
wrong:

   starting phase `build'
   
src/github.com/ipfs/go-ipfs/vendor/github.com/lucas-clemente/quic-go/internal/qerr/error_codes.go:6:2:
 build constraints exclude all Go files in 
/tmp/guix-build-go-ipfs-0.11.0.drv-0/src/github.com/ipfs/go-ipfs/vendor/github.com/lucas-clemente/quic-go/internal/qtls
   Building 'github.com/ipfs/go-ipfs/cmd/ipfs' failed.

The build log then shows the results of `go env`, where nothing looks
suspicious to me. Then another cryptic line:

   command "go" "install" "-v" "-x" "-ldflags=-s -w" 
"github.com/ipfs/go-ipfs/cmd/ipfs" failed with status 1

Does anyone have an idea for debugging this issue?

Cheers,
  Konrad.

Re: Guix Documentation Meetup

[Katherine Cox-Buday]

Blake Shaw  writes:

> I'd love to know where you found trouble so that I can take that into
> consideration when developing a design strategy for the makeover.

When reading this, please keep in mind that I have a lot of gratitude for the 
various maintainers of this software and its respective documentation. 
Communication is very difficult, and relaying my experience and opinions is 
meant to convey that experience, and not to criticize anyone's efforts.

I think my frustration stems from the confluence of me not being familiar with 
scheme, how Guix writes scheme, how scheme the language and ecosystem work, the 
tools we have available to us, and then finally the documentation.

Not being a schemer (yet?), I can't speak with much authority, aside from the 
fact that I've written code in many languages, and most of these pain points 
are well addressed in others.

Usually, my frustrated workflow goes like this (warning: ignorance on display! 
:p):

- Identify something in Guix I want to do

- Open (or create) a file

- Start geiser

- Start writing Guile

- Come upon a semantic structure I want to write, and realize I don't know the
  Guile way to do it.
  
- In geiser, run =,a thing-i-want-to-look-for= (this is supposedly an apropos
  command that is supposed to search symbols for you). The command returns
  nothing. I realize I have to import the module implementing the thing I'm
  looking for first, thus defeating the purpose.

- Before, I would then go here[1] and try and textually search for the symbol.
  I have recently discovered the emacs function: =helm-info-guile= which makes
  searching a bit faster.

- Find that there are multiple, competing, modules which do the same thing in
  different ways.

- Realize I don't know which one to use, or which one Guix would prefer.

- Sometimes, realize that Guix has their own wrapper around one of the
  modules, and learn that something I thought was standard scheme is actually
  a Guix neologism.

- Import one and try it. Maybe import another and try it. Lose track of why
  I've imported things as I'm trying them because the module names have no
  indication of what they implement.

- Wish that Guix had a standard to prefix function calls with their module, as
  we do with =license:=.

- Have no way of automatically and programatically cleaning up imports to work
  around this.

- Forget what I was even trying to accomplish. Go to bed and try again
  tomorrow!

Specific to Guile documentation, I guess if I boil the above down, it would be 
something like:

Early in the documentation, directly address the intrinsic fragmentation of the 
scheme ecosystem, and how a new Guiler is meant to navigate that. Do so in 
terms that don't rely on experience with the Scheme ecosystem.

The Guile reference manual has this[2] section which, to me, is a paragraph 
which touches on this, and then much later has a blurb[3] on what SRFI is. I 
had no idea what =ice-9= was, and the first mention[5] of it in the manual is 
one of its modules. To my knowledge, what =ice-9= is, or why it's called that, 
is never addressed. It appears[5] I am not the first to be confused by this.

As a newcomer to Guile, and to scheme, I would expect Guile to give me its 
opinion of how to do things (i.e. which modules to prefer, what is considered 
"standard" in most schemes) until I've written enough Guile to form my own. As 
it's written, my impression is that the documentation relies on the reader 
knowing a lot about scheme coming in.

I feel there just needs to be an easier gradient for people trying to use Guile 
as their first scheme. It is not specifically Guile's problem, but as a service 
to its developers, the meta-topic should be addressed so a new developer is not 
left confused.

When we put a lot of work into something, it's really easy to fall in love with 
the idiosyncrasies of the thing, and to lose sight of what it's like to come 
into an ecosystem with no context. This can result in addressing things that 
feel important to us, the expert, but are really much further up the ladder of 
complexity.

When writing a landing page for a language, I feel the following is important:

*Don't overwhelm your newcomers.*
Your landing page should have few links, and they should directly address 
high-level questions:

- What am I looking at?
- How is what I'm looking at organized?
- What should people like me (e.g. non-programmers, programmers, schemers,
  people who don't speak English) be reading?
- A link to a site which provides easy to use symbol lookup.

The documentation can fan out in complexity from there, but the landing page 
must not be overwhelming.

Anyway, those are my opinions :)

[1] - https://www.gnu.org/software/guile/manual/guile.html
[2] - https://www.gnu.org/software/guile/manual/guile.html#Guile-Scheme
[3] - https://www.gnu.org/software/guile/manual/guile.html#SRFI-Support
[4] - https://www.gnu.org/software/guile/manual/guile.html#ice_002d9-optargs
[5] - 

Re: How to handle package udev rules?

[Danny Milosavljevic]

Hi,

On Sun, 12 Dec 2021 21:58:14 +0100
g...@member.fsf.org wrote:

> If I change my operating-system config to inlcude udev-rules from
> package "projecteur" everything works fine - at least if I do it as a
> regular user. As soon as I sudo the guix system reconfigure command the
> package is known but it's code is not. Error message is:
> 
> > $ sudo guix system reconfigure ~/etc/config.scm
> > ice-9/boot-9.scm:3329:6: In procedure resolve-interface:
> > no code for module (projecteur)  
> 
> Could it be the case that sudo'ed the variable GUIX_PACKAGE_PATH is not
> known or not interpreted correctly? Does the package need to reside
> somewhere else than in GUIX_PACKAGE_PATH?

Yeah, sudo is very paranoid. You need to pass -E GUIX_PACKAGE_PATH to it:

   sudo -E GUIX_PACKAGE_PATH guix system reconfigure ~/etc/config.scm


pgp4jE7o4Rtsb.pgp
Description: OpenPGP digital signature

Re: How to handle package udev rules?

[gyps]

Dear Danny, dear Tobias,

thanks for the hints which immediately solved my issue.
It now compiles and everyting is fine but one thing.

If I change my operating-system config to inlcude udev-rules from
package "projecteur" everything works fine - at least if I do it as a
regular user. As soon as I sudo the guix system reconfigure command the
package is known but it's code is not. Error message is:

> $ sudo guix system reconfigure ~/etc/config.scm
> ice-9/boot-9.scm:3329:6: In procedure resolve-interface:
> no code for module (projecteur)

Could it be the case that sudo'ed the variable GUIX_PACKAGE_PATH is not
known or not interpreted correctly? Does the package need to reside
somewhere else than in GUIX_PACKAGE_PATH?

Cheers,

Alex

On Sun, Dec 12 2021, 19:17:26, Danny Milosavljevic  
wrote:

> [[PGP Signed Part:Undecided]]
> Hello Alexander,
>
> On Sun, 12 Dec 2021 13:12:50 +0100
> Alexander Asteroth  wrote:
>
>> I tried to import the libgudev module but that that only results in the
>> package wanting to write to another write-protected directory from the
>> store.
>
> It's supposed to write those to $output/lib/udev/rules.d (s.t. there's
> *.rules inside) instead.   There's usually a cmake variable to make it do
> that--but you need to look at the CMakeLists.txt in question.
>
> Guix will pick those up if they originate in something it can see and add
> those to Guix's udev service automatically (via the service extension 
> mechanism,
> which allows you to extend service config from outside the udev service).
>
> Are you using Guix as an operating system? Or on top of another distribution?
>
>> As I understand, the udev-rules are usually created on system level.
>
> Yes.
>
>> That would mean I need to split the package into a service part
>> and a package part? And remove the installation of the udev-file from
>> the package install process?
>
> Kinda not really--at least not exactly.  See below.
>
> Example I'm using (that one definitely works--but I only add the custom
> package because the upstream package doesn't do it![1]):
>
> /etc/config.scm :
>
> (define my-ledger-nano
>   (package
> (name "my-ledger-nano")
> (version "1")
> (source #f)
> (build-system trivial-build-system)
> (synopsis "")
> (description "")
> (license #f)
> (home-page #f)
> (arguments
>  `(#:builder
>(begin
>  (mkdir %output)
>  (mkdir (string-append %output "/lib"))
>  (mkdir (string-append %output "/lib/udev"))
>  (mkdir (string-append %output "/lib/udev/rules.d"))
>  (call-with-output-file (string-append %output 
> "/lib/udev/rules.d/99-my-ledger-nano.rules")
>(lambda (port)
>  (format port
> "SUBSYSTEM==\"usb\", ATTRS{idVendor}==\"2c97\", MODE=\"0600\", 
> OWNER=\"dannym\", TAG+=\"uaccess\", TAG+=\"udev-acl\"
> KERNEL==\"hidraw*\", ATTRS{idVendor}==\"2c97\", MODE=\"0600\", 
> OWNER=\"dannym\", SYMLINK+=\"ledger_%n\", TAG+=\"uaccess\", TAG+=\"udev-acl\"
> ")))
>  #t)
>
> (operating-system
>   ...
>   (services
> (simple-service 'custom-udev-rules udev-service-type (list 
> sane-backends my-ledger-nano)))
>
> You can add your package reference there and it will work.
>
> Or you can try adding your package reference into
>   (operating-system (packages (list ...)))--should be enough.
>
> If you mean adding your package's udev rules to the operating system
> configuration without being the "root" user in-between: no, that would be a
> (very bad! those rules run as root!) security problem.
>
> In the case of your package, it seems[0] that they calculate the directory to
> store the udev rules to from pkg-config--which will result in the udev
> package's install directory. That won't work.
>
> But in line 214 in [0] they seem to allow you to override it anyway.
> So you can try to call cmake with
>
>   -DCMAKE_INSTALL_UDEVRULESDIR=$output//lib/udev/rules.d
>
> like this (in your package definition):
>
> (package
>   ...
>   (arguments
>  '(#:configure-flags (list (string-append "-DCMAKE_INSTALL_UDEVRULESDIR="
>   (assoc-ref %outputs "out")
>   "/lib/udev/rules.d"
>
> [0] https://github.com/jahnf/Projecteur/blob/develop/CMakeLists.txt#L231
> [1] https://github.com/LedgerHQ/udev-rules/pull/8
>
> [[End of PGP Signed Part]]

Re: How to handle package udev rules?

[Danny Milosavljevic]

Hello Alexander,

On Sun, 12 Dec 2021 13:12:50 +0100
Alexander Asteroth  wrote:

> I tried to import the libgudev module but that that only results in the
> package wanting to write to another write-protected directory from the
> store.

It's supposed to write those to $output/lib/udev/rules.d (s.t. there's
*.rules inside) instead.   There's usually a cmake variable to make it do
that--but you need to look at the CMakeLists.txt in question.

Guix will pick those up if they originate in something it can see and add
those to Guix's udev service automatically (via the service extension mechanism,
which allows you to extend service config from outside the udev service).

Are you using Guix as an operating system? Or on top of another distribution?

> As I understand, the udev-rules are usually created on system level.

Yes.

> That would mean I need to split the package into a service part
> and a package part? And remove the installation of the udev-file from
> the package install process?

Kinda not really--at least not exactly.  See below.

Example I'm using (that one definitely works--but I only add the custom
package because the upstream package doesn't do it![1]):

/etc/config.scm :

(define my-ledger-nano
  (package
(name "my-ledger-nano")
(version "1")
(source #f)
(build-system trivial-build-system)
(synopsis "")
(description "")
(license #f)
(home-page #f)
(arguments
 `(#:builder
   (begin
 (mkdir %output)
 (mkdir (string-append %output "/lib"))
 (mkdir (string-append %output "/lib/udev"))
 (mkdir (string-append %output "/lib/udev/rules.d"))
 (call-with-output-file (string-append %output 
"/lib/udev/rules.d/99-my-ledger-nano.rules")
   (lambda (port)
 (format port
"SUBSYSTEM==\"usb\", ATTRS{idVendor}==\"2c97\", MODE=\"0600\", 
OWNER=\"dannym\", TAG+=\"uaccess\", TAG+=\"udev-acl\"
KERNEL==\"hidraw*\", ATTRS{idVendor}==\"2c97\", MODE=\"0600\", 
OWNER=\"dannym\", SYMLINK+=\"ledger_%n\", TAG+=\"uaccess\", TAG+=\"udev-acl\"
")))
 #t)

(operating-system
  ...
  (services
(simple-service 'custom-udev-rules udev-service-type (list 
sane-backends my-ledger-nano)))

You can add your package reference there and it will work.

Or you can try adding your package reference into
  (operating-system (packages (list ...)))--should be enough.

If you mean adding your package's udev rules to the operating system
configuration without being the "root" user in-between: no, that would be a
(very bad! those rules run as root!) security problem.

In the case of your package, it seems[0] that they calculate the directory to
store the udev rules to from pkg-config--which will result in the udev
package's install directory. That won't work.

But in line 214 in [0] they seem to allow you to override it anyway.
So you can try to call cmake with

  -DCMAKE_INSTALL_UDEVRULESDIR=$output//lib/udev/rules.d

like this (in your package definition):

(package
  ...
  (arguments
 '(#:configure-flags (list (string-append "-DCMAKE_INSTALL_UDEVRULESDIR="
  (assoc-ref %outputs "out")
  "/lib/udev/rules.d"

[0] https://github.com/jahnf/Projecteur/blob/develop/CMakeLists.txt#L231
[1] https://github.com/LedgerHQ/udev-rules/pull/8


pgpJcpN9h9FfN.pgp
Description: OpenPGP digital signature

Re: How to handle package udev rules?

[Tobias Geerinckx-Rice]

Alexander,

Alexander Asteroth 写道：
The question now is, what is the correct guix-way to implement 
this:


Not as complicated as you fear!

udev rules aren't special.  Just install them to the package's own 
/lib/udev/rules.d directory.  If the build system tries to 
write to another package's output, see if it provides any options 
to change that, or patch it in the worst case.



As I understand, the udev-rules are usually created on system
level. That would mean I need to split the package into a 
service part
and a package part? And remove the installation of the udev-file 
from

the package install process?


Guix System provides a ready-made udev-rules-service to gather up 
all desired udev rules and pass them to the running udev.  I think 
this is how it works:


 (operating-system
   […]
   (services
 (cons* […]
(udev-rules-service 'projecteur
projecteur)
%base-services)))

‘Think’ because I do it differently in my own configurations.

Or is there another way for a package to provide the udev rules 
from a
user-level install? 


If this means ‘can I use Guix's udev rules on a foreign 
distribution’: I'm not sure, but not out of the box.


Kind regards,

T G-R


signature.asc
Description: PGP signature

How to handle package udev rules?

[Γυψ]

Sorry, I sent this email from a non-subscribed account and therefore it
probably wasn't sent (if you receive it twice sorry for that).

Dear all,

I'm trying to build my first guix package and so far, after a lot of
trial and error to find the right packages providing the necessary cmake
functionality I managed to get the package to compile. (up to the point
where the install script want's to copy some udev rules file) 

The package is a linux software that can be used with logitech
presenters [0]. Therefore it needs udev rules/devices to communicate
with the device.

The question now is, what is the correct guix-way to implement this:

I tried to import the libgudev module but that that only results in the
package wanting to write to another write-protected directory from the
store.

As I understand, the udev-rules are usually created on system
level. That would mean I need to split the package into a service part
and a package part? And remove the installation of the udev-file from
the package install process?

Or is there another way for a package to provide the udev rules from a
user-level install? 

Cheers,
Alex

-

[0] https://github.com/jahnf/Projecteur

How to handle package udev rules?

[Alexander Asteroth]

Dear all,

I'm trying to build my first guix package and so far, after a lot of
trial and error to find the right packages providing the necessary cmake
functionality I managed to get the package to compile. (up to the point
where the install script want's to copy some udev rules file) 

The package is a linux software that can be used with logitech
presenters [0]. Therefore it needs udev rules/devices to communicate
with the device.

The question now is, what is the correct guix-way to implement this:

I tried to import the libgudev module but that that only results in the
package wanting to write to another write-protected directory from the
store.

As I understand, the udev-rules are usually created on system
level. That would mean I need to split the package into a service part
and a package part? And remove the installation of the udev-file from
the package install process?

Or is there another way for a package to provide the udev rules from a
user-level install? 

Cheers,
Alex

-

[0] https://github.com/jahnf/Projecteur

Re: [bug#51845] [CORE-UPDATES] librsvg and rust

[Efraim Flashner]

On Wed, Dec 08, 2021 at 02:36:11PM +, Ricardo Wurmus wrote:
> 
> Ludovic Courtès  writes:
> 
> > Hello!
> >
> > For the record, this is a followup to Efraim’s proposal in
> > .
> >
> > Efraim Flashner  skribis:
> >
> >> Option 1:
> >> Track down the ~220 crates which form the dependency graph (of crates)
> >> for librsvg and pin them until the next core-updates cycle. Continue
> >> like with other packages and add newer versions (like cmake or meson) as
> >> packages need them.¹
> >
> > The advantage of this approach is that we could do it incrementally: we
> > could merge ‘core-updates-frozen’ today and just add pinned variants of
> > these 200+ crates as needed as time passes.  The downside is that it’s a
> > lot of crates to take care of, and we might still accidentally overlook
> > seemingly innocuous crate upgrades that end up causing major rebuilds.
> >
> >> Option 2:
> >> Use the bundled crates and treat it as just part of the librsvg source
> >> code.²
> >>
> >> Option 2b:
> >> Use the bundled crates for now to finish with core-updates-frozen and
> >> revisit this immediately on core-updates (not frozen).
> >
> > This option will involved a rebuild on x86_64, but the advantage is that
> > we’ll be safe going forward: we won’t accidentally cause world rebuilds
> > just because an obscure crate somewhere has been upgraded.
> >
> > [...]
> >
> >> I'm currently leaning option 2b, it'll get us past this hurdle for
> >> core-updates-frozen and let us make changes to the crates as we work to
> >> integrate them more fully into Guix.
> >
> > Same here; it’s not ideal, but it seems like the most reasonable
> > short-term option.
> >
> > If there are no objections, I’d suggest that you go ahead with this
> > plan.
> 
> I agree that 2b is the most sensible option in our current situation.

Patches pushed to core-updates-frozen. I added a TODO to fix the
situation.

Thanks for the input everyone.

-- 
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