Re: What ARM hardware should we buy and where should we host it?
On Tue, Sep 04, 2018 at 02:03:18PM -0400, Leo Famulari wrote: >On Mon, Sep 03, 2018 at 10:59:38AM -0700, Vagrant Cascadian wrote: >> One of the most promising seems to be the SynQuacer: >> >> https://www.96boards.org/product/developerbox/ >> >> With a 24-core processor, SATA, PCIe, USB 3.0, micro-atx form-factor, >> and 4 ram slots (up to 64GB, in theory, but may be picky about >> ram). > >It has 24 cores of Cortex-A53 CPUs, which are intended for "mobile" >applications (smartphones and similar). IMO, it would be great to get >more powerful processors. But, if this thing is working for Debian and >can handle sustained load on all 24 cores, that's already better than >some of the armhf boards we have. According to that Debian mailing list >post, this can do both 32 and 64-bit. Correct. >Steve, do you find the SynQuacer can handle being fully loaded for >extended periods of time? I've been doing rebuilds of the entire Debian archive for the last few weeks on a Synquacer and some other machines. It's not shown any issues at all during that period. A53 cores are not all that fast for single-threaded code, but the CPU is claimed to only hit 5W flat out on all 24 cores. It's got a large passive heat sink and a small fan in the PSU. No issues seen. -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: Roadmap for Guix 1.0
Kinda late to the party here but I think a goal for 1.0 should be to ensure every single package builds on x86_64 and/or i686 and that most substitutes are available at the time of release. Having guix claim to have packages which then fail to build can leave a poor first impression. It's fine for alpha/beta but I think it will be really important for 1.0 to feel as robust as possible. I'd even say that any packages which don't build for 1.0 should be deleted or at least hidden. Maybe of channels happen we could use a stable vs unstable channels. That's my 2 cents on 1.0 at least. On September 4, 2018 6:55:57 PM EDT, fis trivial wrote: > >Ludovic Courtès writes: > >> Hello Guix! >> >> I’ve pushed to guix/maintenance.git a list of things that IMO we >should >> do or might want to do for 1.0, with the understanding that 1.0 >should >> happen in 2018 (or early 2019 at the latest!). :-) >> >> >https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org >> >> The list focuses on “big item” features and tasks, omitting routine >bug >> fixes and improvements. Some of these items don’t require a lot of >work >> or expertise though, so hopefully there’s enough on everyone’s plate. >> >> Feel free to comment, volunteer, add items (but not too many!), >remove >> items, promote items, etc. Committers should feel free to edit the >file >> directly in maintenance.git, especially to mark things as done. ;-) >> >> Copy of the file attached below. >> >> Ludo’. >> >> PS: I’m starting the discussion but will go AFK soon after sending >this >> message. :-) > >Hi Ludovic, > >For near future version of GUIX, maybe 1.1, would it be possible to: > >Upgrade to latest GCC as base compiler > >Use gold linker as default > >Based on experience, newer GCC and gold linker could reduce compilation >time >and memory requirement dramatically. It would be beneficial to both >build >farm which have heavy load and laptop users who have very limited >memory. > >Thanks. >-- >Jiaming
Re: Roadmap for Guix 1.0
Ludovic Courtès writes: > Hello Guix! > > I’ve pushed to guix/maintenance.git a list of things that IMO we should > do or might want to do for 1.0, with the understanding that 1.0 should > happen in 2018 (or early 2019 at the latest!). :-) > > https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org > > The list focuses on “big item” features and tasks, omitting routine bug > fixes and improvements. Some of these items don’t require a lot of work > or expertise though, so hopefully there’s enough on everyone’s plate. > > Feel free to comment, volunteer, add items (but not too many!), remove > items, promote items, etc. Committers should feel free to edit the file > directly in maintenance.git, especially to mark things as done. ;-) > > Copy of the file attached below. > > Ludo’. > > PS: I’m starting the discussion but will go AFK soon after sending this > message. :-) Hi Ludovic, For near future version of GUIX, maybe 1.1, would it be possible to: Upgrade to latest GCC as base compiler Use gold linker as default Based on experience, newer GCC and gold linker could reduce compilation time and memory requirement dramatically. It would be beneficial to both build farm which have heavy load and laptop users who have very limited memory. Thanks. -- Jiaming
Re: Firefox 52's end of life, packaging Chromium
Hi, Mark H Weaver skribis: > I admit that it's unclear whether or not those data transmissions could > reasonably be called 'spyware', but at the very least their existence > provides cover for spyware added later, by conditioning users to accept > data transmission to Google when it hasn't been requested (by either the > user or the website being visited). Speaking of spyware, someone shared these links recently on IRC, which I found insightful: https://spyware.neocities.org/articles/icecat.html https://spyware.neocities.org/articles/firefox.html https://spyware.neocities.org/articles/chrome.html For instance, Firefox’ portal detection mechanism (which I find handy) raises privacy issues, even if that’s not intended. (I suppose we could replace it with example.org and it would work just as well.) Ludo’.
Re: https://issues.guix.info
Hello! Ricardo Wurmus skribis: > Some of you know this already, but I think it’s time for a proper > announcement here. I made a little something: > > https://issues.guix.info One word: awesome! Hopefully contributors-to-be will be less scared than with the old interface, and… hopefully more of the current contributors will feel like reviewing patches too! :-) Ludo’.
Re: bootstrap: i686-linux now builds without binutils, gcc, and glibc seeds
Hello Jan, > The wip-bootstrap branch now builds without binutils, gcc, and glibc seeds. > > Thanks to #bootstrappable and #glibc and a week's work of hammering and > determination we succeeded in bootstrapping glibc-2.16.0. This glibc is > recent enough to bootstrap GuixSD! > [...] > We're now very close to have Guix x86 be the first GNU/Linux that was > bootstrapped without the use of binary C compiler seed. That's *awesome*! Thank you (and everyone else involved) for all your work on #bootstrappable, really exciting stuff! -amin
Re: Heads-up: New dependency on Guile-Gcrypt
Hi Alex, Alex Vong skribis: > CXXLDguix-daemon > /usr/bin/ld: nix/nix-daemon/guix_daemon-guix-daemon.o: in function `main': > /home/alexvong1995/scm/guix/nix/nix-daemon/guix-daemon.cc:434: undefined > reference to `gcry_check_version' > /usr/bin/ld: /home/alexvong1995/scm/guix/nix/nix-daemon/guix-daemon.cc:442: > undefined reference to `gcry_control' What does “grep LIBGCRYPT config.log” return? ‘nix/local.mk’ expects $(LIBGCRYPT_LIBS) to contain at least “-lgcrypt”, but in your case this variable seems to be empty. Ludo’.
Re: Heads-up: New dependency on Guile-Gcrypt
On Wed, Sep 05, 2018 at 04:07:41AM +0800, Alex Vong wrote: > Is master FTBFS because of this update? I get the following error when > running make: It works for me after I did `make clean` and made sure that guile-gcrypt was available. Basically: $ guix environment --pure guix --ad-hoc guile-gcrypt $ make clean && ./configure --localstatedir=/var && make What happens if you try something like that? signature.asc Description: PGP signature
Re: Heads-up: New dependency on Guile-Gcrypt
Is master FTBFS because of this update? I get the following error when running make: == Updating ./doc/version.texi MAKEINFO doc/guix.info Updating ./doc/version-fr.texi MAKEINFO doc/guix.fr.info CXX nix/nix-daemon/guix_daemon-nix-daemon.o CXX nix/nix-daemon/guix_daemon-guix-daemon.o CXX nix/libstore/libstore_a-gc.o CXX nix/libstore/libstore_a-globals.o CXX nix/libstore/libstore_a-misc.o CXX nix/libstore/libstore_a-references.o CXX nix/libstore/libstore_a-store-api.o CXX nix/libstore/libstore_a-optimise-store.o CXX nix/libstore/libstore_a-local-store.o CXX nix/libstore/libstore_a-build.o CXX nix/libstore/libstore_a-pathlocks.o CXX nix/libstore/libstore_a-derivations.o CXX nix/libstore/libstore_a-builtins.o CXX nix/libstore/libstore_a-sqlite.o AR libstore.a ar: `u' modifier ignored since `D' is the default (see `U') CXX nix/libutil/libutil_a-archive.o CXX nix/libutil/libutil_a-affinity.o CXX nix/libutil/libutil_a-serialise.o CXX nix/libutil/libutil_a-util.o CXX nix/libutil/libutil_a-hash.o CXX nix/libutil/libutil_a-gcrypt-hash.o AR libutil.a ar: `u' modifier ignored since `D' is the default (see `U') CXX nix/boost/format/libformat_a-free_funcs.o CXX nix/boost/format/libformat_a-parsing.o CXX nix/boost/format/libformat_a-format_implementation.o AR libformat.a ar: `u' modifier ignored since `D' is the default (see `U') CXXLDguix-daemon /usr/bin/ld: nix/nix-daemon/guix_daemon-guix-daemon.o: in function `main': /home/alexvong1995/scm/guix/nix/nix-daemon/guix-daemon.cc:434: undefined reference to `gcry_check_version' /usr/bin/ld: /home/alexvong1995/scm/guix/nix/nix-daemon/guix-daemon.cc:442: undefined reference to `gcry_control' /usr/bin/ld: libutil.a(libutil_a-hash.o): in function `nix::HashSink::currentHash()': /home/alexvong1995/scm/guix/./nix/libutil/gcrypt-hash.hh:35: undefined reference to `gcry_md_copy' /usr/bin/ld: /home/alexvong1995/scm/guix/./nix/libutil/gcrypt-hash.hh:35: undefined reference to `gcry_md_copy' /usr/bin/ld: /home/alexvong1995/scm/guix/./nix/libutil/gcrypt-hash.hh:35: undefined reference to `gcry_md_copy' /usr/bin/ld: /home/alexvong1995/scm/guix/./nix/libutil/gcrypt-hash.hh:35: undefined reference to `gcry_md_copy' /usr/bin/ld: libutil.a(libutil_a-gcrypt-hash.o): in function `guix_hash_init': /home/alexvong1995/scm/guix/nix/libutil/gcrypt-hash.cc:31: undefined reference to `gcry_md_open' /usr/bin/ld: libutil.a(libutil_a-gcrypt-hash.o): in function `guix_hash_final': /home/alexvong1995/scm/guix/nix/libutil/gcrypt-hash.cc:46: undefined reference to `gcry_md_get_algo_dlen' /usr/bin/ld: /home/alexvong1995/scm/guix/nix/libutil/gcrypt-hash.cc:45: undefined reference to `gcry_md_read' /usr/bin/ld: /home/alexvong1995/scm/guix/nix/libutil/gcrypt-hash.cc:47: undefined reference to `gcry_md_close' /usr/bin/ld: libutil.a(libutil_a-gcrypt-hash.o): in function `guix_hash_update': /home/alexvong1995/scm/guix/nix/libutil/gcrypt-hash.cc:38: undefined reference to `gcry_md_write' collect2: error: ld returned 1 exit status make[2]: *** [Makefile:3422: guix-daemon] Error 1 make[2]: Leaving directory '/home/alexvong1995/scm/guix' make[1]: *** [Makefile:4549: all-recursive] Error 1 make[1]: Leaving directory '/home/alexvong1995/scm/guix' make: *** [Makefile:3200: all] Error 2 == Christopher Lemmer Webber writes: > Ludovic Courtès writes: > >> Hello Guix! >> >> Coming soon: Guix will no longer provide its own crypto modules and will >> instead depend on Guile-Gcrypt: >> >> https://issues.guix.info/issue/32606 >> >> ‘guix pull’ will happily perform the transition. >> >> If you’re used to working on a Git checkout with “guix environment >> guix”, you’ll have to add ‘guile-gcrypt’ to the environment. If your >> “guix” is too old and lacks the ‘guile-gcrypt’ package, you have a >> chicken-and-egg problem that you can solve either by running ‘guix pull’ >> or by running this from your checkout: >> >> $(make as-derivation)/bin/guix environment guix >> >> or: >> >> $(make as-derivation)/bin/guix package -i guile-gcrypt >> >> Besides, our friends at openSuSE have already created a ‘guile-gcrypt’ >> package. :-) >> >> Ludo’. > > Woohoo! Really nice to see that package put to good use! signature.asc Description: PGP signature
Use https in 'gnu/packages/mp3.scm'
Tags: patch Hello, The following patches update urls in 'gnu/packages/mp3.scm' to use https. For the package 'eyed3', I update it to use the redirected url. Cheers, Alex signature.asc Description: PGP signature
Re: Use https in 'gnu/packages/mp3.scm'
Alex Vong writes: > Tags: patch > > Hello, > > The following patches update urls in 'gnu/packages/mp3.scm' to use > https. For the package 'eyed3', I update it to use the redirected url. > > Cheers, > Alex Sorry, I meant to send the mail to guix-patch! signature.asc Description: PGP signature
Re: What ARM hardware should we buy and where should we host it?
On Mon, Sep 03, 2018 at 10:59:38AM -0700, Vagrant Cascadian wrote: > One of the most promising seems to be the SynQuacer: > > https://www.96boards.org/product/developerbox/ > > With a 24-core processor, SATA, PCIe, USB 3.0, micro-atx form-factor, > and 4 ram slots (up to 64GB, in theory, but may be picky about > ram). It has 24 cores of Cortex-A53 CPUs, which are intended for "mobile" applications (smartphones and similar). IMO, it would be great to get more powerful processors. But, if this thing is working for Debian and can handle sustained load on all 24 cores, that's already better than some of the armhf boards we have. According to that Debian mailing list post, this can do both 32 and 64-bit. Steve, do you find the SynQuacer can handle being fully loaded for extended periods of time? signature.asc Description: PGP signature
Re: Firefox 52's end of life, packaging Chromium
Joshua Branson transcribed 1.4K bytes: > Nils Gillmann writes: > > > Joshua Branson transcribed 2.3K bytes: > >> Amin Bandali writes: > >> > >> > Ricardo Wurmus writes: > >> > > >> > >> There is also the Brave browser > >> > >> https://brave.com/ > > > > It would very likely not be accepted in Guix. At least by my > > interpretation of what we have included and cared for so far. Brave is > > basically replacing Ads with other Ads and all the requests you make > > in the browser are send through their proprietary servers. > > Could be that we already discussed Brave a while back on irc or on > > this list. Even when rejected, no onw forbids anyone to provide it > > outside of core. > > Oh really? I had no idea that they send stuff through their proprietary > servers. That doesn't really make it free software. :( Bummer. I've read into it again. Technically their source code is open. But. There's only a minimal gain and possible even inside Guix work to modify Brave to fit into our model, as they use Chromium. It still looks like their server side is proprietary. Understandable, but I'm waiting on how much information they publish with the 1.0 release as they hint to do so in their FAQ (https://brave.com/faq/). I'm interested but very sceptic about it. Read more (but no technical details) at https://brave.com/about-ad-replacement/ Debian has not processed the RFP for it so far: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864795 > > > >> > > >> > In terms of documentation, they have a high-level description of > >> > the various components and patches [1], and build instructions > >> > for a few platforms and distros [2]. There was also an attempt > >> > to make a nix package a while ago [3], which may be helpful to > >> > look at. > >> > > >> > [0]: https://github.com/Eloston/ungoogled-chromium > >> > [1]: > >> > https://github.com/Eloston/ungoogled-chromium/blob/master/docs/design.md > >> > [2]: > >> > https://github.com/Eloston/ungoogled-chromium/blob/master/docs/building.md > >> > [3]: https://github.com/NixOS/nixpkgs/pull/30916 > >> >
