core-updates is back

core-updates is back

[Ludovic Courtès]

Hi!

I pushed a new core-updates branch, with some of the changes I had in
mind.  Go ahead if you know of anything that needs to be fixed there.

As discussed before, we’ll merge the branch before June 13th.

Thanks,
Ludo’.

Re: core-updates is back

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> I pushed a new core-updates branch, with some of the changes I had in
> mind.  Go ahead if you know of anything that needs to be fixed there.
>
> As discussed before, we’ll merge the branch before June 13th.

One week left!

As far as I’m concerned, there are a few minor core package upgrades to
do, plus I’d like to make sure there are no reference leaks (in current
master, the final Findutils hold a reference to the bootstrap binaries.)

Ludo’.

core-updates is back

[Ludovic Courtès]

Hello!

‘core-updates’ is open again for updates to core packages (the implicit
inputs of ‘gnu-build-system’), their dependencies, or the (guix build …)
modules.

Things I’d like to see in this branch include:

  • Removing locales from ‘glibc’, and instead provide a separate
    package to build them on-demand, and then using $LOCPATH.  This will
    save a lot of space.

  • Maybe try using GCC 4.9.2 as the default compiler.

Other ideas welcome.

Ludo’.

Re: core-updates is back

[John Darrington]

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

On Sat, Nov 22, 2014 at 01:01:05PM +0100, Ludovic Courtès wrote:
     Hello!
     
     ‘core-updates’ is open again for updates to core packages (the implicit
     inputs of ‘gnu-build-system’), their dependencies, or the (guix build …)
     modules.
     
     Things I’d like to see in this branch include:

     [...]
     
     Other ideas welcome.

There is some oddness in cross-pkg-config: It creates a symlink to the real pkg-config,
But does not do so for the pkg.m4 file.  
I think the symlink is wrong anyway, since in the build environment the symlink target 
will not exist.

Unfortunately, since almost everything depends on pkg-config this is hard to test.

J'


     
     

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: core-updates is back

[Ludovic Courtès]

John Darrington <john@darrington.wattle.id.au> skribis:

> There is some oddness in cross-pkg-config: It creates a symlink to the real pkg-config,
> But does not do so for the pkg.m4 file.  

Why would the missing pkg.m4 be a problem?  It’s only used when
bootstrapping Autoconf-based packages.

(And if it’s really needed, it’s easy to add that symlink.)

> I think the symlink is wrong anyway, since in the build environment the symlink target 
> will not exist.

Of course it exists!

--8<---------------cut here---------------start------------->8---
$ guix build "/gnu/store/y634jqapqxs6ajzifx0shd8w7iaf9yrc-pkg-config-mips64el-linux-gnu-0.27.1.drv"
The following file will be downloaded:
   /gnu/store/9ycjrm4n6w4ar740vsxlacbd2x5s3khr-pkg-config-mips64el-linux-gnu-0.27.1
@ substituter-started /gnu/store/9ycjrm4n6w4ar740vsxlacbd2x5s3khr-pkg-config-mips64el-linux-gnu-0.27.1 /gnu/store/fkq63515pz3l8bdyi6qhchb9pida7pzp-guix-0.8.47739f5/libexec/guix/substitute-binary
found valid signature for '/gnu/store/9ycjrm4n6w4ar740vsxlacbd2x5s3khr-pkg-config-mips64el-linux-gnu-0.27.1', from 'http://hydra.gnu.org/nar/9ycjrm4n6w4ar740vsxlacbd2x5s3khr-pkg-config-mips64el-linux-gnu-0.27.1'
downloading `/gnu/store/9ycjrm4n6w4ar740vsxlacbd2x5s3khr-pkg-config-mips64el-linux-gnu-0.27.1' (0.0 MiB installed)...
http://hydra.gnu.org/nar/9ycjrm4n6w4ar740vsxlacbd2x5s3khr-pkg-config-mips64el-linux-gnu-0.27.1	   0.2 KiB transferred@ substituter-succeeded /gnu/store/9ycjrm4n6w4ar740vsxlacbd2x5s3khr-pkg-config-mips64el-linux-gnu-0.27.1
/gnu/store/9ycjrm4n6w4ar740vsxlacbd2x5s3khr-pkg-config-mips64el-linux-gnu-0.27.1

$ ls -l /gnu/store/9ycjrm4n6w4ar740vsxlacbd2x5s3khr-pkg-config-mips64el-linux-gnu-0.27.1/bin/
total 4
lrwxrwxrwx 2 root root 76  1 janv.  1970 mips64el-linux-gnu-pkg-config -> /gnu/store/s432k19icqqjchfp83klghv3p07q5hdd-pkg-config-0.27.1/bin/pkg-config

$ guix gc --references /gnu/store/9ycjrm4n6w4ar740vsxlacbd2x5s3khr-pkg-config-mips64el-linux-gnu-0.27.1
/gnu/store/s432k19icqqjchfp83klghv3p07q5hdd-pkg-config-0.27.1
--8<---------------cut here---------------end--------------->8---

Thanks,
Ludo’.

Re: core-updates is back

[John Darrington]

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

On Sat, Nov 22, 2014 at 06:36:47PM +0100, Ludovic Courtès wrote:
     John Darrington <john@darrington.wattle.id.au> skribis:
     
     > There is some oddness in cross-pkg-config: It creates a symlink to the real pkg-config,
     > But does not do so for the pkg.m4 file.  
     
     Why would the missing pkg.m4 be a problem?  It’s only used when
     bootstrapping Autoconf-based packages.

Right.  If you want to bootstrap an autoconf based package (for example, guix-devel from package-management.scm),
then it will fail.
     
     (And if it’s really needed, it’s easy to add that symlink.)
     
     
     Of course it exists!

I thought that whilst bulding things were in a chroot jail where only those things explicitly declared as inputs
actually existed.

J'
     

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: core-updates is back

[Ludovic Courtès]

John Darrington <john@darrington.wattle.id.au> skribis:

> On Sat, Nov 22, 2014 at 06:36:47PM +0100, Ludovic Courtès wrote:
>      John Darrington <john@darrington.wattle.id.au> skribis:
>      
>      > There is some oddness in cross-pkg-config: It creates a symlink to the real pkg-config,
>      > But does not do so for the pkg.m4 file.  
>      
>      Why would the missing pkg.m4 be a problem?  It’s only used when
>      bootstrapping Autoconf-based packages.
>
> Right.  If you want to bootstrap an autoconf based package (for example, guix-devel from package-management.scm),
> then it will fail.

Oh right, this one is a good example.  I’ll add the symlink.

>      (And if it’s really needed, it’s easy to add that symlink.)
>      
>      
>      Of course it exists!
>
> I thought that whilst bulding things were in a chroot jail where only those things explicitly declared as inputs
> actually existed.

More precisely, the inputs *and* their run-time dependencies are
available.

For instance, if a package has Coreutils as an input, then its build
process gets both Coreutils and libc in its chroot (otherwise the
Coreutils programs would be unusable.)

Ludo’.