Re: Video narration
Hi Paul ;) > Thank you. I will also check through the transcripts and make any > slight changes needed to make the narration more-natural-for-me to > speak. I will be careful not to alter the timings or meanings. Thank you. The transcripts have a timing as an idea, but speak spontaneously, like you normally do. And of course you are welcome to make changes to sound more natural :) I will start git pulling before making some comments. > Also, I will have more information on Wednesday about the time slots > available for the recording process. Please, let me know whatever information you need and also that you can share. And sorry for the delay. My recording process is difficult: I use my headsets in my phone, try to avoid environmental noise as much as possible, then I put it on my computer and change the format to mp3. Tried Audacity but my recording sounds horrible. Regards :) Laura PS: please git pull because I go on adding/updating stuff :)
Re: Video narration
Hi Laura, > I have realized that I have a typo and have to make a minor change in > 04-packaging2, that will affect the audio and of course the > transcript. Just wanted to let you know. Will push it ASAP. Thank you. I will also check through the transcripts and make any slight changes needed to make the narration more-natural-for-me to speak. I will be careful not to alter the timings or meanings. Also, I will have more information on Wednesday about the time slots available for the recording process. Best regards, Paul.
Re: packaging - sentences in description
Thanks Tobias, and also to you, Julien! now mi package lints like a charm! Tobias Geerinckx-Rice writes: [...] >> I copy/pasted and adapted the description from the project >> homepage, >> I'm using emacs and auto-fill mode on so it should have followed >> the >> rules in .dir-locals.el > > These rules are for formatting Scheme code, they won't touch the > insides of strings. they help to auto-fill strings also, but don't help with (my lack of knowledge about) proper sentences handling I live in emacs but was still not aware (among too much other things) of https://www.gnu.org/software/emacs/manual/html_node/emacs/Sentences.html#Sentences IMHO we need to add this info in https://www.gnu.org/software/guix/manual/en/html_node/Synopses-and-Descriptions.html#Synopses-and-Descriptions (valid for non-emacs users also) I can send a patch if agreed :-) [...] >> I can't understand where the sentences in my description lacks >> the two required spaces: any hint please? > > Everywhere? :-p eh :-) [...] >> [1] it takes more than five minutes just for the description: I >> will >> diligently do it for all my packages :-)... but it's a little >> bit >> discouraging :-S > > I can sympathise, but it's not that much work compared to writing > code, and about as important. for sure! I'll meditate meanwhile :-D [...] Thanks! Gio -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: gold linker and collect2: fatal error: cannot find 'ld'
On Sun, Mar 17, 2019 at 05:06:16PM +0100, Pjotr Prins wrote: > Unfortunately the runtime of compiled software fails because the rpath is > not updated either. So that requires adding in the RPATH explicitly on > the ldc command line. When I set the RPATH the runtime is fine. Reading up on the ld-wrapper code - that is exactly what happens. A gold-wrapper can do same. I think, like with rustc, I need to wrap the ldc compiler build with ld-wrapper and the ldc tests with gold-wrapper (yet to be written). gold does not honour LIBRARY_PATH so that means we'll have to use LD_LIBRARY_PATH or pass the lib path(s) on the command line. Does this make sense? If it does we can make an attempt. Pj.
Re: SANE / simple-scan working for anyone?
Huh, Tobias Geerinckx-Rice wrote: From the sane-backends change log: “Note 3: The Linux USB3 workaround which was added in version 1.0.25 is now disabled by default. If you have difficulty using a scanner which previously worked, or intermittent scanner availability, try setting the new environment variable SANE_USB_WORKAROUND=1 before starting your frontend.” I'll try that when I'm reunited with mine. This actually worked. Or at least, simple-scan suddenly started scanning after launching it a second time, with this variable set. Kind regards, T G-R
Re: Libre games that might be worth packaging :)
Ricardo Wurmus writes: > Pierre Neidhardt writes: >> It's named "armagetronad". Shouldn't we name this >> "armagetron-advanced"? > > Instead of renaming the packages (whose names follow our packaging > guidelines) how about adding the full name of the games to the > description? That would not help interfaces like Emacs-Guix and Helm-System-Packages. I think names are more important than having obsolete packages :) -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Libre games that might be worth packaging :)
swedebugia writes: > Hi! > > I just went through Julie Marchants excellent list of libre games: > https://onpon4.github.io/articles/libre-games.html > > There are so many! :) > I have packages for Adanaxis, Alex the Allegator 4, B.A.L.L.Z., Criticalmass and Dopewars. I'll clean them up and upload them when I can. signature.asc Description: PGP signature
Re: packaging - sentences in description
Giovanni Biscuolo wrote: (description "Golang package for conveniently using named read/write locks. These appear to be especially useful for synchronizing access to session based information in web applications. The common use case is to use the package level functions, which use a package level set of locks (safe to use from multiple goroutines simultaneously). However, you may also create a new separate set of locks test. All locks are implemented with read-write mutexes. To use them like a regular mutex, simply ignore the RLock/RUnlock functions.") (license license:public-domain --8<---cut here---end--->8--- it builds but when I check its description I get [1]: --8<---cut here---start->8--- giovanni@anemone: time ./pre-inst-env guix lint -c description go-github-com-burntsushi-locker gnu/packages/golang.scm:3202:19: go-github-com-burntsushi-locker@0.0.0-0.a6e239e: sentences in description should be followed by two spaces; possible infractions at 60, 329, 447 […] --8<---cut here---end--->8--- I copy/pasted and adapted the description from the project homepage, I'm using emacs and auto-fill mode on so it should have followed the rules in .dir-locals.el These rules are for formatting Scheme code, they won't touch the insides of strings. (Which isn't to say there isn't some M-x double-my-spaces somewhere that I don't know of…) I can't understand where the sentences in my description lacks the two required spaces: any hint please? Everywhere? :-p Instead. Of. Like. This. ^ ^ ^ We. Write. Like. This. ^^ ^^ ^^ [1] it takes more than five minutes just for the description: I will diligently do it for all my packages :-)... but it's a little bit discouraging :-S I can sympathise, but it's not that much work compared to writing code, and about as important. There will always be people who have never even heard of your package, and there's nothing more frustrating than reading a 1( or 10)-line description and not learning a thing. Kind regards, T G-R
Re: packaging - sentences in description
Le 2019-03-18 15:34, Giovanni Biscuolo a écrit : Hi Guix I'm packaging go-github-com-burntsushi-locker, this is the package definition: [...] (home-page "https://github.com/BurntSushi/locker;) (synopsis "Manage named ReadWrite mutexes in Go") (description "Golang package for conveniently using named read/write locks. These appear to be especially useful for synchronizing access to ^ here session based information in web applications. The common use case is to use the package level functions, which use a package level set of locks (safe to use from multiple goroutines simultaneously). However, you may also create a new separate set of locks ^ here test. All locks are implemented with read-write mutexes. To use them like a regular ^ and here mutex, simply ignore the RLock/RUnlock functions.") (license license:public-domain I think that's all. HTH :)
packaging - sentences in description
Hi Guix I'm packaging go-github-com-burntsushi-locker, this is the package definition: --8<---cut here---start->8--- (define-public go-github-com-burntsushi-locker (let ((commit "a6e239ea1c69bff1cfdb20c4b73dadf52f784b6a") (revision "0")) (package (name "go-github-com-burntsushi-locker") (version (git-version "0.0.0" revision commit)) (source (origin (method git-fetch) (uri (git-reference (url "https://github.com/BurntSushi/locker;) (commit commit))) (file-name (git-file-name name version)) (sha256 (base32 "1xak4aync4klswq5217qvw191asgla51jr42y94vp109lirm5dzg" (build-system go-build-system) (arguments '(#:import-path "github.com/BurntSushi/locker")) (home-page "https://github.com/BurntSushi/locker;) (synopsis "Manage named ReadWrite mutexes in Go") (description "Golang package for conveniently using named read/write locks. These appear to be especially useful for synchronizing access to session based information in web applications. The common use case is to use the package level functions, which use a package level set of locks (safe to use from multiple goroutines simultaneously). However, you may also create a new separate set of locks test. All locks are implemented with read-write mutexes. To use them like a regular mutex, simply ignore the RLock/RUnlock functions.") (license license:public-domain --8<---cut here---end--->8--- it builds but when I check its description I get [1]: --8<---cut here---start->8--- giovanni@anemone: time ./pre-inst-env guix lint -c description go-github-com-burntsushi-locker gnu/packages/golang.scm:3202:19: go-github-com-burntsushi-locker@0.0.0-0.a6e239e: sentences in description should be followed by two spaces; possible infractions at 60, 329, 447 Some deprecated features have been used. Set the environment variable GUILE_WARN_DEPRECATED to "detailed" and rerun the program to get more information. Set it to "no" to suppress this message. real4m24.644s user5m24.480s sys 0m1.420s --8<---cut here---end--->8--- I copy/pasted and adapted the description from the project homepage, I'm using emacs and auto-fill mode on so it should have followed the rules in .dir-locals.el I can't understand where the sentences in my description lacks the two required spaces: any hint please? Thanks! Gio [1] it takes more than five minutes just for the description: I will diligently do it for all my packages :-)... but it's a little bit discouraging :-S [2] https://www.gnu.org/software/guix/manual/en/html_node/Synopses-and-Descriptions.html#Synopses-and-Descriptions -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Libre games that might be worth packaging :)
Pierre Neidhardt writes: > Ricardo Wurmus writes: > >> We have this. It’s called “btanks”. > > Shouldn't we name this "battle-tanks"? > > >> I think this one is packaged: see the `crawl' and `crawl-tiles' packages. > > Shouldn't we name this "dungeon-crawl-stone-soup"? > > >> > Armagetron Advanced - A 3-D variant of the Light Cycles sub-game of the >> > classic Tron arcade game. Highly configurable and very fun to play. >> >> This we have already. :) > > It's named "armagetronad". Shouldn't we name this > "armagetron-advanced"? Instead of renaming the packages (whose names follow our packaging guidelines) how about adding the full name of the games to the description? -- Ricardo
Re: Libre games that might be worth packaging :)
Pierre Neidhardt writes: > Dan Frumin writes: > >>> Shouldn't we name this "dungeon-crawl-stone-soup"? >>> >> >> Possibly, but the official packages from crawl.develz.org are called `crawl' >> and `crawl-tiles'. > > Maybe packagers use abbreviated names, often with underscores or simply > no word separator. > > I think we should not follow what other packagers do, but rather what > the _users_ expect. The full program name is much more certain to be > known to the wider audience rather than some abbreviation that is only > known to the set of developers / restricted community members. This is what our packaging guidelines say: --8<---cut here---start->8--- 14.4.2 Package Naming - […] Both [variable name and package name] […] correspond to the lowercase conversion of the project name chosen upstream, with underscores replaced with hyphens. --8<---cut here---end--->8--- -- Ricardo
Re: Libre games that might be worth packaging :)
On 18-03-19 08:25, Pierre Neidhardt wrote: Ricardo Wurmus writes: We have this. It’s called “btanks”. Shouldn't we name this "battle-tanks"? I think this one is packaged: see the `crawl' and `crawl-tiles' packages. Shouldn't we name this "dungeon-crawl-stone-soup"? Possibly, but the official packages from crawl.develz.org are called `crawl' and `crawl-tiles'. Maybe it is good to add the abbreviation "DCSS" somewhere in the description tho? Armagetron Advanced - A 3-D variant of the Light Cycles sub-game of the classic Tron arcade game. Highly configurable and very fun to play. This we have already. :) It's named "armagetronad". Shouldn't we name this "armagetron-advanced"? Cheers!
Re: Libre games that might be worth packaging :)
Ricardo Wurmus writes: > We have this. It’s called “btanks”. Shouldn't we name this "battle-tanks"? > I think this one is packaged: see the `crawl' and `crawl-tiles' packages. Shouldn't we name this "dungeon-crawl-stone-soup"? > > Armagetron Advanced - A 3-D variant of the Light Cycles sub-game of the > > classic Tron arcade game. Highly configurable and very fun to play. > > This we have already. :) It's named "armagetronad". Shouldn't we name this "armagetron-advanced"? Cheers! signature.asc Description: PGP signature
