Re: Identical files across subsequent package revisions
Hi Julien and Simon, Julien Lepiller writes: > Le 23 décembre 2020 09:07:23 GMT-05:00, zimoun a > écrit : >>Hi, >> >>On Wed, 23 Dec 2020 at 14:10, Miguel Ángel Arruga Vivas >> wrote: >>> Another idea that might fit well into that kind of protocol---with >>> harder impact on the design, and probably with a high cost on the >>> runtime---would be the "upgrade" of the deduplication process towards >>a >>> content-based file system as git does[2]. This way the a description >>of >>> the nar contents (size, hash) could trigger the retrieval only of the >>> needed files not found in the current store. >> >>Is it not related to Content-Addressed Store? i.e, «intensional >>model»? >> >>Chap. 6: <https://edolstra.github.io/pubs/phd-thesis.pdf> >>Nix FRC: >><https://github.com/tweag/rfcs/blob/cas-rfc/rfcs/0062-content-addressed-paths.md> > > I think this is different, because we're talking about sub-element > content-addressing. The intensional model is about content-addressing > whole store elements. I think the idea would be to save individual > files in, say, /gnu/store/.links, and let nar or narinfo files > describe the files to retrieve. If we are missing some, we'd download > them, then create hardlinks. This could even help our deduplication I > think :) Exactly. My first approach would be a tree %links-prefix/hash/size, to where all the internal contents of each store item would be hard linked: mainly Git's approach with some touch here and there---some of them probably have too much good will, the first approach isn't usually the best. :-) - The garbage collection process could check if there is any hard link to those files or remove them otherwise, deleting the hash folder when needed. - The deduplication process could be in charge of moving the files and placing hard links instead, but hash collisions with the same size are always a possibility, therefore some mechanism is needed to treat these cases[1] and the vulnerabilities associated to them. - The substitution process could retrieve from the server the information about the needed files, check which contents are already available and which ones must be retrieved, and ensure that the "generated nar" is the same as the one from the server. This is quite related to the deduplication process and the mechanism used there[2]. Happy hacking! Miguel [1] Perhaps the usage of two different hash algorithms instead of one, or different salts, could be enough for the "common" error case as a collision on both cases are quite improbable. They are possible anyway with a size bigger than the hash size, therefore a final fallback to actual bytes is probably needed. [2] The folder could be hashed, even with a temporary salt agreed with the server, to perform an independent/real-time check, but any issue here has bigger consequences too, as no byte to byte comparison is possible before the actual transmission.
Re: Identical files across subsequent package revisions
Hi Ludo, Just one interjection: wow! :-) Ludovic Courtès writes: > Hello Guix! > > Every time a package changes, we end up downloading complete substitutes > for itself and for all its dependents, even though we have the intuition > that a large fraction of the files in those store items are unchanged. It's great you're taking a look into these kind of optimizations, as they also close the gap between only-binary distribution and the substitutes system. > [Awesome data collection omitted for brevity] > > Thoughts? :-) Probably you're already aware of it, but I want to mention that Tridgell's thesis[1] contains a very neat approach to this problem. A naive prototype would be copying of the latest available nar of the package on the client side and using it as the destination for a copy using rsync. Either the protocol used by the rsync application, or a protocol based on those ideas, could be implemented over the HTTP layer; client and server implementation and cooperation would be needed though. Another idea that might fit well into that kind of protocol---with harder impact on the design, and probably with a high cost on the runtime---would be the "upgrade" of the deduplication process towards a content-based file system as git does[2]. This way the a description of the nar contents (size, hash) could trigger the retrieval only of the needed files not found in the current store. Nonetheless, these are only thoughts, I'll ping back if and when I have something more tangible. ;-) Happy hacking! Miguel [1] https://rsync.samba.org/~tridge/phd_thesis.pdf [2] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
Re: Word order in Guix l10n
Hi Julien, Julien Lepiller writes: > This specific syntax looks ok, but we need to limit ourself to the > common syntax between guile and lisp, because that's what gettext > supports. The issue with Guile's format is explained here[1], as the used implementation follows SRFI-28[2], but there are no difference between the format from Common Lisp and the one from (ice-9 format)[3] on the surface level: both implementations are compatible regarding numeric, iteration, selection and jump directives, to name a few. Other directives might be compatible, such as the plural directive ~P, or not, although most of them shouldn't be used in any case: not because they could have compatibility problems but because they don't fit into internationalized messages correctly. For example, most languages have irregular cases for plural formation, some have more than two grammatical numeric cases, such as singular/dual/plural, and some don't have an equivalent category, such as Japanese. That's exactly use case of ngettext---I've pointed out on the other mail the pending issue on that area, which is related to the omission of the numeric parameter but not its order, and applies both to Common Lisp and (ice-9 format). > We should use this kind of syntax everywhere we have more than one > argument. I don't see the advantage of using everywhere jumps on the msgids. Nonetheless, a TRANSLATORS: comment placed on the first string appearing on the POT file, pointing the section of the manual for (ice-9 format), or even an explicit and detailed explanation of this syntax could be very helpful for translators. The attached patch does this, although any suggestion or even a complete rewrite is welcome, because I don't feel it quite inspired. > Also thinking about rtl languages, it's probably important > for them, though I'm not sure how gettext works for them. gettext-family functions only see byte arrays and provide the corresponding array, the bytes are always placed in increasing memory locations. Right-to-left handling is a responsibility of visualization layer, which sometimes includes the final format, but that is an issue even with left-to-right languages as French. For example, this composition... (string-append translated ": " other-translated) ... produces weird results, or convoluted French translations, because it isn't handled properly. A format string must be used here too, because it must include the white-space expected in French before the colon: (format #f (_ "~a: ~a") translated other-translated) Newlines are the only ones that are omitted sometimes from the internationalized composition because the convention up-to-down is followed, but this is a limitation of the teletype/terminal interface though; graphic interfaces aren't composed with this limitation and "whole widgets" should be the localization frame, which usually is the case. Happy hacking! Miguel [1] https://www.gnu.org/software/guile/manual/html_node/Simple-Output.html [2] https://www.gnu.org/software/guile/manual/html_node/SRFI_002d28.html [3] https://www.gnu.org/software/guile/manual/html_node/Formatted-Output.html >From 2615934a2c377858dce2a0410982287faed754a9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?= Date: Wed, 23 Dec 2020 13:07:38 +0100 Subject: [PATCH] nls: Add comment about format directives. * gnu.scm (%try-use-modules): Add comment for translations. It should be placed on the first string found by xgettext. --- gnu.scm | 13 + 1 file changed, 13 insertions(+) diff --git a/gnu.scm b/gnu.scm index f139531ef3..0e87b10eb2 100644 --- a/gnu.scm +++ b/gnu.scm @@ -78,6 +78,19 @@ (raise (apply make-compound-condition +;; TRANSLATORS: The scheme-format tag is used to identify +;; strings that contain format directives as specified +;; here: +;; https://www.gnu.org/software/guile/manual/html_node/Formatted-Output.html +;; +;; The goto/jump directive can be used to alter the order +;; of the arguments, either performing relative jumps with +;; ~N* and ~N:* (forward and backwards respectively) or +;; the absolute position of the argument can be used +;; (starting from 0) with ~N@*. When N isn't provided, +;; it's understood to be 1 on the relative jumps (next and +;; previous argument respectively) and 0 on the absolute +;; jumps (first argument). (formatted-message (G_ "module ~a not found") module) (condition -- 2.29.2
Re: Word order in Guix l10n
Hi Ludo, Ludovic Courtès writes: > With (ice-9 format), as has been suggested before, we should be able to > do away with the “argument jumping” syntax (info "(guile) Formatted > Output"): > > (format #f "~1@*~d Zeichen lang ist die Zeichenkette `~0@*~a'" "ab" 2) > > It’s a bit awkward though, in particular because we have to jump to the > previous argument (0 and 1 here instead of 1 and 2). I wouldn't think of absolute goto directive jumping to the previous argument, it's just another chapter of the eternal debate regarding the first ordinal: Common Lisp/SLIB/ice-9 use the '0' convention for the 'first' position---the smallest element from the set of natural numbers---, instead of '1'. C-style arrays can be interpreted like this too. > Does xgettext support that syntax? We’ve had troubles before with ~*. These troubles are related to plural forms[1]. Singular forms don't have any issue because the type and number of format specifiers must match always. > If it does, where should we use this syntax in lieu of the simpler > forms? Everywhere? Yup, for singular forms (non-ngettext) it can be used everywhere right now. The translation of plural forms could, at most, omit one numeric directive (the one used for the ngettext call) to allow a more natural way of expressing implicitly the numeral, but this will need to wait for the next release of GNU gettext---the patch is almost there[2]. Nonetheless, the current version of msgfmt works correctly when no format directive is omitted. Happy hacking! Miguel [1] https://lists.gnu.org/archive/html/bug-gettext/2020-11/msg00027.html [2] https://lists.gnu.org/archive/html/bug-gettext/2020-12/msg00041.html
Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals
Hello Maxim, Maxim Cournoyer writes: > Hello Miguel, > > Miguel Ángel Arruga Vivas writes: > >> Hi! >> >> Christopher Lemmer Webber writes: >> [...] >>> It sounds like you're already putting together the work to do it. If >>> you don't mind doing it that would save me a lot of time right >>> now... I'm quite swamped! I'd be very grateful! >> >> No problem, I just didn't want to end up with two reports for the same >> issue. It's already open as <https://bugs.gnu.org/44698>. > > Woo! That was quick! Well, I wouldn't call it quick, as I wanted to pin-point at least the issue, but it took me a long time to even trim the reproducer. Christopher mail really was a heads up to at least report the bug to Emacs people. > I've tested the repro script and could reproduce for the first time (the > steps must be followed scrupulously otherwise just changing buffer can > cause the bad behavior to disappear)! Thank you for the confirmation. > Thank you for the efficiency with which you handled the issue, it's much > appreciated. You're welcome. Nonetheless, I wish I already had a solution... :-( Happy hacking! Miguel
Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals
Hi! Christopher Lemmer Webber writes: [...] > It sounds like you're already putting together the work to do it. If > you don't mind doing it that would save me a lot of time right > now... I'm quite swamped! I'd be very grateful! No problem, I just didn't want to end up with two reports for the same issue. It's already open as <https://bugs.gnu.org/44698>. >>[...] > I've pushed the fix to master. I also did the setq-local thing as > another commit. Thanks. > However, since Miguel is the one submitting the upstream report, I left > a TODO item to link to that once done. Miguel, do you mind committing > that once done? Pushed the update for the TODO line to master as 3428c66c5a4d5f1a5fd2f1ad4cd3105993ae8e6d. Happy hacking! Miguel signature.asc Description: PGP signature
Re: GNU Guix 1.2.0rc1 available for testing!
Hi, I didn't update my mail so often and you've already solved it... Sorry for the noise and thank you for the patch. :-) Happy hacking! Miguel
Re: GNU Guix 1.2.0rc1 available for testing!
Hallo, Leute! "pelzflorian (Florian Pelz)" writes: > On Sun, Nov 15, 2020 at 10:53:29PM +0100, Marius Bakke wrote: >> I have just installed a system using manual partitioning through the >> installer, with encryption. Everything worked like a charm. [...] > Maybe it depends on how fast the machine completes a formatting task? > So I tried again two more times and it failed again, I got the error > again both times during partition formatting. [...] > I assume some formatting step had not completed in time. >From your log, the format didn't even took place, as it is the following step from run-partitioning-page (at gnu/installer/newt/partition.scm), but it was writing the partitions to the disk. I think this comment from free-parted (at gnu/installer/parted.scm) tells the same problem you're hitting: --8<-- ;; XXX: Formatting and further operations on disk partition table may fail ;; because the partition table changes are not synced, or because the device ;; is still in use, even if parted should have finished editing ;; partitions. This is not well understood, but syncing devices and waiting ;; them to stop returning EBUSY to BLKRRPART ioctl seems to be enough. The ;; same kind of issue is described here: ;; https://mail.gnome.org/archives/commits-list/2013-March/msg18423.html. -->8-- Nonetheless, we're only waiting 1 second + processing time to timeout the lookup for EBUSY at 'with-delay-device-in-use?'. Should we extend that timeout? I don't think waiting even minutes at this stage would be a big issue, as formatting an encrypted partition may take hours and will be performed just after that. WDYT? Happy hacking! Miguel
Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals
Hi Maxim and Christopher, Maxim Cournoyer writes: >[...] > Christopher Lemmer Webber writes: > [...] >> I figured out what was happening! The bug is *technically* in vc-mode. >> However, nontheless it manifested here... >> >> Here's what happened. vc-mode has some various hacks, as you can see >> above with "hack-local-variables-apply"... which traverses the dirlocals >> stuff. (Not sure what the purpose is, didn't look too long.) The file where these functions are located is lisp/files.el, right on the Emacs core. Some modes add hooks there, like flyspell or cc, but not vc, so I don't really think the problem is exclusive from that mode after some debugging. This code ends up in file-local-variables-alist, even though dir-local-variables-alist contains the correct values for some reason I still don't really understand. >> However for whatever reason, vc-mode also seems to be reusing buffers >> such as `*vc-diff*'... and somehow still is left in the directory >> context it *first* was used in. This may be the culprit but I think it isn't the issue, as file-local-variables-alist accumulates every eval marked as nil, not only the first/last one... when it fails, as we've seen. >> Thus if I C-x v = in a guix-oriented buffer first, and then switch to >> another completely different project and do the same, it's loading the >> dirlocals from Guix(...) >> >> This is clearly a bug in vc-mode, I'll try to report it as such. > Thank you for the investigation. I'd be really happy if you could > report the problem upstream (M-x report-emacs-bug) aznd link to it here! I haven't reported it yet, but as you can see I have a reproducer script attached. I haven't seen anything in vc-code that points in that direction, surely though Emacs people will have a better understanding. Christopher, would you mind to CC me if you open the bug? I can do it too if you tell me to, but I don't want to create a duplicate entry if we do it roughly at the same time. > [..] Miguel had written in IRC at the time of the initial report, but > to no avail. Maxim, could you test the script to check if we can narrow the cases? It shows the README in the emacs it opens, so it should be straight-forward. >> In the meanwhile, I used this hacky "fix". Maybe worth applying for the >> moment... what do you think of it? > > I'd like to have the upstream bug linked in that fix rather than the > Guix one; that way it'll be possible to track upstream resolution and > know when the workaround can be removed. Apart from the tracking reference, I agree that it's worth applying it. And also, thank you both for making easier to work on guix. :-) Happy hacking! Miguel reproducer.sh Description: reproducer
Re: Fixing Zabbix db-secret-file documentation.
Hi! Tobias Geerinckx-Rice writes: > Miguel, > > Thank you, and everyone else, for all your translation efforts. I've > translated before. It's ruddy hard work. You're welcome, and thank you too: we had nothing to translate if nobody pushed changes to make Guix even more awesome than it currently is. :-) > Miguel Ángel Arruga Vivas 写道： >> Tobias Geerinckx-Rice writes: >> Just for the record, I'm glad to translate that change or whatever >> comes >> next, but it makes me a bit sad when that effort is reduced to a >> number, > > I'm not reducing your effort to a number, quite the opposite: I meant > that keeping the old wording ‘just because it's already been > translated’ would be doing so. No problem, I understood, but my point really was that it isn't a problem because "it's already been translated" but because "it triggers again a procedure which was already taking place". > Nobody actually suggested that, and I'm very happy that you're both > willing and able to translate new strings so late. I wasn't expecting > that. I try to maintain the translation up to date, as I'd like to keep "info guix.es" as close as possible to a fully translated "info guix" (quite hard to do though, and not really an option with our current flow), so for me it actually means just one change in my working PO file, but that isn't usually the case for everybody. > Let me know what needs to happen if there's still time! I guess that pushing another tarball to TP isn't the path we're going to take as I feel it will cause more friction on that side, but surely we could do it, even only sending one for the manual is a possibility there. On the other hand, removing that phrase is an editorial change that perhaps could be done at project level instead of at TP: querying the translators directly how to remove the old bits from their translation may be an option for this. The last option (that I don't like neither, but it isn't on my hand to take a final decision) is to keep the release as it is: it wouldn't affect the manual shown by the installation, but it'll be lost as soon as a pull is performed. WDYT? Happy hacking! Miguel signature.asc Description: PGP signature
Re: Fixing Zabbix db-secret-file documentation.
Hi! Tobias Geerinckx-Rice writes: > I've changed it to front-end just for consistency... for now ;-) and > pushed to master as 83dee0e5b29dee75cffd5aa2a7748697eb73b036. If > nobody objects I'll cherry-pick it to version-1.2.0 before the > release. That'll be the on-line manual for some time to come. I have to raise my hand here, as TP.org hasn't updated their page yet, or at least I haven't received the email yet, but the tarball was already sent. Perhaps we're lucky and the first mail may end in /dev/null with no fuss if we send the update soon Julien, WDYT? Just for the record, I'm glad to translate that change or whatever comes next, but it makes me a bit sad when that effort is reduced to a number, because that "number" means making accessible the documentation to people who don't speak English. I understand what you meant, and I agree about the change too; I just wanted to clarify that it isn't a matter of boosting stats but working together. Happy hacking! Miguel signature.asc Description: PGP signature
Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals
gt;>now my vc-diff is broken outside of there... :\ >> >> I'm presuming that if I understood whatever this is doing, it's probably >> something that gives me a better user experience if I accept it while >> working on Guix. But a) for whatever reason Emacs' dir-locals stuff is >> written in such a way that it antagonizes me for not accepting it and I >> didn't know what it eval was (maybe this is a lack of understanding in >> how to "say no and get it to listen to me"... I didn't resist for too >> long) and b) it seems like this change isn't scoped to Guix's checkout >> itself somehow... Sorry again, as soon as I have a bit of time I'll update. Happy hacking! Miguel signature.asc Description: PGP signature
Re: Branching for v1.2?
Hi simon, zimoun writes: > Hi, > > On Sat, 31 Oct 2020 at 23:28, Ludovic Courtès wrote: > >> Having pushed the (guix transformations) patch¹, which also updates the >> manual and thus requires yet some more translation work, I think I don’t >> have any serious changes to make and I’d be happy to branch now. WDYT? > > I think it would be good to branch. > > >> There are a couple of pending issues, notably regarding locales in GRUB, >> but nothing big hopefully, and nothing that changes the manual and >> strings I believe. > > Does it break the system? > Miguel seems to say no. Only Ludo knows about which exact issues was thinking, I can speak only for myself. :-) Messages displayed by GRUB should be localized as declared on the operating-system with current master; menu items aren't translated yet because I have to work more on that implementation and I couldn't reach this release with something good, sorry. :-( > Does it downgrade the first impression that the user has? As far as my testing goes, all the bits that could lead to that are already solved on master too. >> Tuesday 6th is approaching very fast and probably we’re be a bit behind >> schedule, we’ll see. > > I think this Fri. Nov. 6th will be hard; but it is still doable if we > branch really soon. Tomorrow? With my translator hat on: a new tarball for TP has to be generated before or after creating the branch (1.2.0-pre3). If done tomorrow, I think the translations could need a bit later than Friday to catch up; Florian and Julien, what do you think? Happy hacking! Miguel signature.asc Description: PGP signature
Re: bug#43879: Problem with graphical installer
Hi Mathieu, Mathieu Othacehe writes: > "All its data will be lost" refers to the hard drive. Maybe we should > say "Their data will be lost", referring to the partitions? Thanks for the review, I overlooked that. > Otherwise, looks nice. Pushed as bc9e66f0feb25c77898222cfe5f3ef484dcee95e with the message changed as suggested. Happy hacking! Miguel signature.asc Description: PGP signature
Re: Branching for v1.2?
Hi! Ludovic Courtès writes: [...] > There are a couple of pending issues, notably regarding locales in GRUB, > but nothing big hopefully, and nothing that changes the manual and > strings I believe. I've already pushed the changes for grub. The only missing bit I've noticed today during some tests is that some strings in gnu/installer/parted.scm:user-partition-description still need some i18n work: format and G_. > Thoughts? > > Tuesday 6th is approaching very fast and probably we’re be a bit behind > schedule, we’ll see. I'm unable to provide a patch for that until tomorrow evening/night WET, but that's pushing more delay onto translations... :( Does anybody else want to pick up this task on the meantime? We also could generate twice the tarball for translations with that update, or declare it a known bug, as it doesn't break the system. Best regards, Miguel signature.asc Description: PGP signature
Re: [PATCH v3] .dir-locals.el: Automatically set the GEISER-GUILE-LOAD-PATH variable.
Hi, Maxim Cournoyer writes: > Pushed to master as 0e1b0958bd. Sorry, this broke etc/indent-code.el and I didn't noticed, my bad. cl-lib is not loaded there and people noticed in the IRC channel. I've pushed 96d0f0b13819a68480e204716c1af6605cfdcb4c to solve this adding (require 'cl-lib) before the cl-pushnew call. Best regards, Miguel signature.asc Description: PGP signature
Re: bug#43879: Problem with graphical installer
Hi,
I CC the list, as we are currently on freeze, but this might require a
fix or at least a big explanation somewhere, my bad for not answering
soon enough. :-(
Marinus Savoritias writes:
> Hi,
>
> The steps that I followed were:
>
> 1. Use guided installation using full disk with graphical installer
>
> 2. I selected use entire disk and not a separate /home
>
> 3. It gave me the warning that its going to format the disk.
Testing this I think this warning may be the confusion source. "All
data will be lost" doesn't include in this case the old ESP partition
(the one in /boot/efi) as that one is not removed when it exists.
> [...] I curiously found that the files from the previous installation
> of Gentoo were there. Even though the installer said that it formatted
> the disk.
To clarify this I propose the attached patch.
> I was using the default that the guided installation uses. I didn't
> change anything there.
Probably it's too late to add new options to that list, or a new
selection step when the partitioning is guided asking if esp should be
kept, as the tests have to be updated too.
> At that point as I said I formatted the disk separately to make sure
> it was properly formatted this time but the same thing happened.
>
> The only way I could work around the bug was by selecting the manual
> partitioning instead of guided in the graphical installer.
I'm throwing a guess here: did you format the root partition but not
/boot/efi the second time?
Happy hacking!
Miguel
From 2c7f127fbf51de89500a6310d6d1ed130587d111 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?=
Date: Sat, 31 Oct 2020 12:15:35 +0100
Subject: [PATCH] installer: Report to the user the formatted partitions.
* gnu/installer/newt/partitions.scm (define-module): Use (ice-9 format).
(draw-formatting-page): Add parameter partitions and provide the list of
formatted partitions to the user.
(run-partitioning-page): Provide user-partitions to draw-formatting-page.
---
gnu/installer/newt/partition.scm | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/gnu/installer/newt/partition.scm b/gnu/installer/newt/partition.scm
index 3b891d693a..bb452a4925 100644
--- a/gnu/installer/newt/partition.scm
+++ b/gnu/installer/newt/partition.scm
@@ -25,6 +25,7 @@
#:use-module (gnu installer newt page)
#:use-module (gnu installer newt utils)
#:use-module (guix i18n)
+ #:use-module (ice-9 format)
#:use-module (ice-9 match)
#:use-module (srfi srfi-1)
#:use-module (srfi srfi-26)
@@ -56,11 +57,17 @@
#:button-callback-procedure button-exit-action)))
(car result)))
-(define (draw-formatting-page)
+(define (draw-formatting-page partitions)
"Draw a page asking for confirmation, and then indicating that partitions
are being formatted."
- (run-confirmation-page (G_ "We are about to format your hard disk. All \
-its data will be lost. Do you wish to continue?")
+ ;; TRANSLATORS: The ~{ and ~} format specifiers are used to iterate the list
+ ;; of device names of the user partitions that will be formatted.
+ (run-confirmation-page (format #f (G_ "We are about to write the configured \
+partition table to the disk and format the partitions listed below. All its \
+data will be lost. Do you wish to continue?~%~{ - ~a~%~}")
+ (map user-partition-file-name
+ (filter user-partition-need-formatting?
+ partitions)))
(G_ "Format disk?")
#:exit-button-procedure button-exit-action)
(draw-info-page
@@ -773,7 +780,7 @@ by pressing the Exit button.~%~%")))
(user-partitions (run-page non-install-devices))
(user-partitions-with-pass (prompt-luks-passwords
user-partitions))
- (form (draw-formatting-page)))
+ (form (draw-formatting-page user-partitions)))
;; Make sure the disks are not in use before proceeding to formatting.
(free-parted non-install-devices)
(format-user-partitions user-partitions-with-pass)
--
2.28.0
signature.asc
Description: PGP signature
Re: [PATCH v2] .dir-locals.el: Automatically set the GEISER-GUILE-LOAD-PATH variable.
Hi Maxim! Maxim Cournoyer writes: > Thanks for your comments, they've already made this proposed change much > better! You did that, they only may have pointed somewhere, but the effort is yours, so thank you again. >> That cleanup seems to me responsibility of that .emacs maintainer >> instead of something to take into account in .dir-locals. ;-) > > Indeed, it could be seen that way! The good news is that it doesn't > seem to cause any problems anyway, should they forget an entry for Guix > there. Cool, one thing less to worry then. >> If there is some way this may happen, then this call is OK, but I'd try >> to stay with a cheaper push unless it's really needed, as O(1) < O(n), >> for almost every n. :-) > > The way I could easily trigger this was to open a dired buffer, and > hitting 'g' to refresh its contents. That usually is bind to revert-buffer, and they're being loaded again, so you're right. Was the definition for other modes intended? I didn't noticed because I copied directly the code onto scheme-mode sexp without looking at the context, what a reviewer... ;-P > I'll be sending a v3 with the fboundp woopsie above fixed. I've taken a look to v3 and LGTM. Even the answer to the question is no, I wouldn't send another patch only for that hypothetical change. Anybody can speak up if they have any objection; if they don't, I think you should push the patch. Happy hacking! Miguel signature.asc Description: PGP signature
Re: [PATCH v2] .dir-locals.el: Automatically set the GEISER-GUILE-LOAD-PATH variable.
Hello, Maxim! Thanks for your effort in this, some comments with the quotes for context. Maxim Cournoyer writes: >> This fails if geiser-guile-load-path does not exist (void-variable). >> The cleanup removes other guixes, isn't it? I suggest making the >> variable buffer-local and forget about hard-coded names. :-) > > That's a good suggestion! I toyed with it and it's a bit tricky but I > think the v2 patch I'll send as a follow-up does the trick. My concern > was also supporting when a user has previously set > geiser-guile-load-path in their .emacs init file, e.g.: > > (setq geiser-guile-load-path (list (expand-file-name "~/src/guix") >(expand-file-name "~/src/shepherd"))) > > That would mean their entries don't get cleaned up (it seems this > doesn't matter in my latest tests with the v2 patch though!). That cleanup seems to me responsibility of that .emacs maintainer instead of something to take into account in .dir-locals. ;-) >> (eval . (setq guix-directory >> (locate-dominating-file default-directory ".dir-locals.el"))) >> (eval . (when (boundp 'geiser-guile-load-path) > > This check makes it so that if geiser-guile-load-path is not already > defined, nothing happens. It is likely that this is the case, as when > relying on just Geiser's autoloads, it is not loaded. The user would > have to either set explicitly before hand or call (require > 'geiser-guile), which we can't rely on. But we can drop this check. You're right, as you can only bind the keys and enable it when used, not at file load as I do, great catch. :-) > One thing that worried me was the %load-compiled-path not appearing in > the order defined from guile-geiser-load-path, but in my latest tests as > mentioned above it didn't matter. With the right directories (meaning no-conflicts between modules) it shouldn't matter, but it's weird. Looking into geiser-guile.el the load path is provided to guile through -L parameters in geiser-guile--parameters, and the extra path for Geiser code is added with geiser-guile--set-geiser-load-path (that's why it is not added to %load-compiled-path)... I'd have to check Guile to be sure why are the differences, but they seem harmless. > + (unless (fboundp 'geiser-guile-load-path) > + (defvar geiser-guile-load-path '())) This checks the function definition, not the variable, as Emacs Lisp has two separate namespaces. > I ended up using `cl-pushnew' here instead of push, as otherwise > repeated entries were accumulated. I wanted to avoid exactly that check, as the variable should end up with duplicated entries only when you call it twice from the same buffer, how could that happen? > + (make-local-variable 'geiser-guile-load-path) > + (cl-pushnew root-dir* geiser-guile-load-path > + :test #'string-equal) If there is some way this may happen, then this call is OK, but I'd try to stay with a cheaper push unless it's really needed, as O(1) < O(n), for almost every n. :-) Again, thank you very much for taking care of this, as it would make life easier for everybody of us who uses Geiser. Happy hacking! Miguel signature.asc Description: PGP signature
Re: [PATCH] .dir-locals.el: Automatically set the GEISER-GUILE-LOAD-PATH variable.
Hi!
I think that geiser should use something (project.el, wink wink) to fill
load-path automatically when that's possible. Nevertheless, I have some
comments for this.
Maxim Cournoyer writes:
> +
> + ;; Emacs-Guix
> + (eval . (setq guix-directory
> + (locate-dominating-file default-directory
> ".dir-locals.el")))
> +
> + ;; Geiser
> + ;; This allows automatically setting the `geiser-guile-load-path'
> + ;; variable when using various Guix checkouts (e.g., via git worktrees).
> + ;; The checkout root directory name should be prefixed by "guix" for it
> + ;; to work correctly.
> + (eval . (let* ((root-dir (expand-file-name
> + (locate-dominating-file
> +default-directory ".dir-locals.el")))
> +;; Workaround for bug https://issues.guix.gnu.org/43818.
> +(root-dir* (if (string-suffix-p "/" root-dir)
> + (substring root-dir 0 -1)
> + root-dir))
This is already implemented by directory-file-name.
> +(clean-geiser-guile-load-path
> + (seq-remove (lambda (x)
> + (string-match "/guix" x))
> + geiser-guile-load-path)))
This fails if geiser-guile-load-path does not exist (void-variable).
The cleanup removes other guixes, isn't it? I suggest making the
variable buffer-local and forget about hard-coded names. :-)
> + (setq geiser-guile-load-path
> + (cons root-dir* clean-geiser-guile-load-path))
This becomes a push with a local variable. Like this:
---8<-
(eval . (setq guix-directory
(locate-dominating-file default-directory ".dir-locals.el")))
(eval . (when (boundp 'geiser-guile-load-path)
(make-local-variable 'geiser-guile-load-path)
(push (directory-file-name
(expand-file-name
(locate-dominating-file default-directory
".dir-locals.el")))
geiser-guile-load-path))
--->8-
Happy hacking!
Miguel
signature.asc
Description: PGP signature
Re: Update on the timeline for the release v1.2.
Hi Simon, Wow, we're almost there! :-) Just some comments inline. zimoun writes: > However, I am sorry, I have not been able to read what is happening on > the translation side --- aside French one ;-). How is the shape? Spanish translation for manual and program messages are almost ready for current master. > The bug #43591 [0] hitting --system or --target (I am still confused > which one. :-)) is in progress. And these architectures will not be > released, right? IIUC it hits builds for a 32-bit targets (armhf) when the machine is running a 64-bit kernel (x86_64, aarch64 too?, as the current system), but aren't these disabled in the farm and this mitigates the issue? > The proposed coming timeline is: > > - freeze starting the Oct. 26th > - last round for testing all over the week > - unfreeze the Oct. 29th and then create the branch > - minor bug fixes and all the papeword around (NEWS, blog, etc.) > - release Nov. 6th. > > Does this timeline sound good, > > @Mathieu: to generate the various images? > @Marius: to merge staging? > @Translators: about the string-freeze, almost 2 weeks? >From my side everything is A-OK, 2 weeks is more than enough to translate the delta with pre1 and to make the final fine-tune; more than that shouldn't be expected for the freeze period. I hope I can do some extra work too... :) Happy hacking! Miguel
Commit access
Hello, everybody! I'm happy to announce with this message my access to the repository and the key I'll use to sign the commits. This text has been signed with it, which has the following information and fingerprint: pub rsa3072 2020-09-09 [SC] [expires: 2022-01-01] 888784C41459ACCB83E7E84C634C6E8979FABEC2 uid [ultimate] Miguel Ángel Arruga Vivas sub rsa3072 2020-09-09 [E] [expires: 2022-01-01] Happy hacking! Miguel signature.asc Description: PGP signature
Re: Localization of language names
Hi, Ludovic Courtès writes: > Brendan Tildesley skribis: > >> Languages listed in the language selection are sometimes in English, >> Rarely in the native language. > > We take language names and their translations from the ‘iso-codes’ > package, specifically the “iso_639-3” message catalog. Quoth > (gnu installer newt locale): > > (lambda (language) > (let ((english (language-code->language-name iso639-languages >language))) > (setenv "LANGUAGE" language) > (let ((native (gettext english "iso_639-3"))) > (unsetenv "LANGUAGE") > native))) Yesterday I took a look at this issue and the problem was that the installed locale during these calls to gettext was the default one: C. I've attached a patch that fixes this and now the installer shows language names in the language itself. Nonetheless, it didn't work when I removed the call from installer to installer-real, as the there comment says, and set the locale directly in the line added by the patch. Therefore I need to take a deeper look into libc code to really understand what's happening there, and check if it is possible to remove that extra call in the future, or find a satisfactory explanation at least. Happy hacking! Miguel From 69b8d919a802d72fca218b7dfd9e7719c4711544 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?= Date: Fri, 16 Oct 2020 15:02:00 +0200 Subject: [PATCH] installer: Call setlocale after init gettext. * gnu/installer.scm (installer-program)[init-gettext]: Change locale from C, installed at the program start. --- gnu/installer.scm | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gnu/installer.scm b/gnu/installer.scm index c582a46c14..f401b242f8 100644 --- a/gnu/installer.scm +++ b/gnu/installer.scm @@ -308,7 +308,8 @@ selected keymap." ;; translated. #~(begin (bindtextdomain "guix" (string-append #$guix "/share/locale")) -(textdomain "guix"))) +(textdomain "guix") +(setlocale LC_ALL ""))) (define set-installer-path ;; Add the specified binary to PATH for later use by the installer. -- 2.28.0 signature.asc Description: PGP signature
Re: Using #true and #false everywhere?
I didn't send this to the list... I must start using S L always instead
of R and changing the headers manually, sorry. :o)
---
Hi Ludo,
Ludovic Courtès writes:
> Hello Guix!
>
> As discussed on IRC recently, several of us think that using “#true” and
> “#false” instead of “#t” and “#f” throughout or documentation and code
> would probably make it easier for newcomers to decipher that.
>
> WDYT?
I think that it could help to the reader.
> This syntax is supported since Guile 2.0. ‘write’ still uses the
> abbreviations, but the good thing is that it means we can change all of
> gnu/packages without triggering a single rebuild.
This is even better. :)
> As for the manual, I’m afraid it’ll make every msgid that contains
> @code{#t} stale. So maybe now’s not a good time to make this change?
It may be a big issue with a release in one week, but on the other hand
the msgids would break just after releasing...
Maybe other translators have a say.
Happy hacking!
Miguel
signature.asc
Description: PGP signature
Re: Release v1.2 and Translation
Hi, First of all, thanks. And second, to leave a clear statement about the main point: I agree with your proposed time frame for the string freeze, October 26th (freeze) to 29th (release). zimoun writes: > Maybe I am missing something. Probably this context helps: I've already uploaded to TP the translation for the manual, so I can compare the "old" pot (the one uploaded to TP) with the "new" one (the one I generated today on my machine). > Now the translation 1.2.0-pre1 is open, so it is almost 3 weeks (even > if I know it is maybe not enough, well we have to fix some deadlines > somehow :-)). Nobody likes deadlines---at least not me, hehe---but I believe they can be really useful sometimes. :-) > The last week, we could string freeze for polishing and not run after > an always moving target. Yup, that's the main advantage of freezing: you can focus as much as possible on the little and not so little details, like bug hunting. > From my point view, a longer freeze would not help to have the work > done. I do not know. What do you think it could be better? I agree that a longer string freeze wouldn't a big difference, and even may hurt. At least the manual is a huge work that probably cannot be done in weeks from scratch, so I'm not thinking about the string freeze as "the time frame to perform the translation" but "a time frame to check the translation already done and fix last minute issues/features". Besides, sorry if the word 'tight' sounded as a complaint meaning protest, if so it'd really be a complaint meaning grief for my schedule, as I'm unable to dedicate much time on working days. Happy hacking and translation too! Miguel
Re: Release v1.2 and Translation
Hi simon and Ludo, zimoun writes: > On Mon, 12 Oct 2020 at 14:30, Ludovic Courtès wrote: >> I agree that a string freeze would be nice… but it’s difficult. There >> are still a few patches out there (such as new package transformation >> options) that will likely be merged soon. That said, this is non-core >> functionality, so maybe we can live with that. Yup, I understand, and of course I don't want to slow the pace of the project at all. I guess that everybody understands (even expects) to wait a bit for certain translation from time to time, specially when the alternative means waiting for fancy new features. :-) >> Anyway, if we’re aiming for Oct. 29th, perhaps we can do a last round a >> week before? > > From my point of view, a string freeze starting on Mon. Oct. 26th > seems the easiest to synchronize all etc. > And unfreeze once the branch is create &co. Three days is a tight schedule, but could be enough if the number of changes keeps close to the current one (there are already 98 fragments without translation on guix-manual, none on guix and I didn't check guix-packages). Nonetheless, probably after the branch generation, I'd like to remove the paragraph that says "some fragments may be found in English" from the release version of the Spanish manual (but keep it with the info downloaded by guix pull), checking that it's true, obv. Best regards, Miguel
Re: Release v1.2 and Translation
Hi everybody, I've noticed that at least the pot file for the manual has to be updated again, as some fragments of guix.texi has been modified since the the pre-release was generated (e.g. section 2.4.2 Using the Offload Facility), therefore they cannot be translated. I've open http://issues.guix.gnu.org/issue/43934 with some minor details I've found during translation, but I'd recommend to perform a complete string freeze at some point before of the release to avoid these issues. WDYT? Happy hacking! Miguel
Manual license (was Re: Translating the web site)
Hi, everybody! Ludovic Courtès writes: > Those at <https://translationproject.org/domain/guix-manual.html> have > the same statement, but it should rather be the same license as the > manual (GFDL). Perhaps a ‘Makevars’ issue too? Sorry for bringing up this old issue so late, but I've just confirmed that the sentence is enforced by TP's robot, as the pot file contains literally this: -- This file is distributed under the same license as the guix manual package. -- Nonetheless I've tried to change the sentence in the po file to that and it complained. As the current phrasing is not really wrong (it says guix package and the package includes the manual) I've sent the file with these two lines instead: -- This file is distributed under the same license as the guix package. Note: The contents of this file are licensed under GNU FDL v1.3. -- I hope this is enough clarification on the legal side. Best regards, Miguel
Re: Release v1.2 timetable
Hi Julien, Julien Lepiller writes: > I'll try sendinq them a tarball for 1.2. They won't accept new pot > files, but maybe they'll update existing ones. Maybe I'm loosing something between all the mail received through this list or on the IRC where I almost never connect to, but why wouldn't translationproject.org accept a new release of guix, guix-packages and guix-manual? AFAIU it's calling make dist and sending them the tarball, plus or minus the associated pot files, am I wrong? On my side I'm working on the translations too, so I hope I have them ready for the release. I'll try the proofread to the whole manual too if I have time enough. :-) Happy hacking! Miguel
Re: u-boot for beagleboard
Hi Vagrant and Danny,
First of all, I cannot start without saying: thank you for you effort
and time.
Danny Milosavljevic writes:
> On Thu, 01 Oct 2020 10:15:40 -0700
> Vagrant Cascadian wrote:
>> Maybe make-u-boot-package should be extended to support passing a list
>> of "common" names for boards, which could then be appended to the
>> description?
>
> Translators should say what they think about that.
As a translator I could have a personal say, but the best practices are
already encoded on gettext manual[1].
> (Long ago, I stopped doing string concatenations like this because
> translating that into some languages isn't easy)
Thank you for raising awareness of this. I've seen plenty of bad
translations because of this anti-pattern, and some of them are
hilarious.
> Other than that, sure, something like that would be nice.
>
> Maybe just make it possible to add any sentence(s) to the description,
> though. That should be translatable enough... I think.
I see two main possibilities for the "translation units" in these cases:
- When the extra data is a "non-localizable string", I'd rather use a
format string for the template, and insert the data through the format
specifier, possibly with a message to the translators to make clearer
the inserted data if it isn't clearly deduced from the message:
--8<--
(let ((desc (format #f
;; TRANSLATORS: ~a is substituted by the board ids.
(_ "Description.~{~% - Board: ~a~}~%")
(list "id1" "id2" ... "idn"
...)
-->8--
- In any other case, I'd concatenate them as two separate paragraphs[2]
and let the translators face them up separately:
--8<--
(let ((desc (format #f
"~s~%~%~s" ; Translating this may be an overkill...
(_ "First paragraph(s).")
(_ "Other paragraph(s)."
...)
-->8--
Happy hacking!
Miguel
[1] https://www.gnu.org/software/gettext/manual/gettext.html#Preparing-Strings
[2] My two cents: As a programmer use as few as possible implicit
references to each other paragraph, please. :-)
They are ok inside the same translation unit, but they can lead to
mismatches if the sentence is common and/or short enough to be used
somewhere else.
Re: Status of Gnome upgrade?
Hi, Yay! We already have Gnome 3.32 on master! Unfortunately, I've found one regression on XFCE/LXDE, as libwnck-2 does not build anymore. I've open a bug report[1] with the proposed patch, sorry I didn't noticed it sooner, but I haven't run a full reconfiguration on my old machine with the branch integrated until it has been in master. Best regards, Miguel [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38547
Re: 'core-updates' Q4 2019
Hi Kei, Kei Kebreau writes: > Miguel Arruga Vivas writes: > Boot and login worked properly for me after I cleared the contents of > my /var/lib/gdm directory (if it's unclear why that directory > matters, see > https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00421.html > for a quick overview). Great pointer, thank you, and good that it's solved. > > - The patch for gedit contains a reference to libgd, wouldn't it be > >clearer for the reader/updater to have it defined in a let over > > the package definition and use the name in native-inputs? > > > > I'm not sure. I don't know if there is an explicit convention for > packaging software that is distributed like this, and the examples of > this in the code base (that I've seen, at least) define the > third-party library the way I've done it here. I'm open to change on > this point though. This actually should have been an open question, as I have a patch on libosinfo, related with gnome-boxes (patches coming soon) and it doesn't feel right for me having usb.ids and pci.ids hidden there, so I've put another origin needed (osinfo-db) out there. > > - Is there any reason to not patch-out the gtk-icon-update-cache > >invocations? If I understand it correctly, this is performed at > >profile level, so makes no sense creating a cache at package > > level, isn't it? The patches for quadrapassel, gnome-klotski, ghex, > >gnome-sudoku, gnome-mines, five-or-more and gedit contain > > references to it. Maybe creating a package like > > xorg-server-for-tests (perhaps 'gtk-bin-for-build'?) linked to > > "true" from coreutils would help in the long term. > > > > I don't think such a reason exists. I could add changes that > substitute calls to "gtk-icon-update-cache" with "true" for these > packages, but I agree that a better solution may be possible. > Perhaps not a package; maybe a new 'patch-gtk-icon-update-cache' > phase in the relevant build systems? Some of these packages already have phases for it on master. I rebased your branch onto it (1a9df94cec..fb936351d3), I had to solve two merge conflicts: devhelp and totem. devhelp's patch has only a trivial conflict, as there was no arguments parameter before. OTOH, I did not check as much as I should totem's last day, as now I have one question here: Who kills the Xvfb server on display :1 after the tests? I see it's a common idiom, but I don't get why shouldn't the daemon treat it like from any other process and wait for it to reach completion (other than technical means, I mean). This could be a great place for a #:xorg-for-tests?, should I try? > > As a final comment, the gnome release cycle and the amount of > > packages involved is quite big, so again, thank you. > > > > Happy hacking! > > Miguel > > Thanks Miguel! This comment and review means a lot! > Kei Thank you too Best regards, Miguel
Re: 'core-updates' Q4 2019
Hi Kei, Kei Kebreau writes: > Update: Please check out the new wip-gnome-updates branch of the Guix > git repository for continued updates. The contents of the notabug.org > link given above will be changed to a notice that says to do this. Thank you very much for this huge effort. I've been playing with the branch and I have a working system, both X11 with GDM and Wayland with SDDM (I haven't tried hard enough to set up gdm with wayland as only a change to gdm-configuration doesn't seem to have any effect) and your branch works great on my machine, do you still have the issue during boot? I haven't found any (new) problem on the applications I've tested (x86_64, normal use with almost all of the gnome applications, not the games though.) Nevertheless, I've been reading the patches and I have a couple of comments about them: - The patch for libdazzle only changes the xorg-server, as it already is at version 3.33.90 in master. It still makes sense as a patch, but the title indicates a version downgrade. - The patch for gedit contains a reference to libgd, wouldn't it be clearer for the reader/updater to have it defined in a let over the package definition and use the name in native-inputs? - Is there any reason to not patch-out the gtk-icon-update-cache invocations? If I understand it correctly, this is performed at profile level, so makes no sense creating a cache at package level, isn't it? The patches for quadrapassel, gnome-klotski, ghex, gnome-sudoku, gnome-mines, five-or-more and gedit contain references to it. Maybe creating a package like xorg-server-for-tests (perhaps 'gtk-bin-for-build'?) linked to "true" from coreutils would help in the long term. As a final comment, the gnome release cycle and the amount of packages involved is quite big, so again, thank you. Happy hacking! Miguel
Granularity of grub-install (was Re: Reproducibility of grub-install)
Hi,
First of all, thank you for your comments. My answers are inline,
although the bad subject was a main issue of misunderstanding. I
changed it, as I think it reflects better my current idea. I'm sorry
for the confusion it certainly caused.
Wed, 23 Oct 2019 11:09:07 +0200
Daniel Kiper wrote:
> On Mon, Oct 21, 2019 at 04:30:21PM +0200, Miguel Arruga Vivas wrote:
> > Hi, everybody!
> >
> > After taking a deeper look into our (guix's) grub installation
> > procedure, I have the thought that it could be a neat idea to make
> > the boot directory an actual derivation instead something of the
> > global status.
>
> I do not understand what you mean by "make the boot directory an
> actual derivation instead something of the global status". Could you
> elaborate more about that?
Currently, the /boot directory is partially a system-wide directory,
even though most of its contents are direct copies of the ones from
grub's installation prefix: /usr/... in most distributions including
BSD world, /{nix,gnu}/store/-grub-2.04 in Nix/Guix. Most of its
contents don't depend at all on the actual machine and that can be
shared between machine-dependent boot-sector/efi-variables
"activations". These contents include all grub modules and message
object files. On the other hand, the task of the platform-specific
installation cannot be "shared", as it must be performed directly "on
the metal". And there is a third task between these two: the generation
of the raw image, that depends on the hardware configuration through
the provided configuration file *and* the binary installation.
> (...)
> I am not sure why grub.cfg have to be reproducible. OK, to some extent
> it has but...
Guix doesn't generate grub.cfg through grub-mkconfig, as each kernel is
also associated with the configuration for the init system too--GNU
Shepherd in Guix--, and one kernel may boot up different systems, so it
is generated with Guile scripts. My understanding is that grub-mkconfig
is a portable tool, not only intended for this case, whose output is
system dependant. I mixed up concepts here, sorry.
> >
> > - /boot/grub/grubenv: IIUC, this file must be writable by grub.
> > This should not be on the store, and not sharing the path may be the
> > main problem right now to implement this.
>
> I do not understand this.
>
> > AFAIK, the grubenv problem requires a modification of the grub code
> > if we try to use a different path for this kind-of-modifiable file,
> > so this would require modify grub to being able to lookup for that
> > file somewhere else. This way the global state can be made
> > explicit.
>
> What do you mean by "This way the global state can be made explicit."?
Sorry again. We do not use load_env nor save_env in our
configuration. I misunderstood the creation in grub-install.c as a
hidden requirement for it, but I'd just had to read the manual. That
global state already is explicit enough. I think now that its creation
should be optional, even though it's created by default as
grub-mkconfig makes use of it. Should I send a patch for it?
> > The image installation into the device is a separate issue from the
> > binaries installation, that could be separated into two separate
> > binaries, or two steps/flags for grub-install, one for binaries
> > installation into ${boot-directory}/grub and the other one for
> > load.cfg generation and core/boot.img installation.
>
> Why do you need to separate this thing into two steps?
I'd like being able to have different grub /boot-like folders, maybe
through unions in the file system (as hard links) of the shared
contents and the physical system dependencies, and activate them
selectively without writing into them any more. This is intended for
Guix's store[1], but other use cases are possible, in order to roll-back
to a previous generation of the system by only writing
core.img/grub.efi/etc. into platform-dependant locations.
As I said before, I see them now as three steps. The middle one is
already there with grub-mkimage. The bios-like installation can be
performed with grub-setup, but EFI systems need grub-install to copy
the image and activate it, the reason behind grub-setup deprecation if I
understand the code correctly. And the copy of the correct files to
the boot-directory needs no modification at all of grub-install.
> > To grub-devel: I'd be able to send patches for the latter if you
> > think
>
> Patches are always welcome...
I'll send just to grub-devel following this mail a patch for a minor
problem I've found reading the code.
The code for an --only-platform-installation flag (the name I'm using
right now) needs more work but I'll send it as soon as I have
something I've tested on x86 BIOS and x86_64 EFI. From my
current understanding it would replace completely grub-setup, wouldn't
it?
Happy hacking!
Miguel
[1] https://guix.gnu.org/manual/en/html_node/Features.html
Reproducible grub-install
Hi, everybody!
After taking a deeper look into our (guix's) grub installation
procedure, I have the thought that it could be a neat idea to make the
boot directory an actual derivation instead something of the global
status.
From what I currently understand:
- boot.img/core.img and load.cfg: The written images must be replaced
on each installation. This is one task performed by grub-install.
- /boot/grub/*: The contents of these folders should be reproducible,
such as the modules or the localization binaries, as currently
grub.cfg is. This is the other task performed by grub-install.
- /boot/grub/grubenv: IIUC, this file must be writable by grub. This
should not be on the store, and not sharing the path may be the
main problem right now to implement this.
AFAIK, the grubenv problem requires a modification of the grub code if
we try to use a different path for this kind-of-modifiable file, so this
would require modify grub to being able to lookup for that file
somewhere else. This way the global state can be made explicit.
The image installation into the device is a separate issue from the
binaries installation, that could be separated into two separate
binaries, or two steps/flags for grub-install, one for binaries
installation into ${boot-directory}/grub and the other one for load.cfg
generation and core/boot.img installation.
To everyone: Are you aware of any other way to achieve this? What do
you think?
To grub-devel: I'd be able to send patches for the latter if you think
it is a good idea without help, but I guess that the first kind of
modification would need some and deeper study of grub code.
To guix-devel: Even though the procedure I have in mind needs
changes in grub, there are alternative ways to achieve this with the
current tools, as copying the files and using the installation as an
"implicit" guix-challenge, but they are not as neat an clean as the
split between reproducible binaries installation and global state,
which includes the disk preparation for the load of the bootloader.
Happy hacking to all!
Miguel
Re: [bug#35394] [PATCH 0/3] Bootloader localization
Hi Ludo’, El Mon, 29 Apr 2019 09:56:25 +0200 Ludovic Courtès escribió: > Hi Miguel, > > Thanks a lot for this work. I've been quite silent about this because I wanted to solve the issue with .mo files in a better way, but my current understanding is that the best way to go with that is to make grub installation (store-)reproducible and removing /boot altogether, so I'll open a different thread on the mailing list about that. For the moment, the patches following this mail rely on the installation of /boot/grub/locale, usually generated by grub-install. The generated grub.cfg scriptlet enables the use case for /boot in a different partition found in many other distributions (which breaks the boot when /gnu/store is encrypted in a different partition, I'm going to fill a bug for that too). I've tested them on the following machine configurations, on top of commit 5f760515c8: - grub-efi on x86_64-gnu-linux: * Encrypted partition for the whole disk. * Separate "/boot" (ext4) and "/" (ext4 and btrfs) partitions. - grub-pc on x86_64-gnu-linux: * Same as grub-efi, plus * Encrypted and different "/boot" and "/" partitions, typing manually in the console "cryptomount (hdX,msdosX)" with the "/" partition to allow grub loading the kernel image. > FWIW, I’m holding off review and integration after 1.0, but I’m happy > if someone else reviews :-), I'm CCing the list to bring some attention onto it, I think it's on-topic enough to worth a try. The hardest part for review is the new test case, because I wanted to be 100% sure I didn't break anything. As you can see, the tested code didn't need almost any change, although I've made some changes on the test case from the last set of patches. > and I’ll be really happy to see it in master once 1.0 is out. I wish we'll see it in master soon. Best regards, Miguel
Re: automake warning
Hello, Ludovic Courtès : > Hello, > > (Digging through old messages…) > > Robert Vollmert skribis: > > > When I run `make` in the guix repository, I always get the following > > block of warnings at the start: > > > > configure.ac:23: warning: The 'AM_PROG_MKDIR_P' macro is > > deprecated, and its use is discouraged. > > configure.ac:23: You should use the Autoconf-provided > > 'AC_PROG_MKDIR_P' macro instead, > > configure.ac:23: and use > > '$(MKDIR_P)' instead of '$(mkdir_p)'in > > your Makefile.am files. > > Makefile.am:613: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS > > This has “always been around” and there’s nothing we can do on our > side. Actually this has been fixed in gettext some time ago. The problem lies on the following line: configure.ac:24: AM_GNU_GETTEXT_VERSION([0.18.1]) This line is used by autopoint (called by autoreconf, called by bootstrap script) to install the macros from that exact version. The first warning can be removed simply bumping the version to 0.18.2, which includes that fix. The newer, the better, but that's the minimal version change. > However, one should definitely ping bug-gett...@gnu.org about this, it > seems silly to have these warnings for years. The warning left can be silly for Guix, as there are three different translation domains in a single source code base, so the setup is inherently more complex. It is not a bad idea at all for a small/medium size project to warn the missing po folder when the internationalization is being set up, as gettext "enforces" the use of recursive make into the it to get the translations targets; Guix does that not only once, but twice, and another time with different tools and make rules for the manual translation. This point maybe worths a discussion in bug-gett...@gnu.org, at least to give some way to disable it, but I had to clarify this beforehand, as guix usage is not the common case and one warning actually complies with our requested behaviour. Happy hacking, Miguel
Re: Gender neutral documentation
Hi! El July 30, 2019 11:53:26 PM UTC, Wilson Bustos escribió: >El July 30, 2019 10:10:21 PM UTC, Wilson Bustos >escribió: >>>Hello everyone! >>>I would like to help to make guix packages, >>I'm also reading documentation and watching videos about this. >>> >>>But I have some questions. >>>1- Do you have some document which explain what means 'gender >neutral' >>>documentation. >>>and how that works in different languages such as Spanish? >>> > >> The use of the feminine gender as neutral in the Spanish translation >is >intended as explained here: >https://guix.gnu.org/manual/es/html_node/Envio-de-parches.html#DOCF40 > >Thank you so much! that article resolve really well my question! You're welcome. >My other question is: >Are you the only person who translate in Spanish? Right now, yes. If you want to help, that'd make it two. :-) >- If I help you with some parts have I to sent it to you first? Well, actually https://translationproject.org is the real platform for the translation process, but we could define any workflow as needed, I think. We can agree about that privately or on the tp list (e...@tp.org.es), if needed. >I ask this because I'm not sure if I can apply all the logic behind the >neo >Spanish rules that you apply, They aren't rules, they're a synthesis of the intent behind my translations. I've shown you an actual example of perfect Spanish where the feminine (grammatical) gender can be applied to any (social) gender. As I bend a little the conventional rules in the default case, I can understand the "neo" as an misplaced joke, but I'd stay close to the facts and far from that kind of modifiers to keep the conversation on topic. >- This rules are also to translate the package description? or only for >the >main documentation? As I said, they aren't rules, only the reason why I did that. I think that it's up to the community to make a decision, not me. Currently, the community decision is to use gender neutral language, but it'd be a nonsense make a decision about a language you don't speak, so this interpretation is at the end up to each language speakers community. Any thought about gender neutrality in Spanish, everybody? Best regards, Miguel
Fwd: Re: Gender neutral documentation
Sorry, I knew something will go wrong (twice)... Fixed here: Mensaje Original De: Miguel Enviado: July 30, 2019 11:34:42 PM UTC Para: guix-devel@gnu.org, Wilson Bustos Asunto: Re: Gender neutral documentation Hello, Wilson! Thank you for your interest in this awesome community. From my side, I've been taking more than expected to finish the translation and send some other patches, sorry for that. I hope to do it soon, but I only can answer with my phone at this moment. I'll try to answer your questions inline, let's see... El July 30, 2019 10:10:21 PM UTC, Wilson Bustos escribió: >Hello everyone! >I would like to help to make guix packages, >I'm also reading documentation and watching videos about this. > >But I have some questions. >1- Do you have some document which explain what means 'gender neutral' >documentation. >and how that works in different languages such as Spanish? > The use of the feminine gender as neutral in the Spanish translation is intended as explained here: https://guix.gnu.org/manual/es/html_node/Envio-de-parches.html#DOCF40 >2- Reading the the Spanish version of the GNU manual in several pages >like >this one: >https://guix.gnu.org/manual/es/html_node/Caracteristicas.html#Caracter_00edsticas > >Has female sentence instead a 'normal' - 'neutral' sentence. >LIKE: `Opera en los perfiles de usuaria, y puede ser usada *con >privilegios >de usuaria normal*.` > >which say 'usuaria' to refer to the user, but that words is only used >to >refer to a woman. >but 'usuario' can be used to refer to a man or woman. As written in the footnote, It's perfectly reasonable to say in Spanish "la persona" and "las personas" (person/people in English), whose grammatical gender is feminine, to refer anyone without making any reference to their preferred gender, so it should be any problem to use that grammatical gender instead of the usual "neutral" one. From Latin's neutral case we have words like "el/la estudiante", "el/la marchante [de arte]", but the selection of the masculine as the default/neutral form is arguably biased towards one end. >Using this all the time it becomes confusing to read for me, due to >this I >change to the english manual. I understand that it can be tiresome, specially if you've been socialized as a male as I've been. On the other hand, more than a half of the Spanish speakers don't have to make any effort in order to understand it. I suppose that the same effort probably have been the done (usually beforehand) by people socialized as females when they read a document claiming (implicitly, as any language construct) that "usuario" applies to them too, but I only have anecdotical evidence... and the fact that women are really underrepresented (at least) in the development and free software community, so I try to take a feminist stance as my grain of sand to move this actual mountain. >I completely respect your job I want to be part of the community and >help, >I know this is a really delicate topic and I don't want to make a flame >war >or something like that. My approach is far from perfect: there are people who don't identify neither as male nor female, so the dissonance is still there, but I'm open to any new idea but using male gender as neutral one for the reasons I exposed there and here. Personally, I think it needs to be openly talked, it shouldn't be a flame war each time somebody mentions it. The conflict is already there, not speaking "about the elephant" doesn't make it disappear and only delays the possible solutions. Best regards, Miguel
Re: Gender neutral documentation
El July 30, 2019 10:10:21 PM UTC, Wilson Bustos escribió: >Hello everyone! >I would like to help to make guix packages, >I'm also reading documentation and watching videos about this. > >But I have some questions. >1- Do you have some document which explain what means 'gender neutral' >documentation. >and how that works in different languages such as Spanish? > The use of the feminine gender as neutral in the Spanish translation is intended as explained here: https://guix.gnu.org/manual/es/html_node/Envio-de-parches.html#DOCF40 >2- Reading the the Spanish version of the GNU manual in several pages >like >this one: >https://guix.gnu.org/manual/es/html_node/Caracteristicas.html#Caracter_00edsticas > >Has female sentence instead a 'normal' - 'neutral' sentence. >LIKE: `Opera en los perfiles de usuaria, y puede ser usada *con >privilegios >de usuaria normal*.` > >which say 'usuaria' to refer to the user, but that words is only used >to >refer to a woman. >but 'usuario' can be used to refer to a man or woman. As written in the footnote, It's perfectly reasonable to say in Spanish "la persona" and "las personas" (person/people in English), whose grammatical gender is feminine, to refer anyone without making any reference to their preferred gender, so it should be any problem to use that grammatical gender instead of the usual "neutral" one. From Latin's neutral case we have words like "el/la estudiante", "el/la marchante [de arte]", but the selection of the masculine as the default/neutral form is arguably biased towards one end. >Using this all the time it becomes confusing to read for me, due to >this I >change to the english manual. I understand that it can be tiresome, specially if you've been socialized as a male as I've been. On the other hand, more than a half of the Spanish speakers don't have to make any effort in order to understand it. I suppose that the same effort probably have been the done (usually beforehand) by people socialized as females when they read a document claiming (implicitly, as any language construct) that "usuario" applies to them too, but I only have anecdotical evidence... and the fact that women are really underrepresented (at least) in the development and free software community, so I try to take a feminist stance as my grain of sand to move this actual mountain. >I completely respect your job I want to be part of the community and >help, >I know this is a really delicate topic and I don't want to make a flame >war >or something like that. My approach is far from perfect: there are people who don't identify neither as male nor female, so the dissonance is still there, but I'm open to any new idea but using male gender as neutral one for the reasons I exposed there and here. Personally, I think it needs to be openly talked, it shouldn't be a flame war each time somebody mentions it. The conflict is already there, not speaking "about the elephant" doesn't make it disappear and only delays the possible solutions. Best regards, Miguel Hello, Wilson! Thank you for your interest in this awesome community. From my side, I've been taking more than expected to finish the translation and send some other patches, sorry for that. I hope to do it soon, but I only can answer with my phone at this moment. I'll try to answer your questions inline, let's see...
Re: Update on 1.0.1
Hi, "pelzflorian (Florian Pelz)" : > Thank you for explaining. You're welcome. :) > I prefer doing `msgmerge --previous --nowrap /path/to/old/de.po > po/doc/guix-manual.pot > /new/de.po` to get the old fuzzy messages and > all messages on a single line. I disagree with TP's --nowrap policy for my local copies. I have them in a git repository, and it is easier to check the history when the lines fit in a 80-column page. The --previous option is quite important though, I should have included that one. Best regards, Miguel
Re: Update on 1.0.1
Hi, "pelzflorian (Florian Pelz)" : > On Thu, May 16, 2019 at 01:38:39PM +0200, Ludovic Courtès wrote: > > I’ll create a ‘version-1.0.1’ branch with the aim of releasing the > > whole thing maybe tomorrow or at least by Tuesday. > > > > If this does not go through the TP, can we send a download link for a > newer PO file adapted to current doc/guix.texi? I agree that it should go through TP[1], nonetheless there is a way to generate the pot file to merge it and get an updated po file. From a fresh checkout of the git tree you only have to follow these steps: $ guix environment guix [env]$ ./bootstrap [env]$ ./configure [env]$ make doc-pot-update [env]$ msgmerge /path/to/old/de.po po/doc/guix-manual.pot > /new/de.po And that /new/de.po file will contain the updated messages for the last version of the manual. > Also it would be good if you could make sure > http://guix.info/manual/en/html_node/Binary-Installation.html#Binary-Installation > will mention Guix version 1.0.1 instead of telling users to download > version UNKNOWN, but maybe this only happened because of the 1.0.0 > %base-packages warning added to the manual. This link, the official one I guess, https://www.gnu.org/software/guix/manual/en/html_node/Binary-Installation.html#Binary-Installation contains the correct version. Is the manual published in guix.info generated automatically? Maybe it is something related with the build process... Happy hacking! Miguel [1] Probably GNU's ftp could be used for that too, as a -pre release. AFAIK, older pre-releases can be removed if the folder grows up too quickly: https://www.gnu.org/prep/maintain/html_node/FTP-Upload-Standalone-Directives.html
Re: GNU gettext 0.20.1 released
Hi Tobias,
Tobias Geerinckx-Rice :
> Bruno,
>
> Wow. Thank you for this great summary! Would that all projects
> published such clear (and custom) release notes… <3
>
> I see that gnu/packages/gettext.scm has a nice chronological list
> of copyright lines, which does make it appear as if I'm the
> current packager of gettext in Guix. However, the Guix project
> doesn't have this notion of (package) maintainer: everyone
> packages, fixes, and updates what they can whenever they can.
> This might change in future but it works rather well now.
>
> For that reason, I'm CC'ing the guix-devel@gnu.org list. I
> encourage you to add it to your own for future releases.
>
> I'm having some trouble with the actual upgrade but I'll save that
> for a reply.
What are the issues you have? I could help with that. :-)
I see a big point that need special care: gettext-tools now depends on
libtextstyle, so gettext-boot0 will definitely fail if only
gettext-minimal is updated to the next version.
This is going to be a big big update in any case. We can avoid
the new bootstrap, keeping 0.19.8.1 for it, but we should update
gettext-minimal so it may not worth the effort as probably almost all
the packages will be rebuilt.
My snippet for building it is this one, with some code from
gettext-minimal and it need some work:
>8
(define-public gettext-next
(package (inherit gettext-minimal)
(name "gettext-next")
(version "0.20.1")
(source (origin
(method url-fetch)
(uri (string-append "mirror://gnu/gettext/gettext-"
version ".tar.gz"))
(sha256
(base32
"0p3zwkk27wm2m2ccfqm57nj7vqkmfpn7ja1nf65zmhz8qqs5chb6"
(inputs
`(("xml2" ,libxml2)
;; Avoid dependency cycles
("unistring" ,(@ (gnu packages libunistring) libunistring))
("ncurses" ,(@ (gnu packages ncurses) ncurses
(arguments
`(#:configure-flags
(list "--with-included-libunistring=no"
"--with-included-libxml=no"
(string-append "--with-libxml2-prefix="
(assoc-ref %build-inputs "xml2"))
(string-append "--with-libncurses-prefix="
(assoc-ref %build-inputs "ncurses"))
(string-append "--with-libtermcap-prefix="
(assoc-ref %build-inputs "ncurses"))
(string-append "--with-libunistring-prefix="
(assoc-ref %build-inputs "unistring")))
#:phases
(modify-phases %standard-phases
(add-before 'configure 'patch-fixed-paths
(lambda* (#:key inputs #:allow-other-keys)
(let* ((bash (which "sh")))
(substitute* '("gettext-tools/config.h.in"
"gettext-tools/gnulib-tests/init.sh"
"gettext-tools/tests/init.sh"
"gettext-tools/system-tests/run-test")
(("/bin/sh")
bash))
(substitute* '("gettext-tools/src/project-id"
"gettext-tools/projects/KDE/trigger"
"gettext-tools/projects/GNOME/trigger")
(("/bin/pwd")
"pwd"))
#t)))
(add-before 'check 'patch-tests
(lambda* (#:key inputs #:allow-other-keys)
(let* ((bash (which "sh")))
;; Some of the files we're patching are
;; ISO-8859-1-encoded, so choose it as the default
;; encoding so the byte encoding is preserved.
(with-fluids ((%default-port-encoding #f))
(substitute*
(find-files "gettext-tools/tests"
"^(lang-sh|msg(exec|filter)-[0-9])")
(("#![[:blank:]]/bin/sh")
(format #f "#!~a" bash)))
#t)
;; When tests fail, we want to know the details.
#:make-flags '("VERBOSE=yes")
8<
Happy hacking,
Miguel
pgpO_JRNXDZ5L.pgp
Description: Firma digital OpenPGP
Re: GNU Guix 1.0.0 released
Well, I must say "¡Enhorabuena!" too. Thank you all, the hard work of this great community is this awesome release 1.0. :-) Happy hacking! Miguel
Re: Last translation round on Monday?
I've fixed it with other two I've found, it was a bad move on my side not generating the info file before uploading it, even more being in the rush of a release. The file has been uploaded to TP again (after checking info+pdf generation), sorry for the trouble. Thank you all and happy hacking, Miguel El Wed, 01 May 2019 16:22:42 +0200 Ludovic Courtès escribió: > BTW, we found a typo (Texinfo syntax error) in ‘guix-manual.es.po’ > that I fixed in a3b32d57d6677fded92dbd3f4ecafbf9aceeb855. > > Ludo’.
Re: Last translation round on Monday?
Hi! El Tue, 30 Apr 2019 18:36:17 +0200 Ludovic Courtès escribió: > Hi again! > > Ludovic Courtès skribis: > > > Since time passes and -pre3 hasn’t shown up at the TP, we should > > probably consider temporarily bypassing the TP for this last > > update. > > Julien and I briefly discussed it on IRC, and we agreed to that. > So Florian & Miguel, could you send your PO files to both of us? Sorry, yesterday I was kind of busy and didn't check the mail until this morning. :-( > With luck, I should be able to build and upload all the release files > tomorrow morning. > > Thanks in advance! :-) > > Ludo’. I've already uploaded the last version of both application and manual. At the end I got 80%+ of the manual, but it needs a whole lot of work yet, so I guess the translation will be finished in a couple of weeks tops. Happy hacking, Miguel
Re: Last translation round on Monday?
El Mon, 29 Apr 2019 22:19:03 +0200 "pelzflorian (Florian Pelz)" escribió: > On Mon, Apr 29, 2019 at 10:08:42PM +0200, Julien Lepiller wrote: > > I've sent a better version to the TP, you will find it here: > > > > https://lepiller.eu/files/guix-1.0.0-pre3.tar.gz > > > > Thanks! > > But this is the same old manual pot file, or do I look in the wrong > place? > Hi Florian, I've downloaded that tarball, and generated guix-manual.pot manually with make doc-pot-update from 05344275517e12ea60039272b5d8936d18fd4338 and I get the same file[1] and I get 7985 messages[2]. I did not check the other one, but I can see guix install/remove/search documentation too, so I have started updating the translation. Best regards, Miguel [1] Diff from generated content, even though git HEAD does not have the latest content. It's a problem with generated files in VCS, but I've already created a bug with my last patch trying to remove generated files from git. :-( >8--- --- guix-1.0.0-pre3/po/doc/guix-manual.pot 2019-04-29 22:18:28.0 +0200 +++ src/po/doc/guix-manual.pot 2019-04-29 22:49:06.498766143 +0200 @@ -7,7 +7,7 @@ msgid "" msgstr "" -"Project-Id-Version: guix 1.0.0-pre3\n" +"Project-Id-Version: guix 0.16.0.5796-05344\n" "Report-Msgid-Bugs-To: l...@gnu.org\n" -"POT-Creation-Date: 2019-04-29 22:18+0200\n" +"POT-Creation-Date: 2019-04-29 22:48+0200\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" @@ -18,7 +18,7 @@ "Content-Transfer-Encoding: 8bit\n" -#. #-#-#-#-# contributing.pot (guix 1.0.0-pre3) #-#-#-#-# +#. #-#-#-#-# contributing.pot (guix 0.16.0.5796-05344) #-#-#-#-# #. type: chapter -#. #-#-#-#-# guix.pot (guix 1.0.0-pre3) #-#-#-#-# +#. #-#-#-#-# guix.pot (guix 0.16.0.5796-05344) #-#-#-#-# #. type: menuentry #: doc/contributing.texi:1 doc/contributing.texi:2 doc/guix.texi:138 8<--- [2] Msgfmt output >8--- $ tar xfp guix-1.0.0-pre3.tar.gz $ cd guix-1.0.0-pre3/po/doc/ $ msgfmt --statistics -o /dev/null guix-manual.pot 0 translated messages, 7985 untranslated messages. 8<---
Re: [PATCH 1/2] bootstrap: Break automake dependency on generated files. (was Re: Let’s translate!)
Hi, El Fri, 26 Apr 2019 11:30:04 +0200 Julien Lepiller escribió: > Thank you! I've just pushed it and removed doc/guix.*.texi and > doc/contributing.*.texi from the repository, added them to .gitignore > too. Thank you very much, my emacs and magit will thank you too, as each change in the manual was taking awfully long to refresh. :) Best regards, Miguel
Re: Translation of the Guix manual & node names
El Tue, 23 Apr 2019 18:56:42 -0300 Laura Lazzati escribió: > Hi! Hi Laura, > I'm always late :S > Do you need help with the Spanish translations? I'm not sure how would be the coordination (send me a mail in private if you are interested in that), but at least reviewing of the document and the executable translations would be awesome. Best regards, Miguel
Bootloader localization
Hi everybody! I've been working on these patches and I've been able to generate a derivation with the format expected by Grub during bootloading, use it in the grub.cfg file. I removed the test for the folder inside the configuration file and added a check for the "locale" output during the file generation. Maybe it is not quite elegant, but I'm open to ideas. Now there are 4 patches instead of 3. What do you think? Best regards, Miguel PS: I CC'ed the mailing list too looking for other ideas. El Tue, 23 Apr 2019 15:17:02 +0200 Miguel escribió: > Hello Guix! > > As a Grub translator, I've been hacking a little bit in order to > provide locale information to Grub. I use Guix in a daily basis, as my > main computer operating system, and I this is a key step in order to > provide a better experience to the all kind of users, who may do not > know other languages than their native one. > > My current idea, implemented in the following patches, is something > along these lines: > 1. Store locale information into boot-parameters file. This patch > contains a quite silly test that requires wiser review. > 2. Provide this information to the bootloader at the configuration > time. This, ideally, should provided at installation time too, but > I'm stuck seeing my first messages in english when grub asks for the > whole-disk encryption passphrase as I don't know how to create a > working core.img yet. > 3. Add a snippet to the generated grub.cfg file with the language > information. Some configurations, as /boot in a separate partition, > does not work with this patch, but take it as a proof of concept. > > Lacking points: > 1. No support for other bootloaders yet. I don't know any of them > too much, but I'm unaware of their localization support. > 2. Grub installation process is not transactional enough. I have > some ideas for that, to be discussed in another thread, although one > key point is tightly related with this topic: /boot/grub/locale > generation. Having this folder as a derivation would make explicit > the dependency, but I have to work more on this and I'm open to any > ideas. > > WDYT? > > Best regards, > Miguel
Re: [PATCH 1/2] bootstrap: Break automake dependency on generated files. (was Re: Let’s translate!)
Hi, El Tue, 23 Apr 2019 16:30:26 +0200 Ludovic Courtès escribió: > Hello, > > Julien Lepiller skribis: > > > This is a very good idea, but I think it leaves a stub texi that > > won't get rebuilt because it's younger than po files. What if we > > add a toucgh invocation to reset the modification time of these > > stubs, to ensure make will want to rebuild them? > > Also, I don’t actually use the ./bootstrap script. :-) Currently it is only a call to autoreconf -fvi, but it's there for a reason, isn't it? > Shouldn’t we instead replace the existing %.texi targets in > doc/local.mk with a phony target like ‘update-texi’, and then add: > > dist-hook: update-texi > > ? The procedure needed currently to a new translation for the manual is: 1. modify doc/local.mk, po/doc/local.mk and so on. 2. guix.LL.texi must be manually generated somehow even though it is listed in BUILT_SOURCES. 3. automake can run without errors with the rules in order to generate the actual translated file. 4. The resulting files are committed. The problem is that automake parses .texi files for the @setfilename tag. On the other hand, guix.LL.texi and contributing.LL.texi are generated files, and they shouldn't be on the VCS, just like neither configure nor Makefile.in are, though they are distributed. My patch tries to avoid this issue creating stub files that will be overwritten with the actual content. This has the advantage of keeping clean git status from other modifications than .po files changes. This may sound familiar to this community, it actually is a bootstrap problem. Running autoreconf -fvi actually tells you that that file is missing, so that part is easy to fix. On the other hand, as far as I tested if it does not contain a line with version-LL.texi, version-LL.texi won't be generated. Happy hacking, Miguel
Re: Translation of the Guix manual & node names
El Tue, 23 Apr 2019 15:52:19 +0200
Julien Lepiller escribió:
> Le Tue, 23 Apr 2019 15:33:32 +0200,
> Ludovic Courtès a écrit :
>
> > Hello Miguel & Meiyo,
Hi!
> > Thanks a lot for your translations of the Guix manual!
Thank you too for your effort and kindness.
> > (...)
> > If we look at these, you both translated, for example, the
> > “Packaging Guidelines” string. However, you also left, in your
> > translations, things like “@pxref{Packaging Guidelines}”.
> > (...)
> No, we have a small script that takes care of this. As long as the
> node name is translated somewhere near the beginning of the file, it
> is also automatically translated in the rest of the file. So that
> shouldn't cause an issue. Maybe there's an error in the script?
>
> Look at xref_command in doc/local.mk
>
> Also look at fr.po, I haven't translated most of the node names.
It took me some time getting that, by example from fr.po, of course, but
I think there are some errors or warnings related when you do it wrong.
AFAIK the only problem are some @ref or @xref entries that contain the
link and some text, that actually must be translated. I have to double
check them this week on the translation.
> > Could you please translate all the node names, and make sure that
> > all the cross-reference commands use the same names? (The plan is
> > to release Guix 1.0 in one week, so it would be great if you could
> > send an updated PO file by then!)
I hope having more than only the node names this week. Pretty sure it
won't be the full translation, but I hope reaching 70% at least for
1.0. We'll see...
Happy hacking,
Miguel
Re: [PATCH 1/2] bootstrap: Break automake dependency on generated files. (was Re: Let’s translate!)
Hi Julien,
First of all, thank you for your work.
El Tue, 23 Apr 2019 09:28:19 +0200
Julien Lepiller escribió:
> This is a very good idea, but I think it leaves a stub texi that
> won't get rebuilt because it's younger than po files.
Yes, you are right indeed. I didn't noticed because I was updating
the .po file manually.
> What if we add a toucgh invocation to reset the modification time
> of these stubs, to ensure make will want to rebuild them?
What about the attached patch? I've just tested it with the other
patch that seems to be missing or blocked by its size, nothing up my
sleeves this time. 0:-)
Best regards,
Miguel
>From fe873d65dd5795bdafc9eed66888f7d2e9bf6b4c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?=
Date: Tue, 23 Apr 2019 11:30:32 +0200
Subject: [PATCH 1/4] bootstrap: Break automake dependency on generated files.
* bootstrap: Generate stub files for the manual translations whose
generated files are not included in the VCS.
---
bootstrap | 14 ++
1 file changed, 14 insertions(+)
diff --git a/bootstrap b/bootstrap
index cb774bc737..c0b5af7677 100755
--- a/bootstrap
+++ b/bootstrap
@@ -2,4 +2,18 @@
# Create the build system.
set -e -x
+
+# Generate stubs for translations.
+langs=`find po/doc -type f -name '*.po' \
+| sed -e 's,guix-manual\.,,' \
+| xargs -n 1 -I{} basename {} .po`
+for lang in ${langs}; do
+if [ ! -e "doc/guix.${lang}.texi" ]; then
+ echo "@setfilename guix.${lang}.info" > "doc/guix.${lang}.texi"
+ echo "@include version-${lang}.texi" >> "doc/guix.${lang}.texi"
+ # Ensure .po file is newer.
+ touch "po/doc/guix-manual.${lang}.po"
+fi
+done
+
exec autoreconf -vfi
--
2.21.0
[PATCH 0/2] Removal of generated files (was Re: Let’s translate!)
Hello everybody! I'm currently working on the Spanish translation for the manual, although I will send the guix domain translation as soon as TP coordinators change the assignation. Regarding the translation process, I think we should remove, at least, the generated files from the repository. AFAIK the only show-stopper is automake. It reads the translated files before make invocation, so the manual .texi files are needed for the bootstrap, even though they are listed in BUILT_SOURCES. guix/self.scm scan their content too in order to generate version-LL.texi. Stubs could be generated before calling autoreconf inside bootstrap script. After that change, adding the spanish (or any new) translation should be only matter of applying a patch like the second one, but with more translated content... WDYT? Any ideas about automated synchronization with translationproject.org as make update-po does? Best regards, Miguel
[PATCH 1/2] bootstrap: Break automake dependency on generated files. (was Re: Let’s translate!)
>From c5ed65b04c412a97674dd9129a0cac10500fdf7a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?=
Date: Tue, 23 Apr 2019 00:21:44 +0200
Subject: [PATCH 1/2] bootstrap: Break automake dependency on generated files.
* bootstrap: Generate stub files for the manual translations whose
generated files are not included in the VCS.
---
bootstrap | 12
1 file changed, 12 insertions(+)
diff --git a/bootstrap b/bootstrap
index cb774bc737..62f6cb0fab 100755
--- a/bootstrap
+++ b/bootstrap
@@ -2,4 +2,16 @@
# Create the build system.
set -e -x
+
+# Generate stubs for translations.
+langs=`find po/doc -type f -name '*.po' \
+| sed -e 's,guix-manual\.,,' \
+| xargs -n 1 -I{} basename {} .po`
+for lang in ${langs}; do
+if [ ! -e "doc/guix.${lang}.texi" ]; then
+ echo "@setfilename guix.${lang}.info" > "doc/guix.${lang}.texi"
+ echo "@include version-${lang}.texi" >> "doc/guix.${lang}.texi"
+fi
+done
+
exec autoreconf -vfi
--
2.21.0
[PATCH] gnu: Add font-google-material-design-icons.
--
José Miguel Sánchez GarcíaFrom 8b9659a427ef460d91a985a4d014bef05a0341d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Sun, 12 Feb 2017 12:26:42 +0100
Subject: [PATCH] gnu: Add font-google-material-design-icons.
* gnu/packages/font.scm (font-google-material-design-icons): New
variable.
---
gnu/packages/fonts.scm | 48
1 file changed, 48 insertions(+)
diff --git a/gnu/packages/fonts.scm b/gnu/packages/fonts.scm
index 43991d103..63f43786e 100644
--- a/gnu/packages/fonts.scm
+++ b/gnu/packages/fonts.scm
@@ -1031,3 +1031,51 @@ designed to work well in user interface environments.")
"Font Awesome is a full suite of pictographic icons for easy scalable
vector graphics.")
(license license:silofl1.1)))
+
+(define-public font-google-material-design-icons
+ (package
+ (name "font-google-material-design-icons")
+ (version "3.0.1")
+ (source (origin
+(method url-fetch)
+(uri (string-append
+ "https://github.com/google/material-design-icons/archive/";
+version ".tar.gz"))
+(sha256
+ (base32
+ "183n0qv3q8w6n27libarq1fhc4mqv2d3sasbfmbn7x9r5pw9c6ga"))
+(file-name (string-append name "-" version "-checkout"
+ (build-system trivial-build-system)
+ (native-inputs
+`(("tar" ,tar)
+ ("gzip" ,gzip)))
+ (arguments
+`(#:modules ((guix build utils))
+ #:builder (begin
+ (use-modules (guix build utils))
+ (let* ((font-dir (string-append %output
+ "/share/fonts/truetype"))
+ (source (assoc-ref %build-inputs "source"))
+ (font-filename "MaterialIcons-Regular.ttf")
+ (src-ttf-file (string-append "material-design-icons-"
+ ,version
+ "/iconfont/"
+ font-filename))
+ (dest-ttf-file (string-append font-dir font-filename))
+ (gzip (assoc-ref %build-inputs "gzip"))
+ (tar (assoc-ref %build-inputs "tar")))
+(setenv "PATH" (string-append gzip "/bin:"
+ tar "/bin:"))
+(system* "tar" "xf" source)
+(mkdir-p font-dir)
+(copy-file src-ttf-file dest-ttf-file)
+ (home-page "http://google.github.io/material-design-icons";)
+ (synopsis "Icon font of Google Material Design icons")
+ (description
+"Material design system icons are simple, modern, friendly, and sometimes
+quirky. Each icon is created using our design guidelines to depict in simple
+and minimal forms the universal concepts used commonly throughout a UI.
+Ensuring readability and clarity at both large and small sizes, these icons
+have been optimized for beautiful display on all common platforms and display
+resolutions.")
+ (license license:silofl1.1)))
--
2.11.1
[PATCH] gnu: Add simh.
--
José Miguel Sánchez GarcíaFrom 1b3ed6f71861cc59493cde95171834139317b561 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Sun, 12 Feb 2017 12:33:49 +0100
Subject: [PATCH] gnu: Add simh.
* gnu/packages/simh.scm: New file.
* gnu/local.mk (GNU_SYSTEM_MODULES): Add simh.scm.
---
gnu/local.mk | 1 +
gnu/packages/simh.scm | 96 +++
2 files changed, 97 insertions(+)
create mode 100644 gnu/packages/simh.scm
diff --git a/gnu/local.mk b/gnu/local.mk
index 63ce3af71..7da022a00 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -341,6 +341,7 @@ GNU_SYSTEM_MODULES =\
%D%/packages/serveez.scm \
%D%/packages/shells.scm \
%D%/packages/shellutils.scm \
+ %D%/packages/simh.scm\
%D%/packages/skarnet.scm \
%D%/packages/skribilo.scm \
%D%/packages/slang.scm \
diff --git a/gnu/packages/simh.scm b/gnu/packages/simh.scm
new file mode 100644
index 0..e424b44a0
--- /dev/null
+++ b/gnu/packages/simh.scm
@@ -0,0 +1,96 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2017 José Miguel Sánchez GarcÃa
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages simh)
+ #:use-module ((guix licenses) #:prefix license:)
+ #:use-module (guix packages)
+ #:use-module (guix download)
+ #:use-module (guix build-system gnu)
+ #:use-module (gnu packages admin))
+
+(define-public simh
+ (package
+(name "simh")
+(version "3.9-0")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "https://github.com/"; name "/" name
+ "/archive/v" version ".tar.gz"))
+ (sha256
+ (base32
+"1ymfy8j15d1aa4ai5xv9w7mk6lk4zx3zhfv0mfn66pdhrc8jlh0g"))
+ (file-name (string-append name "-" version "-checkout"
+(build-system gnu-build-system)
+(inputs
+ `(("libpcap" ,libpcap)))
+(arguments
+ '(#:tests? #f
+ #:make-flags (list
+ "LDFLAGS=-lm"
+ (string-append "INCPATH="
+ (assoc-ref %build-inputs "libpcap")
+ "/include")
+ (string-append "LIBPATH="
+ (assoc-ref %build-inputs "libpcap")
+ "/lib"))
+ #:phases
+ (modify-phases %standard-phases
+ (delete 'configure)
+ (add-before 'build 'prepare-build
+ (lambda _
+ (mkdir "BIN")))
+ (replace 'install
+ (lambda* (#:key outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+ (bin (string-append out "/bin/"))
+ (lib (string-append out "/lib/simh/")))
+ (mkdir-p bin)
+ (mkdir-p lib)
+ (for-each
+ (lambda (file)
+ (copy-file file (string-append bin
+"simh-"
+(basename file
+ (find-files "BIN"))
+ (for-each
+ (lambda (file)
+ (copy-file file (string-append lib
+(basename file
+ (find-files "VAX" "bin$"
+(home-page "http://simh.trailing-edge.com";)
+(synopsis "Collection of simulators from The Computer History Simulation
+Project")
+(description
+ "SIMH is a highly portable, multi-system simulator. SIMH implements
+simulators for:
+
+@itemize
+@item Data General Nova, Eclipse.
+@item Digital Equipment Corporation PDP-1, PDP-4, PDP-7, PDP-8, PDP-9, PDP-10,
+PDP-11, PDP-15, VAX.
+@item GRI Corporation GRI-909, GRI-99.
+@item IBM 1401, 1620, 1130, 7090/7094, System 3.
+@item Interdata (Perkin-Elmer) 16b and 32b systems.
+@item Hewlett-Packard 2114, 2115, 2116, 2100, 21MX, 1000.
+@item Honeywell H316/H516.
+@item MITS Altair 8800, with both 8080 and Z80.
+@item Royal-Mcbee LGP-30, LGP-21.
+@item Scientific Data Systems SDS 940.
+@item SWTP 6800.
+@end itemize")
+(license license:expat)))
--
2.11.1
[PATCH] gnu: Update youtube-dl to 2017.02.01.
-- José Miguel Sánchez GarcíaFrom 44bd8d238e6cc44fd8a7a1784787ee5214132097 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?= Date: Sat, 4 Feb 2017 13:52:00 +0100 Subject: [PATCH] gnu: youtube-dl: Update to 2017.02.01 * gnu/packages/video.scm (youtube-dl): Update to 2017.02.01. --- gnu/packages/video.scm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gnu/packages/video.scm b/gnu/packages/video.scm index ccc576063..8cbbb9d76 100644 --- a/gnu/packages/video.scm +++ b/gnu/packages/video.scm @@ -970,7 +970,7 @@ access to mpv's powerful playback capabilities.") (define-public youtube-dl (package (name "youtube-dl") -(version "2017.01.29") +(version "2017.02.01") (source (origin (method url-fetch) (uri (string-append "https://yt-dl.org/downloads/"; @@ -978,7 +978,7 @@ access to mpv's powerful playback capabilities.") version ".tar.gz")) (sha256 (base32 -"0visxc4rb6kw4hjcgcv5llis08z0syhian1m5hr1fdbz4w73hx9l" +"1jkra0kgqg9ks76hwfcfsdaiknr9w8vavja0rc81ia644085axzz" (build-system python-build-system) (arguments ;; The problem here is that the directory for the man page and completion -- 2.11.0
[PATCH] gnu: Add font-awesome.
--
José Miguel Sánchez García
From d4eb96046e2bd0538b16880295a5cd05275de7f8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Sat, 28 Jan 2017 13:42:09 +0100
Subject: [PATCH] gnu: Add font-awesome.
* gnu/packages/fonts.scm (font-awesome): New variable.
---
gnu/packages/fonts.scm | 38 ++
1 file changed, 38 insertions(+)
diff --git a/gnu/packages/fonts.scm b/gnu/packages/fonts.scm
index 29ae579ba..a72c2df79 100644
--- a/gnu/packages/fonts.scm
+++ b/gnu/packages/fonts.scm
@@ -15,6 +15,7 @@
;;; Copyright © 2016 Marius Bakke
;;; Copyright © 2016 Toni Reina
;;; Copyright © 2017 Tobias Geerinckx-Rice
+;;; Copyright © 2017 José Miguel Sánchez García
;;;
;;; This file is part of GNU Guix.
;;;
@@ -996,3 +997,40 @@ designed to work well in user interface environments.")
(synopsis "Mozilla's monospace font")
(description "This is the typeface used by Mozilla in Firefox OS.")
(license license:silofl1.1)))
+
+(define-public font-awesome
+ (package
+ (name "font-awesome")
+ (version "4.7.0")
+ (source (origin
+(method url-fetch)
+(uri (string-append "http://fontawesome.io/assets/";
+name "-" version ".zip"))
+(sha256
+ (base32
+ "1frhmw41lnnm9rda2zs202pvfi5vzlrsw4xfp4mswl0qgws61mcd"
+ (build-system trivial-build-system)
+ (native-inputs
+`(("unzip" ,unzip)))
+ (arguments
+`(#:modules ((guix build utils))
+ #:builder (begin
+ (use-modules (guix build utils))
+ (let* ((font-dir (string-append %output
+ "/share/fonts/opentype"))
+ (source (assoc-ref %build-inputs "source"))
+ (src-otf-file (string-append "font-awesome-"
+ ,version
+
"/fonts/FontAwesome.otf"))
+ (dest-otf-file (string-append font-dir
"/FontAwesome.otf"))
+ (unzip (assoc-ref %build-inputs "unzip")))
+(setenv "PATH" (string-append unzip "/bin"))
+(mkdir-p font-dir)
+(system* "unzip" source "-d" ".")
+(copy-file src-otf-file dest-otf-file)
+ (home-page "http://fontawesome.io";)
+ (synopsis "Font that contains an rich iconset")
+ (description
+"Font Awesome is a full suite of pictographic icons for easy scalable
+vector graphics.")
+ (license license:silofl1.1)))
--
2.11.0
[PATCH] gnu: Add light.
--
José Miguel Sánchez García
From 39adc264a5f2df4ebeaad7879d7005f0831841c3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Sat, 28 Jan 2017 13:07:57 +0100
Subject: [PATCH] gnu: Add light.
* gnu/packages/light.scm: New file.
* gnu/local.mk (GNU_SYSTEM_MODULES): Add light.scm.
---
gnu/local.mk | 1 +
gnu/packages/light.scm | 57 ++
2 files changed, 58 insertions(+)
create mode 100644 gnu/packages/light.scm
diff --git a/gnu/local.mk b/gnu/local.mk
index 59fc1a82c..da7064569 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -225,6 +225,7 @@ GNU_SYSTEM_MODULES =\
%D%/packages/libusb.scm \
%D%/packages/libunwind.scm \
%D%/packages/libupnp.scm \
+ %D%/packages/light.scm \
%D%/packages/lighting.scm \
%D%/packages/links.scm \
%D%/packages/linux.scm \
diff --git a/gnu/packages/light.scm b/gnu/packages/light.scm
new file mode 100644
index 0..4db886588
--- /dev/null
+++ b/gnu/packages/light.scm
@@ -0,0 +1,57 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2017 José Miguel Sánchez García
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages light)
+ #:use-module ((guix licenses) #:prefix license:)
+ #:use-module (guix packages)
+ #:use-module (guix download)
+ #:use-module (guix build-system gnu)
+ #:use-module (gnu packages man))
+
+(define-public light
+ (package
+ (name "light")
+ (version "1.0")
+ (source (origin
+(method url-fetch)
+(uri (string-append "https://github.com/haikarainen/"; name
+"/archive/v" version ".tar.gz"))
+(sha256
+ (base32
+ "0r5gn6c0jcxknzybl6059dplxv46dpahchqq4gymrs7z8bp0hilp"))
+(file-name (string-append name "-" version "-checkout"
+ (build-system gnu-build-system)
+ (arguments
+'(#:tests? #f ; no tests
+ #:make-flags (list "CC=gcc"
+ (string-append "PREFIX=" %output))
+ #:phases
+ (modify-phases %standard-phases
+ (delete 'configure)
+ (add-after 'unpack 'patch-makefile
+(lambda _
+ (substitute* "Makefile" (("chown") "#")))
+ (native-inputs
+`(("help2man" ,help2man)))
+ (home-page "https://haikarainen.github.io/light";)
+ (synopsis "GNU/Linux application to control backlights")
+ (description
+"light is a program to control backlight controllers under GNU/Linux.
+It's the successor of lightscript, which was a bash script with the same
+purpose, and tries to maintain the same functionality.")
+ (license license:gpl3)))
--
2.11.0
[PATCH] gnu: Add compton.
--José Miguel Sánchez García 0001-gnu-Add-compton.patch Description: Binary data
[PATCH: gnu: lua-lpeg: Update to 1.0.1.
-- José Miguel Sánchez García From bead1655bc8c93d34196ba9b024c55058689cd59 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?= Date: Sun, 15 Jan 2017 00:03:33 +0100 Subject: [PATCH] gnu: lua-lpeg: Update to 1.0.1. * gnu/packages/lua.scm (lua-lpeg): Update to 1.0.1. --- gnu/packages/lua.scm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gnu/packages/lua.scm b/gnu/packages/lua.scm index 65c335d37..721eceddf 100644 --- a/gnu/packages/lua.scm +++ b/gnu/packages/lua.scm @@ -371,13 +371,13 @@ Notable examples are GTK+, GStreamer and Webkit.") (define-public lua-lpeg (package (name "lua-lpeg") -(version "1.0.0") +(version "1.0.1") (source (origin (method url-fetch) (uri (string-append "http://www.inf.puc-rio.br/~roberto/lpeg/lpeg-"; version ".tar.gz")) (sha256 - (base32 "13mz18s359wlkwm9d9iqlyyrrwjc6iqfpa99ai0icam2b3khl68h" + (base32 "0sq25z3r324a324ky73izgq9mbf66j2xvjp0fxf227rwxalzgnb2" (build-system gnu-build-system) (arguments `(#:phases -- 2.11.0
Re: [PATCH] gnu: Add nim.
On 2017-01-09 18:09, David Craven wrote: Hi Jose, Some changes I made: * change module name to (gnu packages nim). * reorder imports alphabetically. * added you to the copyright header. * added a comment as to why the tests are disabled. * returned true after substitute* * used (zero? (system* "./install.sh" ... * removed new line after description * added a trailing dot to the commit message headline I don't think we need a separate /opt subfolder, opt is basically /gnu/store for FHS systems. Pushed as 84aafbbb664925ed1a9de3e53238bc54c743a968. Thank you! Thanks for cleaning *the stupid mess* I made with this particular package. Sorry for that, I'll start to calm down and check my patches before submitting. -- José Miguel Sánchez García
Re: [PATCH] gnu: xmonad: Add missing propagated input.
On 2017-01-08 11:56, l...@gnu.org wrote:
Hi!
José Miguel Sánchez García skribis:
On 2017-01-07 22:48, l...@gnu.org wrote:
José Miguel Sánchez García skribis:
xmonad package needs some love, and this is the first step. ghc
should
be a
propagated input, because it's needed for certain commands such as
xmonad --recompile.
Instead of propagating it, would it be possible to hard-code the
absolute file name of ‘ghc’ inside the xmonad source?
That would avoid pulling in GHC in the user’s profile, which could
conflict with the user’s GHC.
Thanks!
Ludo’.
I don't understand. xmonad needs ghc at runtime to compile the
configuration
file (because the configuration file is a binary and XMonad is a
library).
Could you explain better?
Propagated inputs are automatically added to the user’s profile. So
with the patch you suggested, when someone installs xmonad, they’d also
get GHC in their profile. This solves the problem at hand, but it’s
not
great: it “pollutes” the user’s profile, and it could conflict with
another GHC already present in the profile.
Thus, when possible, we often patch patches to do (roughly):
execv("/gnu/store/…/bin/ghc", …);
instead of
execvp("ghc", …);
IOW, we specify the absolute file name of the executable instead of
relying on $PATH lookup.
An example of that is ‘gv’, where we patch the source to refer to the
absolute file name of ‘gs’ instead of looking it up in $PATH:
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gv.scm#n46
Same for ‘egrep’:
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/base.scm#n95
HTH!
Ludo’.
Oh, I see. I've been trying to fix it properly but I can't (I can patch
the
source, but it generates other errors I haven't solved yet). I think
I'll
keep working on the patch on my free time until I can make it work fine.
Thanks Ludo!
--
José Miguel Sánchez García
Re: [PATCH] gnu: Add nim.
On 2017-01-08 14:47, David Craven wrote:
+ (add-before 'install 'create-dest-dirs
+ (lambda* (#:key outputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out")))
+ (mkdir out)
+ (mkdir (string-append out "/bin")
+ (replace 'install
+ (lambda* (#:key outputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out")))
+ (system (string-append "./install.sh " out "/opt"))
+ (symlink
+ (string-append out "/opt/nim/bin/nim")
+ (string-append out "/bin/nim"
Done. Nim is installed in /opt because it's the easiest and
recommended
way of installing it.
What do you think about patching install.sh to not create a nim
subfolder?
Then you could replace these two phases with
+ (lambda* (#:key outputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out")))
+ (system* "./install.sh" out))
It would pollute the root directory, but as it's going to be alone in
his own
directory... I don't know, but here you have another patch that does
exactly
that. If you're going to add it, feel free to choose the one you prefer
(if you
choose the first, change the version, they updated to 0.16.0 ;) )
--
José Miguel Sánchez GarcíaFrom ca6fd2b7fb995b93d3ae96c39952d6445c0bba7f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Mon, 9 Jan 2017 18:15:37 +0100
Subject: [PATCH] gnu: Add nim
* gnu/local.mk (GNU_SYSTEM_MODULES): Add nim.scm.
* gnu/packages/nim.scm: New file.
---
gnu/local.mk | 1 +
gnu/packages/nim.scm | 61
2 files changed, 62 insertions(+)
create mode 100644 gnu/packages/nim.scm
diff --git a/gnu/local.mk b/gnu/local.mk
index cc42a122d..a7b917e6e 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -272,6 +272,7 @@ GNU_SYSTEM_MODULES =\
%D%/packages/networking.scm \
%D%/packages/nfs.scm \
%D%/packages/nickle.scm \
+ %D%/packages/nim.scm \
%D%/packages/ninja.scm \
%D%/packages/node.scm\
%D%/packages/noweb.scm \
diff --git a/gnu/packages/nim.scm b/gnu/packages/nim.scm
new file mode 100644
index 0..0370be68e
--- /dev/null
+++ b/gnu/packages/nim.scm
@@ -0,0 +1,61 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2012 Nikita Karetnikov
+;;; Copyright © 2015, 2016 Efraim Flashner
+;;; Copyright © 2016 Rene Saavedra
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (jmi2k packages nim)
+ #:use-module ((guix licenses) #:prefix license:)
+ #:use-module (guix packages)
+ #:use-module (guix download)
+ #:use-module (guix build-system gnu))
+
+(define-public nim
+ (package
+(name "nim")
+(version "0.16.0")
+(source
+ (origin
+ (method url-fetch)
+ (uri (string-append "http://nim-lang.org/download/";
+ name "-" version ".tar.xz"))
+ (sha256
+ (base32
+"0rsibhkc5n548bn9yyb9ycrdgaph5kq84sfxc9gabjs7pqirh6cy"
+(build-system gnu-build-system)
+(arguments
+ `(#:tests? #f
+ #:phases
+ (modify-phases %standard-phases
+ (delete 'configure)
+ (add-after 'unpack 'patch-installer
+ (lambda* (#:key outputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out")))
+ (substitute* "install.sh"
+ (("1/nim") "1")
+ (replace 'install
+ (lambda* (#:key outputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out")))
+ (system* "./install.sh" out)))
+(home-page "http://nim-lang.org";)
+(synopsis "Statically-typed, imperative programming language")
+(description
+ "Nim (formerly known as Nimrod) is a statically-typed, imperative
+programming language that tries to give the programmer ultimate power without
+compromises on runtime efficiency. This means it focuses on compile-time
+mechanisms in all their various forms.")
+(license license:expat)))
--
2.11.0
Re: [PATCH] gnu: Add nim.
On 2017-01-07 17:41, José Miguel Sánchez García wrote: On 2017-01-07 01:37, José Miguel Sánchez García wrote: On 2017-01-06 17:27, José Miguel Sánchez García wrote: Add the compiler for the Nim programming language <http://nim-lang.org/> I found a mistake I made in the patch, so please wait until I send the fixed version. This one builds but places the binary in the wrong place. Sorry! Done. Nim is installed in /opt because it's the easiest and recommended way of installing it. Last fix, I promise! -- José Miguel Sánchez GarcíaFrom 82fab5f830d6079692c1dcadec0b673d23a53fdd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?= Date: Fri, 6 Jan 2017 17:34:26 +0100 Subject: [PATCH] gnu: Add nim. * gnu/packages/nim.scm: New file. * gnu/local.mk (GNU_SYSTEM_MODULES): Add nim.scm. --- gnu/local.mk | 1 + gnu/packages/nim.scm | 62 2 files changed, 63 insertions(+) create mode 100644 gnu/packages/nim.scm diff --git a/gnu/local.mk b/gnu/local.mk index 2fbb01fb2..289d860e6 100644 --- a/gnu/local.mk +++ b/gnu/local.mk @@ -272,6 +272,7 @@ GNU_SYSTEM_MODULES =\ %D%/packages/networking.scm \ %D%/packages/nfs.scm \ %D%/packages/nickle.scm \ + %D%/packages/nim.scm \ %D%/packages/ninja.scm \ %D%/packages/node.scm\ %D%/packages/noweb.scm \ diff --git a/gnu/packages/nim.scm b/gnu/packages/nim.scm new file mode 100644 index 0..7bbdac45e --- /dev/null +++ b/gnu/packages/nim.scm @@ -0,0 +1,62 @@ +;;; GNU Guix --- Functional package management for GNU +;;; Copyright © 2016 José Miguel Sánchez GarcÃa +;;; +;;; This file is part of GNU Guix. +;;; +;;; GNU Guix is free software; you can redistribute it and/or modify it +;;; under the terms of the GNU General Public License as published by +;;; the Free Software Foundation; either version 3 of the License, or (at +;;; your option) any later version. +;;; +;;; GNU Guix is distributed in the hope that it will be useful, but +;;; WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;;; GNU General Public License for more details. +;;; +;;; You should have received a copy of the GNU General Public License +;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>. + +(define-module (gnu packages nim) + #:use-module ((guix licenses) #:prefix license:) + #:use-module (guix packages) + #:use-module (guix download) + #:use-module (guix build-system gnu)) + +(define-public nim + (package +(name "nim") +(version "0.15.2") +(source + (origin + (method url-fetch) + (uri (string-append "http://nim-lang.org/download/"; + name "-" version ".tar.xz")) + (sha256 + (base32 +"12pyzjx7x4hclzrf3zf6r1qjlp60bzsaqrz0rax2rak2c8qz4pch" +(build-system gnu-build-system) +(arguments + `(#:tests? #f + #:phases + (modify-phases %standard-phases + (delete 'configure) + (add-before 'install 'create-dest-dirs + (lambda* (#:key outputs #:allow-other-keys) + (let ((out (assoc-ref outputs "out"))) + (mkdir out) + (mkdir (string-append out "/bin") + (replace 'install + (lambda* (#:key outputs #:allow-other-keys) + (let ((out (assoc-ref outputs "out"))) + (system (string-append "./install.sh " out "/opt")) + (symlink + (string-append out "/opt/nim/bin/nim") + (string-append out "/bin/nim" +(home-page "http://nim-lang.org";) +(synopsis "Statically-typed, imperative programming language") +(description + "Nim (formerly known as Nimrod) is a statically-typed, imperative +programming language that tries to give the programmer ultimate power without +compromises on runtime efficiency. This means it focuses on compile-time +mechanisms in all their various forms.") +(license license:expat))) -- 2.11.0
Re: [PATCH] gnu: xmonad: Add missing propagated input.
On 2017-01-07 22:48, l...@gnu.org wrote: José Miguel Sánchez García skribis: xmonad package needs some love, and this is the first step. ghc should be a propagated input, because it's needed for certain commands such as xmonad --recompile. Instead of propagating it, would it be possible to hard-code the absolute file name of ‘ghc’ inside the xmonad source? That would avoid pulling in GHC in the user’s profile, which could conflict with the user’s GHC. Thanks! Ludo’. I don't understand. xmonad needs ghc at runtime to compile the configuration file (because the configuration file is a binary and XMonad is a library). Could you explain better? -- José Miguel Sánchez García
Re: [PATCH] gnu: Add nim.
On 2017-01-07 01:37, José Miguel Sánchez García wrote: On 2017-01-06 17:27, José Miguel Sánchez García wrote: Add the compiler for the Nim programming language <http://nim-lang.org/> I found a mistake I made in the patch, so please wait until I send the fixed version. This one builds but places the binary in the wrong place. Sorry! Done. Nim is installed in /opt because it's the easiest and recommended way of installing it. -- José Miguel Sánchez GarcíaFrom 82fab5f830d6079692c1dcadec0b673d23a53fdd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?= Date: Fri, 6 Jan 2017 17:34:26 +0100 Subject: [PATCH] gnu: Add nim. * gnu/packages/nim.scm: New file. * gnu/local.mk (GNU_SYSTEM_MODULES): Add nim.scm. --- gnu/local.mk | 1 + gnu/packages/nim.scm | 62 2 files changed, 63 insertions(+) create mode 100644 gnu/packages/nim.scm diff --git a/gnu/local.mk b/gnu/local.mk index 2fbb01fb2..289d860e6 100644 --- a/gnu/local.mk +++ b/gnu/local.mk @@ -272,6 +272,7 @@ GNU_SYSTEM_MODULES =\ %D%/packages/networking.scm \ %D%/packages/nfs.scm \ %D%/packages/nickle.scm \ + %D%/packages/nim.scm \ %D%/packages/ninja.scm \ %D%/packages/node.scm\ %D%/packages/noweb.scm \ diff --git a/gnu/packages/nim.scm b/gnu/packages/nim.scm new file mode 100644 index 0..7bbdac45e --- /dev/null +++ b/gnu/packages/nim.scm @@ -0,0 +1,62 @@ +;;; GNU Guix --- Functional package management for GNU +;;; Copyright © 2016 José Miguel Sánchez GarcÃa +;;; +;;; This file is part of GNU Guix. +;;; +;;; GNU Guix is free software; you can redistribute it and/or modify it +;;; under the terms of the GNU General Public License as published by +;;; the Free Software Foundation; either version 3 of the License, or (at +;;; your option) any later version. +;;; +;;; GNU Guix is distributed in the hope that it will be useful, but +;;; WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;;; GNU General Public License for more details. +;;; +;;; You should have received a copy of the GNU General Public License +;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>. + +(define-module (jmi2k packages nim) + #:use-module ((guix licenses) #:prefix license:) + #:use-module (guix packages) + #:use-module (guix download) + #:use-module (guix build-system gnu)) + +(define-public nim + (package +(name "nim") +(version "0.15.2") +(source + (origin + (method url-fetch) + (uri (string-append "http://nim-lang.org/download/"; + name "-" version ".tar.xz")) + (sha256 + (base32 +"12pyzjx7x4hclzrf3zf6r1qjlp60bzsaqrz0rax2rak2c8qz4pch" +(build-system gnu-build-system) +(arguments + `(#:tests? #f + #:phases + (modify-phases %standard-phases + (delete 'configure) + (add-before 'install 'create-dest-dirs + (lambda* (#:key outputs #:allow-other-keys) + (let ((out (assoc-ref outputs "out"))) + (mkdir out) + (mkdir (string-append out "/bin") + (replace 'install + (lambda* (#:key outputs #:allow-other-keys) + (let ((out (assoc-ref outputs "out"))) + (system (string-append "./install.sh " out "/opt")) + (symlink + (string-append out "/opt/nim/bin/nim") + (string-append out "/bin/nim" +(home-page "http://nim-lang.org";) +(synopsis "Statically-typed, imperative programming language") +(description + "Nim (formerly known as Nimrod) is a statically-typed, imperative +programming language that tries to give the programmer ultimate power without +compromises on runtime efficiency. This means it focuses on compile-time +mechanisms in all their various forms.") +(license license:expat))) -- 2.11.0
Re: [PATCH] gnu: Add nim.
On 2017-01-06 17:27, José Miguel Sánchez García wrote: Add the compiler for the Nim programming language <http://nim-lang.org/> I found a mistake I made in the patch, so please wait until I send the fixed version. This one builds but places the binary in the wrong place. Sorry! -- José Miguel Sánchez García
[PATCH] gnu: Add nim.
Add the compiler for the Nim programming language <http://nim-lang.org/> -- José Miguel Sánchez GarcíaFrom fd950d2907c649ca4220830fe1431c34bec62e0c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?= Date: Fri, 6 Jan 2017 17:34:26 +0100 Subject: [PATCH] gnu: Add nim. * gnu/packages/nim.scm: New file. * gnu/local.mk (GNU_SYSTEM_MODULES): Add nim.scm. --- gnu/local.mk | 1 + gnu/packages/nim.scm | 54 2 files changed, 55 insertions(+) create mode 100644 gnu/packages/nim.scm diff --git a/gnu/local.mk b/gnu/local.mk index 2fbb01fb2..289d860e6 100644 --- a/gnu/local.mk +++ b/gnu/local.mk @@ -272,6 +272,7 @@ GNU_SYSTEM_MODULES =\ %D%/packages/networking.scm \ %D%/packages/nfs.scm \ %D%/packages/nickle.scm \ + %D%/packages/nim.scm \ %D%/packages/ninja.scm \ %D%/packages/node.scm\ %D%/packages/noweb.scm \ diff --git a/gnu/packages/nim.scm b/gnu/packages/nim.scm new file mode 100644 index 0..5d5ffe1a8 --- /dev/null +++ b/gnu/packages/nim.scm @@ -0,0 +1,54 @@ +;;; GNU Guix --- Functional package management for GNU +;;; Copyright © 2017 José Miguel Sánchez GarcÃa +;;; +;;; This file is part of GNU Guix. +;;; +;;; GNU Guix is free software; you can redistribute it and/or modify it +;;; under the terms of the GNU General Public License as published by +;;; the Free Software Foundation; either version 3 of the License, or (at +;;; your option) any later version. +;;; +;;; GNU Guix is distributed in the hope that it will be useful, but +;;; WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;;; GNU General Public License for more details. +;;; +;;; You should have received a copy of the GNU General Public License +;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>. + +(define-module (gnu packages nim) + #:use-module ((guix licenses) #:prefix license:) + #:use-module (guix packages) + #:use-module (guix download) + #:use-module (guix build-system gnu)) + +(define-public nim + (package +(name "nim") +(version "0.15.2") +(source + (origin + (method url-fetch) + (uri (string-append "http://nim-lang.org/download/"; + name "-" version ".tar.xz")) + (sha256 + (base32 +"12pyzjx7x4hclzrf3zf6r1qjlp60bzsaqrz0rax2rak2c8qz4pch" +(build-system gnu-build-system) +(arguments + `(#:tests? #f + #:phases + (modify-phases %standard-phases + (delete 'configure) + (add-after 'install 'install-binaries + (lambda* (#:key outputs #:allow-other-keys) + (system + (string-append "./install.sh " (assoc-ref outputs "out") "/bin"))) +(home-page "http://www.nim-lang.org";) +(synopsis "Statically-typed, imperative programming language") +(description + "Nim (formerly known as Nimrod) is a statically-typed, imperative +programming language that tries to give the programmer ultimate power without +compromises on runtime efficiency. This means it focuses on compile-time +mechanisms in all their various forms.") +(license license:expat))) -- 2.11.0
[PATCH] gnu: xmonad: Add missing propagated input.
xmonad package needs some love, and this is the first step. ghc should
be a
propagated input, because it's needed for certain commands such as
xmonad --recompile.
Note that the package remains broken and needs more improvements, but I
haven't
been able to solve them yet.
--
José Miguel Sánchez GarcíaFrom c2bd154711abf7945895503b1d8250134792e5b2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Fri, 6 Jan 2017 17:24:07 +0100
Subject: [PATCH] gnu: xmonad: Add missing propagated input.
* gnu/packages/wm.scm (xmonad)[propagated-inputs]: Add ghc.
---
gnu/packages/wm.scm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gnu/packages/wm.scm b/gnu/packages/wm.scm
index 6713560c5..5c44bcff5 100644
--- a/gnu/packages/wm.scm
+++ b/gnu/packages/wm.scm
@@ -343,6 +343,8 @@ prompt.")
("ghc-utf8-string" ,ghc-utf8-string)
("ghc-extensible-exceptions" ,ghc-extensible-exceptions)
("ghc-x11" ,ghc-x11)))
+(propagated-inputs
+ `(("ghc" ,ghc)))
(arguments
`(#:phases
(modify-phases %standard-phases
--
2.11.0
Re: [PATCH] gnu: Add beep.
On 2017-01-04 08:10, Tobias Geerinckx-Rice wrote:
José,
On 02/01/17 20:33, José Miguel Sánchez García wrote:
Add beep command.
Thanks!
-;;; Copyright © 2016 José Miguel Sánchez García...
+;;; Copyright © 2017 José Miguel Sánchez García...
Please keep both years:
;;; Copyright © 2016, 2017 José Miguel Sánchez García...
(base32 "0bgch6jq5cahakk3kbr9549iysf2dik09afixxy5brbxk1xfzb2r"
A bit long, easily solved by moving the hash string to its own line:
(base32
"0bgch6jq5cahakk3kbr9549iysf2dik09afixxy5brbxk1xfzb2r"
; It doesn't install without this
I'd consider that implied, and just drop this comment.
(Future note: since in-line comments like this one aren't considered
full sentences, they don't start with a capital letter. Full-line
comments beginning with ;; are, and do.)
You're also doing more than patching the makefile here. Consider moving
the ‘mkdir-p’ part to a separate, later phase (add-before 'install).
Sorry to ruin your ‘let’ factoring...
(synopsis "Command line utility for Linux that beeps the PC speaker.")
(description "Command line utility for Linux that beeps the PC
speaker.")
I'll trust you that this is indeed Linux-specific: the manual mentions
ioctls, and I can't get it to make a sound from within X :-(
s/command line/command-line/ when used as an adjective.
Descriptions should be between 5 and 10 lines where possible, use full
sentences, and not repeat the synopsis ($ info guix "Synopses and
Descriptions").
Luckily, the first paragraph of the man page makes a pretty good
starting point:
beep allows the user to control the PC speaker with precision,
allowing different sounds to indicate different events. While it can
be run quite happily on the command line, it's intended place of
residence is within shell/perl scripts, notifying the user when
something interesting occurs. Of course, it has no notion of what's
interesting, but it's real good at that notifying part.
I'd re-write the synopsis as ‘Linux command-line utility to control the
PC speaker’. It does a tad more than just beep, even if it's the
musical
equivalent of burping the alphabet.
(home-page "http://www.johnath.com/beep";)
^^^
Your package is missing a few brackets. Did the patch get truncated?
Kind regards,
T G-R
I've applied your changes, ran guix lint and tested it. Here you have
the fixed patch.
--
José Miguel Sánchez GarcíaFrom ad6b9c735a45738c798a0c677ebc9e4062e17aef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Thu, 5 Jan 2017 00:23:18 +0100
Subject: [PATCH] gnu: Add beep.
* gnu/packages/terminals.scm (beep): New variable.
---
gnu/packages/terminals.scm | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index 52767ba6c..dd4142ac8 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -4,7 +4,7 @@
;;; Copyright © 2016 Alex Griffin
;;; Copyright © 2016 David Craven
;;; Copyright © 2016 Ludovic Courtès
-;;; Copyright © 2016 José Miguel Sánchez GarcÃa
+;;; Copyright © 2016, 2017 José Miguel Sánchez GarcÃa
;;;
;;; This file is part of GNU Guix.
;;;
@@ -326,3 +326,37 @@ configuration, testing, and debugging tool. It has also serves well
as a low-tech serial communications program to allow access to all
types of devices that provide serial consoles.")
(license license:gpl2+)))
+
+(define-public beep
+ (package
+(name "beep")
+(version "1.3")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "http://www.johnath.com/"; name "/"
+ name "-" version ".tar.gz"))
+ (sha256
+ (base32
+ "0bgch6jq5cahakk3kbr9549iysf2dik09afixxy5brbxk1xfzb2r"
+(build-system gnu-build-system)
+(arguments
+ `(#:tests? #f ; no tests.
+ #:phases
+ (modify-phases %standard-phases
+ (delete 'configure)
+ (add-after 'unpack 'patch-makefile
+ (lambda _
+ (substitute* "Makefile" (("/usr") (assoc-ref %outputs "out")
+ (add-before 'install 'create-dest-dirs
+ (lambda _
+ (mkdir-p (string-append (assoc-ref %outputs "out") "/bin"))
+ (mkdir-p (string-append (assoc-ref %outputs "out") "/man/man1")))
+(synopsis "Linux command-line utilitu to control the PC speaker")
+(description "beep allows the user to control the PC speaker with precision,
+allowing different sounds to indic
Re: [PATCH] gnu: Add beep.
On 2017-01-02 20:10, José Miguel Sánchez García wrote:
Add beep command.
Quick edit: Remove redundant (assoc-ref %outputs "out") with a let
binding.
--
José Miguel Sánchez GarcíaFrom 777c91a14817929d37e4cc60a80f3b3f078fe9a4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez?=
Date: Mon, 2 Jan 2017 20:27:42 +0100
Subject: [PATCH] gnu: Add beep.
* gnu/packages/terminals (beep): New variable.
---
gnu/packages/terminals.scm | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index 52767ba..0bb75a5 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -4,7 +4,7 @@
;;; Copyright © 2016 Alex Griffin
;;; Copyright © 2016 David Craven
;;; Copyright © 2016 Ludovic Courtès
-;;; Copyright © 2016 José Miguel Sánchez GarcÃa
+;;; Copyright © 2017 José Miguel Sánchez GarcÃa
;;;
;;; This file is part of GNU Guix.
;;;
@@ -326,3 +326,29 @@ configuration, testing, and debugging tool. It has also serves well
as a low-tech serial communications program to allow access to all
types of devices that provide serial consoles.")
(license license:gpl2+)))
+
+(define-public beep
+ (package
+(name "beep")
+(version "1.3")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "http://www.johnath.com/"; name "/"
+ name "-" version ".tar.gz"))
+ (sha256
+ (base32 "0bgch6jq5cahakk3kbr9549iysf2dik09afixxy5brbxk1xfzb2r"
+(build-system gnu-build-system)
+(arguments
+ `(#:tests? #f ; No tests.
+ #:phases
+ (modify-phases %standard-phases
+ (delete 'configure)
+ (add-after 'unpack 'patch-makefile ; It doesn't install without this
+ (let ((out (assoc-ref %outputs "out")))
+ (lambda _
+ (mkdir-p (string-append out "/bin"))
+ (mkdir-p (string-append out "/man/man1"))
+ (substitute* "Makefile" (("/usr") out
+(synopsis "Command line utility for Linux that beeps the PC speaker.")
+(description "Command line utility for Linux that beeps the PC speaker.")
+(home-page "http://www.johnath.com/beep";)
--
2.10.1.windows.1
[PATCH] gnu: Add beep.
Add beep command.
--
José Miguel Sánchez GarcíaFrom 62188944da4e42ed46662ca2cc812cced70b0aed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Mon, 2 Jan 2017 20:52:24 +0100
Subject: [PATCH] gnu: Add beep.
* gnu/packages/terminals.scm (beep): New variable.
---
gnu/packages/terminals.scm | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index 52767ba6c..641725bda 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -4,7 +4,7 @@
;;; Copyright © 2016 Alex Griffin
;;; Copyright © 2016 David Craven
;;; Copyright © 2016 Ludovic Courtès
-;;; Copyright © 2016 José Miguel Sánchez GarcÃa
+;;; Copyright © 2017 José Miguel Sánchez GarcÃa
;;;
;;; This file is part of GNU Guix.
;;;
@@ -326,3 +326,29 @@ configuration, testing, and debugging tool. It has also serves well
as a low-tech serial communications program to allow access to all
types of devices that provide serial consoles.")
(license license:gpl2+)))
+
+(define-public beep
+ (package
+(name "beep")
+(version "1.3")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "http://www.johnath.com/"; name "/"
+ name "-" version ".tar.gz"))
+ (sha256
+ (base32 "0bgch6jq5cahakk3kbr9549iysf2dik09afixxy5brbxk1xfzb2r"
+(build-system gnu-build-system)
+(arguments
+ `(#:tests? #f ; No tests.
+ #:phases
+ (modify-phases %standard-phases
+ (delete 'configure)
+ (add-after 'unpack 'patch-makefile ; It doesn't install without this
+ (lambda _
+ (mkdir-p (string-append (assoc-ref %outputs "out") "/bin"))
+ (mkdir-p (string-append (assoc-ref %outputs "out") "/man/man1"))
+ (substitute* "Makefile" (("/usr") (assoc-ref %outputs "out"
+(synopsis "Command line utility for Linux that beeps the PC speaker.")
+(description "Command line utility for Linux that beeps the PC speaker.")
+(home-page "http://www.johnath.com/beep";)
+(license license:gpl2+)))
--
2.11.0
[PATCH] gnu: libtermkey: Update to 0.19.
Just changed the version string from 0.18 to 0.19.
--
José Miguel Sánchez GarcíaFrom 89893f7c39c64a12a5b0f82e96c3cc9fac982730 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Thu, 29 Dec 2016 19:08:13 +
Subject: [PATCH] gnu: libtermkey: Update to 0.19.
* gnu/packages/terminals.scm (libtermkey): Update to 0.19.
---
gnu/packages/terminals.scm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index efedba480..9a70e109e 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -266,7 +266,7 @@ multi-seat support, a replacement for @command{mingetty}, and more.")
(define-public libtermkey
(package
(name "libtermkey")
-(version "0.18")
+(version "0.19")
(source (origin
(method url-fetch)
(uri (string-append "http://www.leonerd.org.uk/code/";
--
2.11.0
[PATCH] gnu: Fix asciinema build.
Tiny fix: add python-requests to the inputs field.
--
José Miguel Sánchez GarcíaFrom cdad51eefcfe5c193fc7efb37cb271195feab310 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Wed, 7 Dec 2016 19:04:23 +0100
Subject: [PATCH] gnu: Fix asciinema build.
* gnu/packages/terminals.scm (asciinema)[inputs]: Add python-requests.
---
gnu/packages/terminals.scm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index e1076c7..67ad7eb 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -161,7 +161,8 @@ insert mode and command mode where keybindings have different functions.")
(("'tput'")
(string-append "'" ncurses "/bin/tput'"
#t)
-(inputs `(("ncurses" ,ncurses)))
+(inputs `(("ncurses" ,ncurses)
+ ("python-requests" ,python-requests)))
(home-page "https://asciinema.org";)
(synopsis "Terminal session recorder")
(description
--
2.9.2
[PATCH] gnu: Add vis, libtermkey and lua-lpeg.
Let's see if these patches get accepted now! I think I've taken into
account
every single detail.
These patches add three packages: vis, lua and libtermkey. vis depends
on lua
and libtermkey, so add them before adding vis.
vis is being added in a new file, gnu/text-editors.scm , as requested
here
<https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00242.html>
--
José Miguel Sánchez GarcíaFrom ce03e4d1418580d353cdb58233550ece380ff2ba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Wed, 7 Dec 2016 18:03:09 +0100
Subject: [PATCH] gnu: Add libtermkey.
---
gnu/packages/terminals.scm | 30 ++
1 file changed, 30 insertions(+)
diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index e1076c7..907fc7b 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -4,6 +4,7 @@
;;; Copyright © 2016 Alex Griffin
;;; Copyright © 2016 David Craven
;;; Copyright © 2016 Ludovic Courtès
+;;; Copyright © 2016 José Miguel Sánchez GarcÃa
;;;
;;; This file is part of GNU Guix.
;;;
@@ -261,6 +262,35 @@ multi-seat support, a replacement for @command{mingetty}, and more.")
(supported-systems (filter (cut string-suffix? "-linux" <>)
%supported-systems
+(define-public libtermkey
+ (package
+(name "libtermkey")
+(version "0.18")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "http://www.leonerd.org.uk/code/";
+ name "/" name "-" version ".tar.gz"))
+ (sha256
+(base32 "09ir16kaarv55mnc4jn2sqnjjhzpb1aha51wpd9ayif887g4d5r3"
+(build-system gnu-build-system)
+(arguments
+ '(#:make-flags (list
+ "CC=gcc"
+ (string-append "PREFIX=" (assoc-ref %outputs "out")))
+#:phases (modify-phases %standard-phases
+ (delete 'configure))
+;; `make test` isn't available
+#:tests? #f))
+(inputs `(("ncurses", ncurses)))
+(native-inputs `(("libtool", libtool)
+ ("pkg-config", pkg-config)))
+(synopsis "Keyboard entry processing library for terminal-based programs")
+(description
+ "Libtermkey handles all the necessary logic to recognise special keys, UTF-8
+combining, and so on, with a simple interface.")
+(home-page "http://www.leonerd.org.uk/code/libtermkey";)
+(license license:expat)))
+
(define-public picocom
(package
(name "picocom")
--
2.9.2
From d3903d74e6ff21afcfd401ed99c7957b3d7dbf16 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Wed, 7 Dec 2016 18:06:22 +0100
Subject: [PATCH] gnu: Add lua-lpeg.
---
gnu/packages/lua.scm | 30 ++
1 file changed, 30 insertions(+)
diff --git a/gnu/packages/lua.scm b/gnu/packages/lua.scm
index f95da35..222e655 100644
--- a/gnu/packages/lua.scm
+++ b/gnu/packages/lua.scm
@@ -7,6 +7,7 @@
;;; Copyright © 2016 Ricardo Wurmus
;;; Copyright © 2016 doncatnip
;;; Copyright © 2016 Clément Lassieur
+;;; Copyright © 2016 José Miguel Sánchez GarcÃa
;;;
;;; This file is part of GNU Guix.
;;;
@@ -365,3 +366,32 @@ secure session between the peers.")
based libraries. It allows using GObject-based libraries directly from Lua.
Notable examples are GTK+, GStreamer and Webkit.")
(license license:expat)))
+
+(define-public lua-lpeg
+ (package
+(name "lua-lpeg")
+(version "1.0.0")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "http://www.inf.puc-rio.br/~roberto/lpeg/lpeg-";
+ version ".tar.gz"))
+ (sha256
+(base32 "13mz18s359wlkwm9d9iqlyyrrwjc6iqfpa99ai0icam2b3khl68h"
+(build-system gnu-build-system)
+(arguments
+ '(#:phases (modify-phases %standard-phases
+(delete 'configure)
+;; `make install` isn't available, so we have to do it manually
+(replace 'install (lambda _
+ (let ((out (assoc-ref %outputs "out")))
+(install-file "lpeg.so" (string-append out "/lib/lua/5.3"))
+(install-file "re.lua" (string-append out "/share/lua/5.3"))
+ ;; `make test` isn't available
+ #:tests? #f))
+(inputs `(("lua", lua)))
+(synopsis "Pattern-matching library for Lua")
+(description
+ "LPeg is a pattern-matching library for Lua, based on Parsing Expression
+Grammars (PEGs).")
+(home-page "http
[PATCH] gnu: Add lua-lpeg
Add lua-lpeg (I hope it's finally correct!)
--
José Miguel Sánchez García
From 4ebd6648b2dcf1e02d39532173781b91850e4f41 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Mon, 5 Dec 2016 15:15:33 +0100
Subject: [PATCH] gnu: Add lua-lpeg
---
gnu/packages/lua-lpeg.scm | 52 +++
1 file changed, 52 insertions(+)
create mode 100644 gnu/packages/lua-lpeg.scm
diff --git a/gnu/packages/lua-lpeg.scm b/gnu/packages/lua-lpeg.scm
new file mode 100644
index 000..50042bd
--- /dev/null
+++ b/gnu/packages/lua-lpeg.scm
@@ -0,0 +1,51 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 José Miguel Sánchez GarcÃa
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages lua-lpeg)
+ #:use-module (guix packages)
+ #:use-module (guix download)
+ #:use-module (guix build-system gnu)
+ #:use-module (guix licenses)
+ #:use-module (gnu packages lua))
+
+(define-public lua-lpeg
+ (package
+(name "lua-lpeg")
+(version "1.0.0")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "http://www.inf.puc-rio.br/~roberto/lpeg/lpeg-";
+ version ".tar.gz"))
+ (sha256
+(base32 "13mz18s359wlkwm9d9iqlyyrrwjc6iqfpa99ai0icam2b3khl68h"
+(build-system gnu-build-system)
+(arguments '(
+ #:make-flags '("LUADIR=/usr/include")
+ #:phases (modify-phases %standard-phases
+(delete 'configure)
+(replace 'install (lambda _
+ (let* ((out (assoc-ref %outputs "out")))
+(install-file "lpeg.so" (string-append out "/usr/lib/lua/5.3"))
+(install-file "re.lua" (string-append out "/usr/share/lua/5.3"))
+ #:tests? #f))
+(inputs `(("lua", lua)))
+(synopsis "Pattern-matching library for Lua")
+(description
+ "LPeg is a pattern-matching library for Lua, based on Parsing Expression
+Grammars (PEGs).")
+(home-page "http://www.inf.puc-rio.br/~roberto/lpeg";)
+(license expat)))
--
1.9.1
[PATCH] gnu: Add vis
Add vis (I hope it's finally correct!). Remember to add it after adding
libtermkey and lua-lpeg.
--
José Miguel Sánchez García
From 9bdbc2064c0dc62e66291d18718932ca8b7f67f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Mon, 5 Dec 2016 15:17:40 +0100
Subject: [PATCH] gnu: Add vis.
---
gnu/packages/vis.scm | 58
1 file changed, 58 insertions(+)
create mode 100644 gnu/packages/vis.scm
diff --git a/gnu/packages/vis.scm b/gnu/packages/vis.scm
new file mode 100644
index 000..39150dc
--- /dev/null
+++ b/gnu/packages/vis.scm
@@ -0,0 +1,57 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 José Miguel Sánchez GarcÃa
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
+
+; TODO: Installation succeeds, but vis complains about not finding base16-theme
+
+(define-module (gnu packages vis)
+ #:use-module (guix packages)
+ #:use-module (guix git-download)
+ #:use-module (guix build-system gnu)
+ #:use-module (guix licenses)
+ #:use-module (gnu packages ncurses)
+ #:use-module (gnu packages libtermkey)
+ #:use-module (gnu packages lua)
+ #:use-module (gnu packages lua-lpeg))
+
+(define-public vis
+ (package
+(name "vis")
+(version "0.2")
+(source (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url (string-append "git://github.com/martanne/"
+ name ".git"))
+ (commit (string-append "v" version
+ (sha256
+(base32 "05pxycrhx297hdwkgky00g9s78dqcaam3lhp3ba903ma605dn34f"
+(build-system gnu-build-system)
+(arguments '(
+ #:make-flags '("CFLAGS=-pie")
+ #:tests? #f))
+(inputs `(("lua", lua)))
+(native-inputs `(("ncurses", ncurses)
+ ("libtermkey", libtermkey)
+ ("lua-lpeg", lua-lpeg)))
+(synopsis "Vim-like text editor")
+(description
+ "Vis aims to be a modern, legacy free, simple yet efficient vim-like text
+editor. It extends vim's modal editing with built-in support for multiple
+cursors/selecctions and combines it with sam's structural regular expression
+based command language.")
+(home-page "https://github.com/martanne/vis";)
+(license isc)))
--
1.9.1
[PATCH] gnu: Add libtermkey
Add libtermkey (I hope it's finally correct!)
--
José Miguel Sánchez GarcíaFrom 8ad5713a25aeb40b9021b30beba7b11d3cf432df Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Mon, 5 Dec 2016 15:12:56 +0100
Subject: [PATCH] gnu: Add libtermkey.
---
gnu/packages/libtermkey.scm | 54 +
1 file changed, 54 insertions(+)
create mode 100644 gnu/packages/libtermkey.scm
diff --git a/gnu/packages/libtermkey.scm b/gnu/packages/libtermkey.scm
new file mode 100644
index 000..e3280ca
--- /dev/null
+++ b/gnu/packages/libtermkey.scm
@@ -0,0 +1,54 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 José Miguel Sánchez GarcÃa
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages libtermkey)
+ #:use-module (guix packages)
+ #:use-module (guix download)
+ #:use-module (guix build-system gnu)
+ #:use-module (guix licenses)
+ #:use-module (gnu packages autotools)
+ #:use-module (gnu packages ncurses)
+ #:use-module (gnu packages pkg-config))
+
+(define-public libtermkey
+ (package
+(name "libtermkey")
+(version "0.18")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "http://www.leonerd.org.uk/code/";
+ name "/" name "-" version ".tar.gz"))
+ (sha256
+(base32 "09ir16kaarv55mnc4jn2sqnjjhzpb1aha51wpd9ayif887g4d5r3"
+(build-system gnu-build-system)
+(arguments '(
+ #:make-flags (list
+"CC=gcc"
+(string-append "PREFIX=" (assoc-ref %outputs "out")))
+ #:phases (modify-phases %standard-phases
+(delete 'configure))
+ #:tests? #f))
+(native-inputs `(("libtool", libtool)
+ ("ncurses", ncurses)
+ ("pkg-config", pkg-config)))
+(synopsis "Keyboard entry processing libary for terminal-based programs")
+(description
+ "Libtermkey handles all the necessary logic to recognise special keys, UTF-8
+combining, and so on, with a simple interface.")
+(home-page "http://www.leonerd.org.uk/code/libtermkey";)
+(license expat)))
--
1.9.1
[PATCH] gnu: Add vis.
Add vis after fixing some inconveniences found in my last attempt
<http://lists.gnu.org/archive/html/guix-devel/2016-12/msg00068.html>. I
can't run guix lint on it now, but I haven't changed anything too
important, so it should be fine.
This package requires libtermkey and lua-lpeg, for which I submitted two
patches (see my last two messages). Be sure to add them before.
José Miguel Sánchez García
From 9bdbc2064c0dc62e66291d18718932ca8b7f67f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Mon, 5 Dec 2016 15:17:40 +0100
Subject: [PATCH] gnu: Add vis.
---
gnu/packages/vis.scm | 57
1 file changed, 57 insertions(+)
create mode 100644 gnu/packages/vis.scm
diff --git a/gnu/packages/vis.scm b/gnu/packages/vis.scm
new file mode 100644
index 000..39150dc
--- /dev/null
+++ b/gnu/packages/vis.scm
@@ -0,0 +1,57 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 José Miguel Sánchez GarcÃa
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
+
+; TODO: Installation succeeds, but vis complains about not finding base16-theme
+
+(define-module (gnu packages vis)
+ #:use-module (guix packages)
+ #:use-module (guix git-download)
+ #:use-module (guix build-system gnu)
+ #:use-module (guix licenses)
+ #:use-module (gnu packages ncurses)
+ #:use-module (gnu packages libtermkey)
+ #:use-module (gnu packages lua)
+ #:use-module (gnu packages lua-lpeg))
+
+(define-public vis
+ (package
+(name "vis")
+(version "0.2")
+(source (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "git://github.com/martanne/vis.git")
+ (commit "v0.2")))
+ (sha256
+(base32 "05pxycrhx297hdwkgky00g9s78dqcaam3lhp3ba903ma605dn34f"
+(build-system gnu-build-system)
+(arguments '(
+ #:make-flags '("CFLAGS=-pie")
+ #:tests? #f))
+(inputs `(("lua", lua)))
+(native-inputs `(("ncurses", ncurses)
+ ("libtermkey", libtermkey)
+ ("lua-lpeg", lua-lpeg)))
+(synopsis "Vim-like text editor")
+(description
+ "Vis aims to be a modern, legacy free, simple yet efficient vim-like text
+editor. It extends vim's modal editing with built-in support for multiple
+cursors/selecctions and combines it with sam's structural regular expression
+based command language.")
+(home-page "https://github.com/martanne/vis";)
+(license isc)))
--
1.9.1
[PATCH] gnu: Add lua-lpeg.
Add lua-lpeg after fixing some inconveniences found in my last attempt
<http://lists.gnu.org/archive/html/guix-devel/2016-12/msg00068.html>. I
can't run guix lint on it now, but I haven't changed anything too
important, so it should be fine.
José Miguel Sánchez García
From 4ebd6648b2dcf1e02d39532173781b91850e4f41 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Mon, 5 Dec 2016 15:15:33 +0100
Subject: [PATCH] gnu: Add lua-lpeg
---
gnu/packages/lua-lpeg.scm | 51 +++
1 file changed, 51 insertions(+)
create mode 100644 gnu/packages/lua-lpeg.scm
diff --git a/gnu/packages/lua-lpeg.scm b/gnu/packages/lua-lpeg.scm
new file mode 100644
index 000..50042bd
--- /dev/null
+++ b/gnu/packages/lua-lpeg.scm
@@ -0,0 +1,51 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 José Miguel Sánchez GarcÃa
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages lua-lpeg)
+ #:use-module (guix packages)
+ #:use-module (guix download)
+ #:use-module (guix build-system gnu)
+ #:use-module (guix licenses)
+ #:use-module (gnu packages lua))
+
+(define-public lua-lpeg
+ (package
+(name "lua-lpeg")
+(version "1.0.0")
+(source (origin
+ (method url-fetch)
+ (uri "http://www.inf.puc-rio.br/~roberto/lpeg/lpeg-1.0.0.tar.gz";)
+ (sha256
+(base32 "13mz18s359wlkwm9d9iqlyyrrwjc6iqfpa99ai0icam2b3khl68h"
+(build-system gnu-build-system)
+(arguments '(
+ #:make-flags '("LUADIR=/usr/include")
+ #:phases (modify-phases %standard-phases
+(delete 'configure)
+(replace 'install (lambda _
+ (let* ((out (assoc-ref %outputs "out")))
+(install-file "lpeg.so" (string-append out "/usr/lib/lua/5.3"))
+(install-file "re.lua" (string-append out "/usr/share/lua/5.3"))
+ #:tests? #f))
+(inputs `(("lua", lua)))
+(synopsis "Pattern-matching library for Lua")
+(description
+ "LPeg is a pattern-matching library for Lua, based on Parsing Expression
+Grammars (PEGs).")
+(home-page "http://www.inf.puc-rio.br/~roberto/lpeg";)
+(license expat)))
--
1.9.1
[PATCH] gnu: Add libtermkey.
Add libtermkey after fixing some inconveniences found in my last attempt
<http://lists.gnu.org/archive/html/guix-devel/2016-12/msg00068.html>. I
can't run guix lint on it now, but I haven't changed anything too
important, so it should be fine.
José Miguel Sánchez García
From 8ad5713a25aeb40b9021b30beba7b11d3cf432df Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
Date: Mon, 5 Dec 2016 15:12:56 +0100
Subject: [PATCH] gnu: Add libtermkey.
---
gnu/packages/libtermkey.scm | 54 +
1 file changed, 54 insertions(+)
create mode 100644 gnu/packages/libtermkey.scm
diff --git a/gnu/packages/libtermkey.scm b/gnu/packages/libtermkey.scm
new file mode 100644
index 000..e3280ca
--- /dev/null
+++ b/gnu/packages/libtermkey.scm
@@ -0,0 +1,54 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 José Miguel Sánchez GarcÃa
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages libtermkey)
+ #:use-module (guix packages)
+ #:use-module (guix download)
+ #:use-module (guix build-system gnu)
+ #:use-module (guix licenses)
+ #:use-module (gnu packages autotools)
+ #:use-module (gnu packages ncurses)
+ #:use-module (gnu packages pkg-config))
+
+(define-public libtermkey
+ (package
+(name "libtermkey")
+(version "0.18")
+(source (origin
+ (method url-fetch)
+ (uri "http://www.leonerd.org.uk/code/libtermkey/libtermkey-0.18.tar.gz";)
+ (sha256
+(base32 "09ir16kaarv55mnc4jn2sqnjjhzpb1aha51wpd9ayif887g4d5r3"
+(build-system gnu-build-system)
+(arguments '(
+ #:make-flags (list
+"CC=gcc"
+(string-append "PREFIX=" (assoc-ref %outputs "out")))
+ #:phases (modify-phases %standard-phases
+(delete 'configure))
+ #:tests? #f))
+(inputs `())
+(native-inputs `(("libtool", libtool)
+ ("ncurses", ncurses)
+ ("pkg-config", pkg-config)))
+(synopsis "Keyboard entry processing libary for terminal-based programs")
+(description
+ "Libtermkey handles all the necessary logic to recognise special keys, UTF-8
+combining, and so on, with a simple interface.")
+(home-page "http://www.leonerd.org.uk/code/libtermkey";)
+(license expat)))
--
1.9.1
