Re: Chrooting into GuixSD
Am 13.06.2018 um 06:04 schrieb swedebugia: > I succeeded to chrooting into the system and set a new password. I > used an arch-image on an USB. > > Is this ability to chroot into GuixSD worth mentioning in the manual? IMHO it is not worth to be mentioned in the manual, as it is the same as for all Linux systems. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Guix Manual in epub format
Am 13.06.2018 um 05:38 schrieb swedebugia: > Hi > I use an ebook reader for reading long detailed documents and books. > I would like a copy of the guix Manual on my reader. > I searched a little and there seem to be no ready tool to convert > info2epub. > > I found this: > > latexml --dest=$1.xml $1.tex > latexmlpost -dest=$1.html $1.xml > ebook-convert $1.html $1.epub --language en --no-default-epub-cover This looks quite complicated. With a short internet search i found: https://github.com/jlhg/texinfo2epub which basically does this: makeinfo --docbook $INPUT_FILE_PATH -o out.xml xsltproc $EPUB_XSL out.xml The stylesheet seams to be part of docbook-xsl already. https://github.com/ikrukov/epub does not provide a script, but describes the same approach. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Chrooting into GuixSD
Hartmut Goebel transcribed 493 bytes: > Am 13.06.2018 um 06:04 schrieb swedebugia: > > I succeeded to chrooting into the system and set a new password. I > > used an arch-image on an USB. > > > > Is this ability to chroot into GuixSD worth mentioning in the manual? > > IMHO it is not worth to be mentioned in the manual, as it is the same as > for all Linux systems. Not really, since you can not *fully* chroot a GuixSD. Some functions will not work, like interacting with the daemon or what it was. Last time I tried this was at least 1.5 years ago. > > -- > Regards > Hartmut Goebel > > | Hartmut Goebel | h.goe...@crazy-compilers.com | > | www.crazy-compilers.com | compilers which you thought are impossible | > >
Re: GSoC: Adding a web interface similar to the Hydra web interface
Hi Tatiana, On Wed, 13 Jun 2018 01:43:31 +0300 Tatiana Sholokhova wrote: > I've just fixed codestyle issues and replaced HTML5 preamble with XHTML. Yeah, looks much more regular now. > I adopted the static file serving procedure from code shared by Ricardo. > > https://github.com/BIMSBbioinfo/rcas-web/blob/22a114a0f281845117ed0ab105267f132fc525e4/rcas/web/render.scm#L68 I understand. It's common to do stuff like that - but it's just an unnecessary risk. Especially since we have cuirass build (and presumably sign) everything for us, it would be very very bad for an attacker to be able to read out the private key used to sign everything. Blacklists are a whack-a-mole approach (maintaining it will never end) - and in this case nothing in POSIX states that these characters are the only problematic ones (and I know of quite a few filesystems where there are a lot more problematic strings). Much better to have a whitelist. > I am considering the following possible implementation of a whitelist. We > can create association list with allowed file names and their mime types (to > replace file-mime-type list). What do you think about it? Yes, that would be a simple way - and easily maintainable, too. Let's do it like that. > Now we have the only one parameter of the request > which is related to pagination. It is the page number. Should we add more > parameters to the request in order to request evaluations with specific > timestamps and IDs? Or there is some other way of doing that? I don't think we would need the parameter for the page number anymore. I think we should add a parameter like "boundary" or something (or multiple ones - I defer to your judgement). It would also be possible to use "boundary=a&boundary=b" (note: same name). Not sure whether that would be obtuse or not. From a technical standpoint it doesn't matter - you just have to have get a tuple of data cells (of the last row) into the query string somehow. Also, it has to be able to be entirely optional (in order to get the first page). The tuple of data cells should uniquely identify one row in the result. (If it didn't, you'd skip the other same-value rows when going to the next page) (There would be an alternative possible to be able to dispense of this requirement, but I think it would be too obtuse to maintain) For the evaluations, the relevant data cells would be (starttime, id, revision) or so. I suggest adding starttime to the "Evaluations" database table to improve usability. (If we wanted to eventually provide a way for the user to sort columns, we'd have to also adapt what columns this cell list contains - although it doesn't make sense to stay on page 243 when you change the sort order :) ) What do you think? > I have > checked the Hydra pagination request structure. It uses the same form of > the request path for pagination buttons that we have now: > "?page=". Yeah, the practice is widespread. Let's do better than that if we can. pgpyfnczUsiQT.pgp Description: OpenPGP digital signature
Re: Chrooting into GuixSD
On 13.06.2018 10:13, Nils Gillmann wrote: Is this ability to chroot into GuixSD worth mentioning in the manual? IMHO it is not worth to be mentioned in the manual, as it is the same as for all Linux systems. Not really, since you can not*fully* chroot a GuixSD. Some functions will not work, like interacting with the daemon or what it was. Last time I tried this was at least 1.5 years ago. You can interact with the daemon: cd /path/to/guix/root sudo mount --bind /dev dev sudo mount --bind /proc proc sudo mount --bind /sys sys sudo unshare -m sudo chroot . /run/current-system/profile/bin/bash source /etc/profile guix-daemon --build-users-group=guixbuild & If you then `su` to a plain user, do `source /etc/profile` again. I think all of `guix pull`. `reconfigure` and `package` search, install and update worked here with that approach. `guix download` failed due to nss certificates, until I added: export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs" export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt" export GIT_SSL_CAINFO="$SSL_CERT_FILE" -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/
Re: Guix Manual in epub format
Hi swedebugia, > I use an ebook reader for reading long detailed documents and books. > I would like a copy of the guix Manual on my reader. > I searched a little and there seem to be no ready tool to convert info2epub. > > I found this: > > latexml --dest=$1.xml $1.tex > latexmlpost -dest=$1.html $1.xml > ebook-convert $1.html $1.epub --language en --no-default-epub-cover > > It makes use of latexml and ebook-converter (the command line tool that comes > with calibre) > Source: https://tex.stackexchange.com/questions/1551/use-latex-to-produce-epub > > Any thoughts? We can generate HTML directly as we do for the online copy of the manual. From there it’s just a small step to epub. -- Ricardo
Re: GSoC: Adding a web interface similar to the Hydra web interface
Tatiana Sholokhova writes: > Hello, > > Thank you for your reviews! > > I've just fixed codestyle issues and replaced HTML5 preamble with XHTML. Just cause I'm curious, why XHTML instead HTML5? Is XHTML better to parse? (This question comes from non guix developer by the way. Just an enthusiast). > > > Thanks again for your excellent work! > > -- > Ricardo
Re: [bootstrappable] Mes 0.15 released
"Orians, Jeremiah (DTMB)" writes: >> I am pleased to announce the release of Mes 0.15, representing 45 commits >> over 3 weeks. The GNU toolchain is getting bootstrapped! wow! > > Great work as always Janneke > -Jeremiah
Re: GSoC: Adding a web interface similar to the Hydra web interface
Joshua Branson ezt írta (időpont: 2018. jún. 13., Sze 15:52): > Tatiana Sholokhova writes: > > > Hello, > > > > Thank you for your reviews! > > > > I've just fixed codestyle issues and replaced HTML5 preamble with XHTML. > > Just cause I'm curious, why XHTML instead HTML5? Is XHTML better to parse? > (This question comes from non guix developer by the way. Just an > enthusiast). > > > > > > > Thanks again for your excellent work! > > > > -- > > Ricardo > Joshua, both formats have advantages, and also disadvantages. I think this issue deserves its own discussion. It would be nice to collect the opinions, but I think that currently we have a good quality and well integrated xml generator, and we do not have a html5 generator. Please correct me if I am wrong. >
Re: GSoC: Adding a web interface similar to the Hydra web interface
Gábor Boskovits writes: > Joshua Branson ezt írta (időpont: 2018. jún. 13., Sze > 15:52): > > Tatiana Sholokhova writes: > > > Hello, > > > > Thank you for your reviews! > > > > I've just fixed codestyle issues and replaced HTML5 preamble with XHTML. > > Just cause I'm curious, why XHTML instead HTML5? Is XHTML better to parse? > (This question comes from non guix developer by the way. Just an > enthusiast). > > > > > > > Thanks again for your excellent work! > > > > -- > > Ricardo > > Joshua, both formats have advantages, and also disadvantages. I think this > issue deserves its own discussion. It would be nice to collect the opinions, > but I think that currently we have a good > quality and well integrated xml generator, and we do not have a html5 > generator. Please correct me if I am wrong. Nope you sound right. I'm not arguing in favor or html5 over xhtml. Both are widely supported by all browsers. Just trying to learn. Thanks!
Re: Fwd: Re: Patch file for colorize module
Hi On Wednesday 13 June 2018 03:42 AM, Ricardo Wurmus wrote: > Hi Sahithi, > > thank you for rebasing it. > > I have applied it successfully and I tested the output with this > command: > > ./pre-inst-env guix build --no-grafts --check hello > > When I run this in the source directory I do see colours and extra dots > on every new line, and I see a couple of missing space characters, just > as your code specifies it. Yes > Do you see this too? (If not, can you tell us what terminal you are > using?) At the very least you should see that every line starts with a > dot. I am able to see the colours. I tested with the same hello package before sending you the patch. And yes "." for each line. > The next steps are to fix the errors in the regular expressions that > swallow certain space characters and to re-read the documentation of > “make-soft-port” to make sure that the procedures in the vector behave > as they should. I will update back once i am through with it. > > -- > Ricardo > > -- Regards Sahithi
New French PO file for 'guix-manual' (version 0.15.0-pre1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'guix-manual' has been submitted by the French team of translators. The file is available at: http://translationproject.org/latest/guix-manual/fr.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/guix-manual/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/guix-manual.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: Fwd: Re: Patch file for colorize module
Hi Sahithi, >> Do you see this too? (If not, can you tell us what terminal you are >> using?) At the very least you should see that every line starts with a >> dot. > I am able to see the colours. I tested with the same hello package > before sending you the patch. And yes "." for each line. Good! >> The next steps are to fix the errors in the regular expressions that >> swallow certain space characters and to re-read the documentation of >> “make-soft-port” to make sure that the procedures in the vector behave >> as they should. > I will update back once i am through with it. After reading the documentation for “make-soft-port” again, I recommend adding very short comments above each of the procedures in the vector to explain what they are intended to do. This is generally good practice when working with facilities that don’t provide named / keyword arguments. -- Ricardo
Re: Testing the installer
Hi swedebugia, > I see two branches with wip-installer. > > What is the difference between those? Wip-installer2 having a newer master > merged in? The “wip-installer2” is newer and has seen more work than the original “wip-installer”, which has been abandoned. If you want to work on it I recommend looking at “wip-installer2”. > I would like to try installing via the installer to test it. Is it working? I don’t know. From what I remember it still had some rather rough edges and was less guided than you would expect from other installers. > Can the installer handle dual-boot detection/setup yet? I don’t think so. -- Ricardo
preparing the next release v0.15.0
Hi Guix, all of us have been very busy fixing bugs, adding great new features, adding packages, and managing core-updates/staging. In fact, we’ve done so much that people installing version 0.14.0 would really miss out on a couple of important changes. (For example, they wouldn’t even be able to update to the latest version directly with “guix pull”.) It’s about time we make another release. Let’s make a plan! Here are a bunch of things that we should look into: * Outstanding patches. There are many patches in the queue at guix-patches[1] that we should go through, comment on, and/or apply before the release. Who would like to join a task force to do that together? Let’s pick 5 patches each and review them so that we can either comment to ask for changes or to apply them. [1]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches * breakage since the last core-updates merge. Since the long overdue merge of the “core-updates” branch we have a few serious problems on i686 (e.g. the gst-plugins-base package) and armhf. Who would like to lead an effort to investigate and fix these problems? (Note: you obviously don’t need to fix them yourself, just keep track of these things and coordinate with others who investigate them.) * collecting new features and big changes in NEWS. The NEWS file already lists some of the changes that the next release would provide compared to 0.14.0, but we all know that there are more. Who would like to take charge of the NEWS file? This involves asking people for changes they would really like to be mentioned and coordinating with other volunteers to search through all commits since v0.14.0 to find noteworthy changes. * Finding a date. Some of the fixes that need to be included may have to end up on core-updates. According to my calendar core-updates will be frozen on <2018-08-06 Mon> and be merged on <2018-08-20 Mon> at the latest. That’s a little late, so if we can solve problems on the master branch with architecture-specific workarounds that don’t result in rebuilding the world (in addition to proper fixes on core-updates) that would be best. What do you think: is July 27 (2018) realistic? Did I miss anything? Who wants to help? Your comments are very welcome! -- Ricardo
Re: preparing the next release v0.15.0
Can we aim for a v1.0 release? At least for the package manager? I am facing people that say Guix is not mature and therefore insecure and therefore they can justifiably ignore my pleas for installation without even looking. I think any outstanding features can be projected on later realeases. GuixSD can have its own release version. Pj.
