Re: rewriting history; Was: Concerns/questions around Software Heritage Archive
On 2024-03-18 15:14, Andreas Enge wrote: Am Mon, Mar 18, 2024 at 04:33:49PM +0200 schrieb MSavoritias: Actually gitlab already is facing something like that and they are doing what was proposed elsewhere: mapping of UUIDs to display names https://gitlab.com/gitlab-org/gitlab/-/issues/20960 Interesting, thanks! It is something that maybe could be implemented by Savannah, but it would probably require a bit of thought. And yet again, somehow the mapping uuid<->"real" names would have to be public (people would "git clone" commits with uuids, and would need to locally replace them by "real" names); so people can always keep copies of the mapping over time. I am also not quite sure about the signing process for committers; in principle keys are enough, but in GPG they are tied to email addresses, and I do not know whether we use this in Guix. In the end, my impression is this will not achieve much more than what we already have with the .mailmap approach. In a sense, everyone would use a pseudonym (their uuid), and then we would keep a mapping between these pseudonyms and, well, "real" names or other pseudonyms chosen by the contributors... Hm, this could indeed be implemented exactly with .mailmap, no? We would need to enforce that authors use a uuid of a specific format, and potentially an empty or dummy email address, or another uuid. Then we could keep a .mailmap file. The history of "real" identities would still be visible in the git history, but as said above, anyway we could not prevent people from storing the association information over time. Right fair. As I have said before SWH does break Guix CoC effectively right now. So what Guix does from this point on will effectively dictate if the CoC is valid or not. Well, the CoC is valid on our communication channels; so what SWH does with our software is outside its scope (that is governed by the license). Andreas I have happened to stumble across a new initiative concerning UUIDs for academic researchers. Here is their description: ``` ORCID, which stands for Open Researcher and Contributor ID, is a free, unique, persistent identifier (PID) for individuals to use as they engage in research, scholarship, and innovation activities. We provide ORCID to researchers free of charge so that we may realize our vision of connecting all who participate in research, scholarship, and innovation are uniquely identified and connected to their contributions across disciplines, borders, and time. ``` Here are its guiding principles: ``` Our Founding Principles ORCID will work to support the creation of a permanent, clear, and unambiguous record of research and scholarly communication by enabling reliable attribution of authors and contributors. ORCID will transcend discipline, geographic, national, and institutional boundaries. Participation in ORCID is open to any organization that has an interest in research and scholarly communications. Access to ORCID services will be based on transparent and non-discriminatory terms posted on the ORCID website. Researchers will be able to create, edit, and maintain an ORCID identifier and record free of charge. Researchers will control the defined privacy settings of their own ORCID record data. All data contributed to ORCID by researchers or claimed by them will be available in standard formats for free download (subject to the researchers’ own privacy settings) that are updated once a year and released under a CC0 waiver. All software developed by ORCID will be publicly released under an Open Source Software license approved by the Open Source Initiative. For the software it adopts, ORCID will prefer Open Source. ORCID identifiers and record data (subject to privacy settings) will be made available via a combination of no-charge and for-a-fee APIs and services. Any fees will be set to ensure the sustainability of ORCID as a not-for-profit, charitable organization focused on the long-term persistence of the ORCID system. ORCID will be governed by representatives from a broad cross-section of stakeholders, the majority of whom are not-for-profit, and will strive for maximal transparency by publicly posting summaries of all Board meetings and annual financial reports. ``` While I do not have the focus to make a further evaluation, I should point out that ORCID is a component of the nascent Open Science Network https://openscience.network/ FWIW, recognising an academic in OSN and being aware of the quality of the tooling Bonfire Networks make me wonder whether ORCID has some good design principles https://bonfirenetworks.org/ In any case, it may provide a practical point for comparison given the thicket of governance issues this thread has discovered. Warmest regards, fsnjfkjljcjcjcdnmddfnfdfnlzxvcllnjnrejvns v fjfdsjhsv
Re: You're invited to the first patch review session!
Hello, On 2024-02-23 19:13, Tomas Volf wrote: On 2024-02-22 23:27:31 +, Steve George wrote: ... Will the Jitsi link be shared somewhere (here, irc, ...) for those of us who are not able to sign up on the page? I am getting this error: Your IP address has been flagged as a source of spam and is blocked from Meetup. Since meetup.com is a commercial, third-party service, I assume there is not anything you can do about that, so I am curious if there are any alternatives how to get into the review session. Well, I did use Mobilizon for the Friday dinner for Guix Days - which though lacking some features is FOSS and Fediverse tech. https://mobilizon.nl/events/ee570f76-1898-43ff-88f0-86f18608ff2d It does permit email (as opposed to registration) to confirm - though I noticed that only 1 or 2 people actually provided any information for me to discern them. ... I guess it meant the system reduced the risk of spam signups but simultaneously didnt enforce accountability to an organiser. On a legal basis Id assert that the specific instance being based in the Netherlands would be advantageous than wherever Meetup queries; routes; and caches. It is run by some random volunteer, with all the carnets of such trust domains. In any case, Im going to try to participate in these events, I reckon it would be a good compensation for there not being a regular Guix meetup in Belgium. Kind regards, Jonathan
Re: Git-LFS or Git Annex?
Hello, On 24-01-2024 16:22, Ludovic Courtès wrote: Hello! I’m looking for ways to incorporate videos into the repositories of our web sites so they’re content-addressed and properly tracked, and to make it easier to create backups (right now those videos are stored on our two main servers and rsynced between them⁰; I’m talking about the videos at guix.gnu.org, 10years.guix.gnu.org, and hpc.guix.info). The question boils down to: Git-LFS or Git Annex? From a quick look (I haven’t used them), Git-LFS seems to assume a rather centralized model where there’s an LFS server sitting next to the Git server¹. Git Annex looks more decentralized, allowing you to have several “remotes”, to check the status of each one, to sync them, etc.² Because of this, Git Annex seems to be a better fit. Data point: guix.gnu.org source is hosted on Savannah, which doesn’t support Git-LFS; the two other web sites above are hosted on GitLab instances, which I think do support Git-LFS. What’s your experience? What would you suggest? In an ideal world I would be encouraging Guix to be operating its own Peertube instance, so that the aforementioned videos can be operating within the Fediverse: https://joinpeertube.org/ https://docs.joinpeertube.org/ Alas, looking at the list of dependencies makes me wonder how long this would take: https://github.com/Chocobozzz/PeerTube/blob/develop/package.json#L86 https://docs.joinpeertube.org/support/doc/dependencies#other-distributions Thanks, Ludo’. ⁰ https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berlin.scm#n193 ¹ https://github.com/git-lfs/git-lfs/wiki/Tutorial ² https://git-annex.branchable.com/walkthrough/ It would be nice if there was an alternative Peertube instance technology in a language we have more comprehensive packaging (than Typescript). I havent heard of anything, hopefully something will pop up during FOSDEM/OFFDEM, Brussels. There should be enough Fediverse technologists at Caldarium (who will be hosting us for the Guix Days dinner on the Friday), I shall try to remember to ask people. -- Jonathan McHugh indieterminacy@libre.brussels
Emacs Packaging Magazine
Hello all, I thought Id point out that there is a niche magazine which has started out, which is dedicated to Emacs Elpa: https://amodernist.com/eaez/sep23.html c/o https://irreal.org/blog/?p=11694 Id assume it could be interesting to those passionate for packaging in the Emacs domain. -- Jonathan McHugh indieterminacy@libre.brussels
Re: ActtivityPub and Haunt
On 29-09-2023 14:10, Efraim Flashner wrote: On Thu, Sep 28, 2023 at 10:03:13PM +0200, Reza Housseini wrote: > But I will hands-down say that Haunt was an EXCELLENT environment for > writing ap.rocks. The implementation guide page especially is a great > demonstration of Haunt's power: > >https://activitypub.rocks/implementation-report/ pretty cool stuff indeed! I also checked out the software mentioned on the page, are there any attempts at packaging some of the software e.g. microblog.pub? Looks like I was starting to work on it at some point. Not sure why I stopped. https://git.sr.ht/~efraim/my-guix/tree/master/item/wip/microblog-pub.scm Should you want a good place to harvest I strongly recommend this list: https://delightful.club/delightful-fediverse-apps/ https://codeberg.org/fediverse/delightful-fediverse-apps As can be imagined, some of these softwares have stacks which Guix is not so usually adept at packaging. However, there are more minimalist and packaging friendly ones than the (interesting) Python one you have started with. If anybody wants some suggestions of low hanging fruit just message me and I can suggest a hitlist. -- Jonathan McHugh indieterminacy@libre.brussels
Re: The Giraffe; the Pelican et al (was Re: The e(macs)lephant in the room and the Guix Bang)
On 25-09-2023 22:35, Simon Tournier wrote: Hi, On Mon, 25 Sep 2023 at 14:13, MSavoritias wrote: So saying that the people who don't know guile or guix need to first contribute docs is pretty ridiculous. Why? Could you explain more why it appears to you “ridiculous”? My frustration seems to be that a lot of negative energy has been directed towards Emacs. It has almost been straying towards anti elitist type discourse (that one is observing more increasingly in politics) - *rather* than doOcracy style discourse that there is a problem and people are capable of autonomously resolving these things. Emacs has not done something wrong here - it has merely had people who have had the capacity for exploration and reaching certain goals and insights then documenting their techniques within the Guix documentation. It seems strange that people havent sooner expressed the concept of: 'well, I have this setup in /this/ editor, Ill put it up. Anybody else want to contribute and fill out gaps X Y and Z?' It is worth noting that there has been a thread fork, starting this this subject title which is behaving more maturely and proactively: RFC: add more setups to Guix docs Similarly, there have been more sounds regarding Vim which are more proactive and constructive. If people want a plurality of editors represented in the documentation they should be proactive about it, rather than lamenting and using divisive rhetoric. Cheers, simon -- Jonathan McHugh indieterminacy@libre.brussels
The Giraffe; the Pelican et al (was Re: The e(macs)lephant in the room and the Guix Bang)
I would assume that people who dont use Emacs are entitled to document their experiences using their weapon(s) of choice within the Guix knowledge corpus. Sure, consider and discuss governance and workflows... but people complaining that Emacs users have documented their techniques to a better standard than non Emacs users within an operating system's documentation is bordering on the ridiculous. On 23-09-2023 10:58, paul wrote: Dear Janneke, On 9/23/23 09:37, Janneke Nieuwenhuizen wrote: Nathan Dehnel writes: I don't use emacs either (because it's so impenetrable) Emacs might be somewhat different from what you know, but this is utter bollocks. Thank you for your opinion but it's just that: a subjective judgement based on your own episodic experience. Which is definitely valid but unrealistically shared by so many to be able to define Nathan's experience "utter bollocks". I think this attitude (in my experience typical of GNU maintainers) where their way of doing computation is more blessed or holier or better sometimes really ruins the social interactions happening around Guix (which is the safest community in the GNU project imho, probably also due to the distance they rightfully posed during the whole stallman drama). It's especially problematic when people in power such as maintainers do not realize their role in the community. You have more power, probably due to your investment you have a clearer vision of where the project is going as well. You are supposed to be a role model for new users and contributors. If he could learn, most anyone should be able to pick it up. People are still indenting their code manually today, etc... it's ridiculous. This behavior is not ok. Again, please, stop throwing your judgement on people. Potential users or contributors even. Also, magit. I use Emacs, love magit, I used to use it daily also at $day_job on Windows because it's just so good, but I can assure you most of Git users never heard of it and live their life pretty happily. giacomo -- Jonathan McHugh indieterminacy@libre.brussels
ActtivityPub and Haunt
In wider fediverse news, The ActivityPub webpage is getting a rejig: https://socialhub.activitypub.rocks/t/activitypub-rocks-portal-from-standards-movement-to-grassroots-fedi/3577 Im emailing, as within the technical discourse page is whether the tech stack should be moved away from (scheme based) Haunt (which powers Guix's website): https://socialhub.activitypub.rocks/t/activitypub-rocks-portal-technical-discussion/3578 Naturally, Id be keen on continuing the furrow carved by Christine Lemmer-Webber and thought it would be worth seeing if there are any Lispers here who would be keen on volunteering, lest the platform goes Typescript. At my end, I consider the benefits to i18n to be a useful synergy: https://socialhub.activitypub.rocks/t/activitypub-rocks-portal-technical-discussion/3578/3 If you agree, Id love you contribute your input there. -- Jonathan McHugh indieterminacy@libre.brussels
Re: How can we decrease the cognitive overhead for contributors?
On 03-09-2023 19:45, Ekaitz Zarraga wrote: Hi, I think this is the biggest hurdle. A lot of folks are using gmail and its web based UI and it is just plain awful. I have made the switch to using neomutt (and isync + notmuch + mstmp) and it has made emails a joy to use and work with. I use protonmail and they don't provide smtp access so I can't do git send-mail as easy as other people do. Protonmail has a bridge that deals with that but we don't have it packaged because it's written in Go and it has TOO MANY dependencies. This is not Guix's fault, but it's a problem Guix doesn't help fix either. The only thing I can do with this is just copy-paste the result of git format-patch and hope it's not a trouble for committers. This doesn't mean I'm against the email based approach, in fact, I really like it. The main problem I see is many people inside guix are not sensible to people's problems and tastes. Some people are forced to use tools for several reasons, too. This is what I mean when I say many times emacs is kind of mandatory, and this thread is kind of a demonstration of what I meant because the main discussion evolved to: you can use this or that in emacs to ease the dev experience. One of the benefits of my being able to attend Guix Days was seeing peoples' workflows and stacks in person. As such, one of my conclusions having (already) committed to Guix was that I needed to master Emacs prior to Guile (Im highly flow orientated). I don't think software we use is the main problem, but the fact that we are not always sensible with other people's experience. Cheers, Ekaitz -- Jonathan McHugh indieterminacy@libre.brussels
Re: Maybe a way to get a few more developpers to work on Guix ?
On 22-06-2023 15:13, Nicolas Graves via "Development of GNU Guix and the GNU System distribution." wrote: https://www.bpifrance.fr/nos-appels-a-projets-concours/appel-a-projets-communs-numeriques-pour-lintelligence-artificielle-generative Here's a call for proposal in French which could match a Guix project with a focus on code generation through LLMs. This could itself help Guix generate (and fix) package definitions. Well if you are wanting to claw at that rabbit-hole: This is a small EU AI fund for civil society not-for-profit organisations (<=30kEUR): https://europeanaifund.org/newspublications/our-ecosystem-grants-programme-is-now-open/ If only Guix had a not for profit based in Europe that could provide such functionality I heard about some hot new foundation however - perhaps somebody could reach out to them to see if they are interested? Applications in for the end of July. -- Jonathan McHugh indieterminacy@libre.brussels
Re: London Guix meetup
On 14-06-2023 00:27, Arun Isaac wrote: Hi all, We are organizing a casual Guix meetup in London. There is no specific agenda. The intention is for Guix users and would-be Guix users in London to get to know each other, and to put faces to names. No prior experience with Guix (or Guile) is necessary. Newcomers are very welcome! Date: Tuesday, June 27 6–9 pm BST Location: Barbican Centre, Silk Street, EC2Y 8DS, London Mobilizon page: https://mobilizon.fr/events/f18da336-07f5-489f-ae7c-394458668cea Looking forward to meeting many of you for a pleasant summer's evening by the fountains at the Barbican Centre! We will provide more exact instructions on how to find us at the venue as we get closer to the date of the event. The date and time are almost confirmed, but we can nudge it a little if you reply quickly (say, within a couple of days). Regards, Arun Guix, Barbican, Mobilizon, thats exuding far too much class :) Cant make it over but enjoy the chance to lock horns! -- Jonathan McHugh indieterminacy@libre.brussels
Re: Fwd: Greens/EFA internship
usen (he/him) IT Project Manager alexander.sassmannshau...@europarl.europa.eu Phone: + 32 228 32860 PHS02C027 Rue Wiertz 60 B-1047 Bruxelles -- Jonathan McHugh indieterminacy@libre.brussels
Re: The Shepherd gets a service collection
Thanks! PS: It just occurred to me that we might as well rename the new (shepherd service …) hierarchy to (shepherd sheep …) or even (shepherd …). Its a shame that Directed Acyclic Graphs are part of Guix verbiage, as otherwise Id be suggesting the name 'dags'. (Dags are the yellowed clumps of wool that cluster around their netherregions. There is a antipodean phrase, 'rattle yer dags!', to mean 'hurry up!', given the clumps bouncing around when sheep move quickly. -- Jonathan McHugh indieterminacy@libre.brussels
Re: Emacs next variants
On 12-03-2023 08:46, Liliana Marie Prikler wrote: Am Sonntag, dem 12.03.2023 um 09:18 +0400 schrieb Andrew Tropin: > As for tree-sitter-with/without-gtk, I have no opinion here. We > could try exporting package rewriters so that everyone can have > their cup of tea, but maintaining one's own Emacs on the > user/channel level ought not to be too difficult either. I guess inheriting pgtk from tree-sitter looks most logical here: no potential problems for X users, tree-sitter for wayland users. Updated the inheritance hierarchy. For the future, I think we should be careful not to be too close to the master branch. emacs-next has thus far historically been a package to try out things for the next release, not the one after that. The inclusion of a package variant with tree-sitter necessitated a change, but for packages that don't need it we should go back to tailing pre- releases as soon as reasonable. Out of curiosity, where do such prescriptions concerning one tool or a set of tools get documented? Or is it currently a situation whereby enough people with such acculumated knowledge and experience as in the vicinity when somebody wants to make relevant changes? Thanks, -- Jonathan McHugh indieterminacy@libre.brussels
Re: Implementing Nix's command-not-found in Guix
On 04-03-2023 22:42, Sarthak Shah wrote: Hello Guix! I'd like to implement something similar to NixOS's command-not-found in Guix. As you can see in the repository below, it contains a nix file which is essentially a shell script which runs the second file, a perl script, if the user enters a command which is not found on this system. The perl script suggests names of packages containing said command which it pulls from an SQL database. https://github.com/NixOS/nixpkgs/tree/master/nixos/modules/programs/command-not-found This would make Guix much more user-friendly; for example, new Guix System users often struggle to figure out how to add the "clear" command to their shell. command-not-found would immediately inform them that it can be found in the ncurses package. How would you recommend I go about implementing something similar for Guix? I have unfortunately been unable to find a database or anything similar listing files outputted to /bin by each package, which would in my opinion be the starting step. While you wait for a better answer it may be worth trying out IDUtils (which if I recall Ludo recommended during a Guix blogpost). ``` An ID database is a binary file containing a list of file names, a list of tokens, and a sparse matrix indicating which tokens appear in which files. With this database and some tools to query it (described in this manual), many text-searching tasks become simpler and faster. For example, you can list all files that reference a particular #include file throughout a huge source hierarchy, search for all the memos containing references to a project, or automatically invoke an editor on all files containing references to some function or variable. Anyone with a large software project to maintain, or a large set of text files to organize, can benefit from the ID utilities. ``` https://www.gnu.org/software/idutils/manual/idutils.html As such, even if it is not a complete solution it could allow you to identify or exclude things in advance of a more complete or bespoke solutions. Happy hacking! -- Jonathan McHugh indieterminacy@libre.brussels
Building Bootloader Images for Owner-Controlled Computers
I noticed this recommendation of a Nix tool. Its not my specialism and Im only providing it for stimulation or as a conversation starter. ``` All the necessary components (coreboot, kernel, busybox-based initramfs with cryptsetup/lvm2) are stored entirely in the bootloader flash chip. This leaves no writable unencrypted media in the boot process when the flash chip's write protect pin is shorted. Ownerboot extends coreboot with a new normal/fallback mechanism. The flash chip holds two complete copies of the bootloader; only a single page (the bootblock) is shared between them. Each image can be flashed and write-protected indepedently of the other. The fallback image can be selected by /dev/watchdog, nvramtool, or physical input (front-panel button on servers, stylus eject on laptops). Because ownerboot is written in nix, it can ensure that these builds are deterministic. Ownerboot contains no binaries, and instantiates nixpkgs with config.allowNonSource=false; if you disable nix's binary substituter you are assured that all the software in your bootloader will be built from source on your local machine, all the way back to the compiler which compiles your compiler. ``` https://sr.ht/~amjoseph/ownerboot/ -- Jonathan McHugh indieterminacy@libre.brussels
Re: Packages grow, no longer fit on a
On 18-01-2023 03:41, kiasoc5 wrote: On 1/17/23 11:25, Ludovic Courtès wrote: There are slight increases of each and every package, and there are also new big dependencies being pulled in for what, from a distance, doesn’t really add functionality. Examples include libgccjit in Emacs and mozjs in polkit. In a way, that’s the “unavoidable” (?) evolution of software, and the problem extends largely beyond Guix. Still, even compared to contemporary distros, we’re doing pretty bad. Debian most likely does better, and people often cite Alpine as the distro providing the smallest packages. Do we have figures? What can we learn from them? What tradeoffs to they make? We can achieve smaller packages by splitting them more. Here is my guess of the amount of package splitting by some distros, from least to most: Slackware < Arch < Fedora < Debian < Alpine - Slackware I believe does not split anything, everything is included. - Arch splits packages on a case by case basis (QEMU for example) - Fedora typically splits packages into package X and package X-devel, where X contains development headers, but usually not more. - Debian splits packages more aggressively. For example libreoffice is split into 6 packages, 1 for each suite (draw, write, etc). And programs may be separated from their outputs (eg zstd and libzstd are split) - Alpine splits even more aggressively, they also split out man pages and shell completions. We may wish to utilize multiple package outputs to a greater extent. Some Guix packages already have bin, doc, and lib outputs. We could make it a policy to split this for all packages. I also wonder how much of the space is taken by debug output. Would making graft derivations substitutable help? https://lists.gnu.org/archive/html/help-guix/2022-10/msg00225.html I think Guix is missing a trick here. All this effort to chain everything with inputs and yet we are using conventional 'package-boxes'. Why not 'Dutch Auction' it and set a maximum amount of inheritants within one package file and then iteratively lower the threshhold (over time!) until there are noises in the guix-devel ML that this principal is being taken far. The outcome could allow more of a layers and multifaceted representation of tools and applications that give more of a distinction between lower level utilities and applications. -- Jonathan McHugh indieterminacy@libre.brussels
Re: GNU Guix 1.4.0 released
On 03-01-2023 19:42, Joshua Branson wrote: What areas does guix need more documentation? To answer that question for myself, I might say more gexp examples. Though unmatched-paren is working on a series of blog posts to dive really deep into that topic. Guix should use more em dashes in the documentation — gets coat -- Jonathan McHugh indieterminacy@libre.brussels
Re: GNU Guix 1.4.0 released
On 03-01-2023 19:42, Joshua Branson wrote: indieterminacy writes: On 03-01-2023 10:08, Ludovic Courtès wrote: Hi! Maxim Cournoyer skribis: Congrats, and yay! It's a hell of a release! :-) Let's try to make more punctual ones from now on, and also try to lower the amount of manual labor producing one incurs (by streamlining the process), as speaking for me, this was one of the reasons I kept putting it back. Definitely, let’s see how we can make the process smoother. In my experience though, a lot of the work is coordination: keeping track of what needs to be done, open bugs, calling for testing, etc. I think we should start thinking about the next release, forming a small release team, and I’ll be happy to mentor! Thanks, Ludo’. Out of curiosity, have you ever approached developing a release from the perspective of doing documentation first? For example, test driven approaches like BDD or TDD have allowed the expectations and examples to be worked out first and the the implementation built to form it. More practically, theres a recent thread concerning different approaches and priorities concerning syntaxes. Also, if during 1.5 there were articulations regarding how existing behaviour does not conform with desired behaviour then it may become easier to divide up tasks into chunks for teams or individuals to work on. With idealised documentation in place this could provide a point of motivation for developers and avoid any fatigue once the solution is in place as the /drudgery/ of explaining how things work and how they can be used had been worked out in advance. What areas does guix need more documentation? To answer that question for myself, I might say more gexp examples. Though unmatched-paren is working on a series of blog posts to dive really deep into that topic. Over the years in general (ie for whatevever in programming), I tend to find documentation examples to provide the easiest way of explaining things and this can create shortcomings as creating or maintenan FWIW, I always need multiple examples for any programming domain but this was not the point I was trying to make. (in any case I learn systems through breaking them, it tends to give me a better understanding of systems). For an idea about documenting before a project, it may be good to create diagrams, as some (like myself) are visually orientated. Not only can it be a visual assistance, it can also aid recall. In terms of a project, this may widen the talent pool and improve alignment. In any case, while I cannot comment on the tactics within the OpenBSD community I always considered it a noble thing that no improvements we put into their OS until the features were correctly documented. While OpenBSD does a pretty good job of documenting everything, I would also chime in and say that Guix does a fantastic job of translating the existing documentation into other languages. What do we have documentation in English, German, French, and significant parts in Russian and some asian languages. That's pretty stellar! Yes, indeed! Seeing this talk in Paris made it very clear how much this is being treated seriously. https://10years.guix.gnu.org/program/#let-s-translate-guix-together- Thanks for making this point. Perhaps some people from different language communities require assistance in order to build next generation Guix functionality. It may be worth lowering the cost of them articulating their needs, including which section within the documentation requires focus for a specific language. Thanks everybody with your work on 1.4.0 ! -- Jonathan McHugh indieterminacy@libre.brussels
Re: GNU Guix 1.4.0 released
On 03-01-2023 10:08, Ludovic Courtès wrote: Hi! Maxim Cournoyer skribis: Congrats, and yay! It's a hell of a release! :-) Let's try to make more punctual ones from now on, and also try to lower the amount of manual labor producing one incurs (by streamlining the process), as speaking for me, this was one of the reasons I kept putting it back. Definitely, let’s see how we can make the process smoother. In my experience though, a lot of the work is coordination: keeping track of what needs to be done, open bugs, calling for testing, etc. I think we should start thinking about the next release, forming a small release team, and I’ll be happy to mentor! Thanks, Ludo’. Out of curiosity, have you ever approached developing a release from the perspective of doing documentation first? For example, test driven approaches like BDD or TDD have allowed the expectations and examples to be worked out first and the the implementation built to form it. More practically, theres a recent thread concerning different approaches and priorities concerning syntaxes. Also, if during 1.5 there were articulations regarding how existing behaviour does not conform with desired behaviour then it may become easier to divide up tasks into chunks for teams or individuals to work on. With idealised documentation in place this could provide a point of motivation for developers and avoid any fatigue once the solution is in place as the /drudgery/ of explaining how things work and how they can be used had been worked out in advance. In any case, while I cannot comment on the tactics within the OpenBSD community I always considered it a noble thing that no improvements we put into their OS until the features were correctly documented. Thanks everybody with your work on 1.4.0 ! -- Jonathan McHugh indieterminacy@libre.brussels
Re: Stratification of GNU Guix into Independent Channels, X-mas and Guix days!
On 24-12-2022 09:37, Pjotr Prins wrote: tis like packages under a X-mas tree guix xmas add games guix xmas add tex guix xmas add paint guix xmas add payamas I just guix pulled version 1.4 out of a cracker. That will make for a happy new year Thanks all! Happy holidays everybody! Jonathan
Winding down of Fosshost
Unfortunately Fosshost is being wound down, due to organistional failings at the executive level. https://fosshost.org/ Given Fosshost's place in the ecosystem: is this something which requires mitigating at the Guix end? -- Jonathan McHugh indieterminacy@libre.brussels
Re: issue tracking in git
On 23-11-2022 15:19, Giovanni Biscuolo wrote: [...] I saw your «L'Union Qiuy Fait La Force» presentation at Ten Years of Guix [1] and I have to admit I still have to "digest" it, because I still do not understand the overall architecture (see below). As I (probably) mentioned it tha talk Qiuy is bourne from the desire to form a notation that sits between semantic and linguistic groups and is simultaneously positioned in the central position of the keyboard. Here is a mail covering some pertinent themes https://list.orgmode.org/a24dc6635138897d3fe978509be3a5cb@libre.brussels/ The problem is not to see the conception from the perspective of architectures but more in terms of a discipline or something akin to thermodynamics. In any case, I have done other talks: Classic Gemini presentation (evaluating it from the perspective of complexity - using Guix package details to demonstrate relative complexity) https://www.youtube.com/watch?v=zyTC4QWGCQg Impressionist talk detailing the tools and formats from the perspective of syntaxes https://archive.fosdem.org/2022/schedule/event/minimalsyntaxes/ I gave multiple other talks this year but they need uploading. I shall keep you informed. indieterminacy writes: [...] FWIW, Ive been working on Gemini and issue trackers in parrallel to Genenetwork. Arun did such a great job with a minimalist setup that I thought it more proper to create a bigger ladder (given the reach of all the domains which Tissue provides(. I have two main strands: Firstly, I have been combining Gemtext's terse syntax with that of the Emacs-Hyperbole format, Koutliner, as well as the "recursive-modelling-language" I have been developing Qiuy. https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_qiuynonical/ As a consequence, it has grown into something different and more complex. I need to trim this, especially as the results of some sprints but once I refactor it it shall be a lot more solid. Secondly, I have been returning to Gemtext from the perspective of Git diffs, with the idea to generate RDF perspectives one each revision per file and then use RDF calls to resolve more complex queries. RDF representations of diffs (commits?) so we can combine this knowledge with others (represented in RDF) AFAIU is great: (open) linked data for knowledge management IMHO RDF is still a little bit underestimated :-D Indeed! Qiuy should have a bright future in relation to RDF (a lot of grunt work however) Im still sophomore in this domain but Im wrapping up enough of my other things to wade into this properly. I have been liasing with somebody with regards to doing RDF activity during Guix Days 2023, Brussels (early February) - come join us! https://git.sr.ht/~indieterminacy/1q20twt_oq_parsing-commits_txr I shall be folding the logic of the first tool into the second (carefully). I need a bit more time to do this to be fully satisfied. what about gNife? https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs --8<---cut here---start->8--- gNife, an Emacs environment for high throughput issue-tracking and knowledge-management - utilising GemText, Koutliner and Qiuy --8<---cut here---end--->8--- Well spotted! Ive positioned the Icebreaker architecture to have a strong interface end (Qiuy originated from packaging my complex Vim infrastructure). It is integral to the project development but optional for users. is it still relevant or do you plan to substitute it with the tools listed above? Its a gestalt thing, just another viewpoint of the same discipline. It remains untouched given some brutal family traumas. Since switching to a modern and more secure laptop I havent had the chance to overcome some niggles. I plan to develop this over time, though I would prefer to refactor it all within Guix Home (as well as my whole setup with regards to system crafting). There are a lot of cool things which the Qiuy annotations are capable of doing when twinned with Emacs-Hyperbole - search for them in that repo for ideas. There are some other tools floating around my forge (concerning hash trees for different interpreters and rdf from the perspective of project management), its mainly in TXR, Gawk and eLisp (though I will be doing more with respect to Guile for these areas over time). Looking at the Icebreaker project descriptions: 1. https://nlnet.nl/project/Icebreaker/ 2. https://portal.mozz.us/gemini/icebreaker.space I can undertand the design principles of the tools you are developing and I'm really impressed with the completeness of this approach with knowledge management, unfortunately I miss the overall architecture and some important detalils that allows me to completely understand how to use (or try to contribute to, one day) this tools: do you plan to add some more documentation soon? The lack of documentati
Re: issue tracking in git
Hi Giovanni, On 23-11-2022 11:29, Giovanni Biscuolo wrote: please are there updates about this initiative? Yeah, issue tracker lives here: => https://issues.genenetwork.org/ The actual issues are in gemini format and can be served with a gemini server. The HTML parser+renderer is written in Guile by Arun => https://git.systemreboot.net/tissue Homepage is https://tissue.systemreboot.net/ Wow! Very interesting project, it deserves more visibility! (why did I miss its existance?!? :-O ) Any other tissue user in this mailing list? FWIW, Ive been working on Gemini and issue trackers in parrallel to Genenetwork. Arun did such a great job with a minimalist setup that I thought it more proper to create a bigger ladder (given the reach of all the domains which Tissue provides(. I have two main strands: Firstly, I have been combining Gemtext's terse syntax with that of the Emacs-Hyperbole format, Koutliner, as well as the "recursive-modelling-language" I have been developing Qiuy. https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_qiuynonical/ As a consequence, it has grown into something different and more complex. I need to trim this, especially as the results of some sprints but once I refactor it it shall be a lot more solid. Secondly, I have been returning to Gemtext from the perspective of Git diffs, with the idea to generate RDF perspectives one each revision per file and then use RDF calls to resolve more complex queries. https://git.sr.ht/~indieterminacy/1q20twt_oq_parsing-commits_txr I shall be folding the logic of the first tool into the second (carefully). I need a bit more time to do this to be fully satisfied. There are some other tools floating around my forge (concerning hash trees for different interpreters and rdf from the perspective of project management), its mainly in TXR, Gawk and eLisp (though I will be doing more with respect to Guile for these areas over time). Kind regards, -- Jonathan McHugh indieterminacy@libre.brussels
Re: Guix Goals: One Hackable Developer Tool To Rule Them All
Sorry if this comes off as facetious (because this is an interesting proposal) but hasnt Make cornered a lot of these usecases well enough? On 13-10-2022 15:56, pinoaffe wrote: Hi, I think that (if done well) this would greatly simplify my workflow in many software projects, so I think it's a good idea. In the rest of my email, I more or less assume that there is a one-to-one correspondence between software projects and guix packages, even though this is clearly not the case. I nonetheless make this assumption since it is the case (or can be made the case) for many of the software projects on which one might want to work using guix. jgart writes: The various language ecosystems have their own linters, formatters, typecheckers, repls, test runners, etc. What if Guix could manage them all? `guix lint` in a python project would run mypy. `guix lint` in a haskell project would run hlint. `guix lint` in an erlang project would run dialyzer. These would require some sort of configurability, since most languages/projects have not just one linter. Even if there's a "monopoly" there might be different settings/versions of said linter. Do you propose that such configuration is added to packages? Or should this go somewhere else? Furthermore, in many projects there are various different languages at once (e.g., a python webapp with client-side javascript and css), so it would probably be useful to mirror the build-phases approach in guix packaging. It might even be possible to set up (somewhat) sane defaults based on the build-system used by the local project. `guix fmt` in a python project would run black. `guix fmt` in a haskell project would run ormolu. `guix fmt` in a erlang project would run erlfmt. My comments regarding linters apply here as well `guix repl` in a python project would run ptpython or some other configured repl. `guix repl` in a haskell project would run ghci. `guix repl` in a erlang project would run erl. This should be fairly easy to implement, assuming that there is just one repl associated to each project one might want to use this command with. It should (imo) be possible to configure/pass arguments to the repl on a per-project basis and whenever you run `guix repl` `guix test` in a python project would run pytest or unittest. `guix test` in a haskell project would run hunit. `guix test` in a erlang project would run eunit. Should I read this as a proposal to add an extra command to build (and test) the local project's guix package, or do you propose to make this do something different? Because I'm not sure the latter would be a good idea, if there is a need to do testing in some other way than currently possible I'd think it would be more valuable (and more clean) to extend the current testing facilities to incorporate this. `guix run` in a python project could start a flask app listening on a particular port. `guix run` in a ruby project could start a puma server. `guix run` in a haskell project could run a pre-configured script or Main.hs `guix run` in a erlang project could start a cowboy server. I'm not sure how widely this may be applicable, since many projects or packages don't have just one way to run them, they may even contain several different executables or modules. The idea would be to have Guix provide a configurable CLI wrapper subcommand around all language ecosystem developer tools. In other words it's the same Guixy thesis applied to developer tooling. I think this could take the Guix developer experience to the next level. Kind regards, pinoaffe -- Jonathan McHugh indieterminacy@libre.brussels
Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic
On 12-07-2022 00:44, Joshua Branson wrote: Sorry for starting this centuries flame war, but I can't help but be more and more impressed with OpenBSD. It seems ideal for small scale servers (aka NOT large databases). It tries really hard to be secure by default and has great documentation. With OpenBSD it is easy to set up a static website (httpd) and your own email server (openSMTPD, spamd, and pf). I would argue that the average user will find OpenBSD to be easier to secure than the Linux kernel. The Hyperbola GNU/Linux team recently announced that they would ditch Linux for OpenBSD. They are using the OpenBSD kernel and the OpenBSD userland. And they are GPL-ing all of the code. It sounds like they will have to replace 20% of said code. https://www.hyperbola.info/ Though the website currently says "Donate to keep the project alive". So that's not super reassuring... Anyway, assuming that the HyperbolaBSD team accomplishes their goals, would Guix System or Guix ever be able to run on HyperbolaBSD? I know that Guix System ties itself to glibc. HyperbolaBSD does NOT use glibc and probably never will. Would it be feasible/desireable for Guix & Guix System to support a BSD kernel and alternative libc? What about other OSes? Thanks, Joshua P.S. I just recently came accross this guide for getting started with OpenBSD on servers: http://si3t.ch/ah/en/toc/ I am really impressed with how easy/awesome OpenBSD is. I recall dicussing this topic area with you last year: https://lists.gnu.org/archive/html/help-guix/2021-06/msg00080.html https://lists.gnu.org/archive/html/help-guix/2021-06/msg00082.html https://lists.gnu.org/archive/html/help-guix/2021-06/msg00083.html https://lists.gnu.org/archive/html/help-guix/2021-06/msg00084.html https://lists.gnu.org/archive/html/help-guix/2021-06/msg00085.html https://lists.gnu.org/archive/html/help-guix/2021-06/msg00086.html Im pleased that the Hyperbola community has been making strides. Hopefully I can one day have an OpenBSD kernel overseeing Guix SD. Kind regards, Jonathan McHugh
Re: how to write services
Hi Maxime, On 18-06-2022 14:23, Maxime Devos wrote: indieterminacy schreef op za 18-06-2022 om 13:53 [+0200]: Additionally, based upon a decent demonstration on LMDB, I realised that my annotation system makes it more feasible to adapt documents into LDIF database-like-files (is that the correct terminology Maxime?) - potentially turning each document into an LDAP ready database. If your asking me, I don't know. What's LDAP doing here? Isn't LDAP about authenticating users, which doesn't seem relevant to the documentation effort? If this is about databases: is the exact database format relevant, or would any do -- e.g., Guix uses SQLite in some places, will SQLite do? The prod was a little tongue in cheek, more of a nod to the thread discussing file-like aspects of computing. I have no focus on LDAP nor authentification per se (though my own annotations would be able to map some of the parameters. My understanding is that LDIF can hold keys and values and as such is capable of representing concepts (or at least pointing to them). As such I fancy a good 'ol hack. In any case I shall be experimenting and breaking things and I should be treated at this point as speculating. I have no desire for substituting existing Guix databases - though I would contend that knowledge-management has different requirements and needs than system-maangement or coding. As such different toiling and tooling is advisable. And the text above seems about databases and RDF, but there appear to be missing some things: * what's the RDF and database for? As I understand it, it's for something about documentation and terminology, but currently it's super vague. * what stuff goes in the RDF and database, and what documents are you speaking of? The Guix manual? All the package definitions, to use them as examples? The mails in the ML? Manually written things? Likewise, how is this database written or generated? * How will this RDF be used? I mean, RDF can be flexible (see e.g. Wikidata), but someone has to actually write some applications that make use of the information, otherwise the fancy RDF is useless. * How is the RDF an improvement on the TeXinfo documentation? I guess I'm missing something important here, but I prefer reading TeXinfo documentation over RDF. Greetings, Maxime. The RDF is something experimental based upon feedback from my own project. Suppose we return to Brian's (apt) analogy concerning buildings and building materials: I would hazard that there would exist chains across triples which would permeate from the concept stages of a building down to the point whereby nails are contextualised (including with regards to safety; purchasing; type; context; implementation). Guix users should be able to build and resolve without the expertise of all layers and abstractions pertinent to Guile and our community. At my end, Ive spent a considerable time creating loose annotations - which I inject everywhere. Here is an example of task orientated annotations operating within my Emacs config: https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs/tree/master/item/init.el#L138 and for policy positions: https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs/tree/master/item/init.el#L155 These annotations recurse through my entire system, for instance operating as directory prefixes for specific concerns: https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs/tree/master/item/rqr_organise https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs/tree/master/item/iq_policy My own bundle of knowledge repos can be found just from searching for '3q' references within my system. Some can be found here (I will upload some Guix repos eventually) https://git.sr.ht/~indieterminacy/?search=3q Feel free to root around for approaches I have been taking to document and plan in modern ways. Similarly, these annotations can operate literate-programming style within comments. The fact that I can operate within Emacs-Hyperbole's Koutliner (block orientated) filetype to provide hierarchy and hyperlinking keeps me in a very terse and tactile state everywhere. Currently I am able to grok my system with ease. Ive been advised that outputting the interpretation of these files into RDF would be advantageous to make use of the graph orientated and folksonomic qualities of Icebreaker's approach. FYI, I did a Fosdem talk. About 21 mins in some of the concepts coalesce into an area more pertinent with regards to RDF themes https://fosdem.org/2022/schedule/event/minimalsyntaxes/ Im hoping that RDF can mitigate some of the chaos from users personal behaviours. My work operates more akin to body-language and philology as opposed to more classical approaches to computer-programming and computer-science. I personally use my annotation system everywhere and adapt it for my own needs. I think of it like
Re: how to write services
Hello Brian, On 16-06-2022 15:09, Brian Cully via "Development of GNU Guix and the GNU System distribution." wrote: caton...@gmail.com writes: I asked for indications about the process (what magic to use in the REPL) My experience with Guix, in general, is that the REPL isn't particularly useful for any task beyond very simple testing (eg, what are the contents of ‘%base-services’). It's a shame, but I suspect it's like this because it's hard to make it more functional, and there are more important problems to work on. Even though I would much prefer to do almost all work with a REPL, I have not invested the effort into figuring it out because I don't have the time or expertise, currently. I can't fault anyone else for making similar choices. This should be covered in the cookbook I agree. The cookbook could use a lot of work. Guix's documentation suffers in the middle ranges. There's a lot of very high level overview, and all the low level bits are reasonably documented, but there's very little on how to integrate them. Personally, Im somebody who requires examples to hack off. As many as possible, to compare and contrast concepts and feed my imagination. I wish I could reach for any API to explore and extrapolate with the same ease as I do with a dictionary. Probably a cognitive failing from me getting into coding so late in life. As with many things, I rely on conversational models to wash over me, so MLs have been useful as filling gaps - though I have to be patient waiting for solutions and ideals to reveal themselves over time. The Guix mailing lists are hugely important to serve as the bridge between higher and lower level concepts. This method may not be optimal to or known by some hoping to users hoping to utilise Guix further however. Similarly, Im sure IRC/Matrix is useful, though I find the volume of the official (Matrix?) room to be like a firehose with its volume and too much to passively observe. If we were building a house, it'd be like having instructions that say: our house is made out of rooms. Then being given a bill of materials for all the different types of nails, boards, etc that can be used to build a house. There's no (or almost no) instructions for how to use those parts to build the shepherd service room, or how to connect the activation plumbing, etc. Unfortunately, those are the instructions that are most important, I think. I like the analogy. I feel that there is an information-governance issue in terms of competencies, knowledge and requirements not fully intersecting. Its not only because of the scale of the Guix community and as you mention the weaker middle layer but problems of time and perspective making it hard for specific solutions to find troubled users with minimal costs. In many respects its not only a problem of documenting and publishing - there needs to be something in place to help orchestrate connections in a way akin to pollination. Like the moribund efficacy of forums such as GitHub Issues, I do feel that the 'classic' model of SEO based search does not serve our individual or collective requirements. I have been nudged into considering RDF more proactively, it would be super if Guix related knowledge could be represented in a semantic form, as it could be that triples can serve to provide 'knowledge-corridors', which connect up aspects of the ecosystem in ways unintended by contributors. I have been keeping notes on my process of learning Guix in the hopes of starting something along these lines, but I'm not sure I'll ever have the time to get around to it; and I'm not much of a writer, besides. You are a cogent and thoughtful writer so please write more and tell people when you make progress! My own research project, Icebreaker, has focused on trying to utilise GemText and augment it with minimal syntaxes to support domains such as knowledge-management and kanban boards. GemText's minimal syntax could allow you to write your thoughts down unimpeded and can be interpreted with ease. See Genenetwork's own approach to such concepts to see how such habits can build out over time: https://github.com/genenetwork/gn-gemtext-threads Midway through my NLNet grant (once a move past a hospice related issue), Ill be integrating two interpreters covering formats (GemText and Koutliner) and my own annotation system (Qiuy). https://git.sr.ht/~indieterminacy/1q20hqh_kq_parsing_gemtext https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_glean For me, this has put me in a situation whereby I can annotate anywhere and soon I shall have a graph of resources to inspect and extrapolate. To aid others comprehension and interoperability I shall be trying to map my opaque seeming annotation syntax into RDF, hopefully something positive can come from that phase. Additionally, based upon a decent demonstration on LMDB, I realised that my annotation system makes it more feasibl
Re: Teams
FWIW, I just want to commend whoever is packaging TexLive. My last update covered March of this year - no mean feat given that it is a 3.4GB package aggregate. (sorry I cant do more direct contributions for Guix atm, looking forward to such an honour eventually) On 04-06-2022 14:07, Ricardo Wurmus wrote: Hi Guix, this is not a new idea[1]: let’s add a page to the website that lists teams and a mail alias for each of the teams. For example, the “R team” consists of people familiar with how R packaging works in Guix, e.g. Simon and myself. There would be an alias “guix-tea...@gnu.org”. People with questions about R in Guix could write an email to that alias. Mumi could also send email to guix-tea...@gnu.org to remind them about patches relating to R / Bioconductor / CRAN, etc. Maintainers could write to these teams before releases to ask if there are any obstacles to a release. As a first step I’d suggest collecting teams, setting up the email aliases, and updating the website to show the existing teams. Here’s a draft of three teams: * R team Simon Tournier Ricardo Wurmus * Java team Julien Lepiller * Rust team Efraim Flashner Aleksandr Vityazev Arun Isaac John Soo Maxim Cournoyer Nicolas Goaziou Tobias Geerinckx-Rice What do you think? -- Jonathan McHugh indieterminacy@libre.brussels
Re: GNU Mes 0.24 released
Larry Doolittle writes: > Ludovic and friends - > > On Sun, May 08, 2022 at 12:34:47AM +0200, Ludovic Courtès wrote: >> Jan Nieuwenhuizen skribis: >> > Mes has now been ported to M2-Planet and can be bootstrapped using >> > stage0-posix[0], starting from the 357-byte hex0 binary of the >> > bootstrap-seeds[1], as was promised at FOSDEM'21[2]. >> This is amazing… congrats to you & everyone involved! You made it! :-) > > +1 > >> The common objection is: “you’re building from source but you’re not >> gonna audit all that source code anyway, so why bother?” [...] >> Supply chain security is a spectrum and I think this achievement changes >> what we can expect and demand. > > I've had this conversation before, any my analogy is to the > three legs of a stool. Bootstrapped toolchains, reproducible builds, > and source-code audits. Each one is arguably useless without the others, > but taken together, you've actually accomplished something meaningful. > Maybe I should also include "cryptographically signed artifact distribution" > on that list. > > - Larry With works this sturdy then even two tool domains suffice as a fine and versatile stepladder... Great job everybody! - Jonathan
Re: Excessively energy-consuming software considered malware?
Attila Lendvai writes: > > and especially so for inflation, which is straight out a tax that > siphons the purchasing power from people who hold cash equivalents > (i.e. the poor), to the people who own assets (i.e. the > wealthy)... who are also closer to the source of new money, and > therefore spend it first on the market, when it has not yet elevated > the prices. see the Cantillon effect: > https://en.wikipedia.org/wiki/Richard_Cantillon#Monetary_theory > With respect, please dont justify philosophies of restrictive supply when writing on technichal forums predicated on ideals of non rivalrous behaviour. Otherwise, I enjoyed the post :) Jonathan
Re: Formalizing teams
Good catch! TBH, I did wonder whether the feudal eptimology of the English word may raise eyebrows. Hartmut Goebel writes: > Am 23.12.21 um 22:51 schrieb Jonathan McHugh: >> I reckon 'coterie' is more elegant a term: > > IMHO we chould not use this term. > > The German translation is "Seilschaft", "Klüngel" - both of which have > negative meaning: Working together to the benefit of the members of > the group only - ignoring common interest.
Re: Convention for new “guix style“?
I wonder if there has been any progress made by Arun Isaac with his program,
Semantically meaningful S-expression diff
https://archive.fosdem.org/2021/schedule/event/sexpressiondiff/
```
Traditional diff implementations, such as GNU Diff, treat files as a
flat list of lines. A tree-diff algorithm that can produce minimal and
semantically meaningful output is a surprisingly more difficult and
complex problem. In fact, for unordered trees, the problem is NP-hard.
```
Jonathan
Liliana Marie Prikler writes:
> Hi,
>
> Am Mittwoch, dem 22.12.2021 um 14:05 +0100 schrieb zimoun:
>> [...]
>> --8<---cut here---start->8---
>> (inputs
>> (list libx11 libiberty ;needed for objdump support
>> zlib)) ;also needed for objdump
>> support
>> --8<---cut here---end--->8---
>>
>> when the comments apply to only one line as it was:
>>
>> --8<---cut here---start->8---
>> `(("libx11" ,libx11)
>> ("libiberty" ,libiberty) ;needed for objdump
>> support
>> ("zlib" ,zlib))) ;also needed for
>> objdump support
>> --8<---cut here---end--->8---
>>
>> Other said, this looks better:
>>
>> --8<---cut here---start->8---
>> (inputs
>> (list libx11
>> libiberty ;needed for objdump support
>> zlib)) ;also needed for objdump support
>> --8<---cut here---end--->8---
>>
>> Obviously, we could come up a rule depending on comments, numbers of
>> inputs, length, etc. It was not the case with the old style when
>> nothing prevented us to do it. Because one item per line is, IMHO,
>> easier to maintain.
> For me personally, this illustrates two things. First, the weakness of
> line comments over preceding line comments ad second the verbosity of
> old input style. You could easily write
> (list libiberty zlib) ; for objdump
> in the new style, which you couldn't before. Therefore, I wouldn't
> mandate a "one line per input" restriction, as the only reason it was
> ever imposed was a historical limitation.
>
>> Consider the case,
>>
>> (inputs
>> (list bar foo1 foo2 foo3 foo3 foo4))
>>
>> then another ’baz’ inputs is added, do we end with,
>>
>> (inputs
>> (list bar foo1 foo2 foo3 foo3 foo4
>> baz))
>>
>> to minimize and ease reading the diff, or do we end with,
>>
>> (inputs
>> (list bar
>> baz
>> foo1
>> foo2
>> foo3
>> foo3
>> foo4))
>>
>> ? And the converse is also true, consider the case just above and
>> what
>> happens if foo1, foo2 and foo3 are removed.
>>
>> One item per line solves all these boring cosmetic questions.
>>
>> Therefore, I propose to always have only one item per line. To be
>> concrete, for one item:
>>
>> (inputs
>> (list foo))
>>
>> or not
>>
>> (inputs (list foo))
>>
>> And for more than one item:
>>
>> (inputs
>> (list foo
>> bar))
>>
>> This would avoid “cosmetic” changes when adding/removing inputs
>> and/or comments.
> In my personal opinion, everything else being equal, changes to
> inputs/native-inputs/propagated-inputs should (almost) always be seen
> as changes to the field, as would be documented in the ChangeLog.
>
> I think the usual scheme coding guidelines also apply well to inputs,
> e.g. inline short stuff, but don't do funky things when the lines grow
> unnecessarily long.
>
> Now I am putting aside the issue of tooling here, because I think that
> humans ought to be able to look at the diff and see that something's
> wrong and correct it, but as others point out an "I don't touch
> comments" approach would be very fine by me.
>
> Cheers
Re: Formalizing teams
Its certainly worth developing more formal clusters. It would be wise to try and make concerns and research interconnected - lest we create silos that communicate with other groups less. Jonathan McHugh Jack Hill writes: > On Wed, 22 Dec 2021, Ludovic Courtès wrote: > >> Hello Guix! >> >> I’ve been looking at our guix-patches backlog, at the great >> contributions we get but that stick there for too long, certainly >> discouraging people, and also at non-code initiatives (meetups, Guix >> Days, Outreachy, documentation, etc.) that we as a project could often >> support and encourage better, wondering how we could improve. >> >> I’ve been inspired by how the Rust folks approach these issues, in >> particular as described here: >> >> https://blog.m-ou.se/rust-is-not-a-company/ >> >> https://www.youtube.com/watch?v=T1t4zGJYUuY >>(RacketCon 2019 talk by Aaron Turon) >> >> One idea that I like is to bring structure to the group, or rather to >> make structure visible, so that newcomers know who they can talk to to >> get started on a topic, know who to ping for reviews, and so that each >> one of us can see where they fit. Rust has well-defined teams: >> >> https://www.rust-lang.org/governance >> >> Guix is nowhere near the size of the Rust community (yet!), but I can >> already picture teams and members: >> >> co-maintainers (“core team”) >> community >> infrastructure >> internationalization >> security response >> release >> Rust packaging >> R packaging >> Java packaging >> >> In Rust, teams are responsible for overseeing discussions and changes in >> their area, but also ultimately for making decisions. I think that’s >> pretty much the case with the informal teams that exist today in Guix, >> but that responsibility could be made more explicit here. They >> distinguish teams from “working groups”, where working groups work on >> actually implementing what the team decided. >> >> How about starting with a web page listing these teams, their work, >> their members, and ways to contact them? Teams would be the primary >> contact point and for things that fall into their area and would be >> responsible for channeling proposals and advancing issues in their area. >> >> What do people think? >> >> Aaron Turon nicely explains that at first sight it has a bureaucratic >> feel to it, but that in practice it does help a lot in many ways, from >> onboarding to channeling change without losing consistency. >> >> Ludo’. > > +1 from me. I think that it is natural that as we grow (yay!) we'll > need a little bit more structure. It would be wise to not overdo it > and create too many teams to start with, but I have nevertheless > brainstormed some additional teams: > > * Documentation/Communication/Cookbook Recipes > * Desktop Environments > > Best, > Jack
Re: Preservation of Guix 2021-10-22
Hi Simon, Would it be remiss to cross reference contributors to these identified scripts against Guix contributors (commits, ML messages)? With that it may be possible to email them a templated message, featuring: * The current activity and reason for outreach * The advantages of providing improvements * A polite request for them (or interested parties) to assist (whenever) possible * A reference to documentation or cookbooks to provide further context and approaches for resolving WDYT? Jonathan zimoun writes: > Hi, > > On Sat, 23 Oct 2021 at 11:55, Timothy Sample wrote: > >> Download the database (there’s a button at the bottom of the report), >> and use SQLite to run the following queries. > > Cool! Thanks. > > > If someone wants to help, > > $ wget https://ngyro.com/pog-reports/2021-10-22/pog.db > $ guix environment --ad-hoc sqlite -- sqlite3 > sqlite> .open pog.db > sqlite> > > then copy/paste that: > >> For the 376: >> >> SELECT fod_id, >> swhid, >> reference >> FROM fods >> LEFT JOIN fod_references USING (fod_id) >> WHERE NOT is_in_swh >> AND reference LIKE '(git-reference%'; > > Therefore, I start with these ones. After this query, a quick Emacs > macro to keep the URLs and then sort them to see if a pattern emerges. > Nothing flashy. For the record, I get 214 GitHub URLs and 32 GitLab > (.com) ones. I also note, among various stuff, that: > > "https://notabug.org/cwebber/guile-squee.git; > "https://notabug.org/mothacehe/guile-squee.git; > > because one is defined at (gnu packages guile-xyz) by guile-squee and > the other at (gnu packages ci) by guile-squee-dev. Then, other remark: > Julia packages are listed: > > "https://github.com/JuliaArrays/OffsetArrays.jl; > "https://github.com/JuliaArrays/StaticArrays.jl; > "https://github.com/JuliaCI/BenchmarkTools.jl; > "https://github.com/JuliaCollections/OrderedCollections.jl; > "https://github.com/JuliaData/Parsers.jl; > "https://github.com/JuliaDiff/ChainRules.jl; > "https://github.com/JuliaDiff/ChainRulesCore.jl; > "https://github.com/JuliaDiff/ChainRulesTestUtils.jl; > "https://github.com/JuliaDiff/FiniteDifferences.jl; > "https://github.com/JuliaGPU/Adapt.jl; > "https://github.com/JuliaGraphics/ColorTypes.jl; > "https://github.com/JuliaGraphics/Colors.jl; > "https://github.com/JuliaLang/Compat.jl; > "https://github.com/JuliaObjects/ConstructionBase.jl; > "https://github.com/JuliaPackaging/JLLWrappers.jl; > "https://github.com/JuliaWeb/URIs.jl; > > when I am sure to have scheduled them couple of days (weeks?) ago. > Therefore, I have not investigated yet if the archiving failed or if POG > is behind. > > Another general remark, some URLs are duplicated, for instance: > > "https://codeberg.org/dnkl/fcft; > "https://git.cbaines.net/git/guix/build-coordinator; > "https://git.code.sf.net/p/wsjt/wsjtx.git; > "https://git.code.sf.net/u/bsomervi/hamlib.git; > "https://git.elephly.net/software/mumi.git; > "https://git.mfiano.net/mfiano/golden-utils; > "https://git.sr.ht/~bzg/org-contrib; > "https://git.systemreboot.net/guile-email; > "https://git.systemreboot.net/guile-xapian; > "https://git.umaneti.net/flycheck-grammalecte/; > "https://github.com/Eloston/ungoogled-chromium; > etc. > … > > I have not checked if several packages refer to the same URL. > > > Now, the core point. Running ’save-origin’ form (guix swh) on the URLs, > I get for instance: > > https://code.divoplade.fr/mkdir-p.git accepted failed > git://pumpa.branchable.comacceptedfailed > > for some I have checked. Investigation why they fails is required. > > > Last, I failed to use TOKEN from “guix repl”. I just do: > > (use-modules (guix swh) > (srfi srfi-1)) > > (setenv "TOKEN" > "eyJhb…" > ) > > (define missings > (list >"git://pumpa.branchable.com/" > > [...] > >"https://salsa.debian.org/installer-team/debootstrap.git; >)) > > (for-each > (lambda (url) >(save-origin url)) > missings) > > but this fails. What do I miss? Does %swh-token need to be exported > and tweaked in the script? > > > Cheers, > simon
Re: Public guix offload server
Hi Arun, Researching git-shell, I noticed an example of how Less could be exploited to increase. privileges: => https://hackaday.com/2017/05/10/git-shell-bypass-less-is-more/ It suggests enabling the no-pty flag to mitigate this. I think it would be great to utilise git-shell (and I am interested in it for my own activities. Do anybody have detailed research regarding SSH access with no shell access? Kind regards, Jonathan Arun Isaac writes: > [[PGP Signed Part:Undecided]] > >>> $ export GUIX_DAEMON_SOCKET=ssh://char...@sandbox.guix.gnu.org:22 >>> $ guix build foo >> >> …requires an SSH access by ’charlie’ to sandbox.guix.gnu.org, And they >> think this access is risky. > > We could provide SSH access but no shell access. We could use some > restricted shell in the spirit of git-shell. All we need is port > forwarding through SSH, not shell access. > > [[End of PGP Signed Part]]
