Re: What’s next?

[Joshua Branson]

Some other cool thoughts:

Package the PHP bits of wordpress.  Then create a wordpress theme that
uses either no or bootstrapable (reproducible?) javascript.  Wordpress
writes some really minimal simple wordpress themes that have minimal
javascript that could be used as a start.  I think there might be a way
that one could then use Emacs to make a really simple blog.  And we
could have a really simple WordPress service.

Or just go crazy a create a competitor to wordpress in GNU guile or
racket.

Package the PHP bits of mediagoblin.  I think this is already done in
one of the WIP branches.  Then create a front-end of media goblin that
uses no or minimal amount bootstrapable (reproducible?) javascript.

One of the guix developers has a WIP git repo web viewer.  And it looks
amazing!  He's got some of his guile code on there. I think it would be
really awesome if savannah's guix git repos could point to that for the
guix repos.  Then we (who am I kidding you, I'm not a developer...yet)
could somehow combine bugs.guix.gnu.org with that guile git repo web
viewer.  The eventual goal could be to create a competitor to sourcehut!

--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

Re: Adding Trilinos to dealii package

[Paul Garlick]

Dear Paul,

> I would like to eventually package the Lethe CFD library

Nice!

Trilinos has many bells and whistles. I imagine that there will be some
significant effort required to package it.  One option would be to
subdivide the library and initially package only the elements you need
for Lethe.  See the Debian approach to packaging Trilinos for example
[1].

If Lethe does not use PETSc there would be no risk of conflict.  The
choice between including the new Trilinos (sub)package as a dependency
of dealii and dealii-openmpi or creating new dealii-trilinos and
dealii-trilinos-openmpi packages would be marginal.  How many models
need to use PETSc and Trilinos at the same time?

> This assumes people won't mind having to build Trilinos as a
> dependency for dealii even if they don't need it.

The model run times are usually very much longer than the library build
times.  I expect this would be true for Trilinos and Lethe too.

Best regards,

Paul.

[1]: https://packages.debian.org/source/buster/trilinos

Rust freedom issue claim

[Bone Baboon]

This is an article from Hyperbola about the Rust trademark. It claims
that Rust has a freedom issue.


I searched for this in the Guix bug and devel mailing list archive but
did not see it.

I would like to know how others interpret this claim of Rust having a
freedom issue.

# Linux-libre

If Rust does have a freedom issue then there is potential that it could
have an impact on Linux-libre.  Recently there was a RFC for adding
support for Rust to the Linux kernel
.  Linus Torvalds's response is
here .

# Responses on Freenode

I asked about Hyperbola's claim of a Rust freedom issue on
##r...@ire.freenode.net and these were some of the responses I
received.  However it appears that the core of Hyperbola's claim
remains unaddressed by these responses.

" the trademarks are now owned by the Rust Foundation
rather than Mozilla, but the Rust Media Guide has not been updated to
reflect this"

" bone-baboon: https://github.com/rust-lang/rust/issues/53287
is closed by https://github.com/rust-lang/rust/pull/59748";

" bone-baboon: whether you consider is a freedom issue or not
is a matter of viewpoint - debian doesn't seem to care at this point,
https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=cargo
shows no bugs open related to trademarks"

Re: Adding Trilinos to dealii package

[Leo Famulari]

On Sun, May 23, 2021 at 02:40:04PM +0200, zimoun wrote:
> Hi,
> 
> > 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?
> 
> AFAIK, there is no concrete standard way.  Only what explained Arun. ;-) 

And we should also consider the utility of the package. If it's not
useful without some large dependency, or typically used with that
dependency, then we don't need to make separate packages.

In general, it's a matter of judgment.

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Efraim Flashner]

On Tue, May 11, 2021 at 10:24:03PM +0200, Ludovic Courtès wrote:
> Hi!
> 
> Efraim Flashner  skribis:
> 
> > How about changing the mips64el documentation to say that there is
> > minimal support for the two architectures, with no substitutes, and may
> > be fun for tinkerers with the hardware. Then we could also change the
> > check in the guix.m4 to add mips64el-linux as supported in case anyone
> > does actually want to play with it.
> 
> No, not as “supported”, I surely don’t want to deal with mips64el-linux
> bugs.  :-)
> 
> > Current text:
> >
> > @item mips64el-linux (deprecated)¬
> > little-endian 64-bit MIPS processors, specifically the Loongson series,
> > n32 ABI, and Linux-Libre kernel.  This configuration is no longer fully
> > supported; in particular, there is no ongoing work to ensure that this
> > architecture still works.  Should someone decide they wish to revive this
> > architecture then the code is still available.
> >
> > Proposed text:
> >
> > @item Alternative architectures
> > In addition to architectures which are actually supported there are a
> > few formally unsupported architectures which may be of interested to
> > tinkerers. Namely mips64el-linux, little-endian 64-bit MIPS processors,
> > specifically the Loongson series, n32 ABI, and powerpc-linux, big-endian
> > 32-bit POWER processors, specifically the PowerPC 74xx series. There are
> > no installation tarballs, substitutes or promises that these
> > architectures are functional.
> >
> > And then I'd move it lower than the powerpc64le-linux entry.
> 

Ah, I didn't see your email.

> Maybe it’s more readable to keep it as a bullet list, like:
> 
>   @item mips64el-linux (@emph{unsupported})
>   …
> 
>   @item powerpc-linux (@emph{unsupported})
>   …
> 
> with a sentence explaining what “unsupported” means.

That was kind-of my idea with grouping them together

> IMO guix.m4 should either require --with-courage or emit a prominent
> warning for these.
> 
> WDYT?
> 
> Thanks,
> Ludo’.
> 

The problem then becomes whoever tinkers with it will have to keep
either a custom guix.m4 for their guix package or a custom guix package
with "--with-courage" as a configure-flag.


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