Re: 34/44: gnu: Add texlive-fonts-ec.

[Ricardo Wurmus]

Hi Mark,

> There's a problem with this commit:
>
> rek...@elephly.net (Ricardo Wurmus) writes:
>> rekado pushed a commit to branch master
>> in repository guix.
>>
>> commit 83c830d1ac010873f702c24542a184cfe07368e3
>> Author: Ricardo Wurmus 
>> Date:   Sun Jul 9 11:55:23 2017 +0200
>>
>> gnu: Add texlive-fonts-ec.
>>
>> * gnu/packages/tex.scm (texlive-fonts-ec): New variable.
>> ---

[…]

> When I try to update my system, I get this:
>
> --8<---cut here---start->8---
> [...]
> Checked out revision 44591.
> A/gnu/store/jnppkb5misjjv8n686sk1lsswbbvqing-svn-checkout/extramarks.sty
> A/gnu/store/jnppkb5misjjv8n686sk1lsswbbvqing-svn-checkout/fancyhdr.sty
> A
> /gnu/store/jnppkb5misjjv8n686sk1lsswbbvqing-svn-checkout/fancyheadings.sty
> Checked out revision 44591.
> svn: E000110: Unable to connect to a repository at URL 
> 'svn://www.tug.org/texlive/tags/texlive-2017.1/Master/texmf-dist/fonts/source/jknappen/ec'
> svn: E000110: Unknown hostname 'www.tug.org'
> r:sha256 hash mismatch for output path 
> `/gnu/store/yfs603a9a4h8zzkdvmyz3krkj12rxhwf-svn-checkout'
>   expected: 12av65fbz9xiashm09c9m1fj1mijxls5xspd7652ry1n5s0nixy4
>   actual:   0mc5p8r5ifi5l29wvcc9hs0pxg6knrvlwn3cgwrcpq4w9xckj9sf
> note: keeping build directory `/tmp/guix-build-svn-checkout.drv-0'
> cannot build derivation 
> `/gnu/store/rwy7f6rz0n88k71jqwljms8sy0n40xsf-texlive-fonts-ec-44591.drv': 1 
> dependencies couldn't be built
> note: keeping build directory `/tmp/guix-build-svn-checkout.drv-1'
> cannot build derivation 
> `/gnu/store/9rkqalxks2j663axrrknx0jjvi06m8ls-texlive-union-44591.drv': 1 
> dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/m9yzz9h1xiblb5qgf230v0hz05flvz6p-dblatex-0.3.9.drv': 1 
> dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/kgbmych3lxsrnn4c3g95s041mp2kz9jq-gtk-doc-1.25.drv': 1 
> dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/d0ysllgpcr8rp49f8g67rbm923c5z0f3-libosinfo-1.0.0.drv': 1 
> dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/65k665a2knqnfk551vdq6v26zr8i941z-tracker-1.12.0.drv': 1 
> dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/krlsqx1jka9s6wirmw2vpgwq595lz3ra-nautilus-3.24.1.drv': 1 
> dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/9gz7fg4i3whk26ci2mhv2n9598nq9bqz-gnome-3.24.2.drv': 1 
> dependencies couldn't be built
> guix system: error: build failed: build of 
> `/gnu/store/9gz7fg4i3whk26ci2mhv2n9598nq9bqz-gnome-3.24.2.drv' failed
> --8<---cut here---end--->8---

I cannot reproduce this.

Did you maybe get an error page with a different hash instead of the
actual SVN checkout?

This message seems to indicate that:

> svn: E000110: Unable to connect to a repository at URL 
> 'svn://www.tug.org/texlive/tags/texlive-2017.1/Master/texmf-dist/fonts/source/jknappen/ec'
> svn: E000110: Unknown hostname 'www.tug.org'

I’ve tried downloading this directory again and I get the same hash as
before.  Maybe it was a temporary problem?

> Also, it would be good to add 'file-name' fields to these svn-checkouts.
> I noticed that I'm downloading a large number of store items named
> /gnu/store/X-svn-checkout, without any indication of which
> package it corresponds to.

Oh, yes, I agree.  I’ll add “file-name” to these packages.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Guix infrastructure

[ng0]

I have no time  at the moment for a full reply,
but I think we got off at the wrong foot Ricardo.

I guess you are trying to read between the lines
that I tried to be negative about everyones work.
I don't have any subtext.
What I could've done better is go more into detail.

