Re: 01/01: gnu: bluez: Install the library and header files.
Hello, On Sat, May 23, 2015 at 06:41:49PM -0400, Mark H Weaver wrote: > The form feeds that you just removed were put in by civodul in commit > c84d0eca053cd524294ad10c1f49a877902932c4. Presumably he put them there > intentionally. Did you intend to remove them as part of this unrelated > bluez commit? this is just a consequence of my editor settings that remove white space at the end of lines upon saving a file. I usually only see them when I commit (and did not consider it harmful, except that it hides the real changes in the diff). I just changed it so that only white space at the end of lines I touched are concerned. Andreas
Re: 01/01: gnu: dbus-glib: Propagate inputs dbus and glib.
On Sat, May 23, 2015 at 07:17:35PM -0400, Mark H Weaver wrote: > The only change you actually made to messaging.scm in this commit was to > add your copyright notice. That was a mistake, I intended to make the change announced in the commit message. Probably a consequence of juggling with too many files, since I also built all the modified packages (with the exception of icecat) to make sure everything still works. > However, I have a larger question about this commit: Should 'dbus' and > 'glib' be removed from the inputs of every package that has 'dbus-glib' > as an input? My answer would be "not necessarily". IMO, the only time > we should remove input A from a package is when it doesn't use A > directly. I have no definite answer to this. Not removing them would definitely mean less work. Even more so since it is not easy to determine the transitive closure of propagation: If A is propagated by B and B is propagated by C, then everything including C does not need to include A. In practice, for a new package, I am usually building with incrementally more inputs, following the complaints by the configure phase. So if it first complains about dbus-glib, I would add it, and not see any complaints about dbus and glib, which would not be included. If it first complains about glib, then dbus, then dbus-glib, I would add all three and maybe not even see that one of them is enough. Contrarily to you, I wondered whether we should not even build a linter to verify if propagated inputs could not be dropped as explicit inputs... But I think it would make for a lot of work with little effect anyway. So maybe we should not do anything special and just let randomness take its course in this matter? Andreas
Re: Guix Oficial Website
Luis Felipe López Acevedo writes: > I attach my implementation. It works, but since I'm a novice, it may > not be pretty :) So, comments are very welcomed. Nice work! I have noticed some trailing whitespaces. In emacs you can invoke 'M-x delete-trailing-whitespace' before saving. -- Mathieu Lirzin
Re: 01/01: gnu: dbus-glib: Propagate inputs dbus and glib.
Commit 2e88d11 suggests that dbus-glib-1.pc mentions GLib and DBus. That’s one of the two criteria that we use to add propagate inputs. So that part of the commit is OK. As for removing DBus and GLib as inputs of the other packages, it’s really a question of whether the package uses them directly or not, as Mark wrote. This would need to be checked for each of them. The conservative approach would be to leave DBus and GLib as inputs until we have evidence that the package in fact only needs dbus-glib. Should we revert that part of the commit, at least for packages for which we don’t know? Thanks, Ludo’.
Re: Guix Oficial Website
Luis Felipe López Acevedo skribis: > On 2015-05-22 08:29, l...@gnu.org wrote: >> Luis Felipe López Acevedo skribis: >> >>> I think I understand the Scheme side of the website now and I'm able >>> to build the HTML using the REPL, so I'd like to give it a try. >> >> Excellent, thank you! >> >> Ludo’. > > I attach my implementation. It works, but since I'm a novice, it may > not be pretty :) So, comments are very welcomed. LGTM, please push! (I can do the CVS commit afterwards.) Thanks, Ludo’.
Re: 01/01: gnu: dbus-glib: Propagate inputs dbus and glib.
l...@gnu.org (Ludovic Courtès) writes: > Commit 2e88d11 suggests that dbus-glib-1.pc mentions GLib and DBus. > That’s one of the two criteria that we use to add propagate inputs. > So that part of the commit is OK. > > As for removing DBus and GLib as inputs of the other packages, it’s > really a question of whether the package uses them directly or not, as > Mark wrote. This would need to be checked for each of them. The > conservative approach would be to leave DBus and GLib as inputs until we > have evidence that the package in fact only needs dbus-glib. Agreed. > Should we revert that part of the commit, at least for packages for > which we don’t know? FWIW, I don't feel the need to revert, especially since it would entail more rebuilding, but in the future I would prefer to use the more conservative approach that you outlined above. Andreas Enge writes: > In practice, for a new package, I am usually building with incrementally more > inputs, following the complaints by the configure phase. So if it first > complains about dbus-glib, I would add it, and not see any complaints about > dbus and glib, which would not be included. If it first complains about glib, > then dbus, then dbus-glib, I would add all three and maybe not even see that > one of them is enough. Fair enough :) I suspect that's the way most of our packages were built, and that's okay. For that matter, I suspect that's the way most authors of C files determine which header files to #include. > So maybe we should not do anything special and just let randomness take its > course in this matter? I don't think we should spend a lot of time on this, but to the extent we are aware of which inputs are directly needed by a given package, I think we should aim to include all directly used inputs, as opposed to aiming to remove inputs whenever they are propagated by something else. Mark
Re: 01/01: gnu: bluez: Install the library and header files.
Andreas Enge writes: > On Sat, May 23, 2015 at 06:41:49PM -0400, Mark H Weaver wrote: >> The form feeds that you just removed were put in by civodul in commit >> c84d0eca053cd524294ad10c1f49a877902932c4. Presumably he put them there >> intentionally. Did you intend to remove them as part of this unrelated >> bluez commit? > > this is just a consequence of my editor settings that remove white space > at the end of lines upon saving a file. I usually only see them when I > commit (and did not consider it harmful, except that it hides the real > changes in the diff). I just changed it so that only white space at the end > of lines I touched are concerned. Sounds good, thanks! Mark
Re: Guix Oficial Website
On 2015-05-24 07:58, Mathieu Lirzin wrote: Luis Felipe López Acevedo writes: I attach my implementation. It works, but since I'm a novice, it may not be pretty :) So, comments are very welcomed. Nice work! I have noticed some trailing whitespaces. In emacs you can invoke 'M-x delete-trailing-whitespace' before saving. -- Mathieu Lirzin Thanks for checking, and for the tip :) -- Luis Felipe López Acevedo http://sirgazil.bitbucket.org/
Re: Guix Oficial Website
On 2015-05-24 08:19, l...@gnu.org wrote: Luis Felipe López Acevedo skribis: On 2015-05-22 08:29, l...@gnu.org wrote: Luis Felipe López Acevedo skribis: I think I understand the Scheme side of the website now and I'm able to build the HTML using the REPL, so I'd like to give it a try. Excellent, thank you! Ludo’. I attach my implementation. It works, but since I'm a novice, it may not be pretty :) So, comments are very welcomed. LGTM, please push! (I can do the CVS commit afterwards.) Thanks, Ludo’. Pushed, and thanks :) -- Luis Felipe López Acevedo http://sirgazil.bitbucket.org/
Re: Website, differentiating GuixSD vs Guix
2015-05-21 23:43 GMT+02:00 Luis Felipe López Acevedo < felipe.lo...@openmailbox.org>: > On 2015-05-20 14:22, Paul van der Walt wrote: > >> Hello Guix, >> >> Minor headache i had, thought i'd share. >> >> Went to the website to download the binary tarball (which seems to work >> very well, kudos!), but was bitten by the fact that the GuixSD and GNU >> Guix downloads aren't separated. I first ended up with GuixSD instead of >> Guix, then after reading way too quickly concluded that i686 was what i >> wanted, ended up with the wrong Guix for my platform (x86_64, which is >> visually at the end of the "list" containing GuixSD 0.8.2 (x86_64) and >> GuixSD 0.8.2 (i686)). >> >> So, i realise i should read more carefully and all, but perhaps a >> horizontal rule between the two GuixSD and the 4 GNU Guix downloads >> would be nice? >> >> Feel free to call me hasty and myopic or just ignore me. Otherwise it >> looks really polished, congrats :) >> >> Ciao, >> p. >> > > Hey, Paul, thanks for your feedback. > > The items in the download page will be updated to look like in the > following mock-up to make them more compact: > > > https://multimedialib.files.wordpress.com/2015/05/guixsd-downloads-mockup-2015-05-21.png > > Hopefully, the new design will also help people What do you think about using a “laptop logo” or something for GSD instead of the “package”? > who push buttons without reading (just kidding :)). > Those who don't know the difference between GSD and Guix :) > > -- > Luis Felipe López Acevedo > http://sirgazil.bitbucket.org/ > >
Re: Website, differentiating GuixSD vs Guix
On 2015-05-24 11:44, Amirouche Boubekki wrote: 2015-05-21 23:43 GMT+02:00 Luis Felipe López Acevedo : [...] Hey, Paul, thanks for your feedback. The items in the download page will be updated to look like in the following mock-up to make them more compact: https://multimedialib.files.wordpress.com/2015/05/guixsd-downloads-mockup-2015-05-21.png [1] Hopefully, the new design will also help people What do you think about using a “laptop logo” or something for GSD instead of the “package”? I think it's a good idea. I can make the change if others agree. -- Luis Felipe López Acevedo http://sirgazil.bitbucket.org/
Re: Guix Oficial Website
Luis, your work on the website is very appreciated, just check result with e.g. https://validator.w3.org/ for syntax and other errors. Then it would be perfect. Regards Adam Pribyl
Re: Prerequesits GuixSD
On Tue, 19 May 2015, Amirouche BOUBEKKI wrote: Le mardi 19 mai 2015 à 10:55 +0200, Ricardo Wurmus a écrit : Hi Fabian, But the system build broke. What exactly does this mean? I used a Lenovo T60 with just 1GB RAM. What hardware do i need to build a Guix system? I used the very tiny system configuration that i found on the installer USB with slight changes. I use the Guix System Distribution (GuixSD) on both a T60 and an X200s. I did *not* compile everything from scratch but used binary substitutes for the vast majority of packages. Here on a glublub X60 it installed correctly with substitues. There is XFCE and WM maker as WM. And it works quiet good as second workstation. GSD hasn't yet, all the s/spies/daemons that other distros can have ;) This is it, with substitutes, it works, even on 1GB of RAM. But as soon as you want to compile, then 1GB of RAM is not enought. I even used 1GB swap and still no go. The question is something I am interest in too - what is the minimum to compile the guix(SD)? Does anybody know? ~~ Ricardo Adam Pribyl
Re: Initializing a 64bit system using guix on a 32bit OS
Ludovic Courtès (2015-05-22 16:28 +0300) wrote: > Alex Kost skribis: [...] >> So I'm wondering is there a way to init a 64-bit system from a 32-bit >> one or perhaps it's just not possible? > > It actually is possible, but a little bit trickier. Mark did it a few > weeks ago, though in a slightly different context. The following should > work: > > 1. Install an i686 GuixSD, simply with ‘guix system init’, but use an > x86_64 kernel. To do that, you need to explicitly ask for an > x86_64 kernel and Guix (so that the daemon accepts to build x86_64 > things) in the OS config: > >(define linux-libre-x86_64 > (package (inherit linux-libre) >(arguments `(#:system "x86_64-linux" > ,@(package-arguments linux-libre) > >(define guix-x86_64 > (package (inherit guix) >(arguments `(#:system "x86_64-linux" > ,@(package-arguments guix) > >(define %my-services > ;; Make sure the ‘guix-daemon’ services uses ‘guix-x86_64’. > (map (lambda (mservice) > (mlet %store-monad ((service mservice)) > (if (memq 'guix-daemon (service-provision service)) > (guix-daemon #:guix guix-x86_64) > (return service > %base-services)) > >(operating-system > ;; ... > (kernel linux-libre-x86_64) > (services %my-services)) > > Normally you’ll get the x86_64 kernel and Guix from hydra.gnu.org, > so no problem. The rest of the user-land will still be 32-bit. > > 2. Boot into the new system, and from there run ‘guix system > reconfigure’ with a cleaned up OS config. > > Let us know how it goes! Mark and Ludovic, thank you very much! Eventually I installed a 64-bit system from a 32-bit Guix, based on your notes. Guix is great! Ave Guix!! -- Alex
Re: 01/01: gnu: dbus-glib: Propagate inputs dbus and glib.
On Sun, May 24, 2015 at 10:33:05AM -0400, Mark H Weaver wrote: > l...@gnu.org (Ludovic Courtès) writes: > > Should we revert that part of the commit, at least for packages for > > which we don’t know? > FWIW, I don't feel the need to revert, especially since it would entail > more rebuilding, but in the future I would prefer to use the more > conservative approach that you outlined above. Okay, both are fine with me. > I don't think we should spend a lot of time on this, but to the extent > we are aware of which inputs are directly needed by a given package, I > think we should aim to include all directly used inputs, as opposed to > aiming to remove inputs whenever they are propagated by something else. Also okay then. It also saves quite some time... Andreas
Re: Guix Oficial Website
On 2015-05-24 13:31, Adam Pribyl wrote: Luis, your work on the website is very appreciated, just check result with e.g. https://validator.w3.org/ for syntax and other errors. Then it would be perfect. Regards Adam Pribyl Hi Adam. Yes, I'm aware of those. Most of them are because of a missing Doctype definition on all pages, and because of using XML syntax in self-closing elements. Part of that is related to the current SXML to XML conversion method. I'll see what I can do :) -- Luis Felipe López Acevedo http://sirgazil.bitbucket.org/
Re: Guix Oficial Website
On 2015-05-24 17:48, Luis Felipe López Acevedo wrote: Hi Adam. Yes, I'm aware of those. Most of them are because of a missing Doctype definition on all pages, and because of using XML syntax in self-closing elements. Part of that is related to the current SXML to XML conversion method. I meant to say that the pages are missing a Document type declaration, and that SXML to XML renders empty non-self-closing elements as self-closing elements. For example (video (@ (src "http://somevideo.org/video.webm";))) Will be rendered as http://somevideo.org/video.webm"/> Instead of http://somevideo.org/video.webm";> In the case of the current video in the homepage, the issue can be avoided because that video should provide alternative content, which I'll fix. And, as a workaround for pages that include JavaScript in the future, I think a noscript element could be used as alternative. -- Luis Felipe López Acevedo http://sirgazil.bitbucket.org/
