Re: emacs-flymake-guix `guix lint -n`

[jgart]

On Thu, 14 Jul 2022 11:49:07 +0200 zimoun  wrote:
> Hi,
> 
> On Wed, 13 Jul 2022 at 21:18, jgart  wrote:
> > Hi Guixers is there currently an emacs package that provides a flymake 
> > backend for `guix lint -n`?
> 
> What do you mean?

See this collection of flymake backends, for example:

https://github.com/mohkale/flymake-collection/tree/release/src/checkers

I mean to have lint warnings show up as you're editing a guix package
in an emacs buffer and have it be integrated into the built-in flymake:

https://www.gnu.org/software/emacs/manual/html_mono/flymake.html


> Well, the Emacs package emacs-guix allows to use “guix lint” from
> Emacs.  Maybe improving this emacs-guix could be worth.  Or another
> fresh one just for linting; I do not know. :-)

Maybe adding a linter to flymake-collection might be the easiest.

I think the `guix lint` implementation in emacs-guix lets you run the
command manually but it's not integrated into a syntax checker like
flymake.

Correct me if I'm wrong on that.

all best,

jgart

glibc-2.33 fails to build on POWER9

[Tobias Platen]

I tried to build glibc-2.33 on my Talos II (no cross compile here),
it fails because the compiler is likely outdated.

checking if the target machine is at least POWER8... yes
checking if the compiler supports -mno-gnu-attribute... yes
checking if gcc compiles signbit with 128-bit floating point type...
yes
checking if gcc compiles with -mabi=ieeelongdouble and -mlong-double-
128... no
checking for objcopy... objcopy
checking version of objcopy... 2.37, ok
configure: error: ***  The compiler must support -mabi=ieeelongdouble
and -mlongdouble simultaneously.

guix --version shows
guix (GNU Guix) 7c9ad54b0616112c7eea6dd02379616aef206490
Copyright (C) 2022 the Guix authors

Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic

[Vagrant Cascadian]

On 2022-07-14, zimoun wrote:
> Well, dreaming about science fiction, it appears me more approachable to
> have Guix running on something as Debian/kfreeBSD – it could be an
> interesting project with the help of Debian folks.  Other said, “just”
> replace the Linux kernel by a variant of the FreeBSD one running with
> GNU GLibc.

Well, guile-3.0 does not build on Debian GNU/kFreeBSD, so that would be
a bit of a blocker for a GNU Guix port:

  https://buildd.debian.org/guile-3.0

But guile-2.2 built fine:

  https://buildd.debian.org/guile-2.2

It is a rough port, I have toyed with it now and again ... requires lots
of patches to code that assume userland based on running kernel; patches
that upstreams are hesitant to take, etc. It is great as a grueling test
of coding assumptions, though!

My guess is you would have the same sort of problems with porting GNU
Guix to any of the *BSD.

Definitely the sort of project that would take someone highly motivated
over many years...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: [WIP Patch] Adding an FHS container to guix shell

[Liliana Marie Prikler]

Hi John,

Am Dienstag, dem 12.07.2022 um 15:59 + schrieb John Kehayias:
> Hi Guixers,
> 
> Apologies for the long email, so let me start with the punchline:
> attached is a diff which adds an '--fhs-container' (or -F) option to
> guix shell/environment to set up an FHS-like container. This includes
> the usual /lib directory and a glibc which loads (a generated in the
> container) /etc/ld.so.cache. This should allow running most things
> that expect a more "typical" Linux environment. Give it a try!
> 
> First, I wanted to ask how people feel about such a feature.
> Obviously, one use is to run pre-built binaries (isolated!), but this
> is also handy for setting up development environments when not able
> (or wanting) to with Guix packages only. For example, using the
> rustup [0] scripts, pretty much anything JS, or just following
> typical Readme instructions to try out something new before
> packaging. I won't debate the details here other than to say this
> topic comes up with Guix and I think it is yet another useful tool
> for guix shell and containers.
> 
> Nix, which I know almost nothing about, does have some FHS
> container/environment options as well.
> 
> Next, some technical points about implementation, which I hope will
> be informed by the first question and what we want from this tool.
> There are two main things needed for the FHS-container:
> 
> 1. Set up directories like /lib. This is easy enough and can be done
> currently, like in roptat's response here [1] by building the profile
> first to know where to link to. Note that it is easier to do it
> within the environment code since we have access to the profile even
> if it is being built for the first time. There are some wrinkles with
> linking something like /bin since we currently add a link for sh; see
> the comments in my diff.
> 
> Right now I did not handle a multi-arch setup, though that shouldn't
> be too difficult. This would probably require an option to build
> either all or specified packages for an additional arch, like 32bit
> in a 64bit system, and make the libraries available (/lib32 or
> something). Though may run into a union-build bug [2]?
> 
> 2. Typically binaries will expect the ld loader to use
> /etc/ld.so.cache for finding libraries. So, I made a glibc package
> that removes our dl cache patch to restore this behavior. It seems
> enough to add this as a default package to the container, though I
> commented out an option to automatically graft everything with this
> glibc. Both worked for me, but grafting didn't seem necessary.
Would it make sense to keep our libc, but also symlink the cache to its
FHS place?  Or do we need to patch our libc so that this cache is tried
if a Guix-specific one isn't found?

