‘core-updates’ schedule

[Ludovic Courtès]

Hello Guix!

This ‘core-updates’ cycle was terribly long, so I suggest to write down
a schedule and then try hard to stick to it.  ;-)

What about this:

  • May 25th, ‘core-updates’ branch frozen (i.e., rebuild-the-world
changes are no longer accepted);

  • June 15th, ‘core-updates’ merged in ‘master’ (i.e., most regressions
compared to ‘master’ have been fixed).

How does that sound?

If anyone wants to make non-trivial changes in ‘core-updates’, let’s
make them as early as possible.

I for one would like to finally merge ‘wip-build-systems-gexp’ so I’ll
try to do that.  There’s also support for response files in
‘ld-wrapper’, but that is easier (see ).

Last but not least: who wants to be the timekeeper?  The position mostly
consists in firmly reminding people of the schedule.  :-)

Ludo’.

Github mirror and archive

[Pjotr Prins]

A bit of a long post, but I would like some feedback:



** Going off github

Because of the discussion around JOSS I did a thought experiment last
night and it scares me: what if I closed my Google account, what if I
closed Facebook and what if I closed github. I'll turn this into a
BLOG entry, most likely.

Facebook would be the easy one (if they allow you - I think you can't
remove it). I use Facebook about weekly to check on some friends and
read a cartoon. Closing Facebook would have no impact on my life
though changing accounts would be a hassle because I would need to
re-register the interesting friends.

Google is a bit harder. I use gmail to monitor the JOSS mailing list
and a few others. I run my own mail server so I can switch Google
accounts and easily re-register. You can't use groups without a Google
account, but if I closed today I could be back when I wanted with a
different account. No real harm done. I also need it for the Google
Summer of Code (GSoC).  Google is famous for tracking and when you are
logged in (as we normally are) it can track the sites you visit. It is
enlightening to visit

 
https://myactivity.google.com/myactivity?utm_source=my-account&utm_medium=&utm_campaign=my-acct-promo

For example I visited the Dlang website yesterday which apparently is
tracked via facebook AND google. Google knows where I am and that I
rented a car and my current interest is supercomputing. I have decided
to start switching Google accounts annually. Fortunately Google caters
for that - so I am not the only one. Even GSoC requires you to
re-register every year.

Now Github. I am one of the early github adopters and created my first
repository November 2008. Being a Ruby guy I was aware of the garage
startup and very much in favour of what they were attempting. It was
(and perhaps is) a cool distributed company. But now it is very
critical to my work flow. Too critical, I think, because even the
thought experiment of removing my account scares me. First of all
github provides me an internet personae. Anyone who wants to assess my
work can visit github and get a clear picture of what I am working on.
This is a valuable resource, but I can probably move it elsewhere
without too much loss. Github has a nice way of showing work, though,
and it is easy to see what organizations I am contributing to and what
type of comments I post. I always tell students that the github track
record is more important (to people like me) than the publishing
record in scientific journal. Code is much clearer to me about what
people (can) contribute. I therefore use github to assess and monitor
other peoples work. Hosting your code elsewhere, as long as it has a
decent interface, is good enough for me - I'll change that
recommendation to something more generic. Commenting on multiple sites
will need multiple accounts.

So I need an account for github hosted repositories, but I can switch
accounts annually without too many concerns, though it will be a
hassle.

