Re: Adding Trilinos to dealii package

[Arun Isaac]

Hi Paul,

> PETSc and Trilinos (and many other libraries available in Guix) can be
> compiled with several different options.
> What is the standard way to deal with this in Guix?

Normal Guix policy is as follows. If adding extra dependencies does not
significantly increase the size of the package (as reported by `guix
size `), then we proceed with that. If it increases the size
significantly, then we may consider adding separate packages (such as
dealii-trilinos, etc.).

Hope that helps! :-)


signature.asc
Description: PGP signature

Re: What’s next?

[raingloom]

On Tue, 18 May 2021 10:05:05 -0400
Leo Famulari  wrote:

> On Mon, May 17, 2021 at 10:35:22PM -0400, Joshua Branson wrote:
> > I suppose someone should fix the Hurd vulnerabilities as reported
> > here:
> > 
> > https://lists.gnu.org/archive/html/bug-hurd/2021-05/msg00079.html
> > 
> > I don't think the vulnerabilities have been disclosed yet nor has
> > there been a fix yet.  
> 
> That message is the disclosure.
> 

Why not put our eggs in a few more baskets with way fewer holes and
more, uh, basket inspectors looking at them, like maybe packaging Minix,
or OpenBSD, or MirageOS, or whatever? I think I stretched that metaphor
but yknow what I mean.
They have seen way more scrutiny than Hurd and also run on more
architectures and while not GPL licensed, AFAIK they are all libre.

Maybe they can't be used in the operating-system-kernel struct field,
but I don't see anything wrong with using Guix to deploy Mirage
unikernel images for instance.
There is even a nascent Scheme unikernel project with Loko Scheme.

Ooor maybe compile some things to WASM and use a WASM+WASI runtime. I
hate webshit but at least there is already tooling and major porting
efforts for WASM.

Re: Freenode Administration

[raingloom]

On Thu, 20 May 2021 01:40:08 -0400
Bone Baboon  wrote:

> Bone Baboon writes:
> > # IRC alternatives / compliments
> >
> > Some criteria that I have come up with are:
> > * Free software
> > * Can be used without a graphical user interface as many GPUs are
> > not compatible with Linux-libre and can not run Xorg or Wayland
> > window managers / desktops.
> > * Peer to peer as a way to avoid the issue of a centralized
> >   administrator changing their administration in undesirable ways.
> >  
> 
> One more criteria.  Is an Emacs client available.  Inspired by
> .
> 
> > Some alternatives that come to mind that would need further
> > investigation include the following.  I do not know if any of these
> > meet all the criteria I mention above.
> >
> > * Scuttlebutt
> > ** https://scuttlebutt.nz/
> > ** Is there a client that works without a graphical environment?
> >
> > * DAT
> > ** Are there messaging application for DAT?
> > ** https://www.datprotocol.com/
> >
> > * IPFS
> > ** Are there messaging application for IPFS?
> > ** https://ipfs.io/
> >
> > * Jami
> > ** https://jami.net/
> > ** Swarms specifically
> > ***
> > https://jami.net/swarm-introducing-a-new-generation-of-group-conversations/
> > *** Swarms are fully distributed and peer-to-peer text
> > conversations, with a potentially unlimited number of participants.
> > **  on Freenode #jami said:
> > "https://github.com/AmarOk1412/jami-cli/ no video/audio support but
> > support swarm"
> >
> > * RetroShare
> > ** http://retroshare.cc/
> > ** Is there a client that works without a graphical environment?  
> 
> Here is what I have discovered after some further preliminary
> exploration.  I have added XMPP and Tox.
> 
> ## Scuttlebutt
> 
> 
> 
> * Free libre - yes
> * Peer to peer - yes
> * Non graphical client - yes
> ** scat 
> ** scatzero 
> ** scuttle-chat 
> * IRC capabilities - ?
> * Emacs client - no
> 
> ## DAT
> 
> 
> 
> * Free libre - yes
> * Peer to peer - yes
> * Non graphical client - yes
> ** cabal-cli 
> * IRC capabilities - yes
> ** 
> * Emacs client - no

I don't think we can package NPM stuff.

Both the Dat and SSB cores have non-JavaScript implementations AFAIK,
but Cabal itself is JavaScript-only and so are all the SSB clients that
I've seen, but admittedly I haven't looked at the state of the SSB
ecosystem in a few months, so maybe that has changed.
The various sbot implementations do not count as proper clients.

Re: website: A little help running the website locally