> The second step is to generate the ld cache, which is done with a
> simple startup script in the container, after creating a temporary
> ld.so.conf (our ldconfig doesn't use the usual default directories?).
> I'm sure I found the hackiest way to do this, but it works :) Again,
> this could be possible without modifying guix containers, but this is
> easier. (For example, you can see work done by myself and others at a
> certain non-free channel to do exactly this.)
> 
> Some questions going forward, besides overall cleanup and tweaking of
> the code (which I provided comments in for some details, please see
> there). It might be nice to be able to extend containers more easily
> with setup scripts, though again this can be done by making some
> Guile scripts to wrap a container and making a package around that
> (e.g. from the non-free channel). What kind of extensions would be
> useful to expose? I think I saw some talk on IRC recently about how
> to manage env variables when using guix shell. Perhaps an extended
> manifest format for shell?
> 
> Relatedly and more generally, perhaps it would be good to have
> somewhere (cookbook?) some recipes of useful guix shell container
> incantations. Sharing what you need from the host for graphical
> programs can be a little tricky to figure out. We have the --network
> option, maybe others would be useful? Or some base package lists for
> development: just like we have our various -build-system's, a package
> list with typical library sets might be a nice convenience.
> 
> What about other uses for this container, like providing an isolated
> environment to build and run software we can't do fully with
> bootstrap and sources (like JS)? Could this become some stop-gap to
> allow people to work with these ecosystems in a more controlled way
> within Guix? Or an alternative build environment? Not entirely sure
> what this could mean, just thinking out loud.
I don't think we should rely on FHS containers in the build system. 
It's nice to have such a feature as a user, who really needs
$ELECTRON_APP and doesn't care about the fact that it's a packaging
nightmare, but on a system level, we ought to provide abstractions that
are meaningful and helpful to 

Re: Updating Packages

[Josselin Poiret]

Hello both,

Munyoki Kilyungi  writes:
> Have a look at:
> 
> that has an in-depth take on packaging.  Once you
> have a patch that you are ready to submit, follow
> this:
> .
> HTH'ed.

I'd just like to add that if at any point you'd like some help, there
are always people willing to provide some on IRC, or on the MLs.  No
stupid questions, just ask away!

Good luck,
-- 
Josselin Poiret

Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic

[zimoun]

Hi Tobias, All,

(French Bastille Day is a day off, so a day for trolling. ;-))


On Thu, 14 Jul 2022 at 10:40, Tobias Geerinckx-Rice  wrote:

> https://www.hyperbola.info/news/announcing-hyperbolabsd-roadmap/

Thanks for the link.  It is helpful for understanding. :-)


> Far from 'recent' in my book.

Indeed, the announcement is from 2019-12-21. :-)

Quoting:

This will not be a "distro", but a hard fork of the OpenBSD
kernel and userspace

Not being a new distro means using the venerable pkg_* package manager,
right?  Well, I am confused by the aim…


>> If you run OpenBSD kernel and OpenBSD userland, why not just run an
>> OpenBSD system? :-)
>
> Because it contains blobs.  HyperbolaBSD doesn't, by definition (see above).

…because HyperboladBSD seems a new distro as gnewSense is a new distro
free from problematic parts but based on an existing other one.  Well,
since it had been announced on late 2019 and we are in 2022, it could be
interesting to know the status on this project.


> Whatever my opinion on WSL, Darwin, and the Hurd, I must concede that they at 
> least exist.  
>
> Porting Guix to something that doesn't is a poor investment in comparison.

Just to be sure to understand, the initial question is to port Guix to
HyperbolaBSD which is a variant of OpenBSD (kernel and userland).

Therefore, correct me if I misunderstand something, it means:

 1. port Guix to a new kernel not using the GLibc
 2. package all the (free) userland OpenBSD managed by Guix