Where did I get the impression of Guix and Guile being
intransparent about the bug? I opened a bug, saw one thread
on the guile mailinglist, and that's it. So given the fact
that I am not omniscient my only logical assumption was that
not much happened in public space.

The rest was run over, but we had some chats over the
weekend and our solution to our side of this is more
clear now. It's not yet ready to be published, but I'll
keep Guix in the loop.

Liam Wigney transcribed 3.4K bytes:
> Hey all,
> 
> While I'm aware it was mentioned that server power was mentioned as an issue, 
> OpenQA might be of interest for automatic testing. 
> 
> > On 9 Jul 2017, at 6:51 pm, Ricardo Wurmus  wrote:
> > 
> > 
> > Hi ng0,
> > 
> >> - master is not stable and it is not being treated as a high priority
> >>  problem
> > 
> > I don’t know where you get this from and I don’t appreciate the
> > insinuation that we don’t care.  The vast majority of commits to
> > “master” are totally fine.
> > 
> > As we don’t have the resources for maintaining a stable branch, “master”
> > is a best effort.
> > 
> >> - a bug in the compiler which is used in the core of Guix is bad.
> > 
> > We all agree here.  I don’t see the point of reiterating it.  The people
> > who can fix it are already working on it — in their own time and in
> > *addition* to all the things they regularly do.
> > 
> > Here’s a shout out to Ludo who tirelessly fixes old and new bugs,
> > implements new features, improves performance, deals with GSoC, and
> > answers community questions; to Andy Wingo who continuously improves
> > Guile performance, implements new Guix services, drafted and implemented
> > the potluck faster than I could blink, …; to Leo and Mark and Marius who
> > keep on top of security issues despite the fact that this is no fun; —
> > the list goes on and on.
> > 
> > Andy and Ludo are working on the Guile bug already.  I don’t see how
> > this can reasonably result in complaints.
> > 
> >>  In my
> >>  understanding that we could at least try to evade this by reducing the
> >>  module sizes is met with arguments like "this will be fixed in the
> >>  future, for now we can only split 1 module the rest has to stay
> >>  together for semantic and linguistic reasons".
> >>  If my understanding of the whole situation is wrong this is due to the
> >>  intransparent dealing with this serious problem and the way my idea
> >>  to temporarily fix it was met.
> > 
> > “Intransparent”?  I don’t know what else to say here.
> > 
> > Breaking up modules is *not* a fix, not even a temporary fix.  How would
> > this help when Guile never frees memory and the cumulative usage ends up
> > being the same?  This is something that needs to be fixed in Guile and
> > both Andy and Ludo have already spent time to investigate this and come
> > up with solutions.
> > 
> > I also wrote that splitting up (gnu packages python) is fine – yet I
> > have not seen a patch that would do this.  There’s only so much a single
> > person can do.
> > 
> > I’m skipping the rest of the complaints in this paragraph, because they
> > add nothing new and ignore the late night efforts of people in the Guix
> > and Guile communities.
> > 
> >> - Writing system services in Shepherd is hard.
> > 
> > I beg to differ.  If you have legitimate concerns please point out the
> > sections in the manuals that are unclear and propose changes.
> > 
> >> These are the major issues Guix could fix.
> > 
> > “Guix” is people.
> > 
> > Personally, I don’t want to spend more time on this discussion, because
> > I want to get back to getting things done that probably only few people
> > will see or notice, but which need to be done anyway.
> > 
> > --
> > Ricardo
> > 
> > GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> > https://elephly.net
> > 
> > 
> 

-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org


signature.asc
Description: PGP signature

Re: core-updates on Hurd

[Ludovic Courtès]

Hello!

Ricardo Wurmus  skribis:

>   105<--153(pid1070)->dir_lookup ("home/buzz/guix/gnu/packages/zation.scm" 64 
> 0) = 0x4002 (No such file or directory) 

I looked more closely, logged in on darnassus, and commit
1ab9e483391f8b62b873833ea71cb0074efa03e7 fixes it AFAICS.

The problem was that ‘struct dirent64’ is slightly different on GNU/Hurd
than on GNU/Linux.

Rennes, could you confirm that it works for you?

Thank you!

Ludo’.

Re: Inkscape libpoppler error

[Mark H Weaver]

Mark H Weaver  writes:

