Re: SageMath packaging work
Hi Vinicus, On 01/06/2024 6:43 am, Vinicius Monego wrote: Em qua, 2024-05-22 às 09:19 +, Ada Stevenson escreveu: Hi Guix, science team! I was reaching for SageMath today and couldn't find it in the package repository. I notice there's a sagemath.scm file, but no actual SageMath package proper. Is there any work being done on packaging it at the moment? Are there any particular blockers preventing its packaging (excessive dependencies, difficult build etc.)? Having SageMath in Guix would be really handy for me, so I'm happy to give packaging it a go if the only reason is that there's not enough interest (I will just have to wait until after exams, so in about 3-4 weeks). Hope you are all doing well! Warmly, Ada Hi Ada, SageMath has a lot of dependencies which you can see on https://doc.sagemath.org/html/en/reference/spkg/ These are my current notes (I'm not sure how to organize them online): Thank you! This is a great resource. Sorry for not responding earlier, I was in the midst of exams. I just want to check if this is still up to date, as far as you know. I want to start helping out with this effort. Standard packages: + Available in the python-team branch (not yet merged): - fqdn (python-team) - isoduration (python-team) - jupyter-events (python-team) - jupyter-server-terminals (python-team) - notebook-shim (python-team) - overrides (python-team) - referencing (python-team) - rfc3986-validator (python-team) - uri-template (python-team) + Series 1 (submitted as issue 70924): - async-lru (review) - calver (review) - memory-allocator (review) - pplpy (review) - primecount (review) - primecountpy (review) - pyproject-api (review) - types-python-dateutils (review) + Series 2 (currently working on, not yet submitted): How are you going with this series? Is there anything I can help with? - gfan (NEXT) - gnumake-tokenpool (v0.0.7+ needs Python 3.11+) - jupyter-lsp (needs updated jupyter-core) - palp http://hep.itp.tuwien.ac.at/~kreuzer/CY/CYpalp.html (NEXT) - pytz-deprecation-shim (OK but temporary usage only) - sympow - tachyon: http://jedi.ks.uiuc.edu/~johns/raytracer/files/ + Remaining standard packages: I'll give these a go. - combinatorial-designs - comm - conway-polynomials - elliptic-curves - graphs - jmol - jsonschema-specifications - jupyter-jsmol - jupyterlab - jupyterlab-mathjax2 - pari-galdata - pari-seadata-small - polytopes-db - pplpy-doc - sage-conf - sage-docbuild - sage-setup - sagenb-export - sagetex - sphinx-inline-tabs - threejs Optional packages: Wow, that is a lot! - admcycles - benzene - buckygen - coxeter3 - csdp - cunningham-tables - cylp - d3js - database-cremona-ellcurve - database-cubic-hecke - database-jones-numfield - database-knotinfo - database-kohel - database-mutation-class - database-stein-watkins - database-stein-watkins-mini - database-symbolic-data - dsdp - e-antic - frobby - gap-jupyter - gap-packages - github-cli - glucose [looks easy] - jupymake - kenzo - latte-int - libsemigroups [looks easy] - lidia - mathics - mathics-scanner - matroid-database - mcqd - meataxe - msolve - nibabel [looks easy] - normaliz [looks easy] - notedown - onetbb - ore-algebra - p-group-cohomology - pandoc-attributes - papilo - pari-elldata - pari-galpol - pari-nftables - pari-seadata - perl-cpan-polymake-prereq - perl-mongodb - phitigra - plantri [looks easy] - polymake [looks easy] - polytopes-db-4d - pycryptosat [looks easy] - pynormaliz [looks easy] - pyppeteer - pyscipopt - pysingular - pyx [looks easy] - qepcad - rst2ipynb - rubiks - saclib - sage-flatsurf - sage-numerical-backends-coin - sage-numerical-backends-cplex - sage-numerical-backends-gurobi - sage-sws2rst - scip - scip-sdp - singular-jupyter - sirocco - slabbe - snappy - soplex - tides - topcom As you can see, it's a lot of packages and dependencies, and these are only the missing ones. Some of them are outdated, abandoned, or too recent. Some of the already packaged dependencies may be too old or need patches. We need at least the standard packages. Finally, we have to glue them all in the sagemath package. So it's a lot of work and nontrivial. If you'd like to help, you can choose to package one of those "looks easy" (but optional) packages, if you're new to Guix. Or try to help with the more complex, yet more important, standard packages. You can see the source link to every dependency in that sagemath packages link. Issue 56729 is a good starting point. Thanks! I'll start with issue 56729, and hopefully bring it up to speed. The blockers are all of those you listed: excessive dependencies, difficult building and lack of interest. Vinicius Warmly, Ada
Re: No mutter on master
Hi Andreas, On 03/07/2024 8:21 pm, Andreas Enge wrote: Hello, currently I cannot reconfigure my laptop with the Xfce desktop environment due to mutter not building: Ok: 166 Expected Fail: 5 Fail: 1 Unexpected Pass:0 Skipped:0 Timeout:0 (this was on a local build). Given the amount of output, I find it difficult to see which test failed. I am on commit 972c06dc79641864b05590b2cd905cc8b810062b from yesterday. As far as I can see, the corresponding derivation has not been built by QA (following is my breadcrump trail of links followed from the data service): https://data.guix.gnu.org/revision/972c06dc79641864b05590b2cd905cc8b810062b https://data.guix.gnu.org/revision/972c06dc79641864b05590b2cd905cc8b810062b/packages https://data.guix.gnu.org/revision/972c06dc79641864b05590b2cd905cc8b810062b/packages?locale=en_US.UTF-8_query=mutter=version=synopsis_name=_results=100 https://data.guix.gnu.org/revision/972c06dc79641864b05590b2cd905cc8b810062b/package/mutter/44.9?locale=en_US.UTF-8 https://data.guix.gnu.org/gnu/store/gn3qgnzix2lnq4cg95samsy07zp0a8qr-mutter-44.9.drv Going back in time, the last successful build I could find was for commit ab41f5ec1cf559708165e1cd28e15538e6a197d6 of June 30. The next entry in the dataservice has status "unknown". After that, I do not see a commit that strikes me as suspicious as far as mutter is concerned. But there are quite a few patches applied to master recently of which I am not sure whether they have gone through QA and the process described here: https://guix.gnu.org/en/manual/devel/en/html_node/Managing-Patches-and-Branches.html Going through QA should normally make sure that dependent packages still build and that substitutes are directly available (while for some recently updated packages there are no substitutes); I would like to invite all committers to follow this procedure. Andreas Mutter is one of those packages that fails on CI for no reason occasionally. The test suite is flaky. Sometimes it passes, and we get a substitute, and sometimes it doesn't and we don't. We probably need to find the flaky test and disable it so this doesn't keep happening. Patches can pass straight through QA only to fail on CI. I had to build it locally the other day because of this substitute outage. Warmly, Ada
ci.guix.gnu.org homepage is down
Hi Guix, I just wanted to send an email out to let people know that the homepage of CI, ci.guix.gnu.org, is down. It returns a 504 Gateway Timeout error. I was looking to see what was causing the build failure of linux-libre@6.9.6, which is when I found I couldn't access it still. I had tried two days ago to access it too, and it had the same error then. Hopefully the sysadmins can look into this! Thank you for all the work you put into making sure things work behind the scenes :-) Warmly, Ada
Re: Disabling authentication checks for tests in local Guix checkouts
Hi Ludo' On 17/06/2024 1:05 pm, Ludovic Courtès wrote: Hi Ada, Ada Stevenson skribis: I'm currently trying to help test the changes to GRUB submitted in issue #71348[1]. Unfortunately, `make check`, whilst building the local Guix channel, authenticates every commit. That means commits not signed by people in `guix-authorizations` will stop the channel from building and prevents running any of the tests. Bummer. :-( I have tried to fix the issue by writing a patch: This patch looks like the right thing to do. I’m not sure how to integrate it though: in the general case, we probably want to keep authentication enabled by default, but how to allow users to easily disable it when using a personal checkout? Initially this seems like it works, as it starts to index all of the commits in the local checkout, which didn't occur beforehand, instead immediately giving a `Git error: cannot locate remote-tracking branch 'origin/keyring'` (I've run `git fetch -a`, and my Savannah remote is called `origin`). Guix caches clones under ~/.cache/guix/checkout. It may be that there’s a clone of your local repo there, but that the clone itself lack a copy of the ‘keyring’ branch? (You can run ‘git fetch -a’ in there.) I tried invoking the tests from within a `./pre-inst-env guix repl` and managed to get both of the tests to run using my patch! They both passed too. I think you're right, there must have been some sort of caching error. Anyway, I'm new to contributing using Debbugs. Is there a way to tag an issue as 'reviewed' or something like that? Or do I just send an email saying I tested the patch and everything looks good? Let me know :-) Thanks for testing! You're welcome! Thanks for writing the patch. Ludo’. Warmly, Ada
Re: Google Summer of Code Inquiry
Hi all, On 10/04/2024 6:33 am, Efraim Flashner wrote: On Tue, Apr 09, 2024 at 05:25:35PM +0200, Ludovic Courtès wrote: Hi Sebastian, Sebastian Dümcke skribis: just wanted to chime in. Since last week I have some working code to generate AppImages with guix pack. I was planning on tidying this up for submission over the next weeks. There is still work to do regarding documentation, adding options specific to the AppImage format, building the AppImageKit runtime from source and a lot of testing. This is great news! Looking forward to incorporating those changes. However, I believe that the remaining effort is around 8-10 hours. I am happy to hand the code over to you to finish up and co-mentor (though this patch would be my first contribution to guix) if you think this is appropriate. It does sound like it jeopardizes this specific project. In a way, that’s a good problem to have as a project, but it does mean that Zachary would need to look for another project (which could still be related to ‘guix pack’). Thoughts? There's always the option of trying to create flatpaks using Guix. I'd love this feature! It would probably more useful than making AppImages too. Warmly, Ada
Disabling authentication checks for tests in local Guix checkouts
Hi Guix, I'm currently trying to help test the changes to GRUB submitted in issue #71348[1]. Unfortunately, `make check`, whilst building the local Guix channel, authenticates every commit. That means commits not signed by people in `guix-authorizations` will stop the channel from building and prevents running any of the tests. I have tried to fix the issue by writing a patch: - diff --git a/etc/system-tests.scm b/etc/system-tests.scm index 221a63bb7f..6655850396 100644 --- a/etc/system-tests.scm +++ b/etc/system-tests.scm @@ -49,7 +49,7 @@ (define (tests-for-current-guix source commit) ;; of tests to run in the usual way: ;; ;; make check-system TESTS=installed-os - (let ((guix (channel-source->package source #:commit commit))) + (let ((guix (channel-source->package source #:commit commit #:authenticate? #f))) (map (lambda (test) (system-test (inherit test) diff --git a/gnu/packages/package-management.scm b/gnu/packages/package-management.scm index 54521ab3c4..46d66604c7 100644 --- a/gnu/packages/package-management.scm +++ b/gnu/packages/package-management.scm @@ -563,7 +563,7 @@ (define-public guix the Nix package manager.") (license license:gpl3+ -(define* (channel-source->package source #:key commit) +(define* (channel-source->package source #:key commit (authenticate? #t)) "Return a package for the given channel SOURCE, a lowerable object." (package (inherit guix) @@ -571,7 +571,8 @@ (define* (channel-source->package source #:key commit) (if commit (string-take commit 7) ""))) (build-system channel-build-system) (arguments `(#:source ,source - #:commit ,commit)) + #:commit ,commit + #:authenticate? ,authenticate?)) (inputs '()) (native-inputs '()) (propagated-inputs '( - Initially this seems like it works, as it starts to index all of the commits in the local checkout, which didn't occur beforehand, instead immediately giving a `Git error: cannot locate remote-tracking branch 'origin/keyring'` (I've run `git fetch -a`, and my Savannah remote is called `origin`). I'm not sure where this second building of the channel is occurring; the channel-build-system is being passed the `authenticate? #f` flag, so I'm at a loss. I'd really appreciate any input or help! Warmly, Ada [1] https://issues.guix.gnu.org/issue/71348
SageMath packaging work
Hi Guix, science team! I was reaching for SageMath today and couldn't find it in the package repository. I notice there's a sagemath.scm file, but no actual SageMath package proper. Is there any work being done on packaging it at the moment? Are there any particular blockers preventing its packaging (excessive dependencies, difficult build etc.)? Having SageMath in Guix would be really handy for me, so I'm happy to give packaging it a go if the only reason is that there's not enough interest (I will just have to wait until after exams, so in about 3-4 weeks). Hope you are all doing well! Warmly, Ada
Re: Guix bios installation: Grub error: unknown filesystem
Hi Attila, On 4/22/24 9:04 PM, Attila Lendvai wrote: This should allow grub to recognise your filesystem during the installation process. I think using a later version of grub would fix this, but that hasn't happened yet. I think there's a patch to upgrade it in `core-updates` somewhere, but I'm not sure. grub seems to be still v2.06 there: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/bootloaders.scm?h=core-updates#n103 Maybe it would be a good idea to upgrade it then. This incompatibility has probably deterred many potential Guixers- it almost deterred me. Having this hacky workaround is just not good UX. I'm not sure what upgrading GRUB would involve; maybe someone else on the mailing list has an idea on where to start? :) Warmly, Ada
Re: Guix bios installation: Grub error: unknown filesystem
Hi Franz, On 4/19/24 2:24 PM, Franz Geffke wrote: I'm having trouble installing guix in qemu, using a "fresh" guix ISO. ``` building /gnu/store/byjlc85abyjc3fjj9z982677skmda7ib-module-import-compiled.drv... building /gnu/store/psw8xn9qpsjjnrqmjrfv0v3jj9fphq5m-module-import-compiled.drv... building /gnu/store/a1zcrrcdwhb4wb2g4r0ph8mqclq7f5xn-install-bootloader.scm.drv... guix system: error: '/gnu/store/li1ic17hz460vp1sg0cx2dwgw8q7i8pj-grub-2.06/sbin/grub-install --no-floppy --target=i386-pc --boot-directory /mnt/boot /dev/sda' exited with status 1; output follows: Installing for i386-pc platform. /gnu/store/li1ic17hz460vp1sg0cx2dwgw8q7i8pj-grub-2.06/sbin/grub-install: error: unknown filesystem. ``` Here's what I've tried so far: 1. The ISO from 2022 https://ftpmirror.gnu.org/gnu/guix/guix-system-install-1.4.0.x86_64-linux.iso: Success 2. Generated a new ISO today: Failure These are the channels, on the booted ISO: ``` guix describe guix 65e8472 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 65e8472a4b6fc6f66871ba0dad518b7d4c63595e ``` Steps I used to install (1) and (2): ``` parted -s /dev/sda -- mklabel msdos mkpart primary ext4 1MiB 100% parted /dev/sda set 1 boot on mkfs.ext4 -L my-root /dev/sda1 mount LABEL=my-root /mnt cp /etc/configuration/lightweight-desktop.scm /mnt/etc/config.scm # adjust disk, bootloader herd start cow-store /mnt guix system init /mnt/etc/config.scm /mnt ``` Findings: I didn't really dig too deeply yet; Only noticed that this command produces a different result, depending on whether the install succeeds, or not `grub-probe --target=fs --device /dev/sda` - Success: `ext2` - Failure: `grub-probe: error: unknown filesystem.` I also tried using GPT instead of MBR, but it makes no difference. I've encountered this problem too, and managed to solve it. I'm 85% sure you're experiencing the same problem as me, and I've been meaning to document it somewhere - its a super obtuse error and it is a showstopper when it comes to installing guix. Basically, there is a compatibility issue regarding the ext4 filesystem features that GRUB 2.06 supports and the features that `e2fsprogs@1.47.0` enables by default when creating your ext4 filesystem. When these features are enabled, it changes the structure of the filesystem enough that GRUB can't recognise it properly and it fails. To fix this, you will need to make sure you create your ext4 filesystem with the following features: `mkfs.ext4 /dev/you-partition-here -O has_journal,ext_attr,resize_inode,dir_index,filetype,needs_recovery,extent,flex_bg,sparse_super,large_file,huge_file,uninit_bg,dir_nlink,extra_isize` These are the features that worked for me. I had to do a lot of trial and error, and I used `tune2fs -l` to see what features weren't supported. The ones I can remember are the metadata_csum features, and some other ones (they showed up as FEATURE_X when running `tune2fs` on my Guix installation image, so I used a Gparted Live CD to get rid of the features that weren't recognised by tune2fs). This should allow grub to recognise your filesystem during the installation process. I think using a later version of grub would fix this, but that hasn't happened yet. I think there's a patch to upgrade it in `core-updates` somewhere, but I'm not sure. Anyway, hope this helps! Warmly, Ada
Re: Error handling when 'guix substitute' dies
Hi Lars, On Tue, Apr 2 2024 at 10:42:18 AM +0200, Lars Bilke wrote: Dear Ludo, I ran the command in a loop on 4 machines for around 2 hours doing 1 request per machine per second but no errors occured... I did a similar thing. No errors at all. However, I was reconfiguring my system at uni yesterday after the gnome-team merge and it was happening a lot! I wonder if it's something to do with the server? I don't know enough about networking to really theorise, haha. On 29 Mar 2024, at 16:10, Ludovic Courtès wrote: Hello, Ada Stevenson mailto:adansk...@gmail.com>> skribis: diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scm index 37cd08e289..3af0bf0019 100755 --- a/guix/scripts/substitute.scm +++ b/guix/scripts/substitute.scm @@ -494,7 +494,9 @@ (define* (download-nar narinfo destination (define (try-fetch choices) (match choices (((uri compression file-size) rest ...) - (guard (c ((and (pair? rest) (http-get-error? c)) + (guard (c ((and (pair? rest) + (or (http-get-error? c) + (network-error? c))) (warning (G_ "download from '~a' failed, trying next URL~%") (uri->string uri)) (try-fetch rest))) I’ll go ahead with this change if there are no objections. Looks good to me! Thanks for looking into this :) OK, I’ll push it shortly, but… Lars Bilke mailto:lars.bi...@ufz.de>> skribis: thanks Ada for bringing this issue up again. I get the same error on `guix pull` almost always when I am on my enterprise network. Re-running `guix pull` a second time also almost always then runs fine. I checked with our IT: nothing suspicious on the network, i.e. no firewall blocking. I never experienced the error on my home network. … your reports make me think there’s a bug lurking somewhere that perhaps only manifests under some precise networking or timing conditions. Could the two of you run the following command in a loop to see whether it’s easy to reproduce that GnuTLS error? guile -c '(use-modules (guix http-client) (ice-9 binary-ports)) (get-bytevector-all (http-fetch "<https://ci.guix.gnu.org/nix-cache-info>"))' If you can reproduce it, could you capture the strace output of the process? You would run the command above prefixed by: strace -o log.strace -s 300 … Thanks in advance! Ludo’. Thanks, Ada
Re: Error handling when 'guix substitute' dies
Hi Ludo', On 3/24/24 11:15 AM, Ludovic Courtès wrote: Hi Ada, Ada Stevenson skribis: Sometimes, usually when I'm on an enterprise network like my university's of library's wifi, the `guix substitute` process dies with a "TLS error in procedure 'write_to_session_record_port': Error in the push function" error message. My connection is rock-solid otherwise, and sometimes it doesn't happen at all. What version of guix-daemon are you using? Was it installed through ‘guix pull’ or via another distro? I’ve seen this before but I haven’t experienced it in a long time, so I wonder if I’m just lucky or if there are other factors at play. I'm running the up-to-date daemon, 1.4.0-18.4c94b9e, on Guix System. I'm not sure if this is a fault in the actual Guix code, or there's some Guile library somewhere that has this bug. Anyway, I think it would be a useful feature to have a way to automatically restart the `guix substitute` process or otherwise recover from this error. Some sort of `--restart=no.restarts.permitted` flag. Whenever I'm updating my system I tend to leave and do something else, and when this happens I come back and nothing's actually been done, and the error is transient so I don't gain anything from seeing this message. ‘guix substitute’ is a ‘guix-daemon’ helper, which automatically (re)starts it when needed. Now, what we could do is have ‘guix substitute’ gracefully handle those errors and keep going. I believe this one-liner should do it: diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scm index 37cd08e289..3af0bf0019 100755 --- a/guix/scripts/substitute.scm +++ b/guix/scripts/substitute.scm @@ -494,7 +494,9 @@ (define* (download-nar narinfo destination (define (try-fetch choices) (match choices (((uri compression file-size) rest ...) - (guard (c ((and (pair? rest) (http-get-error? c)) + (guard (c ((and (pair? rest) + (or (http-get-error? c) + (network-error? c))) (warning (G_ "download from '~a' failed, trying next URL~%") (uri->string uri)) (try-fetch rest))) I’ll go ahead with this change if there are no objections. Looks good to me! Thanks for looking into this :) Thanks, Ludo’. Thanks, Ada
Error handling when 'guix substitute' dies
Hi Guix, I have this gripe with usability regarding using substitutes. Sometimes, usually when I'm on an enterprise network like my university's of library's wifi, the `guix substitute` process dies with a "TLS error in procedure 'write_to_session_record_port': Error in the push function" error message. My connection is rock-solid otherwise, and sometimes it doesn't happen at all. I'm not sure if this is a fault in the actual Guix code, or there's some Guile library somewhere that has this bug. Anyway, I think it would be a useful feature to have a way to automatically restart the `guix substitute` process or otherwise recover from this error. Some sort of `--restart=no.restarts.permitted` flag. Whenever I'm updating my system I tend to leave and do something else, and when this happens I come back and nothing's actually been done, and the error is transient so I don't gain anything from seeing this message. I workaround could potentially be wrapping `guix upgrade` and the like in a script that keeps on restarting the commands until they exit with 0. This seems a little clunky and fragile, especially if there's an actually fatal error, eg. my config is not valid. What do you guys think? Would this be something that people would be interested in? Or would it be better to try and find out why there's these transient errors (a way more time-consuming effort, I fear). Does anyone else have this issue? Warmly, Ada
Re: GNU and GSoC
Hi, Having Guix be part of GSoC would be fantastic! I'd love to have the opportunity to be mentored. It would be exciting for Guix to receive some more attention, as well as showing people how fun it is to hack on :) Thanks, Ada On 2/23/24 7:38 AM, Pjotr Prins wrote: The GNU project is a GSoC org again. Last year Sarthak did a great job working on parameterization of Guix. It works, and you can try the code. See => https://guix.gnu.org/blog/2023/parameterized-packages-for-gnu-guix/ => https://blog.lispy.tech/ For this year GNU can propose projects again. We should suggest Guix, Mes and Hurd projects in the coming two weeks. Ping Gábor, Sarthak, Arun, Efraim or me if you are interested in co-mentoring an effort. Note that GSoC is competitive for orgs, mentors and students. It requires effort, but anyone who participates can attest it is rewarding. I have been doing this for more than 10 years. It is a great programme. Pj.
Re: status of (future of) Guix QA
Hi, On 12/22/23 8:11 PM, Andy Tai wrote: Curious of the status of the future of Guix QA as package definition contributors rely on it for updating packages (sending patches to get accepted/committed) in guix... I'm curious too. Did anything come of the discussion a few weeks ago? Ada (adanksa)
Re: RFI: Guix XMPP service. paid service?
Hi, On 12/14/23 7:36 AM, Ricardo Wurmus wrote: jbra...@dismail.de writes: I would like to pay $5 a month to have an xmpp account coolawesomeusern...@guix.gnu.org Are there other interested parties? It might be a possible way to generate $$ to continue developing guix. I’d rather not commercialize stuff like this, especially not for project communication. I wouldn’t want our servers to cache image, video, and audio uploads by “coolawesomeusername” that aren’t related to discussing Guix. Nor would I want to give the impression that “coolawesomeusername”’s activities are in any way endorsed by guix.gnu.org. We don’t ache for $5 a month, and giving away autonomy over the name and what it is associated with is worth far more than a trickle of $5. In my personal opinion (as an experienced curmudgeon) I think that setting things up for commercialization is to invite unspeakable dread and rot. Agreed. Accounts with an official domain like 'guix.gnu.org' should be left for very special cases, such as admin accounts or special server infrastructure. Upkeeping a XMPP server that caches this data would be a little more expensive than usual, but if you use Guix often and want to support the project you should very well just donate. (As a digression, I do believe that we should promote the link to donate to the project a little bit more, perhaps in the IRC and XMPP banners?) Anyway, hosting a server should be pretty cost efficient. A few terabytes would go a long way, and you wouldn't need that much compute speed either. An XMPP server would be the least of our worries expenditure-wise (we still have to decide whats happening with qa.guix and data.guix (!)) Thanks, Ada (adanska)
Re: RFI: Guix XMPP service.
Hi, On 12/10/23 4:04 PM, MSavoritias wrote: On 12/10/23 17:56, Vivien Kraus wrote: Le dimanche 10 décembre 2023 à 17:45 +0200, MSavoritias a écrit : There is also a trust issue. For acceptance, we need bridging. For bridging, we need policing. And for policing, we need people with time. I am of the opinion that bridging would be a bad idea. The differences between IRC and XMPP are significant enough that bringing would probably be more disruptive than conducive to acceptance. A better approach would to simply have a separate IRC and XMPP channel. If people end up preferring XMPP, more people will simply elect to use it. In any project eventually the main communication channels tend to split up into smaller groups once they get to a certain size anyway for a number of reasons. This doesn't stop these other spaces from being 'accepted', and if we have the XMPP channel become official, I think this is acceptance enough. That's a good question yeah. Whether we want bridging that is. Personally I am leaning that we don't. Because bridging can ruin the experience of people that use XMPP. But I can see it either way. Maybe we could do something a little smarter, like having sneek deliver messages in both IRC and XMPP. Vivien There are mirroring ways yeah. That would be a better solution. Because there is biboumi but it basically just creates an IRC room in XMPP. Also sneek should filter stuff probably. Because xmpp allows pictures and long messages and such. So it shouldn't mirror everything as is. I don't know how possible it is though. Maybe some custom setup of something. That said I do have my doubts whether this is more trouble than its worth personally. Given that IRC and XMPP are two very different protocols that are probably gonna attract a different community. Agreed. Specifically, mobile XMPP clients work far, far better than their IRC counterparts out of the box. I think we'd see a lot of people come to the XMPP server due to it's great mobile accessibility. In short, I think we should host our own XMPP server (maybe a VPS for uptime purposes? With media uploads and message logs, storage would be much more of a factor to consider compared to IRC) under the guix.gnu.org domain name and list it on the website. I think once we get to that stage, investigating how to keep track of message logs (perhaps mirroring logs to logs.guix.gnu.org, perhaps under a separate page to the IRC logs) will be vital in moderation efforts. Bridging would cause more problems and potentially solve a problem that we shouldn't want to solve (having one unified space). MSavoritias Ada (adanska)
Re: Add xmpp room to the list of group chats.
Hi, On 12/7/23 11:25 AM, MSavoritias wrote: On 12/7/23 09:42, Ada Stevenson wrote: Hi, On 12/2/23 8:20 AM, MSavoritias wrote: Hey, I thought this mailing list is the most fitting for the request feel free to point out if its better somewhere else. Is the community open to have group chats listed in other networks than IRC assuming they are free software? Having chat groups in different networks is going to greatly improve the accessibility of the project towards new contributors which I think we recently wanted to start working on as one of our areas of focus. The group chat I am talking about is in xmpp/jabber and it is here -> g...@chat.disroot.org It has already the CoC of the guix project and xmpp is free software from server to client. Also disclaimer: I am not talking about starting to bridge them. That is an entirely separate thing with different tradeoffs and maintenance. Just listing the group chat is easy though :) Msavoritias This sounds like a good idea to me! XMPP just works a lot nicer with stuff like attachments and message logging without needing peripheral tooling like znc to get around things like message logging/persistance. Whether we go with disroot.org to host the chat, or whether GNU can host something for us in the future I'm not sure, but I'm keen to see more usage of XMPP. I think the channel should be listed once we have a strong consensus that we want to use XMPP as a main communication channel. Perhaps this is suitable for a RFI? Why main communication channel? I mean sure we can have a discussion regarding that, but I think that brings far more questions than just listing the xmpp channel as an alternative. Plus we don't even know how desirable it would be for it to be the main channel? (Although a lot of people have started to appear in the channel which is nice ^^) Sorry, I got a bit overzealous, haha! You're right, I don't think its useful to be talking about changing the 'main' channel as it were. IRC is mature and is working well at the moment, and is integrated with a lot of people's workflows already (ERC for emacs, for example). The model I was looking at was similar to -> General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software. - ziglang/zig github.com Community <#> General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software. - Community · ziglang/zig Wiki https://github.com/ziglang/zig/wiki/Community <https://github.com/ziglang/zig/wiki/Community> I see. In my opinion I'm not the biggest fan of having all of these disjoint spaces for a community the size of Guix (that is, relatively small). There are a lot of merits at this stage to keeping communication centralised so everyone can be seen and heard. Of course, as the project matures and more people come to use it, it is natural that more channels on different platforms will pop up; this works when there are many people working on a project and traffic gets too heavy and needs from a platform diversify. As it stands now, I think having IRC, XMPP and the mailing list as communication platforms serve to cover the needs of most people, whilst still keeping things central. However, I understand the desire to keep everything as central as possible, especially when it comes to communication. IRC works well enough in most cases, and by far has the most active users. This doesn't mean things can improve, though, and the niceties provided by a more modern protocol such as XMPP could be worth it, potentially. Anyway, there isn't much harm in maintaining our own XMPP channel for those who wish to use it. What is being proposed here? hosting our own xmpp server or promoting this as an "official" channel? whatever that means. I am proposing hosting our own server as well as putting the XMPP channel on the Guix homepage, promoting it as a means to get in touch with the community in the same way IRC and the mailing list are. The current disadvantage with hosting on disroot.org is the 30 day message and file storage limitation[1]. One of the great things about the IRC chat is the online, searchable log[2] that goes all the way back to 2013. The benefits of having conversations saved like this speaks for itself. If there is a way to replicate this with XMPP and bypass this 30 day limitation this would make XMPP far more viable as a communication channel. MSavoritias Thanks, Ada (adanksa) [1] https://disroot.org/en/services/xmpp [2] https://logs.guix.gnu.org What do you think? Thanks, Ada (adanska)
Re: Add xmpp room to the list of group chats.
Hi, On 12/2/23 8:20 AM, MSavoritias wrote: Hey, I thought this mailing list is the most fitting for the request feel free to point out if its better somewhere else. Is the community open to have group chats listed in other networks than IRC assuming they are free software? Having chat groups in different networks is going to greatly improve the accessibility of the project towards new contributors which I think we recently wanted to start working on as one of our areas of focus. The group chat I am talking about is in xmpp/jabber and it is here -> g...@chat.disroot.org It has already the CoC of the guix project and xmpp is free software from server to client. Also disclaimer: I am not talking about starting to bridge them. That is an entirely separate thing with different tradeoffs and maintenance. Just listing the group chat is easy though :) Msavoritias This sounds like a good idea to me! XMPP just works a lot nicer with stuff like attachments and message logging without needing peripheral tooling like znc to get around things like message logging/persistance. Whether we go with disroot.org to host the chat, or whether GNU can host something for us in the future I'm not sure, but I'm keen to see more usage of XMPP. I think the channel should be listed once we have a strong consensus that we want to use XMPP as a main communication channel. Perhaps this is suitable for a RFI? However, I understand the desire to keep everything as central as possible, especially when it comes to communication. IRC works well enough in most cases, and by far has the most active users. This doesn't mean things can improve, though, and the niceties provided by a more modern protocol such as XMPP could be worth it, potentially. Anyway, there isn't much harm in maintaining our own XMPP channel for those who wish to use it. What do you think? Thanks, Ada (adanska)
Re: Questions about packages because of license and other
Hi, On 12/6/23 8:36 PM, Christian Miller wrote: Hi, 1. PrismLauncher[0]: The software itself is licensed as GPL3 but it is used to download and launch a proprietary videogame called "Minecraft". Since it is itself GPL3 licensed but used for a proprietary videogame, would it be allowed for upstream or not? This is already included in the Guix-Gaming[1] channel. 2: PCSX2[1]: Software itself is licensed as GPL3 but is used to emulate a PlayStation 2 (game console), which is highly proprietary hardware. It is also wishlisted on libreplanet[2]. It requires the original proprietary BIOS (not distributed by the software) to run. Since it is a game console, it also requires proprietary video games (not distributed by the software). For these gaming related packages that require non-free software, perhaps it might be a good idea to contribute to Guix-Gaming[1] instead, rather than upstream. 3. impatient-mode[3]: This is an Emacs mode to write HTML and see it in realtime rendered in the web browser. It has no license file. In the file "impatient-mode.el" it says "This is free and unencumbered software released into the public domain.". Is this suitable for an upstream package? It looks to me not correctly licensed but I am also not an expert in this and therefore unsure. Public domain would be suitable for inclusion, though. PrismLauncher works but does not show images from the instance. PCSX2 works but does not show icons. Imaptient-mode is done. Since it is better to push as much as possible upstream, would they met the requirements or not? [0] https://github.com/PrismLauncher/PrismLauncher [1] https://github.com/PCSX2/pcsx2 [2] https://libreplanet.org/wiki/Group:Guix/Wishlist#Emulation [3] https://github.com/skeeto/impatient-mode [1] https://gitlab.com/guix-gaming-channels/games Thanks, Ada (adanksa)
Re: Making linux-libre@6.5 the default kernel
Hi! Hi Leo! :) The reason is that I haven't had enough time to make these changes lately, and for a while I have been the only person updating the kernel in Guix. That makes a lot of sense. I had no idea - the reason I came to the mailing list was to figure out what everyone's doing, and that's proved very fruitful. Thank you for all of your work :) So, to make things clear, the delay in making 6.5 the default kernel is in part because you lack sufficient support in the case that things go wrong or some urgent change needs to be pushed? That makes sense, and I'm sorry it is this way. :/ I'd like for more people to join the effort, and there's some info about that subject here: https://lists.gnu.org/archive/html/guix-devel/2023-10/msg00079.html I don't think I'll be of much help - I'm pretty unfamiliar with kernel configuration, and I currently have a few Guix packages that I'm working on that are taking up most of my Guix time. However, I wish you the best, and I do hope that you're able to muster some extra hands from the community. During the university holidays I'll see if I'm able to lend some help - even if it isn't full-time! Thanks! Ada (adanska) On 10/8/23 6:17 PM, Leo Famulari wrote: On Tue, Oct 03, 2023 at 11:05:40AM +, Ada Stevenson wrote: Hi Guix! Hi! I understand why that may be; the commit is quite new, and pushing new kernel versions on everyone is a pretty big thing. I just want to know what the timeline on this sort of thing is - when can we expect the new 6.5 kernel to become the default? Thanks for asking about this. The reason is that I haven't had enough time to make these changes lately, and for a while I have been the only person updating the kernel in Guix. I'd like for more people to join the effort, and there's some info about that subject here: https://lists.gnu.org/archive/html/guix-devel/2023-10/msg00079.html OpenPGP_0x99A5BEE5B59C15DB.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Making linux-libre@6.5 the default kernel
Hi Guix! I saw that linux-libre@6.5 was merged upstream today - however, it hasn't been made the default yet. I understand why that may be; the commit is quite new, and pushing new kernel versions on everyone is a pretty big thing. I just want to know what the timeline on this sort of thing is - when can we expect the new 6.5 kernel to become the default? There is some pressure to do so - 6.4 is EOL, and I'm sure you've heard the news regarding the Linux maintainers and the pressures supporting older kernel versions. I think it's good idea to expedite the transition to the new stable kernel slightly. Thanks! Ada (adanksa) :) OpenPGP_0x99A5BEE5B59C15DB.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