Bah I wish all the best for people who would tackle this. :-)

Well, dreaming about science fiction, it appears me more approachable to
have Guix running on something as Debian/kfreeBSD – it could be an
interesting project with the help of Debian folks.  Other said, “just”
replace the Linux kernel by a variant of the FreeBSD one running with
GNU GLibc.

However, doing so, the point #2 (BSD userland) is lost.

My understanding is: #1 and #2 require more work than the union of the
Guix community *and* the other kernel community could provide, IMHO.
Assuming both communities would be interested in. :-)


Cheers,
simon

Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic

[Tobias Geerinckx-Rice]

On 14 July 2022 10:23:49 UTC, zimoun  wrote:
> Well, I am missing where it is announced.  Could you be more specific?

https://www.hyperbola.info/news/announcing-hyperbolabsd-roadmap/

Far from 'recent' in my book.

Whatever my opinion on WSL, Darwin, and the Hurd, I must concede that they at 
least exist.  

Porting Guix to something that doesn't is a poor investment in comparison.

> If you run OpenBSD kernel and OpenBSD userland, why not just run an
OpenBSD system? :-)

Because it contains blobs.  HyperbolaBSD doesn't, by definition (see above).



Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

Re: Updating Packages

[Munyoki Kilyungi]

allan  anaandika:

> Hi there! I am new to software development, but I would like to contribute. I 
> want to start by updating some rust packages to newer versions.
>
> So far I have just been making scheme files in a seperate directory
> and running "guix build -f $SCHEME_FILE". I am trying to follow the
> [guidlines in the
> manual](https://guix.gnu.org/manual/en/html_node/Contributing.html),
> but git is still new to me and I am a little confused how to make this
> all work.
>
> What should I do to get package builds to recognize the updates I make to 
> dependencies?
>

Have a look at:

that has an in-depth take on packaging.  Once you
have a patch that you are ready to submit, follow
this:
.
HTH'ed.

-- 
(Life is like a pencil that will surely run out,
but will leave the beautiful writing of life.)
(D4F09EB110177E03C28E2FE1F5BBAE1E0392253F
(hkp://keys.gnupg.net))


signature.asc
Description: PGP signature

Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic

[zimoun]

Hi,

On Mon, 11 Jul 2022 at 18:44, Joshua Branson  wrote:

> The Hyperbola GNU/Linux team recently announced that they would ditch
> Linux for OpenBSD. They are using the OpenBSD kernel and the OpenBSD
> userland. And they are GPL-ing all of the code. It sounds like they will
> have to replace 20% of said code.
>
> https://www.hyperbola.info/

Well, I am missing where it is announced.  Could you be more specific?

If you run OpenBSD kernel and OpenBSD userland, why not just run an
OpenBSD system? :-)


Well, Debian is working (maybe the project is stalling?) on running GNU
userland using GLibc on the top of a FreeBSD kernel.  The conclusion is:
it is a piece of work. :-)

https://www.debian.org/ports/kfreebsd-gnu/

What I miss with your proposal is: are you interested by OpenBSD
userland software and you would like them running on a Linux kernel?  Or
are you interested by specific OpenBSD kernel feature and you would like
be able to run GNU software on it?

I think, similar as Josselin, that it requires a lot of work because
many low-level features are kernel dependant.  Therefore, it appears to
me more being worth to focus on smoothing the WSL2 experience, focus on
the Hurd, or to attempt something on the Darwin kernel.


Cheers,
simon

Re: [WIP Patch] Adding an FHS container to guix shell

[zimoun]

Hi

On Tue, 12 Jul 2022 at 15:59, John Kehayias  
wrote:

> Apologies for the long email, so let me start with the punchline:
> attached is a diff which adds an '--fhs-container' (or -F) option to
> guix shell/environment to set up an FHS-like container. This includes
> the usual /lib directory and a glibc which loads (a generated in the
> container) /etc/ld.so.cache. This should allow running most things
> that expect a more "typical" Linux environment. Give it a try! 

Cool!  Well, I am not sure if this could help with the long time ago
proposed “guix run” [1].


1: 


Cheers,
simon

Re: emacs-flymake-guix `guix lint -n`

[zimoun]

Hi,

On Wed, 13 Jul 2022 at 21:18, jgart  wrote:
> Hi Guixers is there currently an emacs package that provides a flymake 
> backend for `guix lint -n`?

What do you mean?

Well, the Emacs package emacs-guix allows to use “guix lint” from
Emacs.  Maybe improving this emacs-guix could be worth.  Or another
fresh one just for linting; I do not know. :-)


Cheers,
simon