[Luis Felipe]

On Saturday, May 22, 2021 3:46 PM, Julien Lepiller  wrote:

> Le Fri, 21 May 2021 19:28:38 +,
> Luis Felipe luis.felipe...@protonmail.com a écrit :
>
> > On Friday, May 21, 2021 7:24 PM, Julien Lepiller jul...@lepiller.eu
> > wrote:
> >
> > > Ah no, I think we found the issue! So we should update the readme
> > > to not require passing GUIX_LOCPATH and set LANG to en_US.UTF-8 (or
> > > any other language listed in po/LINGUAS).
> >
> > Will you update the README, or should I sent a patch?
>
> I updated the README, so it should now give you correct directions.
> Thanks for reporting the issue and for your time while we tried
> debugging this :)

こちらこそ、どうもありがとう、みんな！

Re: blog post about shepher user services

[Adriano Peluso]

Il giorno sab, 22/05/2021 alle 15.49 +0200, Leo Prikler ha scritto:
> Hi,
> 
> the blog post you've linked
>   
> https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/
> seems to neither contain mentions of XDG_CONFIG_DIR, nor mcron.
> 
> Did you mean 
>   https://guix.gnu.org/en/blog/2020/gnu-shepherd-user-services/
> instead?

yes, I pasted the wrong one, sorry


> 
> FWIW, $XDG_CONFIG_DIR should be $XDG_CONFIG_HOME, I myself always mix
> those up as well.  

Good to know

> As far as mcron integration is concerned, it doesn't
> look as though this has been done yet and I think work remains to be
> done to have mcron running "as a part of shepherd" rather than as its
> own daemon.  You can right now already run regular cron-jobs through
> mcron just how people did before systemd was a thing.  You just need
> to
> make sure you launch mcron as a user service if you want to go with
> this particular configuration style, otherwise mcron as a system
> service ought to suffice as well.
> 
> Regards,
> Leo
> 

Ok, thanks

Re: website: A little help running the website locally

[Julien Lepiller]

Le Fri, 21 May 2021 19:28:38 +,
Luis Felipe  a écrit :

> On Friday, May 21, 2021 7:24 PM, Julien Lepiller 
> wrote:
> 
> > Ah no, I think we found the issue! So we should update the readme
> > to not require passing GUIX_LOCPATH and set LANG to en_US.UTF-8 (or
> > any other language listed in po/LINGUAS).  
> 
> Will you update the README, or should I sent a patch?

I updated the README, so it should now give you correct directions.
Thanks for reporting the issue and for your time while we tried
debugging this :)

blog post about shepher user services

[Leo Prikler]

Hi,

the blog post you've linked
  
https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/
seems to neither contain mentions of XDG_CONFIG_DIR, nor mcron.

Did you mean 
  https://guix.gnu.org/en/blog/2020/gnu-shepherd-user-services/
instead?

FWIW, $XDG_CONFIG_DIR should be $XDG_CONFIG_HOME, I myself always mix
those up as well.  As far as mcron integration is concerned, it doesn't
look as though this has been done yet and I think work remains to be
done to have mcron running "as a part of shepherd" rather than as its
own daemon.  You can right now already run regular cron-jobs through
mcron just how people did before systemd was a thing.  You just need to
make sure you launch mcron as a user service if you want to go with
this particular configuration style, otherwise mcron as a system
service ought to suffice as well.

Regards,
Leo

blog post about shepher user services

[Adriano Peluso]

There's this blog post:

https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/

I have 2 observations about it

1) it mentions a XDG_CONFIG_DIR environment variable. 
 But on my Ubuntu desktop, I find a XDG_CONFIG_DIRS (note the final S)
variable. 
This could be confusing to someone not knowing well their way around.
Was this a simple slip ? Or is there any more specific reason for this
missing S ?

2) in the end it announces a second post about integrationg Shepherd
with mcron to come up with something that could substitute systemd's
timer funtionality.
It would be interesting to read the second blog post

Adding Trilinos to dealii package

[Paul A. Patience]

Hi,

I would like to eventually package the Lethe CFD library [1], but it
requires a version of dealii compiled with Trilinos, which is not
currently available in Guix.

PETSc and Trilinos (and many other libraries available in Guix) can be
compiled with several different options.
What is the standard way to deal with this in Guix?
>From what I can tell, in general the packages get a reasonable default
and people who require different options make a channel and inherit from
the base package, and in some really practical cases we get a variant of
the package with a similar name, e.g., dealii-openmpi.