There are a few projects and organizations, however, which make it
very hard to leave my account and one of them is my work environment
(https://github.com/genenetwork) and the other is the Journal of Open
Source Software (JOSS). They require an account and they, implicitely,
require me to use the same account over time. These two environments
(and a few others) depend on all members in the organization to be
stable. It would not do if everyone switched accounts every year.

GeneNetwork could move elsewhere, but it would make it much harder to
collaborate. People already have github accounts which makes it easy
to contribute. Being on a different site requires people logging in
separately and would impact contributions (including bug reports) for
sure. I am certain this will have an impact: you want to make
contributing as easy as possible (especially in Science where people
don't have patience to juggle accounts).

The key thing here is the issue tracker. Github made it so that you
can not easily move the issue tracker to a different provider. Much of
the value of github is in using the issue trackers.

This cluster effect is much more visible on JOSS. In fact the journal
can not exist without github because the software stack is (1) built
on the issue tracker and (2) attracts authors and reviewers through
its network. Removing my account would invalidate the reviews I am
involved in and moving JOSS elsewhere would loose the cluster effect.

In all, I have come to depend on github, critically because
organizations I am involved in would be severely impacted when we
moved elsewhere. Even for GNU Guix - which pointedly does not use
github - would be severely hampered if something happened to
github. So many projects are hosted on github that distribution and
deployment of free software would be severely broken if github went
down. In other words we have built a monster.

People wrote me that they are concerned about other trends. For
example the Julia language is ba

Re: Github mirror and archive

[Catonano]

2017-04-06 11:53 GMT+02:00 Pjotr Prins :


In all, I have come to depend on github, critically because
> organizations I am involved in would be severely impacted when we
> moved elsewhere. Even for GNU Guix - which pointedly does not use
> github - would be severely hampered if something happened to
> github. So many projects are hosted on github that distribution and
> deployment of free software would be severely broken if github went
> down. In other words we have built a monster.
>

[...]



> Also
> software releases distributed by github should be mirrored elsewhere.
> GNU Guix, for example, should mirror and fully archive the source
> tarballs that github provides.
>

A side note: If and when Guix will have GNUnet, it could use it to
distribute non only binaries but also tarballs

Re: ‘core-updates’ schedule

[Leo Famulari]

On Thu, Apr 06, 2017 at 10:34:29AM +0200, Ludovic Courtès wrote:
> This ‘core-updates’ cycle was terribly long, so I suggest to write down
> a schedule and then try hard to stick to it.  ;-)

At the beginning of the cycle, I was confident that we could build and
merge it in 2 or 3 weeks. But, it took about 6 weeks before we could
merge.

Something we can all do to speed up the process is try `guix package -u`
and `guix system build`, starting at the beginning of the freeze. [0]

You will find build failures before they show up on Hydra, and find bugs
and regressions before we merge core-updates into master. Our build farm
is relatively slow and unreliable, so it's inefficient to wait for it to
find build failures; it won't find applications bugs at all in many
cases.

> Last but not least: who wants to be the timekeeper?  The position mostly
> consists in firmly reminding people of the schedule.  :-)

I tried to do it this time around, but we kept finding bugs and
experiencing build failures that we couldn't ignore.

[0] I was able to rely on core-updates after ~3 weeks (excluding
libreoffice).

Re: Non-graphical GRUB configuration

[Leo Famulari]

On Wed, Apr 05, 2017 at 04:43:32PM -0400, myglc2 wrote:
> > ... you won't get '--unit=0' unless you specify (serial-unit 0) in your
> > GuixSD configuration. However, GRUB defaults to '0', according to its
> > manual.
> 
> Yes I noticed. I was operating on the hope that less would be more ;-)

I decided against hard-coding the current GRUB defaults into this code.
I'd rather take them from GRUB at run-time, and accept the upstream
changes as they come. Plus, we won't have to update our code as often :)

Re: 04/05: gnu: xorg-server: Update to 1.19.3.

[Leo Famulari]

On Thu, Apr 06, 2017 at 10:04:12AM -0400, Marius Bakke wrote:
> mbakke pushed a commit to branch staging
> in repository guix.
> 
> commit 7c42cc7738cb28f393b17f9074a264607456c012
> Author: Marius Bakke 
> Date:   Thu Apr 6 15:42:15 2017 +0200
> 
> gnu: xorg-server: Update to 1.19.3.
> 
> * gnu/packages/xorg.scm (xorg-server, xorg-server-xwayland): Update to 
> 1.19.3.
> [native-inputs]: Remove FONT-UTIL, LIBTOOL, AUTOMAKE and AUTOCONF.
> [arguments]: Remove 'bootstrap' phase.

This can go straight to master, right?

