Re: CDN performance

[Chris Marusich]

Meiyo Peng  writes:

> After careful thought, I realized the new CDN won't benefit China
> residents as planned. Any popular CDN outside China is significantly
> throttled by ISP/GFW and the situation is worse every year. A CDN will
> be a great improvement for western countries but not for many asia
> countries.

Could you try running the measure_get shell function I included in the
following email?

https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00192.html

For convenience, here is the definition:

--8<---cut here---start->8---
measure_get () {
curl -L \
 -o /dev/null \
 -w "url_effective: %{url_effective}\\n\
http_code: %{http_code}\\n\
num_connects: %{num_connects}\\n\
num_redirects: %{num_redirects}\\n\
remote_ip: %{remote_ip}\\n\
remote_port: %{remote_port}\\n\
size_download: %{size_download} B\\n\
speed_download: %{speed_download} B/s\\n\
time_appconnect: %{time_appconnect} s\\n\
time_connect: %{time_connect} s\\n\
time_namelookup: %{time_namelookup} s\\n\
time_pretransfer: %{time_pretransfer} s\\n\
time_redirect: %{time_redirect} s\\n\
time_starttransfer: %{time_starttransfer} s\\n\
time_total: %{time_total} s\\n" \
"$1"
}
--8<---cut here---end--->8---

Specifically, I am curious to know what performance you get when you run

  measure_get 
https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19

from a computer in China.  Please be sure to run it two times in a row,
to ensure that CloudFront has cached the object.

CloudFront has edge locations in Hong Kong, so I am curious to know what
performance improvement, if any, you observe.

-- 
Chris


signature.asc
Description: PGP signature

Why is GCL built with gcc@4.9?

[Mark H Weaver]

Hi Efraim,

I'm curious about this commit of yours from April 2017:

--8<---cut here---start->8---
commit 5c7815f205e9164d4b82378de91bee7a65bcfbcb
Author: Efraim Flashner 
Date:   Mon Apr 10 05:20:09 2017 +0300

gnu: gcl: Build with gcc@4.9.

* gnu/packages/lisp.scm (gcl)[native-inputs]: Add gcc@4.9.
--8<---cut here---end--->8---

Do you remember why you did this?  There's no explanation in the
comments, nor in the commit log, nor in the 'bug-guix' or 'guix-devel'
email archives from around that time.

I'd like to remove it, and I've verified that on x86_64-linux, GCL
builds successfully with the default compiler.

In general, it would be good to include comments with rationale for
workarounds like this, so that we have some idea of when the workaround
can be removed, and what tests we must do to ensure that the original
problem has been addressed.

 Thanks,
   Mark

Gash and Geesh together at last

[Timothy Sample]

Hi Guix,

I am very happy to announce that Gash and Geesh are merging into a
single project.  Jan and I discussed this earlier today, and decided
that the time has come.  We worked out a list of goodies from each
project that we should be able to zip together into an even greater
whole.

(A quick bit of context: Gash and Geesh are both shells written in Guile
Scheme and designed for, among other things, being part of the Guix
bootstrap process.)

Roughly speaking, the plan is to take the interface, interpreter,
utilities, most of the built-ins, and the test suite from Gash, and put
that with the parser, environment, word-splitting module, a handful of
built-ins, and the test suites from Geesh.  We decided that it will
probably be easier to move code from Gash into Geesh, so that is what
I’ll be working on next.  I plan to do it in small steps, so there
should be lots of visible progress as it all comes together.

For the final project, I’m hoping we can keep the name Gash, since it is
the older of the two.


-- Tim

Re: GC Warning: Out of Memory

[Rene]

Hello Ludovic,

>
> How did you obtain those .go files?
>

I made a mistake when copying my repository, I cloned the repository again and 
these are my
observations:

To start guix-daemon:

$ sudo ~/guix/pre-inst-env guix-daemon --build-users-group=guixbuild -c 1 
--debug
build log compression: 2
extra chroot directories: ''
automatic deduplication set to 1
listening on `/var/guix/daemon-socket/socket'
524201 operations

On the other hand:

$ ./pre-inst-env guix build hello -n --verbosity=100
...
madvise failed: Function not implemented
madvise failed: Function not implemented
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 2097152 bytes
GC Warning: Out of Memory! Heap size: 113 MiB. Returning NULL!
Warning: Unwind-only `out-of-memory' exception; skipping pre-unwind handler.
madvise failed: Function not implemented

And it does not create any file in `/tmp`.

The error is similar to the one reported[1], but in 2017; Any idea about if it 
is the same situation?

Thank you


Environment:
* guix (GNU Guix) 0.16.0.112-46e61 (master branch)
* Debian/Hurd
* guile (GNU Guile) 2.2.4


[1]https://lists.gnu.org/archive/html/help-guix/2017-11/msg00016.html

Re: Preparing the reduced bootstrap tarballs, take 3

[Mark H Weaver]

Ludovic Courtès  writes:

> Jan Nieuwenhuizen  skribis:
>
>> Ludovic Courtès writes:
>>
>> Hi!
>>
>>> I’ve just uploaded these to
>>> :
>>>
>>>   linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>>>   linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz.sig
>>>   mescc-tools-static-0.5.2-0.bb062b0-i686-linux.tar.xz
>>>   mescc-tools-static-0.5.2-0.bb062b0-i686-linux.tar.xz.sig
>>>   mes-minimal-stripped-0.18-0.08f04f5-i686-linux.tar.xz
>>>   mes-minimal-stripped-0.18-0.08f04f5-i686-linux.tar.xz.sig
>>
>> Great!
>>
>>> Could you adjust bootstrap.scm to refer to this URL?  Currently I see
>>> bootstrap.scm refers to a different version of
>>> linux-libre-headers-stripped so it should be the only one whose hash
>>> needs to be changed.
>>
>> I don't see that...and the hash matches.
>
> We’ve discussed it in person, and now I think we’re all set!  :-)

