Mesa out of date (and move to libglvnd?)
Hi everyone, Mesa has fallen quite of date (latest upstream is 21.1.4, guix core-updates up to 20.2.6, or else 20.2.4 for everyone else). There is patch available here: https://issues.guix.gnu.org/49339 however it currently includes enabling libglvnd. I don't think that is necessary from my testing, but does raise the question of moving to libglvnd for packages requiring GL (which would be needed if Mesa has it enabled). As far as I understand it, libglvnd is meant to be vendor neutral and provide GL for anything to link to, and then hands off to vendor specific GL. I have at tested building some packages when mesa has libglvnd enabled, like libepoxy and xorg-server. Both needed libglvnd as inputs, but otherwise build fine. I haven't tested running as I'm currently on a foreign distro. However, does seem like this would be a good idea, as it should alleviate dealing with vendor specific GL in building packages. libglvnd is new to me, but perhaps someone can weigh in on this issue? Anyway, my main goal right now is to have Mesa updated in core-updates before the upcoming freeze. Mesa is already very out of date, and would then push it to another ~6 months for the next core-updates when it is already ~7 months out of date (and they make quick releases for fixes in drivers and software that uses Mesa). I can update #49339 with a minimal Mesa version bump patch if that helps, just don't want it to get lost in the current shuffle. Thanks! John
Re: New Operating System and Kernel development
On Wed, Jul 7, 2021 at 5:33 AM Amar M. Singh wrote: > > appreciate feedback, in the end I hope to make something that is > usable and used rather than purely for amusement purposes :) If you're interested in playing with some code/idea, even just for your own amusement, don't let others' opinion stop you from doing that. Success of any new work or idea are very slim, so if you try to optimize for that, you might not get anything done at all. Just my 2. bits. Best regards, -- Gurjeet Singh http://gurjeet.singh.im/
Re: New Operating System and Kernel development
Hi amar, this is unrelated to GNU or Guix, but if you want to avoid C/C++ it may be worth taking a look at https://www.redox-os.org, which is written in Rust — of course there's also the GNU Hurd (and I'm sure many other projects), but this is the only one I'm aware of that has "avoid using C/C++" as one of its stated goals (apart from some more specific things like MirageOS, which uses OCaml a lot). ~stuebinm On 07.07.21 17:01, guix-devel-requ...@gnu.org wrote: Message: 5 Date: Wed, 07 Jul 2021 11:51:45 + From: "Amar M. Singh" To: guix-devel@gnu.org Subject: New Operating System and Kernel development Message-ID: Content-Type: text/plain; charset="utf-8" Hello all, Is there any research into new Operating Systems and kernel development? I'd like to announce 'heh' that I'm starting on just such a project :) I have a few ideas about what i want to build but that's getting far ahead of myself, I think I should build it to run on Qemu or Xen hypervisor. The most dreaded thing i want to avoid is C or C++. The source code shall go on to https://codeberg.org/nly. And always appreciate feedback, in the end I hope to make something that is usable and used rather than purely for amusement purposes :) Thank you for reading so far, ~amar
Re: New Operating System and Kernel development
Hi Amar, Did you study Hurd and other micro-kernel approaches? Some people working on that here (though not me). Pj. On Wed, Jul 07, 2021 at 11:51:45AM +, Amar M. Singh wrote: > Hello all, > > Is there any research into new Operating Systems and kernel > development? I'd like to announce 'heh' that I'm starting on just > such a project :) > > I have a few ideas about what i want to build but that's getting far > ahead of myself, I think I should build it to run on Qemu or Xen > hypervisor. The most dreaded thing i want to avoid is C or C++. The > source code shall go on to https://codeberg.org/nly. And always > appreciate feedback, in the end I hope to make something that is > usable and used rather than purely for amusement purposes :) > > Thank you for reading so far, > ~amar >
Re: Create branch for Haskell build changes and updates?
Hey Guix, I’m very happy to see some movement on haskell support. We try to track the stack package set for a given ghc version. Updating to ghc 8.10.4, then, means updating to stackage lts 18.1. One other issue that should be addressed is that cabal-install will need to be updated to 3.x. I have tried but I don’t know how to build it. I also nominate updating the ghc-profile-hook. It needs some work to be fully functional. Perhaps a search-path would be the way to go there? Kindly, John Soo
Re: Questions regarding Python packaging
Am 29.06.21 um 09:20 schrieb Lars-Dominik Braun: AFAIK this might not be true if other build systems not using setuptools at all might show up. And isn't this the main reason for all your work? No, try Sorry, I've been inprecise on this: There might still be quite some packages out there importing plain, old distutils (and not setuptools) in their setup.py. These are what I meant with "other build systems not using setuptools". For these setup.py to understand the options we (and pip) need for installation, "import distutils" has to be hacked to actually become "import setuptools" - which is what setuptools-shim does -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Create branch for Haskell build changes and updates?
‐‐‐ Original Message ‐‐‐ On Wednesday, July 7th, 2021 at 1:47 AM, Xinglu Chen wrote: > On Mon, Jul 05 2021, John Kehayias wrote: > > > 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. > > Thank you for bringing this up! I posted a WIP patch for adding GHC > > 8.10 a while ago, but nobody showed any interest[1]. > > I don’t have any experience with updating the Haskell toolchain in Guix, > > but I think it would be great to have a separate branch for updating the > > haskell-build-system and Haskell packages. :) > > [1]: https://yhetil.org/guix-devel/87o8cgfbg1@yoctocell.xyz/ I'm no expert in Haskell packages (every time I dive in anywhere it always seems a bit of a mess), but I'm happy to help out. Given the number of interdependent packages, probably makes sense to do this anytime needing to update a core package, GHC, etc. Does any maintainer or someone with repository access want to set this up? Perhaps someone that has already handled Haskell updates? We have several patches we can push right away and see how the updates go in the CI. Given the scope, I think it is difficult to do without a CI, though I've recompiled many a package with the patches I've submitted. I can help take charge (or do whatever) once a branch is set up, just let me know.
Re: Effectively force all GNOME users to locally compile ZFS?
Mark H Weaver 写道： 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 suggested splitting *libvirt*, not ZFS. How would splitting ZFS into two identically-licenced halves help? Kind regards, T G-R signature.asc Description: PGP signature
New Operating System and Kernel development
Hello all, Is there any research into new Operating Systems and kernel development? I'd like to announce 'heh' that I'm starting on just such a project :) I have a few ideas about what i want to build but that's getting far ahead of myself, I think I should build it to run on Qemu or Xen hypervisor. The most dreaded thing i want to avoid is C or C++. The source code shall go on to https://codeberg.org/nly. And always appreciate feedback, in the end I hope to make something that is usable and used rather than purely for amusement purposes :) Thank you for reading so far, ~amar
Re: Removing package input labels: last call!
Hi! I hope I'm not too late! I've given the patch a try and have a couple of questions: - Since not all the inputs *have* to be converted to the new format: is this more some kind of syntactic sugar and less of a "we really want this to be the new standard" kind of improvement? Or is the goal to replace *all* input lists with the new style? - Regarding the speed of the transition: do I understand correctly that the script should be able to convert the vast majority of packages and that afterwards maybe other definitions will/might/could be translated by hand? - Follow up: is your intention to adjust the script to work with more and more package definitions or are you leaning into a more "let's have a sound script which is useful for many cases but leaves a biggish bunch of manual labor but at least it won't break a thing" kind of solution? - Is there a way to check the integrity of a package definition *without* building the whole thing? I had some ideas (see below) for adding special cases to your `guix style` script but was unable to test whether they actually work (because compiling tonnes of codes unsurprisingly takes quite some time). What I found: - Small things like libX11 vs libx11. If I understood correctly the new patch series takes care of this case. - I think there's a whole class of cases where version-names and other package-definition specifics make the "does-the-package-name- match-the-label-exactly" algo fail: - ,python-wrapper vs. "python" - ,python-minimal-wrapper vs. "python" - ,python2 vs. "python" - ,python-cython vs. "cython" - ,iproute2 vs. "iproute" - etc I've written some code and tested it with some specific package definitions but since I was unable to test whether these substitutions actually work for *all* package definitions I'll just leave these remarks here :) I hope this is somewhat help- or useful. Gabriel
Re: Effectively force all GNOME users to locally compile ZFS?
Hi Mark, Something about this virt-manager reasoning strikes me as bogus, but it's complicated by how Guix works in practice… I think any perceived (pseudo-)(cosplay-)(that includes me)‘legal’ issues are a distraction. Mark H Weaver 写道： For now, I think that commit 61ccd756e5ff73b2f8dc3449df537f1c5adb5872 should be reverted until we can evaluate the situation more carefully. I reverted it already. Anything else is a waste of all our valuable time. Thanks, T G-R signature.asc Description: PGP signature
Re: Effectively force all GNOME users to locally compile ZFS?
Ludovic Courtès 写道： 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? No. I meant package. I would rather have nothing depend on ZFS by default, but we could have “libvirt-with-zfs” etc. Who knows, but I'd rather just revert the commit and be done with it. ‘Nothing depend on ZFS by default’ is clear and unambiguous. Thanks! 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, Yeah, this is still a bug, but it's up to the GNOME users to deal with :-) Kind regards, T G-R signature.asc Description: PGP signature
Re: Use of %texlive-revision and %texlive-tag in tex.scm
On +2021-07-06 15:28:43 -0300, Nathan Benedetto Proença wrote: > Bengt Richter writes: > > > Hi Nathan, > > Nice writeup! > > Thank you! > > > On +2021-07-05 11:03:46 -0300, Nathan Benedetto Proença wrote: > >> 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 > >> > > > > I am wondering about guaranteeing generic behaviour by > > guaranteeing program source and toolchain source hash > > equivalences vs ignoring sources and guaranteeing end > > results by testing results. > > It seems to me that you are talking about my email regarding using > hashing in Scheme refactoring, right? > This one: > > https://lists.gnu.org/archive/html/guix-devel/2021-07/msg00023.html > > I will assume this is the case, even though I we can actually simply > talk about what you wrote. > > First thoughts: I think that what we really want to guarantee is > "correctness", and that both hashes or tests are mere proxies for this. > > I see them as useful in distinct moments of package development. > > For example, lets say that I want to partially upgrade TeXLive (which I > am already convinced is not a good idea, TBH, but serves as an > example). > To be able to do so, I may think that I want to refactor some function > to pinpoint the version I will download. > I can then make a single commit which updates the signature and all the > call sites of the function. > I can then actually upgrade the package I care about in a second commit, > and do some "proper testing" in it, like producing some
