End of beta soon? drop i686?

End of beta soon? drop i686?

[swedebugia]

Hi

First of all thanks for building a great OS! (im writing this in vimb in
guixsd) :D

Below is my reaction to the talk about 1.0 that has appeared on the
list.

I see Ludo' is entuthiastic about 1.0 and hope to reach that soon.

I recently decided to try running guix as a daily system to test and
hunt bugs and have fun.

In my view we still have a system where encountering a bug is still far
more common than any other OS I ever used.

Some of these bugs of course stems from the user not knowing how guix
works, but in my case I had to manage and work-around to just keep going
and getting things done.

For that reason I think we are still quite far from 1.0 at the moment.

That could of course change quickly, but I see more energy going into
updating (a tad rushed if you ask me) and packaging and this introduces
new instabilities and bugs a little faster than we can keep up it seems.

E.g. on 0.16.0-3.6ddc63e (a few days behind master) on an i686-install
on a x86 64 bit machine with a slow disk and 2GB RAM
1) right now webkit freezes on youtube

2) reconfigure is broken, see resent thread
$ sudo -E ~/src/guix/pre-inst-env guix system reconfigure ~/config.scm 
Password: 
guile: warning: failed to install locale
Backtrace:
In ice-9/boot-9.scm:
  2726:13 19 (_)
In ice-9/threads.scm:
    390:8 18 (_ _)
