Re: Debbugs Usertags - which user to use?

[Chris Marusich]

Maxim Cournoyer  writes:

> Hello,
>
> Chris Marusich  writes:
>
> [...]
>
>> Yes, my understanding is that the user "guix" would also work.
>>
>> I think it would be fine to use the user "guix" instead of
>> "guix-devel@gnu.org".  Perhaps it would have the added benefit of
>> eliminating any possible risk of accidentally spamming the email list,
>> although so far that hasn't happened.
>>
>> To give others time to voice their opinion, I'll plan to update the
>> manual to suggest using the "guix" user about 2 weeks from now.  At that
>> time, I'll also re-tag the handful of issues currently tagged with the
>> powerpc64le-linux usertag associated with the guix-devel@gnu.org user.
>
> Sounds good to me!
>
> Thank you,
>
> Maxim

Done in 586136d12745eeddccd05d80dbd21959595b45d1.

-- 
Chris


signature.asc
Description: PGP signature

Re: Use of %texlive-revision and %texlive-tag in tex.scm

[Thiago Jung Bauermann]

Hello,

Em segunda-feira, 5 de julho de 2021, às 14:09:24 -03, Xinglu Chen 
escreveu:
> FYI, someone else is already workin on upgrading Texlive to 2021 on the
> ‘core-updates’ branch (Texlive is already at 2020 on core-updates).
> 
>   
> 
> Maybe you would be interested in helping out?

Indeed, that would be awesome. One way to help would be with more testing 
of the TeX Live 2021 patches. I’m not actually a TeX user, so the only 
testing I did was building the “texlive*” packages, the Guix manual and 
running the `tests/texlive.scm` test. It would be great to have someone who 
actually uses TeX involved in this process. :-)

Also of course feel free to propose or submit changes if you see anything 
in the patches which you think could be improved.

From the original email:

Em segunda-feira, 5 de julho de 2021, às 11:03:46 -03, Nathan Benedetto 
Proença escreveu:
> You see, they give me the impression that Guix is really concerned about
> upgrading *all* of texlive at once.
> These variables tell me I should go to the file texlive.scm and bump the
> tag and revision, and then handle all the broken hashes.

That’s what I did. :-)
 
> Hence, it seems to me that any attempt to upgrade the texlive package
> would have to be done in a separate branch, which would only be merged
> into master when all the packages are upgraded.

Yes, because updating texlive causes thousands of packages to be rebuilt. 
For example:

$ guix refresh --list-dependent texlive-bin | tr ' ' '\n'  | wc -l
2020

> Is this the case?

My impression from working on this TeX Live update is that this is indeed 
the case.

> And if so, why?

I don’t know why, but it makes sense to me.
As I mentioned before, I’m not a TeX user and I’m not familiar with its 
ecosystem, but my impression is that TeX Live is produced and also supposed 
to be consumed as a consistent whole. Mixing and matching packages from 
different revisions of the TeX Live Subversion repository would mean that 
you’re running a “Frankenstein”  which no one else is running¹, and so you 
have bigger chances of running into problems that don’t affect anyone else.

> In any case, as this may be a choice between shipping stable and
> up-to-date packages, and as I am new to contributing to Guix, I found
> fitting to ask.

That is the reasoning which makes the current arrangement make sense to me.
Note that there is a third choice: update all of TeX Live at once, but do 
so more frequently and take the packages straight from the trunk branch, 
rather than a tag. This is what upstream recommends, actually:

https://tug.org/pipermail/tex-live/2021-June/047187.html

-- 
Thanks,
Thiago

¹ This the story I’m referring to, of course: https://xkcd.com/1589/

Re: Effectively force all GNOME users to locally compile ZFS?

[Mark H Weaver]

Hi,

Giovanni Biscuolo  writes:

> Mark H Weaver  writes:
>
>> Tobias Geerinckx-Rice  writes:
>>
>>> Maxime Devos 写道：
 Perhaps the "zfs" package can be split in an userspace package
 (containing userspace binaries and libraries) and a kernelspace
 component (containing the kernel module)? And let the kernelspace
 component be unsubstitutable and the userspace component
 substitutable?
>>>
>>> That's a very good idea if possible.
>>
>> I agree that this would be a fine solution.
>
> AFAIK the licensing problem is just for the kernel modules binaries
> (re)distribution, (obviously) not for the userspace binaries, so AFAIU
> this would be a fine solution.

Sorry, I spoke too soon above.  It seems that there is a problem with
including CDDL-licensed ZFS code on the userspace side.  'virt-manager'
is distributed under GPLv2+ and links with 'libvirt'.

> Meanwhile, what do you think about a temporary revert of commit
> 61ccd756e5ff73b2f8dc3449df537f1c5adb5872 to avoid causing GNOME users
> ZFS compilation upon update (if I correctly understand the issue)?

Agreed, both for the reason you mentioned and also to avoid violating
the GPL when we distribute 'virt-manager'.

  Thanks,
Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

