Re: ‘sudo’ leaves PATH unchanged… so what?
Giovanni Biscuolo writes: > IMHO it should be explicitly stated that in general it's not > advised/needed to install guix for the root user and that "guix system" > must be run as a normal user via sudo (and the user must be allowed to > do so by root via sudoers); then the example above Currently, installing Guix for the root user is what the installer script does and what the instructions for the binary installation method suggest. -- Ricardo
Re: ‘sudo’ leaves PATH unchanged… so what?
Hi all, Ludovic Courtès writes: > Ricardo Wurmus skribis: > >> Ludovic Courtès writes: >> >>> Hello Guix, >>> >>> I’m not sure if this is a bug, but on Guix System, ‘sudo’ leaves PATH >>> unchanged: this also happens on foreign distros :-) [...] >> Yes, this is expected and desired behaviour. Sysadmins generally use >> “su -” or “sudo -i” to get a “proper” root login shell because of this. > > OK. > >>> However, it trips up many people. yes, and it was a subject of many help requests both here and help-guix in recent months (since I'm subscribed) [...] > … which doesn’t do what one might think before “sudo guix pull” updates > root’s ‘guix’ whereas “sudo guix system” uses the user’s ‘guix’. > > Either we should rephrase it or perhaps explicitly write: > > From then on, you can update GuixSD whenever you want by running: > > @example > guix pull > sudo guix system reconfigure /etc/config.scm > @end example IMHO it should be explicitly stated that in general it's not advised/needed to install guix for the root user and that "guix system" must be run as a normal user via sudo (and the user must be allowed to do so by root via sudoers); then the example above [...] Thanks! Giovanni -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Testing CloudFront for distribution of substitutes on ci.guix.info
Hi Guix, in order to improve availability of binary substitutes and download speeds for many users, we will experiment with Amazon’s CloudFront CDN service for https://ci.guix.info. Note that this only concerns the distribution of substitutes; builds still happen on the same build farm as before, berlin.guixsd.org. Starting on Wednesday 23 at 01:15 UTC requests for substitutes that are sent to https://ci.guix.info will be served by the CDN instead. This experiment is expected to last up to one month. The maintainers and Guix system administrators will re-evaluate the use of a CDN for ci.guix.info at that point. If you prefer to bypass the CDN you can connect to https://berlin.guixsd.org directly as before. On a Guix system you can override the list of default substitute servers with this services value: (modify-services %desktop-services (guix-service-type config => (guix-configuration (inherit config) (substitute-urls (list "https://berlin.guixsd.org;) -- Ricardo on behalf of the Guix maintainers
Re: 01/01: tests: docker: Run a guest guile inside the docker container.
Hi Danny, guix-comm...@gnu.org writes: > dannym pushed a commit to branch master > in repository guix. > > commit 49ec5d88c5770ae49b45849cb691c8921ecf4ca7 > Author: Danny Milosavljevic > Date: Mon Jan 14 15:44:16 2019 +0100 > > tests: docker: Run a guest guile inside the docker container. > > * gnu/tests/docker.scm (run-docker-test): Add parameters. Load and run > docker container. Check response of guest guile. > (build-tarball): New procedure. > (%test-docker): Use it. > [description]: Modify. [...] > +(define (build-tarball) > + (mlet* %store-monad > + ((_ (set-grafting #f)) > + (guile (set-guile-for-build (default-guile))) > + (guest-script-package -> > +(dummy-package "guest-script" > + (build-system trivial-build-system) This introduces a duplicate field initializer in the expanded 'package' object, because the 'dummy-package' macro introduces its own 'build-system' field initializer. From (guix tests): (define-syntax-rule (dummy-package name* extra-fields ...) "Return a \"dummy\" package called NAME*, with all its compulsory fields initialized with default values, and with EXTRA-FIELDS set as specified." (package extra-fields ... (name name*) (version "0") (source #f) (build-system gnu-build-system) (synopsis #f) (description #f) (home-page #f) (license #f))) If you need to use trivial-build-system, then I think you can't use the 'dummy-package' macro as it's currently implemented. Regards, Mark
Re: Shell installer script (feedback)
Dear,
> the manual was found both in the store in a profile (not my current) and
> in /usr/local/share/info/
My point was that I needed to tweak. When a newcomer needs to tweak
just to read the manual, it is not a nice first experiment.
But now, it is fix by the new release. \o/
>
> After adjusting my infopath to this it worked like a charm:
> export
> INFOPATH="/home/sdb/.guix-profile/share/info:/usr/local/share/info${INFOPATH:+:}$INFOPATH"
Yes I have the same. :-)
Cheers,
simon
Re: Swag for FOSDEM!
Ludovic Courtès writes: > Hello Guix! > > I realize we don’t have a coordinated plan to get stickers to FOSDEM, > and maybe we should address that. :-) > > Is anyone willing to help with that? (We could consider reimbursing > using the FSF fund if it’s a reasonable amount.) I'll bring some stickers along, the same I've brought to FOSDEM the last time. There not the best stickers for mass distribution though, as the sheets are rather large to give out. signature.asc Description: PGP signature
Re: Shell installer script (feedback)
zimoun writes: >> > As a newcomer, I find it lacks an optional installation of default >> > packages in the default profiles. >> > I have in mind: nss-certs, recutils, emacs (or info), glibc-locales. >> >> I think that’s fine as the purpose of this script is just to get Guix >> itself installed. For everything past that you can use Guix. > > For example, the Debian proposes some flavour, as SSH server, which > desktop, etc. It is optional but it really eases the first experience > and strongly facilitates the access to newcomers. IMHO. That’s something the *system installer* can provide. I see the role of the installer *script* to be much more limited. -- Ricardo
Re: Shell installer script (feedback)
On 2019-01-17 18:10, zimoun wrote:
Dear,
The script is nice because it just works! :-)
As a newcomer, I find it lacks an optional installation of default
packages in the default profiles.
I have in mind: nss-certs, recutils, emacs (or info), glibc-locales.
Then, "Run 'info guix' to read the manual." does not work.
Because the command info is not installed by default on all the distributions.
And the Guix manual does not seem installed by default. Am I doing wrong?
I used the installer here on parabola and I found this (with 'locate'):
the manual was found both in the store in a profile (not my current) and
in /usr/local/share/info/
After adjusting my infopath to this it worked like a charm:
export
INFOPATH="/home/sdb/.guix-profile/share/info:/usr/local/share/info${INFOPATH:+:}$INFOPATH"
--
Cheers Swedebugia
Re: Shell installer script (feedback)
Hi again, > > As a newcomer, I find it lacks an optional installation of default > > packages in the default profiles. > > I have in mind: nss-certs, recutils, emacs (or info), glibc-locales. > > I think that’s fine as the purpose of this script is just to get Guix > itself installed. For everything past that you can use Guix. For example, the Debian proposes some flavour, as SSH server, which desktop, etc. It is optional but it really eases the first experience and strongly facilitates the access to newcomers. IMHO. I suggest optional default packages, then it just works for newcomers. As first experience, they do not need to dive in all the details about the locales, the certificates, etc. Something optional with `read -p "Install default packages? (yes/no)" yn' IMHO if one installs Guix with this script, then they does want an easy first experience; a "just works" without fighting against Certificates or Locales to run first experiments. > > > Then, "Run 'info guix' to read the manual." does not work. > > Because the command info is not installed by default on all the > > distributions. > > > > And the Guix manual does not seem installed by default. Am I doing wrong? > > This has recently been fixed, but it’s not working in the 0.16.0 release. Ok, nice ! All the best, simon
Re: Shell installer script (feedback)
Hi simon, > As a newcomer, I find it lacks an optional installation of default > packages in the default profiles. > I have in mind: nss-certs, recutils, emacs (or info), glibc-locales. I think that’s fine as the purpose of this script is just to get Guix itself installed. For everything past that you can use Guix. > Then, "Run 'info guix' to read the manual." does not work. > Because the command info is not installed by default on all the distributions. > > And the Guix manual does not seem installed by default. Am I doing wrong? This has recently been fixed, but it’s not working in the 0.16.0 release. -- Ricardo
Shell installer script (feedback)
Dear, The script is nice because it just works! :-) As a newcomer, I find it lacks an optional installation of default packages in the default profiles. I have in mind: nss-certs, recutils, emacs (or info), glibc-locales. Then, "Run 'info guix' to read the manual." does not work. Because the command info is not installed by default on all the distributions. And the Guix manual does not seem installed by default. Am I doing wrong? What do you think? All the best, simon
Swag for FOSDEM!
Hello Guix! I realize we don’t have a coordinated plan to get stickers to FOSDEM, and maybe we should address that. :-) Is anyone willing to help with that? (We could consider reimbursing using the FSF fund if it’s a reasonable amount.) Ludo’.
Re: Communication and Design at Guix
Hello, swedebugia writes: > On 2019-01-17 12:10, Ricardo Wurmus wrote: >> >> L p R n d n writes: >> >>> Guix is ... >>> >>> ... a package and system manager. (A seen previously, system manager is >>> too wide) >>> ... a package manager and machine administrator. >>> ... a package and machine administrator. >>> ... a package and environment manager. >>> >>> WDYT? If anyone has an idea, don't be shy :) >> >> “administrator” is generally understood to be a person (as in “system >> administrator”). “environment manager” is just as vague as “system >> manager”, in my opinion — “everything is the environment!”. It only >> makes sense to people who are already familiar with the term >> “environment” in a computing context. >> >> That’s the advantage the word “package manager” has — it’s already a >> well-established term, for better or worse. >> >>> I'd like to keep the "package manager" part as it'll probably ring a >>> bell to any linux user and helps understand the not so familiar part >>> (system/environment dealing). >> >> Right, that’s what I meant. >> We are underselling Guix, though, if we keep referring to it as a >> “package manager”, because people’s familiarity with other package >> managers may make them think in smaller terms. >> >> FWIW, I’m with Ludo here with regards to “Guix” as the “single brand”. >> I disagree with this part that George wrote: >> >>> "Guix System" is a "bad" name for "GuixSD." Why? Because a new user's >>> first expectation is for "Guix system" to refer to the whole of Guix, >>> which we want to call "Guix" (referred to as "Guix Brand" below). >> >> In my experience “… system” is not generally used to describe a tool’s >> full set of features. I think “Guix System” is just the right term for >> everything that Guix generates or operates on with the “guix system” set >> of commands. “GuixOS” is, in my opinion, a pretty terrible name (I’m >> also not a fan of all the other “…OS” names out there) and it needlessly >> keeps the confusion between “Guix, the tool” and “Guix, the system” >> alive. > > Interesting. > > So if we go with "Guix System" would the following sentences be meaningful? > > "Is your operating system running Guix?" (ambiguous) > > "Which operating system do you use? Guix System." > "Are you on Guix System?" > "Which version of Guix System are you using?" (we should really have something > like lsb_release -a output this term) > "How did you install your Guix System?" > "Can I dual-boot Guix System and Parabola GNU/Linux?" > > "A: My Guix System runs Linux. B: Oh, I use the Hurd on mine!" I like this. I would go a little further in terms of branding. If we go with this, I think speaking of "a Guix system" instead of "the Guix System" (if it's a noun, it's a brand so we would end up with the same problem that we have with GuixSD). "a Guix system" aknowledge the fact that Guix is almost a "system builder" (VMs, containers, computers, clusters?). I know Ludovic wasn't fond of "system" but we could replace the word with anything else if someone find something more appropriate. Plus, I had sone thoughts about how Guix doesn't fit really well within the usual "linux distribution" definition. (I think it's unfortunately disadvantaging Guix in reviews, for example.) I find that speaking of Guix in those terms, even if it doesn't explain anything, at least gives some hints. I mean, at some point, changing of channel can almost be like changing distro... > "I love the R.M. Stallman picture that is on my Guix System during boot!" :D > (https://wallup.net/wallpapers/richard-stallman/) > > "My Guix System performs really well" > "Since I switched my operating system to Guix System I have not looked back" > "I love my Guix System!" > "Guix helps me get things done instead of losing myself in the details of > dependencies and stuff when coding" > "Guix makes it easy for me to sandbox my browser so I can surf without > worrying > too much" > "Guix System boots a little slower than XX but it is worth the wait!" > "I really like the roll-back provided by Guix System when I end up in a broken > state" (geek version) > "I really like the roll-back provided by Guix System when my pc won't boot and > just goes black so I can't use the mouse or log in." (non-geek version) > "I recommend Guix System because it makes it easy to copy your friends OS > setup > so that you can get to all the fun parts quickly without worrying about > installing this or that - everything is there out-of-the-box!". > > If not please comment. Have a nice day, Lprndn
Re: Mozilla-importer and mozilla-build-system
swedebu...@riseup.net writes: > Hi > > We currently have neither langpacks, dictionaries nor add-ons for Icecat > packaged. > > This forces the users to install them iperatively through Icecat which > for the case of dictionaries entails getting an error when following the > "add dictionaries" menu-link in Icecat to an old mozilla-page. > > Installing via the new mozilla dictionary UI page here does work though > (swedish): > https://addons.mozilla.org/en-US/firefox/addon/g%C3%B6rans-hemmasnickrade-ordli/ > > Clicking install downloads and loads this file: > https://addons.mozilla.org/firefox/downloads/file/1163981/swedish_dictionary-1.18.1webext.xpi > > The langpacks are provided by upstream here: > ftp://ftp.gnu.org/gnu/gnuzilla/60.3.0/langpacks/ > > Add-ons installation support is buggy as has been reported here: > https://lists.gnu.org/archive/html/bug-gnuzilla/2018-12/msg4.html > > We can do better than this! > > I beleive all these problems could be solved easily if we would package > these in guix and make sure our Icecat looks for them in the right > place. > > Perhaps a new mozilla-importer and mozilla-build-system is a worthwhile > project? It should unpack and install the .xpi-files. There is an API > available for the add-ons repository: > https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/AMO/Add-ons_manager_API > > An example output is this: > https://services.addons.mozilla.org/en-US/firefox/api/1.5/addon/1865 > > If we package the langpacks and dictionaries from the upstream links I > hope we can update them with "guix refresh". This sounds like a splendid idea! -- Joshua Branson Sent from Emacs and Gnus
Re: Communication and Design at Guix
On 2019-01-17 12:10, Ricardo Wurmus wrote: L p R n d n writes: Guix is ... ... a package and system manager. (A seen previously, system manager is too wide) ... a package manager and machine administrator. ... a package and machine administrator. ... a package and environment manager. WDYT? If anyone has an idea, don't be shy :) “administrator” is generally understood to be a person (as in “system administrator”). “environment manager” is just as vague as “system manager”, in my opinion — “everything is the environment!”. It only makes sense to people who are already familiar with the term “environment” in a computing context. That’s the advantage the word “package manager” has — it’s already a well-established term, for better or worse. I'd like to keep the "package manager" part as it'll probably ring a bell to any linux user and helps understand the not so familiar part (system/environment dealing). Right, that’s what I meant. We are underselling Guix, though, if we keep referring to it as a “package manager”, because people’s familiarity with other package managers may make them think in smaller terms. FWIW, I’m with Ludo here with regards to “Guix” as the “single brand”. I disagree with this part that George wrote: "Guix System" is a "bad" name for "GuixSD." Why? Because a new user's first expectation is for "Guix system" to refer to the whole of Guix, which we want to call "Guix" (referred to as "Guix Brand" below). In my experience “… system” is not generally used to describe a tool’s full set of features. I think “Guix System” is just the right term for everything that Guix generates or operates on with the “guix system” set of commands. “GuixOS” is, in my opinion, a pretty terrible name (I’m also not a fan of all the other “…OS” names out there) and it needlessly keeps the confusion between “Guix, the tool” and “Guix, the system” alive. Interesting. So if we go with "Guix System" would the following sentences be meaningful? "Is your operating system running Guix?" (ambiguous) "Which operating system do you use? Guix System." "Are you on Guix System?" "Which version of Guix System are you using?" (we should really have something like lsb_release -a output this term) "How did you install your Guix System?" "Can I dual-boot Guix System and Parabola GNU/Linux?" "A: My Guix System runs Linux. B: Oh, I use the Hurd on mine!" "I love the R.M. Stallman picture that is on my Guix System during boot!" :D (https://wallup.net/wallpapers/richard-stallman/) "My Guix System performs really well" "Since I switched my operating system to Guix System I have not looked back" "I love my Guix System!" "Guix helps me get things done instead of losing myself in the details of dependencies and stuff when coding" "Guix makes it easy for me to sandbox my browser so I can surf without worrying too much" "Guix System boots a little slower than XX but it is worth the wait!" "I really like the roll-back provided by Guix System when I end up in a broken state" (geek version) "I really like the roll-back provided by Guix System when my pc won't boot and just goes black so I can't use the mouse or log in." (non-geek version) "I recommend Guix System because it makes it easy to copy your friends OS setup so that you can get to all the fun parts quickly without worrying about installing this or that - everything is there out-of-the-box!". If not please comment. -- Cheers Swedebugia
Re: [PATCH] gnu: Add glibc-locales variants for older versions of glibc.
Ricardo Wurmus writes: > * gnu/packages/base.scm (make-glibc-locales, make-glibc-utf8-locales): New > procedures. > (glibc-locales): Express in terms of make-glibc-locales. > (glibc-utf8-locales): Express in terms of make-glibc-utf8-locales. > (glibc-locales-2.27, glibc-utf8-locales-2.27): New variables. This is for the benefit of people who run Guix on top of a foreign distro. On a Guix system people can simply use the “locale-libcs” field of their operating system declaration, but on a foreign distro there is no way to install a locales package for older versions of glibc. This patch generates variants for version 2.27 and overrides the name so that both “glibc-locales” and “glibc-locales-2.27” can be installed into the same profile. (Without the name override that’s not possible.) -- Ricardo
Re: Merging ‘wip-newt-installer’ in master?
Heya! Mathieu Othacehe skribis: >> I think we can now merge on ‘master’. There might still be rough edges >> but the guts of it is in good shape AFAICS so we can polish it on >> ‘master’. > > Yes I think we can continue the polishing on master :). Here's a small > patch to the TODO file with some suggestions made by Björn and you. Pushed to ‘master’, along with the TODO update on your behalf. I realize that rebasing probably wasn’t so wise for a long-lived branch like this after all, especially since it led me to resign all your commits. Oh well. To everyone: please test, hack, and have fun with the installer! Ludo’.
[PATCH] gnu: Add glibc-locales variants for older versions of glibc.
* gnu/packages/base.scm (make-glibc-locales, make-glibc-utf8-locales): New
procedures.
(glibc-locales): Express in terms of make-glibc-locales.
(glibc-utf8-locales): Express in terms of make-glibc-utf8-locales.
(glibc-locales-2.27, glibc-utf8-locales-2.27): New variables.
---
gnu/packages/base.scm | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index e79d2a987..cf86f0658 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -13,7 +13,7 @@
;;; Copyright © 2017, 2018 Marius Bakke
;;; Copyright © 2017 Eric Bavier
;;; Copyright © 2018 Tobias Geerinckx-Rice
-;;; Copyright © 2018 Ricardo Wurmus
+;;; Copyright © 2018, 2019 Ricardo Wurmus
;;;
;;; This file is part of GNU Guix.
;;;
@@ -975,7 +975,7 @@ with the Linux kernel.")
(("/bin/pwd") "pwd"))
#t
-(define-public glibc-locales
+(define-public (make-glibc-locales glibc)
(package
(inherit glibc)
(name "glibc-locales")
@@ -1010,7 +1010,7 @@ the 'share/locale' sub-directory of this package.")
,(version-major+minor
(package-version glibc)))
-(define-public glibc-utf8-locales
+(define-public (make-glibc-utf8-locales glibc)
(package
(name "glibc-utf8-locales")
(version (package-version glibc))
@@ -1060,6 +1060,18 @@ test environments.")
(home-page (package-home-page glibc))
(license (package-license glibc
+(define-public glibc-locales
+ (make-glibc-locales glibc))
+(define-public glibc-utf8-locales
+ (make-glibc-utf8-locales glibc))
+
+(define-public glibc-locales-2.27
+ (package (inherit (make-glibc-locales glibc-2.27))
+ (name "glibc-locales-2.27")))
+(define-public glibc-utf8-locales-2.27
+ (package (inherit (make-glibc-utf8-locales glibc-2.27))
+ (name "glibc-utf8-locales-2.27")))
+
(define-public which
(package
(name "which")
--
2.20.1
Re: Idea: guix printer configuration generation
On 2019-01-17 13:08, Gábor Boskovits wrote: Hello, swedebugia ezt írta (időpont: 2019. jan. 17., Cs, 8:22): "Gábor Boskovits" skrev: (16 januari 2019 16:00:30 CET) Hello, ezt írta (időpont: 2019. jan. 16., Sze, 15:35): Hi I would rather not have to learn the CUPS web interface just to configure my printer. Do we have a way to do this yet from config.scm? I think we should abstract away everything CUPS. Maybe we could make a guix printer importer? The idea is to extract information about the printer via Guile and print what the user need to add to the config.scm. Something like this: $ guix printer "Found 1 USB printer: HP DeskJet 4330 (cups-configuration (printer (name "HP DeskJet 4330" (connection "usb://34234556" (settings (paper "a4" (source "default" ..." When the user adds this to their config.scm and reconfigures the printer JUST WORKS. Thoughts? -- Cheers Swedebugia I've found the CUPS config stuff somewhat problematic. The config file is generated from another config file, and some other things, that trigger regenerating the config. Sometimes even the printer ink level is regenerating cups configs, which is really annoying. Modifying files in /etc is not a very nice way to handle that indeed. The problem is known upstream, and seems to be won't fix. If we could get around that in any sane way, I would be very happy. Thanks for the link. This morning I read parts of the source code for the filters. I was not impressed. As this program is essentially the work of one person and not a well oiled community that can be reasoned with it really begs to be forked/replaced. In my view it should be split into a few well working interacting programs instead of this one big C program that tries to do everything from backend to converting to-from postscript, (rasterization), filtering, web admin system & printer sharing over the web. I would be very happy with a tool set like this: * frontend gui program to orchestrate the whole thing and help the user understand what is going on (display progress, errors, cancel job). * guile-wrapper for ghostscript that helps converting pdf documents (if any program wants to print output pdf or ps please) + guile-wrapper to apply filters for a given printer configuration. * backend to communicate with the printer (exposes API) (this could be a patched cups-minimal package). Configuration is done in 1 file that is written by the user or guix when reconfiguring. So to print I could either use the wrapper directly from the command line or use the frontend gui. A cli frontend could easily be created that informs the user about the current state of the printer, the queue and maybe history of printed jobs. If anybody wants to share the printer then this will be another server-frontend component developed apart from but interacting via APIs with the other parts. -- Cheers Swedebugia
Re: ‘sudo’ leaves PATH unchanged… so what?
Ricardo Wurmus skribis:
> Ludovic Courtès writes:
>
>> Hello Guix,
>>
>> I’m not sure if this is a bug, but on Guix System, ‘sudo’ leaves PATH
>> unchanged:
>>
>> --8<---cut here---start->8---
>> $ sudo env|grep '^PATH='|sha1sum
>> 5236ce49c388ade7c3e8f767d8136c1c38a97c6a -
>> $ env|grep '^PATH='|sha1sum
>> 5236ce49c388ade7c3e8f767d8136c1c38a97c6a -
>> --8<---cut here---end--->8---
>>
>> I think that’s because the shell spawned by ‘sudo’ is not a login shell,
>> so ~root/.bash_profile and other files that define/modify environment
>> variables are not sourced. So I think this is expected behavior.
>
> Yes, this is expected and desired behaviour. Sysadmins generally use
> “su -” or “sudo -i” to get a “proper” root login shell because of this.
OK.
>> However, it trips up many people. In particular, people are surprised
>> that “sudo guix system reconfigure …” does not use ~root/.config/guix,
>> and instead uses theirs (or /run/current-system/profile/…).
>>
>> My take on this is that this is normal behavior, but that we should
>> maybe recommend “sudo -i guix system reconfigure …” instead of
>> “sudo guix system reconfigure” in the manual, and/or add a warning in
>> the manual.
>
> Why would we want to recommend the use of the root user’s installation
> of Guix, though? I usually don’t care at all about the root user’s
> Guix.
Yeah, you’re right.
I think the main reason would be this bit in the manual:
--8<---cut here---start->8---
@cindex upgrading GuixSD
>From then on, you can update GuixSD whenever you want by running @command{guix
pull} as @code{root} (@pxref{Invoking guix pull}), and then running
@command{guix system reconfigure /etc/config.scm}, as @code{root} too, to
--8<---cut here---end--->8---
To many, this translates to:
sudo guix pull
sudo guix system …
… which doesn’t do what one might think before “sudo guix pull” updates
root’s ‘guix’ whereas “sudo guix system” uses the user’s ‘guix’.
Either we should rephrase it or perhaps explicitly write:
From then on, you can update GuixSD whenever you want by running:
@example
guix pull
sudo guix system reconfigure /etc/config.scm
@end example
WDYT?
Ludo’.
Re: Idea: guix printer configuration generation
Hello, swedebugia ezt írta (időpont: 2019. jan. 17., Cs, 8:22): > > "Gábor Boskovits" skrev: (16 januari 2019 16:00:30 CET) > >Hello, > > > > ezt írta (időpont: 2019. jan. 16., Sze, 15:35): > >> > >> Hi > >> > >> I would rather not have to learn the CUPS web interface just to > >> configure my printer. Do we have a way to do this yet from > >config.scm? I > >> think we should abstract away everything CUPS. > >> > >> Maybe we could make a guix printer importer? > >> > >> The idea is to extract information about the printer via Guile and > >print > >> what the user need to add to the config.scm. > >> > >> Something like this: > >> $ guix printer > >> > >> "Found 1 USB printer: HP DeskJet 4330 > >> (cups-configuration > >> (printer > >>(name "HP DeskJet 4330" > >>(connection "usb://34234556" > >>(settings > >> (paper "a4" > >> (source "default" > >> ..." > >> > >> When the user adds this to their config.scm and reconfigures the > >printer > >> JUST WORKS. > >> > >> Thoughts? > >> > >> -- > >> Cheers > >> Swedebugia > >> > > > >I've found the CUPS config stuff somewhat problematic. > >The config file is generated from another config file, and some other > >things, that trigger > >regenerating the config. Sometimes even the printer ink level is > >regenerating cups configs, > >which is really annoying. Modifying files in /etc is not a very nice > >way to handle that indeed. > >The problem is known upstream, and seems to be won't fix. If we could > >get around that in any sane way, > >I would be very happy. > > > >Best regards, > >g_bor > > I did not understand what you meant. Does the cups server regenerate you > printer config automatically? > Have a look at this upstream issue: https://github.com/apple/cups/issues/3067 It keeps coming up again and again, and stated it won't be fixed again and again... The main problem seems to be, that state and config is mixed in the config files. > I'm surprised nobody forked the CUPS project long ago. Maybe this should be a > high priority for GNU? > -- > Sent from my p≡p for Android. Best regards, g_bor
Re: ‘sudo’ leaves PATH unchanged… so what?
Ludovic Courtès writes: > Hello Guix, > > I’m not sure if this is a bug, but on Guix System, ‘sudo’ leaves PATH > unchanged: > > --8<---cut here---start->8--- > $ sudo env|grep '^PATH='|sha1sum > 5236ce49c388ade7c3e8f767d8136c1c38a97c6a - > $ env|grep '^PATH='|sha1sum > 5236ce49c388ade7c3e8f767d8136c1c38a97c6a - > --8<---cut here---end--->8--- > > I think that’s because the shell spawned by ‘sudo’ is not a login shell, > so ~root/.bash_profile and other files that define/modify environment > variables are not sourced. So I think this is expected behavior. Yes, this is expected and desired behaviour. Sysadmins generally use “su -” or “sudo -i” to get a “proper” root login shell because of this. > However, it trips up many people. In particular, people are surprised > that “sudo guix system reconfigure …” does not use ~root/.config/guix, > and instead uses theirs (or /run/current-system/profile/…). > > My take on this is that this is normal behavior, but that we should > maybe recommend “sudo -i guix system reconfigure …” instead of > “sudo guix system reconfigure” in the manual, and/or add a warning in > the manual. Why would we want to recommend the use of the root user’s installation of Guix, though? I usually don’t care at all about the root user’s Guix. -- Ricardo
Re: Communication and Design at Guix
L p R n d n writes: > Guix is ... > > ... a package and system manager. (A seen previously, system manager is > too wide) > ... a package manager and machine administrator. > ... a package and machine administrator. > ... a package and environment manager. > > WDYT? If anyone has an idea, don't be shy :) “administrator” is generally understood to be a person (as in “system administrator”). “environment manager” is just as vague as “system manager”, in my opinion — “everything is the environment!”. It only makes sense to people who are already familiar with the term “environment” in a computing context. That’s the advantage the word “package manager” has — it’s already a well-established term, for better or worse. > I'd like to keep the "package manager" part as it'll probably ring a > bell to any linux user and helps understand the not so familiar part > (system/environment dealing). Right, that’s what I meant. We are underselling Guix, though, if we keep referring to it as a “package manager”, because people’s familiarity with other package managers may make them think in smaller terms. FWIW, I’m with Ludo here with regards to “Guix” as the “single brand”. I disagree with this part that George wrote: > "Guix System" is a "bad" name for "GuixSD." Why? Because a new user's > first expectation is for "Guix system" to refer to the whole of Guix, > which we want to call "Guix" (referred to as "Guix Brand" below). In my experience “… system” is not generally used to describe a tool’s full set of features. I think “Guix System” is just the right term for everything that Guix generates or operates on with the “guix system” set of commands. “GuixOS” is, in my opinion, a pretty terrible name (I’m also not a fan of all the other “…OS” names out there) and it needlessly keeps the confusion between “Guix, the tool” and “Guix, the system” alive. -- Ricardo
‘sudo’ leaves PATH unchanged… so what?
Hello Guix, I’m not sure if this is a bug, but on Guix System, ‘sudo’ leaves PATH unchanged: --8<---cut here---start->8--- $ sudo env|grep '^PATH='|sha1sum 5236ce49c388ade7c3e8f767d8136c1c38a97c6a - $ env|grep '^PATH='|sha1sum 5236ce49c388ade7c3e8f767d8136c1c38a97c6a - --8<---cut here---end--->8--- I think that’s because the shell spawned by ‘sudo’ is not a login shell, so ~root/.bash_profile and other files that define/modify environment variables are not sourced. So I think this is expected behavior. However, it trips up many people. In particular, people are surprised that “sudo guix system reconfigure …” does not use ~root/.config/guix, and instead uses theirs (or /run/current-system/profile/…). My take on this is that this is normal behavior, but that we should maybe recommend “sudo -i guix system reconfigure …” instead of “sudo guix system reconfigure” in the manual, and/or add a warning in the manual. Thoughts? Ludo’.
Re: Communication and Design at Guix
Hello, Thanks for your feedbacks! George Clemmer writes: > Hi Lprndn, > > I am glad to see your interest in these issues. > > Ludovic Courtès writes: > >> Hi, >> >> L p R n d n skribis: >> >>> Ludovic Courtès writes: >> >> [...] >> A very concrete task that could be of interest to you is the “name change” (a bit of a strong word) that we’d like to implement by 1.0. I’ll try to summarize. Currently we have “Guix” and “GuixSD”, and that confuses things: people visit the web site, they see a “GuixSD” logo and get confused because they were just looking for a package manager, not a whole distro, or they think “GuixSD” is a storage device ;-), things like that. The idea is to bring everything under the “Guix” name. Most of the time, writing “Guix” is good enough—after all, one can run ‘guix system’ on a foreign distro, too. When we really need to make the distinction, for instance in the manual, we would write “Guix System” to designate what we currently call “GuixSD”. >>> >>> Hum. It might just be as easy as getting rid of the GuixSD logo and >>> wording for the most part. Then we can find a *preferred* way to >>> designate GuixSD (a Guix system (probably), Guix distro, Guix os).Here, >>> it's more about making GuixSD "disappear" but we could also just rebrand >>> GuixSD with some kind of "subtitle": "Guix, the system", derive a logo >>> from the Guix's one. It depends a lot from what we want to put under >>> the spotlight. >> >> The idea is more to have a single “brand”: Guix. > > Yes a single brand is the way to go. But, piecemeal changes to the web > site are unlikely to get us there unless we work from a unified "Guix > Brand" product description. E.g., earlier I proposed ... > > "'Guix' is a software environment manager that creates user environments > that are completely and independently specified by users. Guix users are > never stuck needing software that a Sysadmin can't, won't, or hasn't > installed. A Guix user can run multiple, differing environments > simultaneously and can replicate any environment on any Guix run-time > platform. Guix provides system-wide environment management when > appropriate to the run-time platform. Creation, modification, and > upgrade are atomic and roll-back is instantaneous, so Guix users and > sysadmins are never stuck with a broken user environment or system. > Guix implements a functional specification of package, user, and system > configurations using the Scheme language. Guix complies with the FSF > Four Essential Freedoms and Free System Distribution Guidelines and > provides easy and immediate access to the exact source being run. By > default, Guix uses pre-built package substitutes from the Guix build > farm and mirrors but users may build any package, or a complete system, > from package developer sources."[1] Yeah, I didn't totally get the single "brand" Guix, at first. ;) This paragraph is nice! It's probably usable as is but I think it could benefits from a little refactoring (multiple parts by usecase or possible user?). I'll try to give it a go if you don't mind. >> Then “Guix System” would be a component of Guix, so to speak, similar >> to GNOME and its applications. > > "Guix System" is a "bad" name for "GuixSD." Why? Because a new user's > first expectation is for "Guix system" to refer to the whole of Guix, > which we want to call "Guix" (referred to as "Guix Brand" below). > > But if we call GuixSD the "Guix System", we create a counter-intuitive > thing to explain. E.g., we will be saying, "Our GNU/Linux System > Distribution, 'Guix System' is just one of multiple ways to use 'Guix > Brand', which includes the Guix package manager, for which we also use > the 'Guix Brand' label. > > Another "bad" thing about calling it "Guix system" is that when a user > searches "guix system" they hit the 'guix system' "Guix Brand" package > manager' command that, BTW, also generates "Guix VMs". > > It will simplify our work if we present GuixSD as simply one of several > Guix download/deployment options. E.g., earlier I suggested ... > > "Guix is available on multiple run-time platforms including bare metal > (GuixSD), Virtual Machines (QEMU image), and any GNU/Linux distro (Guix > Binary).[1]" > > With this approach, we only need a distinctive label for GuixSD that > doesn't puzzle users to produce reliable search hits on the relevant > parts of our message and documentation. E.g., GuixOS. I understand. Currently, I'm searching for some kind of one liner to describe Guix. Something that quickly describe what Guix is. In your previous paragraph you use "software environment manager". Personnaly, I can't say if it works, I don't think I have the necessary knowledge to get it. If other guix users thinks it's easily understandable it should be ok. Otherwise, I was more with things like this: Guix is ... ... a package and system manager. (A seen previously, system manager is
Re: Merging ‘wip-newt-installer’ in master?
Hey, > I think we can now merge on ‘master’. There might still be rough edges > but the guts of it is in good shape AFAICS so we can polish it on > ‘master’. Yes I think we can continue the polishing on master :). Here's a small patch to the TODO file with some suggestions made by Björn and you. Mathieu TODO Description: Binary data
Re: Merging ‘wip-newt-installer’ in master?
> I think we can now merge on ‘master’. There might still be rough edges > but the guts of it is in good shape AFAICS so we can polish it on > ‘master’. No objections from me. Thank you, Mathieu, for the great work! -- Ricardo