The potential problem with PETSc and Trilinos when it comes to dealii is
that some of the optional modules they can be compiled with are the
same, which causes trouble when dealii is configured with both of
them [2].
(From what I can tell, the module in question is not configured in the
Guix package for PETSc, so this point may be moot.)

I'm wondering what the best way would be to add Trilinos to the dealii
packages (assuming I manage to package Trilinos as well).
In other words, which would be best among the following:

- Build Trilinos with a reasonable configuration for dealii [3] and
  update the dealii and dealii-openmpi packages to include it (if the
  problem mentioned above turns out not to be an issue).
  This assumes people won't mind having to build Trilinos as a
  dependency for dealii even if they don't need it.

- Build Trilinos as above but add separate packages for the resulting
  dealii, e.g., dealii-trilinos, dealii-trilinos-openmpi.
  This seems like it would get awkward quite quickly, which is why
  assuming my thoughts on the purposes of channels are correct, this is
  the inferior option.

- Abandon all hope and just maintain a channel for dealii configured
  with Trilinos (the inferiorer option :)).

- Some other possibility I have not thought of.

Thank you and best regards,
Paul

[1]: https://github.com/lethe-cfd/lethe
[2]: https://www.dealii.org/current/external-libs/petsc.html
[3]: https://www.dealii.org/current/external-libs/trilinos.html

Re: Freenode Administration

[Bone Baboon]

François writes:
>> # IRC alternatives / compliments
>
> On alternatives you missed Matrix[1] which is federated (like email)
> and have several clients includig weechat for text-based interface.
>
> Several people (and I am one of them) already uses Matrix clients to
> access IRC networks with bridges (which libera.chat does not already
> have but work is in progress).
>
> There is even some ongoing work ([2], [3]) on making Matrix more
> peer-to-peer but it is still completely experimental.
>
>
> [1]: https://matrix.org
> [2]: 
> https://matrix.org/blog/2021/05/06/introducing-the-pinecone-overlay-network
> [3]: https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix

## Matrix



* Free libre - yes
* Peer to peer - no yet, currently federated servers
** 
** 
* Non graphical client - yes
** 
** 
** 
** 
* IRC capabilities - yes
* Emacs client - yes
** 

Re: Scala package

[Shyam Saran]

It is helpful for our beloved OS -thanks
it will be helpful for app development.
At present, I do not know any of groovy, scala (will learn.)


On Fri, 21 May 2021 at 01:05, Julien Lepiller  wrote:

> I'll think about that. Note that we already have Groovy, as it's properly
> bootstrapped :)
>
> Le 20 mai 2021 15:09:08 GMT-04:00, Shyam Saran 
> a écrit :
>>
>>
>> Many people want to move all their development work on guix
>>
>> example android sdk app development, yes scala, gradle, kotlin, groovy
>> etc (even blockstack, ethereum) required to be packaged
>> As many of you, and Julien trying this.
>>
>> So more than contributing code, please provide a blog post from which,
>> who all want to help
>> can also get guidance.
>>
>>
>> Thanks
>>
>> syam
>>
>>
>>
>>
>>
>> On Wed, 19 May 2021 at 21:06, Katherine Cox-Buday <
>> cox.katherin...@gmail.com> wrote:
>>
>>> Ludovic Courtès  writes:
>>>
>>> >> I think the best way to bootstrap would be to reimplement Scala in
>>> > another language. I tried that too, but even the parser is crazy.
>>>
>>> Yes, the syntax is complex. Maybe even worse than C++ in terms of
>>> parsing. I abandoned scala awhile ago, but I saw that with its latest
>>> release, maybe some things got simplified. Maybe it's worth another
>>> look?
>>>
>>> > Could you share a link to that so everyone realizes just how far you
>>> > went?  :-)
>>>
>>> Before I outright abandoned the language, I was looking into
>>> bootstrapping this too. I did not go nearly as far, but was strongly
>>> dissuaded by core scala contributers from even trying (to be fair, they
>>> probably don't hold bootstrapping in high regard as we do).
>>>
>>> The only thought I have to contribute is: would it be possible to
>>> bootstrap off of a binary seed, and then do what's possible to grow that
>>> down to prior versions as much as possible? It's a compromise, but it at
>>> least gets Guix into the scala ecosystem and provides scaffolding to
>>> work off of. Of course this might run contrary to Guix's goals/needs.
>>>
>>> --
>>> Katherine
>>>
>>>