Create branch for Haskell build changes and updates?

[John Kehayias]

Hello,

There have been several recent bug reports and patches (list below) that could 
be addressed with some changes to haskell-build-system, the Hackage importer, 
and some package updates. Given the number of packages affected, it was 
discussed on #guix that it would be good to have a branch for these changes and 
to have Cuirass build the Haskell packages to look for breakage.

How do we feel about this? I'm happy to help with some patches I've submitted 
and update some packages, though it would also be good to have someone 
experienced with Haskell packaging and/or Guix too. (I'm new to both, but I've 
had success with my patches at least, locally.)

Here is a (partial) list of the most recent bugs and patches that would belong 
on this branch:

- https://issues.guix.gnu.org/48944 (build failure for new package, addressed 
by next patch)

- https://issues.guix.gnu.org/49199 (patch to add package-db to runhaskell to 
help with non-trivial configure stage; worked around in existing packages with 
a TODO marked to make this change actually)

- https://issues.guix.gnu.org/49418 (metadata revisions not imported, so e.g. 
dependency requirements out of date)

- https://issues.guix.gnu.org/49326 (bug with specifying ghc version for 
building)

- https://issues.guix.gnu.org/49320 (importer doesn't support some stages)

- https://issues.guix.gnu.org/48999 (local source for Haskell packages)

I'm not sure what we would want to include or not in such a branch, but I think 
it would make sense to put together the build-system and related changes at 
least. Some package updates (like a ghc version) would also affect a lot of 
packages, so might be good to do that together as well.

Thanks,
John

Re: Effectively force all GNOME users to locally compile ZFS?

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès  writes:

> I would rather have nothing depend on ZFS by default, but we could have
> “libvirt-with-zfs” etc.
>
> I agree that GNOME Boxes and libvirt should not depend on ZFS by default
> because (1) ZFS is an optional feature and probably not widely used, (2)
> ZFS combination with GPL code is problematic and as such we’d rather
> limit it to a minimum, and (3) having users systematically build a
> dependency locally should be avoided in general.
>
> WDYT?

I agree that having a separate 'libvirt-with-zfs' would be preferable.

I see now that there's a problem even on the userspace side:
'virt-manager' is a GPLv2+-licensed program based on 'libvirt'.  If I
understand correctly, it would be a GPL violation for us to distribute
'virt-manager' linked with CDDL-licensed component(s) of ZFS.

For now, I think that commit 61ccd756e5ff73b2f8dc3449df537f1c5adb5872
should be reverted until we can evaluate the situation more carefully.

What do you think?

Regards,
  Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

Re: Use of %texlive-revision and %texlive-tag in tex.scm

[Xinglu Chen]

FYI, someone else is already workin on upgrading Texlive to 2021 on the
‘core-updates’ branch (Texlive is already at 2020 on core-updates).

  

Maybe you would be interested in helping out? 

Exploiting hashes for Scheme refactoring

[Nathan Benedetto Proença]

Good morning!

As a new Guix developer, I want to learn about workflows which help me
catch bugs in Scheme development.

Is it a good idea to exploit Guix hashing infrastructure to ensure that
a Scheme refactoring did not change the packages produced?
Has some developer already done that?
Are there another tools and techniques I should be aware of?

As I said in the other email I sent to the mailing list, I am interested
in upgrading the texlive package in tex.scm.
Depending on what you teach me there, a solution could involve changing
more than 100+ places where the origin of packages is specified.

Without proper tooling, this can demand a whole lot of developer time
--- be it my time, or other contributors time.
Would this imply more than 100+ patches submitted and reviewed, and
perhaps in an alternative branch which core developers would have to
maintain?

Then I noticed I could use the hashes for the packages produced as a
test of whether my refactor was satisfactory or not.

For example, let's say I want to change the signature of a function.
I could simply change the function, and Emacs my way into changing the
call sites (Occur-mode, search-replace, or perhaps a some custom
elisp).
While developing, I could simply test if the hash of a single
package was the same as its previous hash.
When I got confident with my change, I could then log to a machine
stronger than my notebook and test if *every* package I touched has the
same hash as the previous one.
This log/procedure could even be sent together with a possible patch, so
to help reviewers trust my patch.

Is this a good use of hashes?
Are there similar techniques already in place?

Thanks in advance,
Nathan

Use of %texlive-revision and %texlive-tag in tex.scm

[Nathan Benedetto Proença]

Hello!

I am trying to upgrade the package texlive, first for me, but hopefully
for a patch, and I have a question regarding Guix policies.

As you can see on

   
https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build-system/texlive.scm?id=f7692617b624a01615cf412773c4dad9a2deeb68

the file guix/build-system/texlive.scm exposes two variables:

(define %texlive-tag "texlive-2019.3")
(define %texlive-revision 51265)

These variables are used throughout gnu/packages/tex.scm, as you can see
on

   
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/tex.scm?id=f7692617b624a01615cf412773c4dad9a2deeb68