$ guix refresh -l -e '(@@ (gnu packages xorg) xorg-server)'
Building the following 72 packages would ensure 127 dependent packages are
rebuilt: xf86-video-i128-1.3.6 xf86-input-void-1.4.1 xf86-video-geode-2.11.19
xf86-video-vesa-2.3.4 xf86-video-tga-1.2.2 xf86-video-sunffb-1.2.2
xf86-input-synaptics-1.9.0 xf86-video-cirrus-1.5.3 xf86-video-mach64-6.9.5
xf86-input-keyboard-1.9.0 xfce-4.12.0 xf86-video-neomagic-1.2.9
xf86-video-ark-0.7.5 xf86-video-vmware-13.2.1 xf86-video-siliconmotion-1.7.9
xf86-video-r128-6.10.2 xf86-video-nouveau-1.0.14 xf86-video-suncg6-1.1.2
xf86-video-glint-1.2.9 xf86-video-trident-1.3.8 xf86-video-tdfx-1.4.7
xf86-video-ati-7.8.0 xf86-video-mga-1.6.5 xf86-input-mouse-1.9.2
xf86-video-fbdev-0.4.4 xf86-input-joystick-1.6.3 xf86-video-openchrome-0.5.0
xf86-video-nv-2.1.21 xf86-video-voodoo-1.2.5 xf86-video-intel-2.99.917-4-7e9e92c
xf86-input-evdev-2.10.5 xf86-video-sis-0.10.9 xf86-video-savage-2.3.9
xf86-video-qxl-0.1.5 gnome-disk-utility-3.22.1 vim-full-8.0.0494 guile-sly-0.1
awesome-4.0 kplotting-5.28.0 kimageformats-5.28.0 kdesignerplugin-5.28.0
lxqt-common-0.9.1 lxqt-session-0.9.0 kdesu-5.28.0 kemoticons-5.28.0
kpeople-5.28.0 kpmcore-2.2.1 baloo-5.28.0 kactivities-stats-5.28.0 kded-5.28.0
kxmlrpcclient-5.28.0 kdevelop-5.0.4 pspp-0.10.2 denemo-2.1 xpad-4.8.0
gnome-calculator-3.22.2 pavucontrol-3.0 gnome-system-monitor-3.22.2
synfigstudio-1.0.2 gobby-0.4.13 higan-101 beast-0.10.0 d-feet-0.3.11
proof-general-4.2 laby-0.6.4 gsegrafix-1.0.6 guile-gnome-2.16.4 linsmith-0.99.30
gnome-3.22.2 gnome-maps-3.18.3 weston-2.0.0 greenisland-0.9.0.1


signature.asc
Description: PGP signature

Re: 04/05: gnu: xorg-server: Update to 1.19.3.

[Marius Bakke]

Leo Famulari  writes:

> On Thu, Apr 06, 2017 at 10:04:12AM -0400, Marius Bakke wrote:
>> mbakke pushed a commit to branch staging
>> in repository guix.
>> 
>> commit 7c42cc7738cb28f393b17f9074a264607456c012
>> Author: Marius Bakke 
>> Date:   Thu Apr 6 15:42:15 2017 +0200
>> 
>> gnu: xorg-server: Update to 1.19.3.
>> 
>> * gnu/packages/xorg.scm (xorg-server, xorg-server-xwayland): Update to 
>> 1.19.3.
>> [native-inputs]: Remove FONT-UTIL, LIBTOOL, AUTOMAKE and AUTOCONF.
>> [arguments]: Remove 'bootstrap' phase.
>
> This can go straight to master, right?

I don't think so, because of the inputs and arguments change, which
would affect xorg-server-1.19.2 as well (and cause the build to fail).

Commit 3433413b18f02436eb8459d097947257ac6973f7 addresses this, so
future xorg-server updates should indeed be eligible for 'master'.


signature.asc
Description: PGP signature

Re: 01/02: gnu: Add emacs-ag.

[myglc2]

On 01/18/2017 at 10:02 Alex Kost writes:

> alezost pushed a commit to branch master
> in repository guix.
>
> commit cf006d2e738f473e7fb630b566e04c4872fa204b
> Author: Christopher Baines 
> Date:   Tue Jan 17 20:07:06 2017 +

Hi Alex & Christopher,

I installed emacs-ag but was a bit disappointed there was no INFO. I see
it can be built from ...

/gnu/store/...emacs-ag-0.47/share/emacs/site-lisp/guix.d/ag-0.47/docs

... using python-sphinx + texinfo. Is there any interest on your part(s)
in adding INFO to the package? If not, I was wondering how one might add
it. Would it be something like ...

(native-inputs ;; so we can build INFO doc
 `(("python-sphinx" ,python-sphinx)
   ("texinfo" ,texinfo)))

... plus fiddle with #:phases? Or is there a better way? TIA - George

Re: Non-graphical GRUB configuration

[myglc2]

On 04/06/2017 at 11:18 Leo Famulari writes:

> On Wed, Apr 05, 2017 at 04:43:32PM -0400, myglc2 wrote:
>> > ... you won't get '--unit=0' unless you specify (serial-unit 0) in your
>> > GuixSD configuration. However, GRUB defaults to '0', according to its
>> > manual.
>> 
>> Yes I noticed. I was operating on the hope that less would be more ;-)
>
> I decided against hard-coding the current GRUB defaults into this code.
> I'd rather take them from GRUB at run-time, and accept the upstream
> changes as they come. Plus, we won't have to update our code as often :)

Nice!

Re: 01/02: gnu: Add emacs-ag.

[Alex Kost]

myglc2 (2017-04-06 13:06 -0400) wrote:

> On 01/18/2017 at 10:02 Alex Kost writes:
>
>> alezost pushed a commit to branch master
>> in repository guix.
>>
>> commit cf006d2e738f473e7fb630b566e04c4872fa204b
>> Author: Christopher Baines 
>> Date:   Tue Jan 17 20:07:06 2017 +
>
> Hi Alex & Christopher,
>
> I installed emacs-ag but was a bit disappointed there was no INFO. I see
> it can be built from ...
>
> /gnu/store/...emacs-ag-0.47/share/emacs/site-lisp/guix.d/ag-0.47/docs
>
> ... using python-sphinx + texinfo. Is there any interest on your part(s)
> in adding INFO to the package?

No interest from me: I've never used 'emacs-ag' and am not going to do
it, sorry :-(

> If not, I was wondering how one might add
> it. Would it be something like ...
>
> (native-inputs ;; so we can build INFO doc
>  `(("python-sphinx" ,python-sphinx)
>("texinfo" ,texinfo)))
>
> ... plus fiddle with #:phases? Or is there a better way? TIA - George

