Re: Guix Documentation Meetup
On Sat, Jan 08, 2022 at 11:24:35AM -0500, Matt wrote: > 2. http://excalamus.com/2021-10-06-guix-debug.html The error about "profile contains conflicting entries" is something we should improve the documentation about, for sure. I opened a tracking bug about it: https://issues.guix.gnu.org/53224 I think we can adapt some older presentations (video-recorded) about Guix, because they helped me understand the subject quite clearly when I watched them when I first learned about Guix. The manual's treatment of profiles and propagation is authoritative and correct, but it does not quite communicate the subject in a way that combines to make these error messages understandable.
Re: Guix Documentation Meetup
On Wed, 12 Jan 2022 13:41:10 -0500 Leo Famulari wrote > On Sun, Jan 09, 2022 at 04:12:57PM -0500, Matt wrote: > > I did. Maybe you missed the two blog posts I linked in the previous > > email? > > Yeah, I did miss that you intended to contribute them. > > There is another side of my advice about submitting your contributions > however you can: It's still important to try to communicate clearly. > Your message includes several paragraphs of meta-discussion before > mentioning that you have some things to contribute, rather than just a > desire to contribute in general. Based on that, both me and Ricardo did > not understand that your blog posts were potential contributions. > > Sorry if that comes across as harsh, but it's always true that > successful collaboration is helped by clear and concise communication. > > Maybe that's a good thing, maybe it's a bad thing. It's the reality in > any collaborative environment where people are busy. > > So, if you have a goal, my advice is to state it clearly and concisely. > > If you have both long-term goals (make it easier to contribute > documentation) and short-term goals (add some Cookbook recipes or wiki > pages), then you should present them separately, or else people will > only focus on one of them. > This is good advice. I will take it to heart. I see how the ways I approached things didn't set things up for success. Thank you.
Re: [bug#53166] [PATCH] website: Announce Guix days!
Pushed with Luis Felipe's patch as 413df9b96887838ba35adf2ddf73836ad9bf6189 and 3985fd27ec85e4c2bf25fc3f3f603179721e6f61, thanks! The website should be updated soon :)
Thank you for your friendship Raghav Gururajan
Hey Raghav, I appreciated your Merry Christmas text, the many packages that you have added for Guix. I've actually been a pretty happy linphone user for a while now! I truly appreciate the work that you do for Guix in the whereiseveryone community. I hope that I can find time to actually join you guys for your community stuff. Wishing you well and your friend, Joshua 143
Re: Guix Documentation Meetup
On Sun, Jan 09, 2022 at 04:12:57PM -0500, Matt wrote: > I did. Maybe you missed the two blog posts I linked in the previous email? > Yeah, I did miss that you intended to contribute them. There is another side of my advice about submitting your contributions however you can: It's still important to try to communicate clearly. Your message includes several paragraphs of meta-discussion before mentioning that you have some things to contribute, rather than just a desire to contribute in general. Based on that, both me and Ricardo did not understand that your blog posts were potential contributions. Sorry if that comes across as harsh, but it's always true that successful collaboration is helped by clear and concise communication. Maybe that's a good thing, maybe it's a bad thing. It's the reality in any collaborative environment where people are busy. So, if you have a goal, my advice is to state it clearly and concisely. If you have both long-term goals (make it easier to contribute documentation) and short-term goals (add some Cookbook recipes or wiki pages), then you should present them separately, or else people will only focus on one of them.
Re: RFC: new syntax for inline patches
On Sat, Jan 08, 2022 at 10:34:15PM +0100, Ludovic Courtès wrote:
> Hi!
>
> Ricardo Wurmus skribis:
>
> > (arguments
> > (list
> > #:phases
> > '(modify-phases %standard-phases
> > (add-after 'unpack 'i-dont-care
> > (lambda _
> > (substitute* "this-file"
> > (("^# some unique string, oh, careful! gotta \\(escape\\)
> > this\\." m)
> > (string-append m "\nI ONLY WANTED TO ADD THIS LINE!\n"
>
> [...]
>
> > There are a few reasons why we don’t use patches as often:
> >
> > 1. the source code is precious and we prefer to modify the original
> > sources as little as necessary, so that users can get the source code as
> > upstream intended with “guix build -S foo”. We patch the sources
> > primarily to get rid of bundled source code, pre-built binaries, or
> > code that encroaches on users’ freedom.
> >
> > 2. the (patches …) field uses patch files. These are annoying and
> > inflexible. They have to be added to dist_patch_DATA in gnu/local.mk,
> > and they cannot contain computed store locations. They are separate
> > from the package definition, which is inconvenient.
> >
> > 3. snippets feel like less convenient build phases. Snippets are not
> > thunked, so we can’t do some things that we would do in a build phase
> > substitution. We also can’t access %build-inputs or %outputs. (I don’t
> > know if we can use Gexps there.)
>
> I agree that #1 is overrated.
>
> As for #3, we could make ‘snippet’ thunked (a snippet can be a gexp
> already). We cannot refer to build inputs there, but that’s on purpose:
> snippets, like patches, are supposed to be architecture-independent and
> unable to insert store file names.
>
> [...]
>
> > (We have something remotely related in etc/committer.scm.in, where we
> > define a record describing a diff hunk.)
> >
> > Here’s a colour sample for the new bikeshed:
> >
> > (arguments
> > (list
> > #:patches
> > #~(patch "the-file"
> > ((line 10)
> > (+ "I ONLY WANTED TO ADD THIS LINE"))
> > ((line 3010)
> > (- "maybe that’s better")
> > (+ (string-append #$guix " is better"))
> > (+ "but what do you think?")
>
> Like Attila my first reaction was skepticism.
>
> … but thinking about it, we could have a record,
> similar to the record you mention; it would be a file-like
> object that, when lowered, would give an actual patch.
>
> So you could write:
>
> (origin
> ;; …
> (patches (list (computed-patch
> (hunk (line 10) (+ "new line") (- "old line"))
>
> The good thing is that the implementation of would be
> entirely orthogonal, separate from the package machinery.
>
> OTOH, if we do that, we might as well write the actual patch right away.
>
> I wonder how frequent the pattern we’re discussing is. I know I’ve used
> it a few times, but I wonder if it warrants sophisticated tooling.
>
> Thoughts?
I'm OK with needing to change the exact line needed if it moves (EXACTLY
line 10, not 8 or 12 or 25).
It comes up a lot when glibc headers move or split, suddenly we're
looking at the sources, trying to find somewhere to stuff in an extra
include statement. Or qt-5.11, I think we came up with 3 different ways
of dealing with the missing header over the 10 patches.
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
Re: RFC: new syntax for inline patches
On Tue, Jan 04, 2022 at 05:50:31PM +0100, Ricardo Wurmus wrote:
> Hi Guix,
>
> does this pattern look familiar to you?
>
> (arguments
> (list
> #:phases
> '(modify-phases %standard-phases
> (add-after 'unpack 'i-dont-care
> (lambda _
> (substitute* "this-file"
> (("^# some unique string, oh, careful! gotta \\(escape\\)
> this\\." m)
> (string-append m "\nI ONLY WANTED TO ADD THIS LINE!\n"
>
> This is a lot of boilerplate just to add a line to a file. I’m using
> “substitute*” but actually I don’t want to substitute anything. I just
> know that I need to add a line somewhere in “this-file”.
>
> Or maybe it’s a CMakeLists.txt file that inexplicably wants to download
> stuff? I should patch that file but it’s a multi-line change. So I’m
> trying to do the same as above with several different anchor strings to
> comment out lines.
>
> We have a lot of packages like that. And while this boilerplate pattern
> looks familiar to most of us now, it is really unclear. It is
> imperative and abuses regular expression matching when really it should
> have been a patch.
>
> There are a few reasons why we don’t use patches as often:
>
> 1. the source code is precious and we prefer to modify the original
> sources as little as necessary, so that users can get the source code as
> upstream intended with “guix build -S foo”. We patch the sources
> primarily to get rid of bundled source code, pre-built binaries, or
> code that encroaches on users’ freedom.
>
> 2. the (patches …) field uses patch files. These are annoying and
> inflexible. They have to be added to dist_patch_DATA in gnu/local.mk,
> and they cannot contain computed store locations. They are separate
> from the package definition, which is inconvenient.
It also feels wrong to add a 30 line patch, taking into account the
header bits, to make a 3 line change.
> 3. snippets feel like less convenient build phases. Snippets are not
> thunked, so we can’t do some things that we would do in a build phase
> substitution. We also can’t access %build-inputs or %outputs. (I don’t
> know if we can use Gexps there.)
I believe you can leave out the modules line and use a gexp in the
snippet (without the "'(begin" portion )
> I feel that the first point is perhaps a little overvalued. I have
> often felt annoyed that I had to manually apply all this build phase
> patching to source code obtained with “guix build -S”, but I never felt
> that source code I got from “guix build -S” was too far removed from
> upstream.
>
> It may not be possible to apply patches with computed store locations —
> because when we compute the source derivation (which is an input to the
> package derivation) we don’t yet know the outputs of the package
> derivation. But perhaps we can still agree on a more declarative way to
> express patches that are to be applied before the build starts; syntax
> that would be more declarative than a serious of brittle substitute*
> expressions that latch onto hopefully unique strings in the target
> files.
>
> (We have something remotely related in etc/committer.scm.in, where we
> define a record describing a diff hunk.)
>
> Here’s a colour sample for the new bikeshed:
>
> (arguments
> (list
> #:patches
> #~(patch "the-file"
> ((line 10)
> (+ "I ONLY WANTED TO ADD THIS LINE"))
> ((line 3010)
> (- "maybe that’s better")
> (+ (string-append #$guix " is better"))
> (+ "but what do you think?")
I have on at least one occasion stopped myself from trying to use ed (it
IS the standard editor) to apply something that SHOULD BE trivial to
change.
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
Re: using an SRFI that is not available in Guile
Attila Lendvai schreef op wo 12-01-2022 om 16:46 [+]: > dear Guixers, > > when working on the (gnu services configuration) module, i would like > to use srfi-189, which is not available in Guile > (https://srfi.schemers.org/srfi-189/srfi-189.html). > > is there any way to add it, or an already established custom for such > a situation? e.g. adding the .scm file to Guix, preferrably late in > the load order, until Guile catches up and shadows it with its own? Instead of bundling it in Guix (which would prevent Guix from being packaged in Guix, due to point 8 in (guix)Submitting Patches), how about making it a package available for anyone (not only Guix)? Have a look at the Guix packages guile-srfi-89/145/158/159/180. Basically, SRFIs can be implemented like any other module in Guile and don't have a special status in Guile (except for cond-expand and some special syntax for importing SRFI modules -- maybe in 'library', not sure where exactly). FWIW I don't think there is any need for Guile to ship an implementation for all SRFIs by itself when they can be implemented as separate libraries that can be installed with $FAVOURITE_PACKAGE_MANAGER. If at some point an implementation of the SRFI is moved into Guile, then the package definition of guile-srfi-NNN can be removed from Guix and guile-srfi-NNN can be removed from package inputs. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
Re: using an SRFI that is not available in Guile
i did a quick experiment: created the srfi/ dir in guix's root dir, downloaded the .scm file from the srfi's git repo, and added a module definition to it. it seems to work as expected. so, technically it seems to be doable. but would a patch that adds it to Guix get accepted? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Knowledge will forever govern ignorance: And a people who mean to be their own Governors, must arm themselves with the power which knowledge gives.” — James Madison (1751–1836), 'Epilogue: Securing the Republic' (1822)
using an SRFI that is not available in Guile
dear Guixers, when working on the (gnu services configuration) module, i would like to use srfi-189, which is not available in Guile (https://srfi.schemers.org/srfi-189/srfi-189.html). is there any way to add it, or an already established custom for such a situation? e.g. adding the .scm file to Guix, preferrably late in the load order, until Guile catches up and shadows it with its own? - attila PGP: 5D5F 45C7 DFCD 0A39
Re: Celebrating ten years of Guix
Hello Ludo, If it helps, feel free to use HSBXL in Belgium as a node. => hsbxl.be/ While not a spacious or plush as the Guix Days location, it has ClubMate and better ICT support. I can be onsite 24/7 whenever you need access. Jonathan McHugh indieterminacy@libre.brussels January 12, 2022 4:11 PM, "Ludovic Courtès" wrote: > Hello Guix! > > This year marks the tenth anniversary of Guix; what if we used that as a > pretext to join forces and organize “special events” throughout the > year? Obviously the Guix Days are already a great start! > > Things that come to mind: > > • Install parties. After the upcoming release, interested folks could > team up with their local GNU/Linux user groups, or with colleagues, > friends, enthusiasts to organize install parties. We could collect > those events on a web page. That’s a great way to connect people, > to debunk fears and myths, and also to get invaluable feedback that > will allow us to improve the installation process. > > • Talks. Presenting Guix to an audience who doesn’t know about it: > could be again your local GNU/Linux user group, colleagues, sysadmin > or techie conferences, scientific conferences, etc. There are many > people here who could do a great job at introducing Guix and sharing > their own experience! > > • Articles. Get an introductory article in your local GNU/Linux or > sysadmin magazine or in some on-line magazine or specialized > journal! > > • Hackathons. Organizing hackathons focused on specific topics: again > it could be local hackathons focused on getting software your > organization or friends need packaged for Guix, it could be on-line > hackathon focused on core features, Software Heritage and Disarchive > integration, scientific workflows, documentation (like the recent > meetups jgart & Julien organized!), translation, etc. > > • Sharing enthusiasm, freedom, and collective work! :-) > > Icing on the cake if Luis, Ricardo, and other artists among us come up > with some sort of a birthday logo, music, and whatnot! > > What do people think? > > Ludo’.
Re: Celebrating ten years of Guix
On 2022-01-12 17:04, Oliver Propst wrote: On 2022-01-12 15:27, Ludovic Courtès wrote: What I guess would be helpful for the community is I guess by trying to do some of the things you listed in a decently orderly manner though. Which if we make certain efforts might actually be *possible. *I have to that end created a shared etherpad here [0] which I guess we could use for now. 0 https://yopad.eu/p/Ten_years-of-Guix-celebration_ideas-365days -- kinds regards Oliver Propst https://twitter.com/Opropst
Re: Celebrating ten years of Guix
On 2022-01-12 15:27, Ludovic Courtès wrote: Hello Guix! What do people think? I think its sounds as great idea to celebrate ten of Guix by doing some or all of the activities you list Ludovic. Something that may could initiate some in opinion needed hope and enthusiasm for Guix and *GNU/Linux systems in general. Building on the great work and efforts many people have done over last ten [!] years aiming (and some degree succeeded) to from my understanding build a solid, extensible computer system centered around GNU software and the principle of freedom for computer users with a varying needs. -- Kinds regards Oliver Propst https://twitter.com/Opropst
Re: Guix wiki
On Wednesday, January 12th, 2022 at 3:51 AM, Matt wrote: > The reality is that wikis can be helpful and they can be misleading. I don't > think anyone is under the impression that they will write and maintain > themselves. > > I'm not advocating for a wiki. I'm saying, there is one currently linked to > from the homepage. What should be done with it? > > I'm willing to help maintain it. Just wanted to add that the links to the Guix group on LibrePlanet were added to the website as part of issue #47555 (https://issues.guix.gnu.org/47555). Quoting the Help page (https://guix.gnu.org/en/help/), this was/is the intended purpose of the Wiki: «The LibrePlanet Wiki provides a collaborative space for people to share additional information about the Guix project and its subprojects. It may contain help information, feature proposals, and notes about work in progress (among other things).» And, being a wiki, I would expect its contents to be like sandcastles in a sandbox. publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Return back original implementation for text-config serialization
On 2022-01-10 21:12, Liliana Marie Prikler wrote: > Am Montag, dem 10.01.2022 um 12:49 +0300 schrieb Andrew Tropin: >> [T]he whole point of escape hatch is to make it possible to reuse >> existing files directly without any manipulation on them and importer >> should demonstrate how to do it. > That'd make more sense if the importer copied bashrc to some well-known > location (e.g. ~/.config/guix/data/.bashrc) and then used that rather > than the file it wishes to replace. IIRC that was one suggested > behaviour of Guix Home in the past, but it didn't get approval because > users wouldn't typically ask for that copying to happen. If you make > it so that plain-file is used normally, but add a switch to express > things in terms of local-file instead, that'd work. > > OTOH, I do think local-file is already well-documented on its own, so > perhaps it'd only take a cookbook entry to show it in combination with > Guix Home and an explanation as to why Guix Home doesn't do that > normally while explaining all the caveats. It seems that current implementation of importer copy files to the directory provided as command line argument and after that generates a config file, which refers those files with local-file. Overall, I think that the importer is not really well-defined both in terms of purpose and implementation and maybe it will be better to hold it until it polished. >> If importer internally do some manipulation (escaping) with the >> content of the file and places the result in the string in scheme >> file, user won't be able to replicate such process easily for other >> services, which not covered by the importer. If I understood >> correctly what you meant in the first message. > Yes, the user would have to manually quote every new line of code > they're adding, but they're free to use all other file-like objects, > including local-file. Having (bashrc (local-file ".bashrc")), whether > implemented on top of slurp-file-gexp or not, is inherently dangerous, > though. > From this >> > The point I'm making is that we shouldn't swap out one bad >> > abstraction for another, but pave the road towards good >> > abstractions, e.g. G-expressions in the way the rest of Guix >> > typically uses them. >> >> Actually, for me, the original implementation looks consistent with >> how the rest of Guix treats G-expressions (uses already known >> abstraction) and only new one intoduces a new abstraction. > That's the point. The old style works just like you'd expect it to, it > becomes a problem when you try to feed it stuff like slurp-file-gexp to > work around some limitations in a way I'm not convinced makes sense. > and this, it looks like you are concerned with local-file, which can lead to the non-reproducible code, when for example the local-file refers something outside of the git repo and on another machine the same config will lead to an error? And slurp-file-gexp additionally hides it from the user by wrapping local-file. Correct me if I'm wrong. >> [I]t's already possible to achieve the same [-- merging multiple >> bashrc snippets into a single file --] with gexps/file-like in both >> new and old text-config implementations. > I find the lack of services in your example concerning, but I'll take > your word for it. In that case, using a gexp for bashrc in the typical > sense is probably the best idea, but we still need to do something with > the reliance on slurp-file-gexp. > > Cheers > >> > PS: >> It's offtopic, but when you will have time please take a look at >> https://issues.guix.gnu.org/52388. > Hahaha, it's been a month, hasn't it? There's some aesthetic > unpleasanties, so I'm not sure if I'll upstream it with slight > stylistic changes or give you some harsher feedback, but I'll try to > decide this weekend. > Yep :) Thank you, will be waiting for it!) -- Best regards, Andrew Tropin signature.asc Description: PGP signature
Celebrating ten years of Guix
Hello Guix! This year marks the tenth anniversary of Guix; what if we used that as a pretext to join forces and organize “special events” throughout the year? Obviously the Guix Days are already a great start! Things that come to mind: • Install parties. After the upcoming release, interested folks could team up with their local GNU/Linux user groups, or with colleagues, friends, enthusiasts to organize install parties. We could collect those events on a web page. That’s a great way to connect people, to debunk fears and myths, and also to get invaluable feedback that will allow us to improve the installation process. • Talks. Presenting Guix to an audience who doesn’t know about it: could be again your local GNU/Linux user group, colleagues, sysadmin or techie conferences, scientific conferences, etc. There are many people here who could do a great job at introducing Guix and sharing their own experience! • Articles. Get an introductory article in your local GNU/Linux or sysadmin magazine or in some on-line magazine or specialized journal! • Hackathons. Organizing hackathons focused on specific topics: again it could be local hackathons focused on getting software your organization or friends need packaged for Guix, it could be on-line hackathon focused on core features, Software Heritage and Disarchive integration, scientific workflows, documentation (like the recent meetups jgart & Julien organized!), translation, etc. • Sharing enthusiasm, freedom, and collective work! :-) Icing on the cake if Luis, Ricardo, and other artists among us come up with some sort of a birthday logo, music, and whatnot! What do people think? Ludo’.
Re: Guix wiki
Attila Lendvai writes: > this sounds nice, but the reality is that nowadays reviewing and > pushing commits can take weeks or even months without much feedback. i > even have a fix for git-authenticate, coupled with tests that > demonstrate a hole, and it's been open for months. i assume because of > the lack of bandwidth from people who are in position to review and/or > push it, but whatever the reason is, this is the case. > > the vision you are painting here is inspiring, but i think the Guix > community is reaching a size where such an organizational structure is > not facilitating the cooperation well enough. more and more random > people will show up, with contributions of varying levels of > quality. if it all goes through the current choke-points of the core > (people, guix-devel, etc), then they will get overwhelmed, or at least > will limit what could otherwise be achieved with more appropriate > tools/processes. You might have a point here, but I get the feeling that things are slowly changing to address it. Also, it's important to keep in mind that the sporadic contributor will always be more scrutinised. > random example: the readability of plain-text emails pouring into > guix-patches, compared to e.g. threaded, formatted, and > displayed-in-context comment threads in a tool like gitlab. I don't see how gitlab would help. Gnus, for instance, provides the formatting you mention. -- André A. Gomes "Free Thought, Free World"
Re: bug#53166: [PATCH] website: Announce Guix days!
Attached is the new version I plan to push this evening. Last call for
comments!
From b52128768525c3a563362d218af3f79b53b96155 Mon Sep 17 00:00:00 2001
From: Julien Lepiller
Date: Mon, 10 Jan 2022 18:05:05 +0100
Subject: [PATCH] website: Add conference announcement.
* website/posts/online-guix-days-2022-announcement-1.md: New file.
* website/static/blog/img/Guix-Days-online-2022.png: New file.
* website/apps/base/templates/theme.scm: Add announce banner.
---
website/apps/base/templates/theme.scm | 9 +-
.../online-guix-days-2022-announcement-1.md | 138 ++
.../static/blog/img/Guix-Days-online-2022.png | Bin 0 -> 103920 bytes
3 files changed, 146 insertions(+), 1 deletion(-)
create mode 100644 website/posts/online-guix-days-2022-announcement-1.md
create mode 100644 website/static/blog/img/Guix-Days-online-2022.png
diff --git a/website/apps/base/templates/theme.scm b/website/apps/base/templates/theme.scm
index 81815b6..3aa09ea 100644
--- a/website/apps/base/templates/theme.scm
+++ b/website/apps/base/templates/theme.scm
@@ -120,7 +120,14 @@
(body
,(navbar #:active-item active-menu-item)
- ;; NOTE: Comment this message out when it is not needed anymore.
+ ;; NOTE: Comment these messages out when they are not needed anymore.
+ (div
+ (@ (class "message-box msg-info"))
+ (p ,(G_ `("Online conference February 19-20. "
+ ,(G_ `(a
+(@ (href "/blog/2022/online-guix-days-2022-announcement-1/"))
+"Learn more"))
+ "!"
;(div
; (@ (class "message-box msg-info"))
; (p ,(G_ `("Online conference November 22nd. "
diff --git a/website/posts/online-guix-days-2022-announcement-1.md b/website/posts/online-guix-days-2022-announcement-1.md
new file mode 100644
index 000..150ad04
--- /dev/null
+++ b/website/posts/online-guix-days-2022-announcement-1.md
@@ -0,0 +1,138 @@
+title: Announcing the second online Guix Days
+date: 2022-01-12 00:00
+author: Guix Hackers
+slug: online-guix-days-2022-announcement-1
+tags: Conference, Community
+---
+
+The Guix hackers are very happy to announce the second online Guix Days
+Conference on **19 & 20 February 2022**. This conference is open to everyone
+and will be held entirely online. Want to speak? Submit your proposal!
+
+Important dates:
+
+1. **February 8**: Deadline for talks proposal.
+1. **February 12**: Deadline for releasing your pre-recorded talks.
+1. **February 14**: Release of the schedule.
+1. **February 19**: Conference day!
+1. **February 20**: Conference day!
+
+
+
+The agenda of these two days is:
+
+ - pre-recorded talks with live question and answer sessions
+ - birds of a feather (BoF) sessions
+ - lightning round talks, if possible
+ - retrospective and future of Guix
+ - hack together
+
+Talks will be released **before** the conference day, **watch them as soon
+as possible**! And: **no registration fee**.
+
+# Until February 8: talk proposals
+
+Propose your talks by sending them to `guix-d...@gnu.org`. Feel free to drop
+in `#guix` on irc.libera.chat to discuss what you would like to talk about
+before submitting. :)
+
+You can choose one of the following formats:
+
+ - Standard talk. 15-45 minutes pre-recorded presentation and a 5 minutes lightning talk.
+ The 5-minute presentation will be live, to refresh our minds, followed by
+ a 30 minutes live Q
+ - BoF (birds of a feather, for a session with a small group who wants to talk
+ about a specific topic) with no presentation. You may prepare something live
+ to spark conversations.
+ - Lightning talk with a 5 minutes live presentation
+
+In addition to the format you would like to choose, please describe your session
+with 10 lines or more (for lightning talks, at least 1 sentence).
+
+Once you have sent your proposal, you will be notified in the coming days
+whether your talk be part of the Guix Day. Submit earlier to get more time to
+prepare your session!
+
+Even for live presentation, please prepare a back-up pre-recorded talk, so
+we can play it if you cannot attend or have a technical problem during the
+Guix days. The deadline for short presentations (5 minutes) is February 16.
+
+We welcome all kinds of topics from the community, especially your own experience
+with Guix, your cool projects that involve Guix in some way, infrastructure around
+guix (translations, continuous integration, ...), and any subject you feel
+should be discussed during the conference.
+
+We particularly encourage people who consider themselves part of a group
+underrepresented in Guix and the broader free software movement to submit
+a talk. Do not hesitate to get in touch with the organizers at `guix-d...@gnu.org`
+if unsure or if you would like guidance on how to prepare your talk.
+
+Please make sure your talk is accessible to a non-expert audience, for instance
+by
Re: bug#53166: [PATCH] website: Announce Guix days!
Great, I added all of that, thanks! Le 12 janvier 2022 12:58:03 GMT+01:00, "Ludovic Courtès" a écrit : >Hi again! > >Julien Lepiller skribis: > >> +# Until February 8: talks proposal >> + >> +Propose your talks by sending them to `guix-d...@gnu.org`. Feel free to >> drop >> +in `#guix` on irc.freenode.net to discuss what you would like to talk about > >Should be irc.libera.chat. > >A couple of ideas occurred to me while biking this morning: > >> +We welcome all kinds of topics from the community, especially your own >> experience >> +with Guix, your cool projects that involve Guix in some way, infrastructure >> around >> +guix (translations, continuous integration, ...), and any subject you feel >> +should be discussed during the conference. > >What about adding something like: > > We particularly encourage people who consider themselves part of a > group underrepresented in Guix and the broader free software movement > to submit a talk; do not hesitate to get in touch with the organizers > at `guix-d...@gnu.org` if unsure or if you would like guidance on how > to prepare your talk. > > Please make sure your talk is accessible to a non-expert audience, for > instance by explaining the general context before diving into > technical descriptions, and by avoiding acronyms and jargon. > >? > >After the first sentence above, I also thought about that one: > > We accept talks in languages other than English provided English > subtitles are included. > >Thoughts? > >Ludo’.
Re: bug#53166: [PATCH] website: Announce Guix days!
Hi again! Julien Lepiller skribis: > +# Until February 8: talks proposal > + > +Propose your talks by sending them to `guix-d...@gnu.org`. Feel free to drop > +in `#guix` on irc.freenode.net to discuss what you would like to talk about Should be irc.libera.chat. A couple of ideas occurred to me while biking this morning: > +We welcome all kinds of topics from the community, especially your own > experience > +with Guix, your cool projects that involve Guix in some way, infrastructure > around > +guix (translations, continuous integration, ...), and any subject you feel > +should be discussed during the conference. What about adding something like: We particularly encourage people who consider themselves part of a group underrepresented in Guix and the broader free software movement to submit a talk; do not hesitate to get in touch with the organizers at `guix-d...@gnu.org` if unsure or if you would like guidance on how to prepare your talk. Please make sure your talk is accessible to a non-expert audience, for instance by explaining the general context before diving into technical descriptions, and by avoiding acronyms and jargon. ? After the first sentence above, I also thought about that one: We accept talks in languages other than English provided English subtitles are included. Thoughts? Ludo’.
Re: Guix wiki
Attila Lendvai writes: > random example: the readability of plain-text emails pouring into > guix-patches, compared to e.g. threaded, formatted, and > displayed-in-context comment threads in a tool like gitlab. > > i subscribed to guix-patches for a while, but it felt like noise. I’m not subscribed to guix-patches. Are you aware of https://issues.guix.gnu.org? -- Ricardo
Re: Guix wiki
what follows is some 0.02 from someone relatively new to Guix. > > sending a patch to the manual is a way higher threshold than editing a > > wiki, especially when it's someone's first contribution. and some > > random, half-baked copy-paste doesn't belong in the manual, while it > > may be very useful when found in a wiki using the search engine. > > This is where we disagree. I’ve wasted so much time in my life > following outdated or wrong instructions on forums or wikis. I really > don’t want to see anything half-baked anywhere near this project. There > are few things that frustrate me more than well-meaning but misleading > advice. sure, this is a matter of taste. although, it's one thing to get misguided with 1) informal instructions, and another with 2) formal ones (i.e. a snippet of runnable code that emits useful errors and backtraces when things go wrong). an obsolete instance of 2) can still be useful when all it needs is just a small change to follow some renames. ad-hoc example: a package definition demonstrates a complex technique, but otherwise uses the obsolete pre-c-u-f merge input syntax, for which the runtime warns/errors. > I keep repeating myself: you don’t need to use debbugs. We do. Nor do this is true to some extent when sending a one-shot patch to the docs. but when i'm sending patchsets to the codebase, i do need to learn at least the basics of debbugs. sorry for broadening the scope here, but these are related. > Before Guix I had never used Debbugs. I rarely ever contributed > patches. I had no idea how to send patches via email. There was a time > when I didn’t know that patches are generated with tools. my point is that i know all these, and have been practicing them for decades, and yet, contributing to Guix required a learning curve that was higher than it's regularly expressed by people who are already used to it. i do understand and accept the reasons (freedom, bootstrappability, independence, etc), but i think the tools/infrastructure that Guix uses for coordination is not very familiar to most programmers. > No aspiring contributor needs to be fully formed before they are > permitted to contribute. Get yourself a mentor within the project who > can shepherd your contributions and make sure they find their way into > the right files. Ping them if your contribution seems to have been > forgotten. > > In my opinion, a public list of mentors that you can ask to charge of > your contribution would be worth more than a mere info dumping site. this sounds nice, but the reality is that nowadays reviewing and pushing commits can take weeks or even months without much feedback. i even have a fix for git-authenticate, coupled with tests that demonstrate a hole, and it's been open for months. i assume because of the lack of bandwidth from people who are in position to review and/or push it, but whatever the reason is, this is the case. the vision you are painting here is inspiring, but i think the Guix community is reaching a size where such an organizational structure is not facilitating the cooperation well enough. more and more random people will show up, with contributions of varying levels of quality. if it all goes through the current choke-points of the core (people, guix-devel, etc), then they will get overwhelmed, or at least will limit what could otherwise be achieved with more appropriate tools/processes. random example: the readability of plain-text emails pouring into guix-patches, compared to e.g. threaded, formatted, and displayed-in-context comment threads in a tool like gitlab. i subscribed to guix-patches for a while, but it felt like noise. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Birds born in a cage think flying is an illness.” — Alejandro Jodorowsky
Re: Parallel guix builds can trample?
Hi - more details below.
Ricardo Wurmus writes:
>
> How are you using Guix with this? Do you generate Guix package
> expressions? Do you use “guix build --with-commit”?
>
The situation is like this - if we had a directory of clones of my
channel:
- pr-1
- pr-2
- pr-3
- pr-4
... and so on
Initially all the clones are taken from the master branch of my
channel and are all identical - but we change the version and commit to
match the head of each PR branch as per below.
Each clone looks like this:
- pr-1
- my-package.scm
- pr-2
- my-package.scm
and so on
Each my-package.scm has a package like below - the inital packages are all
identical, but my system effectively seds the version and commit values
like the below. These values are never committed back to master they
are used only as local channels to build each PR to test each build
still passes.
(define-public my-package
(package
(name "my-package")
(version "this-is-different-for-each-pr") ;; replace master version
(source
(git-checkout
(url "ssh://same@repo:7999/same/repo.git")
(commit "this-is-different-for-each-pr") ;; replace master version
everything else remains the same in the package
At this point we have lots of local channels referencing different commits, in
the same package, ready to build - so I spawn them all simultaneously -
the equivalent pseudo-shell that I will mock up today would be:
# define some sort of return code array:
RC=[]
for dir in pr-dirs
RC[${dir}]=`guix build -K -L ${dir} my-package & 2>&1 > /tmp/${dir}.log` #
note the ampersand
wait
for rc in $RC
if $rc.value != 0:
report the failure of build $rc.key
What I'm seeing occasionally is that the logs and return code for say directory
pr-1
and appearing in the guix build for pr-3 or pr-6 instead.
We know this becuse the code is different enough in pr-1 that it's logs
are unique across all the PRs. We can also check the source code if the
build fails using --keep-failed to show it doesn't match the commit id
in the package used to build it.
Hopefully that makes sense? I can post the actual shell script once
I've written the mock.
Re: Guix wiki
Matt writes: > My guess, as Guix is a package manager, there are two audiences: > package users (end users) and package maintainers. I'm curious what > degree of separation between those should exist for Guix. On of the goals of the GNU project is to give users the tools to liberate themselves from arbitrary restrictions. The Hurd pretty much does away with the concept of an all-powerful root user as the only privileged account to alter settings such as network, file system virtualization, drivers, etc. Emacs is designed to be a collection of extensions. Guile was designed to be the extension language for every part of the GNU system that was still constrained by the dead systems programming language C. Likewise, Guix aims to give “end users” control over their software environments and systems, privileges that used to be reserved for the sysadmin class. All design decisions in Guix are aimed at extending privileges to users: package transformations, package inheritance, building packages from JSON descriptions for those averse to Scheme, per-user channels, time machine, an extensive API to build and export systems, virtual machines, containers, environments, etc. We don’t like to erect arbitrary boundaries between “end users” and maintainers. The concept of “maintainer” only ever has meaning in the context of project management. (Unlike nixpkgs, for example, we don’t record package maintainers with package definitions.) So, ideally, the information in the manual / cookbook will benefit all users, no matter how deep they want to dive. A single document cannot accomplish this, which is why we recognize the existence of other GNU manuals and link to them where possible. -- Ricardo
Re: Guix wiki
zimoun writes: > Hi Tobias, > > On Wed, 12 Jan 2022 at 03:20, Tobias Geerinckx-Rice wrote: > >> I'm disappointed by the ‘bikeshedding’ insult. I really don't >> care what you call it. > > 'insult' is a strong word and I am somehow hurt that you give me this > intention. I do not know what I did wrong --since we both agree we do > not care about the name-- but apparently my contributions to these > email lists lead to misunderstandings -- probably because my English > is not good enough. Therefore, I take a step back and some distance > with this thread and many others. > > >> > - cathedral, as it is today >> >> I object to redefining loaded terms to promote it. > > ..and I already agreed that it was probably a wrong choice. It seems that you're both are on the same page, and got too "excited" about the wording. Please don't draw more importance than it deserves. Simon, I'm sure everyone is eager to listen to your insights. -- André A. Gomes "Free Thought, Free World"
Re: Planet of Guix-related posts?
As someone how cares deeply about Guix I can state I think that the Cookbook is a great resource. I feels like the Cookbook have a clear focus on quality documentation and has to life only as a result of lots hard work and love for the Guix project. That said even as a technical person I do must admit that find some segment and concepts in the cookbook as hard to read and understand (especially from the the perspective of a non-technical person). So guess a relevant question could be how do we make the Guix documentation easier to understand for everybody and how do we improve the explanations of the current segments in the Cookbook. -- Kinds regards Oliver Propst https://twitter.com/Opropst
Re: Guix wiki
Hi Tobias, On Wed, 12 Jan 2022 at 03:20, Tobias Geerinckx-Rice wrote: > I'm disappointed by the ‘bikeshedding’ insult. I really don't > care what you call it. 'insult' is a strong word and I am somehow hurt that you give me this intention. I do not know what I did wrong --since we both agree we do not care about the name-- but apparently my contributions to these email lists lead to misunderstandings -- probably because my English is not good enough. Therefore, I take a step back and some distance with this thread and many others. > > - cathedral, as it is today > > I object to redefining loaded terms to promote it. ..and I already agreed that it was probably a wrong choice. Best regards, simon
Re: Planet of Guix-related posts?
Matt writes: > What problem is the cookbook trying to > solve? Once that's clear, we can make judgements about whether it > accomplishes that goal. The idea of a cookbook arose from dissatisfaction with the manual. The manual had few examples, and as a reference style document it was considered to be the wrong place for long excursions, tutorials, and detailed examples. I started the cookbook by adapting some popular blog posts. The idea was that it could be home to hands-on tutorials, motivated examples, hints and tricks, etc that would be out of place in the manual. This is not set in stone, and it was always the intention to let the cookbook become whatever contributors made of it. It was only always meant to enhance and supplement the manual. -- Ricardo
Re: Planet of Guix-related posts?
Matt writes: > On Mon, 10 Jan 2022 10:21:51 -0500 zimoun > wrote > > > (On a side note between parenthesis, we should avoid to fall into the > > "Package Definition" tutorial fallacy; as explained here for monads > > > https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/. > > And I wrote one post about monad and another about Packaging. ;-) > > However, I think the official documentation has enough materials for > > starting to package. End of parenthesis.) > > If many people feel inclined to write their own packaging tutorial, > it's probably an indication that the manual isn't sufficient. The experience with monad tutorial suggests that people write them because they learned something new and want to put their understanding into words in the hopes that other people benefit from it. There is an overabundance of monad tutorials out there. This is not evidence of the claim that existing explanations are somehow flawed. -- Ricardo
Re: Parallel guix builds can trample?
Philip Beadling writes: > The source in each one will be slightly different and although I only > specify commit id in the package How are you using Guix with this? Do you generate Guix package expressions? Do you use “guix build --with-commit”? If the hash in the “source” field corresponds to source code in the store then it doesn’t matter what the commit id or version string says. The hash identifies the source. -- Ricardo