> Kei Kebreau  writes:
>
>> Kei Kebreau  writes:
>>
>>> Daniel Pimentel  writes:
>>>
 Hi guixs,

 today I updated my GuixSD but my Inkscape not start :(

 I installed poppler and I reinstaled inkscape too. In my
 ~/.guix-profile there isn't libpoppler.so.66 but in my system there:
 /gnu/store/mpq4v7hgg02gl0bkjjq8612rm3sira5s-poppler-0.52.0/lib/libpoppler.so.66
 /gnu/store/c31lmp5smk9snfyb8rf7mmzrdv15aps8-poppler-0.52.0/lib/libpoppler.so.66
 /gnu/store/8c0bj7imclym7rmf1pa3cgf2xg1qbv25-poppler-0.52.0/lib/libpoppler.so.66

 Error output:
 inkscape: error while loading shared libraries: libpoppler.so.66:
 cannot open shared object file: No such file or directory
>>>
>>> Hi Daniel,
>>>
>>> I just checked the inkscape package on my computer and I got the same
>>> error. I'm looking into the problem now. Sorry for the inconvenience.
>>
>> I've found the source of the issue and I'm seeing about fixing it. In
>> the meantime, you can reinstall inkscape using the following command:
>>
>> guix package -i inkscape --no-grafts
>
> For the details about what's going on here, see:
>
>   https://bugs.gnu.org/27621

The problem with libpoppler is now fixed, so I recommend that you run
"guix pull" (or equivalent) and then "guix package -i inkscape" at your
earliest opportunity.  Running ungrafted software is best avoided,
because it leaves many security flaws unpatched.

  Mark

Re: 01/01: gnu: wxmaxima: Update to 17.05.0.

[Mark H Weaver]

Kei Kebreau  writes:

> Mark H Weaver  writes:
>
>> k...@openmailbox.org (Kei Kebreau) writes:
>>
>>> @@ -2172,6 +2176,10 @@ point numbers.")
>>> ("shared-mime-info" ,shared-mime-info)))
>>>  (arguments
>>>   `(#:phases (modify-phases %standard-phases
>>> +  (add-before
>>> +   'configure 'autoconf
>>> +   (lambda _
>>> + (zero? (system* "./bootstrap"
>>
>> In general, autoconf-style phases like this should be put after the
>> 'unpack' phase, not before the 'configure' phase.  The reason is that on
>> some platforms (e.g. mips64el-linux), the 'patch-usr-bin-file' phase
>> needs to be able to operate on the generated configure script.
>>
>> When you move the phase earlier, you may then find that you need to
>> launch the 'bootstrap' script differently, because its shebang will not
>> be correct.  That's because it will now be run before the
>> 'patch-source-shebangs' phase.
>>
>> So, the way we normally do this is to run something like:
>>
>>   (zero? (system* "sh" "bootstrap"))
>>
>> Grepping for "add-before 'configure" reveals that there are now a rather
>> large number of instances of this problem.  Oh well.
>>
>>Mark
>
> I see. Thank you for the correction.
>
> Do you consider it worth going through the package code and patching
> this problem specifically or should it be corrected gradually while
> making other changes?

If you (or anyone else) is willing to work on this, I think it would be
quite helpful to go through and fix some or all of these problems
proactively.  It's quite common for people to look at existing packages
for examples of how things should be done, so the presence of these
mistakes in our tree will spawn new instances of the same mistake until
they are eradicated :)

Two things to keep in mind:

* If changing a package would trigger a large number of rebuilds, the
  change should be made on 'core-updates' instead.

* For each change on 'master', we should make sure the package still
  builds successfully before pushing it.  That should be enough testing
  for kind of change.

 Thanks!
   Mark

Re: python-conda: Build is not reproducible

[Ludovic Courtès]

Hi Frederick,

Frederick Muriithi  skribis:

> On Fri, Jul 7, 2017 at 3:03 PM, Ludovic Courtès  wrote:
>> Hello,
>>
>> This is most likely a consequence of .
>>
>> Can you run:
>>
>>   diff -ru --no-dereference \
>> /gnu/store/302bb93kq3170xr57vijil7cya2s74ir-python-conda-4.3.16{,-check}
>>
>> to confirm that only Python object files are affected?
>>
>
> The output of running that is:
>
> Binary files 
> /gnu/store/302bb93kq3170xr57vijil7cya2s74ir-python-conda-4.3.16/lib/python3.5/site-packages/conda/cli/__pycache__/help.cpython-35.pyc
> and 
> /gnu/store/302bb93kq3170xr57vijil7cya2s74ir-python-conda-4.3.16-check/lib/python3.5/site-packages/conda/cli/__pycache__/help.cpython-35.pyc
> differ
> Binary files 
> /gnu/store/302bb93kq3170xr57vijil7cya2s74ir-python-conda-4.3.16/lib/python3.5/site-packages/conda/cli/__pycache__/install.cpython-35.pyc
> and 
> /gnu/store/302bb93kq3170xr57vijil7cya2s74ir-python-conda-4.3.16-check/lib/python3.5/site-packages/conda/cli/__pycache__/install.cpython-35.pyc
> differ
> Binary files 
> /gnu/store/302bb93kq3170xr57vijil7cya2s74ir-python-conda-4.3.16/lib/python3.5/site-packages/conda/__pycache__/__init__.cpython-35.pyc
> and 
> /gnu/store/302bb93kq3170xr57vijil7cya2s74ir-python-conda-4.3.16-check/lib/python3.5/site-packages/conda/__pycache__/__init__.cpython-35.pyc
> differ

Thanks for testing.  That indeed corresponds to the bug I mentioned
above, so it’s not specific to this package, don’t worry.  :-)

Ludo’.

Re: Installer, ISO9660, etc.

[Ludovic Courtès]

Danny Milosavljevic  skribis:

> On Fri, 07 Jul 2017 13:34:52 +0200
> l...@gnu.org (Ludovic Courtès) wrote:
>
>> Danny Milosavljevic  skribis:
>> 
>> > 95% done.  If would actually work if we came to a consensus about the 
>> > volume label (it must be uppercase; see bug# 27520 in guix-patches).  
>> > Also, UUID boot support is still mostly missing - same as in the 
>> > non-iso9660 case.  
>
>>I hope I’m not holding anything back in this area!
>
> Oh, not at all.  I'm just not clear on which way we chose (if any?).
>
> What was the string-upcase solution?  Even if it's created with 
> (string-upcase "GuixSD") (and it is - if you don't override it) the boot code 
> as it is now will still fail to find the root - because it matches labels 
> case-sensitively.  The string-upcase is buried deep within the image creation 
> procedure.

Right.

> Or do you mean I should put (string-upcase "GuixSD") in system-disk-image in 
> gnu/system/vm.scm as well ? That would work, I guess... although the finished 
> image (iso9660 or not!) would still have "GUIXSD" then.  I don't see that as 
> a big deal, though :)
>
> There's still the following places:
>
> ./gnu/build/vm.scm:search --set=root --label 
> gnu-disk-image~@
> ./gnu/system/install.scm:  (device "gnu-disk-image")
> ./gnu/system/vm.scm:"gnu-disk-image")
>
> Or do you mean we should just match case-insensitively in 
> gnu/build/file-systems.scm ?
>
> I.e. use
>
>  (define partition-label-predicate
>   (partition-predicate read-partition-label string-ci=?))
>
> That would mean match case-insensitively for both iso9660 and non-iso9660.  I 
> would very much prefer this fix.

What about this not-so-bad solution:

diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index 3e722d081..662fd0085 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -335,11 +335,18 @@ the image."
 system described by OS.  Said image can be copied on a USB stick as is.  When
 VOLATILE? is true, the root file system is made volatile; this is useful
 to USB sticks meant to be read-only."
+  (define normalize-label
+;; ISO labels are all-caps (case-insensitive), but since
+;; 'find-partition-by-label' is case-sensitive, make it all-caps here.
+(if (string=? "iso9660" file-system-type)
+string-upcase
+identity))
+
   (define root-label
 ;; Volume name of the root file system.  Since we don't know which device
 ;; will hold it, we use the volume name to find it (using the UUID would
 ;; be even better, but somewhat less convenient.)
-"gnu-disk-image")
+(normalize-label "gnu-disk-image"))
 
   (define file-systems-to-keep
 (remove (lambda (fs)

That way we preserve case-sensitivity for the other file systems.

If that’s fine with you, let’s do that!

Longer-term we should probably create  records for each
file system in (gnu build file-system); this would include, for each
file system, the ‘superblock?’ procedure, the ‘label’ procedure, and,
probably, a ‘label=?’ procedure.

Thanks,
Ludo’.

Re: Inkscape libpoppler error

[Daniel Pimentel]

Thanks Guixs :)

---
Daniel Pimentel (d4n1)

On 2017-07-08 23:21, Mark H Weaver wrote:

Kei Kebreau  writes:


Kei Kebreau  writes:


Daniel Pimentel  writes:


Hi guixs,

today I updated my GuixSD but my Inkscape not start :(

I installed poppler and I reinstaled inkscape too. In my
~/.guix-profile there isn't libpoppler.so.66 but in my system there:
/gnu/store/mpq4v7hgg02gl0bkjjq8612rm3sira5s-poppler-0.52.0/lib/libpoppler.so.66
/gnu/store/c31lmp5smk9snfyb8rf7mmzrdv15aps8-poppler-0.52.0/lib/libpoppler.so.66
/gnu/store/8c0bj7imclym7rmf1pa3cgf2xg1qbv25-poppler-0.52.0/lib/libpoppler.so.66

Error output:
inkscape: error while loading shared libraries: libpoppler.so.66:
cannot open shared object file: No such file or directory


Hi Daniel,

I just checked the inkscape package on my computer and I got the same
error. I'm looking into the problem now. Sorry for the inconvenience.


I've found the source of the issue and I'm seeing about fixing it. In
the meantime, you can reinstall inkscape using the following command:

guix package -i inkscape --no-grafts


For the details about what's going on here, see:

  https://bugs.gnu.org/27621

Please email further comments about this issue to: 
27...@debbugs.gnu.org


Thanks!
  Mark

Re: Guix infrastructure

[Liam Wigney]

Hey all,

While I'm aware it was mentioned that server power was mentioned as an issue, 
OpenQA might be of interest for automatic testing. 

> On 9 Jul 2017, at 6:51 pm, Ricardo Wurmus  wrote:
> 
> 
> Hi ng0,
> 
>> - master is not stable and it is not being treated as a high priority
>>  problem
> 
> I don’t know where you get this from and I don’t appreciate the
> insinuation that we don’t care.  The vast majority of commits to
> “master” are totally fine.
> 
> As we don’t have the resources for maintaining a stable branch, “master”
> is a best effort.
> 
>> - a bug in the compiler which is used in the core of Guix is bad.
> 
> We all agree here.  I don’t see the point of reiterating it.  The people
> who can fix it are already working on it — in their own time and in
> *addition* to all the things they regularly do.
> 
> Here’s a shout out to Ludo who tirelessly fixes old and new bugs,
> implements new features, improves performance, deals with GSoC, and
> answers community questions; to Andy Wingo who continuously improves
> Guile performance, implements new Guix services, drafted and implemented
> the potluck faster than I could blink, …; to Leo and Mark and Marius who
> keep on top of security issues despite the fact that this is no fun; —
> the list goes on and on.
> 
> Andy and Ludo are working on the Guile bug already.  I don’t see how
> this can reasonably result in complaints.
> 
>>  In my
>>  understanding that we could at least try to evade this by reducing the
>>  module sizes is met with arguments like "this will be fixed in the
>>  future, for now we can only split 1 module the rest has to stay
>>  together for semantic and linguistic reasons".
>>  If my understanding of the whole situation is wrong this is due to the
>>  intransparent dealing with this serious problem and the way my idea
>>  to temporarily fix it was met.
> 
> “Intransparent”?  I don’t know what else to say here.
> 
> Breaking up modules is *not* a fix, not even a temporary fix.  How would
> this help when Guile never frees memory and the cumulative usage ends up
> being the same?  This is something that needs to be fixed in Guile and
> both Andy and Ludo have already spent time to investigate this and come
> up with solutions.
> 
> I also wrote that splitting up (gnu packages python) is fine – yet I
> have not seen a patch that would do this.  There’s only so much a single
> person can do.
> 
> I’m skipping the rest of the complaints in this paragraph, because they
> add nothing new and ignore the late night efforts of people in the Guix
> and Guile communities.
> 
>> - Writing system services in Shepherd is hard.
> 
> I beg to differ.  If you have legitimate concerns please point out the
> sections in the manuals that are unclear and propose changes.
> 
>> These are the major issues Guix could fix.
> 
> “Guix” is people.
> 
> Personally, I don’t want to spend more time on this discussion, because
> I want to get back to getting things done that probably only few people
> will see or notice, but which need to be done anyway.
> 
> --
> Ricardo
> 
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
> 
> 

Re: core-updates on Hurd

[Ricardo Wurmus]

ren...@openmailbox.org writes:

> On 2017-07-07 10:41, ren...@openmailbox.org wrote:
>> Hello,
>> 
>> I attached the output of the command.
>> Thanks

What is going on here:

  201<--198(pid1070)->dir_readdir (0 -1 0) = 0 
"\xaad\x01\0\0\0\0\0\x10\0\0\x01.\0\0\0\xf7\xa2\b\0\0\0\0\0\x10\0\0\x02..\0\0+i\x01\0\0\0\0\0\x14\0\0\x05gd.go\0\0\0\xa1h\x01\0\0\0\0\0\x1c\0\0\fvalgrind.scm\0\0\0\0"
 760
  …
  201<--198(pid1070)->dir_readdir (760 -1 0) = 0 "" 0

?

I don’t really understand the output, but it looks like it read nothing
when reading the directory inode.  That’s right before it tries this:

  105<--153(pid1070)->dir_lookup ("home/buzz/guix/gnu/packages/zation.scm" 64 
0) = 0x4002 (No such file or directory) 

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: core-updates on Hurd

[Manolis Ragkousis]

On 07/09/17 13:20, Ricardo Wurmus wrote:
> 
> Manolis Ragkousis  writes:
> 
>> For example trying ./pre-inst-env guix build hello it fails with:
>>
>> 166<--165(pid2386)->io_write ("guix build: error: lstat: No such file or
>> directory: "/home/manolis/repos/guix/g" -1)guix build: error: lstat: No
>> such file or directory: "/home/manolis/repos/guix/gnu/packages/zation.scm"
>>  = 0 104
>>
>> Not here that there is no file named
>> "/home/manolis/repos/guix/gnu/packages/zation.scm". Could it be
>> something that there is something wrong with the guix build command?
> 
> There is no file called “zation.scm” but “serialization.scm”.
> 

Exactly Ricardo, for some reason files are getting corrupted.

Re: core-updates on Hurd

[Ricardo Wurmus]

Manolis Ragkousis  writes:

> For example trying ./pre-inst-env guix build hello it fails with:
>
> 166<--165(pid2386)->io_write ("guix build: error: lstat: No such file or
> directory: "/home/manolis/repos/guix/g" -1)guix build: error: lstat: No
> such file or directory: "/home/manolis/repos/guix/gnu/packages/zation.scm"
>  = 0 104
>
> Not here that there is no file named
> "/home/manolis/repos/guix/gnu/packages/zation.scm". Could it be
> something that there is something wrong with the guix build command?

There is no file called “zation.scm” but “serialization.scm”.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Guix infrastructure

[Ricardo Wurmus]

Hi ng0,

> - master is not stable and it is not being treated as a high priority
>   problem

I don’t know where you get this from and I don’t appreciate the
insinuation that we don’t care.  The vast majority of commits to
“master” are totally fine.

As we don’t have the resources for maintaining a stable branch, “master”
is a best effort.

> - a bug in the compiler which is used in the core of Guix is bad.

We all agree here.  I don’t see the point of reiterating it.  The people
who can fix it are already working on it — in their own time and in
*addition* to all the things they regularly do.

Here’s a shout out to Ludo who tirelessly fixes old and new bugs,
implements new features, improves performance, deals with GSoC, and
answers community questions; to Andy Wingo who continuously improves
Guile performance, implements new Guix services, drafted and implemented
the potluck faster than I could blink, …; to Leo and Mark and Marius who
keep on top of security issues despite the fact that this is no fun; —
the list goes on and on.

Andy and Ludo are working on the Guile bug already.  I don’t see how
this can reasonably result in complaints.

>   In my
>   understanding that we could at least try to evade this by reducing the
>   module sizes is met with arguments like "this will be fixed in the
>   future, for now we can only split 1 module the rest has to stay
>   together for semantic and linguistic reasons".
>   If my understanding of the whole situation is wrong this is due to the
>   intransparent dealing with this serious problem and the way my idea
>   to temporarily fix it was met.

“Intransparent”?  I don’t know what else to say here.

Breaking up modules is *not* a fix, not even a temporary fix.  How would
this help when Guile never frees memory and the cumulative usage ends up
being the same?  This is something that needs to be fixed in Guile and
both Andy and Ludo have already spent time to investigate this and come
up with solutions.

I also wrote that splitting up (gnu packages python) is fine – yet I
have not seen a patch that would do this.  There’s only so much a single
person can do.

I’m skipping the rest of the complaints in this paragraph, because they
add nothing new and ignore the late night efforts of people in the Guix
and Guile communities.

> - Writing system services in Shepherd is hard.

I beg to differ.  If you have legitimate concerns please point out the
sections in the manuals that are unclear and propose changes.

> These are the major issues Guix could fix.

“Guix” is people.

Personally, I don’t want to spend more time on this discussion, because
I want to get back to getting things done that probably only few people
will see or notice, but which need to be done anyway.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Guix infrastructure

[Ricardo Wurmus]

myglc2  writes:

 The bayfront hardware described here ...

 https://www.gnu.org/software/guix/news/growing-our-build-farm.html

 ... seems weak to me. Is there a plan to scale it up and make it redundant?
>>>
>>> It will be a lot more powerful than the current Hydra system. As for
>>> specific plans, I'll let those administering the system chime in.
>>
>> That machine is super powerful…
>
> Well, I disagree. A 2010 motherboard with 2 x 2011 CPUs (16 core at
> 1.6GHz) is weak compared to modern servers.

The machine is sufficiently powerful for what it should do.  It just
doesn’t do that yet, because it crashes.  Bayfront is *not* the build
farm, it’s just the front-end of that build farm.

> As you have experienced here, the learning/deployment costs and hassle
> associated with each new type of server often dwarfs other costs. The
> best way to minimize this is to minimize the number of types of servers
> you own.

The servers I’m preparing to add to the build farm once I’m back to the
office are all of the same type.  There are dozens of them.

> At this point it makes sense to abandon the Vikings motherboard and
> choose a popular, mainstream, current x86_64 motherboard. Since AMD has
> not been a competitive server vendor for the last ~8 years this means,
> practically speaking, picking a popular intel-based motherboard.

There is a group of sysadmins in contact with Vikings and taking care of
the build farm.  I’d rather keep the discussions about how to move
forward with our servers there.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: core-updates on Hurd

[Manolis Ragkousis]

Hello again,

I rebased my guix repo on the latest core-updates and you are correct.
On Hurd while building running make inside guix, something is going
wrong and changes the filenames guix is looking for while trying to
build packages.

For example trying ./pre-inst-env guix build hello it fails with:

166<--165(pid2386)->io_write ("guix build: error: lstat: No such file or
directory: "/home/manolis/repos/guix/g" -1)guix build: error: lstat: No
such file or directory: "/home/manolis/repos/guix/gnu/packages/zation.scm"
 = 0 104

Not here that there is no file named
"/home/manolis/repos/guix/gnu/packages/zation.scm". Could it be
something that there is something wrong with the guix build command?

Manolis

On 07/09/17 10:15, Manolis Ragkousis wrote:
> Hey Rene,
> 
> There seems to be something really wrong with your installation of guix.
> Files are missing. Did you delete something by hand?
> 
> 
> 105<--153(pid1070)->dir_lookup
> ("usr/local/share/locale/en_US.UTF-8/LC_MESSAGES/guix.mo" 1 0) =
> 0x4002 (No such file or directory)
>   105<--153(pid1070)->dir_lookup
> ("usr/local/share/locale/en_US.utf8/LC_MESSAGES/guix.mo" 1 0) =
> 0x4002 (No such file or directory)
>   105<--153(pid1070)->dir_lookup
> ("usr/local/share/locale/en_US/LC_MESSAGES/guix.mo" 1 0) = 0x4002
> (No such file or directory)
>   105<--153(pid1070)->dir_lookup
> ("usr/local/share/locale/en.UTF-8/LC_MESSAGES/guix.mo" 1 0) = 0x4002
> (No such file or directory)
>   105<--153(pid1070)->dir_lookup
> ("usr/local/share/locale/en.utf8/LC_MESSAGES/guix.mo" 1 0) = 0x4002
> (No such file or directory)
>   105<--153(pid1070)->dir_lookup
> ("usr/local/share/locale/en/LC_MESSAGES/guix.mo" 1 0) = 0x4002 (No
> such file or directory)
>  168<--167(pid1070)->io_write ("guix build: error: lstat: No such file
> or directory: "/home/buzz/guix/gnu/packag" -1) = 0 95
> 
> Manolis
> 

Re: core-updates on Hurd

[Manolis Ragkousis]

Hey Rene,

There seems to be something really wrong with your installation of guix.
Files are missing. Did you delete something by hand?


105<--153(pid1070)->dir_lookup
("usr/local/share/locale/en_US.UTF-8/LC_MESSAGES/guix.mo" 1 0) =
0x4002 (No such file or directory)
  105<--153(pid1070)->dir_lookup
("usr/local/share/locale/en_US.utf8/LC_MESSAGES/guix.mo" 1 0) =
0x4002 (No such file or directory)
  105<--153(pid1070)->dir_lookup
("usr/local/share/locale/en_US/LC_MESSAGES/guix.mo" 1 0) = 0x4002
(No such file or directory)
  105<--153(pid1070)->dir_lookup
("usr/local/share/locale/en.UTF-8/LC_MESSAGES/guix.mo" 1 0) = 0x4002
(No such file or directory)
  105<--153(pid1070)->dir_lookup
("usr/local/share/locale/en.utf8/LC_MESSAGES/guix.mo" 1 0) = 0x4002
(No such file or directory)
  105<--153(pid1070)->dir_lookup
("usr/local/share/locale/en/LC_MESSAGES/guix.mo" 1 0) = 0x4002 (No
such file or directory)
 168<--167(pid1070)->io_write ("guix build: error: lstat: No such file
or directory: "/home/buzz/guix/gnu/packag" -1) = 0 95

Manolis

Re: Guix infrastructure

[Efraim Flashner]

On July 7, 2017 6:00:42 AM GMT+03:00, Leo Famulari  wrote:
>On Thu, Jul 06, 2017 at 08:09:17PM -0400, myglc2 wrote:
>> On 07/01/2017 at 14:01 Leo Famulari writes:
>> > ... Bayfront is still not fully operational, so hydra.gnu.org is
>still
>> > serving as the front-end of the build farm. We are still relying on
>the
>> > Hydra software. That is, the situation is basically the same as
>before.
>> > Adding build machines will not help very much until the front-end
>> > hardware gets faster.
>> 
>> This leaves me wondering ...
>> 
>> Is the hydra/front-end hardware going to be upgraded?
>
>Yes...
>
>> Is bayfront/cuirass intended to replace hydra?
>
>... and yes.
>
>> The bayfront hardware described here ...
>> 
>> https://www.gnu.org/software/guix/news/growing-our-build-farm.html
>> 
>> ... seems weak to me. Is there a plan to scale it up and make it
>redundant?
>
>It will be a lot more powerful than the current Hydra system. As for
>specific plans, I'll let those administering the system chime in.
>
>> A reliable, resourced, managed, "nightly Guix build" should pay big
>> dividends for the project. But, from reading the lists, I get the
>> impression that such a thing does not exist. Is that correct?
>
>Currently, we tend to build all the packages as often as we can with
>our
>resources, which is less than once a day.
>
>> Do we know what would be needed to achieve a complete nightly build?
>
>It depends on what you mean by "complete".
>
>I doubt we can find armhf hardware that could build all the packages
>daily. That platform doesn't get very powerful in general and, in my
>experience, the machines that do exist can't handle sustained high
>loads, nor do they have fast network and I/O interfaces.
>
>It is possible for x86_64, i686, and eventually for aarch64. Maybe we
>will be able to cross-build from aarch64 to arhmf; I'm not sure.
>Efraim?

In theory it should be possible to build and run armhf packages on aarch64, in 
practice its not always the case. 
http://sjoerd.luon.net/posts/2017/07/debian-armhf-vm-on-arm64/ says:

On the 64 bit ARM side, we're running on Gigabyte MP30-AR1 based servers which 
can run 32 bit arm code (As opposed to e.g. ThunderX based servers which can 
only run 64 bit code). As such running armhf VMs on them to act as build slaves 
seems a good choice, but setting that up is a bit more involved than it might 
appear.


>
>Ricardo has been working on getting some new x86_64 / i686 builders
>online:
>
>https://gnunet.org/bot/log/guix/2017-06-30#T1433202

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.