In ice-9/boot-9.scm:
  2994:20 17 (_)
   2312:4 16 (save-module-excursion #<procedure 9e63af8 at ice-9/boo?>)
  3014:26 15 (_)
In unknown file:
          14 (primitive-load-path "gcrypt/hash" #<procedure 9f4e260 ?>)
In gcrypt/hash.scm:
     19:0 13 (_)
In ice-9/boot-9.scm:
   2874:4 12 (define-module* _ #:filename _ #:pure _ #:version _ # _ ?)
  2887:24 11 (_)
   222:17 10 (map1 (((gcrypt common)) ((gcrypt utils)) ((rnrs #)) # ?))
  2800:17  9 (resolve-interface (gcrypt common) #:select _ #:hide _ # ?)
In ice-9/threads.scm:
    390:8  8 (_ _)
In ice-9/boot-9.scm:
  2726:13  7 (_)
In ice-9/threads.scm:
    390:8  6 (_ _)
In ice-9/boot-9.scm:
  2994:20  5 (_)
   2312:4  4 (save-module-excursion #<procedure 9e63a98 at ice-9/boo?>)
  3014:26  3 (_)
In unknown file:
           2 (primitive-load-path "gcrypt/common" #<procedure 9f9fe3?>)
In gcrypt/common.scm:
    35:13  1 (_)
In unknown file:
           0 (dynamic-link "/gnu/store/7y93yw3110fimzyrqlda7s7633ijk?")

ERROR: In procedure dynamic-link:
In procedure dynamic-link: file:
"/gnu/store/7y93yw3110fimzyrqlda7s7633ijkxcq-libgcrypt-1.8.3/lib/libgcrypt",
message: "file not found"


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.

4) gnome-shell-extensions does not work with any of the browsers
available it seems.

5) our bug tracker is hard to navigate (for newcomers at least).
(surprisingly we do not seem to have a lot of duplicate bugs though)

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).

To sum it up: lets not ruin what we have by rushing ahead and ending
beta too early.

Lets either drop i686 support or test it more and look into the missing
substitutes. 

I'm in favor of dropping i686 and let somebody else create a guix-32-bit
fork like what happened in Arc. Then we can focus on bughunting 64 bit
and working with the more promising architectures like those I mentioned
lately on devel instead of wasting time on slow legacy intel-backdoored
architecture.

-- 
Cheers
Swedebugia

Re: End of beta soon? drop i686?

[ng0]

swedebugia@riseup.net transcribed 4.7K bytes:
> Hi
> 
> First of all thanks for building a great OS! (im writing this in vimb in
> guixsd) :D
> 
> Below is my reaction to the talk about 1.0 that has appeared on the
> list.
> 
> I see Ludo' is entuthiastic about 1.0 and hope to reach that soon.
> 
> I recently decided to try running guix as a daily system to test and
> hunt bugs and have fun.
> 
> In my view we still have a system where encountering a bug is still far
> more common than any other OS I ever used.
> 
> Some of these bugs of course stems from the user not knowing how guix
> works, but in my case I had to manage and work-around to just keep going
> and getting things done.
> 
> For that reason I think we are still quite far from 1.0 at the moment.
> 
> That could of course change quickly, but I see more energy going into
> updating (a tad rushed if you ask me) and packaging and this introduces
> new instabilities and bugs a little faster than we can keep up it seems.
> 
> E.g. on 0.16.0-3.6ddc63e (a few days behind master) on an i686-install
> on a x86 64 bit machine with a slow disk and 2GB RAM
> 1) right now webkit freezes on youtube
> 
> 2) reconfigure is broken, see resent thread
> $ sudo -E ~/src/guix/pre-inst-env guix system reconfigure ~/config.scm 
> Password: 
> guile: warning: failed to install locale
> Backtrace:
> In ice-9/boot-9.scm:
>   2726:13 19 (_)
> In ice-9/threads.scm:
>     390:8 18 (_ _)
> In ice-9/boot-9.scm:
>   2994:20 17 (_)
>    2312:4 16 (save-module-excursion #<procedure 9e63af8 at ice-9/boo?>)
>   3014:26 15 (_)
> In unknown file:
>           14 (primitive-load-path "gcrypt/hash" #<procedure 9f4e260 ?>)
> In gcrypt/hash.scm:
>      19:0 13 (_)
> In ice-9/boot-9.scm:
>    2874:4 12 (define-module* _ #:filename _ #:pure _ #:version _ # _ ?)
>   2887:24 11 (_)
>    222:17 10 (map1 (((gcrypt common)) ((gcrypt utils)) ((rnrs #)) # ?))
>   2800:17  9 (resolve-interface (gcrypt common) #:select _ #:hide _ # ?)
> In ice-9/threads.scm:
>     390:8  8 (_ _)
> In ice-9/boot-9.scm:
>   2726:13  7 (_)
> In ice-9/threads.scm:
>     390:8  6 (_ _)
> In ice-9/boot-9.scm:
>   2994:20  5 (_)
>    2312:4  4 (save-module-excursion #<procedure 9e63a98 at ice-9/boo?>)
>   3014:26  3 (_)
> In unknown file:
>            2 (primitive-load-path "gcrypt/common" #<procedure 9f9fe3?>)
> In gcrypt/common.scm:
>     35:13  1 (_)
> In unknown file:
>            0 (dynamic-link "/gnu/store/7y93yw3110fimzyrqlda7s7633ijk?")
> 
> ERROR: In procedure dynamic-link:
> In procedure dynamic-link: file:
> "/gnu/store/7y93yw3110fimzyrqlda7s7633ijkxcq-libgcrypt-1.8.3/lib/libgcrypt",
> message: "file not found"
> 
> 
> 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.
> 
> 4) gnome-shell-extensions does not work with any of the browsers
> available it seems.
> 
> 5) our bug tracker is hard to navigate (for newcomers at least).
> (surprisingly we do not seem to have a lot of duplicate bugs though)
> 
> 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).
> 
> To sum it up: lets not ruin what we have by rushing ahead and ending
> beta too early.

Agreed, and I would add a plea to focus more on Shepherd before it is
called 1.0.

> Lets either drop i686 support or test it more and look into the missing
> substitutes. 
> 
> I'm in favor of dropping i686 and let somebody else create a guix-32-bit
> fork like what happened in Arc. 

Entirely dropping it will be easy. But it involves much more than just
the packages. And once you go beyond just the packages fork work is
high-friction work. Even just the packages can be, depending on how the
person approaches it, semi-high friction work.

Let's not drop an architecture because occasionally something breaks for
it. breakage is bad, yes. but it's more than just the broken packages.
it is the way patches find their way into master. if you have more
patience then I had, you can try to address the workflow in guix (there
will be some past discussions you can find on the mailinglists).

I've been on the high-friction lane with GuixSD, so I am talking from
experience and not just assumptions.
 
> Then we can focus on bughunting 64 bit
> and working with the more promising architectures like those I mentioned
> lately on devel instead of wasting time on slow legacy intel-backdoored
> architecture.

I disagree that legacy architectures should be dropped. Everything we have
at the moment which is affordable is so called legacy. You have to go back
very far in time to get hardware which wasn't build on the decisions intel
(and AMD!) took. even if guix had support for those older architectures
I'd still consider the idea not worth following through. guix would disregard
a broad spectrum of people who financially or by locationcan not afford or
get hardware other than the current supported one. Not everyone is capable or
willing to send patches or bugreports to address their problems.

If spectre and friends is the base of argumentation, x86_64 would have to
be dropped too and instead only focus on a small subset of arm and older
architectures.

> -- 
> Cheers
> Swedebugia
> 

Re: End of beta soon? drop i686?

[Mark H Weaver]

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

Re: End of beta soon? drop i686?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

Hi Mark,

> Note that we also lost 'icecat' on armhf-linux with the 52->60 upgrade,
> because our 'rust' packages have never worked on armhf-linux.

Wait, what?  I wasn't aware.  Let's track this as a bug - that's
definitely not supposed to happen.

mrustc works on armhf - I tested it on physical armhf hardware before merging.

So one of the other Rusts doesn't work?  I'll check out Hydra logs...

https://hydra.gnu.org/build/3215481/nixlog/1/raw indicates a timeout of
silence - we might want to increase it.  (this particular step takes many
many MANY minutes on x86_64, too).

Would that be the "(properties '((timeout . 3600)))))" thing?  Or is a
"timeout of silence" an extra setting?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: End of beta soon? drop i686?

[Mark H Weaver]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> Hi Mark,
>
>> Note that we also lost 'icecat' on armhf-linux with the 52->60 upgrade,
>> because our 'rust' packages have never worked on armhf-linux.
>
> Wait, what?  I wasn't aware.  Let's track this as a bug - that's
> definitely not supposed to happen.
>
> mrustc works on armhf - I tested it on physical armhf hardware before merging.
>
> So one of the other Rusts doesn't work?  I'll check out Hydra logs...
>
> https://hydra.gnu.org/build/3215481/nixlog/1/raw indicates a timeout of
> silence - we might want to increase it.  (this particular step takes many
> many MANY minutes on x86_64, too).
>
> Would that be the "(properties '((timeout . 3600)))))" thing?  Or is a
> "timeout of silence" an extra setting?

'max-silent-time' is the property specifying the number of seconds of
silence before aborting the build.  For example, here's the 'properties'
field of our guile-2.2 package:

    (properties '((timeout . 72000)               ;20 hours
                  (max-silent-time . 36000)))     ;10 hours (needed on ARM
                                                  ;  when heavily loaded)

The timeouts should be large enough to accommodate an armhf build slave
that's performing two concurrent builds.

     Thanks,
       Mark

Re: End of beta soon? drop i686?

[Ricardo Wurmus]

ng0@n0.is writes:

> Let's not drop an architecture because occasionally something breaks for
> it. breakage is bad, yes. but it's more than just the broken packages.
> it is the way patches find their way into master. if you have more
> patience then I had, you can try to address the workflow in guix (there
> will be some past discussions you can find on the mailinglists).
>
> I've been on the high-friction lane with GuixSD, so I am talking from
> experience and not just assumptions.

I don’t understand what you are alluding to.  Could you please
elaborate?  Could you translate this into concrete suggestions or
expectations? 

--
Ricardo

Re: End of beta soon? drop i686?

[Ricardo Wurmus]

Mark H Weaver <mhw@netris.org> writes:

>> 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.

I whole-heartedly agree with Mark.  We will not drop i686 support.

--
Ricardo

sent not too far away from my i686 GuixSD machine

Re: End of beta soon? drop i686?

[Andreas Enge]

On Wed, Dec 12, 2018 at 03:16:56AM +0100, Ricardo Wurmus wrote:
> > 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.
> 
> I whole-heartedly agree with Mark.  We will not drop i686 support.

And a big advantage of i686, even if noone were to use it anymore, is that
we have a large build farm capacity, since it is built on the x86_64 machines.
So it can act as our "canary in the mine", warning of portability problems.

Andreas

Re: End of beta soon? drop i686?

[ng0]

Ricardo Wurmus transcribed 659 bytes:
> 
> ng0@n0.is writes:
> 
> > Let's not drop an architecture because occasionally something breaks for
> > it. breakage is bad, yes. but it's more than just the broken packages.
> > it is the way patches find their way into master. if you have more
> > patience then I had, you can try to address the workflow in guix (there
> > will be some past discussions you can find on the mailinglists).
> >
> > I've been on the high-friction lane with GuixSD, so I am talking from
> > experience and not just assumptions.
> 
> I don’t understand what you are alluding to.  Could you please
> elaborate?  Could you translate this into concrete suggestions or
> expectations? 

I've suggested enough over the years and it was always "oh, good idea".
Whoever wants to improve the state of simply commiting to master etc
can do it, I myself no longer care (which I don't mean in a negative
sense, I just have enough other things to focus on).

> --
> Ricardo
> 

Re: End of beta soon? drop i686?

[Joshua Branson]

swedebugia@riseup.net writes:

> Hi
>
>
> E.g. on 0.16.0-3.6ddc63e (a few days behind master) on an i686-install
> on a x86 64 bit machine with a slow disk and 2GB RAM
> 1) right now webkit freezes on youtube

While, a FSF endorsed distro has no requirement to support a non-free
website, as a youtube addict, I can see your point.  I currently use
Parabola's version of icecat, because it is generally better than
Guix's.

The last time I tried guix's iceweasel, it was *un-useable* on many
sites I came across.  I couldn't log into my bank account (though that's
probably 'cause my bank only lets you log in via "firefox"), youtube
stopped working, scrolling was choppy, changing tabs took 3+ seconds.
The whole time I used it, I was just waiting for it to crash.  I would
have to periodically close iceweasel, because if I didn't, it would
crash and suspend my system.  Then I would have to do a hard restart to
recover.  I was unable to switch to another virtual console to kill
iceweasel.  This still happens occasionally with Parabola though.

(note, I'm running Parabola with guix installed.  I'm running guix's emacs).

Also what's a freedom alternative to youtube?  libre.fm is pretty swell,
but their music collection doesn't seem to be increasing.  I suppose I
could get into podcasting some more.

Does anyone know where I can freedom-ly listen to Ben Shapiro, Steven
Crowder, and other conservative news hosts, and watch movie trailers?  I
suppose I could listen to their podcasts...

> 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.

I had a similar issue a few days ago.  I have 4GB of ram on a Macbook
7,1.  There was no substitute available for gcc.  Twice guix pull failed
to, because I could not build gcc.  Luckily, today there is a gcc
substitute, and guix pull worked wonderfully.

However, can this problem be solved by guix?  This might be a problem
that ought to be addressed upstream.

> 5) our bug tracker is hard to navigate (for newcomers at least).
> (surprisingly we do not seem to have a lot of duplicate bugs though)

There is a nice web version that someone wrote.  I forget where it is,
but it's really slick!

> To sum it up: lets not ruin what we have by rushing ahead and ending
> beta too early.

I reluctantly agree.

--
Joshua Branson
Sent from Emacs and Gnus

Re: End of beta soon? drop i686?

[Mark H Weaver]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> writes:

>> Note that we also lost 'icecat' on armhf-linux with the 52->60 upgrade,
>> because our 'rust' packages have never worked on armhf-linux.
>
> Wait, what?  I wasn't aware.  Let's track this as a bug - that's
> definitely not supposed to happen.
>
> mrustc works on armhf - I tested it on physical armhf hardware before merging.
>
> So one of the other Rusts doesn't work?  I'll check out Hydra logs...
>
> https://hydra.gnu.org/build/3215481/nixlog/1/raw indicates a timeout of
> silence - we might want to increase it.  (this particular step takes many
> many MANY minutes on x86_64, too).
>
> Would that be the "(properties '((timeout . 3600)))))" thing?  Or is a
> "timeout of silence" an extra setting?

I see that you increased the timeouts for rust-1.19.0, and I asked Hydra
to retry the build.  It failed again, in a different way:

  https://hydra.gnu.org/build/3215481/nixlog/2/raw

      Mark

Re: End of beta soon? drop i686?

[Mark H Weaver]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> writes:

>> Note that we also lost 'icecat' on armhf-linux with the 52->60 upgrade,
>> because our 'rust' packages have never worked on armhf-linux.
>
> Wait, what?  I wasn't aware.  Let's track this as a bug - that's
> definitely not supposed to happen.
>
> mrustc works on armhf - I tested it on physical armhf hardware before merging.
>
> So one of the other Rusts doesn't work?  I'll check out Hydra logs...
>
> https://hydra.gnu.org/build/3215481/nixlog/1/raw indicates a timeout of
> silence - we might want to increase it.  (this particular step takes many
> many MANY minutes on x86_64, too).
>
> Would that be the "(properties '((timeout . 3600)))))" thing?  Or is a
> "timeout of silence" an extra setting?

I see that you increased the timeouts for rust-1.19.0, and I asked Hydra
to retry the build.  It failed again, in a different way:

  https://hydra.gnu.org/build/3215481/nixlog/2/raw

      Mark

Re: End of beta soon? drop i686?

[George Clemmer]

swedebugia@riseup.net writes:

> First of all thanks for building a great OS!
+1

> In my view we still have a system where encountering a bug is still far
> more common than any other OS I ever used.
+1

> To sum it up: lets not ruin what we have by rushing ahead and ending
> beta too early.
+1

FWIW, GuixSD has been my daily headless server driver for ~3 years.

Re: End of beta soon? drop i686?

[Mark H Weaver]

Hi Joshua,

Joshua Branson <jbranso@dismail.de> writes:

> The last time I tried guix's iceweasel, it was *un-useable* on many
> sites I came across.  I couldn't log into my bank account (though that's
> probably 'cause my bank only lets you log in via "firefox"), youtube
> stopped working, scrolling was choppy, changing tabs took 3+ seconds.
> The whole time I used it, I was just waiting for it to crash.  I would
> have to periodically close iceweasel, because if I didn't, it would
> crash and suspend my system.  Then I would have to do a hard restart to
> recover.  I was unable to switch to another virtual console to kill
> iceweasel.  This still happens occasionally with Parabola though.

I'm reasonably sure that Guix has never had an iceweasel package.
Am I mistaken, or did you mean to say something else?

      Mark

Re: End of beta soon? drop i686?

[swedebugia]

On 2018-12-12 08:40, Andreas Enge wrote:
> On Wed, Dec 12, 2018 at 03:16:56AM +0100, Ricardo Wurmus wrote:
>>> 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.
>>
>> I whole-heartedly agree with Mark.  We will not drop i686 support.
> 
> And a big advantage of i686, even if noone were to use it anymore, is that
> we have a large build farm capacity, since it is built on the x86_64 machines.
> So it can act as our "canary in the mine", warning of portability problems.

Thanks for sharing your views on this.

I suggest we clearly state in the download page and or in the manual 
(Limitations) that i686 is a somewhat rough experience with not as many 
substitutes as x86_64 and might have more bugs too.

-- 
Cheers
Swedebugia