Re: self hosting hardware
2017-07-12 15:34 GMT+02:00 Ricardo Wurmus : > > Catonano writes: > > > Let's say I just want statiic web sites, a mail server and an IRC > bouncher > > > > That is: let's talk about hardware. That's where I need help > > I’m using a Samsung N148 netbook for elephly.net. I don’t run a mail > server, but I use it for XMPP, IRC bouncer, static web sites, git > server, Tor, etc. > > It’s small (thinner than my router), cheap (if you can still get it), > and it has an Intel Atom CPU, so it doesn’t consume much. It’s i686 > with limited RAM, so at the moment it’s barely enough to compile Guix, > but I hope we can fix this before the next release will be out. > > The hardware works fine with GuixSD, as far as I can tell. > As far sa I understand, no, it can't be bought anymore But I get your message about what kind of machhines can be used for this Thanks
Re: self hosting hardware
2017-07-12 17:03 GMT+02:00 Vincent Legoll : > But it's pretty expensive, the motherboard with SoC processor costs ~450€. > > No, that's cheap, really, have a look at that one: > https://www.crowdsupply.com/raptor-computing-systems/ > talos-secure-workstation > > I'm not sure I understand wat you mean to indicate, with this link It takes me to the Talos Motherbard campaign page. But that campaign is failed, as afr as I understand. Is there any hardware from that project that can be bought ?
npm (mitigation)
I read that Jelle and Jan used their own branch in order to have npm based software to be installed in their GuixSD environments, as binary blobs Can I ask you for instructions about how to do that exactly ? I might need to work a litle on some web siites in the future Which branch exactly did you use, and how, exactly ? Thanks
Re: Rails
On 12/07/17 18:47, ng0 wrote: Pjotr Prins transcribed 0.4K bytes: On Wed, Jul 12, 2017 at 08:03:48AM +, ng0 wrote: While I was working on it (or occasionally do) I wonder why we have so little rails packages? What happened there? Ruby support is great in Guix. But we don't use Rails much, yet. Dave started packaging some time back, but not sure what happened. We also need it for Arvados - Fred is working on that. Pj. Ah! Good to know. I have some packages in a dirty branch, I just need to figure out the right order. at the moment it's just one file and the top view are about 40 rails packages I guess. There is actually a branch wip-rails on savannah that boots rails. It is somewhat dated, and needs some overall work (removal of unused packages, to start). Help is welcome - I won't be able to get to this for a few months at least. Many of the packages you list ng0 are in that branch, or already in Guix. ben
Re: npm (mitigation)
Hi Catonano, I would be be happy to help you with this, but tbh, I am not comfortable discussing this in-depth on guix-devel, as this seems antithetical to Guix' goals. All I will say here is that you need to adapt the npm importer to use the sources from the npm registry instead of resolving to any 'upstream' urls. I believe Jan's importer was already able to do this last time I checked, so you might really only need to checkout their branch and rebase on current master. Regardless, the biggest issue that remains is still that npm-land is mired in cyclical dependencies and a fun-but-not-actually unique dependency resolving scheme. I am currently working on a guile version of what Sander did for Nix for importing entire npm dependency trees, but this will likely lead to lots of programmatically defined packages instead of the guix approach of mostly-manually defining each package. It might therefore be a good candidate for a guix channel, if that is still being worked on. Good luck! - Jelle 2017-07-14 10:52 GMT+02:00 Catonano : > I read that Jelle and Jan used their own branch in order to have npm based > software to be installed in their GuixSD environments, as binary blobs > > Can I ask you for instructions about how to do that exactly ? > > I might need to work a litle on some web siites in the future > > Which branch exactly did you use, and how, exactly ? > > Thanks >
core-updates failing packages
The armhf port is currently blocked while we try to build Guile 2.2.2, so I'm focusing on x86_64-linux for now. Here is a list of failing packages on x86_64-linux that need some help: gnome-mime-data fails due to a regex parsing issue that was exposed by the update to Perl 5.26.0: https://hydra.gnu.org/build/2170234 go-1.8 fails due to the same regex parsing issue: https://hydra.gnu.org/build/2168634 gengetopt fails: https://hydra.gnu.org/build/2169271 guile-bash fails: https://hydra.gnu.org/build/2171039 ngs-sdk fails due to the Perl 5.26.0 change to a "dotless INC": https://hydra.gnu.org/build/2171274 metabat fails: https://hydra.gnu.org/build/2171756 perl-class-accessor-grouped fails due to dotless INC (patch available on upstream bug tracker): https://hydra.gnu.org/build/2170942 perl-http-parser-xz fails due to dotless INC: https://hydra.gnu.org/build/2172752 perl-object-signature fails due to dotless INC (patch available on upstream bug tracker): https://hydra.gnu.org/build/2172672 perl-test-script fails due to dotless INC: https://hydra.gnu.org/build/2174900 perl-unicode-normalize fails due to dotless INC: https://hydra.gnu.org/build/2171416 perl-www-curl fails due to dotless INC: https://hydra.gnu.org/build/2174250 perl-xs-object-magic fails due to dotless INC: https://hydra.gnu.org/build/2170768 python2-pexpect fails: https://hydra.gnu.org/build/2168957 quilt fails due to that Perl 5.26.0 regex parsing issue: https://hydra.gnu.org/build/2169903 zsh fails its tests. I've noticed this test suite is unreliable: https://hydra.gnu.org/build/2170357 signature.asc Description: PGP signature
Re: npm (mitigation)
Catonano writes: > I read that Jelle and Jan used their own branch in order to have npm > based software to be installed in their GuixSD environments, as binary > blobs Jelle wrote a nice and clean npm importer, no binary anything. Npm packages have the can be source or binary. Depending on how you want to look at it you can make change this source/binary disctinction less white/black and turn it into a gray-scale. As we are talking about javascript, in some cases source and binary packages are identical. In other cases, the binary packages come with preprocessed documentation and lack the sources. Other binary packages include minimized javascript and even further into the darkness some binary packages do not include the non-minimized javascript. Then some binary packages come with pre-compiled binaries and the worst are binary package that do not come with the C/C++ sources that were used to compile these binaries. In all these cases the binary packages can be built from their source package. Here is where it starts to get nasty. Building a package from source can only be done if you have all its dependencies already installed. In theory that should not be a problem. It appears that the npm ecosystem has manouvered itself into a place where bootstrapping seems impossible: it turns out that any serious package (notably all npm build system packages) have over 1000 dependencies, often with cyclic dependencies or even missing packages. To break this boostrap loop on Guix I have added a couple of patches onto Jelle's npm importer branch that implement a --binary flag. This allows binary npm packages to be installed in Guix and serve as a basis to build other npm packages from source. Apparently have no problem*) adding binary blobs for gcc, haskell (...?) to Guix. Similarly we could consider adding a/some binary blobs for npm buildsystem packages to Guix and use those for a basis to build source-only packages. > Can I ask you for instructions about how to do that exactly ? git clone https://gitlab.com/janneke/guix.git The branch `npm' is rebased on version-0.13.0, have a look at guix import npm --help and look in gnu/packages/npm.scm for instructions. Greetings, janneke *) Actually I do not like this very much and that's why some of us seek to remove the need for our bootstrap binaries with our stage0 and Mes projects. -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: npm (mitigation)
On Fri, Jul 14, 2017 at 13:57:30 +0200, Jelle Licht wrote: > Regardless, the biggest issue that remains is still that npm-land is mired > in cyclical dependencies and a fun-but-not-actually unique dependency > resolving scheme. I still think the largest issue is trying to determine if a given package and its entire [cyclic cluster] subgraph is Free. That's a lot of manual verification to be had (to verify any automated checks). npm's package.json does include a `license' field, but that is metadata with no legal significance, and afaik _defaults_ to "MIT" (implying Expat), even if there's actually no license information in the repository. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: npm (mitigation)
2017-07-15 5:34 GMT+02:00 Mike Gerwitz : > On Fri, Jul 14, 2017 at 13:57:30 +0200, Jelle Licht wrote: > > Regardless, the biggest issue that remains is still that npm-land is > mired > > in cyclical dependencies and a fun-but-not-actually unique dependency > > resolving scheme. > > I still think the largest issue is trying to determine if a given > package and its entire [cyclic cluster] subgraph is Free. That's a lot > of manual verification to be had (to verify any automated > checks). npm's package.json does include a `license' field, but that is > metadata with no legal significance, and afaik _defaults_ to "MIT" > (implying Expat), even if there's actually no license information in the > repository. And that is exactly why this probably won't end up in Guix proper, at least for the foreseeable future. And also the reason that the entire npm situation is so sad. The default MIT/Expat only applies to people who generate their package metadata via npm init by just pressing enter; IANAL, but directly referring to a valid and common SPDX identifier is not that different from including some file under the name of LICENSE/COPYING. It is true that lots of npm projects do not include copyright and/or license headers in each source file, but this is also true for lots of other free software. - Jelle
