Re: plasma desktop in guix

[jbranso]

July 26, 2023 2:23 PM, "Tobias Platen"  wrote:

> That looks good. Soon I'll try to get XRDesktop working on the Guix
> System, either with Gnome or with KDE. Still a long way to get it
> working on my Talos II. (I will have to upgrade my GPU to one from
> RED Semiconductor as the current one needs non-free firmware.)
 
Just out of curiosity, how decent is the libre RED Semiconductor GPU?

Is it mostly RYF?

Joshua

Re: Kdump

[Csepp]

Christina O'Donnell  writes:

> Hi guix and guixesses,
>
> I'm still enjoying my guix machine crashing every other week despite changing 
> all the software and half the hardware. So I'm trying to get kdump
> working so I can get to the real reason behind it. However I see that 
> kdump-tools haven't been packaged yet. I see this as an opportunity for me to
> contribute to Guix, but it'll be my first time.
>
> - How interested would people be in me packaging kdump and related tools?

More debugging tools (and docs!) are always welcome IMHO.

> - Is there a reason why it's not there already?
>
> - Has it been tried before?

Searching the mailing lists doesn't turn up much, so I assume no one has
tried it:
https://yhetil.org/guix/?q=kdump

> The scope seems to be around 3-4 packages and a system service. Does that 
> sound about right or could there be more I'm missing?
>
> On Debian there's:
>
> crash/testing,now 8.0.2-1 amd64 [installed,automatic]
>   kernel debugging utility, allowing gdb like syntax
>
> kdump-tools/testing,now 1:1.8.1 amd64 [installed]
>   scripts and tools for automating kdump (Linux crash dumps)
>
> libkdumpfile-dev/testing 0.5.1-1 amd64
>   libkdumpfile development libraries and header files
>
> libkdumpfile-doc/testing,testing 0.5.1-1 all
>   Kernel coredump file access (documentation)
>
> libkdumpfile10/testing 0.5.1-1 amd64
>   Kernel coredump file access
>
> python3-libkdumpfile/testing 0.5.1-1 amd64
>   Python bindings for libkdumpfile
>
> I'd want to package all of these except the python bindings. I see that 
> kexec-tools is already in guix which is good!
>
> Is this a sensible direction?
>
> Kind regards,
>  - Christina

I'd say go for it!  If they are mostly written in C then you probably
don't have to package a lot of transitive dependencies.  Looking in
gnu/packages/linux.scm could be a good starting point for packaging
kernel related tools.

Re: poetry not building

[John Kehayias]

Hi all,

On Fri, Jun 23, 2023 at 08:49 AM, Lars-Dominik Braun wrote:

> Hi Reza,
>
>> Poetry is not building on ci.guix.gnu.org [1]. There is a pending patch
>> [2] on the issue tracker. What is missing to apply this patch and how
>> can I help?
>
> both contributors to that issue – John and me – are busy with other
> things right now. That’s all.
>
> My proposal in the python-team branch is rather intrusive and requires
> a world rebuild. I wrote down what needs to be done here:
> 
> Some of that work has been merged into the python-team branch already,
> but I think the 3rd point is missing entirely and the 2nd one is not
> properly tested yet.
>
> Cheers,
> Lars

Yes, it is a rather intrusive change of our python world, requiring
rebuilding of everything that uses python. As noted above, you can use
something like time-machine for older guix with working poetry or use
a local copy with those patches for a newer one. Either will likely
require some local rebuilding.

Anyway, yes, I was distracted with other matters but have just
finished merging mesa-updates which took a bit longer than expected.
I'm not expert on these more internal python and python packaging
matters, so help is welcome. I will work on reviving this next though.

John

Re: Adding Django 4.2 LTS

[Development of GNU Guix and the GNU System distribution.]

On 2023-07-30 22:13, Maxim Cournoyer wrote:

> Hi,
>
> Luis Felipe  writes:
>
>> Hi,
>>
>> I've been using Django 4.2.2 from my personal Guix channel for a
>> couple of days and it seems to work alright, so I'd like to send a
>> patch to include it in Guix, although I have some questions first.

Hi!

I've already submitted a patch series updating django to 4.2.2. It's in
55476, but I don't have feedback from the python team. 