An example is the following code:

  (define hyph-utf8-scripts
(origin
  (method svn-fetch)
  (uri (texlive-ref "generic" "hyph-utf8"))
  (file-name (string-append "hyph-utf8-scripts-"
(number->string %texlive-revision)
"-checkout"))
  (sha256
   (base32
"0lk7shx768sxvgr85y8bnmmnj8x4bbkgpxrz3z8jp8avi33prw83"

Grep tells me there are 290+ occurrences of `%texlive-revision`.
What is the purpose of these variables?

You see, they give me the impression that Guix is really concerned about
upgrading *all* of texlive at once.
These variables tell me I should go to the file texlive.scm and bump the
tag and revision, and then handle all the broken hashes.

Hence, it seems to me that any attempt to upgrade the texlive package
would have to be done in a separate branch, which would only be merged
into master when all the packages are upgraded.

Is this the case?
And if so, why?

I have the impression that if such "monolithic" upgrade is not a goal,
and "partial" our "per-package" upgrades are desirable, there may be
better solutions.

For example, we could add keyword arguments to texlive-ref and
texlive-origin, so the code above becomes something like this

  (define hyph-utf8-scripts
(origin
  (method svn-fetch)
  (uri (texlive-ref "generic" "hyph-utf8"
#:texlive-tag "texlive-2019.3"
#:texlive-revision 51265))
  (file-name "hyph-utf8-scripts-51625-checkout")
  (sha256
   (base32
"0lk7shx768sxvgr85y8bnmmnj8x4bbkgpxrz3z8jp8avi33prw83"

This would work right now, and we could eventually remove every use of
%texlive-revision and %texlive-tag, so they become implementation
details of the build-system texlive.scm; a fallback version.
And further down the road we may even decide to remove this fallback,
and make developers be explicit about their tags and revisions; this
could amount to a refactor which makes the keyword arguments into
required arguments, for example.

I also like the second version of the code because the hash already
pinpoints the tag and revision: both texlive-ref and texlive-origin use
these variables to find the correct files to download.
This just makes this dependency explicit.

In any case, as this may be a choice between shipping stable and
up-to-date packages, and as I am new to contributing to Guix, I found
fitting to ask.

Thanks in advance!
Nathan

Trying OpenCL on Guix: An Experience Report

[Katherine Cox-Buday]

I have written up a blog post here[1] which describes my experience with
trying to use OpenCL on Guix. While researching this, I found a few
messages in IRC and on guix-help wondering how to get this to work, so I
hope this helps someone.

As always, thanks to everyone involved in Guix.

[1] 
https://katherine.cox-buday.com/blog/2021/07/05/trying-opencl-on-guix-an-experience-report/

-- 
Katherine

Re: Effectively force all GNOME users to locally compile ZFS?

[Giovanni Biscuolo]

Mark H Weaver  writes:

> Tobias Geerinckx-Rice  writes:
>
>> Maxime Devos 写道：
>>> Perhaps the "zfs" package can be split in an userspace package
>>> (containing userspace binaries and libraries) and a kernelspace
>>> component (containing the kernel module)? And let the kernelspace
>>> component be unsubstitutable and the userspace component
>>> substitutable?
>>
>> That's a very good idea if possible.
>
> I agree that this would be a fine solution.

AFAIK the licensing problem is just for the kernel modules binaries
(re)distribution, (obviously) not for the userspace binaries, so AFAIU
this would be a fine solution.

Meanwhile, what do you think about a temporary revert of commit
61ccd756e5ff73b2f8dc3449df537f1c5adb5872 to avoid causing GNOME users
ZFS compilation upon update (if I correctly understand the issue)?

Best regards, Giovanni.

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: Effectively force all GNOME users to locally compile ZFS?

[Ludovic Courtès]

Hi,

Tobias Geerinckx-Rice  skribis:

> Mark H Weaver 写道：
>> The reason is that our 'gnome' package depends
>> on 'gnome-boxes'
>
> To me (a non-GNOME user), this is the problem.  GNOME Boxes is a
> wonderful front-end for creating and running virtual machines 
> using libvirt.  Why is it installed by default for every GNOME desktop
> user?

Yeah, default GNOME should probably not depend on GNOME Boxes.

> Conversely, it would be unfortunate to leave libvirt users with a less
> useful package because of that.
>
> How about moving libvirt_storage_backend_zfs.so to a separate output?
> Fortunately libvirt appears to be modularly well-designed, although I
> haven't tried myself.

That wouldn’t really help, would it?

I would rather have nothing depend on ZFS by default, but we could have
“libvirt-with-zfs” etc.

I agree that GNOME Boxes and libvirt should not depend on ZFS by default
because (1) ZFS is an optional feature and probably not widely used, (2)
ZFS combination with GPL code is problematic and as such we’d rather
limit it to a minimum, and (3) having users systematically build a
dependency locally should be avoided in general.

WDYT?

Ludo’.