From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: End of beta soon? drop i686? Date: Tue, 11 Dec 2018 15:02:54 -0500 Message-ID: <87y38val12.fsf@netris.org> References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54609) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWoGK-0002bG-TS for guix-devel@gnu.org; Tue, 11 Dec 2018 15:04:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gWoGH-000199-5G for guix-devel@gnu.org; Tue, 11 Dec 2018 15:04:12 -0500 Received: from world.peace.net ([64.112.178.59]:54814) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gWoGG-00011f-T2 for guix-devel@gnu.org; Tue, 11 Dec 2018 15:04:08 -0500 In-Reply-To: (swedebugia's message of "Mon, 10 Dec 2018 23:58:24 -0800") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: swedebugia@riseup.net Cc: guix-devel@gnu.org Hi, In this message, I'll respond to only one of your points: swedebugia@riseup.net writes: > 3) icecat does not have a substitute available and guix package -i > icecat -n outputs: > The following derivations would be built: > /gnu/store/7wmg5qw3s45mi8ss9q3q45hfmx3j91y6-profile.drv > /gnu/store/sfpiyr8mksl13g1kycigfi7yddf9pyi1-info-dir.drv > /gnu/store/rm2hf8k5iawdqwi4ngjkndnws47cwnb7-glib-schemas.drv > /gnu/store/rc6v87y5afpn5lcxn1fpm8dhzh9psgkj-xdg-desktop-database.drv > /gnu/store/r5zvxiwbglk3z0vv1vxpr00fz0j0bavp-ca-certificate-bundle.drv > /gnu/store/hxldf31yk8v0kx2vrmdxhca0vqmgd36h-xdg-mime-database.drv > /gnu/store/kc1g4aiizjd83cmfnr29qk36znkb971f-rust-1.19.0.drv > /gnu/store/4fc6d5aw42gpypq42svdn2l00lidw8r5-rust-1.20.0.drv > /gnu/store/bzgwrd3dyw6kxq6lkrqfdh13xfl5gq2q-rust-1.21.0.drv > /gnu/store/2s3y8vpvcc2rplsf8k3m787ildyd01xi-rust-1.22.1.drv > /gnu/store/gww3qar4hrab1r6cnyafpk8wg44znzb9-rust-1.23.0.drv > /gnu/store/aq8fy5fhr5rx3na83ziv48aqy4dbbf1w-rust-1.24.1.drv > /gnu/store/70p9k9zd680lmwxqa03whpwq6xwywr1i-fonts-dir.drv > /gnu/store/65hdbc7gzlxk1fwn658y6rjqb9k1dbh4-gtk-im-modules.drv > /gnu/store/3lwwhgh4sijdb7bf7lkhnb777xxvax4v-gtk-icon-themes.drv > /gnu/store/bxz8fxgmm1cgclkz5540nxibp0n3b5c9-icecat-60.3.0-gnu1.drv > /gnu/store/s7kskm9w8fr0fr5b7m2rlap843cmqh8s-manual-database.drv > > Having heard how a horror and RAM hog rust is I simply cannot use the > web on this guix version and would have to downgrade. The problem with > downgrading is lack of information. Building guix takes time and I dont > know which latest version of guix has an icecat x86 64-bit binary. The reason that substitutes are not available for 'icecat' on i686 is because 'rust' consistently fails to build on i686. On the master branch, it became broken in early November, when the source-only 'rust' bootstrap was merged into our 'master' branch. Note that we also lost 'icecat' on armhf-linux with the 52->60 upgrade, because our 'rust' packages have never worked on armhf-linux. > Earlier running 0.15 and later on a x86 64 bit install I had far better > coverage of substitutes and fewer errors (before latest core-updates > merge). Unfortunately, as I've lamented before, current Guix development practices work well only on x86_64-linux, because that's the only system that's consistently well tested by upstream. On other systems, software is frequently broken by upstream changes, and the Guix community does not have enough non-x86_64 developer energy to keep up with the large number of portability bugs that arise on the cutting edge of development. > Lets either drop i686 support or test it more and look into the missing > substitutes. I'm opposed to dropping i686 support. If we dropped support for systems that are not well supported in Guix, the only system left standing would be x86_64-linux. I believe it is of paramount importance that Guix be portable to multiple processor architectures. Even if we are not yet able to provide a good user experience on other systems, we can still keep the bulk of our code portable and multi-architecture aware. Mark