>>
>> 1. python-asgiref >= 3.6.0 and < 4 is a requirement for Django 4.2 LTS
>> series, there is a patch for it already
>> (https://issues.guix.gnu.org/61543), it builds, doesn't appear to have
>> known vulnerabilities and Django 4.2.2 works with it. Would it be okay
>> to add it to Guix until someone else packages the latest version
>> (3.7.2, but it currently fails to build for me: sanity-check
>> DistributionNotFound or something)?
>
> This usually means one of the inputs of the package doesn't have a
> compatible version.  Please check which one it is (the Python error
> message should contain that information).
>
>> 2. "guix lint python-django@4.2.2" says this version of DJango might
>> be vulnerable to CVE-2023-31047 but reading the CVE description
>> version 4.2.2 doesn't seem to be affected. Is there anything I should
>> do regarding this warning?
>
> If you are absolutely sure about that you could add a 'lint-hidden-cve'
> property to the package definition.
>
>> 3. Guix currently distributes versions of Django that no longer
>> receive security updates or bug fixes. For example,
>> python-django@4.0.7, python-django@3.1.14, python-django@2.2.28 (see
>> https://www.djangoproject.com/download/). Should they be removed?
>
> They should be upgraded to the latest available version (the old
> versions shouldn't be kept around).

-- 
Best regards,
Nicolas Graves

Re: Adding Django 4.2 LTS

[Development of GNU Guix and the GNU System distribution.]

On 2023-07-30 22:13, Maxim Cournoyer wrote:

> Hi,
>
> Luis Felipe  writes:
>
>> Hi,
>>
>> I've been using Django 4.2.2 from my personal Guix channel for a
>> couple of days and it seems to work alright, so I'd like to send a
>> patch to include it in Guix, although I have some questions first.

Hi!

I've already submitted a patch series updating django to 4.2.2. It's in
55476, but I don't have feedback from the python team. 

>>
>> 1. python-asgiref >= 3.6.0 and < 4 is a requirement for Django 4.2 LTS
>> series, there is a patch for it already
>> (https://issues.guix.gnu.org/61543), it builds, doesn't appear to have
>> known vulnerabilities and Django 4.2.2 works with it. Would it be okay
>> to add it to Guix until someone else packages the latest version
>> (3.7.2, but it currently fails to build for me: sanity-check
>> DistributionNotFound or something)?
>
> This usually means one of the inputs of the package doesn't have a
> compatible version.  Please check which one it is (the Python error
> message should contain that information).
>
>> 2. "guix lint python-django@4.2.2" says this version of DJango might
>> be vulnerable to CVE-2023-31047 but reading the CVE description
>> version 4.2.2 doesn't seem to be affected. Is there anything I should
>> do regarding this warning?
>
> If you are absolutely sure about that you could add a 'lint-hidden-cve'
> property to the package definition.
>
>> 3. Guix currently distributes versions of Django that no longer
>> receive security updates or bug fixes. For example,
>> python-django@4.0.7, python-django@3.1.14, python-django@2.2.28 (see
>> https://www.djangoproject.com/download/). Should they be removed?
>
> They should be upgraded to the latest available version (the old
> versions shouldn't be kept around).

-- 
Best regards,
Nicolas Graves

Binary descriptors for OpenCV

[Ricardo Wurmus]

Hi Guix,

I’d like to draw your attention to https://issues.guix.gnu.org/64945.
It’s a patch that adds binary descriptors to OpenCV.

These descriptors are the result of a very expensive computation, which
could be performed with lots of memory and GPUs.  The result is a small
number of very small descriptors in binary format, which OpenCV can use
as an input to a feature detection algorithm.

This is probably one of the simplest cases of machine learning output;
the output is small and compared to other machine learning models
require only a small amount of computation.  But it’s above the
threshold for our build farm and not something we can have users
recompute on install.

The software used to generate these descriptors is freely licensed, and
the descriptors are living in the twilight zone of assets that are not
quite software but clearly not just decorative either.  They are large
arguments to image feature detection algorithms, much like an image mask
would be.

What shall we do with this patch?  Can we accept it or does it cross a
line we don’t want to cross?

-- 
Ricardo

IPv6 access for ci.guix.gnu.org

[Guillaume Le Vaillant]

Hi.
The substitute server at ci.guix.gnu.org is not reachable via IPv6.
I found messages from 4 years ago indicating that the network where the
CI machine is was not ready for IPv6 (see [1]).
Is it still the case today?

[1] https://lists.gnu.org/archive/html/guix-devel/2019-08/msg00096.html


signature.asc
Description: PGP signature

Re: Guix and the developer ecosystem

[(]

Hi,

Distopico  writes:
> In terms of programming languages, I have found almost all the ones I
> needed, with the exception of Kotlin.

The build sequence for Kotlin is some sort of hellish double
nightmare-loop of doom.  As far as I'm aware, this is how
the main dependencies of Kotlin relate to each other:

 .-.
 | |
   .-> gradle --.  V
   | ^  |kotlin --.
openjdk  '--'^^   |
   | |'---'
   '-'

Fun!

> In some languages like Haskell and GoLang, the language server depends a
> lot on the version it was compiled with. For example, I tried gopls,
> which is available in Guix, but it was built with Go 17 and is not
> compatible it.

Ah, that'll be because Guix uses Go 17 for building Go programs, unless
you override the ``#:go'' keyword, but the latest version of Go it
provides is Go 20.  I suppose it couldn't hurt to change it to be built
with the latest version.  (We can't just make the default build Go be
20, as that would require the CI to rebuild all Go packages.)

> All this text is provided some context for two simple questions:
>
> 1. Are there plans in the future to improve integration between
> development tools? For example, having haskell-language-server for
> ghc@9.x and another one for ghc@8.x, or something similar to the
> overwrite feature in Nix flake?
>
> is it mainly focused on HPC (High-Performance Computing)?

Definitely not :)

> I have started contributing to packages that I believe could be useful,
> and I like to contributing to teams such as Haskell or Rust. However,
> there are other topics, such as compiler and tools compatibility, where
> I'm not entirely clear about the direction that has been planned.

The problem with Haskell, Rust, and Elm is mainly, as lilyp has
said/implied, that while the dependency trees of C applications and such
typically resemble the following:

O <-- O
  O <-- O <-- O
O <-- O

dependency trees for Rust, Haskell, and Elm look like this:

/ O
  / O <-- O
  | \ O
  |
  | / O
/ O <-- O <-- O
| | \ O
| |
| | / O
| \ O <-- O
|   \ O
|
|   / O
| / O <-- O
| | \ O
| |
| | / O
  O <-- O <-- O <-- O <-- O
| | \ O
| |
| | / O
| \ O <-- O
|   \ O
|
|   / O
| / O <-- O
| | \ O
| |
| | / O
\ O <-- O <-- O
  | \ O
  |
  | / O
  \ O <-- O
\ O

Except in reality it's much much much much much worse.

So it's not because that's not something we'd like to have, it's largely
because packaging such things is a royal pain and there aren't all that
many people with the motivation to do that.

> And apologies for the lengthy text.

It's okay, questions are good :)

  -- (