Does our documentation include instructions on how to reproducibly build
these new bootstrap binaries, to independently verify them?

 Thanks,
   Mark

Re: End of beta soon? drop i686?

[Mark H Weaver]

Hi Joshua,

Joshua Branson  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?

[George Clemmer]

swedebu...@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?

[Joshua Branson]

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

Possible guidelines to package TeXlive

[Pierre Neidhardt]

Héctor from IPFS just pointed me to 

https://build.opensuse.org/package/show/openSUSE%3ALeap%3A15.0/texlive-specs-a

which contains an amazing list of 2000+ TeXlive package recipes!
That could be very useful for Guix ;)

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: GuixSD on AArch64

[Vagrant Cascadian]

On 2018-12-12, Andreas Enge wrote:
> On Mon, Oct 22, 2018 at 12:17:58PM -0700, Vagrant Cascadian wrote:
>> Looking like u-boot 2019.01 might be more likely, but modest patches
>> work with 2018.11-rc2. I'll probably bring the pinebook with me to the
>> Paris meetup in December... though with only 2GB of ram it might not
>> make the most exciting GuixSD system... :)
>
> did you come to the meeting,

Yes! it was good fun.

> and did you manage to install GuixSD on your Pinebook?

Not yet... The substitutes were below 1% for aarch64 the last few weeks,
and only recently have started catching up. And building natively
was... astoundingly slow.

I did get the patched u-boot pinebook into Guix, and tested it
manually. I haven't yet checked current status of linux-libre on
aarch64, which might need some additional kernel configuration features
enabled compared to recent Debian kernel versions.


live well,
  vagrant

Re: bioinformatics.scm vs bioconductor.scm ?

[Ricardo Wurmus]

zimoun  writes:

> Thank you the explanations.
>
>
>> New Bioconductor packages should go to bioconductor.scm.  Eventually we
>> may move all remaining R packages from bioinformatics to
>> bioconductor.scm.
>
> I am a bit confused.
> The file bioconductor.scm contains (or will contain) all R packages
> from Bioconductor, right?

Correct.

> But R packages from CRAN used in Bioinformatics ? bioconductor.scm or
> bioinformatics.scm?

Neither :)  We put them in cran.scm.  At least that’s the new way of
doing this.  Previously it was all ad-hoc, meaning that packages would
end up in bioinformatics.scm…

Ideally, bioinformatics.scm would only contain non-R tools like
samtools, bamtools, bioinfo pipelines, etc.

> And I am asking myself if a massive import from Bioconductor should be
> possible ?

Certainly!  I’ve done this before actually, but I hit two minor
problems:

1. the bioconductor recursive importer does not *automatically* switch
   to “CRAN mode” when a dependent package isn’t found on Bioconductor.
   Not a big problem, but it means that teh import isn’t fully
   automatic.

2. compiling big Guile modules (such as a future (gnu packages cran))
   require lots of memory since Guile 2.2(?), so I didn’t add all these
   packages.  This is a bug and we’d have to split the module, probably,
   to work around it.

--
Ricardo

Re: bioinformatics.scm vs bioconductor.scm ?

[zimoun]

Thank you the explanations.


> New Bioconductor packages should go to bioconductor.scm.  Eventually we
> may move all remaining R packages from bioinformatics to
> bioconductor.scm.

I am a bit confused.
The file bioconductor.scm contains (or will contain) all R packages
from Bioconductor, right?
But R packages from CRAN used in Bioinformatics ? bioconductor.scm or
bioinformatics.scm?

And I am asking myself if a massive import from Bioconductor should be
possible ?

Re: GuixSD on AArch64

[Andreas Enge]

Hello Vagrant,

On Mon, Oct 22, 2018 at 12:17:58PM -0700, Vagrant Cascadian wrote:
> Looking like u-boot 2019.01 might be more likely, but modest patches
> work with 2018.11-rc2. I'll probably bring the pinebook with me to the
> Paris meetup in December... though with only 2GB of ram it might not
> make the most exciting GuixSD system... :)

did you come to the meeting, and did you manage to install GuixSD
on your Pinebook?

Andreas

Re: End of beta soon? drop i686?

[ng0]

Ricardo Wurmus transcribed 659 bytes:
> 
> n...@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: 01/01: hydra: Increase image sizes for USB image and Flash image.

[Giovanni Biscuolo]

Ricardo Wurmus  writes:

> Ludovic Courtès  writes:
>
>> One problem with the installation OS is that it’s pulling ALSA and all
>> sorts of sound-related libraries (libsamplerate, etc.), which clearly is
>> unnecessary in the installation image.  That comes from the alsa-utils
>> udev rules.  We could remove those udev rules, but since they’re in
>> %base-services, I chose not to do that to avoid breaking everyone’s
>> config.

for sure users should be warned of this important change, anyway I doubt
any user using sound does not use %desktop-services (possibly customized)

> I’m in favour of moving them elsewhere, such as %desktop-services.

yes please: sound related services are not-so-base, we do not need them
on installation/web/mail/DNS et. al servers (and containers) and it does
not makes much sense to remove them an all that class of
hosts/containers

it makes sense - semantically speaking - to move sound to
%desktop-services since we only need sound on desktops

thanks!
Gio

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: GuixSD on eoma68-a20?

[Danny Milosavljevic]

Ye!

flash-image just successfully built on Hydra.

Can I have the resulting file please?

See https://hydra.gnu.org/build/3255541/log/raw


pgpDhY5HPmJHh.pgp
Description: OpenPGP digital signature