It is probably the only way: one need to add a phase that would run
"makeinfo" (as it is done in 'haskell-mode' package, for example).
Though I have no idea how 'python-sphinx' should be used there.

-- 
Alex

Re: 04/05: gnu: xorg-server: Update to 1.19.3.

[Leo Famulari]

On Thu, Apr 06, 2017 at 06:11:02PM +0200, Marius Bakke wrote:
> Leo Famulari  writes:
> > On Thu, Apr 06, 2017 at 10:04:12AM -0400, Marius Bakke wrote:
> >> gnu: xorg-server: Update to 1.19.3.
> >> 
> >> * gnu/packages/xorg.scm (xorg-server, xorg-server-xwayland): Update to 
> >> 1.19.3.
> >> [native-inputs]: Remove FONT-UTIL, LIBTOOL, AUTOMAKE and AUTOCONF.
> >> [arguments]: Remove 'bootstrap' phase.
> >
> > This can go straight to master, right?
> 
> I don't think so, because of the inputs and arguments change, which
> would affect xorg-server-1.19.2 as well (and cause the build to fail).
> 
> Commit 3433413b18f02436eb8459d097947257ac6973f7 addresses this, so
> future xorg-server updates should indeed be eligible for 'master'.

Ah, right! Thank you for explaining :)


signature.asc
Description: PGP signature

cuirass question

[myglc2]

In "6.2.7.15 Continuous Integration" there is a reference to
'(https://notabug.org/mthl/cuirass)' but the doc is for GuixSD '(gnu
services cuirass)'.

And git://git.sv.gnu.org/guix/maintenance.git/hydra/bayfront.scm also
uses GuixSD '(gnu services cuirass)'.

So here is the question... Is it correct to assume that the primary
cuirass way forward is (gnu servies cuirass) on GuixSD?

If so, should the reference to '(https://notabug.org/mthl/cuirass)' be
removed?

TIA - George

cuirass question

[myglc2]

In "6.2.7.15 Continuous Integration" there is a reference to
'(https://notabug.org/mthl/cuirass)' but the doc is all for of GuixSD
'(gnu services cuirass)'. Also
git://git.sv.gnu.org/guix/maintenance.git/hydra/bayfront.scm uses GuixSD
'(gnu services cuirass)'.

This left me wondering... has '(https://notabug.org/mthl/cuirass)' been
replaced by (gnu servies cuirass) on GuixSD?

If so, should the reference to '(https://notabug.org/mthl/cuirass)' be
removed?

TIA - George

Re: 'guix build' and garbage collection

[Chris Marusich]

l...@gnu.org (Ludovic Courtès) writes:

> Hi!
>
> Chris Marusich  skribis:
>
>> Do you know why the intensional model hasn't been deployed in the 11
>> years since the thesis was published?  To learn more, I can think of a
>> few places to look (Nix email lists, other Nix-related research papers),
>> but if you have specific recommendations, it would be helpful!
>
> The intensional model (content-address item) works well if and only if
> packages are 100% bit-reproducible, which they are not (yet!).
>
> Also I’m not sure how substitutes could work with this model since one
> cannot refer to the build result until it’s available.

FYI, section 6.4.4 (p. 157) of Eelco's thesis describes how substitution
works in the intensional model.  When performing substitution for a
store path p, if a trusted substitute for p has been registered, then it
is tried, and the substitution is considered successful if and only if
the output's content-addressed store path equals p.

If I learn more about why Nix doesn't use the intensional model, I'll
let you know.

-- 
Chris


signature.asc
Description: PGP signature

Re: Github mirror and archive

[Pjotr Prins]

On Thu, Apr 06, 2017 at 09:53:02AM +, Pjotr Prins wrote:
> A bit of a long post, but I would like some feedback:

I guess most of you agree ;). Preaching to the converted.

Pj.